长程/复杂任务编排工作指导。接收复杂任务后,依次完成验收标准确认、计划拆分与自审、项目文件初始化、子任务文档创建、执行者-评估者 subagent 并行迭代、主 agent 巡检协调、聚合与整体评估,直至满足验收标准后交付。
触发条件:任务涉及多个交付阶段、需要协调多个 crew、或估计完成周期超过单次对话的长程任务。
适用领域:深度调研、自媒体内容生产、视频生成、故障排查与根因分析、多维度数据处理、配置新的对内/外 crew、开发新的技能等。
sessions_spawn 交给 subagent;主 agent 不得代做任何子任务。allowAgents 白名单内选择最合适的 crew;如果 allowAgents 为空或没有合适的 crew,则 spawn 给自己。task.md 产出交付物。acceptance.md 判断该子任务是否可以交付。仔细阅读用户描述,提炼:
基于以上分析,起草验收标准清单:
验收标准:
AC-1: <可观测、可验证的具体标准>
AC-2: ...
AC-N: ...
要求:
向用户呈现:
任务目标:<一句话概括>
验收标准:
AC-1: ...
AC-2: ...
...
请确认以上验收标准,或告诉我需要调整的部分。
等待用户明确确认。用户有修改时,更新标准后重新确认。未经确认,不得进入 Phase 3。
将任务拆解为若干子任务。每个子任务必须可独立执行、可独立评估、可独立返工。每个子任务至少包含:
子任务 T-N:<子任务名称>
目标:<该子任务解决什么问题>
交付物:<必须产出的具体内容,可量化>
约束:<执行限制、事实边界、质量要求、来源范围等>
验收重点:<本子任务最关键的检查点>
执行者指派:<crew-id 或 self>
评估者指派:<crew-id 或 self>
模型层级:<strong / default>
依赖:<无 / 依赖 T-X 完成后启动>
执行方式:<并行 / 串行>
返工策略:<被打回后如何继续>
规则:
allowAgents 白名单内的 crew。在计划落地实施前,必须创建一个独立的 planning reviewer subagent,与主 agent 以 GAN 模式完成计划定稿。
做法:
要求:
| # | 反模式 | 检查点 |
|---|---|---|
| A1 | 子任务粒度过粗 | 单子任务是否仍承载多个目标、估计耗时过长? |
| A2 | 依赖关系不清 | 下游是否明确依赖哪个文件、产物或 verdict? |
| A3 | 过度串行 | 无真实依赖的子任务是否错误地排成串行? |
| A4 | 交付物与验收脱节 | 执行者产物是否无法支撑评估者判定? |
| A5 | 文档无法独立执行 | 如果只给 task.md / acceptance.md,子 agent 是否仍能工作? |
| A6 | 指派对外 crew | 是否有子任务错误地指派了 external crew? |
| A7 | 返工路径缺失 | evaluator 打回后,是否没有明确返工入口? |
| A8 | 过度依赖对话 | 关键信息是否没有提前落到文档与约束中? |
这一步不必与用户确认,但必须经过 planning reviewer subagent 的审查通过。
当 planning reviewer subagent 认为技术方案和计划都已经足够清晰、可执行时,主 agent 应立即按计划创建项目文件夹:
./projects/<YYYYMMDD>-<task-slug>/
./projects/<id>/
PROJECT.md
tasks.json
progress.md
subtasks/
T-1/
task.md
acceptance.md
artifacts/
T-2/
task.md
acceptance.md
artifacts/
final/
# Project: <任务名称>
**ID**: <YYYYMMDD>-<task-slug>
**Created**: <日期时间>
**Status**: planned
## 目标
<一句话概括任务目标>
## 验收标准
- AC-1: ...
- AC-2: ...
## 执行总览
- 子任务数量:N
- 并行组:...
- 关键依赖:...
{
"project_id": "<YYYYMMDD>-<task-slug>",
"created_at": "<ISO 8601>",
"status": "planned",
"subtasks": [
{
"id": "T-1",
"name": "<子任务名称>",
"executor_assignee": "<crew-id 或 self>",
"evaluator_assignee": "<crew-id 或 self>",
"dependencies": [],
"status": "pending",
"executor_status": "pending",
"evaluator_status": "pending",
"verdict": "unknown",
"artifact_dir": "./projects/<id>/subtasks/T-1/artifacts/",
"result_summary": ""
}
]
}
建议状态流转:
status:planned → executing → aggregating → overall_review → donestatus:pending → running → awaiting_verdict → accepted | needs_rework | blockedverdict 只能由 evaluator 或 overall evaluator 的正式结论驱动。# Progress Log — <任务名称>
## [<时间戳>] Phase 4: 项目初始化完成
- 项目目录:./projects/<id>/
- 子任务数量:N 个
- 已创建子任务文档:T-1 ... T-N
必须在每个子任务目录下创建两个 Markdown:
task.md:详细描述子任务内容、目标、上下文、依赖、产物位置、执行约束acceptance.md:详细描述子任务验收标准、检查方法、拒收条件、评估输出格式建议模板:
# task.md
## 目标
## 输入与上下文
## 交付物
- 路径:./projects/<id>/subtasks/T-N/artifacts/
- 必须包含:...
## 约束
## 禁止事项
# acceptance.md
## 必须满足
- AC-TN-1: ...
- AC-TN-2: ...
## 拒收条件
## 评估输出格式
- verdict: accepted | needs_rework | blocked
- findings:
- <编号化问题清单>
- evidence:
- <对应文件 / 事实 / 缺口>
每个子任务都必须创建两个 subagent:
task.md 执行acceptance.md 评估关键约束:
task.md、acceptance.md、artifacts/ 内产物和结构化 verdict 为中心。accepted,该子任务就不能进入可交付状态。executor 至少应收到:
task.md 路径acceptance.md 路径建议 executor 输出格式:
执行回合:
子任务:T-N
本轮修改产物:
- <文件路径>
本轮结果摘要:
- <1-3 条>
需评估项:
- <请 evaluator 针对哪些标准检查>
evaluator 至少应收到:
acceptance.md 路径task.md 路径建议 evaluator 输出格式:
评估回合:
子任务:T-N
verdict: accepted | needs_rework | blocked
findings:
1. <问题或通过项>
2. ...
evidence:
- <文件路径 / 事实依据 / 缺失项>
next_action:
- <执行者下一轮应修改什么>
每个子任务都按以下循环推进,直到 evaluator 给出 accepted:
task.md 产出或修改交付物。acceptance.md 对产物做批判性检查。needs_rework,执行者只针对 findings 返工,不重做无关部分。blocked,主 agent 介入,澄清事实、修正文档或向用户确认。accepted 时,主 agent 才能把该子任务状态写为 accepted。Phase 5 的巡检仍然是主 agent 的职责,至少包括两类工作。
一类:推进卡住的 subagent
二类:处理问题与偏差
task.md 或 acceptance.md 与事实不符,应向主 agent 提问。主 agent 不得:
artifacts/ 里出现新文件,就直接把子任务标记为完成。只有以下动作允许更新子任务状态:
runningawaiting_verdictacceptedneeds_reworkblocked巡检记录建议追加到 progress.md:
## [<时间戳>] 巡检
- T-1: evaluator 判定 needs_rework,已要求执行者继续
- T-2: evaluator 卡住,已发送“继续”
- T-3: task.md 与事实冲突,已向用户确认并更新文档
所有子任务都获得对应 evaluator 的 accepted verdict 后,主 agent 才能进入聚合阶段。
聚合时:
tasks.json,确认所有相关子任务 status = acceptedaggregating./projects/<id>/final/ 下生成聚合产物progress.md 追加记录## [<时间戳>] Phase 6: 结果聚合完成
- 已接受子任务:X / N
- 聚合产物:./projects/<id>/final/
注意:在 Phase 6 完成前,不必创建整体评估 subagent。此时各子任务的可接受性,已经由各自 evaluator 负责。
Phase 6 聚合完成后,必须再 spawn 一个独立的 overall evaluator subagent,专门评估最终整合结果。
它至少应读取:
PROJECT.mdacceptance.md 与产物摘要其职责:
建议输出格式:
整体评估:
verdict: accepted | needs_rework
findings:
1. <全局缺口>
2. ...
impacted_subtasks:
- <T-2>
- <需要新增 T-5>
rationale:
- <为何当前聚合结果仍不满足全局 AC>
如果 overall evaluator 明确给出 accepted,进入 Phase 8。
如果 overall evaluator 给出 needs_rework,主 agent 必须基于 findings 组织返工:
task.md 或 acceptance.mdtask.md、acceptance.md这个循环应持续,直到 overall evaluator 认为可以交付。
如果返工轮次明显增多,主 agent 应主动向用户汇报风险、差距和拟调整方案;但不能跳过 overall evaluator 的最终判定。
当且仅当 overall evaluator 明确接受后:
tasks.json 顶层 status 更新为 doneprogress.md 追加最终记录## [<时间戳>] Phase 8: 任务完成
- 整体评估:accepted
- 最终产物:./projects/<id>/final/
向用户交付:
任务完成
项目目录:./projects/<id>/
最终产物:
<路径 / 摘要>
验收确认:
AC-1: ✅ ...
AC-2: ✅ ...
整体评估:
accepted
交付后执行常规 closeout。
| # | 反模式 | 后果 | 应对 |
|---|---|---|---|
| P1 | 子任务粒度过粗 | 单个执行者长期失控或难以评估 | 每个子任务只负责一个清晰目标 |
| P2 | 过度依赖对话 | 需求漂移、理解不一致、难追责 | 关键约束必须落到 task.md / acceptance.md |
| P3 | 执行者无 evaluator 配对 | 无法形成独立验收闭环 | 每个子任务必须成对 spawn |
| P4 | 见产物就改状态 | 误把“有文件”当“可交付” | 只有 evaluator verdict 才能决定接受 |
| P5 | 文档与事实脱节 | 子 agent 基于错误约束持续返工 | 一旦发现偏差,主 agent 立即更新文档并广播 |
| P6 | 过早整体评估 | 还未完成子任务验收就提前总评 | 只有 Phase 6 后才创建 overall evaluator |
| P7 | 指派 external crew | Spawn 失败或流程中断 | 仅指派 self 或 allowAgents 白名单内 crew |
| P8 | 主 agent 越权代评 | 评估失真,流程失守 | 主 agent 只治理流程,不代替 evaluator 下 verdict |
遇到以下情况,需要修改计划或文档时,遵守正式变更流程。
task.md / acceptance.md所有变更必须在 progress.md 追加:
## [<时间戳>] 计划变更
- 变更原因:<触发场景>
- 变更内容:<新增 / 修改 / 取消哪个子任务,或更新哪份文档>
- 影响范围:<受影响的子任务 / 评估者 / 聚合结果>
- 用户确认:<已确认 / 无需确认>
以下内容一旦已获用户确认,后续若要修改,必须重新与用户确认:
全局验收标准(AC)
最终交付物形式 以下内容通常不需要单独等待确认,但发生重大变化时,应及时同步用户:
子任务总体拆分逻辑
关键执行顺序与重大依赖关系