Benchmark phone agent Android: cách đánh giá mobile agent đáng tin cậy năm 2026

Benchmark phone agent Android nên đo điều gì

Đánh giá phone agent Android không thể dừng ở câu hỏi “agent có bấm được vài nút không”. Một benchmark tốt phải đo kết quả đã xác minh và quá trình đi tới kết quả đó. Tác vụ chỉ được tính là đạt khi mục tiêu được hiểu đúng, trạng thái Android phù hợp, hành động nằm trong phạm vi được phép, side effect đúng với kỳ vọng và kết quả sau cùng được kiểm tra bằng bằng chứng quan sát được.

Từ kinh nghiệm xây FoneClaw, chúng tôi chia thành bốn lớp. Lớp đầu là hiểu mục tiêu: agent có biết người dùng muốn gì, thiếu gì và cần hỏi lại ở đâu không. Lớp thứ hai là thực thi: agent có dùng đúng GUI, công cụ có cấu trúc hoặc workflow Android được hỗ trợ không. Lớp thứ ba là kiểm soát: quyền, phê duyệt, dừng và tiếp quản tay có xuất hiện đúng lúc không. Lớp cuối là phục hồi: khi quyền mất, app đổi giao diện hoặc người dùng ngắt giữa chừng, agent có đưa ra đường sửa cụ thể không.

Vì vậy, benchmark phone agent Android nên ghi lại cả pass, fail, partial, wrong side effect và recovered. Một chuỗi tap nhìn có vẻ hợp lý vẫn chưa phải kết quả nếu app chưa đổi trạng thái, tin nhắn gửi sai người, hoặc quyền được yêu cầu sai thời điểm. Với vòng cải thiện kỹ năng và harness dài hạn, bài Phone agent tự cải thiện: phiên bản kỹ năng, kiểm thử và hoàn tác là phần đọc tiếp về governance của bộ kiểm thử.

Bức tranh benchmark mobile agent năm 2026

Năm 2026 có nhiều benchmark mobile agent đáng chú ý, mỗi bộ phơi bày một khoảng trống khác nhau. Cách đọc đúng là dùng chúng như ống kính thiết kế bộ test, không ghép điểm số thành một leaderboard chung. Mỗi benchmark có app, môi trường, số bước, cách chấm và mức tương tác người dùng riêng.

Với FoneClaw, chúng tôi dùng các bài học này để thiết kế bộ kiểm thử nội bộ: thay đổi ngôn ngữ, thay đổi app state, thêm tác vụ nhiều bước, ghi phê duyệt và đo phục hồi. Phần khám phá năng lực đáng tin cậy cũng cần được kiểm thử riêng; bài Agentic Resource Discovery: ai-catalog.json, xác minh và quyền cho phone agent đi sâu vào cách agent tìm và tin công cụ trước khi dùng.

Sáu chiều kiểm thử cho phone agent Android thật

Một bộ kiểm thử GUI agent Android nên biến từng nguồn khó thành một chiều riêng. Chiều thứ nhất là cấu hình: phiên bản Android, OEM, kích thước màn hình, ngôn ngữ, bàn phím, quyền đã cấp và trạng thái app. Với FoneClaw, chúng tôi đặc biệt chú ý locale vì phone agent phải hiểu cả câu lệnh và giao diện trong nhiều ngôn ngữ, bao gồm bộ trải nghiệm 14 ngôn ngữ của sản phẩm.

Chiều thứ hai là độ dài tác vụ: một bước, vài bước, hay long-horizon workflow. Chiều thứ ba là phạm vi app: một app, nhiều app, hoặc phối hợp giữa app và cài đặt hệ thống. Chiều thứ tư là độ rõ của ý định: người dùng nói đầy đủ, mơ hồ, sai tên người nhận, hoặc cần hỏi lại. Chiều thứ năm là bề mặt hành động: GUI nhìn thấy, function có cấu trúc, host-side tool, hoặc phối hợp nhiều bề mặt. Chiều thứ sáu là side effect: đọc-only, thay đổi có thể đảo ngược, gửi dữ liệu ra ngoài, hoặc hành động cần phê duyệt mạnh.

Mỗi chiều nên được thay đổi độc lập. Nếu một test vừa đổi ngôn ngữ, vừa đổi app, vừa thêm thiếu quyền, vừa đổi người nhận, đội phát triển sẽ khó biết nguyên nhân fail. Bộ test tốt bắt đầu bằng baseline rõ, sau đó randomize một hoặc hai chiều có kiểm soát. Đây là cách biến benchmark AI agent 2026 thành công cụ engineering thay vì một bảng xếp hạng đẹp mắt.

Chỉ số độ tin cậy ngoài tỷ lệ hoàn thành

Tỷ lệ thành công là chỉ số bắt buộc, nhưng nó chỉ là điểm đầu. Phone agent cần thêm chỉ số độ tin cậy. Trước hết là verified pass: trạng thái sau hành động phải khớp kỳ vọng. Tiếp theo là checkpoint completion: agent có hiểu mục tiêu, mở đúng app, nhận đúng màn hình, xin đúng quyền và dừng ở phê duyệt đúng không. Partial score giúp biết tác vụ fail ở đâu.

Wrong side effect là chỉ số cần được tách riêng. Gửi sai người, đổi sai cài đặt hoặc ghi sai dữ liệu nặng hơn việc dừng sớm. Human intervention rate đo số lần người dùng phải sửa, chọn lại hoặc tiếp quản. Recovery success đo khả năng quay lại đúng mạch sau khi thiếu quyền, mất mạng, app đổi trạng thái hoặc người dùng bấm dừng. Latency và cost cũng quan trọng vì phone agent phải hữu ích trong đời sống thật, không chỉ chạy được trong phòng lab.

