四层中的 13 个 Agent 协议——今天该部署什么
AI agent 协议栈的四层：MCP、A2A、AG-UI 和支付。今天该部署什么、该关注什么——面向 2026 年架构师的决策指南。
每个人都说集成 AI agent 就像集成任何其他 API 一样——但如果没有共享协议，每个模型乘以每个工具再乘以每个 agent，就会形成组合爆炸，也就是在团队交付任何有用成果之前就将其扼杀的 N×M 问题。这适用于所有在生产环境部署 agent 的团队：每一对新的模型–工具组合，都是一个需要维护的独立 bespoke connector。在过去十八个月里，也就是 2024 到 2026 年之间，一个分层的开放协议栈已经出现——类似 HTTP 和 TCP/IP——并且其关键层已经进入 Linux Foundation 旗下。
接下来的十一分钟里，你将知道四层中哪些今天就该部署，哪些只需关注。你不仅会了解这些协议确实存在，还会理解为什么越接近用户和金钱，成熟度就越低。
栈图：四层，一个类比
关于这个协议栈，最重要的事实只有一个：**越接近用户和金钱，成熟度就越低。**基础层——工具和上下文——已经可用于生产，并且是事实标准。Agent-to-agent 通信已经达到生产级，并正在整合市场。接口层已经达到临界规模。支付层仍在快速增殖——五个相互竞争的协议，其中大多数还是 2026 年的试点项目。
对架构师来说，实际结论很简单：**今天部署栈的底部，关注栈的顶部。**部署 MCP 做工具集成，基于 A2A 构建通信，用 AG-UI 标准化接口——而在支付层，运行试点，不要把业务建立在它们之上。这不是市场失败。这是自然顺序：离风险最远的东西最先被标准化。
本文后续会按照同一套框架拆解每一层：它存在的目的、由哪些协议构成、哪些已经可用于生产、它们的差异在哪里——以及应该选择什么。我们从基础层开始，因为没有它，上面的三层就无从立足。
四个问题，一个栈
N×M 问题听起来很抽象，直到你用团队工时去计算它。N 个模型乘以 M 个工具等于 N×M 个独立集成——每一个都需要编写、测试和维护。协议会一次性标准化双方，因此数量降到 N+M。这就是这场运动背后的全部直觉，并在协议栈的每一层重复出现。
这种模式有先例。Language Server Protocol 正是为代码编辑器解决了这个问题——不再为每个编辑器–语言组合编写一个插件，一个协议就够了。MCP 直接继承了它，甚至包括消息格式：两者都使用 JSON-RPC 2.0，一种轻量级、基于 JSON 的远程调用格式。但有一个区别：LSP 在本地、可信环境中运行。Agent 协议栈跨越信任边界——这改变了一切，后文我会回到这一点。
四层，四个类比
四层解决四个不同问题。工具和上下文是 API Gateway——AI 的 USB-C。Agent-to-agent 通信是 TCP/IP，再加上一点 service mesh。Agent UI 是接口层的 HTTP 和 HTML。支付是电子商务的 SSL——信任和授权层。
贯穿其中的是横切的发现与身份基础设施——AGNTCY，一个部分由 Cisco 开发的开放项目，充当 agent 的 DNS 和 PKI：层级命名、消息路由和可验证凭证。这里的网络类比非常准确，不过——正如我最后会说明的——它也有边界。
思维上的关键转变是：架构师不应把这十三个协议看作一锅首字母缩略词大杂烩，而应把它们视为一个整体协议栈，其中**每一层都有自己的位置和成熟度。**决策单位是栈图，而不是任何单个协议。既然图已经清晰——哪个基础层已经足够成熟，可以今天就构建在其之上？
第 1 层——工具和上下文：MCP，AI 的 USB-C
**MCP——Model Context Protocol——是一个开放标准，用于将 LLM 应用连接到工具和数据。**最简单的说法是：一个像 USB-C 一样的通用端口，AI 通过它接入任意工具或数据存储，而不是为每个工具单独准备一根线缆。它存在的原因很明显——它解决了工具层的 N×M 问题。
其机制是不对称且清晰的。架构中有三个角色：Host（例如 Claude 或 IDE）、Client（到一个 server 的一条连接）和 Server，后者暴露三类原语——tools、resources 和 prompt templates。消息通过 JSON-RPC 传输。今天的生产传输方式是 Streamable HTTP，它取代了较早的 HTTP+SSE；在企业部署中，还会加入 OAuth 授权。
成熟度与简单性的代价
就成熟度而言，MCP 在它所在的层没有真正的竞争者。它已经完全可用于生产，拥有多语言 SDK，并被最大的一些玩家采用——从 OpenAI 到 Google DeepMind，二者都在 2025 年春季采用了该协议（MCP 最初由 Anthropic 创建）。网上流传的 server 数量（从“数千个”到“超过一万个”）应被视为厂商报告，而不是审计结果。唯一的替代方案是 ad-hoc tool calling——也就是回到 bespoke integrations，这是一种倒退。
不过，简单性是有代价的，而且是字面意义上的成本。每个连接的 server 都会在会话开始时注入数千个 token 的工具 schema。在一次测量中（Scalekit，厂商报告），通过 MCP 执行同一个 GitHub 查询，消耗的 token 大约是通过普通 CLI 的 32 倍。这不是理论——这是每个会话都会产生的真实账单。
第二个代价是安全性。LLM 会将它读取的工具描述视为可信内容，而其中可能包含 tool poisoning——隐藏在 metadata 中的恶意指令，模型会将其当作工具的合法部分来执行。后文我会再次讨论这个话题，因为它适用于整个协议栈。
建议很明确：今天就采用 MCP——但要以成熟架构师的方式，而不是以爱好者的方式。采用 MCP Gateway 模式，而不是让 agent 直接连接到 servers：集中认证、访问策略和审计轨迹。将范围限制在三到五个高价值、已签名的 servers，并将每个都视为第三方依赖。MCP 将 agent 连接到工具——但当 agent 需要彼此交谈时，它们需要的不只是一个 USB 端口。
第 2 层——Agent-to-Agent 通信：A2A 及其传输
A2A——Agent2Agent——是让 agent 像 agent 一样交流，而不是像工具一样被调用的协议。差异是根本性的：你调用一个工具，但你会把一项任务委派给一个 agent，就像委派给团队中的同事一样。这一层存在的目的，是让来自一个厂商的 agent 能够把工作分配给另一个厂商的 agent，而不需要编写 glue code——没有它，Salesforce agent 就无法与 ServiceNow agent 协同。
该机制的核心是 Agent Card——位于 /.well-known/agent-card.json 的一个 JSON 文件，agent 在其中声明自己的能力和认证方式。传输层是 HTTP 搭配 JSON-RPC，并可选使用 gRPC 来满足高频、低延迟需求。任务周期通过定义好的状态机流转——从 “submitted” 到 “completed” 或 “input-required”——这使 A2A 成为一个具有可预测流程的协议，而不是松散的消息交换。
A2A 赢得了这一层
最重要的不是 A2A 如何工作，而是 **A2A 赢得了它所在的层。**它已经可用于生产，被超过一百五十家组织使用，集成进 Microsoft Copilot Studio 和 Amazon Bedrock——并且正在整合市场。IBM 的并行 ACP 协议在 2025 年夏季与 A2A 合并——这是 IBM 和 Linux Foundation 联合公告中的自愿整合——BeeAI 平台也完成了迁移。这是该领域第一次重大整合，也是通信层走向的信号。
这一层的其他协议是补充，而不是默认替代品。SLIM 是 A2A 下方的传输层，使用 MLS (RFC 9420)——一种 IETF 端到端群组加密标准，受 Double Ratchet 方法（Signal 的底层机制）启发，并将其扩展到从两人到数千人规模的群组——当受监管环境需要 E2EE 时值得考虑。AGP 是一种受互联网路由启发的层级 gateway，只有当每个 domain 的 mesh network 超过五十个 agent 时才有意义。ANP 走向相反方向：它押注基于 DID 的去中心化身份——一种没有中央权威的 agent identifier——但它仍是草案，没有具名部署案例。
Agent-card spoofing 陷阱
这里有一个值得直接点名的陷阱。Agent-card spoofing 是一种攻击，恶意 agent 通过提交伪造的 card 来冒充另一个 agent 的能力。缓解方式是 JWS 签名——但要注意其中的细微差别：签名说明 card 是真实的，**并不说明 agent 会按其声明行事。**这就是为什么来自外部 agent 的数据，包括它的 Agent Card，都应该被视为不可信输入。
建议是：基于 A2A 构建通信，使用已签名的 Agent Cards 和传输层授权。需要 E2EE 时部署 SLIM；在密集 mesh network 中使用 AGP；ANP 仅用于观察；完全跳过 ACP，因为它已被弃用。当 agent 能够对话并使用工具后，问题就变成：如何把这一切展示给屏幕另一侧的人类？
第 3 层——Agent UI：AG-UI 承载，A2UI 绘制
第三层受困于容易混淆的首字母缩略词问题，所以我们先立即厘清。AG-UI 是一个基于事件的协议，用于将 agent 连接到用户应用——client 发送查询，并监听 typed events 流。A2UI 是一种 generative UI 规范——agent 发送声明式组件描述，而不是代码，client 使用原生 widgets 渲染它。形象地说：AG-UI 是 agent 实时与屏幕交流所通过的线缆，而 A2UI 是对该屏幕应呈现内容的描述。
Agent 需要专门的接口层，是因为一个具体原因：它们需要长生命周期、双向连接，而不是经典的 REST request/response。AG-UI 标准化了事件流：response streaming、shared state（agent 与 frontend 之间共享的双向状态）以及 human-in-the-loop interrupts——在 agent 执行动作前由人类批准的暂停点。这意味着一组标准事件类型，从消息片段到工具调用开始。
互补，而非竞争
A2UI 是互补而非竞争关系——这是这一层的核心。它将组件树描述为数据，并在 React、Flutter 或 Angular 中原生渲染。关键属性是：**A2UI payload 在 AG-UI event 内传输。**一个负责承载，另一个负责绘制。尽管名称相似，这些协议是互补的，而不是争夺同一个角色。
就成熟度而言，AG-UI 今天走得更远。它已经通过 Microsoft Agent Framework 和 AWS Bedrock AgentCore 的集成达到临界规模，这在实践中意味着企业级 GA。A2UI 在早期版本中已经稳定，并且与框架无关，但没有可比的部署规模。唯一真正的风险是独立演进——A2UI 在 Google 旗下，AG-UI 在 CopilotKit 旗下——以及未来可能出现的功能重复。
建议是：今天就部署 AG-UI 作为 agent–frontend 交互运行时；它能消除从零编写自定义 WebSocket 协议的需求。在 generative UI 能带来真实价值的场景试点 A2UI，将其作为 payload 放进 AG-UI stream 中，并预期规范会发生变化。现在，agent 已经有了工具，能够与其他 agent 和用户交流——最难的一层仍然存在：当它想花钱时怎么办。
第 4 层——Agent 支付：五个协议，没有赢家
这是 agent 自主付款的一层——也是协议栈中最年轻、最碎片化的部分。五个协议，各自处于不同层级，目前还没有明确赢家。有些押注 crypto wallets，有些押注 card networks——而目前，整个体系主要适用于机器为 API 访问向机器付款的场景，而不是你买鞋的场景。
关键在于区分层级，因为这些协议**并不是一对一竞争者。**x402 运行在 rail 层——它复活了 HTTP 402 “Payment Required” 状态码，该状态码在 HTTP 早期（RFC 1945，1996）被保留，并延续到 RFC 2068：server 返回带有支付条件的 402，agent 签署一笔 USDC stablecoin 支付，结算在链上数百毫秒内完成。AP2 运行在更高的授权层：它是一串已签名的 mandates——Intent、Cart、Payment——也就是用户同意的证明，形成可审计轨迹。UCP 由 Google 和 Shopify 开发，覆盖从搜索到结账的完整购买周期。身份层有两个 card-network 协议：Visa TAP 在 HTTP headers 中签署 agent identity（基于 RFC 9421，HTTP request signing），而 Mastercard Verifiable Intent 使用 SD-JWT——一种支持选择性字段披露的 token。
可用于生产，还是炒作
现在是最难的部分：可用于生产，还是炒作。答案取决于用例。对于 machine-to-machine micropayments，x402 是真实存在的——根据 Coinbase 数据（厂商报告，2026 年 4 月测量），它处理了超过 1.65 亿笔交易，总量约 5000 万美元——这些是动态数字，不同来源会根据时间段和方法论报告不同数值。
对于零售 agentic commerce，它仍然是试点。将 x402 部署在消费级应用中的从业者描述了同一个约束：协议只管理交易本身，而不管理完整业务逻辑——定价、退款和账单。这并不矛盾。这是两个不同条件产生的两个不同结果：x402 的大多数真实交易量来自 AI compute 的 micropayments，而不是消费者购买。
这一层的其余部分甚至更早。AP2、UCP、Visa TAP 和 Mastercard VI 大多还是预览、草案和 2026 年试点，采用数字是厂商报告，未经审计验证。还有监管障碍：x402 对 hot wallets 中 USDC 的依赖，在欧盟 MiCA 制度下是一个真实的合规问题。Chargeback 机制和争议解决——传统 card payments 的基石——在这里仍未经检验。
建议有意保持谨慎：**在支付层，做试点，不要构建业务。**将 x402 用于 API billing 和 AI compute 试点，设置预算，并有意识地管理 USDC custody。将 AP2 mandate 模型保留在 reference architecture 中，因为 TAP、VI 和 UCP 可以与它组合。只有当一个标准出现，并具备可工作的争议处理和 chargebacks 时，才在这里构建生产级零售业务。支付层有五个协议仍处于试点，而通信层正在一个 foundation 下整合——这种对比比任何单一规范都更能说明整个协议栈的状态。
管道并非中立：整合、碎片化与攻击面
HTTP 和 TCP/IP 的类比贯穿了整篇文章，但它有一个边界——值得在有人不加批判地接受之前点明。互联网的管道是哑的，对其中流动的内容漠不关心。Agent 管道承载指令和支付授权——工具描述、Agent Cards、mandates——所以有人可以投毒。这是根本差异：在 agent 协议栈中，payload 本身就是攻击面。
整合 vs 碎片化：不同层有不同动力学
首先，不同层之间有一个很容易被误认为悖论的对比。通信层正在整合——ACP 被 A2A 吸收，发现基础设施和 MCP 本身迁入 Linux Foundation。支付层却同时在增殖——TAP、VI、UCP、AP2 和 x402 并行发展。这不是同一层内部的矛盾，而是不同层拥有不同动力学：协议栈底部成熟并集中，顶部仍在实验。只要记得成熟度越接近金钱越低，这就很自然。
已被测量的威胁
Payload 的可攻击性不是假设。MCPTox benchmark（Wang et al., arXiv:2508.14925）在真实 MCP servers 上测量了这一点：o1-mini 模型达到了 72.8% 的攻击成功率——在近四分之三的尝试中，工具描述中的恶意指令成功通过。矛盾的是，更强的模型有时更脆弱，因为攻击利用的正是模型对指令的服从性。
也有已记录案例。被检测到的恶意 npm package postmark-mcp 是典型的 supply-chain attack：攻击者以相同名称发布了原始 Postmark Labs library 的伪造副本，代码几乎完全相同——只改了一行，悄悄把每封发送邮件 BCC 给攻击者。Package signature 并不能说明其行为。
每一层都有自己的向量。MCP——tool poisoning 和 shadow servers，后者指未经 IT 部门知晓而部署的未授权 servers。A2A——agent-card spoofing 和 replay。支付——rug-pull（工具定义或 server 在批准后被更改）以及未授权支出。基础设施的响应包括 KYA（Know Your Agent）——一种将 agent wallet 绑定到可验证法律实体的框架，可视作“agent 的数字护照”。
给架构师的结论清晰而严峻：**标准化不等于安全。**通信在一个 foundation 下整合，并不意味着支付是安全的——那是不同层，有不同动力学。为每一层设计防御：底部使用 MCP Gateway，中间使用 signed Agent Cards，顶部使用 spending caps 和 human approval。每个 server 和每张 card 都是审计和 sandboxing 的候选对象，而不是中立管道的一部分。现在我们已经知道什么准备好了、什么正在增殖、什么可被攻击——还剩一件事：把所有内容放进一张决策表。
推荐栈：部署什么、关注什么、跳过什么
四层，一个模式——整张地图被压缩成一个你会反复回看的决策。协议栈底部已经可用于生产，顶部仍处于试点，成熟度从工具向金钱递减。以下是你可以贴在办公桌上方的推荐栈。
今天部署——MCP（始终放在 MCP Gateway 模式之后）、A2A（使用 signed Agent Cards）、AG-UI（作为接口运行时）。
持续关注——SLIM、A2UI、x402、AP2、UCP、Visa TAP、Mastercard VI、AGP、ANP。每个都有具体升级条件：需要 E2EE 时使用 SLIM，mesh network 变得密集时使用 AGP，M2M micropayments 进入产品时使用 x402。
忽略——ACP。它已被弃用；将所有内容迁移到 A2A。
为每一层设计防御——标准化不等于安全；每个 server 和每张 card 都是不可信输入。
这张地图在架构师的日常工作中究竟改变了什么？它给你一个将支付从试点升级到生产的触发条件——出现一个具备可工作争议处理和 chargebacks 的标准。它给你一个决策规则：评估层及其成熟度，而不是围绕某个首字母缩略词的炒作。支付的碎片化不是混乱——而是一个不成熟层的自然状态。
感谢你和我一起走完整个协议栈的四层——这是很密集的材料，我很感谢你投入的时间。如果这张地图改变了你对 agent 协议层的思考方式，请把它转给其他正在做这些决策的人。欢迎留言告诉我你自己正在部署哪一层，以及这个协议栈最让你意外的地方。