Khi mô hình trợ lý AI trên Android bị gián đoạn: cách thử lại, đổi mô hình và tiếp tục an toàn
Hướng dẫn thực tế từ FoneClaw để nhận diện lỗi mô hình AI trên Android, giữ trạng thái tác vụ, thử lại có giới hạn, đổi mô hình phù hợp và tiếp tục mà không lặp thao tác điện thoại.
- Phân loại lỗi trước khi thử lại: sự cố nhà cung cấp, giới hạn sử dụng, thông tin xác thực, mạng yếu và mô hình đã ngừng nhận yêu cầu cần cách xử lý khác nhau.
- Giữ riêng trạng thái phản hồi AI và trạng thái thao tác trên điện thoại để tránh gửi lại tin nhắn, tạo sự kiện, gọi điện hoặc thay đổi cài đặt hai lần.
- Thử lại theo giới hạn nhỏ, có thời gian chờ tăng dần, rồi dừng để kiểm tra trạng thái khi lỗi kéo dài hoặc có dấu hiệu quá tải.
- Trong FoneClaw, người dùng có thể xem tiến trình, đọc lại phản hồi dài, thử lại có kiểm soát, gửi phản hồi kèm ngữ cảnh và cấu hình mô hình tương thích khi cần.
Khi mô hình trợ lý AI trên Android bị gián đoạn, việc đầu tiên không phải là bấm thử lại ngay. Từ kinh nghiệm xây dựng FoneClaw, chúng tôi dùng một trật tự đơn giản hơn: nhận diện loại lỗi, giữ trạng thái tác vụ trên điện thoại, thử lại trong giới hạn nhỏ, chỉ đổi sang mô hình thay thế khi mô hình đó phù hợp, rồi tiếp tục từ bước đầu tiên chưa được xác nhận. Cách làm này giúp bạn khôi phục sự cố LLM di động mà không biến một lỗi phản hồi thành hai lần gửi tin nhắn, hai lần tạo lịch hoặc hai lần thay đổi cài đặt.
Điểm quan trọng nhất là tách phản hồi của mô hình khỏi kết quả thật trên Android. Một câu trả lời bị ngắt có thể xảy ra sau khi thao tác đã hoàn tất, trước khi thao tác bắt đầu, hoặc ngay giữa lúc FoneClaw đang chờ bạn phê duyệt. Vì vậy, chúng tôi thiết kế luồng tiến trình, phê duyệt, thử lại và phản hồi theo hướng có thể xem lại. Bài này là cách chúng tôi muốn người dùng xử lý khi trợ lý AI không phản hồi ổn định: bình tĩnh phân loại, giữ bằng chứng hiện có, rồi khôi phục có kiểm soát.
Nhận diện lỗi trước khi thử lại
Một lỗi giống nhau trên màn hình có thể đến từ nhiều lớp khác nhau. Nếu trợ lý đứng yên sau khi bạn nhập yêu cầu, nguyên nhân có thể là mạng Android yếu, máy đang mất kết nối, dịch vụ mô hình phản hồi chậm, tài khoản đã chạm hạn mức, khóa API hết hiệu lực, hoặc mô hình đã ngừng nhận yêu cầu. Các nhà cung cấp lớn thường phân biệt lỗi xác thực, giới hạn sử dụng, lỗi máy chủ, hết thời gian chờ và quá tải trong tài liệu vận hành. Anthropic, chẳng hạn, mô tả riêng các nhóm lỗi API và cách xử lý lỗi máy chủ có thể thử lại trong hướng dẫn lỗi Claude API.
Trong FoneClaw, chúng tôi xem đây là bước chẩn đoán trước khi hành động tiếp. Nếu lỗi nằm ở mô hình, phần suy luận có thể chưa tạo được kế hoạch mới. Nếu lỗi nằm ở Android, mô hình có thể đã trả lời đúng nhưng thao tác trên điện thoại bị kẹt do quyền, ứng dụng nền, hộp thoại hệ thống hoặc màn hình thay đổi. Hai trường hợp đó không nên được xử lý bằng cùng một nút thử lại.
Cách đọc nhanh là quan sát dấu hiệu: lỗi đăng nhập hoặc khóa sai cần sửa thông tin xác thực; thông báo giới hạn cần chờ hoặc điều chỉnh hạn mức; quá tải và hết thời gian chờ có thể thử lại có giãn cách; mô hình đã ngừng nhận yêu cầu cần đổi cấu hình. OpenAI từng công bố các báo cáo sự cố về độ trễ và lỗi tăng cao, còn xAI cũng từng ghi nhận sự cố mô hình trên ứng dụng Android rồi đánh dấu phục hồi trong trang trạng thái Grok Android. Những ví dụ đó nhắc chúng ta một điều thực tế: sự cố có thể là tạm thời, nhưng không phải mọi lỗi đều là sự cố tạm thời.
Giữ trạng thái tác vụ trước mọi lần thử lại
Trước khi thử lại trợ lý AI an toàn, hãy ghi nhận trạng thái cuối cùng đã chắc chắn. Bạn đã gửi tin nhắn chưa, hay mới đến màn hình soạn thảo? Lịch đã có sự kiện mới chưa, hay FoneClaw chỉ vừa chuẩn bị thẻ phê duyệt? Cài đặt đã đổi chưa, hay Android đang mở đúng trang cài đặt nhưng chưa có thao tác cuối? Đây là ranh giới mà chúng tôi dùng khi thiết kế tác vụ điện thoại: kế hoạch có thể được viết lại, nhưng trạng thái đã xác nhận trên thiết bị phải được tôn trọng.
Với tác vụ có hậu quả rõ ràng như gửi SMS, gọi điện, xóa dữ liệu, tạo sự kiện lịch hoặc thay đổi quyền, bạn nên dừng nếu không chắc thao tác đã hoàn tất. Đừng gửi lại toàn bộ yêu cầu ban đầu theo kiểu “làm lại từ đầu”. Hãy chuyển yêu cầu thành câu lệnh tiếp tục: “Kiểm tra xem tin nhắn đã gửi chưa; nếu chưa, tiếp tục từ bước gửi và hỏi tôi trước khi gửi”. Cách diễn đạt này giữ mục tiêu cũ nhưng không buộc trợ lý tái chạy các bước đã xong.
Trong FoneClaw, chúng tôi tách trạng thái hội thoại, trạng thái tác vụ và trạng thái phê duyệt để người dùng có thể xem tiến trình rõ hơn. Khi bạn nhìn lại phần phản hồi dài hoặc kết quả hành động, hãy tìm ba thông tin: mục tiêu ban đầu là gì, bước nào đã được xác nhận, bước nào còn chờ. Nếu vấn đề vượt ra ngoài lớp mô hình, bài 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 giúp bạn đi rộng hơn qua quyền, màn hình, ứng dụng đích và trạng thái hệ thống.
Thử lại lỗi tạm thời mà không tạo áp lực lặp
Thử lại có ích khi lỗi thực sự tạm thời: hết thời gian chờ, máy chủ quá tải, mạng vừa rớt, hoặc phản hồi bị cắt trước khi mô hình hoàn tất. Nhưng thử lại liên tục có thể làm tình hình xấu hơn. Trong một báo cáo sự cố của OpenAI, lưu lượng thử lại tăng mạnh đã góp phần làm tải hệ thống phía sau nặng hơn; chi tiết này được nêu trong bản ghi sự cố ChatGPT và nền tảng. Vì vậy, chúng tôi khuyến nghị một nhịp nhỏ: thử lại một lần, chờ lâu hơn nếu vẫn lỗi, rồi dừng sau vài lần để kiểm tra trạng thái.
Quy tắc thực hành của chúng tôi là không để nút thử lại thay thế phán đoán. Nếu lỗi nói về giới hạn sử dụng, khóa sai hoặc mô hình đã ngừng nhận yêu cầu, việc thử lại ngay thường chỉ tạo thêm thất bại. Nếu lỗi nói về quá tải hoặc hết thời gian chờ, hãy giữ nguyên tác vụ, không thay đổi mục tiêu, và thử lại phần phản hồi thay vì lặp lại hành động điện thoại đã được phê duyệt. Anthropic cũng khuyến nghị tăng khoảng chờ cho các lỗi máy chủ có thể khôi phục, được mô tả trong tài liệu lỗi API của họ.
Bảng dưới đây là cách chúng tôi thường hướng dẫn người dùng tự phân loại trước khi khôi phục:
| Dấu hiệu | Cách xử lý nên chọn | Điều cần tránh |
|---|---|---|
| Hết thời gian chờ hoặc quá tải | Thử lại ít lần, chờ lâu hơn giữa các lần | Bấm liên tục trong vài giây |
| Giới hạn sử dụng hoặc hết quota | Chờ hạn mức phục hồi hoặc điều chỉnh gói/cấu hình | Xem như lỗi mạng tạm thời |
| Khóa API hoặc đăng nhập không hợp lệ | Cập nhật thông tin xác thực trong nơi cấu hình an toàn | Dán khóa bí mật vào hội thoại công khai |
| Mô hình không còn nhận yêu cầu | Chọn mô hình tương thích đang được nhà cung cấp hỗ trợ | Thử lại cùng mô hình mãi |
Đổi mô hình sau khi kiểm tra tương thích
Đổi mô hình không lặp thao tác là một quyết định có chủ ý. Khi bạn chuyển từ mô hình này sang mô hình khác, bạn chỉ thay dịch vụ suy luận; trạng thái thật của điện thoại Android không tự quay lại, không tự xóa và cũng không tự được xác minh. Đây là lý do trong FoneClaw, chúng tôi xem phần chọn mô hình là cấu hình do người dùng kiểm soát, còn các hành động trên điện thoại vẫn đi qua ranh giới phê duyệt và xác nhận riêng.
Trước khi đổi sang mô hình AI dự phòng Android, hãy kiểm tra ba điều. Một là mô hình mới có nhận cùng kiểu đầu vào không: văn bản, ảnh màn hình, ngữ cảnh dài, hoặc yêu cầu cần hiểu giao diện. Hai là mô hình mới có phù hợp với tác vụ đang làm không: viết lại email khác với điều khiển cài đặt, còn đọc ảnh màn hình lại khác với tóm tắt thông báo. Ba là bạn có thể chuyển ngữ cảnh cần thiết mà không kéo theo các bước đã hoàn tất hay dữ liệu nhạy cảm không cần thiết.
Khi người dùng muốn so sánh cách chọn mô hình cho tác nhân điện thoại, chúng tôi tách chủ đề đó sang bài Định tuyến mô hình cho tác nhân điện thoại: Kimi, DeepSeek, GLM và FoneClaw, vì lựa chọn mô hình nên dựa trên năng lực, độ ổn định, chi phí và kiểu tác vụ. Với FoneClaw, hướng chúng tôi xây tiếp là làm phần cấu hình mô hình rõ ràng hơn: người dùng có đường mặc định để dùng ngay, đồng thời có khu vực riêng để chỉnh mô hình tương thích khi họ cần kiểm soát sâu hơn.
Tiếp tục từ bước chưa xác nhận
Khi phản hồi của mô hình đã khôi phục, đừng xem một câu trả lời trôi chảy là bằng chứng rằng Android đã làm xong việc. Trợ lý có thể trả lời lại đầy đủ trong khi tác vụ trên điện thoại vẫn đang chờ quyền, bị ứng dụng đích chặn, hoặc đã hoàn tất từ lần trước. Cách tiếp tục an toàn là bắt đầu từ bước đầu tiên chưa được xác nhận, ưu tiên đọc trạng thái trước khi ghi trạng thái.
Ví dụ, nếu bạn nhờ trợ lý tạo một sự kiện lịch và mô hình bị gián đoạn, bước tiếp theo nên là kiểm tra lịch xem sự kiện đã tồn tại chưa. Nếu chưa có, hãy tiếp tục tạo với cùng tiêu đề, thời gian và lịch đích, rồi hỏi lại trước khi ghi. Nếu đã có, trợ lý nên báo rằng tác vụ đã hoàn tất và không tạo bản sao. Với tin nhắn, email, cuộc gọi, ghi chú hay thay đổi cài đặt, nguyên tắc cũng giống vậy: đọc hoặc xác minh trước, chỉ thực hiện tiếp phần chưa chắc chắn.
FoneClaw được xây theo hướng làm rõ tiến trình đang chạy và kết quả sau hành động, để bạn có thể tiếp tục mà không mất ngữ cảnh. Khi mục tiêu hoặc tác động thay đổi, chúng tôi muốn hệ thống yêu cầu phê duyệt mới thay vì lặng lẽ dùng lại quyết định cũ. Nếu bạn cần dừng một tác vụ có dấu hiệu đi sai hướng trước khi tiếp tục, bài Cách dừng tác nhân AI trên Android và cô lập tác vụ an toàn đi sâu vào thao tác ngắt, cô lập và giữ thiết bị ở trạng thái kiểm soát được.
Xử lý hạn mức, khóa và mô hình đã ngừng nhận yêu cầu
Một số lỗi không nên được giải bằng thử lại. Lỗi xác thực thường cho biết khóa API, tài khoản, quyền truy cập hoặc cấu hình endpoint cần được sửa. Lỗi giới hạn có thể liên quan đến tốc độ gọi, quota, giới hạn chi tiêu hoặc gói dịch vụ. Lỗi mô hình ngừng nhận yêu cầu cần cập nhật sang mô hình thay thế mà nhà cung cấp đang hỗ trợ. Anthropic công bố riêng tài liệu về vòng đời mô hình trong hướng dẫn ngừng hỗ trợ mô hình Claude, và cách phân loại này cũng là thực hành tốt với các nhà cung cấp khác.
Khi cấu hình mô hình trong FoneClaw, hãy giữ khóa và thông tin xác thực trong khu vực thiết lập phù hợp, không đưa chúng vào nội dung yêu cầu hằng ngày. Nếu bạn dùng mô hình tự cấu hình, hãy lưu lại tên mô hình, endpoint, quyền truy cập và kiểu dữ liệu mà mô hình nhận. Khi có lỗi kéo dài, kiểm tra các thông tin đó trước khi kết luận rằng tác nhân Android hỏng.
Chúng tôi đang làm phần quản lý mô hình tùy chỉnh theo hướng dễ chỉnh trực tiếp hơn, vì người dùng nâng cao thường cần thay đổi nhà cung cấp, mô hình hoặc thông tin kết nối mà không phá vỡ tác vụ điện thoại. Phần thiết lập chi tiết được đặt trong bài Kết nối API mô hình AI với tác nhân Android trong FoneClaw. Bài này hữu ích khi bạn đã biết lỗi nằm ở cấu hình, không còn là một lần quá tải ngắn hay mạng Android chập chờn.
Khôi phục trong FoneClaw mà không lặp thao tác
Trong FoneClaw, chúng tôi xây luồng khôi phục quanh ba câu hỏi: mô hình đã trả lời đến đâu, tác vụ điện thoại đã làm đến đâu, và người dùng đã phê duyệt tác động nào. Ứng dụng hiện hỗ trợ xem tiến trình rõ hơn, đọc lại phản hồi dài, thử lại phản hồi khi phù hợp và gửi phản hồi kèm ngữ cảnh liên quan. Điều này giúp nhóm sản phẩm của chúng tôi cải thiện các ca lỗi thật mà không bắt người dùng mô tả lại toàn bộ phiên làm việc từ đầu.
Khi gặp mô hình trợ lý AI trên Android bị gián đoạn trong FoneClaw, hãy làm theo trình tự này:
- Xem lại trạng thái cuối cùng trên màn hình FoneClaw và ứng dụng Android đích.
- Ghi nhận bước nào đã được xác nhận, bước nào mới là kế hoạch.
- Chỉ thử lại phần phản hồi nếu lỗi có vẻ tạm thời và hành động điện thoại chưa bị lặp.
- Nếu mô hình hiện tại không phù hợp hoặc không còn nhận yêu cầu, chọn mô hình tương thích trong phần cấu hình.
- Tiếp tục từ bước chưa xác nhận đầu tiên, rồi kiểm tra kết quả sau khi hoàn tất.
FoneClaw có đường dùng mặc định cho người mới và cấu hình mô hình tương thích cho người cần kiểm soát sâu hơn. Bạn có thể xem phạm vi hiện tại của các tác vụ, phê duyệt và 100+ built-in tools trong trang Tính năng FoneClaw. Khi muốn cài ứng dụng hoặc lấy bản mới nhất theo thông tin sản phẩm hiện có tại thời điểm bài viết được cập nhật, hãy dùng trang Tải FoneClaw để đi theo đường phân phối chính thức.
Bài học lớn nhất của chúng tôi khi xây FoneClaw là khôi phục không phải là làm lại. Một tác nhân điện thoại đáng tin cậy cần biết dừng, đọc lại trạng thái, hỏi lại ở ranh giới quan trọng và tiếp tục có bằng chứng. Với lỗi mô hình AI, cách xử lý tốt nhất thường là chậm hơn vài giây ở đầu, nhưng tiết kiệm nhiều rủi ro ở cuối.