Agent 协议分层：MCP、A2A、ACP 与 AG-UI

做一个 IDE 里的 Coding Agent 时，编辑器要展示 Diff 和权限请求，运行时要调用 Issue、文档和浏览器工具，遇到高风险任务还可能要委派给独立安全 Agent。前端控制台又需要把全过程呈现给用户。

这些连接都在谈消息、能力、会话和事件，很容易被误读成互相竞争的“统一标准”。更实用的看法是：它们主要连接不同边界–MCP 连接 AI 应用与工具、资源；A2A 连接相互独立的 Agent 系统；ACP 连接编辑器等 Client 与 Coding Agent；AG-UI 连接 Agent 后端与面向用户的前端。

一个真实产品完全可能同时使用四者。协议分层的意义，不是背四个缩写，而是知道身份、上下文、控制权和事件在哪一层流动。

先按连接对象选协议： 应用接工具看 MCP，独立 Agent 服务之间委派看 A2A，编辑器接 Coding Agent 看 ACP，前端展示和控制运行过程看 AG-UI。

下面用一个 Coding Agent 系统串起这四层，最后给出一张可以直接拿去画架构图的责任矩阵。

别让一个“万能消息”承担四种信任关系

“Agent 连接一切”听起来简洁，工程上却会把不同信任关系混在一起。工具 Server 通常由应用按最小权限调用；远程 Agent 可能是另一个团队运营的自治系统；编辑器需要展示文件 Diff 和终端；用户界面则关心流式文本、状态、批准和可交互组件。

这四类连接在五个方面差异明显：

边界	典型身份	主要状态	控制权	主要风险
应用-工具	Host 与 Server	工具、资源、调用结果	Host/模型选择工具	越权与数据泄漏
Agent-Agent	两个自治服务	任务、产物、进度	协商与委派	身份代理与责任不清
编辑器-Coding Agent	Client 与代码 Agent	会话、文件、终端	用户与 Agent 交替	仓库副作用
前端-Agent 后端	UI 与运行时	事件、消息、状态	双向交互	状态不同步、误批准

用同一种消息把所有关系都表示为“请做这件事”，授权和可观察性就会变得含糊。工具调用、远程任务委派、编辑器交互和用户界面事件，虽然都能传 JSON，却需要不同的生命周期和责任归属。

MCP：把工具和上下文接进应用

上一讲已经展开 MCP。它的核心对象是 Host、Client、Server，以及 Server 暴露的 Tools、Resources、Prompts。[1]

MCP 官方规范页面

图 1：MCP 解决的是应用如何连接外部能力。它不是远程 Agent 的组织架构。来源见文末。

典型场景：Coding Agent 通过 MCP 读取 Issue、查询文档、操作浏览器；桌面助手通过 MCP 访问日历和文件。这里的中心责任仍在 Host：它选择进入模型上下文的信息、校验工具参数、显示审批并记录调用。

一句话概括：MCP 让能力可插拔。接入时仍要把“Host 决定什么可以进入上下文、什么调用需要批准”写进产品逻辑。

A2A：把任务交给另一个自治系统

Agent2Agent（A2A）关注一个 Agent 如何发现另一个 Agent 的能力、委派任务、跟踪进度和接收产物。[2]

与 MCP Server 相比，远程 Agent 往往不是一个被动函数集合。它可能拥有自己的模型、工具、状态机、权限和长期任务。调用方不需要、也未必能看到其内部实现。

例如采购 Agent 把“向三个合格供应商询价”交给供应商侧 Agent。对方可能需要多轮处理、等待人工响应，并返回报价单产物，而不是立即返回一个 JSON 函数结果。A2A 因此更关心 Agent 能力发现、任务生命周期、长时运行与状态更新、消息和工件、异步与流式交互，以及不透明实现之间的互操作。

A2A 官方 GitHub 页面

图 2：A2A 项目进入 Linux Foundation 生态，官方仓库是规范和 SDK 变化的一手入口。来源见文末。

一句话概括：A2A 让自治系统可委派。读图时先看它的规范与 SDK 入口，再回到一个现实问题：任务交出去以后，谁还对用户目标和数据去向负责？答案通常仍是发起方的领域系统。

ACP：让编辑器知道 Agent 正在改什么

