Google 在 2026 年 6 月 17 日公布 Agentic Resource Discovery，简称 ARD。这是一个开放规格，目标是让 AI agent 可以在网络上发现、验证和连接工具、skills、其他 agents、MCP servers、OpenAPI tools 以至 nested catalogs。它处理的不是模型本身，而是 agentic web 缺少的一层：能力在哪里、应该用哪个、是否可以安全连接。
这个问题会愈来愈重要。当 agent 只是在一个平台内使用固定工具，平台自己的 registry 已经够用。但如果一个 operations agent 要处理生产事故，它可能需要查 observability 系统、工程文件、deployment history、support tickets，甚至交给另一个 troubleshooting agent。这些能力通常分散在不同团队、供应商和云平台，没有共同发现方法。
ARD 的核心设计是 catalogs 和 registries。Catalog 是由组织放在自己 domain 下的描述文件，列出可用能力和连接资讯；因为它由 organization domain 发布，domain ownership 会成为身份和信任的基础。Registry 则像 agentic web 的搜索引擎，负责 crawl catalogs、建立索引，并在 agent 查询时回传合适能力与验证 metadata。
这个设计重要的地方，是 discovery layer 不尝试取代每个工具原本的 protocol。ARD 只负责让 agent 找到能力、确认发布者身份和信任资料，之后再交回原生 protocol 或 API 直接连接。这与 MCP、A2A 或 OpenAPI 的关系比较像「搜索与信任入口」，而不是另一套要取代所有东西的 runtime。
Google 亦特别强调 cryptographic verification。生产环境的 agent 不能只因为搜索结果看起来相关就连接。ARD 让 publisher 附上可验证 trust metadata，client agent 或 registry 可以确认 publisher 的真实 cryptographic identity。当 agent 会接触企业资料、执行工作流或触发外部操作，这类身份验证会变成基本要求。
另一个重点是 Gemini Enterprise Agent Platform 的 Agent Registry。Google 表示 Agent Registry 会支持搜索、发现和 hosting agentic resources，包括 agents、skills、MCP servers 和其他 tools，并会通过 globally unique namespaced URNs、agentic egress policies、spec pinning 和 Agent Identity 来支持企业治理。
ARD 的出现说明 agent 生态正在由单一应用，走向更像 web 的分布式架构。过去网站靠搜索引擎、DNS、TLS 和标准化 metadata 形成可互通的网络；agentic web 也需要类似基础件，否则每个 agent 都会被困在单一平台和私有 registry 里。
对企业而言，ARD 的意义不只是又多一个规格，而是提醒大家 agent 治理不能只做在模型层。真正落地时，还要知道能力由谁提供、版本是否被 pin、哪些外部连接被允许、身份能否验证，以及 discovery 结果是否可审计。这些问题会直接决定 agent 能否由 demo 走向生产环境。
