Agentic Resource Discovery 智能体资源发现：ai-catalog.json、可信目录与手机授权边界

先回答：ARD 解决的是智能体资源在哪里、由谁发布、如何连接

Agentic Resource Discovery 智能体资源发现，简称 ARD，解决的不是“让智能体自动做事”，而是“让智能体以可验证的方式找到可用资源”。根据 Google Developers Blog 对 ARD 的发布说明，这项开放规范在 2026 年 6 月 17 日公布，用于在 Web 上发布、发现和验证工具、技能与智能体。换成手机智能体的语言，ARD 更像能力地址簿和信任线索系统：它告诉客户端某个组织公开了哪些能力、这些能力通过什么协议连接、发布者身份如何验证。

ai-catalog.json 是这个思路里的关键文件名。一个组织可以把目录放在自己的域名下，让外部智能体、注册表或合作方读取。目录里的条目不是最终授权书，而是能力说明：这里有一个工具、一个技能、一个智能体，或者另一个目录；它可能暴露 MCP、A2A、OpenAPI 这样的连接信息，也可能带有发布者验证元数据。读者最应该抓住的一点是：ARD 先把“可发现性”和“连接线索”标准化，后面的执行仍要走资源自己的原生协议和本地运行时策略。

过去很多 AI 智能体资源发现依赖私有集成、手写插件列表或闭环市场。这样的方式短期可用，但跨组织、跨协议、跨平台时会迅速变复杂。ARD 的价值在于把发现动作放回发布者域名和可索引目录中，让资源可以被检索、比较和验证。它让智能体知道“哪里可能有能力”，但不会替用户决定“是否应该调用这个能力”。

目录和注册表如何发布、索引与发现能力

理解 ARD 时，可以把流程拆成四步：发布、发现、验证、连接。发布阶段，资源提供方在自己的域名下放置 ai-catalog.json 工具目录，列出工具、技能、智能体或嵌套目录。发现阶段，客户端可以直接抓取一个已知合作方的目录，也可以向注册表提出自然语言或结构化意图查询。验证阶段，客户端查看发布者身份、目录完整性和元数据。连接阶段，客户端再根据目录中声明的 MCP、A2A、OpenAPI 或其他接口进入真正调用。

ARD 公开规范与仓库说明了规范、schema、信任架构和参考实现方向，并以 Apache-2.0 许可公开演进。对于产品团队，这意味着 ai-catalog.json 工具目录不应该被设计成“一个神奇总线”。它更像能力元数据文件：条目说明资源名、用途、接口、认证提示、发布者信息、版本或嵌套目录。注册表的角色是爬取、索引和返回匹配结果，同时附带验证信息；它不是执行代理，也不应该替运行时绕过策略。

目录和注册表的区别也很实际。目录由资源发布者控制，适合表达“我们提供什么”。注册表索引多个目录，适合回答“哪个资源可能符合这个意图”。如果你已经信任某个合作方，直接读取其域名下的目录更明确；如果你要跨网络寻找能力，注册表搜索更灵活。两条路径都需要后续验证和本地策略，而不是找到条目就执行。

发布者验证能证明什么，也不能证明什么

可信智能体工具目录首先要解决身份问题。生产级发现可以在连接前包含可加密验证的发布者元数据，这能帮助客户端判断目录是否来自声明的组织、目录是否被篡改、资源入口是否与发布方绑定。相比口头复制一个工具地址，这一步让智能体少依赖硬编码白名单和人工粘贴链接，也降低了被冒名目录误导的概率。

但身份可信和行为可信不是同一件事。一个目录确实由某家公司发布，并不说明它的每个能力都适合当前用户、当前账号、当前手机任务或当前风险级别。发布者验证无法替你完成端点兼容测试，也不能判断某个 OpenAPI 操作是否会产生外部后果，更不会给 Android 应用授予联系人、位置、通知或文件访问权限。换句话说，验证回答“是谁发布的”，执行治理回答“这次能不能做、能做到哪一步、谁来确认”。

在手机智能体里，这个区别尤其关键。恶意冒名会带来连接风险，真实但过宽的能力也会带来操作风险。一个可信目录可能包含读取型工具、写入型工具、支付或消息发送类能力；它们的风险等级不同，用户期望也不同。因此，验证成功之后还要做能力范围、协议兼容、权限需求、审批策略和结果可见性检查。可信目录是入口，治理规则才是通往真实动作的门。

ARD 如何交给 MCP、A2A、OpenAPI 和应用调用契约

ARD 不替代 MCP、A2A 或 OpenAPI。它的工作是帮助客户端发现这些能力在哪里、由谁发布、用什么接口连接；真正通信仍走目录条目声明的原生协议。一个目录可以告诉客户端“这里有 MCP 服务器”，也可以指向 A2A 智能体、OpenAPI 工具或另一个目录。连接之后，参数格式、认证方式、错误响应、流式输出、工具调用语义，仍由对应协议或应用契约决定。

这对手机场景有直接影响。即使 ARD 发现了某个移动能力，Android 侧仍然需要一个可调用的契约：可能是系统权限下的本地工具，可能是 App Intents 类的应用动作描述，也可能是厂商服务提供的 API。想深入理解应用如何从“人点界面”走向“机器可调用”，可以继续看 App Intents、可被机器调用的应用和手机 AI Agent：普通用户该看什么，那篇文章聚焦的是发现之后的应用调用契约。

协议交接还需要校验。客户端要确认端点版本、认证方式、输入 schema、输出结构、错误处理和速率限制；手机运行时还要确认这项能力是否映射到受支持动作。发现到一个“发送消息”能力，并不等于它知道手机联系人是谁、当前用户想发给谁、内容是否已经确认。ARD 让资源更容易被找到，原生协议让资源可连接，本地运行时让动作可控。

