第 13 章 · 协议：MCP、A2A、AG-UI 分别连接哪些参与方

本章是全书时效性风险最高的一章。 协议采用日期式或语义化版本，破坏性变更频繁。仅在本书资料整理期间，MCP 的若干条目就已经失效。本章的版本号与存活状态都只代表资料截止日。

---

13.1 三件不同的事，共用一个词

第 12 章完成了 Agent 拆分与否的工程决策；而在确定需要跨越进程或系统边界进行外部通信时，协议选型（Protocol Architecture）便成为决定系统拓扑与解耦深度的核心。

在当前大模型基础设施生态中，「Agent 协议」这一宽泛术语常被笼统用于指代三类截然不同、各司其职的通信维度：

• 垂直向下 · 工具与上下文交互：Agent 如何标准化调用底层工具与挂载外部数据源；
• 水平横向 · 跨 Agent 对等协作：两个或多个彼此独立的 Agent 之间如何安全交换意图与任务；
• 垂直向上 · 前端渲染与状态同步：Agent 如何将内部思考轨迹与执行事件流式推送至用户界面。

图 13-1　MCP、A2A 与 AG-UI 分别连接哪些参与方

图 13-1 展示了现代 AI Agent 架构中三大主流通信协议的正交三维拓扑映射：垂直向下的 MCP 协议专注于 Host 与数据源/工具 Server 之间的 1:1 星型挂载；水平维度的 A2A 协议专注于跨组织、跨信任边界的对等 Peer 协作与独立 Task 状态机流转；垂直向上的 AG-UI 与 A2UI 协议则专注于将 Agent 内部的思考轨迹、工具事件与组件状态实时同步至交互前端。三个协议在功能正交维度上各司其职，生产系统通常协同组合使用，绝非互斥替代关系。

协议认知的典型工程误区：最严重的架构错误是将 MCP 误用为 Multi-Agent 协作协议，将另一个完整的 Agent 强行包装为 MCP Server。这种做法虽能勉强调通，但由于 MCP 物理架构缺乏 Agent 身份认证、能力协商与任务全生命周期管理，会导致连接数随 Agent 规模线性暴增且失去对等协作能力。

---

13.2 逐轴解析：MCP、A2A、AG-UI 与存废协议全景

13.2.1 MCP：定位为标准工具与上下文层，而非对等协作层

MCP（Model Context Protocol）官方将其类比为 AI 时代的 LSP（Language Server Protocol），其核心使命是让工具与数据源实现跨应用标准化复用。

官方架构规范在 Scope 一节做出了明确的边界约束：

MCP focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs or manage the provided context.

表 13-1 阐明了 MCP 的三角色定义与严格拓扑约束。

表 13-1：MCP 的三角色拓扑与 1:1 连接约束

核心角色	角色物理定位与职责
Host	AI 宿主应用本体，统一编排调度所有 Client 连接器
Client	驻留在 Host 内部的适配器，与单一 Server 维持专属点对点连接
Server	提供特定上下文资源或工具能力的独立进程（本地 stdio 或远程 HTTP）

核心物理拓扑约束：1 Client $\leftrightarrow$ 1 Server 严格强绑定。Host 若需连接 $N$ 个 Server，必须在内部实例化 $N$ 个独立的 Client 进程；Server 彼此之间物理隔离、完全不可见且严禁横向通信。这种星型结构从根本上决定了 MCP 无法承载 Agent 之间的去中心化对等协作。

13.2.2 MCP 2026-07-28 核心修订：彻底倒向无状态设计

MCP 规范在 2026-07-28 版本中实施了剧烈的重构，全面废弃了此前 2025-11-25 版本的有状态假设，见表 13-2。

表 13-2：MCP `2026-07-28` 核心修订对系统工程的重大影响

协议核心变更条目	系统工程实现影响与应对策略
移除 initialize 握手，全面转向无状态	每个请求通过 _meta 显式携带版本与能力；新增 server/discover 声明端点
物理废除 Mcp-Session-Id 会话头	传输层不再维护协议级会话，会话绑定需完全退回应用层自行管理
废除 SSE 断线续传与 Last-Event-ID	数据流中断后在途请求直接作废，客户端必须使用全新 Request ID 重发
subscriptions/listen 替代显式订阅	采用长连接流接收主动推送通知，严禁 Server 推送未订阅的事件类型
Task 状态机移出核心规范并转为轮询	阻塞式 Task 结果改为基于 tasks/get 的被动轮询模型
日志与采样整体标为 Deprecated	废弃协议内日志，转向标准 OpenTelemetry 与标准模型 API 直连

架构演进启示：MCP 正在坚决剔除复杂的协议层有状态能力，将连接保活、断线重放与会话状态机的复杂度全部推回 Host 应用层（第 14 章的事件溯源正是应对该趋势的自研基础）。

13.2.3 A2A：坚持跨信任边界的对等 Peer 协作

A2A（Agent2Agent Protocol）由 Linux Foundation 托管，其核心设计立足于跨组织、跨厂商的黑盒 Agent 协作：

without needing access to each other’s internal state, memory, or tools

表 13-3：A2A 从 0.x 到 1.0 的破坏性重构

0.x 遗留规范	1.0 现行正式规范
斜杠路径方法名（message/send）	PascalCase 标准 RPC 方法名（SendMessage、GetTask）
根路径元数据（/.well-known/agent.json）	标准发现端点（/.well-known/agent-card.json）
弱类型小写状态字符串	强类型枚举（TASK_STATE_SUBMITTED、TASK_STATE_WORKING 等 8 状态）

