Subagent Orchestrator Skill#

版本#

• v2.0.0 (2026-05-25): 重大升级（参考 Trae Solo / Windsurf Cascade / Devin）

  1. 新增 Phase 0.5 需求完善——接需求后主动询问 3-5 个问题，明确后再拆解
  2. 新增 独立任务空间——每个任务专属目录，中间文件和最终产物集中管理
  3. 新增 Plan 驱动机制——Phase 1 输出完整 Plan，Phase 3 按 Plan 逐项打勾
  4. 改造 交付清单——最终交付含中间产物列表 + 相关文件的 diff
  5. 新增 Checkpoint + Revert——每步完成后打 checkpoint，支持回退
  6. 新增 Queued Messages——执行期间可追加指令，进入队列依次执行
  7. 新增 实时进度反馈——每步完成后推送微信，不等最终完成

---

核心原则#

1. 分工原则#

角色职责不做什么Main Agent需求确认、三文件准备、启动 Subagent、监控进度、失败汇总、Queued Messages 路由、最终整合推送微信不亲自执行信息收集/重IO操作Subagent执行具体子任务、写数据文件、更新状态、Checkpoint、失败5次即停+报告不做最终决策、不回写任务文件

串行：共享资源（浏览器/数据库）；并行：独立资源（web_fetch/不同API）。不确定时默认串行。

2. 三文件分离原则#

Token 节流规范：

• _任务.md：Main Agent 写一次，Subagent 启动时只读一次，永不重读
• _状态.md：Subagent 增量写，Main Agent 只扫进度，保持 <500字
• _数据.md：Subagent 增量写，Main Agent 仅读此文件汇总
• 失败先写状态文件；同一错误连续失败5次立即停止，不空转

3. 独立任务空间原则#

每个任务有专属目录，所有产物集中管理：

text

~/.openclaw/workspace/tasks/[任务ID]/
├── _任务.md           # Main Agent 写入，Subagent 只读
├── _状态.md           # Subagent 增量写
├── _数据.md           # Subagent 增量写
├── _交付清单.md       # Phase 4 由 Main Agent 汇总
├── _Plan.md           # 独立 Plan 文件，Subagent 执行前只读此文件（不读 _任务.md）
├── _Checkpoints.md    # Checkpoint 记录，支持回退
├── _MessageQueue.md   # Queued Messages 队列
└── workspace/         # 任务执行时的所有中间文件
    ├── [子任务A]/
    └── ...

• 用户可指定空间： --workspace /path/to/dir，则使用用户指定目录
• 命名规则： [任务ID] = 任务名-日期-序号，如 ai-research-20260525

4. Plan 驱动原则#

Phase 1 的核心产出是 Plan，所有后续执行必须严格按 Plan 推进：

text

## Plan（共 N 步，控制在 3 轮以内）
- [ ] Step 1: [描述]（工具：[预期工具]，产出：[中间/最终产物]）
- [x] Step 2: [描述] ✅ 完成于 10:02（工具：[实际用到的工具]，产出：[实际产出]）
- [ ] Step 3: [描述]

• Plan 总步骤数控制在 3 轮以内
• Phase 3 每完成一个 Step → 在 Plan 中打 [x] 并标注实际工具和产出
• Subagent 发现 Plan 有缺陷 → 写状态文件 + tag=need_user → Main Agent 询问用户是否更新

5. 需求完善原则（Phase 0.5）#

收到任务后， 不立即拆解，先主动完善需求，询问 3-5 个关键问题：

text

1. 【目标明确化】最终交付物？格式？位置？
2. 【范围界定】包含什么？明确排除什么？
3. 【约束条件】时间/格式/工具限制？参考文件？
4. 【验收标准】怎么算完成？量化指标？
5. 【优先级】必须 vs 可精简？
6. 【背景/上下文】解决什么问题？历史背景？
7. 【工作空间】指定目录 or 默认 tasks/[任务ID]？

跳过条件： 用户需求已包含完整信息（目标/范围/验收标准/交付位置均有）→ 直接进入 Phase 1

6. Checkpoint + Revert 原则#

每次 Phase/Step 完成后自动记录 checkpoint，支持回退：

markdown

## Checkpoint 记录
| ID | 时间戳 | Phase/Step | 状态摘要 | 可回退 |
|-----|---------|-----------|---------|-------|
| ckpt-0 | 10:00 | Phase 1 | Plan已确认，3步子任务 | 是 |
| ckpt-1 | 10:15 | Phase 3 Step1 | 收集阶段完成，10条记录 | 是 |

