先记住这个答案
该模式适用于子任务数量和性质依赖具体输入、无法提前写死工作流的场景，典型如代码库多文件修改或多源信息检索。中央编排 LLM 根据任务实时制定计划，将子任务分派给多个 worker 执行，再汇总结果。与固定工作流的根本区别在于分解本身由模型驱动，因此能应对不可预测的任务结构。但如果子步骤可预先枚举，则应选用 prompt chaining 或 parallelization，以降低延迟和不可控性。
- 子步骤不可预先确定时优先考虑该模式。
- 编排者根据具体输入动态规划任务分解。
- 固定步骤任务应改用更简单的工作流。
编排-工人的运行机制
Orchestrator-Workers 包含一个中央 LLM 编排者和若干 worker 模型。编排者接收用户任务后，先规划一个临时执行计划，确定需要哪些子任务、它们的依赖关系以及如何分配。然后调用 worker 各自执行一个子任务，每个 worker 的提示词由编排者根据上下文构造，包含足够的具体指令和必要背景。worker 返回结果后，编排者整合中间结果，若需要还会触发后续轮次的补充查询。
该模式的关键属性是子任务列表不在代码中预处理，而是输入相关的动态结构。例如，修改视频生成脚本可能涉及调参、验证输出和回滚三步骤，但具体改动哪些参数完全依赖任务描述。这种灵活性让系统能处理边界情况，但代价是编排者的规划质量对整体成功率有重大影响，规划偏差可能导致错误累积。
代码库多功能模块化重构
假设输入：一个后端仓库有 40 个服务，用户要求“将认证模块的日志统一改为结构化 JSON，并增加请求 ID 追踪”。此任务涉及多个配置文件、中间件和测试文件，数量与类型依赖具体代码现状。编排者先分析仓库结构，识别出需要修改的 7 个文件，包括中间件入口、日志工具类和 3 个测试文件，将其分为三个相互独立的子任务：改造日志格式、添加请求 ID 生成、更新测试断言。
在这个假设场景中，三个 worker 并行执行，各自运行测试验证。编排者收集结果时发现测试断言与请求 ID 关联逻辑不匹配，便动态创建第四个 worker 修正测试夹具。最终预期所有测试通过，改动合并。若使用固定工作流，开发者需预先枚举所有可能文件，难以覆盖仓库演变后的新组件；编排模式则根据当前状态决策，能处理未知文件结构与依赖。
适用边界的判断条件
容易失效的场景是任务可被清晰离散化为固定阶段，例如“翻译并校对”两步永远不变，此时 prompt chaining 更简单可控。或子任务完全独立且数量已知，如对十个文档分别摘要，parallelization 的预先切片可节省编排开销。另外，若执行过程需要多轮探索性决策，并涉及环境反馈循环，直接使用 agent 模式更好，因为 worker 间缺乏共享记忆时，编排者每次都要重述上下文，成本增大。
编排者单点错误会导致分派计划失误，本身需要验证和重试机制。实践中给每个 worker 返回结果附加结构化状态（如 success、error），编排者据此决定是否重试或调整计划。同时要限制 worker 数量和轮次，避免无限扩张。引入人工检查点，在关键改动前由人确认，能有效降低灾难性失败风险。
容易答错的地方
- 混淆为高层并行化
- 并行化是预先将任务切分为固定子任务，而 Orchestrator-Workers 是编排者动态决定子任务。误用并行化会丢失对不可预知子任务的覆盖，导致遗漏。
- 认为只能用于多文件代码任务
- 虽然代码修改是典型案例，但多源研究、报告生成等也适用。关键在于子任务集随输入可变，而非特定领域。排除搜索任务会错过广泛应用。
面试官还会怎么问？
编排者的规划如何与 worker 的执行结果交互？
Worker 返回结构化结果，编排者查验是否满足目标，若缺失则创建额外 worker 或要求重试。该循环让计划能动态修正，但需设置最大轮次避免死循环。
与 Supervisor 多 Agent 模式有何不同？
Orchestrator-Workers 是工作流模式，worker 通常是单步 LLM 调用，无自主循环；Supervisor 则管理多个自主 Agent，后者能独立行动多步。前者更像调度，后者偏向治理。
如何评估 Orchestrator-Workers 是否比单 Agent 更划算？
对比端到端延迟与总成本。若子任务可并行，该模式通常比单 Agent 串行长循环延迟更低，但可能因多个 LLM 调用增加 token 消耗；若子任务串行依赖明显，单 Agent 免去汇总开销，往往更划算。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。