orchestrate

多 Agent 编排

使用独立 Agent 增加有效产能，同时确保结果连贯一致。按可独立推进的问题、产物和资源进行拆分。协调者负责整合，并最终确认任务已完成。

用户的指示优先于此技能的指南。委派、工具和外部操作仍须遵循当前宿主的指示和授权。此技能不会赋予执行者超出协调者权限的权限。

派发前检查能力

检查可用工具及其当前架构。不同宿主在 Agent 生命周期、继承的上下文、文件系统共享、工作树隔离、异步结果和权限方面各不相同。应主动了解这些特性，不要根据产品名称推断，也不要照搬过时的参数。

在允许的情况下，使用宿主支持的委派工具。外部 CLI 审查者仍会消耗资源，且仍须遵循委派和权限规则；它不能成为绕过限制的途径。如果没有合适的委派接口，请直接执行，或为获授权的外部执行者准备任务。任务队列本身不会启动 Agent。

根据依赖关系选择模式

工作模式	协调方式
独立的研究问题	并行调查，基于证据进行综合
接口稳定、职责互不重叠的功能	并行构建，指定整合负责人
在多个模块中重复进行同一项更改	使用范围明确的自动化转换或分工执行者，并进行合并验证
相互依赖的编辑或共享的可变状态	为依赖项指定一位负责人，围绕该工作并行推进
影响重大的审查	由具备不同风险视角的独立只读审查者执行
小型且紧密耦合的更改	直接执行

Agent 数量应根据明确且有价值的工作方向、可用产能和整合成本来确定。只有在能提供独特证据或缩短独立工作耗时时，增加 Agent 才有价值。不要把过去团队的规模当作默认标准。检查关键路径：如果某个分支正等待一个共享接口，加快该分支可能无法提高整体吞吐量。

明确所有权与集成方式

启动构建者之前，检查仓库状态和现有工作树。梳理共享资源和文件：生成的工件、架构、锁文件、数据库测试数据、端口、构建输出和包缓存，都可能在原本互不相关的模块之间发生冲突。

根据工作内容选择隔离方式：

隔离方式	适用场景	所需协调
共享工作树，路径互不重叠	小型独立变更，且所有权明确	对有争用的文件和 Git 索引操作指定唯一所有者
独立工作树	工作人员需要独立分支或构建状态	明确基准版本、分支/路径、合并顺序和集成负责人
只读版本	审查或研究	固定版本/差异，以及允许生成的临时输出

工作树可以隔离已跟踪文件和索引，但不会自动隔离端口、数据库或外部服务。遵循项目的工作树布局。绝不要为了消除冲突而覆盖他人或协作者的修改。

对于共享工作树，让工作人员报告补丁和检查结果，由一名协调者暂存并提交范围明确的变更，除非另有明确约定的所有权方案。并行编辑时，避免大范围暂存和全仓库自动修复。接受提交前检查钩子的副作用。遇到锁冲突时，查明实际持有者；进程列表无法确定时，不能据此认定可以安全删除锁。查阅 git 以了解恢复方法。

分派工作前，明确如何将部分进展整合为整体进展。指出每位使用者需要的工件，以及工件何时才算就绪。不要让已完成的分支无人负责检查和合并。

编写能传递必要上下文的任务简报

向每位工作人员提供原始相关请求和范围明确的任务。包含那些重新查找代价高昂或其检出内容中没有的信息，尤其是用户的更正和尚未记录的决策。涉及位置时，使用绝对路径和精确版本。

简报要素	目的
目标与范围	所需结果、负责的范围和排除项
当前依据	相关代码、版本、接口和已验证的前提
依赖项	已就绪的内容、承诺提供的内容及其负责人
权限	允许进行的修改、提交权限和外部操作
验证	对此项贡献的检查和验收条件
返回内容	已变更的工件或发现、依据、局限及有理有据的偏离

允许工作人员质疑前提并报告必要的范围扩展。简报应限定任务，而不是强迫采用已知有问题的机制。强制模板应保持简短；详细示例见 references/dispatch-briefs.md。

进行独立的首次审查时，提供原始请求和未经引导的变更内容，不要暗示实施者期望的结论。进行后续验证时，提供发现的问题和修复声明，以便审查者确认问题是否已解决。这是两种不同的审查任务。

监督工作，而不成为瓶颈

