claude-mem 中 do Skill 的编排实践：用 ORCHESTRATOR 子代理逐阶段执行分阶段实施计划

导读

在 claude-mem 的 Skill 体系中，make-plan 负责把一项复杂任务拆解为可在新对话上下文中逐个执行的"分阶段实施计划"（phased implementation plan），而 do Skill 则负责以 ORCHESTRATOR（编排者） 的身份，把这些阶段逐个派发给专用子代理去落地、验证与提交。本文以 openclaw/skills/do/SKILL.md 为骨架，结合 make-plan Skill、OpenClaw 插件清单 与仓库中真实的 plans/ 设计文档，完整讲解该执行协议的门控规则、各阶段子代理分工、失败模式清单及其与计划端契约的衔接方式。读完你将掌握一套可直接复用的"计划—执行—验证—提交"多代理工程化流程。

---

一、先理解它属于哪一环：claude-mem 的计划与执行双 Skill

claude-mem 是一个为各类编码 Agent（Claude Code、OpenClaw、Codex 等）提供跨会话持久上下文的开源项目。项目仓库把一套"面向 Agent 自身工程化"的 Skill 方法论同时分发给两条宿主线：

• OpenClaw 插件线：位于 openclaw/skills/（其中 make-plan、do 两个 Skill 一同存在）；
• Claude Code 插件线：位于 plugin/skills/，其中 do Skill 内容与 OpenClaw 版本逐字一致。

两套 Skill 能随插件被加载，靠的是两件事：

1. Skill 目录布局：OpenClaw 侧通过 openclaw/openclaw.plugin.json 中的 skills 数组把 skills/make-plan 与 skills/do 挂载为插件能力；
2. frontmatter 描述触发：每个 SKILL.md 文件顶部都有 name 与 description 字段（如 do 的描述是 "Execute a phased implementation plan using subagents. Use when asked to execute, run, or carry out a plan — especially one created by make-plan"）。宿主 Agent 依据 description 判断当前任务是否命中该 Skill，因此 do 被设计成"明确收到计划后的执行入口"，与 make-plan 天然成对：make-plan 描述里同样写明"Use … especially before executing with do"。

因此，这一对 Skill 构成了 claude-mem 方法论里的核心闭环：oh-my-issues（问题聚类）→ make-plan（文档调研 + 分阶段计划）→ do（编排子代理逐阶段执行与验证）。do 正好处于该闭环的下游执行端。

---

二、角色模型：ORCHESTRATOR 只做协调、路由与验证

do Skill 开篇即给出最关键的定位：

You are an ORCHESTRATOR. Deploy subagents to execute all work. Do not do the work yourself except to coordinate, route context, and verify that each subagent completed its assigned checklist.

（你是编排者。把所有工作都派发给子代理去执行。除协调、路由上下文、验证每个子代理是否完成其被指派的核对清单之外，不要亲自做事。）

这是一个容易在实践中走形、却决定成败的约束，可以从三个层面理解：

• Why not 亲自做：单次会话的上下文窗口与注意力是稀缺资源。把大规模实施拆成多个"新鲜子代理"分别执行，可以让每个子代理带着最小必要上下文独立工作，避免主会话上下文被各阶段中间产物持续污染。
• ORCHESTRATOR 的三项保留职能是纪律性的：
  1. coordinate（协调）：决定当前推进哪个阶段、以何种顺序、把阶段边界画在哪；
  2. route context（路由上下文）：只把当前阶段真正需要的计划片段、文档引用、交接信息传给对应子代理；
  3. verify（验证）：对照计划核对子代理回报的证据，判断是否放行进入下一阶段。
• 与 make-plan 的角色分工一致：make-plan 同样是 ORCHESTRATOR 心智——"用子代理做事实收集与提取（文档、示例、签名、grep 结果），把综合与计划撰写留给自己"。do 不过是把这个"编排者不亲自动手"的原则从写计划阶段延伸到了执行阶段。这在整个方法论中是自洽且被反复强调的。

---

三、Execution Protocol 逐步拆解

3.1 Rules：执行协议的三条铁律

原文规定三条规则，是后续每个阶段操作的总纲：

规则	原文要点	落地方案
1. 新鲜子代理	Each phase uses fresh subagents where noted (or when context is large/unclear)	阶段任务明确、计划章节就绪时启用新子代理；当上下文过大或含糊不清时同样换新，防止陈旧记忆污染判断
2. 单一目标 + 证据	Assign one clear objective per subagent and require evidence (commands run, outputs, files changed)	每个子代理只领一个清晰目标，回报时必须附带已执行命令、运行输出、改动文件清单等证据，而非一句"完成了"
3. 门控推进	Do not advance to the next step until the assigned subagent reports completion and the orchestrator confirms it matches the plan	未收到完成报告、或报告与计划不符，绝不提前进入下一步

