这篇文章试图回答一个很具体的问题——当你真正开始搭Agent系统的时候MCP和A2A分别在什么环节介入什么时候只够用一个什么时候必须两个都上。先搞清楚一件事这俩不是竞品我在网上看到很多文章把MCP和A2A放在一起做对比评测最后给出一个结论说A2A是MCP的替代品或者谁更强。这个理解从根本上就是错的。MCP解决的是Agent和工具之间的连接问题。你的Agent要查数据库、调API、读写文件这些动作都需要一个统一的接口协议MCP就是干这个的。它解决的是每个工具都要定制对接这个工程痛点。A2A解决的是Agent和Agent之间的通信问题。你有一个负责检索的Agent、一个负责支付的Agent、一个负责物流的Agent它们来自不同的团队甚至不同的公司需要一种标准化的方式互相发现、互相通信、互相协作A2A就是干这个的。一句话总结MCP是Agent的手让它能操作工具A2A是Agent的嘴让它能和别的Agent说话。这两层是正交的。你需要Agent操作工具就用MCP你需要Agent之间协作就用A2A你的系统又需要操作工具又需要Agent之间协作就两个都用。不存在选MCP还是选A2A这种问题真正的问题是你的系统到底需要到哪一层。MCP2026年7月刚经历了一次大重构如果你上次看MCP还是半年前的文章那你需要重新了解了。2026年7月28日MCP发布了有史以来最大的一次架构更新核心变化是从有状态协议变成了无状态协议。这个改动听起来是个工程细节但实际上解决了一个很致命的问题。旧版MCP是有Session的。客户端连上服务端之后要先握手initialize/initialized服务端返回一个Session ID之后所有请求都带着这个ID。这意味着服务端必须记住这个Session的状态你不能随便加机器做负载均衡一台Pod挂了整个会话就丢了。企业基础设施团队问MCP服务能不能像普通微服务一样水平扩缩容答案一直是不太能。新版MCP彻底去掉了Session。每个请求都是独立的自己携带协议版本、客户端身份和能力信息。服务端不需要维护任何状态随便丢到负载均衡器后面Cloudflare Workers、Vercel这种Serverless平台也能直接跑。MCP的维护者Mazin Gilbert自己也说了有状态Session是企业从试点走向大规模部署的首要障碍。除了去Session之外还有几个关键变化值得关注Multi Round-Trap RequestsMRTR以前如果工具执行到一半需要问用户一个确认必须依赖一个长连接让服务端反向回调客户端。现在不用了服务端可以返回一个input_required的响应客户端收集到用户输入后重新发起请求整个过程不需要保持连接。Header路由请求里强制带上Mcp-Method和Mcp-Name这两个Header你的网关、限流器、WAF可以直接根据Header做路由和鉴权不用去解析JSON Body。缓存友好tools/list、resources/list这些响应现在带了TTL和缓存策略而且顺序是确定性的客户端可以安全地缓存工具列表不用担心重连之后缓存失效。从生态数据来看MCP在不到两年的时间里做到了GitHub上15900多个MCP Server相关仓库、SDK月下载量接近5亿次、TypeScript和Python SDK各自累计突破10亿次下载、官方Registry登记的Server接近1万个。全球41%的软件组织已经在生产环境中使用了MCPStacklok 2026报告数据。这个 adoption 速度在基础设施协议里算是非常快的。MCP新版协议的代码长什么样为了让大家有个直观感受看一下新版MCP的请求格式。去掉了Session之后每个请求都变成这样的POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search Content-Type: application/json { jsonrpc: 2.0, id: 1, method: tools/call, params: { name: search, arguments: {q: otters}, _meta: { io.modelcontextprotocol/clientInfo: { name: my-app, version: 1.0 } } } }注意到几个关键点没有Session ID没有initialize握手Mcp-Method和Mcp-Name作为Header直接暴露给网关。这个请求可以被丢到任何一台服务器后面处理不需要sticky session。如果你的工具需要跨调用保持状态比如一个购物车新版规范的建议是让服务端返回一个handle比如basketId客户端在后续调用中作为参数传回来。状态从隐藏在协议层变成了暴露在业务参数中——看起来多了一步实际上更好调试因为你在请求日志里就能看到这个handle的传递链路。如果你之前已经基于旧版MCP写了Server迁移的主要工作是去掉initialize/initialized处理、去掉Mcp-Session-Id的生成和校验、把需要跨调用保持的状态改成显式handle。TypeScript和Python SDK都提供了迁移指南大部分改动是机械性的。A2A一年过去了落地情况怎么样A2A是Google在2025年提出的到现在也过了一周年。它的核心设计思路是Agent Card——每个Agent通过一个公开的JSON文件通常放在.well-known/agent.json声明自己的能力、认证方式和输入输出格式。别的Agent想跟你协作先读你的Agent Card知道你能干什么、怎么认证然后按A2A定义的消息格式发起Task。A2A的Task有明确的生命周期submitted → working → input-required → completed/failed。这个设计比MCP成熟的地方在于它从一开始就是为跨组织、跨信任域的场景设计的内置了OAuth授权、RBAC权限控制和签名验证。截至2026年中A2A协议已经有超过150个组织在生产环境部署。Google把它捐给了Linux Foundation目前和MCP同属Agentic AI Foundation管理。A2A 1.0版本加入了签名的Agent Card支持加密身份验证。但说实话A2A的落地速度比MCP慢。原因也很直接大多数团队现阶段做的Agent系统主要需求是让一个Agent能调用一堆工具还没到需要多个Agent跨组织协作的阶段。A2A解决的是一个未来一定会遇到但现在很多团队还没遇到的问题。A2A的Agent Card实际长什么样Agent Card是A2A的核心概念理解它基本就理解A2A一半了。一个简单的Agent Card文件通常放在.well-known/agent.json大概长这样{name:flight-booking-agent,description:查询航班、比价和预订机票,url:https://api.travel-agent.com/a2a,version:1.2.0,organization:TravelCo,capabilities:{streaming:true,pushNotifications:false},authentication:{schemes:[oauth2],credentials:{tokenUrl:https://auth.travel-agent.com/token}},skills:[{id:search-flights,name:航班搜索,description:根据出发地、目的地和日期搜索可用航班,inputModes:[application/json],outputModes:[application/json]},{id:book-flight,name:机票预订,description:预订指定航班需要支付确认,inputModes:[application/json],outputModes:[application/json]}]}几个设计决策值得注意第一凭证credentials不在Agent Card里。Agent Card只告诉你去哪里拿tokentokenUrl不告诉你token本身。这避免了把敏感信息暴露在一个公开文件里。第二skills列表是Agent Card的核心。它不是简单的我能做什么而是每个skill都有明确的输入输出格式定义。这让调用方的Agent可以自动判断自己能不能用这个skill——如果你的输入格式不匹配根本不需要发起请求。第三version字段是必须的。跨组织协作最怕的就是接口悄悄变了版本号让调用方可以锁定兼容的版本。A2A的Task生命周期也值得一提。一个典型的交互流程是调用方发起Tasksubmitted→ 被调用方开始处理working→ 如果需要更多信息返回input-required让调用方补充 → 最终返回completed或failed。这个设计跟传统API的request-response模式最大的区别是它是异步的。一个Task可以跑几分钟甚至几小时调用方通过轮询或者push notification获取结果。这在Agent场景中很常见——一个复杂的Agent任务不可能在几百毫秒内完成。实际怎么选看你的系统架构到了哪一层说了这么多背景回到最核心的问题你该怎么选。我把常见的Agent系统分成四个层级你对照自己的需求判断就行第一层单Agent 本地工具如果你的Agent就是在一个进程里跑调用的是本地文件系统、本地数据库、本地函数那MCP和A2A都不需要。你直接写函数调用就行加协议层是过度设计。这个阶段该关心的事情是Prompt工程、工具描述的准确性、错误处理和重试逻辑。第二层单Agent 远程工具/多工具源如果你的Agent需要调用远程API、连接多个数据源或者你想让同一个Agent在不同框架里复用同一套工具这时候该上MCP了。MCP的价值在这里体现得很明确你写一次MCP Server任何支持MCP的Agent框架都能直接用。不用给LangChain写一套集成、给CrewAI写一套集成、给自研框架再写一套。典型场景你的Agent需要同时查PostgreSQL、调内部REST API、读写本地文件你想把公司内部的工具统一封装成MCP Server让不同团队的Agent都能用你在用Claude Desktop、Cursor这类工具想接入自定义数据源这里有一个容易踩的坑值得说一下。MCP的工具定义会被完整塞进LLM的上下文窗口里。如果你的Server暴露了太多功能相似的工具比如get_user_by_id、get_user_by_name、get_user_by_email这三个模型经常选错。MCP生态里有个说法叫tool sprawl就是工具目录膨胀导致模型选择准确率下降。解决方案是在Server端做工具合并把相似操作合并成一个工具通过参数区分而不是分成三个工具。第三层多Agent协作同一系统内如果你的系统里有多个Agent分工协作——比如一个负责检索、一个负责推理、一个负责执行——但它们跑在同一个系统里、同一个信任域内这时候你有两个选择选项A不用A2A用你框架原生的多Agent机制。LangGraph的state graph、CrewAI的role-based crew、或者你自己写的Supervisor-Worker模式。大多数情况下这就够了。选项B用A2A来定义Agent之间的通信协议。好处是Agent之间的接口标准化了你替换某个Agent的实现比如把检索Agent从LangChain换成LlamaIndex不需要改其他Agent的代码。坏处是多了一层抽象调试复杂度上升。我的建议是如果你的团队不超过5个人、系统不超过10个Agent用框架原生机制就够了。A2A在这个阶段的收益不明显。第四层跨组织Agent协作当你的Agent需要和外部组织的Agent协作时A2A才真正成为刚需。比如你的电商平台的订单Agent需要和供应商的库存Agent、物流公司的调度Agent协作你在做一个行业联盟多家企业的Agent需要互相发现、互相调用你想发布一个Agent服务给外部开发者使用这些场景下A2A的Agent Card机制非常有用外部Agent读你的Agent Card就知道你能干什么、怎么认证、输入输出格式是什么不需要看文档、不需要对接口。另外一个容易忽视的点安全模型差异。MCP在设计上对安全是可选的规范里Authorization不是必须的。有安全研究者测试过恶意MCP Server可以在工具描述里嵌入隐藏指令tool poisoning攻击在某些基准测试中攻击成功率达到了100%。MCP新版规范在OAuth 2.1和CIMDClient ID Metadata Documents方面做了加强但在实际部署中很多Server还是没有启用鉴权。A2A从一开始就把安全当成核心设计要素Agent身份在HTTP传输层管理、凭证不暴露在Agent Card中、v1.0支持签名验证。如果你做的是跨信任域的系统A2A的安全模型明显更成熟。五个真实架构场景帮你判断该用哪个光说层级有点抽象我再给五个具体的场景每个场景直接告诉你该用MCP、A2A还是都不用场景一客服Agent查订单状态和发起退款一个Agent查数据库、调内部API都是工具调用。只需要MCP。不需要A2A因为没有别的Agent参与。这个场景占了目前大多数团队80%的工作量。场景二RAG检索Agent动态查多个知识库一个Agent需要根据用户问题动态选择查哪个知识库——产品文档、FAQ、技术手册。每个知识库是一个MCP ServerAgent根据问题语义选择调用哪个。只需要MCP。但这里有个陷阱如果你的知识库很多比如50个全部作为MCP工具列出来模型的上下文会被工具定义撑爆选择准确率也会下降。解决方案是在MCP前面加一层语义路由——先用embedding匹配最相关的5个知识库再只把这5个作为MCP工具暴露给模型。这个模式目前还没有标准实现但很多团队已经在用了。场景三公司内部多个Agent分工处理一个工单比如一个IT工单系统分诊Agent判断问题类型 → 网络Agent排查网络问题 → 系统Agent检查服务器状态 → 汇总Agent生成报告。这些Agent都在同一个公司内、同一个信任域。这种情况不需要A2A。用LangGraph的state graph或者自己写一个状态机就够了。A2A的Task生命周期、Agent Card这些机制在单组织内部是多余的。你应该把精力放在Agent之间的任务编排、错误传播和结果聚合上。场景四你的采购Agent和供应商的库存Agent协作下单两个Agent分属不同公司各有各的系统和权限规则。你的采购Agent通过MCP查你自己的ERP系统供应商的库存Agent通过MCP查它的仓储系统。两个Agent之间通过A2A通信你的Agent发起一个采购订单Task供应商的Agent接收后查库存、预留货物、返回确认。这是MCP和A2A必须同时上的典型场景。缺MCPAgent没法操作各自的内部系统缺A2A两个Agent没法跨组织通信。场景五浏览器自动化Agent帮用户完成网页操作一个Agent打开浏览器、点击按钮、填表单、抓数据。这是纯本地操作既不需要MCP操作的是浏览器而不是API也不需要A2A。这类场景用browser-use、Playwright MCP这类工具更直接。不过要注意如果这个浏览器Agent需要和别的Agent协作比如抓取数据Agent抓完之后把结果给分析Agent处理那协作这一层就需要A2A了。两个协议都还不完善的地方说了各自的优势也得说说它们还没覆盖到的区域。记忆和状态管理。MCP管的是工具调用A2A管的是Agent通信但Agent的记忆——跨会话的上下文积累、长期知识沉淀、工作记忆管理——目前没有任何标准协议。每个团队都得自己做。腾讯最近开源了TencentDB-Agent-Memory把记忆分成Chat Memory、Skill、LLM-Wiki、Code-Graph四种资产算是一个有价值的尝试但离成为标准还早。这个空白对实际开发的影响很大。你在MCP和A2A之上搭的系统状态怎么存、怎么取、怎么在Agent重启后恢复全是自定义的。如果你做的Agent系统需要长期运行、需要记住用户偏好和历史操作这块的工程量不小。评测和可观测性。Agent的输出是非确定性的同样的输入可能得到不同的结果。MCP和A2A都不提供评测框架。你怎么判断一个Agent在引入新工具后是变好了还是变差了怎么做回归测试怎么监控一个Agent的调用成功率、平均耗时、token消耗这些问题目前都得自己解决。PenguinHarnessLlamaFactory作者郑耀威的新项目做了一个叫GDPevo的评测基准专门测试Agent的自进化能力划分了训练集和测试集来防止Agent背答案。但这类工具还非常早期。国内的情况国标和生态都在加速如果你主要做国内市场有几个信息值得留意。2026年7月中国发布了GB/Z 185-2026《智能体互联互通》国家标准覆盖了7个方向的互操作规范。这是全球范围内最早把Agent协议写成国标的尝试之一。虽然国标目前是指导性质GB/Z不是强制标准但它代表了监管层对Agent协议标准化的重视程度。同一时间29个国家在上海签署了WAICOWorld AI Cooperation Organization创始文件推动AI Agent的跨国协作标准。这意味着未来做Agent系统协议合规可能不再只是技术问题也会涉及政策要求。从实际开发的角度看国内Agent生态有两个特点第一MCP的采用速度非常快。国内很多AI产品包括扣子Coze、Dify、FastGPT等都已经支持MCP。TypeScript在MCP生态中占比超过40%这也跟国内前端开发者大量参与AI应用开发有关。第二A2A的落地场景跟海外不太一样。海外更多是企业间协作跨组织B2B国内更多是平台内多Agent编排比如一个电商平台上客服、物流、支付各自的Agent在平台框架内协作。这种场景下用框架原生的编排能力可能就够了不一定需要A2A。但如果你做的是开放平台、想允许第三方开发者接入自己的AgentA2A的Agent Card机制就很有用了。主流框架对MCP和A2A的支持情况选框架的时候协议支持是一个越来越重要的维度。截至2026年8月主流框架的支持情况大致如下LangGraph 1.0Alice Labs评分8/10原生支持MCP状态持久化和human-in-the-loop做得最好。A2A支持需要自己集成没有官方方案。适合需要复杂状态管理的单Agent工具场景。Google ADK 2.0唯一一个同时原生支持MCP和A2A的主流框架提供Python/TypeScript/Java/Go四种SDK。如果你预见到未来需要做跨Agent协作ADK是目前最省事的选择。缺点是最佳体验依赖Google Cloud生态。CrewAI 1.14原生支持MCP2026年6月加入了可插拔的记忆、知识库和RAG后端。多Agent编排role-based crew做得很易用。不支持A2A但它的设计思路是用内部机制替代A2A的角色。适合快速搭建多Agent原型。OpenAI Agents SDK原生支持MCP7种sandbox执行环境。和OpenAI Responses API深度集成。不支持A2A因为OpenAI的思路是用GPTs Actions来解决Agent发现和协作的问题。Claude Agent SDK原生支持MCP毕竟是Anthropic自己做的架构和Claude Code相同。不支持A2A。一个趋势很明显**MCP已经是所有框架的标配不支持MCP的框架基本等于出局了。A2A目前只有Google ADK原生支持其他框架要么不关心要么用自己的机制替代。**这个局面在2026年下半年可能会有变化因为Linux Foundation在推动A2A成为更广泛的标准。给不同阶段的团队一点具体建议如果你刚开始做Agent项目先别管协议把核心逻辑跑通。用一个框架LangGraph或CrewAI都行手写几个工具调用验证业务逻辑是否成立。这个阶段最大的风险不是技术选型是你花两周搭了一个完美架构结果业务方向是错的。如果你的Agent系统已经有3-5个工具在用了开始考虑MCP。把工具封装成MCP Server好处是会逐渐显现的——工具的管理、版本控制、权限控制都会变得更清晰。MCP新版规范改成无状态之后部署也简单了不需要专门维护一个有状态服务。如果你在做多Agent系统但都在一个团队内用框架原生的多Agent机制。把精力放在Agent之间的任务分解和错误处理上这比引入A2A重要得多。如果你开始对接外部系统的Agent是时候认真看A2A了。从Agent Card的设计开始先定义好自己Agent的能力边界和认证方式。如果你在做面向未来的Agent基础设施MCP A2A一起上。MCP管内部工具接入A2A管外部Agent协作。同时开始思考记忆和评测层怎么做因为这两个是上层协议没覆盖到的空白也是你做出差异化的地方。总结MCP和A2A不是二选一的关系它们解决的是不同层次的问题。MCP让Agent能操作工具A2A让Agent之间能协作。你需要哪个取决于你的系统到了哪一层。2026年7月的MCP大重构是一个标志性事件——它从开发者玩具变成了可以上生产的协议。A2A还在等一个大规模落地的契机但它的标准化程度和安全模型确实更成熟。最后说一点个人的判断协议层的标准化速度比大多数人预期的快。MCP从提出到成为事实标准用了不到两年A2A也在快速铺开。现在花时间理解这些协议的边界和适用场景比等到不得不迁移的时候再学要划算得多。附录我见过的几个典型踩坑写到最后补充几个在实际项目中经常见到的问题不一定跟协议本身有关但都是搭Agent系统时绕不开的坑一MCP Server返回了太多信息把上下文撑爆了。一个MCP Server查数据库之后把完整的结果集几千行塞进了响应里。模型的上下文窗口是有限的被工具返回值占满之后连用户的问题都看不到了。解决方案是在Server端做结果截断和摘要——返回top 10结果加一个总数而不是一次性返回所有数据。坑二Agent在一个工具上反复重试死循环。工具调用失败了Agent的逻辑是换个参数再试一次。但失败的原因是权限不够重试多少次都没用最后token消耗了几十块钱还在跑。解决方案是在MCP Server端返回明确的错误码和错误信息不是简单的failed同时在Agent侧设置重试上限和熔断机制。坑三多个MCP Server的工具名字冲突。你接了两个MCP Server一个叫文件管理一个叫云存储它们都有一个叫upload的工具。模型搞不清该调哪个。解决方案是在Server端给工具名加命名空间前缀比如file/upload、cloud/upload或者在Client端做工具名的冲突检测。坑四A2A的异步Task超时了没人管。调用方发起一个A2A Task之后就去干别的了被调用方的Agent处理到一半挂了Task一直停在working状态。调用方等了三天才发现。解决方案是设置合理的超时机制A2A的Task规范支持expires_at字段同时调用方要有轮询检查超时的逻辑。这些问题都不是协议本身的设计缺陷而是Agent系统作为一个整体必然面临的工程挑战。协议解决的是连接和通信的标准化问题但连接上之后怎么用、怎么管、怎么兜底还是得你自己想清楚。参考资料MCP 2026-07-28 SpecificationRedis Blog: 5 agent architecture scenarios - assess MCP vs A2AAlice Labs: AI Agent Frameworks 2026 Production-Tested Ranking