Agentic Resource Discovery: ai-catalog.json, xác minh và quyền cho phone agent

Agentic Resource Discovery giải quyết vấn đề gì?

Agentic Resource Discovery, thường viết tắt là ARD, là một đặc tả để công bố, tìm kiếm và xác minh tài nguyên mà tác nhân AI có thể dùng: tools, skills và agents. Theo công bố ARD của Google Developers ngày 17 tháng 6 năm 2026, mục tiêu của ARD là tạo một cách thống nhất để tác nhân biết năng lực nào tồn tại, do ai phát hành và nên kết nối qua giao thức nào.

Vấn đề thực tế nằm ở chỗ hệ sinh thái agent đang phân mảnh. Một dịch vụ có thể có MCP server, một dịch vụ khác dùng OpenAPI, một nhà cung cấp khác mô tả agent qua A2A, còn ứng dụng di động lại cần hợp đồng gọi riêng. Nếu mỗi nhóm tự giữ một registry nội bộ hoặc viết mô tả thủ công, tác nhân khó tìm đúng tài nguyên và càng khó đánh giá nguồn gốc.

ARD đưa vào một lớp khám phá trước khi kết nối. Một domain có thể công bố catalog, ví dụ thông qua ai-catalog.json hoặc một catalog được tham chiếu, để mô tả năng lực, giao thức, endpoint, metadata nhà phát hành và các catalog lồng nhau. Tác nhân hoặc runtime có thể đọc catalog trực tiếp từ domain đã biết, hoặc hỏi registry bằng ý định tự nhiên như “tìm công cụ gửi hóa đơn” hay “tìm agent xử lý lịch”.

Điểm quan trọng nhất cho phone agent: ARD trả lời câu “tài nguyên nào có thể tồn tại và nên kết nối ở đâu”, chứ không trả lời câu “người dùng đã cho phép hành động này chưa”. Khám phá tài nguyên cho tác nhân AI là bước mở đường; quyền trên điện thoại, xác nhận người dùng và phạm vi hành động vẫn là một chuỗi kiểm soát riêng.

Catalog và registry công bố năng lực như thế nào?

Một catalog ARD có thể được hiểu như bảng kê năng lực do chính nhà phát hành quản lý. Trong catalog, nhà cung cấp mô tả tài nguyên nào đang có, tài nguyên thuộc loại gì, cách kết nối ra sao, giao thức gốc là MCP, A2A, OpenAPI hay một catalog khác, và metadata nào hỗ trợ xác minh. kho đặc tả ARD công khai cho thấy phần schema, kiến trúc tin cậy và công việc tham chiếu được phát triển mở, theo giấy phép Apache-2.0.

Registry đóng vai trò khác. Registry không phải bên thực thi thay tài nguyên, mà là nơi crawl, lập chỉ mục và trả về các năng lực phù hợp với truy vấn. Khi một client hỏi registry theo ý định, registry có thể trả về danh sách tài nguyên khớp, thông tin xác minh, đường dẫn catalog và giao thức được quảng cáo. Client sau đó vẫn phải tự đánh giá, chọn và kết nối theo giao thức gốc.

Trong thực tế, một đội ngũ có thể dùng cả hai đường. Với đối tác đã biết, runtime có thể fetch catalog trực tiếp từ domain của đối tác. Với nhu cầu mở hơn, registry search giúp tìm khả năng phù hợp trong hệ sinh thái lớn hơn. Cả hai đường đều cần kiểm tra freshness, chữ ký hoặc metadata xác minh, phiên bản schema và sự khớp giữa mô tả với endpoint thực tế.

Xác minh nhà phát hành chứng minh điều gì?

Xác minh giúp giảm nhầm lẫn nguồn gốc. Khi catalog có metadata có thể kiểm chứng bằng mật mã hoặc gắn với domain do nhà phát hành kiểm soát, runtime có cơ sở tốt hơn để biết tài nguyên được công bố bởi đúng tổ chức. Đây là cải thiện lớn so với việc một tác nhân chỉ thấy một URL lạ hoặc một mô tả công cụ không có nguồn gốc rõ ràng.

