1. 从单兵作战到集群协作多智能体到底在解决什么问题我去年花了大半年时间一直在跟 LangChain 的 DeepAgents 死磕。一开始只是拿它写点自动化脚本、跑跑数据流后来越用越不对劲——单智能体的能力天花板太明显了一个 agent 既要会调用工具、又要会拆分任务、还得处理上下文长尾稍微复杂一点的业务流转它就手忙脚乱不是遗忘中间状态就是重复调用同一个工具。直到我把架构切换到多智能体集群配合 MCP、A2A 和 Skills 这套组合拳才真正感受到什么叫“112”。先说结论单体 agent 做演示没问题做生产级应用一定不够。你需要的是多个智能体各司其职再通过统一协议让它们互相通信、共享能力、编排任务。这个思路的背后就是 DeepAgents 提供的编排框架、MCP 提供的工具接入标准、A2A 提供的智能体互联协议以及 Skills 提供的可复用行为封装。把这四样组合在一起你才能搭建出一个真正能应对复杂业务的多智能体集群。写这篇博文的时候我已经用这套架构跑通了几个实际项目包括一个电商客服场景和一个私有数据问答系统。过程中踩了不少坑也总结出一些真正能落地的经验。如果你恰好也在调研多智能体架构或者已经在用 LangChain、Claude Code、Cursor 这类工具但总觉得单兵作战不够爽这篇文章应该能帮你省下不少试错时间。下面我按自己的理解把这套架构拆成四个核心部分DeepAgents 怎么用、MCP 怎么接、A2A 怎么连、Skills 怎么写。最后再给一个完整的实战案例把整条链路串起来。2. DeepAgents多智能体编排的主控大脑2.1 DeepAgents 到底是什么和普通 Agent 有什么区别DeepAgents 不是简单地对 GPT-4 这类模型做一层包装它更接近一个完整的智能体运行时。普通 agent 的典型工作方式是你给它一个任务它在自己的循环里调用工具、生成回复直到任务结束。这个过程是单线程的、串行的所有决策都由同一个模型完成。DeepAgents 引入了一个很有意思的机制subagents子智能体。主智能体负责接收用户意图、拆解高层计划然后把子任务委派给不同的 subagent每个 subagent 可以有自己的工具集、自己的上下文窗口、甚至自己的模型配置。这就好比一个项目组里项目经理不亲自写代码而是把模块分给前端、后端、测试各自去干。实际使用中你会发现这种分工带来的最大收益不是速度而是上下文隔离。单 agent 最头疼的问题就是上下文爆炸——对话稍微长一点模型就开始遗忘早期信息。而 subagent 每个都有自己的独立上下文主 agent 只需要维护一个高层的“项目状态”具体细节由各 subagent 自己处理再汇报结果。我做过的项目里有个任务涉及 200 多个文件的状态跟踪之前单 agent 跑到第 80 个文件就已经乱套换成 DeepAgents 后让 5 个 subagent 各管 40 个文件全程零失误。2.2 DeepAgents 的架构拆解Planner、Worker 与 Supervisor官方文档把 DeepAgents 的架构描述得比较抽象我用自己的话说一下。整个运行过程可以拆成三个角色Planner规划器负责理解用户需求生成一个高层的任务清单。比如用户说“帮我分析这份财报”Planner 会拆出“读取 PDF”“提取财务指标”“对比历史数据”“生成分析报告”四个子任务。Worker执行器也就是 subagent每个 Worker 拿一个子任务调用自己配好的工具去执行。执行完了把结果返回给 Planner。Supervisor监督器盯着整个流程的执行状态判断是否需要调整计划。比如某个 Worker 执行失败Supervisor 会决定是重试、换工具、还是告诉 Planner 修改子任务。这三个角色不是每次都同时存在。简单任务下Planner 和 Worker 可以合并但复杂任务里三者缺一不可。我自己习惯的做法是任务拆解是硬编码的不交给模型自由发挥。也就是我在代码里明确写好“这个任务必须拆成三步”而不是让模型自己决定怎么拆。原因很简单模型自己拆的任务很多时候不合理尤其是在工具调用受限的时候。以 LangChain 的 DeepAgents API 为例典型的初始化代码长这样from langchain_deepagents import DeepAgent from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o, temperature0) agent DeepAgent( namedata_analysis_agent, llmllm, tools[read_pdf, extract_indicators, compare_history, generate_report], max_subagents5, ) result agent.run(请分析这份2024年度财报)这里max_subagents控制了最多能创建多少个子智能体。我试过设成 2 和设成 8 的区别设小了任务排队时间变长设大了上下文切换开销反而让效率下降。实际经验是普通业务场景 3~5 个 subagent 是最佳区间超过 8 个就需要重新审视任务拆解逻辑了。3. MCP让每个智能体都能“伸手够到”外部世界3.1 MCP 协议的本质它是 AI 世界的 USB-C很多人第一次接触 MCPModel Context Protocol时容易把它和普通的 API 库搞混。举个例子你给 agent 配一个 HTTP 请求工具这在传统开发里就是“写一个 function calling 接口”。但 MCP 做的事情更底层它定义了一套统一的协议让任何 agent 都能通过同一种方式连接任何支持 MCP 的工具服务。类比一下没有 USB-C 之前各种设备用不同的充电口你得备好几根线。MCP 就是统一了充电口的标准——你只需要一根线就能连手机、连笔记本、连平板。MCP 之于 AI 工具生态就是这个角色。你不需要为 ChatGPT、Claude Code、DeepAgents 分别写一套工具适配代码只要对方实现了 MCP server你就能直接连。这个“标准化”的价值在集群场景里被放大很多倍。一个多智能体集群里可能要接数据库、浏览器、设计软件、代码编辑器、API 网关等几十种工具。如果每个工具都单独做适配工作量是爆炸性的。但 MCP 协议统一之后每个工具只需要实现一个 MCP server所有 agent 都能复用。3.2 MCP Server 与 Client核心概念与一次完整的工具接入MCP 的架构分两端。MCP Server服务端持有实际工具能力的进程。比如一个 MySQL MCP Server能接收 SQL 查询请求并返回结果。MCP Client客户端运行在 agent 内部的连接器。agent 通过 Client 发现 Server 提供的工具列表再动态决定调用哪些。我自己在项目里最常用的接入方式是通过 stdio 或 SSE 两种传输方式。stdio 适合本机进程SSE 适合远程服务。比如在 DeepAgents 里接入一个本地的浏览器自动化 MCP Serverfrom langchain_deepagents import DeepAgent from mcp_client import MCPClient mcp_client MCPClient(http://localhost:8931) browser_tools mcp_client.discover_tools() agent DeepAgent( nameweb_agent, llmllm, tools[*browser_tools], )这里discover_tools()是关键——它会用 MCP 协议里的tools/list方法向 Server 请求当前可用的工具列表然后把工具的动态参数 schema 转换成可被模型识别的格式。这也是 MCP 的优势之一工具的增删不需要改 agent 代码只要 Server 端更新Client 自动感知。我在实际测试中接过 Playwright MCP Server、Chrome DevTools MCP Server、MySQL MCP Server、甚至 Blender MCP Server。除了 Blender 因为软件自身的稳定性问题偶尔卡死其他几个都表现得非常稳定。当前端开发场景里Chrome DevTools MCP Playwright MCP 的组合几乎能覆盖所有浏览器交互类任务。区别在于Chrome DevTools MCP 偏向读取页面信息和操作 DOMPlaywright MCP 更擅长完整的浏览器自动化流程比如填表单、点击导航、截图断言。两者可以互补使用但要注意同一个页面同时被两个工具控制时抢占资源导致的冲突。3.3 谷歌浏览器扩展中的 MCP 连接设置一个值得关注的新动向热词里有一条“谷歌浏览器扩展设置中启用MCP连接”这确实是一个趋势。现在很多浏览器自动化框架比如 Browser Use 的底层模型都依赖浏览器扩展来实现对页面的精细控制。MCP 被放进浏览器扩展设置意味着用户可以在浏览器的 UI 层直接管理哪些工具可以被 agent 调用。这套设计对多智能体集群特别有用你可以在扩展里给不同的 subagent 分配不同的权限。比如“数据收集 agent”只能读取当前标签页“自动化测试 agent”才有操作 DOM 的权限。权限粒度控制在本地浏览器层面做效率非常高而且不涉及敏感服务端配置。具体操作上如果你用的是 Chrome 系浏览器在扩展管理的“选项”页面里找到“MCP 连接”相关设置填入你的 MCP Server 的 WebSocket 或 HTTP 端点即可。需要留意的是现代浏览器扩展默认禁用了跨站请求如果你把 MCP Server 跑在远端要给扩展设置里加上对应的域名白名单否则连接会被浏览器策略直接拦掉。这个坑我踩过一次排查了半天最后发现只是白名单没配。4. A2A智能体之间如何“说人话”协作4.1 A2A 协议的核心思路智能体的“会话层”MCP 解决的是“agent 调工具”A2AAgent-to-Agent协议解决的是“agent 找 agent”。两者是不同层面的东西千万别混。MCP 属于工具接入层A2A 属于智能体通信层。A2A 协议最早由 Google 提出后来被 Linux Foundation 接手。它的核心抽象是 AgentCard——每个 agent 通过一份 JSON 描述文件宣布自己的能力和通讯端点。其他 agent 通过发现 AgentCard、理解其能力范围然后发起任务请求。你把它理解成是两个项目经理在开会A 说“我这边需要一份财务汇总”B 说“我可以做但我需要原始数据”A 回复“数据在这个共享盘里”。整个沟通过程是结构化的、基于消息传递的而不是让一个模型去读另一个模型的输出。4.2 实现一次 A2A 通信从 AgentCard 到任务交付实际开发里A2A 的通信流程大概是这样的发现Agent A 从注册中心读取 Agent B 的 AgentCard。AgentCard 里包含name、description、url、skills等字段有点像智能体的“简历”。协商Agent A 根据 AgentCard 里的能力描述判断 Agent B 是否适合执行当前子任务。请求Agent A 向 Agent B 的端点发送一个task请求携带任务描述和上下文数据。执行与反馈Agent B 接收任务执行过程中通过status消息向 Agent A 同步进度。交付Agent B 完成任务返回结果Agent A 继续后续流程。这个流程看起来简单但实现起来有几个细节编解码格式统一被定义成 JSON所以两端不需要共享代码库。任务 ID 是全局唯一的整个生命周期内通过它追踪状态。超时和重试机制必须上层实现A2A 协议本身不保证交付。在 DeepAgents 里接入 A2A 时我习惯把 A2A 通信器封装成一个 Tool 暴露给主 agent。这样主 agent 不需要理解协议细节只需要在工具列表里看到“call_agent_b”这个动作就行。封装思路from langchain_deepagents import DeepAgent from a2a_client import A2AClient a2a_client A2AClient(https://agent-b.example.com/a2a) def call_agent_b(task_desc: str) - str: task_id a2a_client.submit_task(task_desc) result a2a_client.wait_for_task(task_id, timeout120) return result.data agent DeepAgent(llmllm, tools[call_agent_b])这里有件事值得多提一嘴在多智能体集群里跨主机的 A2A 通信要特别注意安全。如果 Agent B 是公网节点传输通道一定要走 TLS同时建议在 AgentCard 里声明authentication字段标明需要的凭证方式。否则你的集群很容易被动成为别人攻击链的跳板。5. Skills把高频操作固化成“肌肉记忆”5.1 Skills 到底是用来解决什么的前面提到的 DeepAgents、MCP、A2A 都是架构层的设计但真正让 agent 从“能用”变成“好用”的往往是 Skills。Skills 的概念是 Anthropic 在 Claude Code 里大规模推广的一个 Skill 就是一组预定义的行为规则、提示词和工具调用序列的集合。它把高频场景的操作逻辑预先封装好agent 遇到对应任务时直接按 Skill 执行而不是每次从零推理。举个例子。我经常需要做前端页面改动如果不用 Skillagent 每次都要自己想“改一个按钮颜色需要哪几步”找到文件、定位样式、修改代码、刷新预览。这个推理过程既慢又容易出错。但封装一个“修改前端样式”的 Skill 之后agent 直接按 Skill 里写好的流程执行效率和准确性都提高了不止一个档次。Skills 解决的问题本质上是大模型的推理能力不应该被浪费在重复且确定的操作序列上。既然你已经知道怎么做了为什么不把它固化下来释放模型的认知资源去处理真正需要推理的部分5.2 实战解析怎么开发一个自己的 Skill开发 Skill 没有想象中那么神秘。它本质上就是一个目录里面包含描述文件、提示词模板、脚本和资源引用。以我写的一个“生成月度销售报表”Skill 为例它的结构是这样的monthly_report_skill/ ├── SKILL.md # 技能描述告诉 agent 什么时候使用 ├── prompts/ │ ├── extract_data.txt # 数据提取的提示词模板 │ └── analyze_trends.txt # 趋势分析的提示词模板 ├── scripts/ │ └── query_database.py # 查询数据库的辅助脚本 └── resources/ └── report_template.xlsxSKILL.md 是这个技能的门面它决定了 agent 在什么情况下会选择这个 Skill。我的一般写法是--- name: monthly_sales_report description: 当用户要求生成月度销售报表、分析销售趋势或查询销售数据时使用。 --- 执行步骤 1. 读取用户指定的月份和产品线。 2. 运行 scripts/query_database.py 拉取原始数据。 3. 按 prompts/analyze_trends.txt 的模板生成趋势结论。 4. 将结果填入 resources/report_template.xlsx。 5. 输出最终报表路径。这里有个很关键的实操心得描述部分一定要写得“窄”。如果你写“当用户需要数据分析时使用”那 agent 遇到所有数据分析任务都会优先调它最后就是频繁误选。把它限定到特定场景比如“月度销售报表”命中率会高很多。5.3 常见 Skills 推荐从小白到进阶的实用技能库我见过不少初学者一上来就想着自己搞一套复杂的 Skills 体系结果最后维护成本比收益还高。我的建议是先收藏一些成熟开源的 Skills 库用好了再自己写。这里有几个比较有代表性的方向前端开发类 Skills包括页面调试、响应式布局调整、性能优化检查。这些 Skill 大多结合 Chrome DevTools MCP 或 Playwright MCP能自动打开浏览器、读取控制台报错、修改代码再刷新验证。数学建模类 Skills这类 Skill 更适合学术场景主要是把常见建模步骤比如数据预处理、特征工程、模型训练、结果可视化固化成标准流程模板。数据库操作类 Skills这类 Skill 会把 MySQL、PostgreSQL 的常见操作规范化包括检查表结构、查慢查询、生成备份 SQL减少手写 SQL 的出错率。AI 漫剧类 Skills你没看错现在连内容生产领域都有 Skills 生态。这类 Skill 通常封装了脚本生成、分镜描述、角色一致性提示词等步骤。我见过有团队把一集 3 分钟的漫剧生成时间从 3 小时压缩到 40 分钟流程就固化在一个 Skill 里。5.4 使用 Skills 时必须避开的坑Skill 并不是万能的以下几个问题我在实际使用中踩过写出来供你参考。第一Skills 与工具 Chain 的冲突。有时候你既配了 Skills又在代码里硬编码了工具调用链agent 就会不知道该听谁的。我的经验是如果任务流程是确定不变的直接用代码写死如果任务场景多变、需要模型判断才交给 Skills。两者不要混用。第二Skills 的版本管理。Skill 会依赖具体工具的 API比如 Chrome DevTools 升级了可能旧的 Skill 脚本就失效了。我会在项目的 CI 流程里加一个定期检测工具版本和 Skill 兼容性的任务避免线上突发故障。第三Skills 的上下文长度。有些 Skill 的提示词又长又啰嗦塞进去直接挤占上下文窗口。这种现象尤其在用 8K 上下文的模型时很明显。所以我一般把 Skill 里的提示词控制在 1.5K 以内关键信息前置避免 agent 读到一半失去焦点。6. 全流程实战用 DeepAgents 搭一套 Web 自动化多智能体系统6.1 场景设定与架构总览理论说了一大堆真正要上手还是得有完整的案例。这里我拿一个真实跑过的项目来做讲解一个名为“前端自动巡检与修复”的多智能体系统。它的业务目标是每天晚上自动访问指定的三个业务页面把控制台报错、异常样式、接口异常全部检查一遍然后自动修复能修的代码问题生成巡检报告。这个系统由 4 个智能体组成智能体职责依赖工具Orchestrator主控拆分巡检任务、汇总结果、决定是否触发修复DeepAgents 内置Page Inspector页面巡检员访问页面、读取 DOM、捕获控制台错误Chrome DevTools MCP、Playwright MCPData Analyzer数据分析员分析报错信息与页面源码的关联MySQL MCP、本地脚本Code Fixer代码修复员读取源码、快速修复、触发重验GitHub MCP、ESLint MCP架构上Orchestrator 是唯一的对外入口其他三个智能体通过 A2A 协议互相通信。工具接入统一走 MCP操作队列和技能库用 Skills 管理。整套系统的结构可以用下面这张表来理解用户触发 | v OrchestratorDeepAgents 主控 |-- A2A - Page InspectorChrome DevTools MCP / Playwright MCP |-- A2A - Data AnalyzerMySQL MCP / 分析脚本 |-- A2A - Code FixerGitHub MCP / ESLint MCP用户只需要给 Orchestrator 一个指令“巡检今天的页面状态”后面整个链路都是自动的。6.2 核心实现步骤说明第一步配置工具层。我需要让所有智能体都能访问各自的 MCP 工具。用 DeepAgents 的ToolRegistry来管理工具依赖每个智能体创建时只注入它需要的那组工具避免工具权限过度暴露。第二步定义 Skill。巡检流程可以固化成一个 Skill包括“打开页面、收集控制台日志、截图、返回状态码”这一整套动作。Code Fixer 也有自己的 Skill比如“模块化修复样式冲突”和“修复 API 调用异常”。第三步编排逻辑。在 Orchestrator 的代码里我用了一组明确的 if-else 加状态机的逻辑来判断如果 Page Inspector 报告有报错就通知 Data Analyzer 分析如果分析结果确认是代码原因就通知 Code Fixer 修复修复完成后触发一次重新巡检确认效果。整个编排逻辑的伪代码是async def run_inspection(): page_report await page_inspector.run() if page_report.has_errors: analysis await data_analyzer.run(page_report) if analysis.is_code_related: fix_result await code_fixer.run(analysis) await page_inspector.recheck(fix_result.files_changed) return build_final_report(...)第四步嵌套 subagents。这个场景下我把 Data Analyzer 和 Code Fixer 这两个智能体再做了一层拆分。Code Fixer 里根据报错类型又分成了“样式修复 subagent”和“逻辑修复 subagent”。这样做的动机是样式修复和逻辑修复的工具集是截然不同的分开之后上下文更干净。6.3 关键参数与经验max_subagents、timeout 和重试策略很多人在多智能体编排时只关注任务拆分不注意性能参数。我把自己实际调过的最优参数写在这里供你直接参考。max_subagents6这个值在巡检场景下够用不会平级横向膨胀太多。timeout90s任何单一 subagent 执行超过 90 秒就判定超时报给 Orchestrator 决定重试还是降级。retry_policy3执行失败最多重试 3 次超过 3 次写入巡检失败清单等待人工介入。concurrency2同一时间最多两个 subagent 并行执行。设成 5 的时候浏览器实例开得太多资源竞争反而更耗时。这套参数在实际运行了两周整体成功率稳定在 98% 以上唯一一次告警是页面本身改版导致旧 Skill 里的选择器失效。这也印证了之前说的Skills 的维护不能一劳永逸业务页面变了Skill 就得跟得改。6.4 这套架构放在企业级场景中的扩展思路如果你看完前面的案例觉得这套架构离自己的业务还远不用急。我再补充一个思路——怎么把上面的系统扩展成更通用的企业级集群。多智能体集群架构最重要的扩展方向之一是横向扩容A2A 协议天然支持不同物理机上的 agent 通信你可以把 Page Inspector 部署在 A 机器上Data Analyzer 在 B 机器上Code Fixer 在 C 机器上只要它们能通过 AgentCard 互相发现整个集群就和在一台机器上没什么区别。另一个扩展点是针对业务做权限隔离。每个 subagent 只赋予完成其任务所需的最小权限。不要让数据分析员直接拿到生产数据库的写权限也不要让代码修复员直接推 main 分支。权限隔离不仅是安全要求也能避免 agent 在复杂逻辑下无限调工具。还有一点我特别想强调在多智能体集群里日志追踪是命根子。单个 agent 出错你还能翻对话记录5 个 agent 互相调用下来没有统一的 trace 系统根本定位不了问题。我在项目里用的是 OpenTelemetry把 A2A 消息和 MCP 工具调用全部做成 span 上报到 Jaeger排查问题的时间至少缩短了一半。7. 常见问题与排查技巧实录这部分我整理了自己和其他开发者交流时最常被问到的几个问题按问题现象、原因、排查思路、实操解决方法的顺序来写。7.1 DeepAgents 创建 subagent 不生效或数量超限现象你在代码里设了max_subagents3但实际运行中 agent 还是只用了 1 个。或者反过来设了 3agent 却一次性创建了 8 个直接把上下文和工具会话数打爆。原因分析这个和模型对任务拆分逻辑的理解直接相关。DeepAgents 不是每次运行都创建满额 subagents它需要模型自己“判断”任务复杂度是否值得额外创建子智能体。模型倾向于保守。排查建议在提示词里显式引导拆解。比如在任务描述里明确写“这个任务包含 3 个独立子任务请分别处理”模型会明显更愿意创建对应数量的 subagents。另外检查你的工具列表里是否有“Task Decomposition”类工具如果有它的返回值会直接影响模型对复杂度的判断。7.2 MCP Server 连接失败connection refused或ETIMEDOUT现象Agent 初始化时报错连不上本地的 MCP Server尤其是在 Docker 化部署之后。原因分析八成是因为 MCP Server 运行在容器的 localhost而 agent 在另一个容器里localhost指向的是容器自己不是宿主机。此外如果你用的是 SSE 传输CORS 策略也会造成连接被拒。排查步骤先在本地命令行用curl或 Postman 直接访问 MCP Server 的健康检查端点确认 Server 本身没问题。检查 agent 运行的网络命名空间与 Server 是否一致。跨容器时用宿主机的局域网 IP 代替localhost。检查 Server 日志确认是否有拒绝特定 Origin 的记录。SSE 模式下大多数 MCP Server 默认只接受来自http://localhost的请求需要显式配置允许的源。7.3 Skills 被模型选择但效果不如预期现象Skill 能被正确命中但执行出来的结果不完整经常跳过中间某个步骤。原因分析我发现最常见的原因是提示词模板里的步骤写得太泛没有强调“必须按顺序执行”。模型的默认行为是“能省则省”凡是看起来不影响最终结果的步骤它可能直接省略。解决方案在 SKILL.md 里加硬性约束。比如在步骤开头加一句“严格按照以下顺序执行不得跳过任何步骤”或者在每个步骤之间用变量依赖来锁住顺序比如第二步的输入是第一步的输出。这就从机制上避免了模型跳过关键环节。7.4 A2A 消息丢失或乱序现象Agent A 向 Agent B 发了任务Agent B 也执行完了但 A 一直拿不到结果。或者两次消息的顺序反了。原因分析A2A 协议本身不保证消息顺序如果你的底层通信是异步的又没有做消息编号就会出现乱序。另外任务超时设置过短也会导致 A 认为消息丢失实际上 B 还在跑。排查建议检查 A2A 消息体里的task_id和message_id是否正确递增。把超时时间调大到正常执行耗时的 2 倍以上先排除超时误判。在 Agent B 的日志里确认任务状态流转是否完整submitted - running - completed。7.5 全套排查速查表问题核心原因快速解决方法子智能体数量不足模型没有拆解足够子任务提示词中显式写明子任务数量subagents 数量爆满任务拆得过细权限混乱调低 max_subagents合并同类任务MCP 连接失败网络命名空间不一致或 CORS检查容器网络配置允许 OriginSkill 执行跳步提示词约束不足添加依赖变量锁定执行顺序A2A 消息乱序异步通信无消息编号为 message_id 做严格递增工具调用循环重复模型未理解任务已经完成在 Skill 中增加终止条件比如“当检测到 success 标志时结束”8. 我最后的几句体会玩了大半年 DeepAgents、MCP、A2A、Skills 的组合最大的感受是这套技术栈的难点不在于单个工具的使用而在于把它们的边界想清楚。MCP 管工具接入A2A 管智能体通信Skills 管行为固化DeepAgents 管整体编排。每一层只做好自己的事系统才能稳定。如果你现在还在用单智能体处理复杂业务我建议你抽一个周末尝试把任务拆给两三个 subagent再配一个简单的 MCP Server 和一个基础 Skill。不用追求一次到位先跑通链路再逐步丰富工具和技能库。等这套链路跑顺了你会跟我一样很难再退回单体 agent 的“刀耕火种”时代。最后再分享一个小技巧多智能体集群跑起来之后发现无论是 MCP 还是 A2A它们的调试最好都保留在一个统一的可视化页面里。我自己用的是 LangSmith 搭配 Jaeger把每一次工具调用、每一条 A2A 消息都记录下来。项目上线前多花半天做链路追踪后期排查问题会省下大把时间。踩过坑之后你会明白可观测性才是多智能体生产环境里最容易忽略、也最影响体验的一环。