Từ Phân loại Ý định đến Không gian Hành động Mở rộng: Tại sao Kiểm thử Di động Cần Mô hình Mới

Tôi là người tạo ra Drengr, một máy chủ MCP (Model Context Protocol) trao cho các tác nhân AI khả năng quan sát và thao tác trên thiết bị di động. Tôi bắt đầu blog này để chia sẻ về mặt kỹ thuật đằng sau nó. Không giả vờ là một quan sát viên trung lập viết một bài phân tích — tôi đã xây dựng công cụ này và tôi ở đây để nói về nó.

Gần đây, Google đã ra mắt AI Edge Gallery — một ứng dụng hộp cát AI trên thiết bị với tính năng "Mobile Actions" cho phép bạn kiểm soát điện thoại bằng ngôn ngữ tự nhiên. Hãy nói "bật đèn pin", một mô hình 270 triệu tham số tên là FunctionGemma sẽ xác định ý định, trích xuất tham số và gửi lời gọi hàm phù hợp. Nó chạy hoàn toàn ngoại tuyến. Nó đạt tốc độ 1.916 token/giây trên Pixel 7 Pro. Và nó thực sự ấn tượng.

Nhưng nó cũng bộc lộ một giới hạn.

Giả định Thế giới Khép kín

Về bản chất, FunctionGemma là một động cơ NLU (Xử lý ngôn ngữ tự nhiên) nhỏ thực hiện phân loại ý định và điền thông tin vào vị trí (slot filling). Bạn nói. Nó phân loại câu của bạn vào một trong các ý định cố định — turnOnFlashlight, createCalendarEvent, showLocationOnMap — và trích xuất các vị trí liên quan: thời gian, địa điểm, tên liên hệ. Mã ứng dụng gốc sau đó gửi đầu ra có cấu trúc tới API nền tảng tương ứng.

Đây là một hệ thống thế giới khép kín. Mọi hành động có thể thực hiện đều được biết đến tại thời điểm biên dịch. Mọi hàm đều được đăng ký trước. Mọi vị trí đều được xác định trước. Công việc của mô hình là so khớp mẫu trên một không gian hành động bị giới hạn — cùng thiết kế cơ bản mà Dialogflow, Alexa Skills và SiriKit Intents đã sử dụng trong nhiều năm, nay chạy trên thiết bị với tốc độ đáng kinh ngạc. Các nền tảng này đã phát triển theo thời gian — App Intents của Apple, tính năng AI tạo sinh của Alexa — nhưng kiến trúc lược đồ ý định (intent-schema) bên dưới vẫn mang tính chất thế giới khép kín theo thiết kế.

Nó hoạt động tuyệt vời với những gì nó có. Nhưng nó không thể làm những gì nó chưa từng được biết là tồn tại.

Vấn đề Thế giới Mở

Bây giờ hãy xem xét một kịch bản khác. Bạn là một kỹ sư QA. Bạn cần xác minh rằng ứng dụng giao hoa áp dụng chính xác mã khuyến mãi tại thanh toán, tổng tiền trong giỏ hàng được cập nhật và màn hình xác nhận hiển thị tóm tắt đơn hàng đúng. Ứng dụng được xây dựng bởi nhóm của bạn. Không ai đăng ký các yếu tố UI của nó dưới dạng các hàm có thể gọi. Không ai tinh chỉnh mô hình trên hệ thống phân loại màn hình của nó.

Đây là một vấn đề thế giới mở. Không gian hành động là không giới hạn. UI là tùy ý. Các màn hình chưa từng được nhìn thấy bởi tác nhân kiểm thử trước đây.

Đây là vấn đề mà Drengr giải quyết.

Tri giác Ưu tiên Văn bản, Không bao giờ Cần Lược đồ

Drengr là một máy chủ MCP — giao thức mở kết nối các mô hình AI với các công cụ và nguồn dữ liệu bên ngoài, theo cách tương tự như LSP (Giao thức Máy chủ Ngôn ngữ) kết nối trình biên tập với các máy chủ ngôn ngữ. Drengr được xây dựng chuyên biệt để tương tác UI di động. Nó không yêu cầu ứng dụng của bạn phải lộ API. Nó không cần nhãn khả năng truy cập (mặc dù nó sử dụng chúng khi có sẵn). Nó không yêu cầu bạn định nghĩa ý định hoặc đăng ký hàm.

Thay vào đó, nó hoạt động thông qua ba nguyên thủy:

• drengr_look — Chụp trạng thái màn hình hiện tại dưới dạng mô tả văn bản thu gọn (~300 token mỗi màn hình) hoặc một hình ảnh được chú thích với các phần tử được đánh số. Ưu tiên văn bản theo mặc định — thị giác chỉ được sử dụng khi ít hơn 60% phần tử có nhãn. Rẻ hơn 100 lần so với việc gửi ảnh chụp màn hình ở mỗi bước.
• drengr_do — Thực hiện 13 hành động trên thiết bị: chạm, nhập, vuốt, nhấn lâu, quay lại, về trang chủ, khởi chạy, đợi, nhấn phím, cài đặt, xóa và nhập, cuộn lên đầu, cuộn xuống cuối. Mỗi hành động trả về một báo cáo tình huống — một diff có cấu trúc về những gì thay đổi trên màn hình (phần tử mới, phần tử biến mất, phát hiện lỗi, phát hiện bị kẹt).
• drengr_query — Các truy vấn có cấu trúc về trạng thái thiết bị và ứng dụng: liệt kê các thiết bị đã kết nối, kiểm tra hoạt động hiện tại, phát hiện lỗi, tìm phần tử theo văn bản, khám phá điều hướng ứng dụng, đọc các cuộc gọi mạng, kiểm tra trạng thái bàn phím, đổ cây UI thô, v.v.

