Gỡ lỗi và khôi phục tác nhân điện thoại Android: checklist, nguyên nhân gốc và cách chạy lại an toàn
Runbook thực tế để dừng, chẩn đoán, khôi phục và chạy lại tác vụ AI agent Android bị lỗi, dựa trên vòng Phát hiện, Quy trách nhiệm, Khôi phục và Chạy lại.
- Khi tác vụ AI agent thất bại, bước đầu tiên là dừng lặp lại, ghi nhận màn hình hiện tại, kiểm tra tác động đã xảy ra và phân biệt tác vụ đọc, tác vụ có thể đảo ngược và tác vụ gây hiệu ứng bên ngoài.
- Lỗi hiện ra thường chỉ là điểm vỡ cuối cùng; nguyên nhân gốc có thể nằm ở ý định ban đầu, ngữ cảnh màn hình, định tuyến năng lực, quyền Android, công cụ, ứng dụng đích hoặc dịch vụ bên ngoài.
- Vòng Phát hiện, Quy trách nhiệm, Khôi phục và Chạy lại của AgentDebugX là khung hữu ích để truy ngược bước gây lỗi, nhưng cần được điều chỉnh cho quyền, phê duyệt và hiệu ứng thật trên điện thoại.
- Trong FoneClaw, trạng thái tác vụ, ngữ cảnh màn hình do người dùng đính kèm, phê duyệt hiển thị, dừng, thử lại và phục hồi quyền giúp người dùng khắc phục trợ lý AI Android theo từng bước có thể kiểm tra.
Dừng tác vụ tác nhân điện thoại bị lỗi trong năm phút đầu
Khi một tác vụ AI agent trên Android thất bại, phản xạ đúng không phải là bấm chạy lại ngay. Một lệnh tưởng như đơn giản có thể đã gửi tin nhắn, tạo lịch, đổi cài đặt, bật chế độ im lặng hoặc gọi một dịch vụ bên ngoài trước khi lỗi hiện ra. Vì vậy, năm phút đầu nên dành cho dừng, quan sát và khóa trạng thái hiện tại.
- Dừng tác vụ đang chạy nếu giao diện còn cho phép dừng.
- Chụp hoặc ghi lại màn hình hiện tại, kết quả cuối cùng và thông báo lỗi.
- Phân loại tác vụ: chỉ đọc, có thể đảo ngược, hay đã tạo hiệu ứng bên ngoài.
- Kiểm tra xem hành động cuối đã thật sự xảy ra chưa: tin nhắn đã gửi, lịch đã tạo, cài đặt đã đổi, tệp đã bị xóa hoặc cuộc gọi đã bắt đầu.
- Chỉ chạy lại sau khi biết bước nào cần lặp và bước nào đã hoàn tất.
Bài báo AgentDebugX về gỡ lỗi tác nhân AI nhấn mạnh một điểm rất đúng với điện thoại: lỗi người dùng nhìn thấy có thể không phải nguyên nhân gốc. Một màn hình báo thiếu quyền có thể bắt đầu từ việc agent chọn sai công cụ; một lỗi gửi tin nhắn có thể đến từ tên liên hệ mơ hồ; một tác vụ bị kẹt có thể do ứng dụng đích không còn ở đúng màn hình. Với tác vụ có bước phê duyệt, bài thiết kế phê duyệt AI agent trên điện thoại giúp đọc rõ lúc nào cần dừng để xem lại trước khi tiếp tục.
Lưu gói bằng chứng tối thiểu trước khi sửa
Một gói bằng chứng tốt đủ để tái dựng đường đi của tác vụ, nhưng không gom toàn bộ dữ liệu riêng tư. Khi xây FoneClaw, chúng tôi học được rằng câu hỏi quan trọng không chỉ là "lỗi gì", mà là "tác vụ đã hiểu mục tiêu ra sao, đã chọn công cụ nào, quyền nào được dùng, màn hình đang ở đâu và kết quả nào đã xuất hiện". Nếu thiếu chuỗi này, việc khắc phục trợ lý AI Android dễ biến thành đoán mò.
Gói tối thiểu nên có bốn phần. Thứ nhất là ý định gốc: bạn muốn agent làm gì và kết quả đúng là gì. Thứ hai là dòng thời gian: bước nào đã chạy, công cụ nào được gọi, bước nào yêu cầu phê duyệt, bước nào báo lỗi. Thứ ba là trạng thái điện thoại: ứng dụng đang mở, mạng, pin, quyền, tài khoản, màn hình khóa và thông báo liên quan. Thứ tư là kết quả sau lỗi: dữ liệu đã tạo, cài đặt đã đổi, lời nhắc đã tồn tại, hoặc hành động chưa xảy ra.
Trước khi gửi cho hỗ trợ hoặc nhóm phát triển, hãy che số điện thoại, địa chỉ, mã xác minh, nội dung tin nhắn riêng, mã thông báo, ảnh nhạy cảm và tên liên hệ nếu chúng không cần thiết để tái hiện lỗi. Gói đã lược bỏ dữ liệu riêng vẫn có giá trị khi còn giữ cấu trúc tác vụ, thời điểm, quyền và trạng thái. Nếu bạn cần hiểu sâu hơn về danh tính tác nhân, quyền và dấu vết kiểm toá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 đặt phần bằng chứng vào một khung quản trị rộng hơn.
Phân loại lớp lỗi để tìm nguyên nhân gốc tác nhân
Một thông báo lỗi ngắn thường che nhiều lớp nguyên nhân. Với phone agent, chúng tôi dùng bản đồ lớp để tránh sửa nhầm chỗ: đầu vào, mô hình, định tuyến năng lực, ngữ cảnh màn hình, quyền Android, công cụ, giao diện ứng dụng, dịch vụ bên ngoài, phê duyệt và kiểm chứng cuối. Mỗi lớp có triệu chứng giống nhau nhưng cách xử lý khác nhau.
| Lớp lỗi | Dấu hiệu thường thấy | Cách kiểm tra nhanh |
|---|---|---|
| Ý định đầu vào | Agent làm đúng cú pháp nhưng sai mục tiêu | Đọc lại câu lệnh, tên người nhận, thời điểm, điều kiện và dữ liệu đích |
| Mô hình và lập kế hoạch | Kế hoạch có bước thừa, thiếu hoặc suy luận sai | So sánh kế hoạch với kết quả mong muốn trước khi gọi công cụ gây tác động |
| Định tuyến năng lực | Agent chọn sai công cụ hoặc chuyển sang phương án yếu hơn | Kiểm tra công cụ được chọn, lý do chọn và điều kiện hỗ trợ |
| Ngữ cảnh màn hình | Agent hiểu sai nút, biểu mẫu hoặc trạng thái ứng dụng | Gắn lại màn hình hiện tại, đọc nhãn, kiểm tra app có ở đúng trang không |
| Quyền Android | Báo thiếu quyền, bị từ chối hoặc hành động im lặng thất bại | Kiểm tra quyền ngay tại thời điểm dùng, vì người dùng có thể thu hồi quyền |
| Công cụ và ứng dụng đích | Gọi công cụ thành công nhưng app không đổi như dự kiến | Xem kết quả công cụ, app foreground, phiên đăng nhập và trạng thái mạng |
| Dịch vụ bên ngoài | Lỗi tải, timeout, tài khoản hoặc giới hạn dịch vụ | Thử bước đọc trạng thái, kiểm tra kết nối và thông báo của dịch vụ |
| Phê duyệt và kiểm chứng | Tác vụ chờ người dùng, hoặc hoàn tất nhưng chưa xác nhận kết quả | Xem thẻ phê duyệt, kết quả cuối và bằng chứng trạng thái sau thao tác |
Hướng dẫn quyền runtime của Android nêu rõ ứng dụng cần kiểm tra quyền khi dùng, vì người dùng có thể từ chối, thu hồi hoặc chọn trạng thái từ chối lâu dài. Điểm này làm cho gỡ lỗi và khôi phục tác nhân điện thoại khác với tác vụ web thuần túy: điều kiện đúng ở đầu phiên có thể đã sai ở giữa tác vụ.
Khi lỗi liên quan tới lựa chọn công cụ hoặc đường dự phòng, hãy tách định tuyến khỏi thực thi. Agent có thể hiểu ý định đúng nhưng chọn nhầm năng lực; cũng có thể chọn đúng năng lực nhưng thiếu ngữ cảnh hiện tại. Chúng tôi tách hai lớp này trong FoneClaw để người dùng và nhóm hỗ trợ nhìn thấy điểm vỡ rõ hơn. Bài Định tuyến năng lực tác nhân AI: AutoAttach, Suggest, Fallback trong FoneClaw giải thích riêng phần định tuyến để bài runbook này tập trung vào xử lý sự cố.
Tìm bước sớm nhất thật sự gây lỗi
AgentDebugX tổ chức gỡ lỗi theo vòng Phát hiện, Quy trách nhiệm, Khôi phục và Chạy lại. Khi đưa khung này vào điện thoại, chúng ta cần thêm một câu hỏi: bước nào là nguyên nhân sớm nhất làm các bước sau đi sai, và bước đó có tạo hiệu ứng bên ngoài chưa? Đây là khác biệt lớn giữa một benchmark phần mềm và một tác vụ trên điện thoại thật.
Bắt đầu từ lỗi hiện ra, rồi đi ngược lại. Nếu tác vụ báo không gửi được tin nhắn, đừng bắt đầu ở nút gửi. Hãy kiểm tra người nhận đã được chọn đúng chưa, nội dung đã được tạo đúng chưa, quyền SMS hoặc ứng dụng nhắn tin đã sẵn sàng chưa, và thẻ xác nhận đã được người dùng duyệt chưa. Nếu tác vụ báo không tìm thấy tệp, hãy xem agent đã dùng đúng ứng dụng tệp chưa, bộ lọc tên tệp có quá hẹp không, bộ nhớ có quyền đọc không, và màn hình hiện tại có phải thư mục dự kiến không.
Một cách làm thực tế là kiểm tra điều kiện trước bằng bước chỉ đọc. Ví dụ: đọc trạng thái quyền, liệt kê sự kiện lịch hiện có, xem thông tin mạng, kiểm tra âm lượng hoặc xác nhận app đang mở. Những bước này ít rủi ro hơn việc chạy lại toàn bộ lệnh. Sau đó đặt tên nguyên nhân gốc theo dạng có thể hành động: "tên liên hệ mơ hồ", "quyền vị trí bị thu hồi", "ngữ cảnh màn hình đã cũ", "công cụ không hỗ trợ trạng thái này", hoặc "dịch vụ bên ngoài timeout". Khi cần biến các lỗi này thành bộ đánh giá lặp lại, bài Benchmark phone agent Android: cách đánh giá mobile agent đáng tin cậy năm 2026 mở rộng phần kiểm thử và chấm độ tin cậy.
Khôi phục và chạy lại mà không nhân đôi hiệu ứng
Chạy lại an toàn nghĩa là khôi phục điều kiện bị hỏng rồi lặp phần nhỏ nhất còn cần thiết. Trước khi bấm retry, hãy hỏi ba câu: bước nào đã hoàn tất, bước nào có thể đảo ngược, và bước nào khi lặp sẽ tạo bản sao? Một lời nhắc lịch, một tin nhắn, một email, một thanh toán, một thay đổi cài đặt hoặc một tệp đã xóa đều cần kiểm tra trạng thái sau lỗi.
Thang khôi phục nên đi từ nhẹ đến mạnh. Đầu tiên là sửa điều kiện quan sát được: mở lại ứng dụng đúng, đưa app về foreground, bật mạng, cấp lại quyền, chọn đúng tài khoản, hoặc gắn lại màn hình hiện tại. Tiếp theo là chạy một bước xác minh chỉ đọc: xem quyền đã có chưa, đọc lịch hiện có, kiểm tra người nhận, xác nhận cài đặt hiện tại. Sau đó mới chạy lại bước công cụ lỗi nếu bước đó chưa tạo hiệu ứng hoặc có cơ chế chống trùng lặp rõ. Cuối cùng là kiểm tra trạng thái sau khi chạy, rồi dừng.
Thực hành tốt về quyền Android khuyến nghị kiểm thử cả trường hợp quyền được cấp và quyền bị thu hồi. Với tác vụ thực tế, điều này cũng là nguyên tắc khôi phục: nếu quyền bị từ chối lâu dài hoặc tự động đặt lại, agent nên hướng người dùng tới nơi sửa quyền hoặc giảm cấp tác vụ thành phần có thể làm được. Việc xóa dữ liệu ứng dụng, đăng xuất tài khoản hoặc chạy lại toàn bộ từ đầu nên được để sau cùng, vì các bước đó có thể làm mất bằng chứng và làm khó truy nguyên.
Với tác vụ nhiều cuộc trò chuyện hoặc nhiều hàng đợi, cần chắc chắn bạn đang sửa đúng phiên. Một lỗi ở phiên A không nên được khôi phục bằng dữ liệu của phiên B. Bài hàng đợi tác vụ AI agent nhiều cuộc trò chuyện trên Android giải thích cách tách trạng thái chạy, chờ và phục hồi giữa các phiên để tránh lặp nhầm.
Dùng các điều khiển hiện có của FoneClaw để chẩn đoán và khôi phục
Trong FoneClaw, chúng tôi xây phần khôi phục quanh trạng thái nhìn thấy được. Người dùng có thể quay lại ngữ cảnh tác vụ, xem kết quả, dùng dừng khi cần, đính kèm màn hình hiện tại một cách chủ động và chạy lại sau khi đã sửa điều kiện. Cách này đưa gỡ lỗi và khôi phục tác nhân điện thoại về các bước cụ thể thay vì buộc người dùng đoán agent đang làm gì.
Ngữ cảnh màn hình là một ví dụ quan trọng. FoneClaw hỗ trợ trợ lý nổi và thao tác đính kèm màn hình hiện tại do người dùng kích hoạt, giúp agent đọc tình huống đang xảy ra trong ứng dụng khác. Khi một tác vụ thất bại vì màn hình đã đổi, biểu mẫu không còn như dự kiến hoặc app chuyển trạng thái, người dùng có thể đưa lại màn hình đúng rồi yêu cầu tiếp tục phần còn lại. Bài Trợ lý AI nổi Android với ngữ cảnh màn hình hiện tại đi sâu vào cơ chế này, còn trong runbook hiện tại điểm cần nhớ là: đính kèm ngữ cảnh đúng trước khi thử lại.
FoneClaw cũng giữ các hành động Android được hỗ trợ trong phạm vi có trạng thái, phê duyệt và kết quả hiển thị. Với hơn 100 công cụ tích hợp trên lộ trình sản phẩm chính, các nhóm năng lực bao gồm kiểm tra trạng thái thiết bị, cài đặt hệ thống, liên lạc, lịch, vị trí, ghi chú, web, quy trình và mở rộng. Khi một công cụ thất bại, hãy đọc kết quả công cụ như bằng chứng: thiếu quyền, sai trạng thái ứng dụng, dữ liệu đầu vào không hợp lệ, dịch vụ không phản hồi hay người dùng chưa phê duyệt.
Luồng xử lý thực tế trong FoneClaw là: quay lại đúng tác vụ, đọc kết quả cuối, sửa điều kiện bị thiếu, dùng retry cho bước phù hợp, rồi xác nhận trạng thái cuối. Với tác vụ có tác động như gửi nội dung, gọi, đổi cài đặt, tạo lịch hoặc dùng dữ liệu riêng, hãy kiểm tra phần đã hoàn tất trước khi chạy lại. Bạn có thể xem phạm vi năng lực hiện tại trên trang tính năng FoneClaw và dùng trang tải xuống FoneClaw để kiểm tra thông tin cài đặt hiện hành.
Tạo báo cáo hỗ trợ hoặc lỗi có ích
Hãy chuyển sang báo cáo hỗ trợ khi lỗi lặp lại sau khi đã sửa quyền, ngữ cảnh và trạng thái ứng dụng; khi tác vụ tạo kết quả khác với phê duyệt; khi công cụ báo thành công nhưng điện thoại không đổi; hoặc khi lỗi liên quan tới dữ liệu nhạy cảm. Một báo cáo tốt ngắn hơn một bản ghi thô, nhưng có cấu trúc rõ.
Mẫu tối thiểu gồm: mục tiêu tác vụ, kết quả mong đợi, kết quả thực tế, bước đã chạy, bước sớm nhất nghi ngờ gây lỗi, trạng thái quyền, ứng dụng đích, thiết bị và phiên bản Android, mạng, thời điểm xảy ra, ảnh chụp đã che thông tin riêng và cách tái hiện bằng dữ liệu giả. Hãy loại bỏ mật khẩu, mã xác minh, mã thông báo, nội dung tin nhắn riêng, thông tin tài khoản, địa chỉ và dữ liệu liên hệ nếu chúng không bắt buộc để phân tích.
Câu mô tả tốt có dạng: "Khi yêu cầu tạo lịch nhắc gọi cho Mai, tác vụ chọn đúng Calendar nhưng dừng ở bước quyền lịch bị thu hồi; sau khi cấp lại quyền, retry bước tạo lịch tạo đúng một sự kiện." Câu này cho biết ý định, lớp lỗi, nguyên nhân gốc và kết quả khôi phục.
Ngăn lỗi lặp lại bằng kiểm thử chấp nhận
Sau khi khôi phục xong, hãy biến lỗi thành một ca kiểm thử nhỏ. Một lần chạy lại thành công chứng minh tác vụ vừa được sửa, nhưng chưa đủ để biết lỗi có tái diễn khi quyền thay đổi, app bị gián đoạn hoặc dữ liệu đầu vào mơ hồ. Với phone agent, kiểm thử phòng ngừa nên bao gồm quyền được cấp, quyền bị thu hồi, app đang foreground, app bị chuyển nền, mạng ổn định, mạng yếu và tên liên hệ hoặc tệp có khả năng trùng.
- Kiểm thử quyền: chạy với quyền có sẵn, quyền bị thu hồi và quyền bị từ chối lâu dài.
- Kiểm thử gián đoạn: đổi ứng dụng giữa chừng, khóa màn hình, mất mạng ngắn hoặc có thông báo xen vào.
- Kiểm thử dữ liệu mơ hồ: dùng tên liên hệ trùng, tệp cùng tên, lịch đã tồn tại hoặc cài đặt đã ở trạng thái mong muốn.
- Kiểm thử chạy lại: xác nhận retry chỉ lặp phần cần thiết và không nhân đôi tin nhắn, lịch, tệp hoặc thay đổi cài đặt.
- Kiểm thử bằng chứng: đảm bảo kết quả cuối, trạng thái quyền và bước phê duyệt đều có thể xem lại.
Một harness tốt ghi lại điều kiện vào, hành động được phép, điểm dừng, bằng chứng khôi phục và tiêu chí đạt. Bài harness phone agent tự cải thiện và quản trị kiểm thử trình bày cách biến sự cố đã gặp thành kiểm thử hồi quy có kiểm soát. Mục tiêu không phải làm agent không bao giờ lỗi, mà là mỗi lỗi để lại đủ tín hiệu để lần sau phục hồi nhanh hơn và an toàn hơn.