2026 年 7 月 28 日，Anthropic 发布了 MCP 协议的第五次大版本修订。
这次更新的核心变化只有一句话 ：协议层不再维护会话状态 。initialize 握手、Mcp-Session-Id 头------全删了。
每个请求自己携带身份、能力、版本号，任何一个服务器实例都能处理，普通的轮询负载均衡器可以直接用。
这个消息在开发者社区里没激起多大水花。但这个变化值得注意：一个为"上下文"（Context）设计的协议，核心连接方式却是无状态的。
HTTP 2.0 之后主流方案都在往有状态方向走（WebSocket、gRPC streaming、SSE），一个专门给 AI Agent 做工具接入的协议，却反着走到 REST 式的无状态路线上去了。
同年 3 月，A2A（Agent-to-Agent Protocol）发布了 v1.0 正式版，25,000 多个 GitHub star，六种语言的官方 SDK（Python、JS、Go、Java、.NET、Rust）。
Azure AI Foundry 和 Amazon Bedrock 都内置了原生支持。
A2A 最核心的设计选择是 ：Task 对象携带完整生命周期状态。
submitted → working → input-required → completed/failed/canceled------这是一个有始有终的工作单元，不是无状态的函数调用。
MCP 的无状态化转型，本质上是职责边界的厘清------MCP 的职责是工具接入，不是会话管理。
状态应该由上层（A2A 的 Task 层、或者应用自己的编排层）来管，MCP 只管"我给你调个工具、拿个资源"。
两套协议不是竞争关系，是分层分工。
A2A 的底层：Agent 怎么发现彼此
A2A 的核心数据结构是 AgentCard------一份 JSON 自描述清单，发布在 Agent 的 /.well-known/agent-card.json 路径下（遵循 RFC 8615 的 well-known URI 规范）。
任何支持 A2A 的客户端，只需要对这个路径发一个 HTTP GET，就能知道对方是谁、能干什么、怎么认证。
这和 MCP 的发现机制有本质区别。MCP 的 Server 需要客户端显式配置连接参数（stdio 的子进程启动命令，或者 Streamable HTTP 的 URL），连接建立之后才能通过 tools/list 查询能力。
A2A 的 AgentCard 是静态的、可缓存的、不需要先建立连接的。你甚至可以把一个公开 Agent 的 AgentCard 当作文档来读。
v1.0 版本给这个发现机制加了一道关键安全措施 ：Signed Agent Card。
AgentCard 的 JSON 经过 JCS（JSON Canonicalization Scheme, RFC 8785）规范化后，用 JWS（JSON Web Signature, RFC 7515）签名。
接收方可以验证签名，确认这张卡片确实来自它声称的来源域，没有被中间人篡改。
这听起来像 HTTPS 证书机制（确实类似），但有一层关键差异。HTTPS 证书验证的是"你在和正确的服务器通信"，Signed Agent Card 验证的是"这个 Agent 声称的能力清单确实由该域名的所有者签发"。
在多 Agent 场景里，一个编排 Agent 可能要从几十个外部 Agent 里选人------每个都声称"我能做数据分析"，但只有一个有签名可验证。没签名的，直接拒掉。
AgentCard 里声明的最关键字段是 skills：一组 AgentSkill 对象，每个包含 id、name、description、tags 和 examples。
注意这不是 MCP 的 tools------tools 是"我能调用什么函数"（原子操作），skills 是"我能完成什么任务"（复合能力）。
一个调用方通过 AgentCard 看到对方有个 financial_analysis skill，它不需要知道这个 skill 内部调了哪几个 MCP tool、用了什么模型、跑了什么 pipeline。
它只需要把任务描述丢过去，然后等结果。
这层抽象就是 A2A 设计原则里的 "opacity"（不透明性）------Agent 之间基于声明的能力协作，不暴露内部实现。
AgentCard 的具体结构：
json
{
"name": "Financial Analyst Agent",
"description": "企业财报分析与风险评估",
"version": "1.0.0",
"url": "https://finance-agent.example.com/a2a",
"protocolVersions": ["1.0.0"],
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [
{
"id": "financial_analysis",
"name": "财报分析",
"description": "分析企业季度和年度财报，输出风险评分与关键指标",
"tags": ["finance", "risk", "quarterly-report"],
"examples": [
"分析苹果 2026 Q2 财报的毛利率变化趋势",
"对比特斯拉和比亚迪的现金流健康状况"
]
}
],
"securitySchemes": {
"bearer": { "type": "http", "scheme": "bearer" }
}
}任务怎么流转：Task 生命周期与流式通信
AgentCard 解决的是"找到谁"，Task 解决的是"怎么协作"。
A2A 里的 Task 是一个完整的工作单元，有全局唯一 ID、有生命周期状态机、有输入输出的 Artifact 容器。它的状态机只有六个状态：
•submitted：任务已提交，等待开始•working：Agent 正在处理•input-required：需要外部输入（通常是等人类审批或补充信息），任务挂起•completed：正常完成，Artifact 可用•failed：执行失败，附带错误信息•canceled：被调用方主动取消
这个状态机里一个关键设计是 input-required。它解决了一个在异步 Agent 系统里经常被忽视的问题：人类在回路里怎么不阻塞整个系统。
传统 RPC 调用，超时就失败了------人类审批可能需要几个小时，这没法用"超时"处理。
A2A 的设计是：任务遇到需要人介入的节点，状态切到 input-required，推送通知给调用方，然后整条链路该干嘛干嘛，不会有一个 Agent 傻等着。
Task 内部的消息（Message）和产出物（Artifact）通过 Part 承载。Part 是一个联合类型（union type），可以是文本（TextPart）、文件引用（FilePart，URI + MIME 类型）、或者结构化数据（DataPart，任意 JSON object）。
多个 Part 组成一条 Message，多条 Message 组成一个 Task 的对话历史。多个 Artifact 组成 Task 的最终产出，支持增量追加（流式生成场景）。
这层数据模型让 A2A 可以同时处理"聊天式协作"和"结构化工作流"------你可以在同一个 Task 里先用自然语言描述需求，再收一个结构化的 JSON 分析结果。
通信传输层上，A2A 提供了一组操作原语，核心是 SendMessage（请求-响应）和 SendStreamingMessage（流式订阅）：
SendMessage 是标准请求-响应模式。客户端发一条 Message，服务端同步返回 Task 对象（可能已完成，也可能还在 working），客户端之后通过 GetTask 轮询结果。
SendStreamingMessage 是流式模式。客户端发消息的同时订阅 SSE（Server-Sent Events）通道，服务端实时推送 TaskStatusUpdateEvent（状态变更）和 TaskArtifactUpdateEvent（产出物增量更新）。
SSE 流在 Task 到达终态（completed/failed/canceled）时关闭。
两种模式的取舍取决于任务时长。Google 的建议是：预期 2 秒内完成的任务用 SendMessage 轮询，超过 2 秒的用 SendStreamingMessage 流式。
这个 2 秒阈值来自于 TCP 连接建立开销和 HTTP 请求延迟的经验值------短任务做流式反而因为建连开销拖慢整体。
还有一种更彻底的模式：Push Notification。Agent 可以主动向调用方配置的 webhook URL 推送状态更新。这对于跨服务器、跨时区的长时间任务尤其有用------调用方不需要维护一个 HTTP 长连接，Agent 完成后自己找上门来。
传输层还有一层考虑：v1.0 的 A2A 把传输绑定从 JSON-RPC 扩展到了 gRPC，不是简单加个选项，而是把 Protocol Buffers 的 .proto 文件提升为"规范源"（normative source of truth）。
a2a.proto 定义数据结构，HTTP+JSON 和 JSON-RPC 的序列化格式从它派生。这意味着 A2A 的核心数据模型和传输协议是解耦的：你可以用 JSON-RPC over HTTP 和 gRPC 跟同一个 Agent 聊天，AgentCard 里的 AgentInterface 让你知道它支持哪种。
这跟 MCP 差别很大。MCP 的传输层只有 stdio 和 Streamable HTTP 两种，JSON-RPC 是唯一的消息编码格式。
A2A 选择多传输绑定，是因为它要面对的场景比"工具调用"复杂得多------有些场景需要 gRPC 的双向流来做 Agent 之间的大规模数据交换，有些场景只需要一条 HTTP POST 抛个任务过去。
MCP 的无状态转型：从会话到自描述请求
回到 MCP 的 2026-07-28 更新。这个版本改的不只是"删了 session"这么简单，它触及的是一个更根本的问题：MCP 在 Agent 通信栈里的职责边界。
之前的 MCP 是这样的：客户端先 initialize 握手，服务器返回 Mcp-Session-Id，此后所有请求都带着这个 ID。
这意味着同一个客户端的连续请求必须路由到同一个服务器实例------要么用粘性会话（sticky session），要么所有实例共享一个 session store。
在本地 stdio 模式下这没问题（一个子进程就一个连接），但在远程 Streamable HTTP 模式下，这对负载均衡器和水平扩展是个不小的限制。
2026-07-28 改了什么？六个 SEP（Specification Enhancement Proposals）协同作用，完成了无状态化。最核心的三项变化：
1删除 initialize/initialized 握手------每次请求在 _meta 字段里携带协议版本、客户端信息、客户端能力声明。2MRTR（Multi Round-Trip Requests）替代了旧版的 elicitation/create 和 sampling/createMessage------当服务器需要在处理中途向客户端要更多信息时，返回一个 InputRequiredResult，而不是保持 SSE 长连接等待。3缓存的引入------tools/list、resources/list 等高频查询响应可以带 ttlMs 和 cacheScope 字段，网关层可以直接缓存，减少对 MCP 服务器的请求压力。
配套优化还包括 server/discover RPC 主动查询、UnsupportedProtocolVersionError 直接返回、以及 Mcp-Method 和 Mcp-Name HTTP 头用于网关路由。
这些改动背后的设计判断是 ：MCP 的职责是工具接入，不是会话管理。会话是有状态的，状态应该由上层（A2A 的 Task 层、或者应用自己的编排层）来管。
MCP 只管"我给你调个工具、拿个资源"------单次调用、独立完成、无副作用（至少协议层看上去是无副作用的）。
这个判断在工程上是成立的。如果 MCP 要同时管工具调用和会话状态，它会变成一个"胖协议"------既要处理 OAuth 认证、又要维护 SSE 长连接、还要在不同服务器实例之间同步 session state。
胖协议的演进速度慢、跨语言 SDK 适配复杂、出 bug 时定位困难。瘦下来之后，每个 MCP Server 只做一件事：收请求、调工具、返回结果。其余的事情交给上层。
但在多 Agent 场景下，MCP 授权模型的设计约束会凸显出来。
MCP 的授权模型分两层：stdio 模式靠宿主进程的权限（服务器作为子进程运行，继承宿主应用的文件系统和网络权限），Streamable HTTP 模式靠 OAuth 2.1（客户端通过授权服务器获取 scope-token）。
但在多 Agent 场景里，当一个编排 Agent 需要让 3 个子 Agent 分别访问 3 个 MCP Server 时，"谁授权了谁"这件事会迅速复杂化。
A2A 在 OAuth 2.0 授权框架下支持受限 token 委派：编排 Agent 拿到用户授权的 token，在向下委派任务时把 token 换成一个 scope 更小的子 token------"你能访问数据库，但只能查，不能写"。
MCP 目前没有内置这套委派链机制，它假定每个 MCP 客户端是一个独立的 trust principal。
但这不意味着 MCP 在多 Agent 场景里没用。恰恰相反 ------每个 Agent 都应该有自己的 MCP 连接。
A2A 管 Agent 之间怎么协作，MCP 管每个 Agent 自己怎么调用工具。这是一个分层架构，不是一个"选 A 还是选 B"的问题。
五种通信拓扑，以及什么时候该用哪种
协议层面讲完了，现在看架构层面------Agent 之间以什么拓扑组织。
业界有大量框架（LangGraph、CrewAI、AutoGen 等）在实现层面对拓扑做了封装，但说到底层结构，可以归纳为五类（这个分类来自 arXiv:2502.14321 的通信视角综述）：
1. 星型（Hierarchical）
一个中央编排 Agent 负责拆任务、分派给子 Agent、收结果、组装。所有通信都经过中心节点。
LangGraph 的 Supervisor 模式、CrewAI 的 Hierarchical Process 都是这种。
优点是可调试性最好：所有状态变更都经过一个点，你只需要审查编排 Agent 的日志就能知道全局发生了什么。
缺点是中心节点是单点瓶颈，它既要拆任务又要合结果，当 Agent 数量超过 15 个，编排 Agent 自己的 context window 会成为硬限制。
2. 网型（Flat/Mesh）
Agent 之间对等通信，没有中心节点。A2A 协议的原始设计就支持这种------任何一个 Agent 都可以通过 AgentCard 发现另一个，直接发起 Task。
优点是故障隔离：一个 Agent 挂了不影响其他人。
缺点是调试难度指数级：10 个 Agent 互相通信产生的消息量是 O(n²)，"为什么 Agent C 收到了错误数据"这件事可能追溯到 3 跳之前的 Agent A。
3. 团队型（Team）
Agent 按角色分组成团队，团队内部紧密协作，团队之间通过指定接口通信。MetaGPT 的"产品经理-架构师-工程师-测试"结构就是团队型的典型实现。
这种拓扑适合角色边界清晰的任务，如软件开发、内容审核、供应链管理等。
弊端在团队之间的接口设计：接口太窄（只传最终结果），下游团队拿到不完整信息；接口太宽（传全部上下文），又会触发 context 膨胀。
4. 社会型（Society）
Agent 在一个共享环境里自由交互，没有预设的通信路径。行为模式通过环境规则涌现。
Generative Agents（斯坦福的 25 个 Agent 小镇实验）是典型例子。
这种模式适合社会模拟和博弈研究，不适合生产系统------它的行为不可预测，出错时没有"回滚到上一个正确状态"的路径。
5. 混合型（Hybrid）
星型管外层流程，网型管内层协作。
比如一个编排 Agent 负责整体 workflow，把其中"代码审查"这一步委派给 3 个审查 Agent 互相 debate，用 majority voting 决定最终结果。
这是 2026 年生产系统里最常见的模式，因为它在可控性和灵活性之间找到了工程上可操作的平衡点。
选哪种拓扑，取决于三个约束：
•Agent 数量 ：少于 5 个，星型最省事；5-15 个，考虑混合型；超过 15 个，必须用网型或团队型（星型的编排瓶颈已经到了）。•任务的可分解性 ：能清晰分解成独立子任务的，星型效率最高；子任务之间有交叉依赖的，网型更合适。•审计要求：需要完整追踪"谁在什么时候为什么做了这个决定"的，星型最优（一个节点有全量日志）；对审计要求不高的内部实验，网型更灵活。
关于拓扑和模型选择的关系，有一组数据值得注意：AdaptOrch 项目（arXiv:2602.16873）测试发现，拓扑结构对系统性能的影响比模型选择更大。
在相同的 Agent 数量下，正确的拓扑选择能带来 12-23% 的性能提升，而换一个更大更贵的模型，收益远小于这个幅度。
四种典型失败模式
下面这些坑不在论文里，是生产环境的工程团队实际踩过的。
1. 无限循环（Infinite Agentic Loops）
这是多 Agent 系统里常见且代价高昂的故障模式。两个或更多 Agent 陷入循环通信：Agent A 产出代码，Agent B 发现问题要求修改，Agent A 改了但引入新 bug，Agent B 再次拒绝------理论上永远不会停下来。
问题会同时从三个方向爆发：API 费用（每次循环都是一次 LLM 调用）、CPU（循环不暂停）、context 膨胀（每次循环都在对话历史里追加内容）。
IAL-Scan 项目（arXiv:2607.01641）扫描了 6,549 个 Agent 项目的代码仓库，在 47 个项目中找到了 68 个"无限循环漏洞"------多数集中在 LangGraph 和 AutoGen 框架。
这些漏洞的 69.1% 来自三个原因：
•重试反馈没有次数上限•工具调用迭代没有次数上限•多 Agent 对话没有轮次上限
通用防护手段：所有 Agent 强制设硬上限（MAX_TURNS=10、MAX_TOOL_CALLS_PER_AGENT=20、recursion_limit），再加上状态哈希检测------如果连续两轮的系统状态相同，自动中断。
没有这些限制的多 Agent 系统存在较高的故障风险。
2. 上下文丢失与漂移（Context Drift）
Agent 之间的每次交接都是一次"传话游戏"。第一个 Agent 输出 3,000 个 token 的分析报告，传给第二个 Agent。
第二个 Agent 拿到的不只是报告，还有编排 Agent 的指令、第一个 Agent 的产出、第二个 Agent 自己的 system prompt------如果这些加起来超过它的 context window，模型会从最早或最不相关的内容开始丢弃。
丢掉的可能恰好是第一个 Agent 输出的关键结论。
对此，一个被验证过的缓解方案是按 Agent 隔离上下文（per-agent scoped memory snapshot）。每个 Agent 的输入只包含它当前任务需要的 state key，而不是整个系统的共享状态。
合并策略（last-write-wins 或 majority vote）显式声明，不在隐式行为里埋雷。某生产团队实施了这个方案后，context 损坏事故显著减少。
3. 幻觉级联放大（Cascading Hallucination）
这是多 Agent 系统里危害最隐蔽的故障模式------因为它的表面没有任何报错。
Agent A 产出了"苹果 2026 Q2 毛利率 48.5%"（实际是 46.9%）。Agent B 拿到这个数据，用它做行业对比分析，得出"苹果毛利率超行业均值 12 个百分点"的结论。
Agent C 拿到 B 的分析，写成最终报告："苹果盈利能力远超同业"。三个 Agent 每一步都"执行正确"（格式对、逻辑对、没有报错），但最终输出从第一跳就错了，后面两跳只是把错误包装得越来越像真的。
arXiv:2606.07941 的论文专门研究了多 Agent 系统中的集体幻觉现象。图网型拓扑里，错误信息会在 Agent 之间交互传播并相互强化，每个下游 Agent 不仅接收了上游的错误输入，还会基于它做"论证补充"，让错误看起来更可信。
缓解方案不是靠模型能力提升（幻觉问题在可预见的未来不会消失），而是靠验证节点：在关键交接点，用外部数据源做事实核查。
MCP 在这个场景里有天然优势：每个 Agent 的内部工具调用可以绑定验证逻辑，"拿到的数据点先跟权威数据库对一下，对不上就标 uncertain"。
4. 回声室放大（Echo Chamber Amplification）
当多个 Agent 在同一个问题上达成一致时，系统会变得越来越自信，即使这个"一致"从一开始就建立在错误的基础上。
三个 Agent 都觉得"A 方案最优"，不是因为 A 真的最优，而是因为 Agent B 和 C 看到了 Agent A 的结论后，用"A 是对的这个前提"去搜证据来支持它。这和人类的"确认偏误"机制几乎完全一致。
解决思路不是让 Agent 更聪明，而是在结构上阻断同质化：
•引入外部视角：用 web search 或知识库做独立验证•引入分歧机制：显式指派一个 Agent 扮演"反对者"角色•引入不确定性量化：要求 Agent 对每个输出附带置信度，低置信度的输出不给下游 Agent 做决策依据
一行代码不用改的生产经验
把协议和拓扑放进生产环境，有几条实践在反复验证中站住了脚。
每条 Agent 交接都是 API 契约------用 JSON Schema 校验上游输出，不合规的直接拒掉，而不是用"下游 Agent 应该能容错"来自欺欺人。
MCP 的工具定义本身就是 JSON Schema，A2A 的 Task Artifact 可以附带 schema 声明，这些机制已经在了，缺的是工程纪律。
流式 > 轮询，缓存共用 > 独立推理。FLASHAGENTS（MLSys 2026）与 KVCOMM（arXiv:2510.12872）都验证了 KV Cache 跨 Agent 复用的收益：KVCOMM 在 5 个 Agent 的设置中把首 token 延迟从 430ms 降到 55ms（7.8 倍），FLASHAGENTS 在链式调用中实现了 3.5 倍的推理加速。
实现复杂度不低，但对于高频交互的多 Agent 系统，这是值得的投入。
OpenTelemetry + W3C Trace Context ------在每次 A2A 调用时传播 traceparent 头，记录 taskId、contextId 和认证 Agent 的身份。
没有分布式 trace 的多 Agent 系统在生产环境是一个黑箱。"为什么这个 ticket 的处理花了 3 分钟"这类问题会浪费大量排查时间。
安全不只是"认证" 。MCP 的 stdio 模式在 2026 年 4 月被 OX Security 发现了一个 RCE 漏洞：客户端读取的 MCP 配置里的 server 启动命令字符串会被直接传给操作系统的 shell 执行，如果配置文件被攻击者写入，就获得了任意代码执行权限。
A2A 的 Signed Agent Card 是必要的，但不够，在实际部署中，API Gateway 统一做 OAuth 2.0/OIDC 验证、rate limiting、请求日志，是标准做法。
分歧和收敛
A2A 和 MCP 之外还有几个协议在演进。
IBM 的 ACP（Agent Communication Protocol）最初是为 BeeAI 平台设计的 REST 式 Agent 通信协议，支持多模态消息和异步流式传输。
2025 年 8 月 ACP 并入 A2A，减少 Agent-to-Agent 层的碎片化。
ANP（Agent Network Protocol）走了另一条路：基于 W3C DID（Decentralized Identifier）和 JSON-LD 的去中心化方案，目标场景是跨组织的 Agent 市场（"我的 Agent 公开接任务，你的 Agent 通过 DID 发现我，不需要中心化的注册中心"）。
目前的落地还少，但设计理念对去中心化场景有参考价值。
Agora 是一个更激进的方向------它不固定协议，而是让 Agent 自己协商用什么协议通信（"元协议"）。这个方向的实用化还有距离。
值得关注的是正在进行的标准化努力。IETF 在 2026 年 7 月的维也纳会议上以 154-51 的票数决定成立 agentproto 工作组，虽然初始范围提案被 38-124 否决（社区认为范围没想清楚），但方向是明确的------Agent 通信正被当作互联网基础设施层的问题来对待。
W3C 也在 2025 年 5 月成立了 AI Agent Protocol Community Group（由 ANP 社区发起）。
整个协议生态在往一个方向收敛 ：分层共存，不是单一胜者。就像 HTTP、WebSocket、gRPC 在同一个互联网基础设施里各管各的层------MCP 管工具接入，A2A 管 Agent 协作，AG-UI（Agent-User Interaction）管前端交互。
三层的职责边界正在变清晰。
参考来源：
- A2A Protocol v1.0 Specification: a2a-protocol.org/latest/spec...
- A2A Protocol v1.0 Release (Google Cloud, Jul 2026): medium.com/google-clou...
- MCP 2026-07-28 Specification RC: blog.modelcontextprotocol.io/posts/2026-...
- MCP Specification 2026-07-28: modelcontextprotocol.io/specificati...
- A2A Protocol GitHub: github.com/a2aproject/...
- Beyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent Systems (arXiv:2502.14321): arxiv.org/abs/2502.14...
- A Survey of Agent Interoperability Protocols (arXiv:2505.02279): arxiv.org/abs/2505.02...
- A Technical Taxonomy of LLM Agent Communication Protocols (arXiv:2606.19135): arxiv.org/abs/2606.19...
- Beyond Message Passing: A Semantic View of Agent Communication Protocols (arXiv:2604.02369): arxiv.org/abs/2604.02...
- AdaptOrch: Adaptive Orchestration for Multi-Agent Systems (arXiv:2602.16873): arxiv.org/abs/2602.16...
- When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents (arXiv:2607.01641): arxiv.org/abs/2607.01...