Định tuyến năng lực tác nhân AI: AutoAttach, Suggest, Fallback trong FoneClaw
Theo dõi một yêu cầu Android qua ghép năng lực theo ngữ cảnh, AutoAttach, Suggest, Fallback, kích hoạt, phê duyệt, thực thi và phục hồi trong FoneClaw.
- Định tuyến năng lực tác nhân AI là quá trình biến một yêu cầu Android thành danh sách năng lực ứng viên, xếp hạng theo ngữ cảnh, quyền, độ tin cậy và trạng thái thiết bị.
- AutoAttach, Suggest và Fallback là ba nhánh khác nhau: tự gắn ngữ cảnh có độ tin cậy cao, đưa lựa chọn để người dùng duyệt, hoặc chuyển sang đường phục hồi khi thiếu hoặc mơ hồ.
- Ghép năng lực, khám phá, đính kèm, kích hoạt, phê duyệt và thực thi là các trạng thái riêng; định tuyến tốt giữ từng bước nhìn thấy được thay vì trộn chúng thành một hành động ẩn.
- Trong FoneClaw, chúng tôi áp dụng capability routing cho 100+ built-in tools, Skill, Workflow và Plugin được quản trị, với xem xét kích hoạt, preview, phê duyệt, kết quả hiển thị và phục hồi quyền.
Từ một yêu cầu Android đến danh sách năng lực ứng viên
Hãy bắt đầu bằng một yêu cầu thật: “dựa trên màn hình này, tạo ghi chú ngắn và nhắc tôi xem lại tối nay”. Với người dùng, đây là một câu nói tự nhiên. Với tác nhân AI trên Android, đó là một bài toán định tuyến năng lực tác nhân AI: yêu cầu có thể cần đọc ngữ cảnh màn hình, tạo ghi chú, tạo nhắc việc, kiểm tra quyền, hiển thị bản nháp và xin phê duyệt trước khi lưu.
Agent không nên nhét toàn bộ công cụ, Skill, Workflow và Plugin vào mọi lượt suy luận. Làm vậy làm tăng nhiễu, tăng chi phí, tăng độ trễ và khiến mô hình dễ chọn nhầm năng lực. Cách tốt hơn là tạo một tập ứng viên nhỏ: năng lực đọc màn hình hiện tại, năng lực ghi chú, năng lực tạo tác vụ hoặc nhắc việc, và năng lực phục hồi quyền nếu thiếu điều kiện.
Xếp hạng ứng viên dựa trên vài tín hiệu: ý định chính của câu nói, dữ liệu đang có trên màn hình, quyền đã cấp, trạng thái app, độ tin cậy của từng năng lực, mức nhạy cảm của hành động và khả năng cho người dùng xem lại kết quả. Ghép đúng năng lực theo ngữ cảnh không phải là giấy phép thực thi. Nó chỉ trả lời câu hỏi “đường nào có vẻ phù hợp nhất để chuẩn bị tác vụ?”.
Trong FoneClaw, chúng tôi thiết kế capability routing như một lớp ra quyết định trước thực thi. Mô hình giúp hiểu ý định và suy luận. Runtime Android của FoneClaw giữ danh sách năng lực được hỗ trợ, trạng thái quyền, kết quả hiển thị và điểm phê duyệt. Nếu bạn cần phân biệt các lớp năng lực ở mức khái niệm, bài Công cụ, Plugin, Skill, Workflow và Shortcut trong FoneClaw khác nhau thế nào? giữ phần glossary rộng hơn, còn bài này tập trung vào cơ chế chọn đường cho một yêu cầu cụ thể.
Chọn AutoAttach, Suggest hay Fallback
Sau khi có danh sách ứng viên, router cần chọn một trong ba nhánh: AutoAttach, Suggest hoặc Fallback. Ba nhánh này không cạnh tranh bằng tên gọi; chúng phục vụ ba mức chắc chắn khác nhau. AutoAttach phù hợp khi ngữ cảnh hoặc metadata liên quan rõ ràng và việc đính kèm không tạo tác động bên ngoài. Suggest phù hợp khi có nhiều đường hợp lý và người dùng nên chọn. Fallback phù hợp khi thiếu năng lực, thiếu quyền, confidence thấp hoặc mục tiêu quá mơ hồ.
| Nhánh | Khi dùng | Ví dụ với yêu cầu Android | Ranh giới an toàn |
|---|---|---|---|
| AutoAttach | Ngữ cảnh liên quan rõ, rủi ro thấp, không tạo hành động có tác động. | Đính kèm metadata màn hình hiện tại để mô hình hiểu nội dung cần ghi chú. | AutoAttach chỉ thêm ngữ cảnh hoặc metadata phù hợp; bước thực thi vẫn đi qua công cụ và phê duyệt riêng. |
| Suggest | Có nhiều năng lực có thể đúng, hoặc người dùng cần chọn hướng. | Đề xuất “tạo ghi chú”, “tạo nhắc việc”, hoặc “tạo cả hai” trước khi tiếp tục. | Suggest giữ lựa chọn nhìn thấy được, đặc biệt khi mục tiêu có thể hiểu theo nhiều cách. |
| Fallback | Thiếu quyền, thiếu năng lực, dependency chưa sẵn sàng, target mơ hồ hoặc confidence thấp. | Nếu chưa có quyền đọc màn hình, đưa người dùng tới bước cấp quyền hoặc đề nghị nhập nội dung thủ công. | Fallback là đường phục hồi có kiểm soát; nó không bỏ qua quyền hoặc chính sách. |
AutoAttach khác Suggest ở chỗ AutoAttach xử lý phần “có thể giúp mô hình hiểu hơn” mà không cần biến thành quyết định người dùng phải chọn. Ví dụ, khi người dùng bấm nút đính kèm màn hình hiện tại từ trợ lý nổi, FoneClaw có thể đưa thông tin màn hình vào ngữ cảnh tác vụ. Điều đó không đồng nghĩa với việc hệ thống đã lưu ghi chú, tạo nhắc việc hoặc chạy Plugin.
Suggest nên xuất hiện khi router nhận ra nhiều đường đều hợp lý. Câu “nhắc tôi xử lý cái này tối nay” có thể là tạo ghi chú, tạo tác vụ, tạo lịch nhắc hoặc mở app liên quan. Nếu hệ thống tự chọn một đường khi confidence chưa đủ, người dùng dễ nhận kết quả sai. Một suggestion tốt dùng nhãn hành động ngắn, cho thấy vì sao nó phù hợp và để người dùng chọn trước khi tiếp tục.
Fallback là phần tạo sự bền vững. Khi không có năng lực phù hợp, router cần nói rõ bước tiếp theo: dùng built-in tool khác, đề nghị bật quyền, yêu cầu chọn app, hoặc lưu một draft chưa kích hoạt. Fallback tốt giúp workflow tiếp tục theo cách có kiểm soát thay vì lặp lại suy luận hoặc đoán hành động. Đây cũng là nơi FoneClaw đặt trọng tâm: người dùng không bị bỏ giữa chừng khi trạng thái điện thoại khác với kế hoạch ban đầu.
Tách khám phá, đính kèm, kích hoạt, phê duyệt và thực thi
Lỗi lớn nhất trong định tuyến công cụ Android là trộn các trạng thái thành một hành động duy nhất. Một router có thể khám phá thấy năng lực, nhưng năng lực đó chưa chắc đã được đính kèm vào ngữ cảnh. Một Plugin có thể được đề xuất, nhưng điều đó chưa phải là cài đặt. Một Skill có thể được tạo bản nháp, nhưng bản nháp đó chưa chạy. Một công cụ có thể được chọn, nhưng hành động có tác động vẫn cần phê duyệt.
- Khám phá: hệ thống tìm năng lực có thể liên quan từ built-in tools, Skill, Workflow hoặc nguồn Plugin được quản trị.
- Đính kèm: router đưa metadata hoặc ngữ cảnh phù hợp vào lượt xử lý, ví dụ màn hình hiện tại hoặc mô tả năng lực.
- Kích hoạt: năng lực được bật hoặc sẵn sàng trong phạm vi người dùng đã hiểu, với dependency được kiểm tra.
- Phê duyệt: hành động có tác động như gửi, lưu, xóa, gọi, cài hoặc thay đổi cài đặt được trình bày để người dùng quyết định.
- Thực thi và xác minh: FoneClaw chạy công cụ Android được hỗ trợ, hiển thị trạng thái và phục hồi khi điều kiện thiếu.
Hệ sinh thái agent cũng đang đi theo hướng tách trạng thái này. bài Google Developers về Agent Plugins mô tả một đặc tả đóng gói Skills và MCP servers bằng metadata chung. Đóng gói giúp năng lực có danh tính và cấu trúc rõ hơn, nhưng bao bì không tự tạo niềm tin, không tự kích hoạt và không tự chạy hành động cho người dùng.
GitHub Changelog về Agent finder cũng là một ví dụ hữu ích: hệ thống có thể xếp hạng tài nguyên phù hợp theo yêu cầu, nhưng vẫn tôn trọng registry và thiết lập được cấu hình. Với FoneClaw, bài học tương tự được đưa vào điện thoại: discovery giúp tìm đường, attachment giúp hiểu ngữ cảnh, activation chuẩn bị năng lực, approval quyết định hành động, execution mới tạo kết quả Android.
Nếu bạn muốn đào sâu riêng vào resource registry, xác minh và quyền tin cậy, bài Agentic Resource Discovery: ai-catalog.json, xác minh và quyền cho phone agent là nơi phù hợp hơn. Bài hiện tại giữ trọng tâm ở state machine sau khi một yêu cầu Android đã cần chọn năng lực.
Dùng manifest, dependency, metadata và confidence đúng cách
Một router tốt cần dữ liệu đầu vào rõ. Manifest cho biết năng lực là gì, thuộc loại nào, cần quyền nào, nhận input nào và trả kết quả gì. Dependency cho biết năng lực cần app, quyền, Plugin, dịch vụ hoặc trạng thái nào trước khi sẵn sàng. Context metadata cho biết yêu cầu hiện tại đang đến từ màn hình nào, app nào, loại nội dung nào và mục tiêu gần nhất của người dùng là gì. Confidence cho biết router tự tin đến đâu về lựa chọn của mình.
Với định tuyến plugin và skill, manifest và metadata chỉ là điều kiện ban đầu. Chúng giúp router xếp hạng ứng viên, nhưng tính đáng tin còn đến từ nguồn phát hành, trạng thái kích hoạt, dependency, quyền Android, hành vi trong lần chạy trước và mức nhạy cảm của tác vụ. Một Plugin được tìm thấy trong nguồn phù hợp vẫn cần quá trình xem xét kích hoạt. Một Skill học từ yêu cầu người dùng vẫn cần preview và xác nhận trước khi trở thành bản nháp có thể quản lý.
Dependency phải được xử lý trước activation. Nếu một năng lực cần quyền thông báo, quyền lịch hoặc app đích đã đăng nhập, router không nên gửi thẳng yêu cầu sang công cụ rồi để lỗi mơ hồ. Nó nên tạo đường phục hồi: mở trang quyền, yêu cầu người dùng chọn tài khoản, hoặc đề nghị một workflow thay thế. Đây là lý do FoneClaw giữ atomic capability snapshot: khi refresh capability thất bại, hệ thống có thể giữ bộ năng lực đã được chấp nhận trước đó thay vì chuyển sang trạng thái nửa mới nửa cũ.
Confidence cũng cần được thiết kế như một tín hiệu hành động. Confidence cao có thể cho phép AutoAttach metadata rủi ro thấp. Confidence trung bình nên chuyển sang Suggest. Confidence thấp nên đi Fallback. Với dữ liệu nhạy cảm, ngưỡng cần cao hơn. Nếu bạn đang thiết kế Skill có quyền sâu hơn, bài Bảo mật kỹ năng AI agent trên điện thoại giúp đặt routing vào bối cảnh quyền và rủi ro cụ thể.
Phục hồi khi thiếu, cũ, bị từ chối hoặc mơ hồ
Khả năng phục hồi quyết định router có dùng được hằng ngày hay không. Có bốn nhóm lỗi thường gặp: thiếu năng lực, dependency cũ, quyền bị từ chối và mục tiêu mơ hồ. Mỗi nhóm cần đường xử lý riêng. Retry mô hình có thể giúp khi câu trả lời chưa rõ, nhưng không sửa được quyền bị tắt, app chưa cài, manifest không khớp hoặc liên hệ có nhiều người cùng tên.
Khi thiếu năng lực, Fallback nên đưa ra đường tiếp theo thay vì tạo cảm giác thất bại. Ví dụ: lưu yêu cầu thành ghi chú, đề nghị dùng built-in tool gần nhất, hoặc hướng người dùng tới Plugin được quản trị nếu tác vụ thật sự cần mở rộng. Khi dependency cũ, router cần refresh capability snapshot hoặc giữ snapshot đã chấp nhận gần nhất. Khi quyền bị từ chối, permission recovery nên đưa người dùng tới đúng màn hình cài đặt và quay lại task continuity sau khi người dùng xử lý.
Ambiguity cần hỏi lại. “Gửi cho Lan” không đủ nếu danh bạ có nhiều Lan. “Lưu cái này” không đủ nếu có thể là memo, calendar event, file hoặc task. Một router có trách nhiệm biến mơ hồ thành câu hỏi nhỏ, không biến mơ hồ thành hành động lớn. Với tác vụ nhạy cảm, phê duyệt phải hiển thị nội dung và target trước khi thực thi.
False-positive và no-match cũng cần được test. False-positive xảy ra khi router gắn nhầm năng lực vì keyword giống nhau: “đặt lịch” có thể là calendar, alarm hoặc task. No-match xảy ra khi yêu cầu hợp lý nhưng chưa có capability phù hợp. Trong FoneClaw, recovery không chỉ là trả lời xin lỗi; chúng tôi hướng tới trạng thái rõ: cần quyền nào, thiếu năng lực nào, người dùng có thể chọn gì tiếp theo và phần task nào vẫn giữ được.
Định tuyến năng lực có quản trị trong FoneClaw
Trong FoneClaw, chúng tôi áp dụng AutoAttach Suggest Fallback như một nền tảng routing có quản trị cho Android phone agent. Người dùng đưa yêu cầu tự nhiên. Mô hình hiểu intent. FoneClaw kiểm tra ngữ cảnh hiện tại, danh sách 100+ built-in tools, Skill, Workflow và Plugin đã được quản trị, rồi chọn đường phù hợp: tự đính kèm ngữ cảnh rủi ro thấp, đề xuất lựa chọn nhìn thấy được, hoặc chuyển sang Fallback khi điều kiện chưa đủ.
AutoAttach trong FoneClaw tập trung vào việc đưa đúng ngữ cảnh vào lượt xử lý. Ví dụ, khi người dùng chủ động dùng trợ lý nổi từ màn hình hiện tại, router có thể gắn metadata màn hình để mô hình hiểu “cái này” đang nói tới nội dung nào. Nó không chạy công cụ âm thầm. Nó giúp mô hình có bối cảnh tốt hơn trước khi FoneClaw chọn công cụ, hiển thị kết quả và xin phê duyệt nếu hành động có tác động.
Suggest là cách chúng tôi giữ quyền quyết định của người dùng khi có nhiều đường hợp lý. Với yêu cầu “nhắc tôi xử lý nội dung này”, FoneClaw có thể đề xuất tạo memo, tạo task hoặc tạo calendar reminder tùy ngữ cảnh. Người dùng chọn hướng trước khi agent tiếp tục. Điều này làm giảm false-positive, đặc biệt với tiếng Việt đời thường, nơi cùng một câu có thể mang nhiều ý định hành động.
Fallback là phần giúp workflow không vỡ khi thiếu điều kiện. Nếu thiếu quyền, FoneClaw đưa người dùng đến đường cấp quyền phù hợp và giữ task continuity. Nếu Plugin cần kích hoạt, quá trình activation được xem xét. Nếu Skill mới được học, FoneClaw dùng preview và xác nhận trước khi lưu thành bản nháp đang tắt, để người dùng quản lý trước khi đưa vào luồng làm việc. Nếu capability refresh gặp lỗi, snapshot đã được chấp nhận vẫn giữ runtime ở trạng thái nhất quán.
Phần quan trọng nhất là phê duyệt. Routing chọn đường, còn approval quyết định bước có tác động. FoneClaw giữ gửi tin, gọi điện, thay đổi dữ liệu, bật tắt cài đặt hoặc dùng dữ liệu riêng trong luồng có trạng thái và xác nhận. Nếu bạn muốn đi sâu vào cách trình bày confidence và lý do để người dùng quyết định đúng, bài UX phê duyệt tác vụ AI agent trên điện thoại: thiết kế để quyết định đúng nối trực tiếp từ routing sang trải nghiệm phê duyệt.
Khi cần xem các năng lực người dùng có thể kiểm tra hiện tại, hãy bắt đầu từ trang tính năng FoneClaw và chọn một yêu cầu nhỏ có cả đường match rõ và đường no-match. Cách chúng tôi xây FoneClaw là biến capability routing thành một vòng nhìn thấy được: hiểu ngữ cảnh, chọn ứng viên, đề xuất hoặc đính kèm, kiểm tra điều kiện, phê duyệt, thực thi và phục hồi.
Bảy kiểm tra để thiết kế capability router
Một capability router tốt cần được kiểm thử bằng cả trường hợp đúng và sai. Đừng chỉ đo accuracy của intent classifier. Hãy đo chất lượng candidate set, false-positive, no-match, dependency, approval và recovery. Với tác nhân Android, kết quả tốt là một workflow rõ ràng, không phải một câu trả lời tự tin.
- Candidate quality: yêu cầu tạo ra danh sách ứng viên đủ hẹp và có thứ tự hợp lý chưa?
- Context fit: AutoAttach có gắn đúng ngữ cảnh rủi ro thấp, hay gắn thừa dữ liệu gây nhiễu?
- Suggest clarity: lựa chọn có đủ rõ để người dùng quyết định giữa memo, task, calendar, app hoặc Plugin không?
- No-match behavior: khi chưa có năng lực phù hợp, router có đưa ra đường tiếp theo hữu ích không?
- Dependency state: quyền, app, Plugin, Skill và snapshot năng lực có được kiểm tra trước activation không?
- Approval boundary: hành động có tác động có hiển thị nội dung, target và lý do trước khi chạy không?
- Recovery evidence: khi thiếu quyền hoặc target mơ hồ, task có tiếp tục được sau khi người dùng sửa điều kiện không?
Bài test đơn giản nhất là cùng một yêu cầu với ba trạng thái: match rõ, match mơ hồ và no-match. Ví dụ, “tạo ghi chú từ màn hình này” khi màn hình có nội dung rõ; “lưu cái này” khi có nhiều khả năng; và “dùng Plugin chưa kích hoạt để xử lý file này” khi dependency chưa sẵn sàng. Nếu router xử lý cả ba trạng thái bằng AutoAttach, Suggest và Fallback đúng chỗ, bạn đã có nền tảng tốt hơn nhiều so với một agent chỉ chọn công cụ theo keyword.