ARD 开放标准：AI Agent 的「HTTP 时刻」来了

2026 年上半年，AI Agent 开发面临一个尴尬的现实：模型能力越来越强，但 Agent 之间的互操作性几乎为零。

碎片化的现状

每个平台都在建造自己的围墙花园：

• Microsoft Copilot 的 Agent 无法直接调用 Salesforce Agentforce 的工具
• Google Vertex AI 上部署的 Agent 发现不了 Databricks 上的数据服务
• 企业内部同一个能力被不同部门用不同框架重复实现 3-5 次
• 开发者每接入一个新平台，就要重写一套集成代码

这不是技术问题，是生态问题。就像 1990 年代初期，各家 BBS、CompuServe、AOL 各自有自己的通信协议——直到 HTTP 统一了 Web。

为什么模型厂商不解决这个问题？

OpenAI、Anthropic、Google 都在做自己的 Agent 框架（Assistants API、Claude Tool Use、Vertex AI Agent Builder），但它们的商业利益决定了它们希望开发者留在自己的生态里，而不是跨平台互操作。

这就是为什么 ARD 的出现如此重要——它不是由一家公司主导的封闭标准，而是由 11+ 行业巨头联合发布的开放规范。

ARD 的设计哲学是极简 + 去中心化——它借鉴了 DNS 和 Web 的成功经验，让任何 Agent 都能像访问网页一样发现全球的能力。

核心概念 1：Catalog（能力目录）

任何服务提供者只需在自己的域名根目录放一个 ai-catalog.json 文件，就能向全球 Agent 宣告自己提供的能力。

Catalog 文件的核心结构包含：version（版本号）、provider（提供者名称）、capabilities 数组（能力列表）。每个 capability 包含 id、name、description、inputSchema、outputSchema、auth 和 pricing 字段。

关键设计决策

• 基于 DNS 的信任：域名所有权 = 身份验证。不需要中心化 CA 机构
• 自描述：每个能力自带 input/output schema，Agent 可以直接理解如何调用
• 去中心化：没有中心服务器，catalog 文件就在你自己的域名上

核心概念 2：Registry（注册索引）

Registry 是 Agent 的「搜索引擎」——它爬取全球发布的 catalog 文件，建立可搜索的索引。

工作流程： Agent 发出意图（如「我需要一个能分析文本情感的工具」）→ Registry 语义匹配全球 catalog → 返回能力描述 + 调用端点 + 认证方式 → Agent 直接调用服务端点。

Registry 不中转流量——它只负责「发现」。实际的 API 调用是 Agent 直接与服务提供者之间进行的。

为什么这个架构能成功？

{
  "version": "1.0",
  "provider": "Example Corp",
  "capabilities": [
    {
      "id": "sentiment-analysis",
      "name": "情感分析 API",
      "description": "分析文本的情感倾向（正面/负面/中性）",
      "inputSchema": { "type": "string", "description": "待分析文本" },
      "outputSchema": {
        "type": "object",
        "properties": { "sentiment": { "type": "string" } }
      },
      "auth": "oauth2",
      "pricing": "free-tier:100/day"
    }
  ]
}

很多开发者问：ARD 和 MCP、A2A 是什么关系？是竞争还是互补？

答案是：它们解决不同层次的问题，是互补关系。

三层协议栈

具体协作流程

一个完整的跨平台 Agent 协作场景分为三步：

第一步（ARD 发现）： Agent A 通过 ARD Registry 发现 Agent B 提供「翻译」能力

第二步（A2A 协商）： Agent A 通过 A2A 协议向 Agent B 发起协作请求

第三步（MCP 执行）： Agent B 内部通过 MCP 调用具体的翻译工具完成任务

关键区别：

• ARD 不关心你怎么调用工具——它只告诉你「谁有什么能力」
• MCP 不关心你怎么找到工具——它假设你已经知道要调用什么
• A2A 不关心工具细节——它只负责 Agent 间的消息传递

为什么不是「一个协议解决所有问题」？

因为关注点分离是工程的基本原则。HTTP 只负责传输，不负责服务发现（那是 DNS 的事），也不负责数据格式（那是 JSON/XML 的事）。分层让每一层可以独立演进。

ARD 的参与方名单堪称豪华：Google、Microsoft、Cisco、Databricks、GitHub、GoDaddy、Hugging Face、NVIDIA、Salesforce、ServiceNow、Snowflake。

为什么这些竞争对手能坐在同一张桌子？

因为 Agent 互操作性的「蛋糕」远大于各自围墙花园的收益。

行业调研显示：

• 跨平台集成是企业 Agent 部署的头号痛点
• 平均一个企业需要对接多个不同的 Agent 平台
• 每个集成项目耗时数周到数月不等

这不是技术问题——这是经济损失。ARD 的价值主张是：标准化互操作层，让所有平台都能接入更大的市场。

各方的战略考量

缺席者意味深长

OpenAI 和 Anthropic 不在首批支持者名单中。 这不难理解——它们的商业模式依赖于开发者留在自己的 API 生态里。ARD 的去中心化发现机制与它们的「中心化平台」策略存在根本张力。

但这不重要。 ARD 的价值在于企业端——当 Salesforce、ServiceNow、Snowflake 都支持 ARD 时，企业 Agent 的互操作性问题就解决了大半。OpenAI 和 Anthropic 最终要么加入，要么面对被企业市场边缘化的风险。

ARD 目前处于规范发布阶段（v1.0），预计 2026 Q3 开始有首批 Registry 服务上线。以下是开发者可以立即开始做的事情。

5.1 发布你的能力（Catalog 端）

最简接入方式：在你的 API 域名根目录放一个 ai-catalog.json。

步骤：

1. 按 ARD 规范编写 ai-catalog.json（参考第 2 节的示例）
2. 确保 HTTPS 可访问（HTTP 会被拒绝）
3. 在响应头添加 X-ARD-Support: true
4. （可选）向公共 Registry 提交你的 catalog URL

5.2 消费外部能力（Client 端）

使用 ARD Client SDK 发现并调用外部能力。核心流程：初始化 Client → 用语义搜索发现能力 → 选择最佳匹配并调用。

5.3 企业接入策略

5.4 与现有架构的整合

ARD 设计上与以下技术栈兼容：

• API Gateway（Kong、Apigee）：可在网关层自动生成 catalog
• 服务网格（Istio、Linkerd）：ARD 发现结果可注入 sidecar 路由
• 身份认证（OAuth 2.0、OIDC）：ARD 原生支持标准认证协议

不需要推翻现有架构——ARD 是在现有基础设施之上加一层「发现能力」。

// ARD Client SDK 示例（TypeScript）
import { ARDClient } from '@ard/client';

const client = new ARDClient({
  registries: ['https://registry.ard.dev'],
  authProvider: myOAuthProvider,
});

// 用语义搜索发现能力
const results = await client.discover({
  intent: '分析用户评论的情感倾向',
  inputType: 'text',
  outputType: 'json',
});

// 选择最佳匹配并调用
const sentiment = await client.invoke(results[0], {
  input: '这个产品太棒了！',
});
console.log(sentiment); // { sentiment: 'positive', confidence: 0.95 }