Tuy vậy, danh mục công cụ tác nhân đáng tin cậy không chỉ dựa vào tên nhà phát hành. Danh tính đúng không đồng nghĩa với hành vi phù hợp cho mọi người dùng. Một endpoint có thể đến từ đúng công ty nhưng vẫn cần quyền tài khoản, scope phù hợp, điều khoản sử dụng, giới hạn vùng, giới hạn dữ liệu và kiểm soát hành động. Metadata nguyên vẹn cũng không tự chứng minh rằng một lệnh cụ thể nên được chạy trên điện thoại của người dùng.

Có bốn câu hỏi nên tách riêng. Ai phát hành tài nguyên? Catalog có còn nguyên vẹn và mới không? Endpoint có tương thích với runtime và giao thức được quảng cáo không? Người dùng hiện tại có quyền thực hiện hành động này, với dữ liệu này, trên thiết bị này không? ARD hỗ trợ mạnh cho hai câu đầu và tạo đầu mối cho câu thứ ba; câu thứ tư thuộc về runtime, chính sách, quyền và xác nhận.

Vì vậy, xác minh trước khi kết nối là bước cần có, nhưng không phải giấy phép để bỏ qua kiểm soát sau đó. Một phone agent nghiêm túc phải xem publisher verification như bằng chứng nguồn gốc, rồi tiếp tục kiểm tra quyền thao tác, mục tiêu hành động và mức rủi ro trước khi chạm vào Android.

ARD bàn giao cho MCP, A2A, OpenAPI và hợp đồng app ra sao?

ARD không thay thế MCP, A2A hay OpenAPI. Nó giống lớp tìm đường và xác minh metadata trước khi runtime đi vào giao thức gốc. Catalog có thể nói “tài nguyên này là MCP server”, “agent này nói A2A”, “tool này có OpenAPI spec”, hoặc “catalog này trỏ đến catalog con”. Khi runtime chọn một entry, phần gọi thật vẫn phải tuân theo giao thức được quảng cáo.

Điểm này đặc biệt quan trọng với ứng dụng di động. Một tài nguyên được phát hiện trên web không tự biến mọi app Android thành app có thể gọi bằng máy. Nếu thao tác cần mở màn hình, truyền intent, nhận kết quả, ghi dữ liệu hoặc yêu cầu xác nhận, app đích vẫn cần một hợp đồng gọi rõ ràng. Để hiểu phần sau khám phá, bài App Intents và ứng dụng có thể gọi bằng máy cho AI agents đi sâu vào cách app bộc lộ hành động để agent có thể gọi một cách có cấu trúc.

Một luồng lành mạnh thường đi như sau: runtime tìm catalog, xác minh publisher, resolve endpoint, kiểm tra giao thức, khởi tạo kết nối, rồi mới đánh giá công cụ có được bật cho người dùng hay không. Nếu giao thức không khớp, schema thiếu, endpoint lỗi hoặc phiên bản không tương thích, runtime nên dừng và báo rõ thay vì tự chuyển sang một endpoint khác không được người dùng hiểu.

Nói ngắn gọn, ARD làm cho tài nguyên dễ tìm và dễ kiểm chứng hơn. MCP, A2A, OpenAPI và hợp đồng ứng dụng vẫn là đường thực thi. Phone agent cần cả hai: khám phá tốt để không kết nối mù, và hợp đồng gọi tốt để không hành động mơ hồ.

Vì sao khám phá không phải là cấp quyền trên điện thoại

Trên điện thoại, quyền không thể được suy ra từ một catalog. Android có cơ chế runtime permission riêng; hướng dẫn quyền runtime của Android nhấn mạnh rằng ứng dụng nên yêu cầu quyền trong ngữ cảnh khi tính năng cần quyền đó, đồng thời tự xử lý tình huống người dùng từ chối. ARD không thay thế bước này, vì ARD không biết đủ ngữ cảnh thiết bị, người dùng, app đích và tác động của từng hành động.

