orchestrator

编排：子 Agent、Agent 团队与并行执行

这些规则适用于所有并行化决策。每项任务都必须遵循。

不适用于单操作请求、简单文件编辑或仅限顺序执行的工作流。

调度

$ARGUMENTS	操作
(empty)	显示空白／帮助画廊，然后对当前请求应用分类门槛和分解门槛
pattern <A-F>	显示 references/patterns.md 中指定的模式
tier	显示层级选择表和模型指导
recovery	显示记账规则和恢复阶梯

规范术语

规范术语	含义
subagent	通过 Task 工具启动、在会话中并行运行的 Agent
wave	在一条消息中调度的一批并行子 Agent
team	通过 TeamCreate 启动、由负责人协调的队友群组
teammate	Agent 团队中拥有指定文件所有权的成员
lead	团队中的编排 Agent；绝不直接实现任务
dispatch	发送一个或多个子 Agent／队友并行执行任务
gate	必须通过才能继续的强制检查点
accounting rule	调度数量 = 已解决数量；不得悄然丢弃任何 Agent

门槛逻辑

在加载完整编排准则前，先使用此门槛：

1. 如果请求恰好只有一个操作，请在单个会话中完成，不要调用此技能。
2. 如果工作包含多个步骤，但都编辑同一个文件或依赖严格的顺序，则不要强行并行；明确保留顺序约束。
3. 如果无法明确分解，请先进行探索，再重新进入门槛流程，不要猜测任务拓扑。
4. 如果另一个正在使用的技能有更严格的阶段顺序或调度前置条件，请保留该技能的控制流程，只在其允许的范围内并行。
5. 如果用户明确要求特定的执行方式，除非与硬性安全约束冲突，否则应遵从。

操作员约定

空白／帮助

1. 显示公开入口：空白／帮助、pattern <A-F>、tier 和 recovery。
2. 在应用分解门槛前，先运行分类门槛。
3. 说明此技能不应接管的临界情况：单操作任务、同一文件的顺序任务，以及有更严格顺序要求的阶段门控技能。
4. 指向模式选择、进度记账、运行时限制和路由错误示例所需的具体参考资料，而不是粘贴整套准则。

pattern <A-F>

1. 加载 references/patterns.md。
2. 介绍指定模式、适用场景、不适用场景及其恢复影响。
3. 除非指定模式明显更适合当前请求，否则将模式 E 作为默认模式。

tier

1. 在讨论机制限制或特定环境的工具约束前，先加载 references/runtime-capability-boundaries.md。
2. 显示层级选择表，并解释为何应采用适用层级中最高的层级。
3. 指出仍应采用较低层级的临界情况，例如恰好只有一个操作，或属于单一领域且无需协调的任务。

recovery

1. 加载 references/progress-accounting.md。
2. 介绍记账规则、恢复阶梯和报告约定。
3. 说明在进入下一波之前，如何处理缺失的 Agent、重新启动的 Agent 和明确跳过的任务。

0.5 不确定性关卡（前置与重新进入）

在分解关卡之前，以及重新进入时，再次应用 instructions/global.md 中的深度路由：

1. 列出仍会妨碍安全分解、任务分派或受影响子任务的假设。
2. 优先探索可通过代码库解决的事项。
3. 如果前置环节仍存在对用户至关重要的不确定性，请在分派子 Agent 或队友之前调用 /grill-me。
4. 如果中途出现对子任务至关重要的分歧，请暂停受影响的工作流，并调用限定范围的 /grill-me（参见 global.md 中的限定范围 grill 契约）。不要重新讨论已确定的计划部分。
5. 不要并行开展依赖未解决用户选择的工作流。不要让子 Agent 在关键分歧上自行猜测。

重新进入的触发条件：

• 子 Agent 或队友返回 blocked-user-pivotal（参见 references/uncertainty-handoff.md）
• 工作波次的核算列出了尚未解决的关键阻碍
• 负责人在下一次分派前发现中途出现分歧

**重新进入后的操作：**暂停受影响的工作流 → 调用限定范围的 /grill-me → 更新提示词 → 恢复或重新分派。

**快速路径：**请求依据充分，且没有对用户至关重要的阻碍 → 继续执行 §0。

0. 分解关卡（任何工作开始前的强制步骤）

在执行任何涉及工具辅助工作的请求之前：

