Agent 协议分层：MCP、A2A、ACP 与 AG-UI
Agent 生态出现了越来越多协议：MCP、A2A、ACP、AG-UI。它们都谈消息、能力、会话和事件，很容易被理解成互相竞争的“统一标准”。
更准确的看法是：它们主要连接不同边界。
- MCP 连接 AI 应用与工具、资源；
- A2A 连接相互独立的 Agent 系统；
- ACP 连接编辑器等 Client 与 Coding Agent；
- AG-UI 连接 Agent 后端与面向用户的前端。
一个真实产品完全可能同时使用四者。协议分层的意义，不是记住四个缩写，而是知道身份、上下文、控制权和事件在哪一层流动。
一、为什么一个协议很难包办全部边界
Section titled “一、为什么一个协议很难包办全部边界”“Agent 连接一切”听起来简洁，工程上却会把不同信任关系混在一起。
工具 Server 通常由应用按最小权限调用；远程 Agent 可能是另一个团队运营的自治系统；编辑器需要展示文件 Diff 和终端；用户界面则关心流式文本、状态、批准和可交互组件。
这四类连接在五个方面差异明显：
| 边界 | 典型身份 | 主要状态 | 控制权 | 主要风险 |
|---|---|---|---|---|
| 应用：工具 | Host 与 Server | 工具、资源、调用结果 | Host/模型选择工具 | 越权与数据泄漏 |
| Agent：Agent | 两个自治服务 | 任务、产物、进度 | 协商与委派 | 身份代理与责任不清 |
| 编辑器：Coding Agent | Client 与代码 Agent | 会话、文件、终端 | 用户与 Agent 交替 | 仓库副作用 |
| 前端：Agent 后端 | UI 与运行时 | 事件、消息、状态 | 双向交互 | 状态不同步、误批准 |
如果用同一种消息把所有关系都表示为“请做这件事”，授权和可观察性就会变得含糊。
二、MCP：应用到工具与上下文
Section titled “二、MCP：应用到工具与上下文”上一讲已经展开 MCP。它的核心对象是 Host、Client、Server，以及 Server 暴露的 Tools、Resources、Prompts。[1]
图 1：MCP 解决的是应用如何连接外部能力。它不是远程 Agent 的组织架构。来源见文末。
典型场景：Coding Agent 通过 MCP 读取 Issue、查询文档、操作浏览器；桌面助手通过 MCP 访问日历和文件。
这里的中心责任仍在 Host：它选择进入模型上下文的信息、校验工具参数、显示审批并记录调用。
一句话概括：MCP 让能力可插拔。
三、A2A：独立 Agent 系统之间的任务协作
Section titled “三、A2A：独立 Agent 系统之间的任务协作”Agent2Agent（A2A）关注一个 Agent 如何发现另一个 Agent 的能力、委派任务、跟踪进度和接收产物。[2]
与 MCP Server 相比，远程 Agent 往往不是一个被动函数集合。它可能拥有自己的模型、工具、状态机、权限和长期任务。调用方不需要、也未必能看到其内部实现。
例如采购 Agent 把“向三个合格供应商询价”交给供应商侧 Agent。对方可能需要多轮处理、等待人工响应，并返回报价单产物，而不是立即返回一个 JSON 函数结果。
A2A 因此更关心：
- Agent 能力发现；
- 任务生命周期；
- 长时运行与状态更新；
- 消息和工件；
- 异步与流式交互；
- 不透明实现之间的互操作。
图 2：A2A 项目进入 Linux Foundation 生态，官方仓库是规范和 SDK 变化的一手入口。来源见文末。
一句话概括：A2A 让自治系统可委派。
四、ACP：编辑器到 Coding Agent
Section titled “四、ACP：编辑器到 Coding Agent”Agent Client Protocol（ACP）瞄准的是 Client 与 Coding Agent 的互操作，尤其是“任意编辑器连接任意 Coding Agent”。[3]
编辑器场景有一组特殊对象：
- 会话创建、恢复与取消；
- 用户消息与 Agent 更新；
- 文件读取、修改和 Diff；
- 终端命令与输出；
- 权限请求；
- 多种内容块和工具调用状态。
这些对象比通用聊天 API 更贴近 Coding Agent 产品。编辑器不只显示一段最终文本，还要知道 Agent 正在读取哪个文件、请求运行什么命令、补丁如何变化、是否需要用户批准。
ACP 的价值在于降低“每个编辑器为每个 Coding Agent 写专有适配”的组合成本。
图 3：ACP 官方仓库直接把目标描述为“连接任意编辑器与任意 Agent”。来源见文末。
一句话概括：ACP 让编码客户端与代码 Agent 可替换。
五、AG-UI：Agent 后端到用户界面
Section titled “五、AG-UI：Agent 后端到用户界面”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 系统
Section titled “六、把四层放进一个 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。
七、协议组合最难的不是连通，而是身份传递
Section titled “七、协议组合最难的不是连通，而是身份传递”协议 A 能成功调用协议 B，并不表示用户授权可以原样向下传。
例如用户在 Web UI 中批准“读取本仓库测试日志”，Coding Agent 随后通过 A2A 委派给外部安全 Agent，外部 Agent 又通过 MCP 调用文件 Server。此时必须回答：
- 外部 Agent 以谁的身份访问；
- 授权范围是否只限某个仓库和路径；
- 是否允许继续转委派；
- 授权何时失效；
- 谁记录最终数据去向；
- 用户批准的预览是否仍与实际参数一致。
如果只是转发一个长期 Token，协议连通越顺畅，权限扩散越快。
更稳妥的方式是使用短期、范围受限、可审计的委派凭据，并让每层重新校验资源、动作和目的。
八、上下文传递也要按层裁剪
Section titled “八、上下文传递也要按层裁剪”协议组合的第二个难点是信息最小化。
Coding Agent 可能看到当前仓库、选中文件和终端，但不该默认读取编辑器里其他项目。
Server 只需收到工具参数，不需要完整用户对话。返回结果应标记来源，并由 Host 决定是否加入模型上下文。
远程 Agent 需要任务说明和必要工件，不一定需要发起方的内部推理、所有用户资料或其他 Agent 历史。
AG-UI 层
Section titled “AG-UI 层”前端需要足够状态供用户理解和控制，但不应显示 Secret、内部凭据或不适合终端用户的模型推理内容。
“端到端共享完整上下文”看似省事，实际破坏了每层的最小披露原则。
九、状态与终态怎样对齐
Section titled “九、状态与终态怎样对齐”四个协议层可能都有自己的 running 和 completed，它们含义却不同。
- MCP Tool 返回成功：一次工具调用已返回；
- A2A Task 完成：远程 Agent 宣布任务进入终态；
- ACP Session 活跃：Coding 会话仍可继续；
- AG-UI Run 完成：当前前端运行流结束。
业务系统不能因为底层一次调用成功，就宣布用户目标完成。应有一个上层状态机负责把协议事件映射到领域状态，并用环境证据确认终态。
例如安全 Agent 返回“审计完成”，上层仍要检查报告工件存在、版本与当前 Commit 匹配、阻断问题数量满足发布政策。
十、版本、能力与降级
Section titled “十、版本、能力与降级”协议都在演进。生产集成需要：
- 固定或记录协商版本；
- 通过 Capability Discovery 判断功能，而不是猜测；
- 对未知事件保留向前兼容策略；
- 不支持关键能力时明确失败；
- 对可选能力提供降级路径；
- 将协议升级纳入契约测试。
“双方都支持这个协议”并不等于支持相同版本、扩展和认证方式。
跨层系统尤其要避免最弱一层被其他层错误掩盖。例如 UI 支持取消，不代表远程 A2A 任务和底层 MCP 工具都能真正停止副作用。
十一、安全分析要沿数据流，而不是沿产品名
Section titled “十一、安全分析要沿数据流，而不是沿产品名”审计一个协议组合系统时，可以追踪四类流：
- 身份流：用户身份怎样变成 Client、Agent 和 Tool 的凭据；
- 数据流：输入、文件、结果流向哪些组织和存储；
- 控制流：谁能发起、取消、批准和宣布完成；
- 证据流：每个结论由什么日志、工件和环境终态支持。
这样分析比问“我们用了 MCP，安全吗”更有效。协议只覆盖链路的一部分，安全取决于整条流上的策略。
十二、20：40 分钟实践：画一张协议责任矩阵
Section titled “十二、20：40 分钟实践：画一张协议责任矩阵”选一个你熟悉的 Agent 产品，例如 IDE 助手、客服或研究工具。不要先决定用哪个协议，先列出参与者：用户、前端、Agent Runtime、外部 Agent、工具 Server 和业务系统。
为每条连接填写：
source -> target传递的数据：调用方身份：允许动作：终态证据：取消语义：建议协议或普通 API：然后做三次故障注入推演：
- 用户在前端取消，但远程任务仍在运行；
- 外部 Agent 把任务继续转委派给未知系统；
- Tool 已产生副作用，但中间网络响应丢失。
如果矩阵无法说明由谁查询真实状态、谁阻止重复动作，说明问题不在协议选型，而在领域状态和责任边界还没设计完。
十三、一个简洁的选型顺序
Section titled “十三、一个简洁的选型顺序”不要问“哪个协议最强”，而要按连接对象选择：
- AI 应用要接工具或数据源：先看 MCP；
- 独立 Agent 服务要委派长任务：看 A2A；
- 编辑器要兼容不同 Coding Agent：看 ACP；
- 前端要显示和控制 Agent 运行：看 AG-UI；
- 如果只是同一进程内两个函数：普通类型化接口可能已经足够。
协议会增加兼容层、状态映射和安全责任。没有跨实现互操作需求时，不必为使用协议而使用协议。
十四、这一讲的结论
Section titled “十四、这一讲的结论”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/