编排引擎能协调多个 Agent 执行，但简单的并行分工往往不如单 Agent 产出。每个 Agent 的输出质量波动大、对前序结果的依赖理解不到位、最后需要某个角色费力整合——这些都是分工设计的通病。真正有效的多 Agent 协作不在并行度有多高，而在三个设计问题：一个任务该怎么切，多个输出怎么合，失败怎么隔离。
三种分工形态
按维度分：评审类任务
最典型的是代码审查、文档评审这类需要多个视角的任务。不同 Agent 各自专注一个维度，然后汇总。
代码审查为例，可以分给三个 Agent：
- 安全 Agent：检查输入验证、SQL 注入防护、密钥处理。
- 性能 Agent：检查 N+1 查询、无界查询、热 key。
- 架构 Agent：检查模块边界、耦合、错误处理完整性。
三个 Agent 各自给出意见清单，然后由主 Agent 或一个汇总角色做两件事：一是去重（同一个问题不重复列），二是优先级排序（P0 阻塞还是 P2 建议）。这时汇合规则很关键——不是简单地把三份清单拼起来，而是按某个一致的优先级框架重新整理，确保同一类问题在不同 Agent 眼里的严重程度评价一致。
适用场景：需要多角度评估、各角度相对独立、容忍的是审查遗漏（宁可多查一遍也不要漏掉）。
按对象分：批量改造类任务
一个大仓库有 20 个相似微服务要做改造。主 Agent 分析整体方案后，将 2 到 3 个服务分配给每个子 Agent，各自按统一的改造清单执行。比如统一升级依赖版本、改配置项名、加监控埋点。
分工的要点是对象的独立性——每个微服务的改造之间没有依赖关系，子 Agent 互相不阻塞。汇合时，主 Agent 的职责是验收每个微服务的改动是否符合标准（检查改了哪些文件、是否有遗漏、有没有多改东西）。
这里的风险在并发覆盖。如果两个 Agent 同时改同一个服务的同一个文件，后一个的改动会覆盖前一个——这是文件系统的天然行为。解决办法是为每个 Agent 创建一个独立的工作副本（worktree、文件夹、docker 卷），改完后再由主 Agent 统一合并回主分支。主 Agent 用三方合并工具（比如语言的 AST diff 或 git3way）来处理冲突。
适用场景：对象多、改造逻辑重复、对象之间独立、改动范围清晰。
按阶段分：流水线任务
任务有明确的前后依赖。比如一个大文档的内容写作、技术校对、编辑润色、排版，这四个阶段必须顺序执行。或者编译系统的代码分析、验证、代码生成、打包，也是顺序的。
这时分工的核心是状态机。不同的 Agent 对应不同的状态，前一个 Agent 的输出成为后一个 Agent 的输入。状态机保证流转的合法性——不能跳过某个阶段也不能倒退（除非显式回流）。
朝廷的"三省六部"模型就是这种形态。任务经历太子分诊→中书规划→门下审议→尚书派发→六部执行→复审→完成。每个阶段由一个 Agent 负责，前一个阶段的决策记在进度日志里，后续 Agent 可以看到。门下在审议时如果发现中书规划有问题，不是直接改，而是封驳回流——把任务退回中书重新规划。这样做的好处是每个 Agent 的职责边界清晰，改错了地方能追溯。
汇合设计的核心：仲裁规则
多 Agent 分工的最大陷阱是汇合环节。两个常见的错误做法：
错误 1：没有汇合，只是拼接。 三个 Agent 的代码审查意见各成一份清单，就这样输出三份。这样做等于没有整合，接收方面对信息爆炸，反而降低了效率。
错误 2：汇合逻辑是临时的。 主 Agent 看了三份审查意见，用一段 prompt 说"帮我归纳一下"，希望生成一个漂亮的总结。但每次运行的结果都不一样，因为没有明确的规则。哪些问题合并为一条，哪些要分开列？什么叫"重要"，重要到什么程度才要列在最前面？
正确做法是明确的仲裁规则。比如：
- 多数投票：如果三个维度都指出某个问题，它就是 P0。
- 优先级数组：安全 > 性能 > 架构。安全问题永远排在前面，除非同一个问题在不同维度的严重程度不同（这时取最高级别）。
- 专门的汇总 Agent：把三份意见作为输入，给它一个明确的 prompt：遵循优先级数组，去重，输出一个按优先级排序的单一清单。这个汇总 Agent 自己不做审查，只做聚合。
汇合规则要写成可验证的、确定性的。最好用代码表达——不是用 prompt 模糊地说"要紧的放前面"，而是用数据结构明确地定义"这个 category 的所有问题得分是 500 点，那个 category 是 100 点，然后按总分排序"。如果用 Agent 实现汇总，也要给它一个包括规则表的完整输入，而不是靠 Agent 自己理解"什么叫重要"。
失败隔离：防止级联故障
按阶段分工时，失败隔离特别关键。如果中书在规划阶段卡住了（比如 token 用完、模型不稳定），后续的门下、尚书、六部都要等。这时需要明确的停滞检测和回流机制。
停滞检测：监控每个阶段的时间戳。如果某个 Agent 的产出超过设定的阈值（比如 10 分钟）还没推进到下一个阶段，系统判定为"停滞"并发起重试。
重试策略：不是无限重试。设一个上限，比如同一个 Agent 最多重试 2 次。如果还是失败，任务进入"升级"流程。升级的意思是把这个任务提交给上一级的更强模型或更全能的 Agent，尝试跳过当前卡点。如果升级也失败了，任务标记为 Blocked，等待人工介入。
回流机制：某些故障需要回流而不是重试。比如门下在审议时发现中书的规划有根本性缺陷（不是中书执行失败，而是逻辑本身有问题），就应该把任务退回给中书，让中书重新规划。这不是门下的工作，而是系统的状态机明确允许的一个合法的流转。
记录每一次流转的决策链：为什么这个任务从 Assigned 进入 Review，Review 时查到了什么问题，决定进入 PendingConfirm，等待确认。这样下来，一个任务的整个生命周期都是可追溯的。
反模式：共享资源竞争
按对象分工时容易出现的一个设计陷阱是多个 Agent 直接竞争修改同一个共享资源。比如多个 Agent 并行修改同一个代码库的多个文件。每个 Agent 读文件→改→写回。但如果两个 Agent 几乎同时读、再几乎同时写，后写的改动就会覆盖先写的。这不是 Agent 能力问题，而是分工没有隔离。
解决办法：隔离写操作，在主控层面统一合并。
具体做法是给每个 Agent 独立的工作副本（可以是 git worktree、隔离的文件夹、容器卷），Agent 的改动都落在各自的副本里。改完后，由主 Agent 负责把所有副本的改动统一合并回主仓库——用三方合并工具（git 的 3way merge、AST diff 等）自动处理无冲突部分，对冲突提出明确的警告。
关键细节：
- 每个 Agent 的改动是独立的。即使两个 Agent 同时改，也不会互相覆盖，因为文件系统层面是隔离的。
- 合并是确定性的。不是靠 prompt 让某个 Agent 去"调和"两份改动，而是用确定的合并算法。
- 可追溯。记录哪个文件来自哪个 Agent，哪些行被改了，有没有合并冲突。故障时能指到具体改动。
这个原理在分布式系统里很常见（COW、WAL 等），用在 Agent 编排设计上也是一样的：隔离并发写，集中化合并。
结尾
有效的多 Agent 工作流从来不是"并行度高就行"。关键是明确的分工形态（维度、对象、阶段）、确定性的汇合规则（不靠 prompt 模糊其辞）、以及完善的失败隔离（停滞检测、重试上限、合法的回流）。随之而来的是可追溯的决策链和低 token 成本——因为没有浪费在重复尝试或产出冲突上，每个 Agent 清楚自己该干什么。
■