Agent Client Protocol（ACP）瞄准的是 Client 与 Coding Agent 的互操作，尤其是“任意编辑器连接任意 Coding Agent”。[3]

编辑器场景有一组特殊对象：会话创建、恢复与取消；用户消息与 Agent 更新；文件读取、修改和 Diff；终端命令与输出；权限请求；多种内容块和工具调用状态。这些对象比通用聊天 API 更贴近 Coding Agent 产品，编辑器不只显示一段最终文本，还要知道 Agent 正在读取哪个文件、请求运行什么命令、补丁如何变化、是否需要用户批准。

ACP 的价值在于降低“每个编辑器为每个 Coding Agent 写专有适配”的组合成本。

ACP GitHub 页面

图 3：ACP 官方仓库直接把目标描述为“连接任意编辑器与任意 Agent”。来源见文末。

一句话概括：ACP 让编码客户端与代码 Agent 可替换。图 3 关注的是编辑器与 Agent 的互操作边界，不会替仓库本身完成分支保护、测试或审批。

AG-UI：把运行过程投影给用户，而不是只吐一段文本

AG-UI 关注 Agent 后端与前端应用的双向事件流。[4]

一个现代 Agent UI 不只是逐字显示文本。它还要呈现当前运行阶段、工具调用开始/进度/结果、结构化状态变化、用户确认或补充输入、可交互卡片/表单/共享数据，以及中断、恢复和错误。如果前端只能接收一段字符串，就只能靠解析自然语言猜测状态。事件协议让 UI 直接消费类型化事件，例如 RUN_STARTED、TOOL_CALL_START、STATE_SNAPSHOT 和 RUN_FINISHED，具体事件以官方规范为准。

AG-UI 不负责 Agent 如何调用数据库，也不决定两个远程 Agent 如何协商。它负责把运行过程可靠地投影给用户，并把用户动作送回运行时。界面能显示“已取消”也不代表底层副作用真的已经停下，终态仍需要运行时和业务系统确认。

一句话概括：AG-UI 让 Agent 过程可交互。

沿着一个 Coding Agent，把四层连成一张图

假设一家企业开发一个 IDE 内的代码维护助手，完整路径可以这样理解：

Developer
   |
Editor / IDE
   |  ACP：会话、Diff、终端、权限