回退操作步骤（Main Agent 执行）：

text

1. 确认 ckpt-ID 存在且「可回退」= 是
2. 备份当前 workspace/ → workspace_backup/
3. 从备份中恢复 ckpt-ID 时 workspace/ 内容（覆盖当前）
4. 将 ckpt-ID 时 _数据.md 内容写入（覆盖当前）
5. 新建 checkpoint ckpt-N+1，记录：回退原因、回退到/来自哪个 checkpoint
6. 通知用户回退完成
7. 若 Subagent 未结束，sessions_send 通知从 ckpt-ID 状态继续

不执行回退： 任务已完成（Phase 4 结束）或 ckpt「可回退」= 否

7. Queued Messages 原则#

Subagent 执行期间，用户可追加指令，Main Agent 将其追加到 _MessageQueue.md，Subagent 每步执行前检查：

markdown

## Message Queue
| # | 时间戳 | 来源 | 消息内容 | 状态 | 执行时机 |
|---|--------|------|---------|------|---------|
| 1 | 10:05 | 微信 | "加一个 XX 字段" | ⏳ | 下一步执行前 |
| 2 | 10:07 | WebChat | "这个先暂停" | ⏳ | 当前步完成后检查 |

处理规则（按优先级）：

• 工具调用 执行前 收到暂停/停止 → 立即停止，状态文件标记 ⏸️ 暂停，报告 Main Agent
• 工具调用 执行中 收到暂停/停止 → 完成当前调用再停止（防止半写入文件）
• 追加类消息 → append 到 _状态.md 的「用户追加指令」区，继续执行
• Phase 4 整合时清空已处理的队列

8. 失败阈值原则#

类型可自行重试超过5次 → 暂停网络临时故障等10秒再试连续5次 → 暂停验证码/风控写状态→暂停—信息不足/参数错误修复后重试连续5次 → 暂停权限/认证失败—立即暂停，报告用户

9. 交付验证原则#

text

📤 交付验证（必须全部提供，否则视为未交付）
- 目标渠道：[channel/thread id 或具体位置描述]
- 消息ID：[message_id 或 object_id]
- 人类可查位置：[可验证的链接或描述]

缺少任一 → 任务视为未完成，不得标记 done。

10. Memory 固化原则（按需写入，不爆炸）#

条件是否写 memory写什么写多少子任务数 ≥ 3 且正常完成写一行摘要任务目标+关键成果+文件路径100字有失败/异常/阻塞写失败原因+解决建议50字正常完成（子任务数 < 3）不写—0发现更好方案/工具写替代方案+使用条件~50字用户做了特殊决策写用户偏好（下次自动用）~30字

11. 模型分级原则#

Agent简单中等（默认）复杂Claude Codeclaude-haiku-4-5@20251001``claude-sonnet-4-6@default``claude-opus-4-6@defaultOpenCodedobest/MiniMaxM2.5``dobest/glm-5.1``dobest-claude/claude-opus-4-6@default信息收集子 Agentdobest/MiniMaxM2.1``dobest/MiniMaxM2.5``dobest/gpt-5.4部署子 Agentdobest/MiniMaxM2.1``dobest/MiniMaxM2.5``dobest/glm-5.1学习子 Agentdobest/MiniMaxM2.1``dobest/MiniMaxM2.5``Qwen3.5-397B

难度判断标准：

难度判断标准简单一次性任务、常识性输出、不需要深度推理、单步或两步完成中等（默认）需要一定上下文、简单推理、多步操作复杂多步骤、深度推理、长上下文、跨域知识、需反复迭代

12. 其他原则#

• 资源整合度： 引用的路径/资源使用前验证可达性（ls 检查目录/文件），不可达则报告用户
• 资源独占： 共享资源不可并发（浏览器/数据库），独立资源可并发（web_fetch/只读API）
• 数据纯正性： 不擅自切换来源，每个来源有验证方法，切换需用户同意

---

自动触发场景#

满足任一即触发，不只是用户主动要求：

1. 预估超出上下文：3+文件、>10轮对话、多轮浏览器操作、单次输出>1500字 → 立即拆分分流
2. Context 即将 compact：回复变慢/开始遗忘/大量工具调用 → 紧急落盘三文件 + spawn 接续
3. 单任务天然拆分：2+独立信息源/平台、分阶段结构 → 按正常流程执行 Phase 0.5-4
4. 执行中途发现上下文不够：数据量超预期/Subagent 自身快爆 → 三文件分离，嵌套 spawn 需用户确认
5. 任务略复杂（3步以上）：多步推理/搜索/文件操作组合 → 优先拆分
6. Subagent 连续失败5次：停止重试，报告 Main Agent
7. Queued Messages 包含暂停/停止指令：立即停止 Subagent，报告 Main Agent

