这个系列写到第八篇，前几篇已经把多智能体的架构选型、任务编排、记忆与知识库、工具调用都过了一遍。这篇想专门聊协议层的问题，也就是MCP（Model Context Protocol）和A2A（Agent2Agent）在设计多智能体系统时到底怎么用。这两个名字最近在各种技术社区里被放在一起讨论的频率非常高，但真正动手落地的人，很多一开始都会犯同一个错误：把MCP和A2A当成了可以互相替换的同层方案。
先直接说结论：MCP管的是“智能体和工具之间的连接”，A2A管的是“智能体和智能体之间的对话”，它们在系统里是上下两层的关系，不是二选一的关系。这篇会把两个协议的核心边界、编排粒度的选择、工具层实战细节，以及多智能体系统里最常见的权限和调试问题一次讲透。无论你是刚接触多智能体的新手，还是已经在系统里接了好几个Agent的开发者，这篇都应该能帮你少踩几个坑。
1. 先理清一个关键问题：MCP和A2A各自解决哪一层的问题
1.1 MCP管的是“触手”，A2A管的是“协作”
很多文章把MCP翻译成“模型上下文协议”，这个翻译没问题，但从工程视角看，它真正做的事情是给AI应用一双可以操作真实世界的“手”。你的Agent要读数据库、查文档、调用内部API、操作浏览器，全靠MCP来统一接入方式。MCP的三类原语——tools（工具调用）、resources（资源读取）、prompts（提示模板）——已经把AI应用与外部系统交互的常见形态都覆盖了。
协议的传输结构也很简单，基于JSON-RPC 2.0，可以用stdio在本地启动子进程互通，也可以走HTTP+SSE做远程服务。也就是说，MCP本质上是一个“连接器标准”，它关心的始终是“AI应用如何安全地触达外部能力”。
A2A则完全是另一层楼的问题。A2A的核心是Agent之间的身份发现、能力协商和任务协作。它定义了AgentCard机制，每个Agent通过一个公开的卡片声明自己能做什么、用什么格式通信、有哪些能力；还定义了完整的Task生命周期（submitted、working、input-required、completed、failed、canceled），让一个Agent可以安全地把任务委托给另一个Agent，并持续跟踪任务状态。
用一个生活化的类比：MCP像USB-C接口，把鼠标、键盘、显示器都统一成一种插口，电脑不用为每个外设定制专属连接；A2A更像是公司之间的商务合作流程，你发一份询价单（任务），对方确认是否能做（协商），然后给你回报价和进度（状态），最后交付成果（artifact）。
1.2 协议边界错位，往往就是系统翻车的开始
在实际项目里，最容易出问题的不是协议本身，而是用错了协议的层级。我见过不止一个团队把MCP Server当成Agent之间的通信总线：让一个Agent把消息塞进MCP的resource里，另一个Agent去那边轮询读取。这种做法不是完全跑不通，但绕开了任务状态管理，Agent之间无法表达“这件任务我需要你继续推进”这种语义，最后消息全堆在资源池里，没人消费、没人清理，系统一跑就悬着一堆僵尸数据。
反过来的误用也常见：有人试图用A2A的消息结构去承载高频工具调用，把每一次small tool调用都包装成一个A2A Task。结果就是Task状态机被频繁创建和销毁，能力协商变成空转，性能开销大，语义还错位了。一个工具调用只是“一次性动作”，而A2A Task是“一个有始有终的协作单元”，两者粒度根本不在一个量级上。
所以我在做设计时的红线很清晰：智能体内部用MCP消费工具，智能体之间用A2A传递任务。MCP的调用方是单个Agent，A2A的调用方是另一个Agent；MCP的返回值直接进入当前Agent的上下文，A2A的返回值则要先经过任务状态机，再决定要不要进入下一步编排。边界守住了，系统架构才不会乱。
2. 多智能体编排粒度怎么定：从A2A直连到网关模式
2.1 Agent一多，直连就撑不住了
两个Agent之间的通信很简单，写个HTTP调用就行。但Agent数量一上来，问题就变了。5个以内的Agent，你可以用最简单的星型拓扑，让编排Agent直接管理所有worker；但到了20个Agent、每个Agent又有自己的MCP工具集，再让所有节点互相直连，服务和消息路径本身就成了一团乱麻。
多智能体编排的粒度选择，本质上是在回答三个问题：谁来发现Agent的能力？谁来路由任务？谁来维护任务状态？这三个问题的答案直接决定了系统是选择集中式、分布式还是混合式。
集中的做法是有一个编排Agent，它负责拆解用户请求，通过A2A把子任务分发给不同的worker Agent。这种模式的好处是决策逻辑清晰，坏处是编排Agent容易成为单点瓶颈。分布式的做法则是让Agent之间通过A2A互相发现、自行协商，适合节点之间能力相近、没有明显上下级关系的场景。实际工程里最务实的往往都是混合式——核心决策走集中编排，非关键路径允许Agent之间直接协商。
电网领域最近有个“多智能体协同可靠运行”的方向就很典型。系统里通常会有调度Agent、负载预测Agent、检修计划Agent，它们之间如果全部硬编码直连，每次业务调整都要改代码。走了A2A之后，调度Agent只需要向负载预测Agent发一个“未来6小时负荷走势”的任务，预测Agent在AgentCard里声明自己有能力处理，双方协商完成后交付结果，调度Agent再统一决策。这就是能力发现和任务路由的实战价值。
2.2 A2A在工程落地时的具体姿势
A2A中有个很有用的设计是AgentCard。每个Agent对外暴露一个JSON-LD格式的卡片，声明自己的标识、通信端点、能力列表、认证方式。有了这个机制，新增Agent时不需要改动任何业务代码，只要注册一张AgentCard，其他Agent就能通过服务目录发现它。
在工程落地时，一般会加一层轻量的A2A Gateway，而不是让所有Agent直接互相访问。Gateway负责三件事：登记和维护AgentCard、做任务分发路由、做协议版本适配。它不承载业务逻辑，只是像一个内网路由器，让Agent之间不需要知道对方的真实地址就能对话。
{ "@context": "https://a2a-api.lge.com/", "name": "load-forecast-agent", "description": "提供区域电网短期负荷预测服务", "url": "a2a://internal/load-forecast", "version": "1.2.0", "capabilities": { "skills": [ { "id": "forecast.6h", "name": "SixHourLoadForecast", "description": "基于历史负荷与气象数据输出未来6小时用电负荷曲线" } ] } }这里要特别提醒一点：A2A的Task状态机必须和你的业务单据状态对齐。不要让A2A的TaskState只活在协议层，业务侧完全不可见。最稳妥的做法是A2A Gateway收到任务状态变更时，同步写一份内部事件到业务消息队列，让上游系统能追踪“这个Agent协作任务走到哪一步了”。否则调完接口发现任务状态是completed，但你并不知道业务结果有没有真正落库。
3. 工具层实战：Browser Use MCP和Playwright MCP到底怎么选
3.1 工具选型决定了整个系统的能力天花板
多智能体系统里有一句大实话：编排决定系统的复杂度上限，工具决定系统的能力上限。Agent再聪明，MCP工具库里的工具质量不行，它也做不成事。一个描述含糊的工具，LLM要么不会调用，要么传错参数，最后回传的结果也未必能解析。我见过很多团队把工具封装成几十个“通用方法”，Agent根本不知道哪个适合当前任务。
所以在MCP Server的设计上，有一个原则值得反复强调：工具数量宁少勿多，工具描述宁长勿短。每个工具的description要像给新同事写交接文档一样，说清楚这个工具做什么、适合什么场景、不做什么、参数代表什么。比如一个查询订单状态的工具，描述里写“查询订单状态”远远不够，要写上“适合在用户询问物流配送进度时使用，输入订单号为字符串类型，返回结构包含配送公司、当前城市、配送状态码”。
3.2 两个浏览器类MCP的真实区别
热词里频繁出现的“Browser Use MCP和Playwright MCP有什么区别”，这个问题非常典型。两者看起来都是让Agent操作浏览器，但设计意图完全不同。Browser Use MCP的设计偏向“任务级代理”，它会把浏览器操作封装得更抽象，Agent只需要用自然语言说“帮我在搜索框输入关键词并提取前十条结果”，它能自动处理元素定位和等待。Playwright MCP则更像“精确遥控器”，它保留了选择器、截图、操作步骤的细粒度控制，适合需要稳定复现、需要精确验证的场景。
我用一个表格把两者的对比列出来，方便你直接对照选型：
| 对比维度 | Browser Use MCP | Playwright MCP |
|---|---|---|
| 定位 | 浏览器操作+信息提取的任务封装 | 浏览器自动化框架的协议封装 |
| Agent使用体验 | 偏向自然语言意图，LLM友好 | 需要明确选择器和操作步骤 |
| 上下文开销 | 会返回结构化提取结果，相对可控 | 可能返回大量DOM和执行日志 |
| 稳定性 | 对页面结构变化容忍度较高 | 需要维护选择器，页面改版易失效 |
| 典型场景 | 信息收集、竞品分析、表单填写 | 自动化测试、重复性巡检、精确交互 |
如果Agent的任务是“调研型”的，比如某个爬虫Agent要在多站点收集信息再汇总，我倾向于用Browser Use MCP，因为它对页面变化的适应性更好，Agent不用关心每个站点的DOM结构。如果任务本质是“验证性”的，比如上线前的回归巡检或定期打卡操作，那就用Playwright MCP，因为你可以把操作步骤固化成精确脚本，测试稳定性要高得多。
这里补充一个工具封装的经验：无论选哪个MCP，都要在Server侧做一层输出裁剪。浏览器自动化工具很容易返回超出预期的长内容，如果不加限制，模型上下文几分钟就被撑爆。我的做法是给所有MCP工具设置输出上限，默认返回摘要和截断正文，并在工具描述里说明“完整内容请用detail参数获取”。
4. 可观测性、权限与调试：多智能体系统最容易翻车的三个环节
4.1 一次请求穿过四层协议，怎么追踪
多智能体系统的调试难度，核心在于一次用户请求可能经过四层跳转：用户请求进入编排Agent，编排Agent通过A2A把任务发给worker Agent，worker Agent调用MCP工具，MCP Server再去访问外部服务。这四层之间的日志如果没有统一关联，排查问题纯粹靠猜。
我的建议是在协议层注入trace上下文。A2A的Request和MCP的Request都支持元信息扩展，把traceId从入口一路带下去，让每一次Agent协作和每一次工具调用都能串到同一个调用链上。
# 伪代码：跨协议传递trace上下文 def dispatch_task(agent_id, task_payload): trace_context = get_current_trace_context() a2a_request = { "method": "tasks/send", "params": { "task": { "artifactId": f"task-{uuid4()}", "message": { "role": "user", "content": [{"type": "text", "text": task_payload}] }, "metadata": {"trace_id": trace_context.trace_id} } } } response = a2a_post(agent_id, a2a_request) return response同时，在编排Agent这一层，要把A2A的任务ID和MCP工具调用的requestId做一次映射。实际过程中你会发现，很多“Agent回答得牛头不对马嘴”的问题，根源不在模型，而在工具调用返回了旧缓存。如果没有trace贯穿，很难定位到是哪个环节拿到的脏数据。
4.2 MCP接入的权限模型与常见配置失误
MCP的接入权限，是很多团队忽视的重灾区。默认情况下，MCP Server并不区分请求来源，谁拿到通道谁就能调用工具。在多智能体系统里，这意味着一个权限敏感的Agent（比如负责写数据库的Agent）很可能被其他Agent借道调用，导致越权。
我的做法是给每个Agent分配独立的MCP通道和凭据，工具级权限在Server侧做二次校验。不要让一个Service Account走遍全系统。尤其是外部MCP工具接入，比如Figma、蓝湖这类设计工具，授权流程更要谨慎。拿Figma MCP来说，你需要在Figma账户里生成Personal Access Token，再作为MCP Server的鉴权凭据；但系统里有多个Agent时，应该通过OAuth交换用户委托令牌，而不是把个人Token硬编码到配置里。否则Agent异常调用，你都不知道是哪个用户授权的操作。
Codex接入MCP后“找不到MCP”的问题，也属于配置层面的高发问题。Codex的MCP配置通常写在config.toml里，常见失败原因有三个：一是config.toml文件路径不对或格式错误，Codex根本没读到配置；二是启动命令的可执行文件不在PATH里，特别是在macOS上，GUI环境启动Codex时PATH被精简，找不到npm或node；三是MCP Server本身启动失败，但日志被忽略了。
所以排查这类问题的顺序应该是：先用codex mcp list确认配置是否加载，再手动在终端跑一次启动命令看是否有报错，最后确认MCP Server返回的是合法JSON-RPC响应而不是一段纯文本。别一上来就怀疑模型能力，十次有八次是配置问题。
4.3 多智能体高频问题排查速查表
把我在实际项目里遇到的典型问题整理成一个速查表，遇到类似情况可以直接对号入座：
| 症状 | 常见原因 | 处理方式 |
|---|---|---|
| 工具总是返回“解析失败” | MCP Server返回了非JSON格式的错误信息 | 在Server侧统一捕获异常，强制输出JSON-RPC格式错误体 |
| Agent反复调用同一个工具不停止 | 工具描述不明显，Agent误判任务未完成 | 检查工具description，明确“该工具完成后的输出形态” |
| 两个Agent协作时任务状态一直卡在working | A2A Task状态未同步，或子任务异步回调缺失 | 检查A2A Gateway的回调机制，增加任务超时重发逻辑 |
| Agent回答里带着不相干的上下文 | MCP工具返回内容过大，污染了模型上下文 | 在MCP Server侧做输出裁剪，控制返回内容字段 |
| Codex提示找不到某个MCP工具 | config.toml未加载或命令路径错误 | 用codex mcp list确认配置，手动执行启动命令排错 |
| 多Agent并发调用MCP时出现串数据 | 多个Agent共用同一MCP会话，上下文未隔离 | 按Agent隔离MCP连接，或在请求参数中注入session标识 |
这张表不是理论推演，是实打实从项目里踩出来的。多智能体系统的排查难度不在于单点技术多复杂，而在于问题常常跨越协议边界。看到工具层报错，原因可能在编排层；看到任务状态异常，原因可能在MCP的并发管理上。所以排查时一定要从trace链路统一视角去看，不要盯着某一个节点死磕。
写到这里，再分享一个我个人在实践中的体会：MCP和A2A的协议版本都还在快速演进阶段，A2A的规范版本迭代尤其频繁。设计系统时不要和具体协议的某个版本绑死，核心是要把“Agent到工具走MCP、Agent到Agent走A2A”这条边界稳定下来，然后在边界处做适配层。这样协议再怎么升级，系统内部只需要改一个适配模块，而不是推倒重来。
最后再给一个小技巧：给每个Agent的工具调用都做一层“翻译层”，把MCP返回的原始JSON统一翻译成系统内部的Schema对象。这层翻译看起来多余，但它能把外部工具的数据结构变化隔离在核心业务之外。真实项目里，你永远猜不到一个第三方MCP Server会在哪个版本偷偷改返回字段。有这层翻译兜底，系统就不会被外部变化突然打断。
