最近大半年我身边的开发者社区出现了一个挺明显的变化大家手里已经不止一个 Agent而是开始认真讨论Agent 的组织方式。我自己在把几个单体 Agent 项目推向生产环境的过程中也踩了不少坑最深的体会是——单体 Agent 不是不好用而是当你把真实业务塞进去之后它会用各种方式提醒你能力的边界不在单次回答的质量而在系统结构。标题里这四个词放一起——DeepAgents、MCP、A2A、Skills——本质上是在回答同一个问题如果 Agent 要成为团队里的正式员工而不是一个偶尔帮上忙的临时工它需要什么样的基础设施和组织关系在这篇内容里我会从单体 Agent 的天花板讲起把 MCP 的外部工具接入、Skills 的团队经验沉淀、A2A 的跨 Agent 协作这三层逻辑拆开再给出一个从单体重构为多智能体组织的完整实操路径。这一套搞下来你能获得的不是多跑几个 Agent 实例的伪多智能体而是真正具有分工、协议、知识沉淀的 Agent 组织。1. 为什么单体 Agent 迟早要走向多智能体组织1.1 单体 Agent 的天花板不是能力不够是结构不对先拿单体架构的演进史来做个类比。早期的软件系统都是一个大单体所有功能塞在一个进程里好处是开发快、逻辑简单坏处是一旦系统变复杂改一个模块就可能拖垮整个应用。后来大家把系统拆成微服务靠 HTTP/消息队列做通信才解决了复杂的规模化问题。Agent 行业的处境几乎一模一樣。单体 Agent 看似智能但你在真实项目里跑一个月就会发现三个硬瓶颈。第一个瓶颈是上下文窗口的物理限制。再大的上下文窗口也架不住你把需求文档、代码库、数据库 schema、第三方 API 文档、日志排障记录全部塞进一次会话。我见过最典型的场景一个单体 Agent 接手了一个中型仓库历史对话几千轮之后它开始遗忘自己三天前确定的技术选型。这和人一样短时记忆是有限的硬塞不会让 Agent 更强只会让它更混乱。第二个瓶颈是工具链的膨胀。单体 Agent 要干活你得给它挂上各种工具——读写文件、执行命令、调 API、查数据库、发通知。全堆在同一个 Agent 里工具描述占用的上下文 token 越来越多模型做工具选择的准确率反而下降。实测下来工具数超过 20 个之后误调、漏调、重复调的概率明显上升。第三个瓶颈是责任边界模糊。一个 Agent 既负责需求拆解又负责写代码还负责自我代码审查。这里面有个天然的冲突它很难在想快速完成任务和严格审查自己的产出质量之间保持平衡。就像让一个人既当运动员又当裁判结果往往会偏袒自己。单体 Agent 的问题不是能力不够强而是结构承载不了复杂度的增长。这不是模型能力的问题是工程结构的问题。1.2 多智能体不是堆数量是重新划分职责边界很多人一听多智能体第一反应是那我同时开十个 Agent 并行跑任务是不是就叫多智能体了这只是并发不叫组织。真正的多智能体组织核心是两件事划分职责边界定义交互协议。每个 Agent 只负责自己领域内的事然后把任务通过明确的协议交给下一个 Agent。这跟你公司里的团队协作逻辑一模一样——产品经理不自己写代码程序员不自己测试测试不自己上线。每个人有明确职责流程节点上有明确的交付物和验收标准。职责边界带来的直接好处是信息隔离。Planner Agent 不需要读全部代码才能拆任务它只需要理解需求和架构概览Coder Agent 不需要管业务方为什么提这个需求它只需要把任务卡里的实现细节落到代码上。每个 Agent 的上下文只装自己该装的东西token 利用率会高很多。失败隔离同样重要。单体 Agent 一旦在某个环节犯错后面全乱。但组织化的 Agent 系统里Reviewer Agent 发现代码有问题只需要把任务退回给 Coder AgentPlanner 不用重新拆一遍任务。错误被圈定在局部系统整体可控性显著提高。1.3 四个技术坐标DeepAgents、MCP、A2A、Skills 各管哪一层这四个概念容易混因为大家都在同一个领域里刷屏。我习惯用组织管理的类比来记DeepAgents含 Claude Agent SDK、Claude Code 这类 Agent 运行时相当于员工本身——它提供了 Agent 循环、状态管理、调度能力是承载智能的最小可运行单元。Skills相当于员工手册和内部培训材料——把团队的最佳实践、操作规范、领域知识沉淀成 Agent 可以直接读取和遵循的技能包。MCPModel Context Protocol相当于员工连接外部系统的标准接口——让 Agent 能稳定的调用 GitHub、数据库、浏览器、内部 API 这些外部工具不需要为每个工具单独写适配。A2AAgent2Agent相当于公司内部的协作流程与通讯协议——让不同的 Agent 能互相发现、派单、回传结果。这四个坐标合在一起才是一个能进生产环境的多智能体组织。单用其中任何一个都只是局部优化。下面我按这个逻辑逐个深挖。2. DeepAgents把 Agent Loop 变成可运行的工程底座2.1 Agent Loop 的本质一个带状态的工作循环理解 DeepAgents 这类框架首先得理解 Agent Loop 这个概念。传统软件调用是请求-响应你发一个 HTTP 请求服务端处理完给你一个响应结束。Agent Loop 完全不是这样——它是一个持续运行的循环模型根据当前上下文做一次推理决定下一步动作。如果是调用工具就执行工具拿到结果。把工具结果拼回上下文再次触发模型推理。循环往复直到模型判定任务完成输出最终结果。这中间每一步都在修改上下文状态所以 Agent 本质上是一个有状态的工作循环而不是一次性的问答。这也是为什么很多团队自研 Agent 框架到后期会非常痛苦——循环、状态、中断恢复、错误处理每个环节都是坑。我自己最早用裸 API 手撸 Agent 循环遇到了几个很现实的问题工具调用的结果格式不统一有的返回 JSON 有的返回纯文本模型解析经常出错循环一旦中间断了整个状态就丢了日志稀烂根本看不清楚模型每一步为什么做出这个决策。这些问题的本质是你虽然调了模型 API但你没有做成一个合格的 Agent 运行时。2.2 DeepAgents 在框架层做了什么Subagents、Hooks、状态管理DeepAgents也就是 Claude Agent SDK这类框架把上面说的这些脏活累活做了标准化你在上面搭业务逻辑而不是从零搭运行时。先说 Subagents 机制。这是实现多智能体组织最底层的一个能力——一个主 Agent 可以动态派生多个子 Agent每个子 Agent 有自己的上下文窗口和任务目标。子 Agent 干完活把结果汇报给主 Agent然后可以回收。这解决了一个大问题主 Agent 不需要亲力亲为处理每一个细节它可以像团队负责人一样把不同的任务分包出去。Hooks 机制也非常重要。Hooks 提供了一组生命周期回调——比如在模型每次推理之前、工具调用之后、Agent 循环结束时触发自定义逻辑。我拿它做过几件很实用的事每次 Agent 调用工具之前先做权限校验防止它误操作生产环境每次工具调用之后把关键结果追加写入独立日志事后可以审计 Agent 当时做了什么在 Agent 进入死循环时自动熔断保底不烧钱。状态管理这块框架也做了很多工作包括会话持久化、断点续跑、上下文的自动压缩。这些功能在单机玩具项目里可有可无但到了生产环境Agent 跑一两个小时甚至过夜任务的场景非常多状态不靠谱整个系统就不可靠。2.3 以 DeepAgents 为底座的最小可行架构我的建议是不要一开始就上五个 Agent 甚至十个 Agent。先以 DeepAgents 为底座搭一个最小可行的单节点架构跑通之后再演进出组织。有一个非常经典的模式叫 Planner-ExecutorPlanner Agent负责接收需求拆解任务输出结构化任务卡。Executor Agent负责具体执行任务卡里的步骤调工具、写代码、跑命令。Reviewer Agent可选但推荐审查 Executor 的产出给出通过或打回意见。这个模式结构简单但已经具备多智能体组织的雏形——每个 Agent 有明确角色、有独立上下文、有协作关系。更关键的是它让你能在一套代码里先把 DeepAgents 的 Subagents、Hooks、状态管理这些基础能力吃透后面再上 A2A 这类协作协议时会轻松很多。3. MCP 与 Skills外部接口与内功心法的双层解耦3.1 MCP 解决Agent 接外部世界的标准化问题如果说 DeepAgents 解决了Agent 怎么运行的问题那么 MCP 解决的是Agent 怎么连接外部世界的问题。在 MCP 之前Agent 接一个工具基本是扒一层皮。每个工具都要单独写一套接入逻辑——GitHub 有一套 REST APIPostgreSQL 要写查询封装浏览器要起自动化控制内部系统可能要走 RPC。这些接入逻辑全写进 Agent 大脑里最终结果是工具描述占用大量上下文模型选择工具的准确率还低。MCP 用一套标准协议把这个问题统一了。它的核心架构是 Host宿主比如 Claude Code、IDE、Client协议客户端、Server工具提供方。Server 暴露三种能力给 AgentTools可执行的动作比如创建分支、发 PR、跑测试。Agent 决定何时调用。Resources可读取的上下文数据比如文件内容、数据库 schema、配置项。Agent 在需要理解环境时读取。Prompts可复用的提示词模板比如生成周报审查代码Agent 可以直接套用。这个协议的真正价值是提供了一种类似USB-C的标准化体验。开发者只需要把工具封装成 MCP Server任何支持 MCP 的 Agent 都能直接使用。今天给 Claude Code 配上 GitHub MCP Server明天给 Codex 配上同一个 Server不需要重复开发适配层。传输层上MCP 支持两种模式。stdio模式适用于本机子进程Agent 起一个 MCP Server 的本地进程通过标准输入输出通信轻量、低延迟。Streamable HTTP模式适用于远程服务通过 HTTP 传递 JSON 消息适合团队内共享的 MCP Server。我之前用 PostgreSQL MCP Server 时走 stdio把内部的 Schema 查询服务暴露给前端 Codex 和 Claude Code 一起用时就部署成 HTTP 模式团队里所有工程师都能接。3.2 Skills 解决Agent 知道怎么做的知识沉淀问题MCP 解决的是Agent 具备调用外部工具的能力但还缺一块Agent 知道该怎么规范地干活。这就是 Skills 要解决的问题。Claude Skills 这类能力本质上是把操作规范和领域知识做成一个技能包核心是一份 Markdown 文件——SKILL.md外加可选的参考脚本、模板、配置文件。这份 Markdown 文件里写清楚这个 Skill 解决什么问题、在什么场景触发、执行的关键步骤是什么、要注意哪些禁忌。Skills 和传统 Prompt Engineering 最大的区别在于Prompt 是写给单次对话的Skill 是写给一类任务的。Prompt 是随用随写、用完即弃Skill 是能沉淀、能版本化、能跨项目复用的资产。用一个类比MCP 是给 Agent 了一把电钻Skills 则是告诉他打孔的标准化流程——先用定位器标记位置、钻孔深度多少、打完之后怎么清理。电钻是工具打孔是手艺。多智能体组织里这两者一个都不能少。Skills 和 MCP 的分工边界我总结一句话Skills 承载组织内的 know-howMCP 承载外部系统的 do-what。Skills 讲流程规范MCP 提供操作入口。同一个数据库Schema 查询用 MCP Server 来做但查询之前先确认表名、查询之后要把结果按约定格式汇报这种规范应该写进 Skills 里。3.3 实操把团队的代码规范做成一个 Skill拿一个最常见的场景举例把团队的代码审查规范沉淀成 Skill。先定义 SKILL.md 的 frontmatter描述技能的身份和触发条件--- name: code-review-checklist description: 用于代码审查场景检查代码质量、安全、性能、可维护性。当用户要求审查 PR、审查代码 diff、评估提交质量时使用。 ---正文部分按团队规范写成结构化清单。关键点是面向 Agent 的文档要写得足够可执行每条标准尽量带明确检查方法和通过条件而不是注意代码质量这种空话。比如检查是否有硬编码密钥或敏感信息搜索 sk_、password、token 等模式一旦命中必须打回。检查异常处理所有外部 IO 是否有 try-catch异常是吞掉还是向上抛。检查 SQL 注入风险拼接 SQL 的字符串是否经过参数化。写成 Markdown 而不是 JSON 是有讲究的。Markdown 本身就是 LLM 训练数据里极其常见的格式模型对它的理解成本最低。而且 Markdown 允许混排列表、代码块、表格表达力比 JSON 强得多。我见过有人把 Skills 写成 YAML 配置结果模型读取时经常理解偏差后来全部改成 Markdown准确率明显提升。Skills 的目录结构也建议规范每个技能一个文件夹里面 SKILL.md 实测可用的参考脚本。整个 Skills 目录跟着项目仓库走团队人人可复用。4. A2A让 Agent 之间学会互相派活4.1 从工具调用到 Agent 互调A2A 协议想解决什么问题MCP 把 Agent 和工具连接起来了但还有一类连接没有标准化——Agent 和 Agent 之间的连接。在跨系统协作场景里这个问题尤其明显。打个比方前端开发 Agent 发现接口文档和实际契约对不上它需要找后端 Agent 确认。在没有 A2A 之前你只能把两个 Agent 塞进同一个上下文或者靠人肉去转达。多智能体系统一旦跨越了单机边界、跨越了不同框架、甚至跨越了不同的团队开发维护就需要一个标准化的协议来定义 Agent 之间如何互相发现、发送任务、回传结果。A2AAgent2Agent协议就是干这个的。它和 MCP 的核心区别在于MCP 是 Agent 对工具的连接Agent-to-toolA2A 是 Agent 对 Agent 的连接Agent-to-agent。一个管理人用工具一个管理人与人之间的协作从字面上就分得清清楚楚。4.2 A2A 的核心对象AgentCard、Task、Message、ArtifactA2A 协议设计的核心对象有四个简洁但覆盖了跨 Agent 协作的所有关键环节。AgentCard是 Agent 的名片用 JSON 描述能力、提供方、支持的传输方式、认证方式。其他 Agent 拿到卡片就能知道这个 Agent 能干什么、怎么找它。Agent 注册到 Agent Directory 之后别的 Agent 能通过目录发现它。这个设计类似于微服务里的服务注册与发现是整个协作体系里偏容易被忽略、但实际上决定系统可用性的一环。{ name: coder-agent, description: 根据任务卡实现代码支持主流语言连接 GitHub 与数据库 MCP 服务, url: https://agents.internal.dev/coder, skills: [python, typescript, sql, refactoring], authentication: { scheme: bearer, credentials: env:A2A_CODER_TOKEN } }Task是 Agent 之间的工单有一个唯一 ID 和生命周期状态。典型状态流是 submitted - working - input-required需要输入更多信息- completed / failed / canceled。任务状态的存在让多智能体协作变得可追踪——你随时可以知道一个任务卡到哪个 Agent 手里了是正在干、还是卡住等输入、还是已经完成。Message是 Agent 之间传递的内容单元内部由 Part 组成Part 可以放文本、文件、代码片段、结构化数据。Artifact是任务完成后产生的产物比如生成的代码文件、修改后的文档、测试报告。这套设计最讨巧的地方在于它把 Agent 之间的协作建模成了交办任务 追踪状态 交付产物而不是远程函数调用 同步等待返回。前者天然支持异步、支持中途被打断、支持追踪审计这在真实工作流里非常重要。现实中很少有一个 Agent 同步等另一个 Agent 计算完的情况更多是任务半天跑完、中间还要互相确认信息的场景。4.3 一个 A2A 协作的时序需求 Agent 如何把任务派给编码 Agent拿前面讲的 Planner / Coder / Reviewer 三人小组来做时序梳理你就明白 A2A 在实际跑起来是什么感觉了。Planner Agent 收到需求之后拆解并生成一个 Task调用 Coder Agent 的接口把任务发出去。Coder Agent 返回 202 Accepted同时创建一个 Task 实例状态是 working。Coder Agent 干了一半发现需求里有个技术细节不清楚于是把 Task 状态更新为 input-required并在 Message 里带上具体问题。Planner Agent 看到这个状态补充说明后再发一条 Message把 Task 推回 working 状态。Coder Agent 完成后把最终代码作为 Artifact 附加到 Task 上状态标记为 completed并通过 AgentCard 里标注的 webhook 通知下游 Reviewer Agent 去审。Reviewer Agent 审完如果发现问题生成一个新 Task 退回给 Coder Agent并附上审查意见作为 Message。这个流程里每一步的状态流转都有记录、每一条 Message 都可追溯。出了事故能回溯是哪一步决策导致的——这在单体 Agent 里几乎不可能做到。A2A 实际上是在为 Agent 系统建立类似于流程管理后台的能力。5. 从单体到组织的实操重构路径以三人开发小组为例5.1 重构前的单体状态与问题清单我在一个内部工具项目上做过一次完整重构初始状态特别典型一个单体 Agent大概就是拿 Claude Code 跑全流程肩负从需求分析到代码实现到测试到发版的全部任务。最初的几天它表现确实亮眼需求文档丢进去直接能产出可运行的代码。但两周后问题集中爆发工具数量堆到十几个Agent 开始在选择工具时犹豫不决有时候重复调用同一个查询工具三四次需求稍微带点上下文关联它就容易漏掉之前定好的技术约束最要命的是代码审查环节它对自己的产出几乎不会提出质疑审查形同虚设。整理出来就四条问题职责过载、上下文混乱、审查失效、不可审计。这四条是单体 Agent 复杂度上去之后的典型症状凡是在生产环境跑过单体 Agent 的人应该都有同感。5.2 拆分方案Planner / Coder / Reviewer 三个 Agent重构方案非常朴素拆成三个 Agent各管一段。Planner Agent负责理解需求文档、拆解任务卡、跟踪整体进度。它的上下文里只装需求文档、任务清单、架构图不装具体代码。Coder Agent负责写代码。它只接收 Planner 的明确任务卡不直接面对原始需求。它通过 MCP 连 GitHub、连数据库、连本地沙盒专注于实现。Reviewer Agent负责审查代码。它的关注点是质量、安全、规范拥有代码审查 Skills 和读取测试结果、静态检查结果的能力。为什么是三个而不是更多因为这正好对应软件开发最基本的三个环节想清楚做什么、动手做、检查做得好不好。再加一个运维 Agent、再加一个文档 Agent会徒增协议交互成本而这三个已经覆盖了单体 Agent 最痛的三块短板。5.3 落地步骤Skills 先行、MCP 接入、A2A 串联重构的执行顺序很有讲究我强烈建议按Skills 先行 - MCP 接入 - A2A 串联这个顺序走每一阶段都有独立的验证点。第一步做 Skills 沉淀。把团队已有的代码规范、审查清单、提交规范先整理成 3-5 个 Skill 文件随仓库走。这个阶段不需要写任何新代码只是把组织怎么干活这件事文本化放在 Agent 能读到的地方。验证方法是让单体 Agent 在挂载 Skills 的情况下跑一次代码生成和审查任务观察产出是否符合规范。第二步接 MCP。把 GitHub 操作、数据库查询、本地命令执行这几个最常用的能力封装成 MCP Server然后接进 Coder Agent。这时候你会发现 Agent 的工具调用开始变得干净一次只做一件事上下文里也不再堆大段工具说明。验证方法是跑一遍 Coder Agent 从开分支到提交 PR 的完整链路确认每个 MCP 工具调用都稳定可靠。第三步才是上 A2A。把 Planner、Coder、Reviewer 各自的 AgentCard 写出来部署 A2A Server然后跑第一个跨 Agent 任务。优先跑那些原本就在单体场景里容易出错的协作动作比如Planner 派任务给 Coder - Coder 回传代码 - Reviewer 审查打回 - Coder 修订先把这个最小协作环跑通。验证方法是任务的状态流转是否清晰、失败时能不能准确定位到是哪个 Agent 的问题。5.4 关键配置与代码实现示例下面给一个最小可复现的配置骨架覆盖三个层次的落地关键点。MCP 客户端配置以 Claude Code 为例JSON 片段{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_TOKEN: ${GITHUB_TOKEN}, GITHUB_REPOSITORY: my-org/my-repo } }, postgres: { command: npx, args: [-y, modelcontextprotocol/server-postgres], env: { DATABASE_URL: ${DATABASE_URL}, SCHEMA_PATH: ./db/schema.sql } } } }A2A Task 下发用 Python 的 requests 写一段最小伪代码import requests TASK_URI https://agents.internal.dev/coder/tasks def dispatch_to_coder(planner_payload: dict) - str: resp requests.post( TASK_URI, json{ type: task/submit, task: { description: planner_payload[description], input: planner_payload, metadata: {agent: planner-agent, trace_id: planner_payload[trace_id]} } }, headers{Authorization: Bearer ...} ) resp.raise_for_status() task_id resp.json()[taskId] return task_id def poll_task_status(task_id: str): resp requests.get(f{TASK_URI}/{task_id}, headers{Authorization: Bearer ...}) return resp.json()[status]Skills 文件目录的组织方式skills/ ├── code-review-checklist/ │ ├── SKILL.md │ └── review_rules.yaml ├── sql-review/ │ ├── SKILL.md │ └── examples/ │ └── bad_sql_examples.sql └── commit-convention/ ├── SKILL.md └── commit_templates/ └── feat.md这里想强调一点Skills 的目录和 MCP Server 的配置都应当纳入版本管理。它们是团队资产跟代码一样需要 review、需要演进。如果只在某一个人电脑上有效那等于没做。5.5 这个方案在真实项目里的效果与成本重构之后这个三人小组在内部工具项目上跑了将近两个月实际效果可以从三个维度说。质量维度代码审查打回率反而提升了但打回的基本都是规范和安全隐患问题很少有需求理解偏差。原因是 Planner 把需求拆清楚之后Coder 只负责实现不太会出现理解错了整个需求这种跑偏事故。成本维度token 消耗确实变多了。同样的功能开发多 Agent 协作比单体 Agent 大概多花 15%-25% 的 token主要是任务描述、状态同步、审查意见这些跨 Agent 消息的开销。但代码返工次数明显下降综合算下来单位有效代码量的成本反而降低了。可维护性维度最大的提升是出问题时的可排查性。以前单体 Agent 跑飞了你完全不知道它在想什么。现在每一个任务都有状态、有 trace_id、有消息记录你可以精确地看出是 Planner 拆错了、Coder 实现错了还是 Reviewer 漏审了。有一点要诚实说多 Agent 不是免费的。它引入了部署和协议的成本、增加了一次任务的延迟还会带来跨 Agent 消息的 token 开销。所以不是所有项目都适合拆。如果你只是写点一次性脚本、做点个人小工具单体 Agent 完全够用。判断标准很简单当单 Agent 的错误已经伤害了项目质量或者你已经难以理解它的决策才是引入多智能体组织的时机。6. 多智能体系统的常见坑与排查实录6.1 问题速查表多智能体系统的调试难度比单体高不少下面是我实测遇到的高频问题整理成速查表方便直接对着排查。现象根因排查方向解法Planner 派了任务Coder 一直没有执行A2A Server 不可达或任务消息没成功投递检查目标 Agent 的 AgentCard URL 能否访问查任务队列日志引入消息重试和超时机制必要时加死信队列Agent 陷入工具调用死循环反复调用同一个 MCP 工具工具返回结果不符合预期模型反复尝试或循环上限没设查看循环日志确认工具输出格式检查 Hook 是否熔断给 MCP 工具统一输出格式在 Agent 循环上设置最大轮次并触发熔断多个 Agent 出现任务互等整体流程卡死跨任务依赖形成了环A 等 BB 等 A画任务依赖图找出环拆分任务层级去掉环状依赖增加超时和人工介入通道Agent 上下文越来越慢token 账单激增跨 Agent 消息里塞入大量原始代码/日志上下文膨胀检查 Message 的 Part 内容看是否有不必要的大块文本用 Artifact 引用替代消息内嵌让接收方按需读取Skills 声明了但 Agent 不按规范执行SKILL.md 的触发条件写得太模糊或描述与任务语义不对齐检查 frontmatter 的 description 写得是否具体重写 description和任务的典型描述做对齐测试在 Skill 里加不适用条件MCP 工具调用时频繁超时远程 MCP Server 过载或鉴权缓存过期查 MCP Server 日志与网络延迟给 MCP Server 加缓存和限流客户端侧重连6.2 三件事别做过度拆分、无限上下文、Agent 互等死锁第一个反模式是过度拆分。我见过一个团队为了充分应用多智能体把流程拆成九个 Agent分别负责需求理解、接口设计、代码生成、单测编写、集成测试、文档编写、安全审查、性能优化、发布执行。结果系统变成了一个巨大的编排调度器Agent 之间的通信消息比实际干活还多任何一个 Agent 抖动都会导致全局排队。我的经验是起步阶段拆到三个角色足以覆盖大部分场景每个角色背后可以用 Subagent 或者进程池去扩并发而不是无限增加 Agent 类型。第二个反模式是无限上下文。多智能体系统有个隐藏诱惑——你可能会觉得跨 Agent 传消息很方便于是把大量原始日志、代码片段、完整配置文件都塞进消息里。短时间内不会出问题等消息量大起来接收方 Agent 的上下文窗口会被撑爆然后开始假装理解式地瞎干活。解决方案是约定消息只传元信息和关键片段完整内容通过 Artifact 或共享存储按需拉取。第三个反模式是 Agent 互等死锁。多智能体协作最典型的死锁场景是Agent A 在等 Agent B 完成数据库迁移Agent B 在等 Agent A 给出迁移脚本的最终版本。看起来荒谬但在真实系统里相当常见尤其是任务拆解不干净、依赖关系有环时。排查的时候把任务依赖图画出来找环同时务必在所有跨 Agent 调用上设置超时和人工介入通道。不能只有机器在等系统里得有人类管理员随时能插一脚。6.3 想清楚再动手何时应该停留在单体架构最后给一个逆向判断。多智能体架构听着高级但技术债也随之而来。我需要非常诚恳地告诉你以下情况建议先别拆留在单体 Agent 反而更快任务规模小一个 Agent 在单个上下文里就能完成纯粹是因为模型能力不够才失败那是换模型的问题不是拆架构的问题。团队里没有足够强的工程能力去维护 Agent 基础设施。多智能体系统需要有人盯着 A2A Server、MCP Server、Skill 版本、Agent 日志。如果没人维护系统会比你想象的更快烂掉。实时性要求极高而跨 Agent 协作无法忍受一次任务多跳的延迟。如果用户点了按钮等 5 秒出结果单体直连模型仍然是首选。多智能体是一个手段不是目的。架构演化应该跟着复杂度走不要跟着潮流走。单体 Agent 能解决的事拆成多智能体组织只是增加维护成本技术上并不会显得更高明。我在实际重构中还有一个体会多智能体系统真正要管理好的不是每个 Agent 的智能而是它们之间的协议。DeepAgents 提供运行底座MCP 接外部工具Skills 沉淀组织的方法论A2A 打通协作链路——这四层合在一起胜过一个全知全能但一团乱麻的巨型单体 Agent。如果你也在从单体走向多智能体的路上我的建议是从最小的三个角色开始先把 Skills 写起来把 MCP 工具接稳再慢慢用 A2A 把协作链条打通。结构对了复杂度是可控的结构不对堆多少聪明都白搭。