1. 分解：列出所需操作（读取文件、编辑、搜索、运行命令、分析）。
2. 分类：哪些操作彼此独立（没有数据依赖）？哪些存在依赖关系？
3. 最大化并行度：主动进一步拆分操作，找出所有并行机会。每项独立操作都应分配给一个单独的子 Agent。思考：能否将任何操作拆成两项？
4. 冲突检查：两个独立操作若要编辑同一文件，则按顺序执行；其余操作仍保持并行。
5. 分派：默认使用模式 E——通过 TeamCreate，为每位队友创建嵌套的子 Agent 工作波次。启动前预先批准权限。仅当任务属于单一领域、无需协调且上下文没有压力时，才使用单纯的子 Agent 工作波次。只有在确实只有 1 项操作时，才使用单会话。
6. 跟踪：对于编排式工作，在分派前创建 TaskCreate 条目（参见第 7 节）。

快速路径：单项操作的请求直接进入单会话。

先探索路径：若没有探索就无法分解，则先启动并行探索团队（模式 F，第 1 波），然后重新进入此关卡。

转换启发式：如果子 Agent 工作波次遇到上下文限制，或 Agent 需要共享发现，则升级为模式 E（团队 + 嵌套工作波次）。

用户覆盖指示：用户明确要求采用特定执行方式时，以用户要求为准。

常见借口（均无效）

• “我自己做更快”——并行子 Agent 能在最慢的单项任务所需时间内完成 N 项任务。
• “任务太简单”——只要有 2 项或更多相互独立的操作，就应并行处理。
• “我先做这一件事”——必须先分解，再开展任何工作。

模式约束

• 计划模式：仅限只读子 Agent。不得使用团队或具备写入能力的 Agent。
• 实施模式：可使用所有层级。默认采用适用的最高层级。
• 委派模式：负责人仅负责编排。所有实施工作均由队友或子 Agent 完成。

技能集成

启用 superpowers 技能时，关卡应在技能的执行结构内运行：

• 阶段关卡型技能：在每个阶段内并行处理。不要跨阶段边界并行。
• 逐任务审查循环型技能：优先遵循技能的顺序结构。在每项任务内并行探索，不要跨任务并行。
• 分派前置条件型技能：技能中的“不要在以下情况使用”条件仍然有效。关卡不会覆盖技能层级的安全防护。

具体的易错案例请参见 references/misroute-examples.md，例如编辑同一文件时应按顺序执行、阶段关卡型审查循环，以及单项操作请求。

---

1. 层级选择（必须遵守——优先选择符合条件的最高层级）

层级	机制	适用场景	模型
Team + 嵌套波次（Pattern E）	TeamCreate + 每位队友启动子 Agent 波次——最多约 50 个 Agent	2 个或更多独立工作流——默认选择	opus（默认）/ Copilot：Opus 4.6 最大思考；仅对极其简单的 /fleet 工作使用 Sonnet 4.6 最大思考
子 Agent 波次	Task 工具，并行调用	同一领域内有 2 个或更多独立操作、无需协调，且不存在同一文件的线性工作链	opus（默认）/ Copilot：Opus 4.6 最大思考；仅对极其简单的 /fleet 工作使用 Sonnet 4.6 最大思考
单会话	直接执行	恰好 1 项操作，或任何必须保持线性的同一文件顺序工作链	不适用

选择符合条件的最高层级。切勿为了降低成本而选择较低层级。仅有 2 项操作还不够；这些操作必须彼此独立。

扩展策略

情况	建议方式
单一领域内的小型多操作任务	只有在存在 2 个或更多真正独立的操作且无需协调时，才使用子 Agent 波次。
跨领域实现	使用 Pattern E，划分明确的负责范围；仅在详细工作适合委派时使用嵌套波次。
探索 → 实现 → 验证工作	使用多波次流程，并在进入下一波之前完成当前波次的核算。
同一文件或顺序紧密的工作	明确保持顺序执行，不要为了并行而人为制造并行。

---

2. 子 Agent 最佳实践

启动

• 一条回复，多次 Task 调用。 必须在同一条消息中派发所有独立的子 Agent。
• 对于无需立即获取结果的子 Agent，使用 run_in_background: true。
• N 项独立操作 = N 个并行子 Agent。只有当它们涉及相同的文件或目录范围时才进行合并。

提示词调整

• 为每个子 Agent 提供详细且独立完整的提示词，注明确切的文件路径、预期输出格式和领域背景。
• 不要依赖子 Agent 继承对话历史——它无法继承。
• 如果子任务遇到父级未预先解决、且会影响用户决策的不确定性，应根据 references/uncertainty-handoff.md 返回 blocked-user-pivotal，而不是猜测。

模型选择

