Phone agent tự cải thiện: phiên bản kỹ năng, kiểm thử và hoàn tác

Phone agent tự cải thiện thực sự thay đổi điều gì?

Một phone agent tự cải thiện không nhất thiết phải tự huấn luyện lại mô hình. Trong kiến trúc thực tế, phần được cải thiện thường là cách agent lập kế hoạch, chọn công cụ, kiểm tra kết quả, phục hồi sau lỗi và gọi lại những kỹ năng điện thoại đã được đóng gói.

Cần tách bốn thành phần. Trọng số mô hình quyết định năng lực nền của model đã chọn. Khung vận hành agent, thường được gọi là harness, gồm prompt, công cụ, cơ chế chạy, quy tắc xác minh, logic điều phối và thủ tục phục hồi. Kỹ năng tái sử dụng mô tả một quy trình cụ thể với đầu vào, điều kiện và kết quả mong đợi. Cuối cùng, thành phần thực hiện Android chuyển kế hoạch thành các thao tác điện thoại nằm trong phạm vi hỗ trợ.

Ví dụ, một kỹ năng tạo lịch thường chọn nhầm cả ngày khi người dùng nói “chiều thứ Sáu”. Cải tiến phù hợp có thể là bổ sung quy tắc xác minh ngày, giờ và múi giờ trước khi lưu. Không cần thay đổi trọng số model; thay đổi nằm ở harness và kỹ năng, nơi lỗi có thể được tái hiện, kiểm thử và quản lý phiên bản.

Khái niệm này cũng khác với việc dạy một quy trình mới từ đầu. Bài Dạy phone agent bằng thao tác mẫu: ghi màn hình, kỹ năng tái sử dụng và an toàn Android tập trung vào quá trình tạo kỹ năng. Trang này giải quyết giai đoạn sau: kỹ năng đã được dùng, có dấu vết thực tế và cần cải thiện mà không làm mất hành vi ổn định.

Như vậy, “tự cải thiện” nên được hiểu là khả năng đề xuất và đưa vào sử dụng những thay đổi có bằng chứng, có kiểm thử và có đường quay lại, thay vì tự sửa mọi thành phần không giới hạn.

Self-Harness cho thấy vòng lặp cải thiện có giới hạn ra sao?

Nghiên cứu Self-Harness đưa ra một vòng lặp ba giai đoạn rõ ràng: khai thác điểm yếu từ dấu vết thực thi, tạo đề xuất thay đổi có giới hạn cho harness và xác minh đề xuất trước khi chấp nhận. Cấu trúc này hữu ích vì nó biến cải tiến thành một quy trình kiểm chứng được thay vì phản ứng tùy hứng sau mỗi lỗi.

Giai đoạn đầu không chỉ đếm thất bại. Hệ thống phải đọc dấu vết để xác định lỗi đến từ đâu: kế hoạch thiếu bước, chọn sai công cụ, không kiểm tra kết quả hay phục hồi không đúng. Một kết quả thất bại chưa đủ chứng minh nguyên nhân; cần đối chiếu trạng thái đầu vào, hành động đã thực hiện và phản hồi của môi trường.

Tiếp theo là đề xuất có giới hạn. Thay vì viết lại toàn bộ agent, hệ thống có thể thêm một quy tắc xác minh, sửa điều kiện chọn công cụ hoặc bổ sung nhánh phục hồi. Thay đổi càng nhỏ thì càng dễ giải thích, kiểm thử và hoàn tác. Đây là nguyên tắc quan trọng với Android, nơi một điều chỉnh tưởng như đơn giản có thể ảnh hưởng nhiều ứng dụng, ngôn ngữ hoặc trạng thái quyền.

Giai đoạn cuối kiểm tra đề xuất trên trường hợp liên quan và tập dữ liệu giữ lại. Các tác giả Self-Harness báo cáo mức tăng tỷ lệ vượt qua trên Terminal-Bench-2.0 đối với ba mô hình nền cố định. Kết quả đến từ việc sửa harness thay vì thay trọng số model. Đây là kết quả do nhóm nghiên cứu công bố trên bài đánh giá cụ thể, không phải bảo đảm rằng cùng mức tăng sẽ xuất hiện trong mọi phone agent.

Khái niệm harness trong nghiên cứu có phạm vi rộng: prompt, công cụ, cơ chế chạy, quy tắc xác minh, logic điều phối và thủ tục phục hồi lỗi. Với phone agent, cách định nghĩa này phù hợp hơn việc chỉ nhìn prompt, bởi chất lượng thực tế phụ thuộc vào toàn bộ đường đi từ kế hoạch đến trạng thái Android.

Phân tích của Salesforce về hướng agent tự cải thiện cung cấp bối cảnh rộng hơn cho lĩnh vực. Tuy nhiên, tín hiệu quan trọng để triển khai sản phẩm vẫn là vòng lặp có bằng chứng, thay đổi tối thiểu và xác minh trước khi chấp nhận.

FoneClaw tự cải thiện kế hoạch và kỹ năng như thế nào?