同时启动彼此独立的工作，并继续处理有价值的本地工作。依赖项就绪后，立即收集结果，而不是等待任意一轮工作结束。只有在确有共同检查点，或需要先校准方法再扩大派发范围时，才分轮进行。

监控结果、工具状态、产物进度和报告的问题。仅凭沉默不能证明 Agent 陷入停滞。进度停止时，先提出有助于辨别情况的问题，或检查相关资源，再考虑打断。及时响应用户的引导；轮询和等待必须遵守宿主环境的实际限制。

需求变更时，通知受影响的执行者并更新共享约定。保留已完成且仍有效的工作。在安全节点停止过时操作，只取消本次运行所拥有的进程或监视器。报告已放弃的工作，以及已经产生的任何副作用。

监视器需要具备可检查的完成条件、故障检测方式、过期或升级条件，以及在执行任何获准操作前检查状态是否过时。先用已知状态测试其信号。详细的监视器指南见 references/dispatch-briefs.md。

收集、整合并验证

阅读结果时，也要查看偏差和局限。检查实际差异并打开影响重大的源文件；执行者的摘要只是陈述，不是证据。未完成的贡献可能包含可用成果，但是否接纳取决于根据任务进行检查，而非其长度或执行者的信心。

在稳定的检查点进行整合，然后运行能够覆盖组合行为的检查。执行者各自的测试可能无法发现接口之间不兼容的假设。确认累计的差异仍能实现用户期望的结果，并遵守明确的约束。

对于要求独立验证的非简单改动，完成前应取得验证结果。实现者可以报告其检查结果，但不能认证独立的 PASS。额外的审查者应覆盖不同风险，或提供刻意独立的评估；发现数量不是目标。

将审查证据关联到某个修订版本或已记录的工作树快照及其环境。使用以下结论：

结论	含义
PASS	声明的审查范围已完成，且没有尚未解决的阻塞性发现
FAIL	有依据的缺陷违反了请求的结果或适用的约定
INCOMPLETE	审查或必需检查未完成；列出未覆盖的范围

被中断的审查不能给出完整的 PASS。意见一致不能确定严重程度；影响和可利用性才是依据。通过代码、规范或复现程序裁定分歧。复现出基线故障可以区分回归与既有行为，但这两种标签都不能替代对变更路径的分析。

修改后，重新评估哪些已审查的主张不再成立，并重新验证受影响的行为及相关集成。运行时代码发生变化时，不要沿用 PASS。纯文档改动无需触发无关的运行时检查，除非项目策略有此要求。

如实说明最终状态

报告已整合的结果、实际执行的检查及其对应修订版本、尚未解决的限制，以及剩余产物的位置。如果外部关卡不可用，应完成已获授权的独立工作，并明确指出具体阻碍和所需操作。遵守宿主环境有关记录任务／目标状态的规则；未经验证的必需工作，不得声称已完成。

通过配置的项目记忆记录持久性协调故障：发生争用的资源、故障机制、修复方法及适用条件。不要将临时日志和执行者之间的闲谈写入永久指南。

证据与局限

已于 2026-09-04 审阅。Anthropic 的多 Agent 研究案例支持明确界定范围并并行开展相互独立的调查，同时提醒注意协调成本和令牌开销。研究结果并未证明编码 Agent 的最佳数量。

Astra 指南建议明确说明委派预期。应在实际宿主环境的契约范围内应用这一建议；API 功能并不能证明某个特定 CLI 提供了这些功能。

反模式

反模式	更好的做法
在找出独立工作之前就选定团队规模	明确有用的工作分工及其集成路径
认为处理不同文件就意味着彼此隔离	检查共享的运行时资源和生成的输出
把外部审查者当作绕过策略限制的手段	遵守相同的权限和授权边界
强迫不完整的审查给出非此即彼的结论	报告 INCOMPLETE，并说明缺少的覆盖范围
根据发现的问题数量投票	核实其机制和影响
让所有共享工作树的工作者同时提交	指定索引和提交操作的负责人
随时间推移自动减少审查	根据当前风险和变更证据匹配检查

参考资料

编写工作者、研究、验证或监视者的指令时，请阅读 references/dispatch-briefs.md。

此技能不是什么

• 忽略宿主环境的委派规则或用户所有权的许可。
• 固定流程、Agent 配额或使用多个 Agent 的要求。
• 综合验证或协调者判断的替代品。