orchestrator-mode

编排模式

主线程负责协调；工作线程负责读取、搜索、编辑、运行命令和验证。进入主线程的每个文件、搜索结果和命令输出都会在本次会话中一直保留，因此大量材料留在工作线程的上下文中，协调者则只保留计划、决策和简要报告。

激活方式

• 限域。“使用子 Agent 检查 X 和 Y”会分别派发 X 和 Y。在这些任务之外，主线程照常工作。
• 持续。“编排模式”或“委派所有任务”会涵盖后续所有请求，直到用户以任何方式结束该模式。在主线程中直接要求完成某一件事属于一次性例外；之后模式会恢复。

每次派发都需要投入成本来启动新工作线程，并且只会返回摘要。如果请求太小，不值得承担这些成本，请说明这一点，并提议直接回答。

协调者自行执行的操作

在持续模式下，以及限域模式中指定的任务范围内，协调者只会调用以下工具：

• 工作线程的启动、发送消息、恢复、等待和停止工具；
• 计划或待办事项工具；
• 技能加载，包括读取技能的 SKILL.md 或其指向的参考文件；
• 向用户提问或向用户报告的工具。

其他所有操作都必须派发，包括快速查看一个文件。返回的制品路径应交给下一位需要它的工作线程；协调者根据返回的摘要采取行动，如果摘要不够完整，则带着具体缺口恢复该工作线程。引导使用 shell 或文件工具的环境提示（如“能用 Bash 完成时就用 Bash”）描述的是工作线程的操作方式；请在任务交接时一并传达。如果没有启动工具，请说明这一点，并遵循用户已授权的直接操作备用方案。

选择工作线程

• 定位文件或代码、回答“X 在哪里”，或浏览许多文件：使用只读搜索 Agent。它负责查找代码；审查和审计则交给通用工作线程。
• 修改或运行任何内容（编辑、命令、测试、查询、网络调研）：使用通用工作线程，或名单中负责该领域的专用工作线程，例如 SQL 或 CI。
• 验证其他工作线程的输出：使用不同的工作线程；如果执行环境支持，则使用只读工作线程。
• 分叉（继承本次对话的工作线程）仅用于需要这些对话历史的任务。仍需向其分配任务、指定负责的路径并约定返回内容。

除非用户或调用方技能有要求，否则不设置模型和推理强度。当提供了脚本化的多 Agent 工作流工具且符合其启用条件时，对于跨许多文件执行同一项检查等范围广、内容统一的任务，应使用该工具；如果每个步骤都依赖前一步的结果，则直接派发。

任务规模

• 单项查找：派发一次。
• 对比任务，或涉及两个区域的修改：并行派发两到四次。
• 功能规模的工作：按依赖层级分波次进行。

将同一区域内的多个相关任务交给同一个工作线程；不同区域的任务则并行处理。除非 Harness 说明表明此环境支持更高上限，否则同时运行的工作线程（包括嵌套线程）最多为 4 个。超过上限时，启动请求会失败，而不会排队：等待某个线程完成后再派发。保持派发结构扁平；在将某个子树交给自己的协调者之前，请先阅读嵌套。

工作流

1. 规划。 按领域将请求拆分为多个任务，仅涵盖用户要求的范围。 将范围之外发现的问题报告给用户，不纳入计划。 选择一个绝对路径作为运行目录，确保每位工作者都能写入，并且位于 仓库之外（如果存在会话暂存区，则使用该暂存区）。在计划工具中或 回复中以编号列表的形式记录计划，并报告变更，而不是重复计划。完成条件： 每个任务都已分配任务内容、负责路径和完成标准，并且已指定运行目录。
2. 分派。 在同一条消息中同时启动相互独立的任务，每项任务都附上完整的 交接说明。完成条件：当前批次中的每项任务都已启动。
3. 收集。 等待完成通知或使用等待工具。若工作者有具体遗漏，则让其补上， 不要让其从头重新调查。如果重试时再次以相同方式失败，应诊断问题或更换 方法；某项任务失败三次后，将其报告为受阻。若依赖项正在等待用户答复， 则继续推进其他独立工作。完成条件：批次中的每位工作者都已返回结果，或已 报告受阻。
4. 集成。 小规模编辑由一位写入者负责。若写入者共用同一工作副本或外部 资源，则依次执行。并行代码写入者各自使用一个工作树，并从固定的基准 SHA 创建分支；由一位集成工作者进行合并。创建工作树前，请阅读 并行写入。完成条件： 所有已接受的工作都位于同一棵工作树中；对于并行写入，还需记录每个分支 及其 HEAD SHA。
5. 验证。 每位写入者都要审查自己的差异，并运行覆盖其变更的检查。对于 合并后的并行工作、架构或数据变更，或需要在多个位置分别作出判断的多文件 变更，应另行分派验证者。验证者报告问题后，由写入者修复，再由验证者 复查。在嵌套运行中，验证各子任务之间的衔接，并复用各子任务针对其负责 部分提供的证据。完成条件：每项变更都有证据：验证者通过，或对于小规模 编辑，提供写入者的差异和检查输出。
6. 报告。 先说明结果，再列出返回的产物路径或 ID、验证结果和未解决的 限制，篇幅应足以让用户据此采取行动。如果请求是问题，则答案就是交付 内容。运行目录会随会话结束而消失，因此如果运行过程中产生值得复用的 研究成果，应让工作者将其保存到仓库的 docs/research/（或项目中的 对应目录），并报告该路径。运行中的 PR 合并后，按照 清理 或已安装的 分支清理技能（例如 cleanup-merged-branches），主动询问是否要删除其 工作树和分支。完成条件：请求的工作已完成，或遇到具体阻碍，导致无法 继续执行已获授权的工作。

交接

工作者会看到其调度提示词，以及其运行框架加载的项目说明，例如 CLAUDE.md 或 AGENTS.md。它看不到这段对话、之前的报告或其他工作者读取的文件， 也不能向用户提问。每次交接都要写成一份完整的任务简报：

• 任务：说明完成条件、负责的路径或资源，以及已授予的权限。
• 目标：对于实现和验证任务，说明这项工作的重要性。
• 已有决策：列出目前的决策及其理由，以及应标记为待确认而不是擅自猜测的问题。
• 先前发现：逐字引用返回摘要中的内容。粘贴此任务所需的部分，并说明省略了哪些内容；对于较长的产物，提供其路径以及要阅读的行或章节。隐藏机密和个人数据。
• 运行目录：提供路径；如果目录不存在则创建，并按路径列出要加载的技能。
• 返回约定：列出 status、files_changed、tests_run、verification_evidence、decisions_made、open_questions 和 artifact_path 等字段。

工作者应将较长的发现和命令输出写入运行目录中的产物，并返回一份简短摘要，其中每项产物对应一行索引。在第一次交接之后的每次交接中，都要附上持续更新的决策清单，并精简至与该任务相关的内容。工作者应将要向用户提出的问题放入 open_questions，同时继续开展互不依赖的工作。

组合

使用者技能可以针对其任务进一步收紧这些规则，例如要求将单个工单也隔离在独立工作树中；也可以在明确说明时替换这些规则，例如允许未编写任何改动的集成工作者担任验证者。未作说明时，以本技能为准。