MCP 漏了一步：代理资源发现（ARD）与「代理的 DNS」

连接一个 AI 代理到工具相对直接：写个 MCP 服务器、声明工具、让模型调用。但当组织拥有数百个跨云、SaaS 平台和内部系统的工具时，事情就变复杂了。MCP 已成为 AI 应用连接外部工具和数据的常用方式，但它假设客户端已经知道要用哪个服务器。ARD（Agent Resource Discovery，代理资源发现）解决了连接之前的这一步：让代理在使用资源之前先找到它。规范用「agentic resource」指代任何 AI 客户端可以连接的东西，从 MCP 服务器到其他外部能力。一个兼容 ARD 的服务跟踪可用的资源，而不是要求开发者预先建立每个连接。

1. 为什么 MCP 漏了一步

MCP 解决的是「如何连接」：协议、工具契约、调用方式。它没有解决「连接什么」：当公司的基础设施分布在多云、SaaS 平台和内部系统上时，客户端怎么知道该用哪个服务器？现在的答案是人工配置——把每个连接的地址写死在代码或配置里。组织越大，这个负担越重。ARD 补上发现层：代理先搜索需要的资源，再通过资源声明的协议（通常是 MCP）连接。AWS 在 8 月 31 日的 Weekly Roundup 中重点介绍了这个开放规范，称之为「代理的 DNS」。

// The gap MCP leaves open: MCP assumes the client already
// knows which server it wants to use. ARD adds discovery
// BEFORE connection -- an agent searches for a resource it
// needs instead of being told where everything is.
// ARD v0.91 (2026-08-26) uses JSON-LD over a REST
// interface. The required endpoint searches by task.
POST /search
{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "SearchRequest",
  "task": "summarize incident JIRA-4421",
  "constraints": {
    "privacy": "internal-or-approved-external",
    "maxResults": 5
  }
}

2. 谁在推动 ARD

尽管 AWS 重点介绍了这个项目，ARD 并不是 AWS 的技术。它由 Google 的 Junjie Bu、Microsoft 的 R.V. Guha 和 Hugging Face 的 Shaun Smith 撰写，以 Apache 2.0 许可发布。来自 Cisco、Databricks、GitHub、GoDaddy、Nvidia、Salesforce、ServiceNow 和 Snowflake 等公司的工程师参与了塑造。AWS 目前的角色是提供规范反馈，并探索它如何与自己的 Agent Registry 协作。有趣的是，AWS 8 月 24 日那篇 ARD 文章的两位作者与 Route 53 关系密切——一位主攻 DNS 和网络技术，另一位负责 Route 53 以及 AWS Agent Registry 中的代理身份与发现的产品管理。

// A discovery service response: several options that all
// appear capable of doing the job. Unlike DNS, a domain
// name points to one location, while an ARD search can
// turn up multiple candidates -- the agent picks.
{
  "type": "SearchResponse",
  "results": [
    {
      "id": "https://registry.acme.dev/agents/incident-summarizer",
      "name": "Incident Summarizer",
      "protocol": "mcp",
      "capabilities": ["summarize", "classify", "triage"],
      "trust": "internal",
      "policy": "requires-human-approval-for-send"
    },
    {
      "id": "https://registry.acme.dev/agents/ops-assistant",
      "name": "Ops Assistant",
      "protocol": "mcp",
      "capabilities": ["summarize", "runbook-lookup"],
      "trust": "internal"
    }
  ]
}

3. 核心设计：JSON-LD + REST

当前 v0.91 提案（2026 年 8 月 26 日）使用 JSON-LD 和 REST 接口。必需的 POST /search 端点按任务搜索，可选端点允许客户端浏览可用资源。每个发现服务可以自行设定返回什么、信任哪些来源。这也是 DNS 类比失效的地方：域名指向一个特定位置，而 ARD 搜索可能返回几个看起来都能胜任的选项——代理需要根据能力、信任和策略挑选。企业可以保留自己的目录和策略，同时在需要时把搜索路由到其他兼容 ARD 的服务：内部资源保持私有，外部目录只在必要时查询。AWS 称之为「describe once, discover everywhere」（描述一次，处处发现）。

