30 秒快速回答
ARD（Agentic Resource Discovery，智能体资源发现）是给 AI Agent 用的一层「发现协议」：让智能体在运行时自己去找、去核验、去连接它所需要的工具、技能和其它智能体，而不是靠工程师把每个接口硬编码进去。
它的核心价值一句话：MCP 解决「怎么调用」，A2A 解决「怎么对话」，ARD 解决「去哪儿找、凭什么信」——三者拼起来，Agent 生态才真正具备跨组织互通的能力。
由 Google、Microsoft 牵头，联合 GitHub、Hugging Face、NVIDIA、Salesforce、ServiceNow、Snowflake、Databricks、Cisco 等十余家企业共同发布，2026 年 6 月 17 日公开首版，Apache 2.0 许可，数据模型沿用 Linux 基金会维护的 AI Catalog，目前为 v0.9 草案。
一、先看清缺口：Agent 只能用「被接线过的能力」
过去两年 Agent 的能力建设都在协议层：MCP 统一了工具调用的接口形态，A2A 统一了智能体之间的通信方式。但一个真实的生产问题始终悬着——能力在哪里？
微软的 Ramanathan Guha 有句被反复引用的话：「AI 只能使用它被显式接线使用的东西，其余的一切对它来说等于不存在。」
三个绕不开的问题：
| 问题 | 现状做法 | 代价 |
|---|---|---|
| 能力在哪儿 | 每个集成都手工写死 endpoint | 接一家工具写一天代码 |
| 该用哪个 | 靠人读文档判断 | 换模型、换场景就得重选 |
| 是否安全 | 只能看域名和口碑 | 无法在运行时验证发布方身份 |
二、两个原语：目录（Catalog）与注册表（Registry）
ARD 的架构非常克制，只定义了两样东西。
目录（Catalog）：组织在自己域名下的固定路径托管一个 ai-catalog.json，声明自己对外提供哪些能力——MCP Server、A2A Agent、OpenAPI 工具，甚至是嵌套的下一级目录。文件挂在自家域名下，域名所有权本身成了身份与信任的密码学基础，与 ANS（Agent Name Service）思路一脉相承。
注册表（Registry）：可以理解为智能体世界的搜索引擎。它抓取、索引各家发布的目录，对外提供检索端点。Agent 用一句自然语言意图去问，注册表返回匹配的能力清单，外加用于核验发布方的信任元数据。
目录文件的结构示意（字段以 v0.9 规范为准）：
{
"publisher": "example.com",
"capabilities": [
{
"type": "mcp-server",
"name": "invoice_query",
"description": "查询企业发票与报销记录",
"endpoint": "https://mcp.example.com/invoice",
"auth": "oauth2"
},
{
"type": "a2a-agent",
"name": "tax_advisor",
"description": "税务合规问答智能体",
"endpoint": "https://agent.example.com/.well-known/agent.json"
}
],
"trust": { "manifest": "https://example.com/trust.json" }
}
type 只描述「是什么、连哪儿、怎么认证」，不强制具体协议。
三、四个阶段：从发现到直连
一个 ARD 客户端跑完一次能力获取，通常走四步：
- 发布目录——服务方把
ai-catalog.json放到自家域名的约定路径，纳入目录管理。 - 发现与解析——客户端两种取法：查注册表（按意图语义检索，注册表负责主动爬取索引），或直接抓已知合作方域名的目录，跳过检索。
- 密码学校验——连接之前，客户端核验发布方真实身份。信任元数据在这一层附着，生产环境不允许跳过。
- 原生协议直连——核验通过后，ARD 立刻退出。后续对话与调用走的是能力方自己的原生协议（MCP、A2A、OpenAPI……），发现层不产生任何运行时开销。
第四步是最聪明的取舍：发现层只做快递员，不做中间人——不代理流量、不改协议、不驻留数据，不会成为新的单点和瓶颈。
四、生态现状：谁已经在跑了
| 参与方 | 已落地动作 |
|---|---|
| GitHub | Agent Finder for Copilot：用自然语言描述任务，从公开目录或企业内部注册表返回排序结果 |
| Hugging Face | Discover Tool：对 Hub 上数千个 Skill 与 MCP Server 做语义搜索 |
| Gemini Enterprise Agent Platform 的 Agent Registry 将原生支持 ARD，提供全局唯一 URN、出口策略（egress policy）、HIPAA 等合规能力 | |
| 规范本身 | Apache 2.0 许可，GitHub 仓库公开征集反馈，官网提供发布首个目录的 quickstart |
信号很清楚：行业选择用一层标准化发现层来解决「工具越多越难管」，而不是让每家框架各自维护 MCP 清单。
五、现在该做什么：三条落地动作
不必等定稿（v0.9 到 1.0 字段仍可能变），但有三件事现在做不会白做：
- 把能力清单结构化成一份 JSON。先做到「一个文件说清有哪些工具、入口在哪、怎么认证」，这是所有发现机制的地基。
- 把身份和域名绑好。ARD 的信任模型建立在域名控制权上，能力和主域名脱钩、靠第三方短链托管的做法，会在这一层吃亏。
- 在 Agent 侧预留「动态发现」接口。别把工具列表写死，留出可按意图检索能力的抽象层——注册表就位时只换实现，不改架构。
六、三个容易踩的坑
| 坑 | 表现 | 解法 |
|---|---|---|
| 把 ARD 当 MCP 替代 | 以为要重构所有 MCP Server | 二者是叠加关系：ARD 在前，MCP 在后 |
| 校验环节图省事 | 为调试方便直接跳过信任核验 | 只在开发环境关闭，生产必须校验，否则等于开放任意端点接入 |
安全提示：发现层天然是新的攻击面——注册表被污染时，Agent 可能被引导连接到伪装成正规服务的端点。这与《MCP 工具中毒》《记忆投毒》属同类风险：「能被发现」也意味着「能被投毒」，校验不可省。
总结
- ARD 是智能体互联的发现层：MCP 管调用、A2A 管通信、ARD 管「找到并核验」。
- 架构只有两个原语：域名下托管的目录 + 做索引的注册表。
- 流程四阶段：发布 → 发现 → 校验 → 原生协议直连，发现层在连接建立后即退出。
- 现在最值得做的不是等定稿，而是把能力清单结构化、把身份绑到自有域名。
延伸阅读建议：先用《什么是 MCP 协议？一文读懂 AI 的 USB 接口标准》和《什么是 A2A 协议？Agent 之间的 TCP/IP 标准全解析》补齐前两层，再用《什么是 MCP Gateway？企业级 AI 工具链安全网关基础设施全解析》把企业侧统一管控补上。