AI agent Android hiểu màn hình: chọn cây UI hay ảnh chụp
Hướng dẫn chọn cây trợ năng, ảnh chụp màn hình hoặc kết hợp cả hai để AI agent Android hiểu màn hình, giảm lỗi, giữ quyền riêng tư và xác minh kết quả.
- Agent Android nên ưu tiên cây UI khi cần nhãn, vai trò, trạng thái và đích thao tác rõ; dùng ảnh chụp khi câu hỏi nằm ở pixel, bố cục, hình ảnh, bản đồ, biểu đồ hoặc nội dung vẽ tùy biến.
- Cây trợ năng và ảnh chụp màn hình đều là bằng chứng có giới hạn: một bên có thể thiếu node hoặc sai ngữ nghĩa, bên kia có thể giàu hình ảnh nhưng thiếu ý nghĩa hành động.
- Quy trình đáng tin là inspect, phát hiện khoảng trống, capture đúng phần cần thiết, reconcile node với pixel, đề xuất hành động, xin xác nhận và đọc lại trạng thái sau khi chạy.
- Trong FoneClaw, chúng tôi dùng screen-information và screenshot tools như hai đường bổ sung cho tác vụ màn hình hiện tại, với tiến trình, quyền, phê duyệt và xác minh kết quả hiển thị cho người dùng.
Nên chọn cây UI, ảnh chụp hay kết hợp cả hai?
Câu trả lời thực dụng là: AI agent Android hiểu màn hình tốt nhất khi chọn đúng nguồn bằng chứng cho đúng việc. Nếu tác vụ cần tìm một nút có nhãn rõ, trạng thái bật tắt, ô nhập liệu, checkbox, tab hoặc mục danh sách có cấu trúc, hãy bắt đầu bằng cây UI hoặc accessibility tree. Nếu tác vụ cần đọc nội dung vẽ bằng canvas, xem vị trí tương đối, nhận diện màu, biểu đồ, bản đồ, ảnh sản phẩm, layout bị che khuất hoặc trạng thái chỉ hiện bằng hình ảnh, ảnh chụp màn hình mới trả lời được phần còn thiếu.
Đường thứ ba là hybrid: đọc cấu trúc ngữ nghĩa trước, chụp màn hình khi có khoảng trống trực quan, rồi đối chiếu hai nguồn trước khi đề xuất hành động. Đây là đường chúng tôi ưu tiên khi xây FoneClaw cho các tác vụ màn hình hiện tại. Nhiều dữ liệu hơn không tự động tốt hơn. Ảnh chụp làm tăng chi phí xử lý và có thể chứa thông tin riêng tư không cần thiết. Cây UI gọn hơn và thường gần với thao tác hơn, nhưng chất lượng phụ thuộc cách app công bố node và trạng thái.
Vì vậy, quyết định đúng không phải “cây UI hay ảnh chụp luôn tốt hơn”, mà là: bằng chứng nào trả lời câu hỏi hiện tại với ít quyền, ít dữ liệu và khả năng xác minh tốt nhất? Nếu bạn muốn đặt quyết định này trong toàn bộ vòng từ ý định đến hành động, bài AI agent điều khiển điện thoại Android: từ ý định đến hành động trình bày đầy đủ hơn về quyền, xác nhận và kiểm tra trạng thái cuối.
Cây trợ năng Android cho biết gì và bỏ sót gì?
Trong Android, accessibility service là công nghệ hỗ trợ người dùng có nhu cầu trợ năng, và khi được người dùng bật cùng cấu hình phù hợp, service có thể nhận sự kiện, xem nội dung cửa sổ và thực hiện một số tương tác thay mặt người dùng. Tài liệu Android về accessibility services mô tả đây là năng lực chuyên biệt, cần cấu hình rõ như khả năng lấy nội dung cửa sổ và gesture. Với phone agent, điều này nên được đọc như một bề mặt có quyền và mục đích rõ, không phải một đường tắt tự động hóa chung cho mọi app.
Đơn vị quan trọng trong cây này là AccessibilityNodeInfo. Tài liệu Android về AccessibilityNodeInfo mô tả node trong nội dung cửa sổ accessibility, với thông tin như text, content description, class hoặc role gần đúng, trạng thái checked, selected, enabled, focused, hành động khả dụng, quan hệ cha con và bounds trên màn hình. Những trường này giúp agent chọn mục tiêu theo nghĩa: “nút Gửi đang bật”, “checkbox này đang được chọn”, “ô tìm kiếm đang focus”, hoặc “mục danh sách này có mô tả đúng người nhận”.
Điểm mạnh của cây UI là compact và action-aware. Nó thường rẻ hơn ảnh chụp về kích thước dữ liệu, ít phụ thuộc OCR hơn, và có thể gắn trực tiếp với node có thể click hoặc nhập. Cách kiểm thử chính thức của Android cũng đánh giá cao selector ổn định, text, content description, resource identifier và quan hệ hierarchy; hướng dẫn UI Automator cho thấy giá trị của việc chờ trạng thái rõ thay vì chỉ bấm theo tọa độ.
Nhưng cây trợ năng có failure modes riêng. Thứ nhất, app có thể không công bố mọi phần được vẽ, nhất là canvas, game, bản đồ hoặc thành phần tùy biến. Thứ hai, node có thể tồn tại nhưng text hoặc content description nghèo nàn, trùng lặp hoặc gây hiểu nhầm. Thứ ba, hierarchy có thể stale khi màn hình thay đổi giữa lúc đọc và lúc thao tác. Thứ tư, bounds có thể đúng về hình học nhưng sai về ý nghĩa nếu overlay, animation hoặc dialog che lên trên. Thứ năm, một node có thể clickable nhưng hành động hậu quả cao vẫn cần người dùng xem lại và xác nhận.
Khi nào cần bằng chứng pixel?
Ảnh chụp màn hình là bằng chứng pixel: nó cho agent thấy thứ đang hiển thị tại thời điểm capture. Bằng chứng này hữu ích khi câu hỏi nằm ở trực quan chứ không nằm trong node. Ví dụ: biểu đồ đang tăng hay giảm, ảnh nào đang được chọn, bản đồ hiển thị lối nào, nút bị disabled bằng màu xám, cảnh báo nổi che phần dưới, form có lỗi đỏ dưới trường nào, sản phẩm nào ở bên trái, hoặc canvas đang vẽ nội dung không có node ngữ nghĩa đủ tốt.
Đây là nơi cây UI và thị giác máy tính bổ sung cho nhau. Cây UI có thể nói “có một ViewGroup ở vùng này”, nhưng ảnh chụp nói vùng đó đang hiển thị biểu đồ, icon cảnh báo hoặc hình ảnh cần đọc. Với agent Android đa phương thức, ảnh chụp giúp mô hình liên kết chữ, biểu tượng, vị trí, kích thước, màu sắc và quan hệ không gian. Nó cũng hữu ích khi người dùng nói “nút màu xanh ở góc dưới”, “ảnh thứ hai”, “dòng bị gạch đỏ” hoặc “mục ở cạnh avatar”.
Ảnh chụp cũng có failure modes. Thứ nhất, OCR có thể đọc chữ đúng nhưng vẫn không biết control nào thực sự nhận tap. Thứ hai, pixel không tiết lộ hidden state, role, accessibility action hoặc quyền đằng sau một nút. Thứ ba, tọa độ phụ thuộc orientation, scale, insets, display cutout, keyboard, overlay và animation tại thời điểm capture. Thứ tư, ảnh chụp có thể chứa dữ liệu riêng tư rộng hơn câu hỏi, như tin nhắn, email, ảnh cá nhân hoặc thông tin tài khoản. Thứ năm, trạng thái có thể đổi ngay sau khi capture, khiến kết luận trực quan cũ đi rất nhanh.
Vì vậy, ảnh chụp nên được dùng có chủ đích. Nếu cây UI đã đủ để chọn đúng node và trạng thái, chụp thêm toàn màn hình chỉ làm tăng dữ liệu nhạy cảm và chi phí. Nếu câu hỏi cần pixel, hãy capture phần tối thiểu có ích, giải thích lý do, rồi dùng ảnh như bằng chứng bổ sung thay vì thay thế hoàn toàn xác minh trạng thái sau hành động.
So sánh chất lượng bằng chứng của cây UI và ảnh chụp
Ma trận dưới đây giúp quyết định nhanh giữa cây trợ năng và ảnh chụp màn hình. Không có hàng nào là tuyệt đối; chất lượng phụ thuộc app, Android version, quyền đã bật, màn hình hiện tại và yêu cầu của người dùng.
| Tiêu chí | Cây UI hoặc accessibility tree | Ảnh chụp màn hình | Giá trị xác minh |
|---|---|---|---|
| Text và nhãn | Tốt khi app cung cấp text hoặc content description rõ. | Tốt khi OCR đọc được chữ đang hiển thị. | Dùng cả hai khi nhãn trong node khác chữ đang thấy. |
| Role và hành động | Mạnh hơn vì có enabled, clickable, checked, selected, focus và action. | Yếu hơn vì pixel không nói chắc role hoặc action. | Cây UI thường là nguồn chính để chọn control. |
| Hình ảnh, biểu đồ, bản đồ | Thường thiếu hoặc chỉ có container. | Mạnh hơn vì thấy trực quan thực tế. | Ảnh chụp giúp giải thích phần node không mô tả. |
| Bố cục và quan hệ không gian | Có bounds và hierarchy, nhưng có thể không phản ánh overlay đúng lúc. | Thấy quan hệ hiển thị và phần bị che. | Hybrid tốt khi tap cần đúng vị trí nhìn thấy. |
| Chi phí và tốc độ | Thường gọn hơn, dễ lọc và ít token hơn. | Lớn hơn, cần xử lý multimodal hoặc OCR. | Chỉ dùng ảnh khi nó trả lời câu hỏi thật. |
| Quyền riêng tư | Ít pixel hơn nhưng vẫn có text nhạy cảm nếu node chứa nội dung riêng tư. | Có thể chứa toàn bộ màn hình và dữ liệu ngoài mục tiêu. | Chọn phạm vi tối thiểu và hỏi trước bước nhạy cảm. |
| Failure mode chính | Thiếu node, node stale, nhãn nghèo, hierarchy sai, bounds bị overlay. | OCR sai, không biết role, tọa độ lệch, dữ liệu nhạy cảm, ảnh cũ. | Dừng hoặc hỏi lại khi hai nguồn xung đột. |
Một nguyên tắc chúng tôi dùng trong FoneClaw là xem bằng chứng theo câu hỏi. Nếu câu hỏi là “đang ở màn hình nào, nút nào có thể bấm, ô nào đang focus”, cây UI thường là nguồn đầu tiên. Nếu câu hỏi là “phần nào đang bị che, màu nào báo lỗi, biểu đồ nào được chọn”, ảnh chụp có giá trị cao hơn. Khi hành động có hậu quả như gửi tin, thay đổi dữ liệu hoặc xác nhận biểu mẫu, bằng chứng chỉ là phần chuẩn bị; người dùng vẫn cần thấy đề xuất và quyết định.
Quy trình kết hợp ngữ nghĩa và trực quan
Quy trình hybrid tốt không bắt đầu bằng việc chụp mọi thứ. Nó bắt đầu bằng inspect. Agent đọc trạng thái có cấu trúc của màn hình hiện tại: app hoặc window, node quan trọng, text, content description, trạng thái enabled, checked, focus, hierarchy và bounds. Nếu yêu cầu của người dùng có thể được trả lời bằng trạng thái ngữ nghĩa ổn định, agent có thể đi thẳng tới đề xuất hành động.
Bước thứ hai là phát hiện khoảng trống. Cần ảnh chụp khi có nội dung trực quan không hiện trong node, khi người dùng mô tả vị trí bằng màu hoặc hình, khi node trùng nhãn, khi overlay có thể che target, khi màn hình có canvas, chart, map, game, ảnh sản phẩm hoặc khi kết quả của lần inspect không đủ tự tin. Đây là lúc agent nên capture tối thiểu phần cần thiết thay vì lấy thêm dữ liệu cho đẹp.
Bước thứ ba là reconcile: đối chiếu node và pixel. Nếu cây UI nói có nút “Tiếp tục” ở dưới cùng nhưng ảnh chụp cho thấy bàn phím che mất vùng đó, hành động đúng là đóng bàn phím hoặc hỏi người dùng, không tap mù. Nếu ảnh chụp thấy chữ “Gửi” nhưng cây UI không có node clickable tương ứng, agent nên coi đó là low-confidence target. Nếu hai nguồn xung đột về vị trí, trạng thái hoặc nội dung, quy trình nên dừng, yêu cầu clarification hoặc chuyển sang manual handoff.
Inspect: đọc trạng thái ngữ nghĩa mới nhất của màn hình.
Detect gaps: xác định câu hỏi nào vẫn chưa được trả lời.
Capture minimally: dùng ảnh chụp khi pixel là bằng chứng cần thiết.
Reconcile: khớp text, bounds, visible layout và trạng thái hành động.
Propose: nêu app đích, node hoặc vùng sẽ dùng, nội dung sắp nhập và kết quả mong đợi.
Approve: xin xác nhận cho hành động có hậu quả, nhất là gửi, lưu, xóa hoặc đổi cài đặt.
Act: thực hiện bằng công cụ được hỗ trợ, theo trạng thái hiện tại.
Verify: đọc lại màn hình hoặc trạng thái sau hành động thay vì suy ra tap đã thành công.
Màn hình Android có thể đổi giữa inspect và action. Thông báo nổi, keyboard, animation, rotation, dialog quyền, refresh dữ liệu hoặc app chuyển trạng thái đều có thể làm target cũ không còn đúng. Vì vậy, bước verify phải dùng fresh state. Với form-filling, logic này càng quan trọng vì một ô sai có thể tạo dữ liệu sai; bài Điền biểu mẫu Gemini trên Android: dùng AI nhưng vẫn kiểm soát đi sâu vào quyết định xem trước, sửa và xác nhận trong trường hợp biểu mẫu.
Cách FoneClaw áp dụng cho tác vụ màn hình hiện tại
FoneClaw là Android phone-agent runtime. Người dùng có thể bắt đầu bằng mô hình mặc định miễn phí; mô hình suy luận và lập kế hoạch, còn FoneClaw cung cấp công cụ Android được quản trị. Với tác vụ current-screen, chúng tôi thiết kế đường đi theo câu hỏi: người dùng muốn agent hiểu văn bản, tìm control, giải thích vùng nhìn thấy, chuẩn bị thao tác hay chỉ mở đúng app?
Khi yêu cầu có thể dựa vào cấu trúc màn hình, FoneClaw ưu tiên thông tin có cấu trúc qua các đường như get_screen_info và cross_app_read_screen. Những công cụ này phù hợp để đọc node, text, mô tả, trạng thái và ngữ cảnh app trong phạm vi được hỗ trợ. Khi câu hỏi cần bằng chứng trực quan, FoneClaw có thể dùng screenshot_take hoặc screenshot_open để đưa ảnh chụp do người dùng chọn hoặc trạng thái màn hình vào đường multimodal. Các cải tiến hiện tại của chúng tôi giúp ảnh đính kèm và ảnh capture giữ kích thước, tham chiếu và đường reanalysis rõ hơn cho tác vụ tiếp theo.
Điểm quan trọng là công cụ không đồng nghĩa quyền mở rộng. FoneClaw không hứa điều khiển mọi app Android hoặc hiểu mọi màn hình như nhau. Chúng tôi giữ tiến trình cross-app hiển thị, dùng quyền theo nhu cầu, đưa hành động nhạy cảm qua phê duyệt và kiểm tra trạng thái sau khi chạy. Nếu bằng chứng thấp hoặc target mơ hồ, FoneClaw nên hỏi lại, mở màn hình cho người dùng tự xử lý hoặc giữ phần đã chuẩn bị mà chưa thực hiện bước cuối.
Trên trang tính năng FoneClaw, chúng tôi mô tả phạm vi công khai bằng 100+ built-in tools. Với screen grounding, con số không quan trọng bằng cách chọn đúng nguồn bằng chứng, giữ dữ liệu tối thiểu và xác minh trạng thái cuối. Nếu bạn dùng trợ lý nổi và muốn gọi agent ngay từ màn hình đang xem, bài Trợ lý AI nổi Android với ngữ cảnh màn hình hiện tại giải thích trải nghiệm gọi current-screen sâu hơn. Khi sẵn sàng thử trên thiết bị thật, hãy bắt đầu từ trang tải FoneClaw cho Android.
Kiểm thử hiểu màn hình bằng tác vụ có thể đảo ngược
Hãy kiểm thử bằng việc nhỏ trên đúng thiết bị, Android version và app bạn định dùng. Một ví dụ tốt là mở một màn hình cài đặt hoặc ghi chú thử, yêu cầu agent nhận diện một nút, giải thích trạng thái và chuẩn bị thao tác có thể hủy. Tránh dùng gửi tiền, xóa dữ liệu, gửi tin thật hoặc đổi cài đặt quan trọng làm bài thử đầu tiên.
- Chọn màn hình vô hại: dùng app thử, ghi chú nháp hoặc form mẫu.
- Ghi mục tiêu trước: target nào đúng, trạng thái ban đầu là gì, kết quả mong đợi là gì.
- Thử cây UI trước: xem agent có nhận diện đúng text, role, trạng thái và bounds không.
- Thêm ảnh chụp có lý do: chỉ capture khi câu hỏi còn lại là trực quan.
- Đổi trạng thái: xoay màn hình, mở keyboard hoặc bật dialog để xem agent có đọc lại không.
- Ngắt một lần: hủy giữa chừng để xem hệ thống báo phần đã làm và phần chưa làm ra sao.
- Xác minh hoặc hoàn tác: mở lại màn hình đích, kiểm tra kết quả và xóa thay đổi thử.
Một màn hình chạy tốt không chứng minh mọi app đều tương thích. Nó chỉ cho thấy đường evidence-selection hoạt động trong tình huống đó. Nếu bạn cần đánh giá formal hơn về độ tin cậy mobile agent, bài Benchmark phone agent Android: cách đánh giá mobile agent đáng tin cậy năm 2026 cung cấp khung benchmark riêng. Và khi cấp quyền sâu hơn cho agent, hãy đọc Sandbox AI agent và quyền trên điện thoại: vì sao vẫn cần ranh giới để tách quyền mô hình, quyền app và quyền hệ điều hành.