multi-agent-orchestration

多 Agent 编排

将工作拆分为相互独立的单元，并行分派给子 Agent，然后整合结果。编排器负责拆分任务、制定约定和合并结果；子 Agent 只负责执行。

适用场景

当任务包含真正独立的子任务（不同文件／模块、并行研究线程、扇出式搜索），且串行执行的成本确实较高时，适合使用。收益来自独立性。

当子任务共享可变状态、必须按顺序执行，或协调开销超过实际工作量时，不要使用。一个专注的 Agent 胜过五个互相妨碍的 Agent。

拆分任务

拆分后的每个单元都应满足：

• 相互独立——不共享可变状态；执行过程中没有单元依赖其他单元的输出。
• 自成一体——提示词包含所有上下文（路径、约束、完成定义）。子 Agent 看不到对话内容。
• 可验证——交付成果清晰且可检查。

如果两个单元必须修改同一个文件，或一个单元需要另一个单元的结果，就将它们合并为一个单元，或按顺序执行——不要并行处理。

分派任务

• 将独立单元一次性批量启动，以便并行运行；不要启动一个、等待完成，再重复启动。
• 为每个 Agent 提供：目标、确切范围（包括和不包括的内容）、输入／路径、输出格式、完成标准。
• 根据工作类型选择合适的 Agent（只读探索、实现或审查）。
• 并发数不要超过真正独立单元的数量上限——Agent 多于独立单元只会增加合并成本。

角色（明确分配）

• 编排器——拆分任务、分派、合并并解决冲突。不编写功能代码。
• 工作 Agent——执行一个单元，并报告结构化结果。
• 审查 Agent（可选）——由独立 Agent 根据规范检查合并后的结果；绝不审查自己的工作。

合并

1. 收集结构化结果；唯一返回的内容是工作 Agent 的消息——转达其中重要的信息。
2. 检查冲突：修改重叠、发现矛盾、假设偏移。
3. 有意地协调处理（由编排器决定；如果工作 Agent 遗漏了范围，则重新分派该单元）。
4. 对合并后的结果执行集成检查——各单元单独通过，也可能组合后出问题。

反模式

• 多个“并行”Agent 编辑同一个文件 → 发生竞争并丢失工作成果。
• 采用顺序分派（启动、等待、再启动），却称之为并行——没有提速。
• 子提示词含糊，假设 Agent 能看到它无法访问的对话上下文。
• 未执行集成检查就接受合并结果。
• 为 2 个独立单元启动 N 个 Agent。

完成条件

每个单元的交付成果都符合其标准，冲突均已解决，且集成结果通过了针对原始目标的端到端检查。