多智能体系统真正难的，通常不是做不出来，而是失控得太快。角色一多、分支一多、等待一多，问题就会从“能不能跑”变成“谁在负责下一步”。
所以编排不该是默认答案。只有当任务天然需要不同职责、不同评估标准和明确控制器时，多智能体才值得承担额外复杂度。
什么时候值得上多智能体
当一项工作已经清楚分成规划、取证、验证和外部动作，多智能体才会真正增加清晰度。
- 任务由多个边界明确的小任务组成。
- 并行调查能明显缩短流程。
- 系统需要控制器来决定继续、重试或停止。
先设计控制器
最稳的起点不是先凑角色，而是先做控制器。控制器持有目标、分支状态和委派契约，负责解释为什么打开一条路径。
- 当前目标是什么。
- 哪些任务仍在打开状态。
- 每次委派的输入和输出是什么。
专家角色要窄
一个专家角色最好能用一句话说清职责。如果它开始自己改目标、扩范围、定策略，它就不再是专家，而是另一个控制器。
- 按工作职责命名角色。
- 明确输入、输出和禁区。
- 把副作用交回控制器决策。
状态属于工作流，不属于聊天历史
提示词历史只适合当前步骤，不能承担系统唯一记忆。任务一旦会暂停、重试或等待外部事件，就必须依赖持久状态。
- 当前处于哪一步。
- 哪些任务待处理、阻塞或完成。
- 哪些检查点需要人工确认。
并行必须提前设计会合点
并行不是多开几个角色就够了。控制器要先说明两个分支为什么能同时跑，以及冲突时由谁裁决。
链路要记录委派和判断
只看工具调用不够。团队还需要看到是谁打开了新分支、收到什么契约、为什么被接受或退回。
- 记录委派原因。
- 记录回传结果如何被判断。
- 记录重试、升级或停止的触发点。
常见失败点
大多数失败都来自边界太弱。控制器不会停，专家拿到的任务太模糊，状态又只活在上下文里，系统自然越来越不可预测。
结语
编排真正解决的不是“更高级”，而是“更清楚”。先有控制器，再有专家；先有状态，再有并行；先有链路，再谈扩展。