• 默认策略：对每个子 Agent、队友和波次均使用 opus。
• GitHub Copilot CLI 覆盖规则：所有计划都应根据 /orchestrator 针对 /fleet 进行优化。对于 /fleet，所有非简单的子 Agent、队友、波次和 /fleet 成员均使用最大思考模式的 Claude Opus 4.6。
• 仅对极其简单的 /fleet 子 Agent 使用最大思考模式的 Claude Sonnet 4.6。如有任何不确定性，升级至 Opus。
• 两项策略同时存在时，采用当前运行环境对应的环境特定覆盖规则。

上下文管理

• 将详细耗时的操作（测试套件、日志解析、文档获取）委派给子 Agent。
• 对于多阶段工作，使用子 Agent 恢复（Agent ID），而不是重新启动。
• 波次完成后，先按照第 4 节的核算规则进行核算，再进行综合或派发下一波。

---

3. Agent 团队最佳实践

• 根据工作量扩展队友数量——不设人为上限。为实现最大并行度，按需使用任意数量的队友（包括嵌套子 Agent 在内，总计最多约 50 个 Agent）。Token 预算不构成限制。
• 在生成队友之前，预先批准常见权限，以减少阻碍。
• 为每位队友分配不同的领域和互不重叠的文件所有权。
• 根据领域需要，为每位队友分配任意数量的任务——不设人为上限。
• 在生成提示词中提供所有特定于任务的上下文：文件路径、架构决策、验收标准。队友不会继承对话历史。
• 使用委派模式，避免负责人亲自实施工作。
• 任务认领使用文件锁定——多个队友同时认领时不会发生竞争条件。
• 绝不要将重叠的文件所有权分配给两位队友。
• 在所有队友任务都得到处理之前，负责人不得开始汇总（第 4 节）。

---

4. 质量关卡与故障恢复

任务核对规则（每次并行派发后都必须执行）

派发 N 个 Agent 后，必须先核对全部 N 个 Agent，再继续：

1. 收集：等待全部 N 个 Agent 返回。使用 TaskOutput 且设置 block=false 进行轮询，以检测超时。
2. 统计：对比已收到的结果和已派发的数量。缺失的结果 = 尚未解决。
3. 解决所有未成功的情况，使用恢复阶梯（见 references/patterns.md）。
4. 关卡：在每个 Agent 都取得 SUCCESS 或明确的 SKIP 之前，不得继续。
5. 汇报：继续之前，通过 TaskUpdate 总结所有 Agent 的结果。

自动化执行钩子

• TeammateIdle 钩子：阻止队友在工作得到验证之前进入空闲状态。
• TaskCompleted 钩子：阻止任务在测试通过之前关闭。
• 两者都使用退出代码 2 发送反馈，并使队友／任务保持活动状态。

计划审批工作流

• 对于高风险变更，在生成提示词中加入“Require plan approval before making changes”。
• 队友进入只读计划模式，准备就绪后向负责人发送 plan_approval_request。
• 负责人批准或拒绝并提供反馈。如果被拒绝，队友需修改计划。
• 在生成提示词中明确审批标准：“only approve plans that include test coverage”。

---

5. 编排模式

模式	名称	适用场景	详情
A	并行子 Agent 波次	一个会话中有 2 个或更多独立子任务	见 references/patterns.md
B	具有文件所有权的 Agent 团队	跨领域功能、大型重构	见 references/patterns.md
C	竞争性假设	调试、架构决策	见 references/patterns.md
D	先计划后协作	需要人工审批的大型任务	见 references/patterns.md
E	使用子 Agent 的队友团队（默认）	2 个或更多独立工作流——默认使用	见 references/patterns.md
F	多波次流水线	探索 → 实施 → 验证阶段	见 references/patterns.md

---

6. 限制

• 队友不支持会话恢复（/resume 和 /rewind 无法恢复队友）。
• 不支持嵌套团队（队友可以使用子 Agent，但不能生成团队）。
• 每个会话只能有一个团队。开始新团队之前，请先清理现有团队。
• 负责人固定——无法转移领导权。
• 所有队友在生成时都会继承负责人的权限模式。
• 子 Agent 恢复可能无法解决所有故障模式（应重新生成，而不是恢复）。
• 没有内置的超时检测——编排者必须手动使用 TaskOutput 轮询。
• 恢复时重新生成的 Agent 计入会话的 Agent 预算。
• 显示模式：默认使用进程内模式（按 Shift+Down 循环切换）；分屏窗格需要 tmux 或 iTerm2。
• 与队友交互：按 Enter 查看会话，按 Escape 中断，按 Ctrl+T 查看任务列表。

渐进式披露