FoneClaw là một phone agent tự cải thiện. FoneClaw có thể dùng kết quả thực thi và dấu vết lỗi để cải thiện cách lập kế hoạch, hành vi của khung vận hành và những kỹ năng điện thoại tái sử dụng, thông qua một vòng đời có kiểm thử, phê duyệt, phiên bản, phát hành theo giai đoạn và hoàn tác.

Trong kiến trúc FoneClaw, mô hình do người dùng cấu hình cung cấp khả năng hiểu ngôn ngữ và lập kế hoạch bên trong quy trình agent. FoneClaw sở hữu phần thực hiện các thao tác Android được hỗ trợ, hiển thị kết quả, áp dụng quyền phù hợp, giữ bước xác nhận và cung cấp phương án xử lý tiếp. Tự cải thiện tập trung vào quy trình này, không sửa trọng số của model đã chọn.

Giả sử một tác vụ nhắn tin thất bại vì có hai liên hệ cùng tên. Dấu vết cho thấy model đã chọn kết quả đầu tiên mà không hỏi lại. Một cải tiến có giới hạn là thêm điều kiện: khi nhiều liên hệ phù hợp, phải hiển thị lựa chọn và chờ người dùng xác nhận. Phiên bản mới cần được thử với một liên hệ duy nhất, nhiều liên hệ trùng tên, danh bạ trống và tên ở các ngôn ngữ khác nhau.

Một ví dụ khác là ứng dụng thay đổi bố cục. Nếu kỹ năng không còn tìm thấy nút cần thiết, FoneClaw có thể dùng bằng chứng lỗi để đề xuất cách nhận diện trạng thái tốt hơn hoặc chuyển sang phương án phục hồi. Thay đổi không tự mở rộng sang ứng dụng khác và không thêm quyền mới chỉ để làm bài thử vượt qua.

Tính tự cải thiện cũng không loại bỏ người dùng khỏi các điểm có hệ quả. Nếu kỹ năng được sửa để soạn tin nhắn tốt hơn, bước gửi vẫn cần xác nhận. Nếu luồng lịch có thêm khả năng xử lý lặp lại, ngày, giờ và quy tắc lặp vẫn phải được hiển thị trước khi lưu.

Khác biệt giữa cải thiện harness và huấn luyện mô hình được phân tích sâu hơn trong PhoneBuddy-4B và huấn luyện Phone Agent: vì sao Mock-App RL quan trọng với Android Agent. Với FoneClaw, mục tiêu là cải thiện hành vi agent có thể quan sát và hoàn tác trong khi giữ nguyên ranh giới Android.

Vòng đời từ dấu vết lỗi đến phiên bản được phát hành

Một thay đổi nên đi qua những bước nào trước khi trở thành hành vi mặc định? Vòng đời FoneClaw bắt đầu từ bằng chứng thực thi và kết thúc bằng khả năng quay lại phiên bản ổn định nếu dữ liệu sau phát hành cho thấy vấn đề.

1. Thu thập bằng chứng: lưu đầu vào, trạng thái ứng dụng, các bước đã chạy, quyền được dùng, điểm xác nhận, kết quả và lỗi.
2. Xác định nguyên nhân: phân biệt lỗi kế hoạch, lỗi công cụ, trạng thái ứng dụng thay đổi, thiếu quyền hoặc dữ liệu mơ hồ.
3. Đề xuất thay đổi tối thiểu: sửa điều kiện, quy tắc xác minh, tham số kỹ năng hoặc nhánh phục hồi nhỏ nhất có thể.
4. Chạy kiểm thử hồi quy: thử lại trường hợp lỗi, trường hợp đã thành công và các biến thể về ngôn ngữ, bố cục, dữ liệu cùng trạng thái tài khoản.
5. So sánh quyền: kiểm tra phiên bản mới có yêu cầu thêm ứng dụng, dữ liệu hoặc quyền Android hay không.
6. Phê duyệt: người hoặc quy trình có thẩm quyền xem bằng chứng, phạm vi thay đổi và kết quả kiểm thử.
7. Gắn phiên bản: lưu nội dung thay đổi, tập kiểm thử, quyền, ngày phát hành và phiên bản trước có thể khôi phục.
8. Phát hành theo giai đoạn: đưa thay đổi tới phạm vi nhỏ trước, theo dõi tỷ lệ thành công, dừng, xác nhận và lỗi mới.
9. Giám sát: so sánh kết quả thực tế với đường cơ sở, không chỉ với trường hợp ban đầu.
10. Hoàn tác: chuyển về phiên bản ổn định khi phát hiện hồi quy hoặc thay đổi quyền ngoài kế hoạch.

So sánh quyền là bước riêng vì thay đổi hành vi có thể vô tình kéo theo quyền rộng hơn. Một cách sửa cần truy cập thêm ứng dụng hoặc dữ liệu không mặc nhiên là lựa chọn tốt. Đội ngũ phải xem quyền mới có thật sự cần cho mục tiêu hay chỉ đang che giấu một thiết kế chưa tối ưu.

