别再盲目追 AI Agent 协议：真正该部署的只有这几层

关注

原创最新推荐文章于 2026-08-28 16:15:54 发布 299 阅读 AI 写同款· GEO 优化 ›

AI 工作流和AI Agent构建指南这些智能体能够自主感知、推理和行动，以追求特定目标，形成强大的集体智慧，可以打破孤岛，集成不同的数据源，并提供无缝的端到端自动化。如今随着AI应用的逐步深化应用和融合发展，一个新的工具应用而生，那就是工作流（Agentic Workflow智能体工作流\代理工作流）或AI agent，它们的结合正在重塑现代企业的运营模式，通过自动化、智能决策和效率优化推动数字化转型。针对这个问题，我们可以通过RAG（检索增强生成）来解决，即通过提供相关的、实时的外部数据来增强 LLM 的响应准确性**，但它仅限于。阅读详情

AI agent 协议栈的四层：MCP、A2A、AG-UI 和支付。今天该部署什么、该关注什么——面向 2026 年架构师的决策指南。

每个人都说集成 AI agent 就像集成任何其他 API 一样——但如果没有共享协议，每个模型乘以每个工具再乘以每个 agent，就会形成组合爆炸，也就是在团队交付任何有用成果之前就将其扼杀的 N×M 问题。这适用于所有在生产环境部署 agent 的团队：每一对新的模型–工具组合，都是一个需要维护的独立 bespoke connector。在过去十八个月里，也就是 2024 到 2026 年之间，一个分层的开放协议栈已经出现——类似 HTTP 和 TCP/IP——并且其关键层已经进入 Linux Foundation 旗下。

接下来的几分钟里，你将知道四层中哪些今天就该部署，哪些只需关注。你不仅会了解这些协议确实存在，还会理解为什么越接近用户和金钱，成熟度就越低。

Agent 协议栈：四层和一个横切基础设施——成熟度越接近用户越低。

栈图：四层，一个类比

关于这个协议栈，最重要的事实只有一个：越接近用户和金钱，成熟度就越低。基础层——工具和上下文——已经可用于生产，并且是事实标准。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 端口。

MCP 就像 USB-C：一个标准通过 servers 将 LLM 应用连接到任意工具。

第 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 能够对话并使用工具后，问题就变成：如何把这一切展示给屏幕另一侧的人类？

Agent-to-agent 通信：A2A 是标准，SLIM 是传输，AGP/ANP 是补充，ACP 已被吸收。

第 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 和用户交流——最难的一层仍然存在：当它想花钱时怎么办。

AG-UI 是事件流运行时；A2UI 是该事件流承载的界面描述。

第 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 下整合——这种对比比任何单一规范都更能说明整个协议栈的状态。

五个处于不同层级的支付协议：rail、authorization、commerce 和 identity——并非 1:1 竞争者。

管道并非中立：整合、碎片化与攻击面

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 的候选对象，而不是中立管道的一部分。现在我们已经知道什么准备好了、什么正在增殖、什么可被攻击——还剩一件事：把所有内容放进一张决策表。

每一层都承载可攻击的 payload——协议栈各层的威胁与缓解措施。

推荐栈：部署什么、关注什么、跳过什么

四层，一个模式——整张地图被压缩成一个你会反复回看的决策。协议栈底部已经可用于生产，顶部仍处于试点，成熟度从工具向金钱递减。以下是你可以贴在办公桌上方的推荐栈。

今天部署——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 协议栈。