先说个背景这是《使用MCP和A2A设计多智能体AI系统》的第六篇。前几篇我们把MCP Server从零搭到了能跑也把A2A协议里的AgentCard、Task模型、消息格式逐条拆过。但说实话“能跑”和“能用在生产环境”之间隔着的不是协议文档而是一堆工程化的脏活累活。这一篇不打算引入新概念而是把MCP和A2A真正组合起来、部署到真实多智能体系统时踩过的坑、验证过的做法以及最近热门的工具链接入实录浏览器自动化、数据库连接、设计协作、垂直引擎一次讲透。不管你是刚把第一个Agent跑起来的新手还是已经在多个Agent之间做编排的老手这期内容应该都能让你少趟几次浑水。1. MCP和A2A职责边界怎么划分才不会让多智能体变成一团乱麻1.1 MCP是“手”A2A是“嘴”先想清楚这两层协议各管什么我见过不少团队一上来就想把MCP和A2A揉进同一个配置文件里结果越揉越乱。其实这两个协议解决的问题是正交的先把边界划清楚后面全部顺了。MCP全称Model Context Protocol核心定位是“模型调用工具”的标准接口。我经常跟人解释MCP相当于软件世界的USB-C口。USB-C统一了充电、数据传输、视频输出MCP统一了Agent访问浏览器、数据库、设计稿、游戏引擎、FPGA工具的方式。最近有朋友问“MCP是软件协议还是硬件协议”这里必须说清楚MCP是应用层软件协议跟硬件协议不沾边。它之所以让人迷惑是因为它能遥控硬件相关工具比如Unity引擎、Vivado但协议本身跑在HTTP、stdio这类软件通道上规约的是数据格式和调用流程不是电气信号。A2A全称Agent-to-Agent定位则是“Agent之间协作”的协议。给我一个更直白的类比A2A是职场社交规则。每个Agent先递一张名片AgentCard说明自己叫什么、能干什么、怎么联系然后通过标准化的任务消息Task派活、跟踪进度、交付结果。没有A2A时Agent之间只能通过硬编码接口互相调用加一个Agent就要改一遍调用方代码有了A2A新增Agent只需要注册名片协作双方按协议说话即可。在实际系统里这两层协议往往是叠着用的顶层是一个或多个编排Agent它们通过A2A互相派活每个被派活的Agent内部通过MCP去调用自己那组工具。换句话说A2A解决的是“组织关系”MCP解决的是“干活能力”。1.2 单协议方案迟早撞上三堵墙只上MCP、不上A2A的系统通常会长成什么样子所有Agent都连到同一个MCP Server上工具列表动辄四五十个。第一堵墙是提示词爆炸每当Agent要决定调用哪个工具它得把所有工具描述塞进上下文token消耗直接起飞。第二堵墙是权限模糊一个能访问数据库的Agent理论上也能访问同一个MCP Server上的文件系统和浏览器“最小权限”根本无从谈起。第三堵墙是单点故障MCP Server一挂全系统一起瘫。只上A2A、不上MCP的系统也有类似问题。Agent之间倒是能互相喊话、派活了但真要去执行任务时没有“手”可用最后还是得绕过A2A去手写工具调用协议沦为摆设。我在一个早期原型里见过这种状态A2A消息满天飞每个Agent都在说“我收到了”但没人真正把活干完因为执行动作没有统一出口。正确的做法是分层每个Agent通过自己的MCP连接器去操作工具任何跨Agent的请求都包装成A2A消息。这样一来单个Agent的工具集可以做得小而精整个系统的扩展靠增加Agent和A2A路由而不是无限堆大工具列表。提示一开始就同时上两套协议确实会增加理解成本。我的建议是先用MCP把单Agent工具调用跑顺再加A2A做协作顺序不能反。2. MCP Server生产级落地的关键问题传输、权限、超时与隔离2.1 stdio还是Streamable HTTP先看部署边界再选MCP官方定义了两种主流传输通道stdio和Streamable HTTP。很多人在配置时拿不定主意其实判断标准非常简单——工具跟Agent是不是跑在同一台机器上。stdio模式本质是MCP客户端直接拉起一个子进程通过标准输入输出传JSON消息。它的优势是零网络开销、不需要鉴权、进程结束连接即断开非常干净。本地CLI工具、浏览器自动化工具、调试器类工具都推荐走stdio。比如热词里高频出现的Playwright MCP和Chrome DevTools MCP默认就是stdio模式因为它们要操作的浏览器和Node进程就在本地。Streamable HTTP则适合跨机器部署、需要多客户端共享的场景。数据库MCP、金融行情MCP、企业后台内置MCP通常走这条通道。它把MCP Server暴露成一个HTTP端点支持Streaming模式推送事件这样Agent可以订阅工具执行过程中的实时进度。实际项目中我见过最典型的混搭架构浏览器自动化Agent和IDE插件Agent在一台开发机上用stdio起Playwright MCP和DevTools MCP而数据库查询Agent和报表生成Agent在服务器上通过Streamable HTTP访问同一个MCP Server。两种传输方式完全不冲突客户端配置里指定transport字段即可。2.2 权限白名单、超时与进程隔离三个不能省的安全阀MCP Server写起来很爽因为工具注册就是加一个函数的事。但生产环境的第一个教训就是不要把所有工具全量暴露给所有Agent。我给MCP Server加了一个工具白名单配置每个Agent拿到的工具列表不一样。比如网页抓取Agent只能看到browser_navigate、browser_click、browser_extract_text这类工具数据分析Agent只能看到query_sql_readonly连写操作的影子都看不到。这个白名单不只是列表过滤还要在工具执行层做参数schema校验——就算Agent被诱导传入了恶意的SQL片段MCP Server也会因为schema不匹配直接拒绝。第二个安全阀是超时。MCP客户端默认的超时时间经常不够用。一个查询大表的SQL可能跑5秒一个浏览器页面可能加载8秒如果不调大请求级超时Agent会反复拿到超时错误然后重试再超时白烧token。我的配置通常分两层连接超时3秒请求超时按工具单独设置。比如浏览器工具给15秒数据库查询给30秒文件操作给10秒。具体数值截个屏记录在配置注释里方便排查。第三个安全阀是进程隔离。用Cheat Engine之类调试工具桥接MCP的场景尤其要小心。这类工具能操作进程内存如果MCP Server直接暴露写任意内存地址的接口等于把整台机器交给了Agent。我建议只暴露受控的能力子集只允许读取指定进程、指定地址段且每次读写都要过一层偏移量校验写操作一律拒绝。曾经有团队图方便把Cheat Engine的全量API映射成MCP工具结果Agent一次误操作把目标进程搞崩连带影响了同一主机的其他服务——这个坑不值得再踩。2.3 公共MCP网关与token管理的常见坑很多公共MCP服务现在采用WebSocket加token的方式接入热词里也能看到这类网关地址的讨论。这类公共网关用起来方便但踩坑频率最高的就是token三件事过期、scope不足、连接被远端重置。token过期是最容易排查的网关返回401刷新后重连即可。麻烦的是scope不足网关的接口文档写着“可访问所有工具”实际token的scope只放开了只读工具Agent调用写工具时会静默失败或飘忽不定地报错。我的排查办法是写一个连通性探测脚本启动时依次调用每个权限范围内的工具把成功与否输出成清单。这样每次部署新环境先跑一遍探测脚本权限问题十分钟内暴露。还有一类坑跟网关的重连机制有关。WebSocket连接不稳定时客户端不会自动重连需要自己实现指数退避重连否则Agent挂起半天才发现连接断了。公共网关虽方便但在核心生产流程里我还是建议尽量自建MCP Server毕竟token的商业可用性不能完全依赖第三方稳定性。3. A2A协作从Demo到可用的三个关键细节3.1 AgentCard名片上的信息写太少找不到活写太满容易翻车A2A协议里每个Agent通过一份AgentCard声明自己的能力。字段不多name、description、skills、url、authentication。但“写什么”非常有讲究。最保守的写法是把description写得又宽又泛比如“能处理所有报表任务”。结果是父Agent每次都会优先把各种报表任务派给它而它实际只会处理CSV和Excel格式遇到JSON报表就当场摆烂。生产环境里description里应该明确边界条件除了写“支持XX格式报表”还要写上“不支持跨数据库关联查询”“不支持实时数据推送”。父Agent在做路由时判断的依据主要就是这段描述描述里没写到的东西全当它不支持这是减少任务失败率的第一个小技巧。skills字段建议展开成结构化列表每条skill给一个name和一个description。比如“网页内容抓取”skill描述里补充“适合静态页面不适合验证码登录后的页面”这样路由Agent在场景不匹配时能提前分流。我自己的经验是每个Agent的AgentCard控制在5~8个skill以内超过10个就说明这个Agent太贪心应该拆成两个。3.2 Task状态机与Artifact引用别把结果塞进消息正文A2A的任务模型里面有一个状态机submitted - working - input-required - completed / failed / canceled。看起来简单但生产环境里最容易出问题的是“completed”之后的结果传递。有人习惯把最终结果直接写在A2A消息的正文里小任务还行一旦结果是大JSON或几百行日志消息体会迅速膨胀。A2A协议的设计是让任务产出ArtifactArtifact引用的是URI或文件句柄真正的数据可以放在对象存储或由MCP resource提供。子Agent完成任务后父Agent拿到Artifact引用再按需去取数据。这样A2A消息本身保持轻量多Agent之间传引用而不是拷数据可以大幅降低网络负载。另一个容易翻车的是重试幂等。A2A客户端在超时后会重发请求如果重发时没有携带同一个requestId子Agent会把同一个任务执行两遍。我们在线上的一个统计Agent就因为这个原因把数据同步任务重复执行了一次生成的结果里出现了一组重复记录。后来排查到根因是重试逻辑里新建了requestId修复后彻底解决。任何写操作类任务重试幂等必须作为上线前检查项。3.3 上下文裁剪别让Agent背上整个对话历史多Agent系统跑久了编排Agent会习惯性地把所有协作过程的完整对话历史转发给每个下游Agent。这种做法在Demo阶段没问题到了生产阶段token开销和上下文干扰都会爆炸。我采用的模式是“决策链快照”。父Agent在派发子任务时只传三样东西任务背景摘要不超过200字、输入参数、期望输出。不传中间推理过程不传其他Agent的原始输出也不传任何原材料。子Agent需要原文件时通过Artifact引用的方式去取。对比数据很直观同样一个数据清洗任务上下文裁剪之前子Agent的输入prompt有6000多token裁剪之后压到1500 token左右不仅token开销省了任务完成速度也明显更快因为Agent不需要在海量无关内容里翻找关键指令。上下文隔离还能避免一个隐患——Agent A的内部错误信息被Agent B读到后B会在自己的回答里“脑补”一些不存在的上下文导致结果变得稀奇古怪。保持每个Agent只看到它该看的是保证多Agent系统稳定输出的重要前提。4. 热门工具链MCP接入实录浏览器、数据库、设计稿与垂直引擎4.1 浏览器自动化工具怎么选Playwright MCP、Chrome DevTools MCP、Browser Use MCP浏览器相关MCP是最近热度最高的方向因为几乎每个Agent系统都要跟网页打交道。热词里就有好几个相关提问尤其是“Browser Use MCP跟Playwright MCP有什么区别”这里一次说透。Playwright MCP把Playwright的能力封装成工具Agent可以直接控制浏览器做点击、输入、导航、断言等操作。它的抽象层级贴近“浏览器操作原语”适合AI驱动的端到端测试、表单填写、页面结构抓取。你在一个网页改版任务里要抓旧版页面的链接列表用Playwright MCP是最直接的。Chrome DevTools MCP则从另一个角度切入它暴露的是DevTools调试协议包括网络请求、DOM断点、Console日志、性能分析。它更适合“观察浏览器内部发生了什么”比如排查页面JS报错、查看API响应、分析渲染性能。热词里有人把Chrome DevTools MCP和Playwright MCP放在一起问我的判断是它们不是竞品而是上下游前者管观察后者管操作。Browser Use MCP定位不同它更像“AI网页助理”。它内部会做页面理解、信息归纳、抗干扰抽取Agent只需给出目标“找出这个页面的主要产品参数”Browser Use负责像人一样浏览并返回提炼后的结果。它跟Playwright MCP的最大区别在抽象层级Playwright给的是操作原语Browser Use给的是任务语义。实际中抽取页面核心信息、竞品调研这类任务用Browser Use更省token需要精确控制每一步交互时用Playwright MCP更稳。工具抽象层级最佳场景典型消耗Playwright MCP浏览器操作原语E2E测试、表单提交、精确抓取步骤多、token消耗中等Chrome DevTools MCP浏览器内部状态网络调试、JS报错定位、性能分析数据量大、需裁剪Browser Use MCP任务语义页面理解、信息归纳、竞品分析单任务token较高但更省事4.2 数据库MCP接入Oracle、金融行情与后台管理系统热词里有两个数据库相关的高频问题一个是“IDEA插件通义灵码怎么用MCP连接Oracle”另一个是“同花顺MCP”。这两个场景合在一起正好覆盖了数据库MCP的两种典型形态。先说Oracle连接。不管是IDE插件还是自建多Agent系统连接数据库的MCP Server背后都是同一套原理把SQL执行封装成工具。你在配置MCP Server时需要指定数据库连接串、凭据位置以及在MCP工具定义中暴露哪些操作。以Oracle为例推荐的做法是只暴露只读查询工具、元数据查询工具和explain plan工具写操作单独放一批需要额外确认的工具。开源的数据库MCP项目通常自带readonly配置项把这个开关打开能省很多事。IDE插件场景里通义灵码通过MCP连接Oracle后AI可以直接在编辑器里执行“查询某个表的行数”“列出某个用户的权限”这类运维操作极大解放双手。但要注意IDE插件有时会自动把MCP工具调用结果拼进对话历史涉及生产库敏感数据时别把凭据放在代码仓库里环境变量或密钥管理服务才是正确位置。同花顺MCP这类金融数据服务则是另一种形态它有行情快照、历史行情、标的筛选等工具部分数据走推送通道。接入多Agent系统时有两个特殊点。一是数据时延敏感股票行情工具通常要求毫秒级响应MCP Server暴露的是HTTP轮询还是WebSocket订阅直接决定了Agent拿到的数据新旧程度。二是速率限制公共行情服务会对调用频率做限制Agent系统里多个任务并发查询时很容易触发限流。我建议在MCP Client层做统一的请求队列和令牌桶而不是让每个Agent各自为战。另一个趋势是开源后台系统在合并MCP能力热词里的RuoYi-Vue-Pro就是一个代表性案例。把MCP集成进后台管理系统的思路很好等于把AI工具能力嵌进了原有的权限体系。但这里有一条红线MCP Server内部一定要复用后台原有的鉴权和数据权限不能因为接了MCP就把菜单权限旁路掉。我在一个内部平台里看到过反面教材——MCP Server直接用数据库管理员账号连接所有Agent都能查任意表后台的部门数据隔离完全失效。这个坑希望大家一次避开。4.3 垂直领域MCPUnity、Vivado、Hermes与安全测试工具垂直领域MCP的热度也在快速上升Unity MCP、Vivado MCP这类是把游戏引擎、FPGA开发工具的能力暴露给Agent。原理都一样把目标工具的API或命令行封装成MCP工具。我用Unity MCP做过一个原型让Agent自动在场景里摆放预制体并调整材质参数Vivado MCP则可以用来让Agent执行综合、仿真命令并解析日志里的时序违例。这类工具接入的核心难点不在MCP封装而在异步执行和主线程安全——Unity、Vivado这类软件往往要求API调用跑在特定线程MCP Server收到请求后不能直接阻塞主线程最好丢进异步队列执行完成后再推送结果。Hermes接入MCP是另一个有意思的方向把消息队列变成Agent的工具让Agent能发布消息、订阅Topic。这种桥接模式很适合做异步事件驱动架构比如一个Agent完成数据清洗后通过Hermes MCP向消息队列发一条“数据已就绪”事件下游报表Agent订阅后自动启动拉数。跟数据库MCP不同消息队列MCP的服务端推送很重要Agent需要常驻监听而不是轮询。最后必须提一下安全测试工具接入MCP。热词里有人谈到Trae IDE搭载Burp Suite MCP Server这本质上是为了让AI能直接操控Burp Suite执行授权范围内的请求拦截和重放测试。这种工具接入生产环境需要格外谨慎除了跟前面提到的Cheat Engine一样做能力裁剪还要明确限定扫描目标为授权范围内的资产不能放给Agent随意扫描公网地址。安全工具的MCP化能显著提升渗透测试效率但前提是权限边界和审计日志做扎实否则AI一把梭后果不堪设想。5. 实战串联一个网页改版数据核对任务如何同时调动MCP和A2A5.1 三个Agent的分工与消息链路理论说太多容易飘还是看一个完整案例。某金融资讯网站改版需要核对改版前后100个页面的关键数据——比如页面上的行情数字、指标结论、发布时间。传统做法是测试人员人工打开页面逐条对比一个人跑一天都不一定跑完。我们把它拆成三个Agent的协作任务Agent-Master编排Agent负责拆任务、派活、汇总结果Agent-Web网页抓取Agent通过Playwright MCP操作浏览器Agent-DB数据回查Agent通过数据库MCP执行只读查询任务链路分四步Agent-Master通过A2A向Agent-Web派发“抓取页面列表”任务请求里带上100个页面URL并通过Task状态跟踪执行进度。Agent-Web逐个打开页面提取关键字段把结果写成JSON文件上传到对象存储然后把Artifact引用放进A2A回执。Agent-Master拿到引用后继续通过A2A向Agent-DB派发“按规则回查线上数据”任务Agent-DB连接数据库执行SQL返回比对基准数据。Agent-Master汇总两边的数据调用自己的MCP工具做差异比对输出一份改版前后差异报告。A2A消息在整条链路里始终保持轻量真正的页面数据和大 JSON 都放到了MCP资源层和对象存储中。当100个页面全部抓完Agent-Web的回执只有一行字加一个URI而不是一条塞满10万字符的消息。第2步和第3步在实现上有个要点Agent-Web抓页面时需要限速并发太高会触发目标站点的反爬机制。我们在浏览器MCP工具外面加了一个并发控制层同一时间只跑两个标签页每个页面之间间隔500毫秒实测下来100个页面20分钟跑完零封禁。5.2 线上踩坑记录与排查速查表这个案例第一次跑通时并不是一帆风顺前后踩了不少坑我按排查顺序整理成一张速查表现象根因处理方法Agent-Web抓取几分钟后全部超时反爬触发浏览器会话被目标站点阻断降低并发、增加随机等待、更换UA池Agent-DB的SQL执行报权限错误MCP工具白名单未放行批量查询工具在MCP Server配置中调整工具白名单数据比对结果里大量假阳性Agent-Web抓取时页面未完全加载就取数给浏览器工具增加等待策略等待关键元素出现A2A任务重试后结果重复统计客户端重试时生成了新请求ID重试必须复用原始请求ID保持幂等网关token过期导致长时间无响应长连接没有做自动刷新机制增加token刷新中间件到期前30秒主动续期汇总报告里的日期格式混乱两个Agent对时间字段的解析规则不一致在A2A任务描述中统一定义时间格式规范其中最有价值的一个排查过程是“数据比对结果里大量假阳性”。第一次跑完Agent-Master报了几十个页面数据不一致。逐个核查发现不是页面真不一致而是Agent-Web在滚动页面时页面上有个行情组件是异步加载的抓取时还没渲染出来。加了显式等待策略后假阳性直接清零。这提醒我们浏览器MCP工具的执行稳定性很大程度上取决于等待策略写没写对不能默认所有元素都是同步渲染。还有一个整体验证思路这类自动化核对任务建议在跑完后抽样5%页面做人工复核。我们在100个页面里抽了5个人工逐一比对确认自动化报告与人工结论一致。这个抽检环节虽然看起来笨但它能帮你在自动化任务上线初期建立信心也能反过来校验MCP工具提取的字段精度。跑完这个案例我个人的习惯是每次给多Agent系统加新的工具或Agent先在纸上回答三个问题——它通过MCP要暴露什么能力它通过A2A要跟谁协作它失败时谁兜底三个问题都答得上来再动手写代码。MCP和A2A的组合方案我在生产环境里验证过多轮希望第六篇的这些实录能让你在搭建自己的多智能体系统时少一点空转多一点真正能交付的结果。