Một catalog có thể nói rằng công cụ “gửi tin nhắn” tồn tại. Điều đó khác với việc người dùng đã bật công cụ gửi tin trong runtime, đã cấp quyền liên quan trên Android, đã chọn đúng người nhận, đã xem nội dung, đã đồng ý gửi và có thể thu hồi quyền sau đó. Cùng một công cụ cũng có thể là rủi ro thấp khi chỉ đọc trạng thái, nhưng trở thành hành động có tác động bên ngoài khi gửi dữ liệu cho người khác.

Với kỹ năng phone agent, phần rủi ro còn nằm ở dữ liệu đầu vào, app đích và cách recovery khi lỗi. Bài Bảo mật kỹ năng AI agent trên điện thoại phù hợp nếu bạn muốn đào sâu vào cách đánh giá kỹ năng, quyền và rủi ro thao tác mà không biến ARD thành một bài bảo mật tổng quát.

Hoạt động đáng tin cậy cũng cần danh tính và dấu vết. Khi một hành động được đề xuất, người dùng nên biết tác nhân nào, công cụ nào, tài khoản nào và kết quả nào liên quan. Phần 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 mở rộng chủ đề đó; tại đây, nguyên tắc chính là khám phá và thẩm quyền phải luôn quan sát được một cách độc lập.

Checklist trước khi kết nối và trước khi thực thi

Trước khi cho một phone agent dùng tài nguyên được phát hiện, hãy chia checklist thành hai nửa. Nửa đầu là trước khi kết nối; nửa sau là trước khi hành động. Cách tách này giúp đội ngũ tránh một lỗi phổ biến: thấy tài nguyên có metadata đẹp rồi cho nó chạm ngay vào dữ liệu hoặc thao tác trên thiết bị.

1. Xác định nguồn: kiểm tra domain, publisher, chữ ký hoặc metadata xác minh nếu có.
2. Kiểm tra catalog: xem catalog có mới, đúng schema, mô tả rõ giao thức và endpoint không.
3. Đối chiếu giao thức: đảm bảo runtime hiểu MCP, A2A, OpenAPI hoặc hợp đồng app được quảng cáo.
4. Bắt đầu với tác vụ rủi ro thấp: thử đọc metadata, mô phỏng lời gọi hoặc chạy tác vụ không có tác động bên ngoài.
5. Kiểm tra trạng thái bật công cụ: công cụ chỉ nên hoạt động khi được bật theo chính sách của runtime.
6. Đánh giá scope: quyền tài khoản, quyền Android và dữ liệu mục tiêu phải khớp với tác vụ cụ thể.
7. Hiển thị bước quan trọng: nội dung gửi đi, người nhận, app đích hoặc thay đổi hệ thống cần rõ trước khi hoàn tất.
8. Áp dụng phê duyệt theo rủi ro: không phải mọi thao tác đều cần cùng mức xác nhận, nhưng thao tác có tác động phải có điểm kiểm soát.
9. Ghi nhận kết quả: runtime nên cho người dùng thấy thành công, thất bại, trạng thái một phần hoặc lý do dừng.
10. Chuẩn bị thu hồi: người dùng cần có đường tắt để tắt công cụ, hủy quyền, gỡ plugin hoặc dừng luồng.

Checklist này cũng giúp xử lý lỗi tốt hơn. Nếu kết nối thất bại, lỗi thuộc về catalog, endpoint hay quyền tài khoản? Nếu hành động bị chặn, đó là do công cụ chưa bật, Android chưa cấp quyền hay chính sách yêu cầu xác nhận? Một runtime trưởng thành không chỉ báo “không làm được”, mà chỉ ra lớp nào đã dừng và người dùng có thể sửa gì.

Cách FoneClaw tách hiển thị catalog khỏi quyền trên điện thoại

