AI Protocol Reference — 领域地图与原理综述
30 秒导读: 这一货架装的不是某个框架、不是某个 agent 产品,而是 agent 时代的**“接口标准”本身**——22 份规范、约定与官方 SDK。它们看起来五花八门(有的讲怎么调工具、有的讲怎么付钱、有的讲怎么画界面),但都在解决同一个根本问题:让 AI agent 与外部世界打交道时,双方先约好一份机器能读、能协商的契约,而不是各写各的临时胶水。这份总纲先讲清这条共性,再把货架拆成 5 条分支,每条分支链到自己的章节。
本货架是 AI 参考三货架之一,只收规范层(normative):协议、标准、约定,以及与协议强绑定的官方 SDK。框架/运行时/研究库在姊妹货架 ai-frontier-reference;可直接上线的 agent 产品在 ai-agent-reference。
1. 共性(主干):agent 时代的“机器对机器契约”
先问:这 23 个库到底共同在干什么
把它们摆在一起,剥掉表面差异——A2A 在传 Agent Card、x402 在传 402 支付挑战、MCP Apps 在传一段 ui:// 界面、AGENTS.md 在传一段给 agent 看的说明——会发现它们做的是同一类事:
在 agent 与某个对端(工具、数据源、另一个 agent、商家、浏览器页面、前端 UI、观测系统)之间,定义一份双方都能机器读懂、能协商版本与能力的契约,从而任意一方换实现都不必让另一方改代码。
这就是树干。过去软件集成靠人:人读 API 文档、人写专属适配、人点网页结账。agent 时代这条路不通——agent 要在运行时自己发现“有什么能接”、自己读懂“契约长什么样”、自己完成交互。于是每一个交互面都被重新标准化成机器契约:
| 过去(人为中心) | 现在(本货架的契约) |
|---|---|
| 人读 API 文档、手写适配 | agent 读 schema/agent card,运行时对接(MCP、A2A) |
| 人在网页点“结账” | agent 凭授权令牌完成支付(x402、AP2、ACP-commerce) |
| 人在浏览器里点按钮 | 页面把能力暴露成工具给 agent(WebMCP、NLWeb) |
| 人读 README 才会用一个库 | agent 读 AGENTS.md / SKILL.md 自动会用 |
| 人看仪表盘排查 | 标准化 span/属性让系统自动观测(OTel GenAI) |
共性的三个共同动作
几乎每份规范都在做下面三件事中的一件或几件——这是判断“它属于这货架”的试金石:
- 发现(discover):对端怎么宣告自己存在、有什么能力。A2A 的 Agent Card、MCP 的
server/discover、MCP Registry 的server.json、AGNTCY Directory 的 OASF 记录、llms.txt 的站点清单,全是“宣告能力”的不同写法。 - 协商(negotiate):双方怎么对齐协议版本与可选能力,谁能调用谁。MCP 的 capability negotiation、ACP 的 v1/v2 schema、ACP-commerce 的 capability_negotiation RFC,都是这一步。
- 交互(interact):约定消息形态后真正来回传东西——调工具、传事件、渲染 UI、发支付挑战。
衡量你读懂了没:任意挑货架里两个库,你能说出它们各自标准化了“哪个交互面”、各自怎么做发现/协商/交互。 这正是下面 5 条分支要回答的。
2. 分支地图(主枝):共性分化出的 5 个交互面
树干是“机器对机器契约”。它自然按**“agent 在跟谁打交道”分化成 5 条主枝——每条主枝是一个交互面**:
agent 时代的机器对机器契约(主干)
“agent 与外部世界的每次交互,都改写成机器可协商的显式契约”
│
┌──────────┬──────────┬────┴─────┬─────────── ┬─────────────────┐
▼ ▼ ▼ ▼ ▼
① 接能力 ② 代理互联 ③ 画界面 ④ 付钱结算 ⑤ 喂指令与可观测
agent→工具 agent→agent agent→前端 agent→钱 人/站点→agent;系统→观测
/数据/发现
│ │ │ │ │
MCP* A2A MCP Apps UCP AGENTS.md
MCP-SDK ACP(Zed) MCP-UI ACP-commerce Agent Skills
Registry AGNTCY† OpenAI Apps AP2 Model Spec
NLWeb AG-UI x402 llms.txt
WebMCP A2UI OTel GenAI
AGNTCY†
*MCP 是整个货架的“地基协议”:它被 ③④⑤ 多条分支当作底层传输/绑定复用(见 §4 交叉点)。†AGNTCY 横跨①②:它的 Directory 既是“发现工具/服务”的目录,也索引 A2A Agent Card,所以两处都点名。
① 接能力 — agent 怎么够到外部工具/数据,怎么发现有什么可接
这条分支解决“agent 的手往外伸”:把工具、文件、数据库、API、整个网站,变成 agent 运行时能调用的能力,并解决“有哪些能力可发现”。MCP 是这条分支(也是全货架)的基石协议——一套基于 JSON-RPC 的 host↔server 接口;NLWeb 让一个网站变成可对话的 /ask//mcp 端点;WebMCP 让浏览器页面把按钮暴露成 agent 工具;MCP Registry 与 AGNTCY Directory 解决“去哪里发现 server/agent”。代表库:mcp-spec(已写子库 doc)。
→ guide/connect-capabilities.md
② 代理互联 — agent/编辑器怎么跟另一个 agent 对话
①是 agent 够工具,这条分支是 agent 够另一个 agent。当对端本身是个有自主性的 agent(而非无状态工具),就需要任务生命周期、流式、推送通知这些更重的语义。A2A 是这条分支的主协议(Agent Card + Task/Message/Artifact 生命周期);ACP(Zed) 是其中一个专门子集——编辑器↔编码 agent 的会话协议;AGNTCY 提供跨组织的分布式发现与可验证身份。代表库:a2a-protocol。 → guide/agent-to-agent.md
③ 画界面 — agent 怎么把交互式 UI 渲染到宿主/前端
光有文字不够,agent 常要回一个可交互的界面(表单、卡片、购物车)。这条分支标准化“界面怎么过线、宿主怎么沙箱渲染”。两种思路:事件流(后端流式发 UI 事件——AG-UI)对 声明式 UI 树(发一棵描述“画什么”的树——A2UI、MCP Apps 的 ui:// 资源)。MCP Apps 是 UI-over-MCP 的官方方向,MCP-UI 是其社区实现料,OpenAI Apps SDK 是 ChatGPT 侧的对应样例。代表库:mcp-apps-ext。
→ guide/render-ui.md