---

执行流程#

Phase 0: 拆分必要性预判#

判断维度是 → 拆分否 → 直接执行独立信息源数量≥2个只有1个步骤数明确超过3步1-2步可一次性完成资源冲突风险有共享资源需串行完全无共享资源预期token消耗多来源→拆分收益高单来源→拆分开销大于收益

预判结论写入任务文件：

markdown

## 拆分判断
- 预判结论：[拆分 / 不拆分]
- 理由：[一句话说明]

---

Phase 0.5: 需求完善（Main Agent）#

触发： 任务需要拆分（Phase 0 判定为拆分），且用户未在需求中提供足够信息

目的： 主动询问 3-5 个问题，完善以下维度，避免执行中反复确认

问题清单（选择性使用，选最关键的 3-5 个问）：

text

1. 【目标明确化】最终交付物？格式？位置？
2. 【范围界定】包含什么？明确排除什么？
3. 【约束条件】时间/格式/工具限制？参考文件？
4. 【验收标准】怎么算完成？量化指标？
5. 【优先级】必须 vs 可精简？
6. 【背景/上下文】解决什么问题？历史背景？
7. 【工作空间】指定目录 or 默认 ~/.openclaw/workspace/tasks/[任务ID]/？

确认话术示例：

text

收到，我来帮你做这个调研。
有几个问题先确认一下：
1. 最终交付物是报告还是摘要文档？格式偏好？
2. 需要覆盖哪些平台/来源？
3. 有没有参考的模板或风格要求？
确认后开始执行。

输出： 收到用户回复 → 综合 Phase 0 判断 → 进入 Phase 1

---

Phase 1: 任务拆解与准备（Main Agent）#

1. 明确目标： 最终交付物是什么？验收标准？（综合 Phase 0.5 用户回复）
2. 输出 Plan： 将任务拆分为 3 轮以内 的可执行步骤，每步标记预期工具/产出
3. 判断串行/并行： 共享资源串行，独立资源并行
4. 创建任务空间（执行此命令）：

bash

mkdir -p ~/.openclaw/workspace/tasks/[任务ID]/workspace/[子任务目录按需创建]
touch ~/.openclaw/workspace/tasks/[任务ID]/_Plan.md
touch ~/.openclaw/workspace/tasks/[任务ID]/_Checkpoints.md
touch ~/.openclaw/workspace/tasks/[任务ID]/_MessageQueue.md

三文件（_任务.md / _状态.md / _数据.md / _交付清单.md）由 Main Agent 在后续步骤写入。

Plan 文件模板（_Plan.md）：

markdown

# [任务名] Plan

## 基本信息
- 创建时间: [时间戳]
- 最后更新: [时间戳]

## Plan（共 N 步，3 轮以内）
- [ ] Step 1: [描述]（工具：[预期工具]，产出：[中间/最终产物]）
- [ ] Step 2: [描述]（工具：[预期工具]，产出：[中间/最终产物]）
- [ ] Step 3: [描述]（工具：[预期工具]，产出：[中间/最终产物]）

## 进度记录
| Step | 状态 | 开始时间 | 完成时间 | 实际工具 | 实际产出 |
|------|------|---------|---------|---------|---------|
| Step 1 | ⏳ | — | — | — | — |
| Step 2 | ⏳ | — | — | — | — |
| Step 3 | ⏳ | — | — | — | — |

Checkpoint 初始记录（_Checkpoints.md）：

markdown

## Checkpoint 记录
| ID | 时间戳 | Phase | 状态摘要 | 可回退 |
|-----|---------|-------|---------|-------|
| ckpt-0 | [时间戳] | Phase 1 | Plan已确认，N步子任务 | 是（Plan确认后） |

状态文件初始内容：

markdown

# [任务名] 状态

## 基本信息
- 任务空间: ~/.openclaw/workspace/tasks/[任务ID]/
- Plan 路径: _Plan.md（Subagent 每次执行前只读此文件，不读 _任务.md）

## Plan 进度
- [ ] Step 1: [描述] — ⏳ 等待中
- [ ] Step 2: [描述] — ⏳ 等待中
- [ ] Step 3: [描述] — ⏳ 等待中

