2026年做 Agent 相关项目的人几乎绕不开两个缩写MCP 和 A2A。MCP 这边生态铺天盖地各家 IDE、浏览器、数据库、甚至安全测试工具都在往上面靠A2A 那边则有 Google 和 Linux Foundation 背书主打 Agent 之间的直接对话。社区里天天有人问“到底哪个是终极标准”“我该学哪个”我看过几十个技术群和帖子争论到最后往往变成站队。作为一个从 2024 年底就开始折腾 MCP又在 2025 年跟着 A2A 规范改了好几版代码的开发者我想把这两个协议的定位、边界、落地方式和未来的格局讲清楚。这篇内容不站队只讲工程上怎么选、怎么用、怎么避坑希望能让正在做 Agent 架构选型的人少走弯路。1. 先把两个协议的角色搞清楚再谈谁赢1.1 MCP 的底层定位把工具接进模型上下文MCP全称 Model Context Protocol由 Anthropic 在 2024 年 11 月开源。它要解决的核心问题非常朴素大模型应用每次要对接一个新的数据源或工具都得重新写一遍集成代码。数据库一个连法、浏览器自动化一个调法、企业内部系统又是一个协议这种“点对点集成”在 Agent 数量多起来之后根本维护不动。MCP 做的事情就是把这些工具统一成一个标准接口让模型通过一个通用协议去“摸”到它们。MCP 的架构里有一个关键角色划分Host 是承载 Agent 的应用程序比如我们开发的客户端、IDE 或者自动化平台MCP Client 负责与某个 MCP Server 建立一对一连接MCP Server 则把具体能力暴露出来。能力分为三类Tools 是让模型可以执行动作的东西比如查订单、写数据库、控制浏览器Resources 是让模型可以读取的上下文数据按 URI 定位Prompts 是预置的提示词模板方便复用一套交互逻辑。整个通信基于 JSON-RPC 2.0走了 initialize 握手、能力协商、功能调用这几个阶段。我自己的理解是MCP 本质上做了件很像“USB-C 标准化”的事情。以前每个设备都有自己的充电口现在大家统一成 Type-C插上就能用。MCP 就是模型和工具之间的 Type-C。到 2025 年OpenAI 宣布支持 MCPGoogle 在 Gemini 相关产品里也接入了 MCP微软的 Copilot Studio 同样把它纳入进来。再加上社区里冒出来的 Playwright MCP、Chrome DevTools MCP、Burp Suite MCP 这类开发者工具接入你基本可以感受到在“Agent 怎么调用工具”这一层MCP 已经成了事实标准。1.2 A2A 的底层定位让智能体之间能互相派活A2A全称 Agent2Agent Protocol是 Google 在 2025 年 4 月的 Cloud Next 大会上提出来的随后捐给了 Linux Foundation拉上了微软、Salesforce、SAP、埃森哲等五十多家企业一起做。它解决的是另一个问题Agent 和 Agent 之间怎么发现对方、怎么发起对话、怎么把任务委托出去、怎么同步执行状态。A2A 的规范里有一个核心概念叫 Agent Card。每个 Agent 在公网或内网的一个 URL 上发布自己的卡片上面写明这个 Agent 叫什么、能干什么、有哪些技能、支持什么传输模式和认证方式相当于一个“Agent 简历”。客户端 Agent 拿到这张卡片就知道该不该找它做事、用哪种方式找它。然后是任务模型A2A 把一次交互抽象成 Message、Task、Artifact、Part 这些概念。你可以把一个 Task 理解为一次“派活”比如“帮我查这几笔订单的物流状态”这个任务的状态可能从 submitted 变成 working再变成 completed中间还能推送通知。而 Artifact 是任务做完后生成的结果文件或结构化数据。这个协议给我的感觉更像 HTTP 之于网页。HTTP 本身不管网页内容是什么它只负责让浏览器和服务器之间按照统一规则交换请求和响应。A2A 也不关心两个 Agent 的业务细节它只负责让一个 Agent 把任务交给另一个 Agent并且把结果拿回来。类比一下MCP 管的是“模型的手”A2A 管的是“Agent 的嘴和耳朵”。1.3 一句话总结差异一个管手一个管嘴很多人误以为 MCP 和 A2A 是同一层的东西所以才会纠结二选一。实际上两者关注的层次完全不同。MCP 的典型交互模式是客户端进程与本地或远程的工具服务之间通信核心抽象是“工具调用”A2A 的典型交互模式是客户端 Agent 与远程 Agent 之间通信核心抽象是“任务委托”。我整理了一张对比表方便直接看到差异维度MCPA2A发起方模型应用 / Host客户端 Agent对端工具、数据源、系统另一个独立 Agent核心抽象Tools、Resources、PromptsAgent Card、Task、Message、Artifact主要动作tools/call、resources/readtask/send、task/get、task/cancel传输stdio 或 Streamable HTTPHTTP(S) JSON-RPC 2.0状态模型偏同步请求响应支持长任务状态机典型场景让 Agent 查库、发消息、操作浏览器客服 Agent 把工单转给订单 Agent从协议目标上想MCP 要消灭的是“工具接入的重复劳动”A2A 要消灭的是“Agent 之间协作的重复劳动”。它们不仅不互斥还天然能形成上下游组合。一个 Agent 内部用 MCP 去控制各种工具对外用 A2A 去和其他 Agent 沟通这恰恰是 2026 年很多成熟 Agent 系统已经在跑的架构。所以问题不该是“谁取代谁”而该是“我这一层该用谁”。2. 2026 年为什么这事值得重新讨论2.1 Agent 应用从单机单能走向多体协同2025 年大量落地的 Agent 项目本质上都是“单 Agent 工具”的模式一个模型实例通过 MCP 调一批工具处理一类任务。这种模式在垂直场景里很好用但很快会遇到天花板。比如一个企业服务 Agent它既要查客户信息、又要查库存、还要触发审批流程如果全部塞进同一个 Agent 的上下文里提示词会越来越臃肿工具列表越来越长模型决策的准确率和响应速度都会被拖累。于是多 Agent 编排开始成为刚需。把任务拆给不同的 Agent每个 Agent 专注一个领域再让它们协作完成一个复杂目标。这一拆问题就来了Agent 之间用什么语言说话A 怎么知道 B 有哪些能力A 把任务派给 B 之后怎么知道 B 干到哪一步了这些不是模型能力问题是通信规范和协作机制问题。2026 年讨论 A2A本质上是在讨论多 Agent 系统的基础设施。当一个系统里 Agent 数量上了两位数你不可能还靠人肉约定每个接口的格式必须有一个大家都认的协议来兜底。MCP 在这个阶段依然重要因为它决定了每个 Agent 内部能触及多少工具、多快触及。但单靠 MCP 解决不了 Agent 之间的横向协作。你可以把 MCP 想象成每个 Agent 的“手”而 A2A 是让这些“手”的主人能互相打招呼、派任务的“语言”。两件事是同一个方向上的不同层级只是正好都卡在了 2025 到 2026 这个时间点上爆发。2.2 各家大厂的押注与博弈观察 2025 年一整年的动作会发现大厂并没有在“MCP 还是 A2A”之间站队而是在做组合布局。Anthropic 手握 MCP 的主场优势但它的 Claude 也支持调用 A2A 兼容的 AgentGoogle 主导 A2A但它的 Gemini API 同样兼容 MCP 工具调用微软则是典型的“两头下注”Copilot Studio 里 MCP 和 A2A 都有对应的集成路径OpenAI 先是在 2025 年宣布支持 MCP同时也在推自己的 AgentKit 和 agent 编排能力后来还发布了 A2A 相关的研究方向。这种局面说明一个事实没有任何一家愿意让对手掌握唯一的协议入口。大家都清楚谁定义标准谁就在生态里卡住最好的位置。但正因为谁都不让谁2026 年出现“一个协议消灭另一个”的概率反而极低。更可能出现的结果是多个协议在各自层次上成为事实标准中间靠网关、适配层和跨协议框架来桥接。对我们做 Agent 开发的人来说这种博弈带来的直接感受是架构上不要和某一个协议的版本绑死。接口层做抽象协议层做适配这样 2026 年上半年用 A2A 0.3 的规范下半年它迭代到 0.4 甚至 1.0你的业务代码也不用大改。2.3 “终极标准”这个说法本身可能是个伪命题很多人喜欢问“MCP vs A2A 谁是终极标准”我现在的看法是这个问题问错了方向。互联网几十年来从没有靠“一个协议包打天下”运转过。TCP/IP 管传输、HTTP 管文本交换、SMTP 管邮件、WebSocket 管长连接它们在不同层次上各自成为标准谁也不取代谁。Agent 协议大概率也会走同样的分层路径。我判断 2026 年的格局会是这样工具接入层MCP 继续保持事实标准的地位因为它的模型最简单、SDK 最全、社区 server 数量已经足够庞大Agent 协作层A2A 最有可能成为默认选项因为它背后有 Linux Foundation 这样的中立组织又有大厂集体背书规范迭代也很快。而在更上层的 Agent 编排框架里开发者不需要直接手搓协议框架会同时支持 MCP 和 A2A把它们当成两种可插拔的连接器。这样一来“终极标准”就变成了一个伪命题。真正需要你决策的只是“我的 Agent 在哪个环节需要哪种标准化”。想清楚这一点比争论谁的名字更响有价值得多。3. 一个真实场景看 MCP 与 A2A 怎么配合3.1 场景设定企业客服系统里的三 Agent 协作说一个我实际搭过的企业级场景方便你直观理解。假设一家电商公司要做一套智能售后系统里面有三个 Agent客服 Agent 负责和用户对话理解用户诉求订单 Agent 负责查询订单、变更物流状态、对接库存系统审批 Agent 负责处理退款、补偿等需要走流程的操作。用户的典型诉求是“我上周买的订单还没发货帮我催一下如果今天发不了就退款”。这个诉求如果只用一个 Agent 硬扛不仅提示词巨大而且退款审批这种敏感操作混在对话模型里安全边界很难控制。所以我把它拆成了三层最上层是面向用户的客服 Agent中间是负责具体业务领域的订单 Agent 和审批 Agent最底层则是各个业务系统包括 CRM、ERP、数据库、工单平台。这里最底层的系统接入我全部走 MCP中层 Agent 与 Agent 之间的协作走 A2A。下面分别展开讲每一层的实际配置。3.2 接入层用 MCP统一工具调用我先在订单 Agent 内部挂了好几个 MCP server。CRM 一个、ERP 一个、数据库一个每个 server 负责暴露自己领域内的工具。比如 ERP 的 MCP server 暴露了 query_order_status、modify_delivery_priority、create_refund_request 这几个工具。订单 Agent 的 MCP Client 在启动时做一次握手然后通过 tools/list 拉取工具清单再在需要时用 tools/call 触发具体动作。这个流程用 Python 伪代码描述大概是# 示意代码MCP 客户端流程 client MCPClient( transportstreamable_http, urlhttp://erp-internal.example.com/mcp ) # 1. 握手协商协议版本和能力 client.initialize( client_nameorder-agent, protocol_version2025-06-18, capabilities{tools: {}} ) # 2. 获取工具清单让模型知道有哪些能力可用 tools client.request(tools/list) # 输出示例 # [ # {name: query_order_status, inputSchema: {...}}, # {name: modify_delivery_priority, inputSchema: {...}} # ] # 3. 模型决定调用某个工具把结果追加回上下文 result client.request(tools/call, { name: query_order_status, arguments: {order_id: A10086} })这里有个细节MCP 在设计上其实对模型很友好。工具返回的原始数据会作为新的上下文消息追加给模型所以模型不需要自己维护外部状态只需要根据返回内容继续推理。这也是 MCP 能快速铺开的原因之一接入成本低模型侧几乎零改造。把底层系统统一接到 MCP 之后订单 Agent 内部就有了完整的信息触达能力专心做业务决策就好了。我在实践中倾向于让每个 MCP server 的职责单一化。比如订单类工具一个 server库存类一个 server不要搞一个“万能 server”把所有工具都塞进去。一是因为 tool 列表过长会稀释模型对工具选择的准确率二是因为单一职责的 server 更容易做权限控制和独立升级。3.3 协作层用 A2AAgent 间派活与状态回传接下来是中层协作。客服 Agent 判断用户需要催发货它并不直接操作 ERP而是通过 A2A 把任务委托给订单 Agent。做法是先从订单 Agent 的 Agent Card 里发现它的能力和通信地址然后发一个 task/send 请求。Agent Card 是 A2A 规范里非常关键的东西我在订单 Agent 的对外 HTTP 端点上放了一个卡片文件内容大致如下{ name: 订单处理 Agent, description: 负责订单查询、催发货、物流变更和退款申请, url: https://agent.internal.example.com/order, capabilities: { skills: [ { id: check_and_expedite, name: 检查订单并发起催发货, description: 根据订单号检查发货状态必要时触发优先发货流程, inputModes: [text], outputModes: [text, file] } ], stream: true, pushNotifications: true }, security: { schemes: [ {type: oauth2, endpoint: https://auth.internal.example.com/token} ] } }客服 Agent 读取这个卡片后确认订单 Agent 具备 check_and_expedite 这个技能于是发起一次任务调用{ jsonrpc: 2.0, id: 1, method: task/send, params: { id: task-A10086-expedite, message: { role: user, parts: [ {text: 订单 A10086 已延迟发货请检查状态并触发催发货流程。如果今天无法发出请准备退款审批。} ] } } }订单 Agent 收到任务后先返回一个 working 状态然后内部通过 MCP 查 ERP、修改发货优先级再决定是否需要把退款审批转给审批 Agent。这里 A2A 的任务模型帮我省了很多事它自带状态机和异步通知机制。长任务不需要客户端一直请求挂着可以用 task/get 轮询也可以注册 webhook 等 pushNotification 推送结果。一开始我设计的时候有个困惑任务拆到什么粒度比较合适A2A 的 Task 是绑定一个“用户意图”粒度还是一个“操作动作”粒度踩过几次坑之后我的结论是Task 应该对应“一个可独立验收的业务结果”而不是对应“一次函数调用”。比如“催发货并确认结果”是一个 Task“更新数据库里的 priority 字段”不叫一个 Task那是 MCP 层 tools/call 该干的活。这样划分Agent 之间的契约才稳定状态机才不容易乱。3.4 两者各管一段灾难就少一半再聊聊如果边界没划清楚会怎样。我见过一个项目团队把 A2A 用在了模型和工具之间给数据库查询这类内部操作也套了 Agent Card结果每个查询都要先做 Agent 发现、再走任务状态机延迟翻了好几倍纯粹是拿大炮打蚊子。反过来也有人把 MCP 用在两个 Agent 之间把另一个 Agent 包装成一个 MCP server然后在提示词里要求模型调用它的 tools。短期能跑通但一旦任务变得复杂你就会发现 MCP 缺乏任务状态管理、缺乏异步通知、缺乏能力发现机制两个 Agent 之间的协作深度完全上不去。实践下来我的体会是MCP 应该尽量下沉保持简单直接让模型“伸手就能碰到工具”A2A 应该尽量上浮专门负责 Agent 之间的业务协同。中间这一层不需要重复造轮子只需要在 Agent 内部做一次协议翻译。客服 Agent 收到用户消息后内部推理决定“需要另一个 Agent 介入”就构造一个 A2A 任务发出去收到任务结果后再回到原来的对话流程继续对用户。每一层只解决自己那一层的问题整个系统的复杂度才不会失控。4. 实战避坑协议落地时的常见问题与排查技巧4.1 stdio 还是 Streamable HTTP两种 MCP 传输怎么选MCP 的传输方式大概率是你接入时遇到的第一个坑。早期 MCP 常用 stdio客户端启动一个本地子进程通过标准输入输出和 MCP server 通信。好处是部署简单、没有网络暴露面非常适合做本地的开发辅助工具比如在 IDE 里挂一个代码分析 server。但 stdio 的问题也很明显不能跨机器、不能做进程复用、调试起来麻烦。如果你的 MCP server 要部署在远程服务器上给多个 Agent 共用那就必须走 Streamable HTTP。这个传输模式在 2025 年的规范里已经取代了早期的 HTTPSSE 方案支持更灵活的流式更新握手逻辑也更干净。我建议一个判断标准server 和 client 是否在同一台机器是优先 stdio否直接 Streamable HTTP。另外如果需要把 MCP 能力暴露给外部团队或第三方系统Streamable HTTP 几乎是唯一选择因为别人不可能为你启动子进程。4.2 鉴权与安全边界别让协议替你扛安全协议只解决“怎么通信”不解决“能不能通信”。A2A 和 MCP 的规范里都允许在传输层之上加认证但具体怎么加完全看你自己。A2A 的 Agent Card 里有 security 字段可以声明 OAuth 2.0、OIDC 或者简单的 API KeyMCP 的 Streamable HTTP 也可以在 Authorization header 里带 Bearer Token。但我强烈建议生产环境里不要用裸 API Key 走公网尤其是 A2A 这种跨 Agent 通信Agent 会拿着你的任务请求到处转发凭据很容易泄露。我在实际部署里至少做了三件事第一MCP server 的 token 按工具域收敛比如订单工具只能访问订单数据库拿不到用户隐私库第二A2A 接口全部走网关网关做一次来源 Agent 身份校验再注入内部短时票据不让真正的外部请求直接打到内网 Agent第三所有 Agent 间通信都记录审计日志谁给谁派了任务、任务结果是什么必须可追溯。这里的安全边界本质上是业务边界一个 Agent 能做什么、不能做什么应该由企业权限模型决定而不是由协议来保证。4.3 任务超时与状态同步长任务别用同步思想A2A 落地时最容易踩的坑是超时。刚上手的时候我习惯性地以为 task/send 会同步返回最终结果结果发现返回的往往只是 submitted 或 working 状态真正的执行在后台继续。如果你用并发模式等在原地请求很容易超时。正确做法是区分短任务和长任务短任务几十秒内能完成可以轮询长任务可能持续几分钟甚至几小时必须依赖推送通知或者做异步等待。A2A 规范里给你两种主动获取结果的路径task/get 去查询任务状态或者通过 pushNotification 配置 webhook 接收任务完成事件。要注意的是webhook 地址要稳定接收端要幂等否则断网重试时会出现重复通知。另外task 的 id 要由发送方生成不要在接收方里随机生成否则客户端没法关联请求和结果。这个细节看似微小排查问题时却能省下大半天。4.4 服务发现与可观测性Agent 多了以后的基本功当系统里 Agent 只有三五个你可以手写配置文件去记对方的地址和 Agent Card。但 Agent 到十几个的时候服务发现就变得很重要。A2A 生态里比较常见的做法是维护一个 Agent 目录服务每个 Agent 启动时把自己注册进去客户端 Agent 按能力和描述去查询。这个目录可以自己搭也可以用开源的 registry 实现。我建议至少把 Agent Card 的版本号、所属业务域、能力标签这几项索引起来否则后面检索会非常痛苦。可观测性方面跨 Agent 调用比单 Agent 调用要难排查得多。任务在客服 Agent 发起传给订单 Agent订单 Agent 再调 MCP 工具链路中任何一环失败都需要知道卡在哪里。我现在的做法是每个 Task 都带一个全局 trace id进入每个 Agent 时把它们作为日志上下文注入这样从头到尾能串起来。否则你就只能对着几个 Agent 各自独立日志和数据库审计记录做人肉推理那种感觉可以称得上痛苦。我顺手整理一个常见问题速查表都是真实踩过的点现象可能原因优先排查思路MCP tools/list 拿不到任何工具server 与 client 协议版本不兼容检查 initialize 阶段版本号确认双方 sdk 版本A2A 请求一直卡在 working接收方 Agent 内部调 MCP 工具超时看接收方日志单独跑一次工具调用确认耗时webhook 收不到完成事件接收端地址不通或未注册检查 Agent Card 里 pushNotifications 是否开启任务明明成功但内存泄漏轮询 task/get 的频率过高连接未释放降低轮询频率优先改为 webhook 推送A2A 免密调通了但审计不过通信链路未走网关或没有 trace id补上统一身份注入与链路追踪4.5 版本迭代太快别把代码绑死在某一版规范上最后这一点我觉得特别值得提醒。A2A 规范在 2025 年经历了好几次较大的接口调整早期的 message/send、message/reply 在后续版本里演进成了 task/send、task/get 这一套。MCP 的传输方式也从 HTTPSSE 演进到 Streamable HTTP协议版本号从 2024-11-05 升级到 2025-06-18后面还有新的日期版本。如果你在代码里到处硬编码协议方法名和传输细节升级一次够你痛苦一周。我的做法是引入一层薄薄的协议适配器。业务代码只依赖一个抽象的服务接口比如 get_order_status(order_id)适配器内部决定是走 MCP 工具调用还是走 A2A 任务委托外部协作 deps 不清楚协议细节。这样协议升级时只需要改适配器业务逻辑不用动。2026 年各协议大概率还会继续演进保持接口的稳定把变化收窄到一个模块里才是长期可持续的做法。5. 我个人的选型建议与体会聊到这儿回到最初的问题MCP vs A2A2026 年谁才是终极标准如果你问我我会说在 Agent 内部工具接入这一层MCP 基本已经赢了在 Agent 之间协作这一层A2A 目前跑得最快但我不会把话说死。更让我在意的不是谁赢而是很多团队到现在还把这两个协议放在对立面上导致架构设计从一开始就走偏。我个人的建议很直接凡是“让模型触达工具、数据源、系统”的路径统一用 MCP保持工具层简单透明凡是“一个 Agent 向另一个 Agent 派活、要结果、追踪进度”的路径考虑用 A2A尤其是跨团队、跨系统甚至跨组织的协作。如果你已经在用某个 Agent 编排框架先别急着手写协议看看框架是否已经同时支持这两种连接器大概率能省掉大量重复工作。最后掏点实操经验。第一2026 年做 Agent 项目协议适配层一定要独立出来不要散落在业务代码里否则每轮协议升级都是煎熬第二先把 MCP 吃透它门槛低、见效快能帮你积累工具层的工程手感再上手 A2A 会顺畅很多第三不要一开始就追求“所有 Agent 都走 A2A”先把一个真实业务的跨 Agent 流程打通跑顺了再逐步扩大范围。协议只是手段能稳定、安全、高效地完成业务目标才是底线。希望这篇内容能帮你在铺天盖地的争论里找到适合自己的那条路。