多智能体协作实战：什么时候该拆 Agent，什么时候不该

#

这两年"多智能体"（Multi-Agent）几乎成了 AI 应用绕不开的话题——Claude Code 里的 subagent、n8n 里的多节点工作流、各种 Agent 编排框架，本质上都在回答同一个问题：一个大模型上下文搞不定的任务，能不能拆成几个更小的、各司其职的智能体来协作完成？

但"能拆"不等于"该拆"。见过太多把简单任务硬拆成五六个 Agent、结果比单个 Agent 直接做还慢还乱的案例，也见过该拆不拆、硬塞进一个上下文里最后输出质量直线下降的案例。这篇聊聊实践中踩出来的经验：什么信号说明该拆了，拆的时候有哪些常见模式，以及最容易掉进去的坑。

一、单智能体的瓶颈

#

在讨论"拆"之前，先搞清楚为什么会有拆的冲动。单智能体架构（一个模型、一个上下文窗口、从头做到尾）在两类场景下会遇到明显瓶颈。

上下文膨胀。 大模型的上下文窗口再大也是有限资源，而且不是"用满了才出问题"——研究和实践都表明，上下文越长、无关信息越多，模型的注意力越容易被稀释，早期给出的指令会被后面几十轮工具调用的输出淹没。一个典型场景是"读代码库找 bug"：如果把探索过程中读到的每个文件全部塞进主上下文，还没开始修 bug，上下文就已经被无关的目录结构、过时的注释挤满了。

任务耦合。 一个任务如果同时要求"保持广泛的探索视角"和"给出高精度的最终结论"，这两个诉求在同一个上下文里其实是冲突的——探索阶段需要大量试错和分支，结论阶段需要收敛和克制。让同一个模型实例在同一个对话里反复横跳，容易两头都做不好：探索不够发散，结论又被探索过程中的噪音带偏。

这两个瓶颈指向同一个解法方向：把"探索"和"决策"分开，把"污染上下文的部分"隔离到别处去，而不是让一个智能体从头背到尾。

二、拆分的几种模式

#

实践中常见的拆分方式大致可以归成三类，各自适合不同的任务形状。

并行探索型（Fan-out / Scatter-gather）。 主智能体把一个宽泛的问题拆成若干个互不依赖的子问题，分发给多个子智能体并行执行，各自在独立的上下文里探索，最后只把摘要结果带回主上下文。典型场景是"在代码库里找到某个功能的所有实现位置"——与其主智能体自己一个文件一个文件翻，不如派几个子智能体分头搜索不同目录，每个子智能体读了再多文件，脏的都是它自己的上下文，回到主线的只有一句"在 X 文件的 Y 行"。这种模式的关键前提是子任务之间没有先后依赖，可以真正并行。

流水线型（Pipeline）。 任务被拆成有先后顺序的几个阶段，前一阶段的输出是后一阶段的输入，例如"设计方案 → 编码实现 → 代码审查"。这种模式不追求并行提速，追求的是阶段间的角色隔离——写代码的智能体不应该同时是审查自己代码的智能体，就像人不容易审出自己文章里的错别字一样，独立的审查阶段能拿到一个"没有先入之见"的视角。

主从型（Orchestrator-Worker）。 一个主智能体持有全局状态和最终决策权，按需调度多个worker子智能体去完成具体子任务，worker 之间互不感知，只和主智能体通信。这是前两种模式的自然延伸——多数实际系统其实是主从型的框架里同时用了并行和流水线：主智能体先并行派发几个探索型 worker，收集结果后再串行派发一个执行型 worker。

三种模式的共同点是：子智能体的上下文是"一次性"的，它们的探索过程、走过的弯路、读过的无关文件都不会进入主上下文，主智能体收到的永远是提炼后的结论。这才是"拆"真正节省的东西——不是省算力，是省主上下文的干净程度。

三、真实案例复盘

#