## 当前指向
- 当前执行到：Step N
- 下一步：Step N 的具体操作

## Checkpoint
- 最新：ckpt-0（Phase 1 完成）
- 可回退到：[ckpt-0]

## Queued Messages
- 待处理：0 条

## 任务状态
- 状态：⏳ Plan 已就绪（Phase 0.5 需求确认完成）

## 用户追加指令
- （空）

## 待解决问题
- 无

---

Phase 2: 启动 Subagent 前确认（Main Agent）#

⚠️ Spawn 前必须确认： 向用户展示 Plan + 子任务列表 + 并行/串行策略 + 预计执行顺序，获明确回复后再 spawn。

确认话术模板：

text

📋 需求已确认，开始执行：

📝 Plan（共 N 步，3 轮以内）
  Step 1: [描述] → 产出：[文件/数据]
  Step 2: [描述] → 产出：[文件/数据]
  ...

📁 任务空间：~/.openclaw/workspace/tasks/[任务ID]/
  所有中间文件和最终产物都存在这里
  交付时包含所有文件的变更 diff

🔀 执行策略：[A || B 先行] → C 串行
📊 实时进度：每步完成后推送微信，完成后推送完整交付清单
开始执行？

每次 spawn 四必填：

• ✅ mode: "session"
• ✅ sessionKey: "[任务ID]-[子任务名]"
• ✅ 完整 task 参数（塞满所有细节，包括 Plan、任务空间路径）
• ✅ 三文件路径告知（强调 workspace/ 下的中间文件都存在任务空间里）
• ✅ 交付证明要求（如有外部交付： proof 字段说明需要的证明类型）

最小 spawn 模板：

javascript

sessions_spawn({
  label: "[子任务描述]",
  mode: "session",
  sessionKey: "[任务ID]-[子任务名]",
  task: `
目标：[明确、可验收的目标]
只读：_Plan.md（Plan 核心）、_任务.md（仅补充说明）
只写：_状态.md + _数据.md + _Checkpoints.md + workspace/
执行前：读 _MessageQueue.md，检查是否有暂停/停止指令
执行中：每完成一个 Step → 更新 _Plan.md（打[x]） + 写 _数据.md + 打 checkpoint
异常处理：立即写入状态文件并报告
验收标准：[至少N条/包含XX/格式为XX]
`
})

---

Phase 3: Subagent 执行（6 步法 + 实时进度）#

⚠️ 重要执行顺序（按此优先级读文件，不要读 SKILL.md 全文）：

text

1. 读 _Plan.md → 找到当前 Step（第一个 [ ] 的行）
2. 读 _MessageQueue.md → 检查暂停/停止指令
3. 执行当前 Step（按 Plan 中的工具预期）
4. 完成后写 _数据.md → 更新 _Plan.md（打[x]）→ 打 checkpoint → sessions_send 进度
5. 读 _状态.md → 更新进度字段
6. 重复 1-5，直到所有 Step 完成

速查表（执行中快速对照）：

动作读什么文件写什么文件确认当前步骤_Plan.md（不读 _任务.md）—检查暂停指令_MessageQueue.md—记录产出—_数据.md（三段式头）更新进度—_Plan.md（打[x]）打快照—_Checkpoints.md推送进度sessions_send → main_状态.md遇到问题—_状态.md + tag=need_user

三段式数据头格式：

text

---

## [子任务] · Plan-Step-N · [时间戳]

[数据类型]
[实际内容]

每完成一个 Step：

• ✅ 更新 _Plan.md（打 [x]，填实际工具和产出）
• ✅ append 到 _数据.md（带三段式标记头）
• ✅ 打 checkpoint（写 _Checkpoints.md）
• ✅ 推送实时进度（sessions_send 给 Main，根据发起渠道推送，不跨渠道）

Checkpoint 格式（每步完成后追加到 _Checkpoints.md）：

text

| ckpt-[N] | [时间戳] | Phase 3 Step N完成 | [workspace 变化描述] | 是 |

实时进度推送（每步完成后）：

javascript

sessions_send({
  sessionKey: "main",
  message: `📊 [任务名] 进度
Step N/N 完成：[step 描述]
产出：[简要摘要]
${is_final_step ? '最终完成，推送交付清单...' : '下一步：${next_step}...'}`
})

结构化 Return（写状态文件）：

text