Quản lý phiên bản giúp trả lời câu hỏi “tại sao agent làm khác hôm qua?”. Mỗi kỹ năng cần mã phiên bản, nội dung thay đổi và tập kiểm thử gắn kèm. Nhật ký phiên chạy phải cho biết phiên bản nào đã được dùng để kết quả có thể tái hiện.

Chi tiết về nguồn kỹ năng và phạm vi quyền được trình bày trong Bảo mật kỹ năng AI agent trên điện thoại. Còn sự khác nhau giữa môi trường cô lập và quyền thiết bị nằm tại Sandbox AI agent và quyền trên điện thoại: vì sao vẫn cần ranh giới.

Những cải tiến nào có thể làm phone agent kém ổn định hơn?

Một hệ thống tối ưu hóa có thể sửa nhầm lỗi không tồn tại. Nghiên cứu Phantom Guardrails tháng 7 năm 2026 chỉ ra rủi ro “lỗi ảo”: bộ tối ưu có thể tưởng tượng ra một thất bại rồi thêm cơ chế bảo vệ không cần thiết. Nếu tiêu chí chấp nhận chỉ là lỗi tưởng tượng không còn xuất hiện, thay đổi vẫn có thể được thông qua mà không tạo giá trị thực.

Trên phone agent, một guardrail dư thừa có thể biến thành câu hỏi xác nhận liên tục, chặn thao tác hợp lệ hoặc làm quy trình dài hơn. Vì vậy, mọi đề xuất phải liên kết với dấu vết có thể tái hiện. Nếu lỗi không tái hiện trong môi trường kiểm soát và không có bằng chứng đầu vào, hệ thống nên giữ nó ở trạng thái giả thuyết.

Sửa quá khớp là rủi ro tiếp theo. Một kỹ năng có thể được điều chỉnh để chạy đúng trên một phiên bản ứng dụng, một kích thước màn hình hoặc một tài khoản cụ thể, rồi thất bại ở nơi khác. Kiểm thử cần thay đổi bố cục, trạng thái đăng nhập, dữ liệu trống, nhiều kết quả và thời gian tải.

Biến thể ngôn ngữ cũng dễ gây hồi quy. Quy tắc nhận diện nút theo một nhãn tiếng Việt có thể không hoạt động khi ứng dụng dùng tiếng Anh, hoặc khi nhà phát triển đổi cách dịch. Kỹ năng nên dựa vào vai trò và trạng thái của thành phần khi có thể, đồng thời có trường hợp thử cho những ngôn ngữ được hỗ trợ.

Permission drift xảy ra khi phiên bản mới đòi thêm quyền mà mục tiêu ban đầu không cần. Một thay đổi có thể cải thiện tỷ lệ hoàn thành bằng cách mở rộng truy cập, nhưng làm yếu ranh giới của sản phẩm. So sánh quyền phải coi quyền mới là một thay đổi chức năng cần phê duyệt riêng.

Một benchmark giữ nguyên cũng chưa đủ. Phone agent hoạt động trong môi trường thay đổi: ứng dụng cập nhật, hệ điều hành đổi hộp thoại, dịch vụ điều chỉnh tài khoản và hành vi người dùng đa dạng hơn tập thử. Tập hồi quy cần được bổ sung từ lỗi thực tế, đồng thời giữ các trường hợp cũ để tránh quên năng lực đã có.

Nhật ký phiên bản, danh tính thực hiện và bằng chứng phê duyệt tạo nền cho việc truy nguyên. Khung liền kề được trình bày trong Danh tính, quyền và nhật ký kiểm toán AI agent: lớp an toàn cho tác nhân trên điện thoại.

Danh sách kiểm tra trước khi đưa thay đổi vào Android thực tế

Làm sao biết một cải tiến đã sẵn sàng? Thay vì chỉ hỏi “tỷ lệ thành công có tăng không?”, hãy kiểm tra cả nguồn bằng chứng, phạm vi thao tác, quyền, trải nghiệm xác nhận và khả năng phục hồi.

Bài kiểm tra cuối nên dùng một thiết bị hoặc môi trường Android gần với thực tế. Chạy một tác vụ thành công, một tác vụ có dữ liệu mơ hồ, một trường hợp thiếu quyền và một tình huống ứng dụng đổi trạng thái giữa chừng. Quan sát không chỉ kết quả cuối mà cả số lần hỏi lại, điểm dừng và khả năng tiếp tục.

Một cải tiến tốt làm agent rõ ràng hơn, không chỉ chủ động hơn. Người dùng phải thấy điều gì đã thay đổi, quyền nào được dùng và kết quả ở đâu. Nếu thay đổi làm tăng tỷ lệ hoàn thành nhưng giảm khả năng kiểm tra hoặc mở rộng quyền không cần thiết, nó chưa sẵn sàng cho phát hành rộng.

FoneClaw kết hợp khả năng tự cải thiện với vòng đời quản trị này: mô hình được cấu hình tiếp tục cung cấp hiểu biết và kế hoạch, FoneClaw cải thiện harness cùng kỹ năng từ bằng chứng thực thi, và các thao tác Android vẫn nằm trong phạm vi hỗ trợ với quyền, xác nhận, phiên bản cùng đường hoàn tác rõ ràng.