第 2 条"evidence"要求与 make-plan 的 Subagent Reporting Contract（强制报告契约） 相互呼应：那边要求每个子代理回报必须包含"查阅的资料、具体发现（确切 API 名/签名/文件路径）、可复制的示例片段位置、置信度说明与已知缺口"，并规定"若子代理只给结论不给来源，则拒绝并重新派发"。也就是说，证据标准从计划阶段就已建立，do 在执行阶段只是继续执行同一套证据纪律。

3.2 During Each Phase：Implementation 子代理的四项义务

每个阶段推进时，编排者要派发一名 "Implementation"（实施）子代理，其任务书包含原文四点：

1. Execute the implementation as specified —— 按计划规格执行，不擅自改需求；
2. COPY patterns from documentation, don't invent —— 从文档中"复制"模式，而不是凭想象发明；
3. Cite documentation sources in code comments when using unfamiliar APIs —— 使用陌生 API 时，在代码注释里标注文档来源；
4. If an API seems missing, STOP and verify — don't assume it exists —— 若某个 API"看起来不存在"，停下来核实，而不是假设它存在。

第 2～4 点本质是同一信念的三次表达："Verify > Assume"（验证大于假设）。项目里凡是采用此方法论落地的设计文档，其"要做什么（What to implement）"条目都会刻意用"从文档/示例的某行复制某个模式"来措辞，而非"迁移/重构现有代码"，原因正是 make-plan 写明的原则——任务措辞必须把 Agent 引向文档而非只给结果（Task Framing Matters）。

3.3 After Each Phase：阶段结束后的四路并行子代理

原文规定每个阶段完成实施后，编排者还需要派发四路承担阶段后职责的子代理：

1. Run verification checklist —— Verification 子代理：证明本阶段确实生效（跑测试、grep 关键输出、核对计划中的验证项）；
2. Anti-pattern check —— Anti-pattern 子代理：用计划中列出的已知坏模式对本阶段改动做 grep 扫描；
3. Code quality review —— Code Quality 子代理：审查本次改动质量；
4. Commit only if verified —— Commit 子代理：仅当验证通过后才派发提交子代理；否则不得提交。

这条顺序链非常关键：验证在前、提交在后。Commit 是被放在整条流水线最后一环的"特权操作"，只有 Verification 证明工作有效、Anti-pattern 扫描干净、Code Quality 审查通过，提交才被授权——这正是原文标题"Commit only if verified"字面与流程上的双重含义。

在 claude-mem 仓库中可找到与该纪律对应的工程痕迹：根目录与 scripts/ 下存在多类"纪律检查脚本"（如 check-hook-io-discipline.cjs、check-pending-queue.ts 等），测试目录 tests/ 覆盖了插件生命周期、hook 行为、观察会话存储等大量模块。这些自动化检查本质上就是把"验证清单"固化成可重复执行的命令，供 Verification/Anti-pattern 子代理直接调用。

3.4 Between Phases：阶段间隙的 Branch/Sync 子代理

阶段与阶段之间，派发 "Branch/Sync"（分支/同步）子代理 完成两件事：

• Push to working branch after each verified phase —— 每个通过验证的阶段结束后，把结果推送到工作分支；
• Prepare the next phase handoff —— 准备下一阶段交接，使下一阶段的子代理"空手进场却有计划上下文"。

这意味着每个阶段以"已验证 + 已推送 + 已交接"收官。交接内容应当只包含下一阶段所需的计划切片与必要上下文，而非整场会话的历史——这样既满足"fresh subagents"，又不至于让新子代理丢失全局计划。这种"阶段自包含、以设计文档为交接载体"的做法与 plans/ 目录中的设计文档（如 plans/02-spawn-contract-templating.md、plans/2026-07-17-phase5-two-lane-sync.md 等）相吻合：仓库把大型改动沉淀为 plans/0X-*.md 文档，供不同会话、不同阶段反复引用，让"跨新会话上下文连续执行"成为可能。

---

四、Failure Modes：需要主动预防的五类失败

原文在协议末尾给出五条失败模式清单，全文照录如下：

• Don't invent APIs that "should" exist — verify against docs —— 不要发明"理应存在"的 API，要对着文档核实；
• Don't add undocumented parameters — copy exact signatures —— 不要添加文档中没有的参数，要逐字复制确切签名；
• Don't skip verification — deploy a verification subagent and run the checklist —— 不要跳过验证，要派发验证子代理并运行核对清单；
• Don't commit before verification passes (or without explicit orchestrator approval) —— 验证通过前（或未经编排者明确批准）不得提交。

这五条与计划端 make-plan 的 "Anti-Patterns to Prevent" 清单几乎一一对应（那边列出：发明"理应存在"的 API 方法、添加文档之外的参数、跳过验证步骤、不查示例就假设结构）。两端的反模式清单一致，说明该方法论在"计划"与"执行"两侧设了同样的防错网：

