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 个独立集成——每一个都需要编写、测试和维护。协议会一次性标准化双方因此数量降到 NM。这就是这场运动背后的全部直觉并在协议栈的每一层重复出现。这种模式有先例。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 层——工具和上下文MCPAI 的 USB-CMCP——Model Context Protocol——是一个开放标准用于将 LLM 应用连接到工具和数据。最简单的说法是一个像 USB-C 一样的通用端口AI 通过它接入任意工具或数据存储而不是为每个工具单独准备一根线缆。它存在的原因很明显——它解决了工具层的 N×M 问题。其机制是不对称且清晰的。架构中有三个角色Host例如 Claude 或 IDE、Client到一个 server 的一条连接和 Server后者暴露三类原语——tools、resources 和 prompt templates。消息通过 JSON-RPC 传输。今天的生产传输方式是 Streamable HTTP它取代了较早的 HTTPSSE在企业部署中还会加入 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 中使用 AGPANP 仅用于观察完全跳过 ACP因为它已被弃用。当 agent 能够对话并使用工具后问题就变成如何把这一切展示给屏幕另一侧的人类第 3 层——Agent UIAG-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 stateagent 与 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 19451996被保留并延续到 RFC 2068server 返回带有支付条件的 402agent 签署一笔 USDC stablecoin 支付结算在链上数百毫秒内完成。AP2 运行在更高的授权层它是一串已签名的 mandates——Intent、Cart、Payment——也就是用户同意的证明形成可审计轨迹。UCP 由 Google 和 Shopify 开发覆盖从搜索到结账的完整购买周期。身份层有两个 card-network 协议Visa TAP 在 HTTP headers 中签署 agent identity基于 RFC 9421HTTP request signing而 Mastercard Verifiable Intent 使用 SD-JWT——一种支持选择性字段披露的 token。可用于生产还是炒作现在是最难的部分可用于生产还是炒作。答案取决于用例。对于 machine-to-machine micropaymentsx402 是真实存在的——根据 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 benchmarkWang 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 在批准后被更改以及未授权支出。基础设施的响应包括 KYAKnow 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 时使用 SLIMmesh network 变得密集时使用 AGPM2M micropayments 进入产品时使用 x402。忽略——ACP。它已被弃用将所有内容迁移到 A2A。为每一层设计防御——标准化不等于安全每个 server 和每张 card 都是不可信输入。这张地图在架构师的日常工作中究竟改变了什么它给你一个将支付从试点升级到生产的触发条件——出现一个具备可工作争议处理和 chargebacks 的标准。它给你一个决策规则评估层及其成熟度而不是围绕某个首字母缩略词的炒作。支付的碎片化不是混乱——而是一个不成熟层的自然状态。感谢你和我一起走完整个协议栈的四层——这是很密集的材料我很感谢你投入的时间。如果这张地图改变了你对 agent 协议层的思考方式请把它转给其他正在做这些决策的人。欢迎留言告诉我你自己正在部署哪一层以及这个协议栈最让你意外的地方。这里给大家精心整理了一份全面的AI大模型学习资源包括AI大模型全套学习路线图从入门到实战、精品AI大模型学习书籍手册、视频教程、实战学习、面试题等资料免费分享扫码免费领取全部内容1. 成长路线图学习规划要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。这里我们为新手和想要进一步提升的专业人士准备了一份详细的学习成长路线图和规划。可以说是最科学最系统的学习成长路线。2. 大模型经典PDF书籍书籍和学习文档资料是学习大模型过程中必不可少的我们精选了一系列深入探讨大模型技术的书籍和学习文档它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。书籍含电子版PDF3. 大模型视频教程对于很多自学或者没有基础的同学来说书籍这些纯文字类的学习教材会觉得比较晦涩难以理解因此我们提供了丰富的大模型视频教程以动态、形象的方式展示技术概念帮助你更快、更轻松地掌握核心知识。4. 2026行业报告行业分析主要包括对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5. 大模型项目实战学以致用当你的理论知识积累到一定程度就需要通过项目实战在实际操作中检验和巩固你所学到的知识同时为你找工作和职业发展打下坚实的基础。6. 大模型面试题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我们将提供精心整理的大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。7. 资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容