Trace quality là nền cho cải thiện. Mỗi run nên có initial state, action log, screenshot hoặc state observation khi phù hợp, approval record, tool result, final verification và retry policy. PhoneHarness nhấn mạnh side-effect verification và traceability; chúng tôi cũng xem trace là cách biến lỗi thành việc sửa được. Với kiến trúc audit và quyền sâu hơn, bài Danh tính tác nhân AI: quyền, phê duyệt công cụ và nhật ký kiểm toán trình bày phần nền bảo mật của chỉ số này.

Kiểm thử phê duyệt, quyền, tự kiềm chế và dừng

An toàn trong benchmark phone agent không thể chỉ đo bằng refusal rate. Một agent tốt cần làm đúng việc được phép, hỏi đúng khi thiếu thông tin, xin phê duyệt đúng lúc, tôn trọng quyền Android và dừng khi người dùng yêu cầu. Với tác vụ có tác động, bài test nên chứa cả tình huống được phép và tình huống cần từ chối hoặc hỏi lại.

KnowU-Bench đáng chú ý vì đưa vào clarification, proactive consent và restraint after rejection. Với phone agent, các tình huống này rất đời thường: người dùng nói “gửi cho Minh” khi có nhiều Minh, agent cần hỏi. Người dùng từ chối gửi bản nháp, agent cần giữ nội dung hoặc hủy theo yêu cầu thay vì tìm đường khác để gửi. Người dùng nói dừng, agent cần ưu tiên dừng hơn việc hoàn tất kế hoạch cũ.

Phê duyệt cũng cần được chấm như một hành vi UX, không chỉ là một popup. Nó phải hiển thị mục tiêu, dữ liệu, hành động, hậu quả và lựa chọn. Bài UX phê duyệt tác vụ AI agent trên điện thoại: thiết kế để quyết định đúng đi sâu vào lớp này. Với kiểm thử bảo mật, hãy thêm case thiếu quyền, quyền bị thu hồi giữa chừng, app yêu cầu xác nhận riêng và người dùng thay đổi ý định.

Cách chúng tôi đánh giá các tác vụ FoneClaw hiện tại

FoneClaw hiện cung cấp một nền rất phù hợp để thiết kế ma trận đánh giá mobile agent. Nền này có trợ lý nổi, gắn màn hình hiện tại, liên tục tác vụ, phê duyệt và dừng, phục hồi quyền, cải thiện DND, âm lượng, meeting-mode, độ tin cậy screenshot và quick actions. Người dùng có thể bắt đầu từ trang tải FoneClaw, còn phạm vi năng lực hiện có được mô tả trên trang tính năng FoneClaw với 100+ built-in tools.

Chúng tôi sẽ chia test hiện tại thành bốn nhóm. Nhóm read-only gồm đọc màn hình đang hiển thị, kiểm tra trạng thái thiết bị, kiểm tra Bluetooth hoặc xem quyền. Nhóm reversible device control gồm DND ngắn hạn, âm lượng, Bluetooth, screenshot và quick actions có thể xác minh. Nhóm external-effect gồm bản nháp tin nhắn, lịch, memo, tasks và workflow có phê duyệt. Nhóm recovery gồm mất quyền, app đổi màn hình, current-screen stale, người dùng dừng giữa chừng và tiếp quản bằng tay.

Một ma trận test tốt ghi rõ initial state, locale, app state, expected state, approval point và recovery path. Ví dụ, test DND không chỉ hỏi “agent bật được không”; nó kiểm tra chế độ ban đầu, thời lượng, phê duyệt, trạng thái sau khi bật, cách tắt lại và trace. Test tin nhắn không chỉ hỏi “agent gửi được không”; nó kiểm tra người nhận, nội dung, app mặc định, nút gửi ổn định và điểm người dùng xác nhận.

Bài viết này định nghĩa phương pháp và ma trận, không công bố điểm benchmark FoneClaw. Chúng tôi dùng phương pháp này để làm rõ sản phẩm cần tốt lên ở đâu: quan sát, lập kế hoạch, phê duyệt, thực thi, xác minh hay phục hồi. Với một kịch bản audit người dùng cụ thể hơn, bài Kiểm tra sức khỏe và quyền Android bằng AI với FoneClaw là ví dụ tốt về read-only và permission-oriented workflow.

Xây protocol benchmark phone agent lặp lại được

Một protocol benchmark lặp lại được nên bắt đầu bằng việc đóng băng môi trường: thiết bị, phiên bản Android, OEM, ngôn ngữ, bàn phím, app version, trạng thái đăng nhập, quyền đã cấp, mạng và retry policy. Sau đó định nghĩa initial state và expected state bằng ngôn ngữ kiểm thử, không chỉ bằng mô tả tự nhiên.

Quy trình bảy bước của chúng tôi là: chọn tác vụ, ghi initial state, randomize một chiều có kiểm soát, chạy agent, ghi mọi hành động và phê duyệt, xác minh side effect, rồi phân loại kết quả thành pass, partial, fail, wrong side effect hoặc recovered. Mỗi run cần có denominator cố định: số lần thử, số retry được phép, khi nào tính là user intervention và khi nào dừng do thiếu quyền.

Scorecard tối thiểu nên gồm task success, verified side effect, wrong side effect, recovery success, approval correctness, human intervention, latency, cost và trace completeness. Để bắt đầu ít rủi ro, hãy dùng một tác vụ có thể đảo ngược như kiểm tra Bluetooth, bật DND ngắn hạn hoặc tạo bản nháp. Sau khi protocol ổn, hãy tăng dần sang multi-app, multi-locale và workflow có phê duyệt mạnh.