orchestrator

用途

Orchestrator 把主会话变成永不阻塞的调度器，核心规则是「绝不阻塞主线程」：一个等待任务完成的回合即视为失败。该模式持续生效，直到用户说「stop orchestrating」。

主要能力

• 任务拆分与派发：把用户消息拆成独立任务，每个任务以 Agent 调用发送到后台子代理，多个新代理在同一条消息中并行发起。
• 不等待、不轮询：不等待代理、不轮询、不 sleep；代理完成时由运行框架发出 <task-notification>，该通知触发下一回合。派发后立即结束回合。
• 长命令后台化：任何可能超过 10 秒的 shell 命令（测试、构建、安装、开发服务器）都以 run_in_background: true 运行。
• 复用与续接：同一主题延续给运行中的代理（用 SendMessage 按其名称发送，保留其上下文）；新主题才启动新代理。
• 账本（ledger）：在 .claude/orchestrator.md（项目若有 .context/ 则用 .context/orchestrator.md；无项目时用 ~/.claude/orchestrator.md）中为每个代理记一行，记录状态、名称、模型、任务与开始时间，例如：

  - [running] audit-auth (opus) — find every route that skips the session check — started 14:02
  - [done]    fix-billing (opus) — PR #812 open, tests pass — 14:20
  - [failed]  repro-upload (opus) — no repro on dev; needs a prod log — 14:31
  

  账本可在上下文压缩后存活，用户说「status」时据此回答。
• 任务简报（brief）：子代理看不到聊天内容，brief 是它唯一的信息来源，需包含：一句话目标及原因；已有事实（文件路径、错误文本、用户原话）；代理独占的文件，并声明「你不是独自工作，其他代理也在编辑此仓库，保留他们的改动，只碰你拥有的文件」；禁止动作（除非用户明确要求，否则不 commit、push、merge、PR、部署、发消息或删除数据）；完成标准（必须运行的检查与需返回的证据）；报告结构（结果优先、证据其次、开放问题最后，300 词以内）；写作规范。每个代理给一个 kebab-case 短名以便后续 SendMessage。
• 模型选择：默认 opus，用于困难、开放或模糊的工作（设计、调试、多文件改动、审查等需判断力的任务）；sonnet 用于规格紧凑的小任务（单文件或单函数、已知修复、重命名、查找、格式变更或明确的通过/失败检查）。若能用一句话写出确切的完成检查且错误答案易发现，用 sonnet，否则用 opus。sonnet 未达标的结果改由 opus 重做。代理类型：Explore 用于只读搜索，Plan 用于设计，general-purpose 用于会写入的工作；写入同一文件的两个代理需设 isolation: "worktree" 或改为串行。

使用方式

• 每回合：读用户消息、拆分为独立任务、决定新代理或续接、并行派发所有新代理、更新账本，然后用三行以内回复说明启动了哪些工作、在哪个名称下、用户接下来可做什么，随即停止。
• 收到 <task-notification>：阅读结果并按 brief 核对，若不达标则跟进或启动更强的代理；更新账本；用几行报告结果（结果优先）；若结果引出下一步，在同一回合派发。代理的结果在通知到达前不得提前写出；用户问及运行中的代理，应说明其仍在运行及正在做什么。
• 用户无需工作的提问：自己立即回答，不为已知答案启动代理。
• 控制指令：「stop <name>」用 TaskStop 停止该代理并在账本标记 [stopped]；「stop all」停止所有运行中的代理；「redirect <name> to …」用 SendMessage 发送新指令。
• 向用户提问：把所需决策收拢成一批简短的提问，一次问完，等待期间保持其他代理运行，不为一个待决问题停止全部工作。

适用场景

需要并行推进多项开发任务、处理长耗时命令、组织多代理协作完成多文件改动与审查的场景。

限制

资料中未说明支持的工具、模型版本、平台与其他限制；模型名称（如 Opus 5.5、Sonnet 5）与 Workflow 工具等属于资料给出的用法约定，具体可得性暂未提供。