// Describe once, discover everywhere: an enterprise keeps
// internal resources private while routing searches to
// approved external catalogs when needed. Each discovery
// service sets its own rules for what it returns and
// which sources it trusts.
{
  "registry": {
    "internal": {
      "visibility": "private",
      "publish": "service mesh auto-registers capabilities"
    },
    "federation": {
      "trustedCatalogs": [
        "https://catalog.partner-a.dev/ard",
        "https://catalog.partner-b.dev/ard"
      ],
      "policy": "internal first, external only when
                 no internal match"
    }
  }
}

4. 对开发者的意义

ARD 把「注册表」从静态配置变成动态基础设施。对平台团队来说，这意味着服务网格可以自动注册能力，而不是维护一份手工更新的工具清单。对代理开发者来说，这意味着不再需要预先知道每个工具的位置——写一个发现客户端，按任务搜索，按信任和策略过滤，然后连接。AWS Agent Registry 已经给 AWS 客户一个资源的中心视图；接入 ARD 后，可以把运行在其他地方的资源也带入这个视图，而不要求公司把所有东西都注册到 AWS。

5. 代码实战：搜索契约、客户端与联邦

本文的代码块把规范拆开：代码块一是 ARD 的 POST /search 请求——JSON-LD 上下文、任务描述、隐私与数量约束；代码块二是发现响应——多个候选资源，各带协议、能力、信任级别和策略；代码块三是注册表联邦配置——内部私有、外部可信目录、内部优先策略；代码块四是最小发现客户端——跨注册表搜索、按信任和能力排序、通过资源声明的协议连接；代码块五是治理时间线——作者、贡献者、许可和下一步（移交 W3C 或 AI 基金会）。

// A minimal ARD discovery client: search across
// registries, filter by trust and capability, then connect
// via the protocol the resource speaks (usually MCP).
async function discover(task, constraints) {
  const registries = await registryList();
  const results = [];
  for (const reg of registries) {
    const res = await fetch(reg + "/search", {
      method: "POST",
      headers: { "Content-Type": "application/ld+json" },
      body: JSON.stringify({ task, constraints }),
    });
    results.push(...(await res.json()).results);
  }
  return rankByTrustAndCapability(results, task);
}
// AWS highlighted ARD in its August 31 Weekly Roundup,
// describing the idea as "DNS, but for agents."

6. 尽早统一，避免碎片化

治理仍在推进中，董事会任期和成员资格等细节尚未确定。小组讨论过最终把项目移交给 W3C 或某个 AI 基金会等中立组织。留给统一方案的时间可能不多了：一旦公司各自建好自己的发现系统，再把这些目录连接起来只会更难。对开发者个人的建议：关注 ARD 规范进展，在你自己的代理工作流里用「按任务发现资源」的模式替换硬编码的工具地址，哪怕只是内部的简单注册表。方向很清晰——连接是协议问题，发现是目录问题，两者都需要标准。

// Governance note: ARD's governance is still being worked
// out. The group has discussed eventually moving the
// project to a neutral organization such as the W3C or an
// AI foundation -- and there may not be much time to
// settle on a common approach, since connecting all these
// directories will only get harder once companies have
// built their own discovery systems.
const ARD_TIMELINE = {
  "v0.91": "2026-08-26 (JSON-LD + REST, POST /search)",
  "authors": ["Junjie Bu (Google)", "R.V. Guha (Microsoft)",
              "Shaun Smith (Hugging Face)"],
  "license": "Apache 2.0",
  "contributors": ["Cisco", "Databricks", "GitHub", "GoDaddy",
                   "Nvidia", "Salesforce", "ServiceNow", "Snowflake"],
  "next": "board terms, membership, neutral home (W3C / AI foundation)"
};