为什么在手机上，发现不等于授权

手机智能体工具目录安全的核心问题，是不要把“看到工具”误读成“可以执行”。手机是私人设备，动作往往连接联系人、账号、位置、文件、通知、支付、邮件和社交应用。ARD 或 ai-catalog.json 工具目录可以提供资源元数据，但真正落到 Android 手机时，还要经过本地启用、协议校验、系统权限、目标确认、风险审批、结果展示和撤销路径。

Android 运行时权限指南强调，应用应在功能需要时按上下文请求权限，并处理用户拒绝权限的情况。这说明 Android 权限本身也是独立层：它解决的是某个应用是否可以访问某类设备能力，而不是远程发布者是否可信，也不是某个业务动作是否应该发生。比如位置权限可以允许读取定位，但并不自动批准“把当前位置发给某人”；通讯相关权限也不等于用户同意发送某条具体消息。

这也是为什么“工具发现与授权区别”不是抽象安全话题，而是手机产品体验问题。用户希望智能体快一点找到能力，也希望它在关键处慢下来让人看见。关于技能本身为什么不能只靠安装前扫描，可以参考 AI Agent 技能安全：为什么手机 Agent 不能只靠安装前扫描；如果你要看身份、权限与活动记录的完整栈，AI Agent 身份、权限与审计轨迹：手机智能体真正需要的安全栈会把治理面展开得更细。

发现资源后的连接前与执行前检查清单

发现资源之后，手机智能体不应该直接进入高风险动作。更稳的做法是把检查分成连接前和执行前两段。连接前关注“这个资源能不能进入我的运行时”；执行前关注“这次动作能不能在这台手机、这个账号、这个目标上发生”。两段都通过，才适合把模型规划推进到真实手机步骤。

1. 确认发布者：核对目录域名、发布者元数据、签名或注册表返回的验证信息。
2. 检查目录新鲜度：看版本、更新时间、嵌套目录和废弃标记，避免调用过期入口。
3. 验证协议：确认 MCP、A2A、OpenAPI 或应用契约的 schema、认证、错误处理和速率限制。
4. 限定范围：只启用当前任务需要的工具或能力，不把整个目录一次性开放给运行时。
5. 从低风险任务开始：先测试读取、解释或模拟计划，再进入写入、发送、控制设备等动作。
6. 核对动作目标：联系人、应用、文件、时间、位置、账号和内容必须能被用户看见。
7. 应用审批策略：外部影响、敏感读取、设备控制和破坏性动作应按策略进入确认或拒绝流程。
8. 记录结果：执行后展示可见结果、失败原因、重试建议和可追溯活动。
9. 准备撤销：支持停用工具、移除插件、回滚配置、撤销权限或切换到手动操作。

这份清单的价值在于让“发现”保持轻量，让“执行”保持可控。注册表可以帮助你更快找到候选资源，但不能替你理解用户意图和设备状态。一个优秀的手机智能体会在模型计划、工具策略和用户确认之间保持清晰路径，而不是把所有外部资源都当成默认可用能力。

FoneClaw 如何把目录可见性和手机权限分开

在 FoneClaw，我们把“看见有哪些工具”和“允许手机执行什么动作”分开设计。FoneClaw 是 Android 手机智能体运行时：配置的兼容模型负责理解、推理和规划，FoneClaw 调用受治理的 Android 工具完成支持范围内的动作。这个设计让模型可以提出计划，但具体工具是否启用、是否需要权限、是否要确认、失败后如何恢复，由运行时策略承接。

根据 FoneClaw 2026 年 8 月 1 日读取的发布数据，0.1.0 增加了按工具搜索、启用控制、审批覆盖、权限恢复和更稳的工具契约，也推进了受信插件的安装与继续执行流程。FoneClaw 当日公开工具目录快照显示，公共内置工具目录覆盖 100+ 工具，并带有风险和审批标签。我们在持久文案里使用 100+，因为精确数量会随产品目录演进；当需要精确审计时，再以日期快照为准。

这不是 ARD 实现声明。更准确的说法是：FoneClaw 当前的受治理目录可以帮助读者理解手机运行时需要哪些本地控制。插件安装从可见提案开始，内置工具和签名插件路径分开，权限在任务需要时引导，结果要展示给用户。对于想把自然语言目标变成 Android 动作的读者，AI Agent 手机控制指南：Android 手机 Agent 真正应该怎么工作提供完整的手机执行模型；本页重点是说明，在任何资源发现机制之后，手机权限和动作审批仍然要由本地运行时管理。

一个具体例子是“发现了一个日程相关能力”。目录可以告诉智能体它存在，协议可以告诉客户端怎样连接，模型可以规划“读取日程、生成提醒、准备通知”。FoneClaw 的职责是判断相应 Android 工具是否受支持、是否已启用、是否需要系统权限、用户是否要确认提醒时间和内容，以及失败时如何回退。这样，能力可见不会自动变成手机权力。

团队采用智能体资源注册表前应测试什么

如果团队准备采用 ARD 或智能体资源注册表，不要只测试“能不能搜到工具”。真正有用的评估要覆盖发现质量、信任元数据、协议交接、本地策略和恢复能力。一个注册表返回很多资源并不一定更好；如果误匹配高、目录过期、验证失败时提示不清、策略拒绝不可解释，用户最后仍然无法安全完成任务。

最终判断很简单：ARD 适合让资源更容易被发现、验证和连接；手机智能体运行时负责让动作变得可见、可控、可恢复。把这两件事拆开，团队才能同时获得开放生态的发现效率和手机端的操作治理。对于高风险或外部影响强的能力，先做低风险连接测试，再进入权限和审批流程，是比追求一次性全自动更可靠的采用路径。