## Subagent Return
tag: [autopilot | done | partial | blocked | need_user | paused]
task_id: [任务ID]
Plan 进度: Step N/N（共 M 步）
steps_completed: [1, 2, ...]
files_written: [文件路径列表]
checkpoints_created: [ckpt-1, ckpt-2, ...]
next: [下一步]
proof: [外部交付证明 / null]

tag 含义：

• autopilot：本轮完成但任务线未结束（还有未完成的 Step）→ Main Agent 必须派下一跳
• done：本任务所有 Plan Step 全部完成 → 进入 Phase 4 整合
• partial：部分完成，状态文件已有断点 → 等待接手或用户决定
• blocked：被阻塞（验证码/权限/网络持续失败）→ 等待人工介入
• need_user：需要用户决策（如 Plan 需要调整）→ 报告给用户
• paused：收到暂停/停止指令 → 等待 Main Agent 决定

---

Phase 3.5: Queued Messages 处理（Main Agent）#

Subagent 返回 tag=paused 或用户发送追加消息时：

1. 读 _MessageQueue.md，按顺序处理
2. 「继续」类 → sessions_send 通知 Subagent 继续执行
3. 「修改 Plan」类 → 更新 _Plan.md， sessions_send 通知 Subagent
4. 「停止/取消」类 → 标记任务为 ❌ 取消，进入 Phase 5 清理
5. 「追加需求」类 → append 到 _任务.md 的「追加需求」区，更新 Plan， sessions_send 通知 Subagent

---

Phase 4: Main Agent 整合（7 步法）#

1. 收集中间产物 + 生成 diff（新增步）：

   • 扫描 ~/.openclaw/workspace/tasks/[任务ID]/workspace/，列出所有文件
   • 对已存在文件（配置/脚本/文档）用 git diff 或文件对比工具提取变更
   • 将 diff 写入 _交付清单.md 的「文件 diff」一节

2. 扫状态文件（极小，token≈0） bash

   read ~/.openclaw/workspace/tasks/[任务ID]/_状态.md
   
   

   判断：全✅→继续 | 有⚠️/❌→汇总已有+标注 | 有⏳→汇总已完成部分

3. 仅读数据文件（纯成果内容，无冗余） bash

   read ~/.openclaw/workspace/tasks/[任务ID]/_数据.md
   
   

   按优先级顺序读，只读数据文件，不读任务文件。

4. 跨数据源交叉统计

   • 同类项归一（忽略空格/标点差异）
   • 提及/出现次数 +1
   • 每项附加所有来源
   • 按出现次数降序

5. 生成最终交付清单：

markdown

# [任务名] 交付清单

## 基本信息
- Plan 执行：N/N 步
- 完成时间：[时间戳]
- 任务空间：~/.openclaw/workspace/tasks/[任务ID]/

## 最终产物（用户明确要求）
| 产物 | 路径/位置 | 格式 | 验证方式 |
|------|---------|------|---------|
| [产物名] | [路径] | [格式] | [验证方式] |

## 中间产物（执行过程中产生）
| 产物 | 路径 | 用途 | 来源 |
|------|------|------|------|
| [中间文件名] | workspace/[path] | [用途] | [Step N 生成] |

## 文件 diff（已存在文件的变更）
| 文件 | 变更类型 | 变更摘要 | diff 关键行 |
|------|---------|---------|-----------|
| [配置文件] | 修改 | [改了什么] | [diff 片段] |
| [脚本] | 新建 | [脚本用途] | 不适用（新建） |

## Checkpoint 记录（可追溯）
| ID | 时间戳 | Phase/Step | 状态 |
|-----|---------|-----------|------|
| ckpt-0 | ... | Phase 1 | Plan完成 |
| ckpt-1 | ... | Phase 3 Step 1 | 收集完成 |

## 数据来源统计
- [子任务A]：[N] 条记录

## 交付验证
- 目标渠道：[channel/thread id]
- 消息ID：[message_id]
- 人类可查位置：[链接/描述]

1. 排序与优先级计算
   • 定义权重维度（来源权重、时间衰减、相关性等）
   • 计算综合优先级分
   • 按分降序排列
2. 输出完成报告：

text

【任务完成】[任务名] ✅
📊 Plan 执行：N/N 步
📦 最终产物：X 个
🔧 中间产物：X 个
📄 文件 diff：X 处变更（详细见 _交付清单.md）
💾 Checkpoint：N 个（可回退）
📁 任务空间：~/.openclaw/workspace/tasks/[任务ID]/