A2A 将 Task 视为具备完整独立生命周期的协议核心实体，其状态机原生支持 REJECTED（被叫方主动拒单）与 AUTH_REQUIRED（跨层级级联授权链），天然契约化支持分布式长程任务。

13.2.4 AG-UI 与 A2UI：垂直向上的交互呈现层

• AG-UI：基于 SSE/WebSocket 规范 Agent 到前端的流式事件传输（RUN_STARTED $\to$ TEXT_MESSAGE_* / TOOL_CALL_* $\to$ RUN_FINISHED），并通过 JSON Patch（RFC 6902）实现高吞吐的状态增量同步（STATE_DELTA）；
• A2UI：专注于声明式 UI 描述，将 Agent 输出的结构化 JSON 映射为客户端原生组件。

13.2.5 协议存废与维护状态清单

表 13-4 基于代码仓的真实 Push 记录与归档状态，给出了业界主流协议的存活判定。

表 13-4：开源 Agent 通信协议维护现状核实（取数时间：2026-07-22 至 2026-08-18）

协议名称	代码仓库与核心指标	当前真实维护与存活状态
IBM/BeeAI ACP	i-am-bee/acp（1,019 stars）	已正式归档并全面并入 A2A 项目
Cisco AGNTCY ACP	agntcy/acp-spec（166 stars）	已正式归档停更
agents.json	wild-card-ai/agents-json（1,315 stars）	已实质停更停摆
AITP	nearai/aitp（25 stars）	已实质停更停摆
ANP	agent-network-protocol/AgentNetworkProtocol	基于 W3C DID 持续活跃维护中

---

13.3 判断标准：协议选型的四项核心准则

判断标准一：严格依据通信正交轴选型

坚决杜绝「一刀切」思维：向下对接工具选 MCP；横向跨信任边界协作选 A2A；向上对接前端选 AG-UI。

判断标准二：精准辨析 Peer 对等协作与 Tool 工具调用

表 13-5：Peer 对等模式与 Tool 调用模式的适用场景对比

协作模式	拓扑本质与权限特征	典型工程场景
Agent as a Tool	主控 Agent 维持全权控制，子 Agent 被封装为标准函数	同一代码仓、同一部署环境内部的紧耦合子任务
Agent as a Peer	双方地位对等，不暴露内部 Memory 与工具细节，通过 Task 契约交互	跨团队、跨公司、跨安全域的分布式异构 Agent 协作（A2A）

判断标准三：清醒界定协议无法代劳的三项核心职责

协议适配层仅处理传输与序列化，以下三项必须由本地运行时直接实现：

1. 输入信任校验与转义：协议绝不保证对端输出的安全性（第 11 章）；
2. 上下文 Token 预算管理：协议绝不负责截断对端返回的大体积 Payload（第 3、9 章）；
3. 确定性重试与超时状态机：协议不定义业务级的重试与补偿策略（第 5、14 章）。

判断标准四：显式锁定协议的具体版本号

在代码与 CI 中必须硬编码协议版本断言（如 MCP_REVISION = "2026-07-28"，A2A-Version: 1.0），坚决禁止使用漂移的 latest。

---

13.4 反面证据与失败模式

失败模式一：将复杂子 Agent 强行包装为 MCP Server

丧失 Agent 身份标识、丧失 Task 异步生命周期管理、连接数呈线性爆炸，且无法支持双向对等调度。

失败模式二：对端输出未做沙箱与转义即直接入模

盲目采信远端 A2A Peer 的返回文本，导致下游 Agent 遭受跨系统传播的 Prompt Injection 攻击。

---

13.5 可以直接采用的最小实现

13.5.1 协议适配层防御性校验伪代码

// 1. 协议版本握手严格断言
export function validateProtocolHandshake(negotiatedVersion: string, expectedVersion: string) {
  if (negotiatedVersion !== expectedVersion) {
    throw new UnsupportedProtocolVersionError(
      `协议版本不匹配: 期望 ${expectedVersion}, 实际协商为 ${negotiatedVersion}. 拒绝降级执行.`
    );
  }
}

// 2. 外部输入统一安全收口
export function sanitizeRemoteAgentPayload(rawResponse: string, tokenBudget: number): string {
  // 必须执行第 11 章的标准防护流水线
  const escaped = escapeHtmlEntities(rawResponse);
  const framed = `<untrusted_peer_response>
${escaped}
</untrusted_peer_response>`;
  return truncateToTokenBudget(framed, tokenBudget);
}

13.5.2 验收测试矩阵

在交付协议接入层前，必须通过以下四项基础验证：

1. 版本不一致熔断测试：模拟服务端返回未支持的 Protocol Version，断言客户端立即报错阻断而非隐式降级；
2. 连接中断自愈测试：主动切断 SSE 连接，断言本地运行时依托自身的 Seq 序号恢复状态，而非依赖协议层会话；
3. 对端注入隔离测试：模拟对端 Agent 返回包含系统提权指令的 Payload，断言本地 Host 严格将其包裹在不可信数据标签中；
4. 多 Server 资源隔离测试：并发建立 10 个 MCP Server 连接，断言每个 Client 实例生命周期独立且无交叉泄漏。