Client AI — Claude Desktop, Cursor, Windsurf, VS Code hoặc bất kỳ máy chủ MCP tương thích nào — đóng vai trò là "bộ não". Drengr cung cấp "mắt" và "tay". Tác nhân nhìn vào một màn hình mà nó chưa từng thấy, hiểu những gì ở đó, quyết định việc cần làm và thực hiện nó. Không cần huấn luyện trước trên ứng dụng của bạn. Không cần bảo trì kịch bản kiểm thử. Không có bộ chọn XPath mong manh bị vỡ mỗi lần sprint.

Tại sao Sự phân biệt này Quan trọng

Sự khác biệt giữa việc gửi hàm thế giới khép kín và tương tác UI thế giới mở không phải là gia tăng. Nó mang tính kiến trúc.

	Thế giới Khép kín (FunctionGemma)	Thế giới Mở (Drengr)
Không gian hành động	Các hàm cố định, xác định trước	Tùy ý, khám phá tại thời gian chạy
Kiến thức UI	Được biên dịch vào mô hình	Quan sát trên từng màn hình qua văn bản + dự phòng thị giác
Hỗ trợ ứng dụng mới	Cần tinh chỉnh hoặc đăng ký hàm	Hoạt động ngay lập tức với bất kỳ ứng dụng nào
Chế độ thất bại	"Tôi không có hàm cho việc đó"	"Tôi có thể thấy màn hình — hãy để tôi tìm hiểu"
Kiến trúc	NLU → gửi hàm	Tri giác → suy luận → hành động

FunctionGemma là một bộ phân loại. Drengr là một tác nhân.

Lợi thế của MCP

Drengr được xây dựng như một máy chủ MCP — cùng mẫu kiến trúc đã làm cho LSP trở thành xương sống của mọi trình soạn thảo mã hiện đại. Chính Anthropic cũng đã vẽ ra sự tương đồng này trong đặc tả MCP: cả hai giao thức đều giải quyết vấn đề tích hợp M×N. LSP kết nối M trình soạn thảo với N máy chủ ngôn ngữ. MCP kết nối M client AI với N máy chủ công cụ. Cả hai đều sử dụng vận chuyển JSON-RPC 2.0.

Điều này có nghĩa là Drengr không phụ thuộc vào một LLM duy nhất. Ngày nay, nhà phát triển có thể kết nối Claude Code, Cursor hoặc Windsurf làm lớp suy luận, và Drengr xử lý tương tác thiết bị. Ngày mai, khi một mô hình tốt hơn xuất hiện, bạn thay thế "bộ não" mà không cần đụng đến công cụ.

Sự tách biệt mối quan tâm này — mô hình suy nghĩ, máy chủ hành động — chính là điều làm cho kiến trúc này bền vững.

Công cụ này Dành cho ai

• Kỹ sư QA mệt mỏi với việc duy trì các tập lệnh Appium bị vỡ mỗi chu kỳ phát hành.
• Nhà phát triển di động muốn xác thực các luồng người dùng mà không cần viết mã kiểm thử.
• Trưởng bộ phận kỹ thuật khám phá kiểm thử dựa trên tác nhân như một lực số nhân cho các nhóm nhỏ.
• Đội ngũ công cụ AI đánh giá cơ sở hạ tầng tương thích MCP để tự động hóa di động.

Đặt lại Vấn đề Kiểm thử

Tự động hóa kiểm thử di động truyền thống đặt câu hỏi: "Làm thế nào để tôi viết kịch bản cho robot nhấn các nút đúng?"

Drengr đặt câu hỏi: "Điều gì sẽ xảy ra nếu robot chỉ cần nhìn vào màn hình và tự tìm hiểu?"

Việc định dạng lại vấn đề này — từ tự động hóa theo kịch bản sang khả năng hành động dựa trên tri giác — chính là sự thay đổi mô hình. Nó là sự khác biệt giữa đưa cho ai đó một bản đồ với mọi ngã rẽ được đánh dấu sẵn, và trao cho họ đôi mắt cùng khả năng định hướng.

Google đã chứng minh rằng NLU trên thiết bị có thể gửi tới một vài hàm của hệ điều hành với tốc độ chóng mặt. Drengr chứng minh rằng một LLM với các công cụ phù hợp có thể hoạt động trên bất kỳ ứng dụng, bất kỳ màn hình, bất kỳ luồng nào — mà không bao giờ được biết trước điều gì sẽ xảy ra.

Drengr miễn phí sử dụng và có sẵn trên npm. Nó hỗ trợ Android (thiết bị vật lý, trình giả lập), trình giả lập iOS (hỗ trợ cử chỉ đầy đủ) và các trang trại thiết bị đám mây (BrowserStack, SauceLabs, AWS Device Farm, LambdaTest, Perfecto, Kobiton). Được xây dựng bằng Rust. Tệp nhị phân duy nhất. Không có phụ thuộc thời gian chạy.