1. 推送最终结果（必须执行）：

   ⚠️ 禁止只回聊天，必须同步推送到用户发起需求的渠道，不跨渠道推送。

   bash

   openclaw message send --channel [发起渠道ID] --target [用户ID] -m "[完成报告内容]"
   
   

---

Phase 4.5: sessions_send 路由处理#

收到 Subagent 的 sessions_send 时：

1. 识别为「进度更新」或「完成通知」
2. 不要 回复 ANNOUNCE_SKIP 或空回复
3. 同步推送到用户发起需求的渠道（不跨渠道）

Anti-Drop Guard： 每次 subagent 返回 tag=autopilot 后，Main Agent 确认：

text

✅ 确认1：任务线还在任务板上（未手动关闭）
✅ 确认2：Plan 尚有未完成 Step
✅ 确认3：下一跳已派发 OR 任务线已显式关闭
→ 任一缺失 → ❌ 立即 spawn 或派给自己

---

Phase 5: 清理（需用户批准）#

触发： 任务完成 / 失败 / 超7天未动 / 用户主动要求

流程：

1. Memory 固化（按需，见原则10）
2. 列出 ~/.openclaw/workspace/tasks/[任务ID]/ 下所有文件（含 workspace/）
3. 向用户展示分类（最终产物 / 中间文件 / 保留文件）
4. 强调 _交付清单.md 不删除
5. 未获批准前不执行任何清理
6. 获批后用 trash，不用 rm

规则：

• 只清理中间文件，不删最终产出和交付清单
• 默认保留 72h 内文件
• 交付清单中标记为「最终产物」的文件永不删除

---

实时进度推送规则#

时机： Phase 3 每完成一个 Step → 推送一条进度（不等最终完成） 渠道： 推送到用户发起需求的渠道（WebChat/Discord/微信等，不跨渠道推送）

内容要素：

text

📊 [任务名] 进度
Step N/N 完成：[step 描述]
产出：[简要摘要]
[下一步提示 / 最终完成预告]

不推送： 步骤内部的重试、工具调用细节、思考过程

---

常见问题速查#

问题解决方案对话太长快撑爆上下文立即执行上下文抢救：落盘三文件 + spawn Subagent 接续Context compact 后忘了在做什么读 _Plan.md 恢复进度，读 _状态.md 恢复上下文Subagent 忘了任务检查 task 参数是否完整；恢复优先级：task > 文件 > 记忆多个 Subagent 资源冲突串行执行，一个用完再下一个Gateway 重启导致失败Main Agent 重新 spawn，状态文件中有 Plan 断点进度卡住subagents list 检查，kill 后从断点重启Token 消耗过大确认只读数据文件汇总，不读任务文件和完整状态日志临时文件堆积Phase 5 清理，必须用户批准Subagent 连续失败 5 次停止重试，写状态文件❌，向 Main Agent 报告，等待人工介入Subagent 返回 autopilot 但任务线停了检查 anti-drop guard 三件事外部交付任务口头确认"已发送"要求提供 delivery-proof，缺一不可标记未完成Plan 中的 Step 执行遇到意外情况写状态文件 + tag=need_user，报告 Main Agent，等用户确认中间文件不知道存哪存到 workspace/[子任务]/，交付时统一汇报用户在 Subagent 执行期间追加指令Main Agent 追加到 _MessageQueue.md，Subagent 下一轮读取用户要求回退到某 checkpointMain Agent 执行回退，恢复 workspace/ + _数据.md 到当时状态

---

辅助功能（精简）#

每日 Session 清理定时任务： 配合 session-cleanup-pro skill 使用。用户确认需要后，用 cron add 创建定时任务（每天凌晨 03:30）。

---

适用场景示例#

场景Plan 拆分执行策略中间产物上下文即将溢出未完成部分拆出 PlanSubagent 执行，Main 只保留等待workspace/ 下中间文件多平台攻略抓取按平台分 Step浏览器串行，web_fetch并行workspace/[平台]/ 数据文件配置修改任务Step1备份→Step2修改→Step3验证串行，备份优先backup/ + diff代码生成+reviewStep 1生成→Step 2 review→Step 3修改串行，review 依赖生成workspace/generate/ + workspace/review/多数据源调研按来源分 StepAPI限流可能需串行workspace/[来源]/ 原始数据

---

设计理念#

找的范围应该确定性，想的综合应该概率性。 三文件分离的本质是关注点分离：任务是契约，状态是心跳，数据是成果。Plan 驱动让执行有章可循，独立空间让交付有据可查，diff 让变更透明可追溯。