delegation-mode

委派模式

委派模式以文件系统作为委派工作的事实来源。 聊天记录适合用于更新进度，但绝不是唯一的交接方式。协调者会创建一份可执行计划，每个工作者都会将自己的结果直接写入 .agents/plans/，后续会话则通过重新运行同一计划并跳过已完成的任务 ID 来继续工作。可复用的运行器会验证结果文件，而不只是工作者的回复，然后才确认任务完成。

当工作规模较大、包含多个步骤、可并行处理、可能超出单个上下文窗口，或值得为下一个 Agent 留下一份持久计划时，请使用此模式。 对于没有持久输出的小型交互式答复，不要使用此模式。

事实来源

每次运行使用一个计划脚本：

.agents/plans/
├── YYYY-MM-DD-<slug>.js              # executable dispatcher and resume state
├── YYYY-MM-DD-<slug>-<task-id>.md    # one durable result per task
└── YYYY-MM-DD-<slug>-FINAL.md        # optional aggregation plan

将 scripts/delegation-plan.template.js 复制到第一个路径，并填写项目背景和任务定义。脚本必须包含：

• 稳定的运行日期和标识；
• 每个任务的稳定且唯一的 ID；
• 每个任务的精确输出路径；
• MODE = "sequential" 或 MODE = "parallel"；
• 初始为空、恢复执行时更新的 DONE_IDS；
• 由 FINAL_DONE 控制的可选最终汇总任务。

将计划脚本保存在 .agents/plans/ 中，以便其他会话无需根据聊天记录重建派发逻辑，也能执行同一个文件。运行脚本前，请填写所有占位符。计划的 DATE、SLUG、任务 ID 和输出路径都是其身份标识的一部分；范围发生变化时，请创建新的标识。

可复用模板会加载 scripts/plan-validation-core.js，它是计划身份检查、安全输出路径、DONE_IDS、Markdown frontmatter、完成标记和持久文件验证的唯一来源。加载器会检查可发布的源代码树和已安装的技能树，确保复制后的计划在安装后仍可使用。

工作者约定

每位受委派的工作者都必须：

1. 阅读完整的任务提示词和相关源文件。

2. 严守分配的范围；除非计划明确指定其负责实现，否则不要编辑应用源代码。

3. 将完整结果直接写入提示词指定的精确输出路径。

4. 使用包含 kind: plan、有意义的 id 和真实 status 的 Markdown 计划 frontmatter。已完成的结果使用 status: done；受阻或未完成的结果不得声称已完成。

5. 包含可执行的发现、决策、阻碍因素或已交付的更改。

6. 在结果文件中将准确的 FILE_WRITTEN: 行作为最后一个非空行，并在回复中也包含该行。这样一来，如果派发器在工作者写入文件后、返回回复前被终止，结果仍可审计。

7. 在回复末尾准确写入：

    FILE_WRITTEN: <exact-output-path>
   

   只有当文件已存在且通过结果文件检查后，回复标记才有效。回复标记是有用的存活信号；文件标记才是持久的完成信号。

对于实现任务，结果计划应记录更改内容、受影响的文件、执行的验证、剩余风险和后续操作。对于分析任务，应记录范围、证据、结论和建议的工作。如果工作者明确记录了其检查范围且未发现问题，空结果也是有效的。

顺序与并行分派

默认采用顺序分派：

const MODE = "sequential";

运行器会等待每个待处理任务完成后，再分派下一个任务。以下情况适合使用顺序分派：

• 任务可能争用共享资源；
• 一个任务依赖另一个任务；
• 多个工作者可能编辑重叠的文件；
• 仓库或工具预算有限；
• 与实际耗时相比，可预测的故障边界更有价值。

只有在所有待处理任务彼此独立时，才使用并行分派：

const MODE = "parallel";

并行任务必须只读应用源代码、写入不同的输出文件，且不能依赖其他任务的结果。运行器使用 Promise.allSettled，因此一个工作者失败不会导致其他工作者的结果被隐藏。只有每个任务都有经过验证的结果文件后，才能进行汇总。如果任务声明了 dependsOn，则必须等到其依赖的任务 ID 确认后才能运行；只有依赖图允许独立分派时，才适合采用并行模式。

每个可写入文件的委派任务都必须使用：

config: { $kind: "general" }

如果任务需要通过写入文件才能完成，请勿使用仅负责探索的工作者。只有在组合技能明确定义了兼容的文件写入约定时，才使用专门的工作者类型。

中断后恢复

被终止的 Code Execution 运行不会使工作者已写入的文件失效。应从计划恢复，而不是从对话记录恢复：

1. 检查计划的输出文件。
2. 确认每个候选结果均已完成、计划 frontmatter 如实无误，并且其精确的 FILE_WRITTEN: 标记位于最后一个非空行；如果工作者响应可用，也应将其作为补充确认。
3. 只将已确认的任务 ID 放入 DONE_IDS。运行器会拒绝未知、重复或过期的 ID，并重新验证每个列出的输出文件。
4. 重新运行完整的 .js 计划。
5. 运行器会跳过 DONE_IDS，只分派缺失或未解决的任务。
6. 只有在确认所有任务 ID 后，才能运行最终汇总。

不要根据工作者未作响应、部分文件或旧聊天消息来推断任务已完成。如果结果文件存在，但缺少完成标记或必需内容，请勿将该 ID 放入 DONE_IDS，并重新运行该任务。如果审查范围发生变化，请创建新的 slug，而不是复用旧结果。

DONE_IDS 特意要求显式指定，而不是通过脚本内的文件系统扫描来推断。这样可以使恢复决策可审计，并避免将截断或过期的文件误判为已完成。

与大型技能组合

委派模式是一个执行层，而不是审查方法。大型技能可以在使用此约定的同时定义自己的任务列表和结果架构。例如，code-review-axes-and-quality：

• 定义十个独立的审查维度；
• 每个维度使用一个稳定的任务 ID 和一个 .agents/plans/ 文件；
• 支持顺序或并行分派；
• 仅在全部十个维度确认后，才运行最终去重汇总。

对于复杂任务，应将工作拆分为具有明确依赖关系的任务，在必要时选择顺序模式，并让最终任务读取先前的计划文件，而不是依赖聊天上下文。

失败与终止状态

结果文件是持久记录。请在其 frontmatter 或正文中使用以下含义：

状态	含义
pending	尚未分派任务。
running	工作正在进行；有用时记录部分进展。
blocked	缺少特定决策、输入或环境条件，导致无法安全推进。
done	任务输出已完成并经过验证。

切勿仅因为任务大部分已完成就将其标记为 done。如果任何任务抛出异常或缺少其标记，计划脚本应报告未解决的任务，并跳过最终汇总。

最终验证

在报告委派运行已完成之前：

1. 确认所有预期的任务结果都已存在、位于 .agents/plans/ 中，并符合所需的架构。
2. 确认 DONE_IDS 中包含每个任务 ID，或该任务已在当前运行中完成。
3. 如果计划定义了最终汇总文件，请确认该文件存在，并在将 FINAL_DONE = true 之前重新验证。
4. 检查链接、frontmatter 和 git diff --check。
5. 对实现工作运行相关测试、lint、类型检查或构建。
6. 在最终计划中记录验证结果和剩余风险。

仍有未解决的关键阻碍时，不要声称已获批准。

随附资源

• scripts/delegation-plan.template.js — 通用的可恢复调度器。
• references/delegation-modes.md — 模式选择和恢复检查清单。