很多团队第一次做多智能体时，最容易犯的错不是角色太少，而是刚开始就把系统拆得过细。角色越多，委派、状态回收和异常解释就越难统一，最终控制器反而成了一个没人说得清的黑盒。
更稳的起点通常是控制器加执行者。控制器只负责目标、路由、会合与停止条件，执行者只负责在清晰边界内完成局部任务。这样既能获得多角色协作带来的清晰分工，又不会在第一天就把系统复杂度推到失控区间。
为什么这个问题重要
真实运行代价
一旦任务需要拆解、并行调查和外部动作，单体 Agent 往往会把“下一步做什么”混在同一段上下文里。随着工具调用变多、等待时间变长，系统很快就失去可解释性。控制器与执行者模式的价值，就是把决策面和执行面拆开，让团队能清楚回答是谁在决策、谁在产出结果、谁在判断是否继续。
- 控制器持有目标、分支状态和委派契约。
- 执行者只处理局部任务，不自行扩张目标。
- 会合点由控制器统一判断，避免各角色互相覆盖状态。
如果不处理会怎样
没有明确控制器时，角色会偷偷兼任调度者，执行结果也会以叙述形式回流，导致分支难以回收、失败难以归因、人工接管时更不知道应该从哪一步恢复。表面上看系统“很灵活”，实际上一旦遇到超时、重试或冲突结论，就很难保持稳定。
适用场景
谁最需要这套方法
当任务天然包含不同职责的步骤，而且这些步骤可以被清楚定义为“提出计划”“执行局部工作”“返回结构化结果”时，控制器与执行者模式就足够支撑第一阶段上线。它尤其适合需要把复杂流程先拆开、但又不想立即引入规划者、评审者、审计者等更多角色的团队。
- 需要把一个目标拆成 2 到 5 个明确子任务的流程。
- 需要并行调查不同信息源，再统一判断下一步的流程。
- 已经接入工具和外部系统，但还希望控制面保持简单的团队。
什么时候先不要这么做
如果任务本质上只是单轮工具调用，或者系统还没有明确的任务边界与输出契约，多智能体不会带来真正收益。这时优先把单体 Agent 的工具契约、状态记录和失败处理做好，通常比引入第二个角色更划算。
推荐系统结构
核心角色与状态
最小可行结构的关键，不是“一个控制器加若干执行者”这么简单，而是控制器必须显式持有运行状态。它至少要知道当前目标、已打开的分支、每个执行者的输入输出契约，以及什么条件下可以继续、重试或停止。
- 控制器定义任务目标、拆解原则和结束条件。
- 执行者接收精简后的上下文包，只返回结构化结果与置信判断。
- 控制器负责会合、冲突裁决和是否触发人工接管。
与 TaskPilots 的映射
在 TaskPilots 的多 Agent 协作编排集群里，这种模式对应的是一个清晰的控制面加若干窄职责执行节点。控制面负责状态层、分支回收和升级逻辑，执行节点负责完成取证、分类、验证或内容生成等局部工作。这样做的好处是后续要扩成 planner-worker-reviewer，也是在现有控制器之上继续加层，而不是推翻重做。
风险与失效点
常见失控方式
最常见的问题有三类。第一类是控制器本身没有状态，所有判断都藏在长上下文里，结果是一次重试就丢掉前文。第二类是执行者拿到的任务描述太宽，开始自己改目标、加步骤或调用不该调用的工具。第三类是会合契约太弱，控制器收到的只是自然语言总结，无法稳定比较不同分支结果。
- 角色边界变宽，执行者悄悄演变成第二个控制器。
- 并行分支返回格式不一，控制器无法可靠合并。
- 没有明确停止条件，系统持续打开新分支并放大成本。
需要人工兜底的地方
涉及高成本副作用、跨系统写入或结论冲突时，人工介入应当放在控制器层，而不是让执行者自由决定。这样既能保留自动化速度，也能保证升级时能看到当前目标、各分支结果和触发接管的原因。
验证指标
上线前怎么验证
上线前不要只测“能跑通”。更重要的是验证控制器能否稳定拆解任务、执行者能否按契约回传、控制器能否在冲突结论下保持一致判断。最有效的做法是准备一批代表性任务，刻意覆盖并行分支、信息矛盾、工具失败和人工接管四类场景。
- 检查同一任务多次运行时，拆解与会合是否稳定。
- 检查执行者回传是否始终符合预设字段。
- 检查工具失败时，控制器是否会重试、降级或停止。
上线后怎么持续判断
生产阶段至少要追踪任务完成率、分支回收率、人工接管率和单次任务成本。对于控制器与执行者模式，还应额外看“无效分支率”和“回传契约合规率”，因为这两项最能揭示角色边界是否开始变形。
下一步 / FAQ
下一步建议
如果你的团队还在判断是否要做多智能体，先不要设计完整组织架构。先用一个控制器加少量窄角色执行者把状态、委派和会合做清楚。等这套最小结构能稳定运行，再决定是否增加规划、评审、审批或治理层角色。
FAQ
控制器会不会变成新的单点瓶颈？ 会，所以它必须持有显式状态和清晰停止条件，而不是继续靠巨型提示词硬撑。
什么时候应该加 reviewer？ 当执行结果的质量判断已经成为独立步骤，而且评审标准可以稳定定义时，再单独拆出 reviewer 才有价值。
控制器能不能直接做工具调用？ 可以，但应该只保留少量与调度强相关的动作；大多数业务执行仍应由执行者承担。