从单体 Agent 迁移到多智能体，真正要解决的往往不是“多加几个角色”，而是先把原本混在一个提示词里的责任拆开。只要任务开始同时包含拆解、路由、并行调查、结果会合和人工兜底，系统的主要风险就不再是模型会不会回答，而是控制器能不能解释自己为什么这样分派、为什么此刻该停、以及失败后能不能回到同一个状态继续执行。
这也是很多团队从试点走向生产时的分水岭。MetaGPT 把多角色协作写成可分工的软件流程，ReAct 说明推理与行动必须围绕外部观察闭环，而 Google Cloud 在 ADK 相关文章里强调多智能体更像一套受控编排机制，而不是简单并排运行多个模型。结合 TaskPilots 的多 Agent 协作编排集群经验，比较稳的迁移顺序通常是先改边界和状态，再增加角色数量。
为什么这个问题重要
真实运行代价
单体 Agent 在早期常常看起来很高效，因为一个提示词就能同时承担理解需求、调用工具、判断结果和决定下一步。但当流程长度增加后，这种“全都让一个 Agent 想明白”的做法会迅速暴露代价：任务目标和运行状态混在一起，任何一次工具失败都可能让系统重新解释上下文，团队也很难追溯是哪一步打开了额外分支。
- 同一个 Agent 既要规划又要执行，责任边界很快变得模糊。
- 分支状态只活在上下文里，等待外部事件后容易失真。
- 成本、时延和人工接管点无法映射到明确节点。
如果不处理会怎样
生产环境里最先出问题的通常不是“答错一次”，而是系统开始不可解释。一个分支为什么被重试、另一个分支为什么被提前合并、最终结论为什么覆盖了人工标记，这些关键问题如果都只能从聊天历史里倒推，治理成本会很快超过自动化收益。很多团队以为自己缺的是更强模型，实际上缺的是可恢复的控制面。
适用场景
谁最需要这套方法
当任务天然具有不同职责和不同验收标准时，多智能体才值得承担额外复杂度。比如一个企业采购自动化流程，需要先由控制器拆成合规核验、供应商调查、价格比较和审批汇总四段，这些子任务既能并行，又必须在会合点统一判断是否继续。此时多智能体的价值不是“更像人类团队”，而是让每个角色只承担一种局部判断，再由控制器统一回收。
- 任务可以拆成多个输入输出明确的子任务。
- 并行调查能够显著缩短总时长。
- 最终动作需要统一审批、审计或冲突裁决。
什么时候先不要这么做
如果当前流程仍然是单轮问答、少量工具调用，或者团队连单体 Agent 的输入输出契约都还没稳定，多智能体只会把问题放大。这个阶段更应该先把工具接口、失败分类和人工接手流程整理清楚，再决定是否需要把一个 Agent 拆成多个角色。换句话说，任务边界不清时，先补结构；任务边界已经清楚但一个 Agent 已经扛不住时，再上编排。
推荐系统结构
核心角色与状态
比较稳妥的迁移方式，是先把原系统拆成四类边界：控制器、专家角色、持久状态和委派契约。控制器只负责决定下一步与停止条件；专家角色只处理局部任务，不修改全局目标；持久状态保存任务阶段、分支状态和审批标记；委派契约则定义每次下发任务时允许使用哪些上下文、必须回传哪些字段。这样做的关键不是角色数量，而是把“谁能改目标、谁只能提交证据”写成系统规则。
- 控制器持有全局目标、分支列表、join 条件和人工升级规则。
- 专家角色按能力窄化，例如研究、验证、写作、审计，而不是让每个角色都能做全部事情。
- 持久状态记录任务 ID、节点状态、版本号和最近一次可恢复检查点。
与 TaskPilots 的映射
映射到 TaskPilots，可以把控制面理解为调度和裁决层，把状态层理解为长期运行任务的唯一事实来源，把并行回收机制理解为 fan-out 和 join 的显式契约。实践中我们更推荐先从 controller-worker 模式起步，再逐步补上 reviewer 或 approval 节点，而不是一开始就设计过多角色。相关思路也可以和站内的 把控制器做成状态机，而不是巨型提示词、从 fan-out 到 join：多智能体流程的会合契约 一起看，会更容易把边界拆得足够清楚。
风险与失效点
常见失控方式
多智能体最常见的失效点，不是单个角色能力差，而是边界开始漂移。专家角色一旦开始自己改目标，控制器就被绕开；持久状态如果和真实外部结果不同步，join 时就会合并错误证据；并行分支如果没有预算和停止条件，系统会把等待时间和模型调用一起放大，最后形成明显的成本外溢。
- 角色漂移：专家角色从执行局部任务变成自发重规划。
- 状态失真：聊天历史与数据库状态不一致，恢复后走错节点。
- 分支失控：并行分派没有上限，回收时也没有冲突解决规则。
需要人工兜底的地方
凡是涉及权限提升、真实写入、对外发送、较高成本操作或证据冲突的节点，都应保留人工审批。人工兜底不只是“最后看一眼”，更应该看到结构化上下文，包括当前控制节点、各分支回传摘要、冲突原因和建议动作。只有这样，人工接手才是延续工作流，而不是重新阅读整段对话再猜系统发生了什么。
验证指标
上线前怎么验证
上线前建议不要直接比较“多智能体是否更聪明”，而要验证边界是否更稳定。可以挑 20 到 50 个真实任务样本，覆盖正常路径、分支冲突、外部失败和人工审批四类情况，重点检查控制器是否总能产出同结构的委派、专家角色是否稳定回传约定字段，以及任务在中断后能否从检查点恢复。
- 委派契约完整率：输入字段、输出字段、证据字段是否齐全。
- 分支回收率：打开的并行分支有多少能在限定时间内回到 join。
- 恢复一致性：同一失败场景重放后是否回到同一个状态节点。
上线后怎么持续判断
进入生产后，可以长期追踪四个核心指标：任务完成率、人工接管率、分支回收率和单次任务成本。完成率下降通常说明角色拆分没有真的提高质量；人工接管率过高，说明自动边界仍然太模糊；分支回收率偏低，说明 fan-out 与 join 契约没写清；单次任务成本持续上升，则往往意味着专家角色开始越权、分支数量失控，或者等待时间没有被纳入控制器决策。
下一步 / FAQ
下一步建议
如果你正准备从单体 Agent 迁移，最实用的第一步不是画一个很大的角色图，而是挑出一个已经频繁出现重试、等待和人工接管的真实流程，先补三样东西：显式控制器、结构化状态和最小委派契约。只要这三层稳定了，后面再增加 specialist、reviewer 或审批节点，复杂度会是可累加的，而不是重新洗牌。
FAQ
是不是角色越多越稳？ 不是。角色越多，协调成本和状态同步成本越高。只有当职责和验收标准真的不同，拆角色才有意义。
多智能体一定比工具链更好吗？ 不一定。若流程主要是固定步骤加少量判断，工具链往往更便宜、更可控；只有在需要动态路由、并行调查和会合裁决时，多智能体才更合适。
如何避免迁移过程中权限失控？ 把所有高风险动作留在控制器或人工审批层，专家角色默认只读或只提交候选结果，不直接执行跨系统写入。