Agent 能被搜到？ARD：MCP/A2A 资源统一发现

你有没有遇到过这种情况：想让你的 Agent 调用一个天气 MCP Server，需要在代码里硬写 endpoint URL。换一个场景想用另一个 MCP，又得重新改配置。Agent 多了以后，管理这些资源地址本身就是个工程问题。

问题不在 MCP 或 A2A 协议本身，而是缺少一个统一的资源目录 ------让 Agent 能像 Google 找网页一样，动态找到自己能用的资源。最近，Google、Microsoft 和 Hugging Face 的工程师联手发布了一个解决方案：Agentic Resource Discovery（ARD）v0.9 草案。

一、问题在哪：Agent 生态缺少「搜索引擎」

先捋一下当前的 Agent 调用模式。你的 Agent 要用一个工具，你需要提前知道它长什么样、在哪、怎么调：

// 当前做法：手动配置每个工具
{
  "mcpServers": {
    "weather": {
      "url": "https://api.weather.com/mcp",
      "apiKey": "xxx"
    },
    "calendar": {
      "url": "https://calendar.company.com/mcp",
      "apiKey": "yyy"
    }
  }
}

这种方式在只有两三个工具时还能接受，但当 Agent 生态扩展到几千上万个能力时，手动配置的模式就彻底崩了。每个 Agent 的 tool description 塞进 LLM 上下文窗口，O(n) 增长------Token 消耗扛不住，信息检索质量也在下降。

这跟没有 Google 之前的互联网一样：网站很多，但你找不到。

二、ARD 是什么：一个搜索层的标准

ARD（Agentic Resource Discovery）是由 Google（Junjie Bu）、Microsoft（R.V.Guha）、Hugging Face（Shaun Smith） 三家联合发布的 v0.9 草案规范。核心思路其实很简单：给 Agent 资源装一个「搜索引擎」。

地址：agenticresourcediscovery.org/spec/ GitHub：github.com/ards-project/ard-spec（400+⭐）

它不是又一套新协议------它也不打算定义 MCP 或 A2A 怎么工作。ARD 做的是编织层：让不同类型的 Agent 资源（MCP Server、A2A Agent、Skill、API）能在一个统一的目录里被搜索到。

ARD 定位：
  A2A（Agent-to-Agent Protocol）→ 管 Agent 之间怎么对话
  MCP（Model Context Protocol）  → 管工具怎么被调用
  ARD（Agentic Resource Discovery）→ 管这些资源怎么被发现

三、核心设计一：搜索优先------把发现移出 LLM 上下文

当前 LLM 选工具的方式是所有 tool description 塞进 context window，靠模型自己推理选。每条 description 几百到几千 token，50 个工具就能吃掉好几万 token，而且还不可扩展------每多一个工具，消耗线性增长。

ARD 把这个「选工具」的过程彻底移出了 LLM 模型：

传统模式：
  工具 A 描述 + 工具 B 描述 + ... + 工具 N 描述 → 全塞进 LLM context
  → LLM 自己决定用哪个 → O(n) 不可扩展

ARD 模式：
  自然语言查询 → Agent Registry 搜索服务 → 返回 top-k 匹配结果
  → LLM 只需要处理 k 个候选 → O(1) 恒定查询成本

核心思路是把 Agent 选择变成信息检索问题，而非推理问题。Registry 可以利用向量嵌入、代表性查询（representative queries）、发布者身份、合规元数据等丰富信号做筛选，而且这些都不消耗 Context Token。

具体来说，每个资源条目可以附带 2-5 条代表性查询，Registry 拿这些查询做语义嵌入，搜索时直接命中：

{
  "identifier": "urn:air:acme.com:server:weather",
  "displayName": "Weather Data Node",
  "type": "application/mcp-server-card+json",
  "url": "https://api.acme.com/mcp/weather.json",
  "representativeQueries": [
    "what is the current wind speed in Chicago",
    "get the 5-day forecast for Seattle"
  ]
}

四、核心设计二：工件无关------不碰 MCP/A2A 内部

这是 ARD 最巧妙的设计决策之一。它不定义 MCP Server 或 A2A Agent 的内部数据结构------那不是它的事。它只做一个信封 ，通过 type 字段（IANA Media Type 格式）告诉你「这是什么东西」，然后把它交给对应的协议去解析：

{
  "entries": [
    {
      "identifier": "urn:air:acme.com:agent:assistant",
      "displayName": "Corporate Assistant (A2A)",
      "type": "application/a2a-agent-card+json",
      "url": "https://api.acme.com/agents/assistant.json",
      "representativeQueries": [
        "help me draft an email"
      ]
    },
    {
      "identifier": "urn:air:acme.com:server:weather",
      "displayName": "Weather Data Node",
      "type": "application/mcp-server-card+json",
      "url": "https://api.acme.com/mcp/weather.json",
      "capabilities": ["WeatherTool", "ForecastTool"]
    }
  ]
}