Trong FoneClaw, chúng tôi xem catalog là cách làm cho năng lực có thể nhìn thấy, còn quyền là quyết định riêng của runtime và người dùng. FoneClaw là runtime phone agent Android: mô hình được cấu hình giúp hiểu, suy luận và lập kế hoạch; FoneClaw gọi các công cụ Android được hỗ trợ, có chính sách và có kết quả hiển thị. Điều này khác với việc một catalog tự cho phép tác nhân làm mọi thứ trên điện thoại.

Theo dữ liệu phát hành FoneClaw ngày 1 tháng 8 năm 2026, bản 0.1.0 bổ sung quản lý từng công cụ, kiểm soát bật tắt, override phê duyệt, recovery quyền và hợp đồng công cụ an toàn hơn. Luồng plugin đáng tin cậy cũng đi qua đề xuất hiển thị và gói được ký, không phải cài đặt âm thầm. Đây là cách chúng tôi giữ ranh giới giữa “biết có một năng lực” và “cho phép năng lực đó chạy”.

snapshot public tool catalog của FoneClaw tại cùng thời điểm có 118 built-in tools trong 11 nhóm với nhãn rủi ro và approval. Trong nội dung bền vững, chúng tôi nói FoneClaw có hơn 100 built-in tools vì catalog sẽ tiếp tục thay đổi. Những nhãn này giúp runtime phân biệt tác vụ đọc rủi ro thấp, tác vụ điều khiển thiết bị, tác vụ giao tiếp, vị trí, workflow, skill và plugin.

FoneClaw hiện được trình bày ở đây như ví dụ runtime có catalog và chính sách công cụ, không phải như một tuyên bố đã triển khai ARD. Nếu bạn muốn xem đầy đủ cách FoneClaw biến ý định thành thao tác Android được hỗ trợ, bài Điều khiển điện thoại bằng AI agent trên Android là phần tiếp theo phù hợp. Với ARD, bài học chúng tôi áp dụng là: phát hiện tài nguyên phải dẫn vào kiểm soát, không bỏ qua kiểm soát.

Đội ngũ nên kiểm thử gì trước khi dùng registry tài nguyên agent

Trước khi đưa một agent resource registry vào sản phẩm, đội ngũ nên đo chất lượng khám phá bằng tình huống thật. Hãy kiểm thử truy vấn tự nhiên, false match, tài nguyên bị lỗi thời, catalog thiếu trường, endpoint đổi phiên bản và metadata xác minh thất bại. Một registry hữu ích không chỉ trả nhiều kết quả; nó phải giúp runtime chọn đúng kết quả và giải thích vì sao một kết quả bị loại.

Tiếp theo là kiểm thử ranh giới quyền. Khi registry trả về một công cụ có vẻ phù hợp, runtime có tôn trọng chính sách bật công cụ không? Nếu Android từ chối quyền, luồng có hướng dẫn lại đúng ngữ cảnh không? Nếu hành động cần xác nhận, người dùng có thấy nội dung đủ rõ để quyết định không? Nếu endpoint thay đổi, runtime có dừng minh bạch thay vì gọi nhầm tài nguyên khác không?

Một ma trận nhỏ là đủ cho giai đoạn đầu: số lần match sai, số catalog stale, số lỗi xác minh, số lần chính sách chặn đúng, số lỗi quyền được recovery, số thao tác bị người dùng thu hồi và chất lượng nhật ký sau khi chạy. Các chỉ số này giữ hai câu hỏi tách biệt: hệ thống có tìm đúng tài nguyên không, và người dùng có thực sự cho phép hành động không.

ARD đáng chú ý vì nó làm cho thế giới công cụ, skill và agent dễ khám phá hơn. Nhưng với phone agent, giá trị chỉ trọn vẹn khi discovery đi cùng runtime có kỷ luật: endpoint được kiểm tra, công cụ được bật có chủ đích, quyền được xin trong ngữ cảnh, hành động có điểm phê duyệt và kết quả có thể xem lại hoặc thu hồi.