Coding Agent Runtime
   |  MCP：Issue、文档、浏览器、数据库工具
   |  A2A：委派安全审计给独立安全 Agent
   `  AG-UI：向 Web 控制台流式呈现状态与审批

这不是建议一定同时部署四种协议，而是说明它们没有天然互斥。系统小的时候，普通类型化接口可能就够；真正有跨实现、跨团队或跨产品边界时，再把协议引进来。一个较小的本地 Coding Agent 可能只需要 ACP 和 MCP；跨公司的采购网络可能重点使用 A2A；面向消费者的研究助手可能重点使用 MCP 和 AG-UI。

协议连通不代表授权可以原样向下传

协议 A 能成功调用协议 B，并不表示用户授权可以原样向下传。

例如用户在 Web UI 中批准“读取本仓库测试日志”，Coding Agent 随后通过 A2A 委派给外部安全 Agent，外部 Agent 又通过 MCP 调用文件 Server。此时必须回答：外部 Agent 以谁的身份访问、授权范围是否只限某个仓库和路径、是否允许继续转委派、授权何时失效、谁记录最终数据去向、用户批准的预览是否仍与实际参数一致。如果只是转发一个长期 Token，协议连通越顺畅，权限扩散越快。

更稳妥的方式是使用短期、范围受限、可审计的委派凭据，并让每层重新校验资源、动作和目的。用户批准“读取测试日志”，不能在传递几层之后变成“可以访问所有仓库文件”。

上下文越过一层，就应该再做一次裁剪

协议组合的第二个难点是信息最小化。

ACP 层：Coding Agent 可能看到当前仓库、选中文件和终端，但不该默认读取编辑器里其他项目。MCP 层：Server 只需收到工具参数，不需要完整用户对话；返回结果应标记来源，并由 Host 决定是否加入模型上下文。A2A 层：远程 Agent 需要任务说明和必要工件，不一定需要发起方的内部推理、所有用户资料或其他 Agent 历史。AG-UI 层：前端需要足够状态供用户理解和控制，但不应显示 Secret、内部凭据或不适合终端用户的模型推理内容。

“端到端共享完整上下文”看似省事，实际破坏了每层的最小披露原则。

每层的“完成”都不是同一种完成

四个协议层可能都有自己的 running 和 completed，它们含义却不同：MCP Tool 返回成功是一次工具调用已返回；A2A Task 完成是远程 Agent 宣布任务进入终态；ACP Session 活跃是 Coding 会话仍可继续；AG-UI Run 完成是当前前端运行流结束。

业务系统不能因为底层一次调用成功，就宣布用户目标完成。应有一个上层状态机负责把协议事件映射到领域状态，并用环境证据确认终态。例如安全 Agent 返回“审计完成”，上层仍要检查报告工件存在、版本与当前 Commit 匹配、阻断问题数量满足发布政策。

版本协商要落到可测试的降级路径

协议都在演进。生产集成需要固定或记录协商版本、通过 Capability Discovery 判断功能而不是猜测、对未知事件保留向前兼容策略、不支持关键能力时明确失败、对可选能力提供降级路径，以及将协议升级纳入契约测试。

“双方都支持这个协议”并不等于支持相同版本、扩展和认证方式。跨层系统尤其要避免最弱一层被其他层错误掩盖。例如 UI 支持取消，不代表远程 A2A 任务和底层 MCP 工具都能真正停止副作用。

审计时沿着数据、身份、控制和证据四条流走

审计一个协议组合系统时，可以追踪四类流：身份流（用户身份怎样变成 Client、Agent 和 Tool 的凭据）、数据流（输入、文件、结果流向哪些组织和存储）、控制流（谁能发起、取消、批准和宣布完成）、证据流（每个结论由什么日志、工件和环境终态支持）。

这样分析比问“我们用了 MCP，安全吗”更有效。协议只覆盖链路的一部分，安全取决于整条流上的策略。

拿自己的系统画一张协议责任矩阵

选一个你熟悉的 Agent 产品，例如 IDE 助手、客服或研究工具。不要先决定用哪个协议，先列出参与者：用户、前端、Agent Runtime、外部 Agent、工具 Server 和业务系统。

为每条连接填写：

source -> target
传递的数据：
调用方身份：
允许动作：
终态证据：
取消语义：
建议协议或普通 API：

然后做三次故障注入推演：用户在前端取消但远程任务仍在运行；外部 Agent 把任务继续转委派给未知系统；Tool 已产生副作用但中间网络响应丢失。如果矩阵无法说明由谁查询真实状态、谁阻止重复动作，说明问题不在协议选型，而在领域状态和责任边界还没设计完。先补 Owner 和终态证据，再看是否真的需要新协议。

一个简洁的选型顺序

不要问“哪个协议最强”，而要按连接对象选择：AI 应用要接工具或数据源，先看 MCP；独立 Agent 服务要委派长任务，看 A2A；编辑器要兼容不同 Coding Agent，看 ACP；前端要显示和控制 Agent 运行，看 AG-UI；如果只是同一进程内两个函数，普通类型化接口可能已经足够。

协议会增加兼容层、状态映射和安全责任。没有跨实现互操作需求时，不必为使用协议而使用协议。

小结

MCP、A2A、ACP 与 AG-UI 不是四个“Agent 万能标准”的竞争者，而是分别处理工具接入、自治系统协作、编码客户端连接和用户交互的边界。

协议分层能降低集成耦合，但也会产生身份委派、上下文裁剪、终态对齐和版本协商的新问题。系统最终仍需要一个领域级 Owner 对用户目标负责。协议调用成功只是链路通了，不是用户的任务已经完成。

第四单元到这里结束。下一讲进入评测：为什么一次 Demo 成功几乎说明不了 Agent 是否可靠，以及怎样建立任务、轨迹和安全三层 Eval。

参考资料

[1] Model Context Protocol, Specification 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25

[2] A2A Project, A2A Protocol Repository. https://github.com/a2aproject/A2A

[3] Agent Client Protocol, Introduction. https://agentclientprotocol.com/

[4] AG-UI, Agent-User Interaction Protocol. https://docs.ag-ui.com/

[5] Google Cloud, A developer’s guide to production-ready AI agents. https://cloud.google.com/blog/products/ai-machine-learning/a-devs-guide-to-production-ready-ai-agents/