Agent 越来越像一个会找资源的执行者。它不只调用本地工具，还可能跨团队查系统、找文档、连接 MCP 服务，甚至请另一个 Agent 协作。问题也随之出现：能力在哪里，哪个能力适合当前任务，连接前怎么确认对方可信。
Google Developers Blog 在 2026 年 6 月 17 日发布 Agentic Resource Discovery specification，提出一个开放规范，用于发布、发现和验证 Web 上的 AI 能力。文章提到，ARD 可以描述 MCP servers、A2A agents、OpenAPI tools 等资源，并通过目录和注册表帮助 Agent 找到合适能力。
事实梳理
ARD 的两个核心对象是 catalogs 和 registries。组织可以在自己的域名下发布 catalog，描述可用工具、技能或 Agent；registry 则像面向 Agent 的搜索引擎，索引这些 catalog，并在发现请求中返回匹配能力和可信元数据。
Google 还提到，Gemini Enterprise Agent Platform 中的 Agent Registry 会支持搜索、发现和托管 agentic resources，并承担企业治理能力，包括命名空间 URN、出站策略、工具和规范固定，以及通过 Agent Identity 和 trust manifest 做可信验证。
影响分析
这件事的信号很清楚：Agent 生态不会只靠单个平台内部的工具列表。未来跨组织、跨协议、跨团队的能力发现会变多，目录、注册表、身份和信任元数据会成为新的基础层。
对企业来说，最直接的影响是连接边界要前移。Agent 发现了一个工具，不代表就可以直接用。团队仍然要接上 工具白名单、权限矩阵 和 审计日志字段，把发现、授权、调用和复盘分开管理。
老达点评
我觉得 ARD 的价值不在于又多了一个名词，而在于它把 Agent 找资源这件事从“手工配置”推向“可发现、可验证、可治理”。这和 MCP、A2A 的关系也更清楚：协议负责怎么连接和协作，ARD 更像告诉 Agent 去哪里找、找到后怎么判断可信。
普通团队短期内不一定要自己做 registry，但可以先学它的思路：内部工具要有清晰目录，说明用途、权限、负责人、输入输出和停用条件。没有目录的工具越多，Agent 越容易接错地方。
总结
Google 推 Agentic Resource Discovery，说明 Agent 工具发现正在进入目录化和验真阶段。发现能力只是第一步，能否可信连接、按权限调用、留下审计记录，才决定它能不能进入生产。