• 计划侧用 Phase 0: Documentation Discovery（文档调研，永远第一步） 产出"Allowed APIs（允许使用的 API）清单"，从源头排除"想当然 API"；
• 执行侧则由 Implementation 子代理第 4 条义务（API 疑似缺失即 STOP 核实） 与 Anti-pattern 子代理的 grep 扫描 在落地时兜底。

对一个为 其他 Agent 提供记忆服务的项目而言，这种反模式纪律尤其重要：do/make-plan 的目标宿主经常需要与陌生 SDK、未知签名打交道，若执行代理凭空捏造 API，污染的不只是代码，还有项目赖以运转的调用链。

---

五、让计划"可执行"：do 所消费的计划契约长什么样

do 假定执行对象是 make-plan 生成的、面向 LLM 友好的分阶段计划。按 make-plan SKILL.md 的规定，每个实施阶段必须包含四个字段，恰好是 do 各子代理的工作输入：

计划字段	说明	do 侧消费方
What to implement	措辞为"从文档/示例复制模式"，而非"迁移现有代码"	Implementation 子代理按此执行
Documentation references	指明要遵循模式的具体文件/行	Implementation 子代理在注释中引用；遇到 API 缺失时据此核实
Verification checklist	证明本阶段生效的测试与 grep 检查	Verification 子代理逐项运行
Anti-pattern guards	明确"不要做什么"（发明 API、加未文档化参数等）	Anti-pattern 子代理据此做 grep 扫描

同时，make-plan 规定计划必须以 Phase 0（文档调研）开头，由"Documentation Discovery"子代理产出引用具体文档来源的 Allowed APIs 清单——这份清单随后成为 do 执行阶段判断"某 API 是否真的存在"的唯一权威参照。可见 do 的每个执行步骤都指向计划中预先定义的契约字段：do 不做自由发挥，它只负责把已固化的计划可靠地变成已验证的代码与提交。

补充：若需求源头是 bug/功能积压而非全新想法，make-plan 建议先经过问题侧兄弟 Skill oh-my-issues（见 plugin/skills/oh-my-issues/SKILL.md）按根因聚类生成计划主文档，再由 make-plan 在其中一个计划切片上工作——这一前置流程产出的同样是 plans/0X-*.md 设计文档，最终仍汇入 do 执行。

---

六、在 claude-mem 仓库中观察这套协议的"实物"

这套方法论并非停留在 Skill 文本中，仓库里有几类可直接对照的实物：

1. 双宿主同一份 Skill：openclaw/skills/do/SKILL.md 与 plugin/skills/do/SKILL.md 内容一致，确保无论 Agent 走 OpenClaw 还是 Claude Code 插件线，拿到的执行协议都相同；两者都由 openclaw/openclaw.plugin.json（OpenClaw 侧）把 skills/make-plan、skills/do 一起声明进插件能力。
2. 成对技能与生态：除 do/make-plan 外，仓库还维护 mem-search、knowledge-agent、pathfinder 等技能（见 plugin/skills/ 目录），每个技能同样依赖 frontmatter 的 name/description 驱动触发——理解这一机制有助于你为自己的团队 Skill 编写可被 Agent 准确命中的描述。
3. 真实设计文档沉淀：plans/ 目录（如 plans/02-spawn-contract-templating.md）中记录了含验证/反模式信息的实施文档，可作为观察"阶段自包含、文档化交接"范式的活样本。

---

七、速查：一次完整的多代理执行循环

把全文浓缩成一次可照做的编排循环，便于作为你自己的 checklist 使用：

1. 接收计划：确认上游是 make-plan（或同类）产出的分阶段计划，含每个阶段的 What/文档引用/验证清单/反模式护栏。
2. 逐阶段推进（Do not advance without confirmation）：
   • 派发 Implementation 子代理：照文档复制模式、陌生 API 引用来源、疑似缺失即 STOP 核实；
   • 派发 Verification 子代理：运行该阶段验证清单，证明生效；
   • 派发 Anti-pattern 子代理：grep 计划列出的已知坏模式；
   • 派发 Code Quality 子代理：审查改动质量；
   • 全部通过后，才派发 Commit 子代理提交；否则打回修复。
3. 阶段收尾：派发 Branch/Sync 子代理推送工作分支、准备好下一阶段交接上下文。
4. 自我防错：随时对照五条失败模式——不发明 API、不加未文档化参数、不跳验证、验证前不提交。
5. 全程角色纪律：ORCHESTRATOR 只协调、路由上下文、核对证据，绝不越俎代庖替子代理干活。

这套"计划契约化 + 执行子代理化 + 验证门控化 + 提交授权化"的流程，正是 do Skill 全文——openclaw/skills/do/SKILL.md——试图在你的下一个多步骤实施任务中固化的行为准则。