案例一：代码库探索的分级派发。 在用 AI 辅助编程时，一个常见操作是"这个函数在哪定义的"“这个报错哪里来的”。如果是单个关键字的精确定位，直接搜索比派子智能体更快——派发和收集结果的通信开销比搜索本身还大。但如果问题是"这套鉴权逻辑在整个项目里是怎么串起来的"，涉及多个文件、多种命名习惯，这时候派一个专门做"广泛探索"的子智能体去做全局搜索、只带回一份综合结论，就明显比主智能体自己边搜边读要干净得多。区别对待的标准很朴素：明确知道去哪找，就自己去；范围不确定、要发散式搜索，才值得拆出去。

案例二：方案实现与复核的角色分离。 写一段实现代码和审查这段代码，如果放在同一个连续对话里，审查环节很容易变成自我确认——因为审查者（还是同一个智能体）已经"知道"自己是怎么想的，很难跳出实现时的思维定式去质疑关键假设。把审查放到一个独立的子智能体里，不共享实现阶段的对话历史、只拿到最终代码和需求描述，反而更容易挑出前后不一致、遗漏的边界条件这类问题。这里拆分带来的价值不是并行提速，而是视角的独立性——花的时间可能更多，但复核质量确实更高。

两个案例合起来的经验是：拆分的收益来自"上下文隔离"或"视角独立"，而不是自动带来速度提升——如果任务本身不需要这两样东西，拆分只会增加调度和通信的开销。

四、常见坑

#

过度拆分。 最常见的错误是"看到任务有好几步，就每一步都拆一个 Agent"。子智能体之间的通信是有损的——只能传递摘要，传不了细节的语气、上下文里的隐含假设。步骤之间耦合度高、需要频繁来回澄清的任务，拆得越细，信息损耗越大，还不如一个智能体带着完整上下文一路做完。经验法则是：拆分要以"子任务之间是否存在硬依赖"和"子任务本身是否需要独立的探索空间"为准，而不是以步骤数量为准。

状态丢失。 子智能体默认不共享主智能体的对话历史，如果主智能体没有把关键约束（比如"不要动某个目录"“性能优先于可读性”）显式带过去，子智能体很容易在缺乏上下文的情况下做出偏离预期的决策。这个坑的解法不是少拆，而是把子智能体当作一个刚入职、什么都不知道的同事去交代任务——需要哪些背景、排除了哪些方案、期望的输出格式，都要在派发时一次性讲清楚，而不是假设它能"猜"到主线的隐含共识。

结果冲突。 并行派发的多个子智能体如果各自对同一份状态做了假设性的修改（比如都以为自己是第一个改某个配置文件的），汇总阶段就会出现冲突甚至互相覆盖。并行探索型任务（只读、只产出信息）几乎不会有这个问题，但一旦涉及并行的写操作（比如让几个 Agent 同时改代码），冲突就几乎是必然的。稳妥的做法是只对纯只读的探索任务做并行，涉及修改的操作即使拆分，也串行执行或者限制在互不重叠的文件范围内。

五、什么时候不该用多智能体

#

拆分不是免费的——每多一个子智能体，就多一次调度延迟、多一次上下文摘要的信息损耗、多一份需要交代清楚的背景假设。以下几种情况，单智能体几乎总是更好的选择：

• 任务本身足够小，一个上下文完全装得下，比如改一个函数、写一段脚本——这时候拆分纯粹是开销，没有收益。
• 步骤之间强耦合、需要保留完整的推理链条，比如调试一个需要来回假设-验证的疑难 bug，中断上下文去问一个不知情的子智能体，反而打断了原本连贯的排查思路。
• 对时延敏感的交互式场景，多一层调度就多一层延迟，用户体感的响应速度会明显变差。
• 任务的准确性依赖于"一个人从头到尾负责"的一致性，比如需要贯穿全文的写作风格、需要统一决策标准的判断类任务，拆给多个智能体反而容易出现风格割裂或标准不一。

说到底，多智能体不是"更高级"的默认选项，它只是解决"上下文隔离"和"视角独立"这两类具体问题的工具。判断要不要拆，先问自己：这个任务卡住的原因，到底是"一个上下文装不下"“一个视角看不清”，还是别的什么——如果两者都不是，大概率不需要多智能体。