编排已更新 2026-06-24 · 版本 1.1
编排器-工作器
编排器 LLM 动态地将任务分解为子任务，将每个子任务委派给工作器 LLM，并综合结果。与固定的并行化不同，编排器在运行时决定子任务，这使其适用于无法提前预知如何分解的复杂任务。
证据: 生产环境置信度: 低来源: 生产系统来源: 个人经验来源: 行业观察
问题
某些任务过于复杂，无法通过单次调用完成，且无法提前分解，因为所需的子任务取决于输入。
适用场景
当任务需要动态分解（子任务的数量和性质因输入而异），且协调模型能够规划和整合工作时，请使用编排器-工作器模式。
解决方案
主导（编排器）模型分析任务，决定需要哪些子任务，并将每个子任务委派给工作器模型（通常是专门的）。然后，它收集并综合工作器的输出以生成最终结果。
它是并行化在智能体（Agentic）层面的泛化：分解是在运行时决定的，而不是硬编码的，这增加了灵活性，但代价是更多的协调工作和不可预测性。
组件
编排器（主导）模型工作器模型委派逻辑综合器共享状态 / 工具
优势
- 处理具有动态分解特征的复杂任务。
- 工作器可以针对每个子任务进行专门化。
- 无需硬编码步骤即可扩展以适应各种输入。
风险
- 协调开销、延迟和 Token 成本。
- 比固定工作流更难预测和调试。
- 编排器可能会规划失误或进行无限循环。
不适用场景
- 当分解方式提前已知时——使用链式调用或固定并行化。
- 适用于单次调用即可处理的简单任务。
- 当可预测性和严格的成本控制至关重要时。
技术
LangGraphCrewAIOpenAI Agents SDKModel Context Protocol (MCP)
示例
- 一个编码任务，其中主导模型决定要修改哪些文件并委派编辑工作。
- 一个研究任务，被拆分为若干子问题，每个子问题分别进行研究然后进行综合。
- 一份由动态选择的章节组装而成的复杂报告。
生产实践证据
- 上下文
- 在 57 天内（161 个会话 / 2,776 个轮次）观察到的单操作员、本地优先 OpenClaw 部署，数据自智能体自身的轨迹追踪聚合而来。
- 场景
- 计划的工作在从父会话派生的隔离、一次性工作器会话中运行，并具有能力范围限制以及子会话/深度限制。
- 技术
- Cron 隔离智能体运行时、会话派生（forkSessionFromParent）、子智能体通道与注册表，以及每个智能体的子会话/深度限制。
- 负载
- 在窗口期内共有 57 个 Cron 隔离的工作器会话（未调用显式的 sessions.spawn 工具）。
- 结果
- 57 个隔离的工作器会话在没有跨会话干扰的情况下运行；派生会话隔离是主要的工作器模式，而显式的 spawn 工具在此窗口期内保持未使用状态。单操作员本地优先部署。
KPI
- 端到端任务完成率
- 在所有子任务中正确完成的编排作业比例；编排器对整个结果负责。
- 工作器扇出与成本
- 每个作业的工作器调用次数及其合并的 Token 成本；如果分解过于草率，编排可能会导致开销激增。
- 关键路径延迟
- 最长依赖链的实际耗时，而不是工作器耗时的总和——这限制了响应速度。
- 子任务错误率
- 单个工作器失败或返回不可用结果的频率，这会触发重试和恢复。
已观测到的失效模式
- 糟糕的分解：编排器错误地拆分了任务，导致即使工作器正确执行，最终仍产生错误的结果。
- 编排器与工作器之间丢失上下文，导致部分结果不一致或相互矛盾。
- 由于在没有预算限制的情况下生成过多工作器或进行深层嵌套，导致成本激增。
- 单点故障：如果编排器判断失误，尽管工作器运行正常，整个作业仍会失败。
经验教训
- 投入精力优化分解逻辑——大多数失败都可以追溯到工作是如何拆分的，而不是工作器本身的问题。
- 显式地向工作器传递其所需的最小上下文，以避免偏差和矛盾。
- 设置预算和深度上限；无限制的编排是智能体成本失控的根源。
- 使编排器的计划具有可检查性，以便将失败追溯到特定的子任务。
常见问题
- 这与并行化有什么不同？
- 并行化使用固定的、预定义的拆分方式。而编排器-工作者（Orchestrator-workers）模式在运行时动态决定子任务，因此它能够处理其形态随输入而变化的任务。
- 这是一个多智能体系统吗？
- 是的——这是一个常见的多智能体模式。只有当任务确实能从动态、可拆分的子任务中获益时，才应使用它。
- 我该如何防止它失控运行？
- 设置预算、步骤限制和终止条件，并增加可观测性，以便您能够查看并限制编排器的规划。