• 默认情况下，不要加载所有编排细节。
• 决定此技能是否应负责处理任务时，阅读 references/classification-gate.md。
• 仅当用户要求特定模式，或拓扑选择是主要问题时，阅读 references/patterns.md。
• 讨论报告、核算或恢复行为时，阅读 references/progress-accounting.md。
• 当子 Agent 遇到对用户决策至关重要的不确定性，或返回 blocked-user-pivotal 时，阅读 references/uncertainty-handoff.md。
• 当工具/运行时限制或特定环境约束影响拓扑时，阅读 references/runtime-capability-boundaries.md。
• 当请求接近触发边界时，阅读 references/misroute-examples.md。

---

关键规则

1. 绝不能按顺序分派相互独立的操作——所有相互独立的 Task 调用都必须出现在同一条响应中。
2. 在执行任何通过工具进行的工作前，始终运行分解关卡；绝不允许跳过。
3. 当满足更高层级的标准时，绝不能降低并行度或层级；遵循文档规定的特定环境模型策略。
4. 绝不能悄然忽略失败的子 Agent——分派 N 个，就必须核算 N 个；每一轮之后都应用核算规则。
5. 在第 N 轮中仍有未解决的 Agent 时，绝不能进入第 N+1 轮；先解决第 N 轮中的所有 Agent。
6. 在分派子 Agent 波次或 Agent 团队前，始终创建 TaskCreate 条目——禁止无记录的编排。
7. 绝不能将重叠的文件所有权分配给两名队友——重叠编辑会导致工作丢失。
8. 始终在子 Agent 和队友的提示词中包含完整上下文——他们不会继承对话历史。

---

参考文件索引

文件	内容	阅读时机
references/classification-gate.md	编排开始前的调用关卡、近似命中规则和优先询问逻辑	决定是否调用此技能时
references/patterns.md	模式 A-F 的详细说明、ASCII 图示、关键规则和恢复阶梯	设计并行执行或选择模式时
references/progress-accounting.md	进度跟踪约定、核算规则详情，以及恢复/报告预期	解释恢复、核算或报告时
references/uncertainty-handoff.md	子 Agent 的 blocked-user-pivotal 返回约定，以及父级限定范围内的追问义务	波次进行中遇到关键阻碍或重新进入时
references/runtime-capability-boundaries.md	层级和运行时边界指南，包括工具或环境限制约束拓扑的情况	选择层级或讨论环境限制时
references/misroute-examples.md	具体的误触发和近似命中场景	检查边界情况的请求时

---

7. 进度可见性（编排工作必需）

所有编排工作都必须通过 TaskCreate/TaskUpdate 生成结构化进度指示。

层级	要求	粒度
子 Agent 波次	必须	每个子 Agent 一个任务，并在分派前创建
Agent 团队	必须	设置期间为每项队友任务创建一个任务
单会话（3+ 个步骤）	建议	每个逻辑步骤一个任务

规则

• 在执行开始前创建任务，不得事后补建。
• 每个任务都必须有描述性的 activeForm，使用现在进行时，并指出具体操作和目标。
• 开始前将任务更新为 in_progress，完成后立即更新为 completed。
• 每轮完成并核算后，在分派下一轮之前总结所有 Agent 的结果。

外部执行环境委派（Grok Build）

当宏观图将节点分配给 Grok Build 时，父级仍负责工作波次、关卡和综合。通过 /grok-delegate 委派执行——仅使用原生 grok -p、-r、工作树和领导者（不使用自定义封装）。预检：在分派任务群之前，先调用 /grok-delegate 预检（参见 grok-delegate 技能）。父级将并行 Grok 节点作为独立的 bash 子进程分派（模式 A/E）。父级关卡未通过后，使用 -r <sessionId> 调整进行中的分支。

Tier-T 简单任务外包： 分解期间，将每个叶节点分类为 Tier-T。若快速预检结果为 ok 且 grok-auth-expiry: ok，则默认将符合条件的有界叶节点（≤3 次读取，或 ≤1 个文件且 ≤80 LOC）交由 /grok-delegate trivial 以单节点 grok -p 执行。父级负责综合。不适用于多节点图、写入重叠、范围宽泛、破坏性/生产环境/git 推送任务、读取机密的任务，或尚未解决的用户关键/子任务关键不确定性（先通过限定范围的 /grill-me 解决）。如果首次原生 Tier-T 分派失败，则对当前父级工作项停止使用 Tier-T，并在本地继续。

范围边界

适用于： 分解、编排拓扑、模式选择、进度核算、恢复/报告，以及多 Agent 执行规则。

不适用于： 单步操作请求、应保持串行的同一文件顺序工作，或覆盖约束更严格的阶段关卡技能契约。