MCP Server 和 A2A Agent 在 ARD 的编目中地位完全平等------都用 identifier 做全局唯一标识，都走 url 或 data 二选一的交付模式。这意味着什么？你的 Agent registry 不需要分别对接 MCP 和 A2A 两套逻辑，ARD 在前面做了一层统一抽象。

五、架构拆解：怎么发布，怎么发现

ARD 定义了两层发现机制：

静态发现（Hosting）

最基础的用法：在你的域名根路径下放一个 /.well-known/ai-catalog.json 文件：

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Acme Enterprise AI",
    "identifier": "did:web:acme.com"
  },
  "entries": [
    {
      "identifier": "urn:air:acme.com:server:weather",
      "displayName": "Weather Data Node",
      "type": "application/mcp-server-card+json",
      "url": "https://api.acme.com/mcp/weather.json"
    }
  ]
}

只要你的网站有 HTTPS，任何人都能通过 https://acme.com/.well-known/ai-catalog.json 发现你提供的 Agent 能力。

动态发现（Registry API）

生产环境需要更高级的搜索能力------自然语言查询、结构化过滤、联邦搜索。Agent Registry 必须暴露两个 REST 端点：

POST /search   → 自然语言 + 过滤器查询，返回相关的结果
POST /explore  → 浏览式发现，无需精确查询

查询请求长这样：

POST /search
{
  "query": {
    "text": "find me a flight booking agent",
    "filter": {
      "type": ["application/a2a-agent-card+json"],
      "tags": ["finance"]
    }
  },
  "federation": "referrals",
  "pageSize": 5
}

DNS 发现

还有一个有意思的机制：通过 DNS SVCB 记录直接指向 Agent Registry。这意味着你的 Agent 可以在网络层就被发现------不用先知道域名，DNS 解析时直接把 Registry 地址返回给你：

_index._agents.example.com 3600 IN SVCB 1 agent-search.example.com

六、生态定位：ARD + A2A + MCP 三层互补

这三个规范不是竞争关系，是三层分工：

层级	协议	解决什么问题
发现层	ARD	怎么找到可用的 Agent / MCP / Skill
交互层	A2A	Agent 之间怎么对话协作
执行层	MCP	Agent 怎么调用外部工具

你现在看 MCP 的「手动配置 endpoint」模式，就是缺了最外层的发现能力。ARD 补上这一层后，一个完整的 Agent 调用链路从「手动写配置 → Agent 调用 MCP」变成「Agent Registry 搜索 → 自动匹配 → Agent 调用 MCP」。

七、上手：在你的项目里接入

目前 ARD v0.9 还是草案阶段，但基础接入方式已经可以用了。

如果你是 Agent 发布方 （有一个 MCP Server 或 A2A Agent 要公开）：在你的域名下放一个 /.well-known/ai-catalog.json，用 URN 格式 urn:air:<你的域名>:<命名空间>:<名称> 做标识。

如果你是 Agent 使用方 （需要动态发现可用资源）：对接任意一个实现了 ARD 的 Registry，通过 POST /search 查询你要的能力。

如果你想运行一个 Registry ：参考 GitHub 上的 Agent-Field/agentic-resource-discovery-lab 项目，那里有一个基于 ClickHouse 的实操示例，演示两个组织之间的跨域数据查询场景。

一个最简单的 solo developer 示例：

// https://alice-dev.github.io/.well-known/ai-catalog.json
{
  "specVersion": "1.0",
  "host": { "displayName": "Alice's AI Tools" },
  "entries": [
    {
      "identifier": "urn:air:hf.co:alice-dev:weather-agent",
      "displayName": "Weather Agent",
      "type": "application/mcp-server-card+json",
      "data": {
        "name": "Weather Agent",
        "tools": [{
          "name": "get_weather",
          "inputSchema": {
            "type": "object",
            "properties": { "city": { "type": "string" } },
            "required": ["city"]
          }
        }]
      }
    }
  ]
}

只要托管在 GitHub Pages 上，别人就能通过你的 GitHub Pages 域名发现你这个天气 Agent。

八、结束：Agent 生态下一步

ARD v0.9 传递了一个很明确的信号：Agent 生态正在从「手动装配」走向「自动发现」。Google、Microsoft、Hugging Face 三家联合推动，说明这不是概念验证，而是进入生产可用的阶段。从搜索架构、URN 标识、信任绑定到 DNS 发现，整套体系已经比较完整。

当然，v0.9 仍是草案------IANA Media Type 注册还在进行中，注册中心的互操作性也等待更多 Registry 接入验证。但方向已经很清晰了：乱长的 Agent 需要被「搜得到」。

• 项目地址在 github.com/ards-project/ard-spec
• 规范文档在 agenticresourcediscovery.org/spec
• 上手教程在 github.com/Agent-Field/agentic-resource-discovery-lab

不是 MCP 不够好，不是 A2A 不够快------是缺一个让它们能被找到的搜索引擎。如果哪天你的 Agent 也能自动发现天气服务、日程管理、代码审查工具，而不是每次手动配 endpoint，你再回头看这个标准，会发现问题的答案早就在那里了。未来 Agent 生态能长多大，很可能取决于资源能不能被简便地找到。