title: Peter Skoett 工作流体系 - OpenClaw 适配性调研
date: 2026-05-17T12:55:00+08:00
lastmod: 2026-05-17T12:55:00+08:00

Peter Skoett 工作流体系 — 与 OpenClaw 的适配性＆集成调研

基于前文的完整工作流调研，此文档专项分析：我们要不要在 OpenClaw 上跑这套体系？怎么协作？影响哪些模块？需要做什么改造？

一、当前环境基线

先明确「我们的 OpenClaw」长什么样：

二、逐 Skill 适配性排查

以下逐一分析 Peter 的 11 个核心 Skill + 4 个 CI Skill，在我们 OpenClaw 环境上的适配程度和改造代价。

2.1 self-improvement（教训记录）

结论：✅ 开箱即用，零改造

这是 Peter 专门为 OpenClaw 做的 Skill。ClawHub 上的 self-improving-agent 直接以 OpenClaw workspace 为第一平台，已经：

• 把晋升目标设定为 AGENTS.md / SOUL.md / TOOLS.md（和我们结构一致）
• 用 workspace 文件注入代替钩子
• 支持 .learnings/ 目录的标准化格式

我们的 MEMORY.md 系统和它互补而不是冲突：MEMORY.md 记大事件和长期记忆，.learnings/ 记具体纠正和错误模式。

安装方式：clawhub install self-improving-agent

协作方式：Agent 自动记错 → 用户被动受益。偶尔人工审查晋升是否合理。

暂无受影响模块。

2.2 plan-interview（结构化需求面试）

结论：✅ 纯 Skill.md，可直接用

本质是一份 Agent 指令——在开始大任务前，按面试框架和用户对齐约束条件。不需要任何钩子或外部脚本。OpenClaw 的 workspace Skill 注入系统可以直接加载。

注意点：该 Skill 是 1:1 对话场景（Agent 问用户 → 用户答），在我们 Matrix 聊天场景中体验自然，甚至优于终端场景。

安装方式：clawhub install plan-interview 或自行写入 SKILL.md

2.3 intent-framed-agent（范围漂移监控）

结论：✅ 纯 Skill.md，可直接用

在执行开始时写一份意图契约（intent frame），然后每步自问「我还在目标范围内吗」。纯 Agent 行为规范，无需外部基础设施。

潜在问题：在 200K 上下文的 DeepSeek V4 Flash 上，意图帧的管理需要额外注意 token 消耗。但总体无技术障碍。

2.4 context-surfing（上下文健康监控）

结论：⚠️ 半兼容。核心逻辑可跑，但钩子依赖需要改造

这是最需要改造的一个 Skill，因为它高度依赖 Claude Code 的钩子系统：

改造方案：

1. handoff 检查 → 写一个 OpenClaw 内部钩子（handler.ts），挂载到 agent:bootstrap​ 事件，在 Agent 启动时扫描 .context-surfing/ 目录下的 handoff 文件并展示摘要
2. 上下文健康检查 → 从「钩子驱动」改成「SKILL.md 指令驱动」。在系统提示词中植入：代理周期性地在重大步骤后检查上下文占用情况，发现接近限额时主动要求用户开启新会话
3. 优雅退出机制 → 作为指令写入 SKILL.md：「如果感觉上下文饱满度过高，先在 .context-surfing/ 保存 handoff 文件，再提示用户开启新对话」

影响模块：

• 新增：~/.openclaw/hooks/context-surfing-handoff-check/（自定义钩子目录）
• 新增：.context-surfing/ 目录（handoff 文件存放）
• 修改：~/.openclaw/openclaw.json（启用 hooks.internal）

2.5 verify-gate（验证门）

结论：✅ Skill.md 即可。OpenClaw 的 exec 工具天然支持

Agent 在说「做好了」之前自动跑编译+测试+lint。在我们的场景中，OpenClaw 有 exec 工具可以直接跑 shell 命令，这套逻辑完全是 Agent 行为层面的——指令够了，不需要额外基建。

但注意：这个 Skill 假设工作目录在项目代码库中。如果我们只是聊天式调用 Agent（没有持续的项目工作目录），verify-gate 需要额外指定项目路径。

2.6 simplify-and-harden（质量审视）

结论：✅ 纯 Skill.md，可直接用

完成后的三轮自审（简化→加固→文档）。纯 Agent 行为规范，不需要钩子或外部工具。

注意点：在 200K 上下文下效果可能打折扣——修正的结果如果跨多轮对话，需要显式要求 Agent 在改动完成的那一轮直接完成所有审视，不要留到后续。

2.7 learning-aggregator（跨会话教训聚合）

结论：✅ 可直接用。建议改成定期任务

本质是让 Agent 读 .learnings/ 目录，做模式识别和晋升候选排序。在我们的场景中，可以用 OpenClaw 的 cron 定时任务来周期性触发：

{
  "cron": [
    {
      "name": "learning-aggregator",
      "schedule": { "kind": "cron", "expr": "0 9 * * 1", "tz": "Asia/Shanghai" },
      "payload": {
        "kind": "agentTurn",
        "message": "以 learning-aggregator 角色分析 .learnings/ 目录，按模式分组，推荐晋升候选人。"
      }
    }
  ]
}

安装方式：Skill.md 注入 + 可选 cron 任务

影响模块：

• 可选：openclaw.json 增加 cron 配置

2.8 harness-updater（教训规则化）

结论：⚠️ 半兼容。需要谨慎处理 AGENTS.md / SOUL.md / TOOLS.md 的自动编辑

核心功能是把聚合后的教训写入永久配置文件。在我们 OpenClaw 中：

• AGENTS.md ✅ 可写
• SOUL.md ✅ 可写（但涉及行为人格，自动添加需要谨慎）
• TOOLS.md ✅ 可写（工具备忘，自动添加安全）
• MEMORY.md ⚠️ 不是原始 Peter 体系的文件。我们需要决定是否支持写入

风险点：

1. 文件结构破坏——harness-updater 是在文件末尾追加，但如果文件格式要求 YAML frontmatter 等，需要确保追加不会破坏文件结构
2. 权限冲突——如果用户和 Agent 都在编辑同一个文件，可能产生冲突
3. 过度晋升——Agent 可能把偶发性错误推向全局规则（这是体系自有风险，不因平台而异）

改造方案：

• 在 SKILL.md 中明确定义写入规则，限定更新范围为文件末尾 Append-only
• 给 SOUL.md 写入加人工确认步（Agent 只能写建议，不自动修改）
• 建立「晋升提案 → 用户确认 → 应用」的三步流程

影响模块：

• workspace/AGENTS.md — 可能被追加内容
• workspace/SOUL.md — 建议只读
• workspace/TOOLS.md — 可安全追加
• workspace/MEMORY.md — 可额外追加（非体系必选）

2.9 eval-creator（回归测试生成）

结论：✅ 可以直接用。但 .evals/ 目录需要纳入版本管理

把晋升的规则变成永久的回归测试用例，放在 .evals/ 下。对 OpenClaw 没有特殊限制——纯文件操作。但注意：

• ​.evals/​ 里的测试需要运行环境支持（比如 verify-gate 的执行能力）
• 如果项目在本地开发机上而非当前服务器，需要路径映射

2.10 pre-flight-check（会话启动检查）

结论：⚠️ 半兼容。需要钩子适配

在每次会话启动时自动检查 .learnings/​ 和 .evals/ 的状态。Claude Code 下用 SessionStart 钩子实现。OpenClaw 中：

• 直接替代：写一个 OpenClaw 内部钩子绑定到 agent:bootstrap 事件
• 备选方案：将检查内容直接嵌入 SKILL.md 的「每次任务开始先做」指令中

改造方案：

• 创建 ~/.openclaw/hooks/pre-flight-check/​，handler.ts 监听 agent:bootstrap 事件
• 脚本读 .learnings/ 和 .evals/，生成摘要注入提示流

影响模块：

• 新增：自定义内部钩子目录
• 修改：openclaw.json 中 hooks.internal.enabled = true

2.11 skill-pipeline（全流程编排）

结论：✅ 可以用，但需调整「深度匹配」逻辑

根据任务大类自动选择 Skill 组合。本质是一个 SKILL.md 中的流程控制。问题在于：

• 它的任务分类（trivial / small / medium / large / long-running）在终端编码场景中有意义（typo fix vs feature dev）
• 在我们 Matrix 聊天场景中，Agent 不是 100% 编码任务，有时是调研、查询、写报告。需要补充这些任务类型的映射

改造方案：

• 下载 SKILL.md，根据我们的使用场景调整任务分类表
• 补充非编码类型的流程映射

2.12 CI 变体（-ci skills）

结论：❌ 不适用

这些是 GitHub Agentic Workflows 的 CI 流程，需要 gh-aw 环境。我们的 OpenClaw 是服务端聊天 Agent，没有 GitHub CI 管道。不适用，无需改造。

三、整体集成方案——如果你想用

3.1 推荐安装清单（渐进式）

3.2 需要修改/新增的 OpenClaw 模块

~/.openclaw/
├── openclaw.json  →  修改：启用 hooks 系统（+3-5 行配置）
├── hooks/         →  新增目录，包含：
│   ├── pre-flight-check/
│   │   ├── HOOK.md
│   │   └── handler.ts      # agent:bootstrap 事件 → 扫描 .learnings/ + .evals/
│   └── context-surfing-handoff/
│       ├── HOOK.md
│       └── handler.ts      # agent:bootstrap 事件 → 扫描 .context-surfing/ handoff
└── workspace/
    ├── .learnings/          →  新增目录（self-improvement 自动创建）
    │   ├── LEARNINGS.md
    │   ├── ERRORS.md
    │   └── FEATURE_REQUESTS.md
    ├── .evals/              →  可选目录（eval-creator 自动创建）
    │   ├── EVAL_INDEX.md
    │   └── cases/
    ├── .context-surfing/    →  可选目录（context-surfing 自动创建）
    └── skills/              →  增加新 Skill.md（如果从 ClawHub 装则自动放这里）

3.3 不需要改的模块

• 通道配置（Matrix）— 不受影响
• 模型配置 — Peter 的体系模型无关
• 内存/每日日志（MEMORY.md + memory/）— 两块记忆体系互补，不冲突
• 现有 Skills（故事、知识库等）— 互不干扰

3.4 协作方式变化

3.5 三个核心决策

1. 要不要让 Agent 自己改 SOUL.md？

• 建议：改 TOOLS.md 和 AGENTS.md 可以自动。SOUL.md（人格和行为准则）建议只生成建议草案，人工确认后再写入。 2. .learnings/ 要不要版本管理？

• 如果不跟代码仓库走，直接放在 workspace 下就行。

• 如果有项目代码库，建议放在项目根目录下，跨 Agent 共享教训。 3. cron 要跑多勤？

• learning-aggregator：每周一次（周一早晨北京时间）

• pre-flight-check：每次会话启动自动触发（钩子）
• eval-creator：晋升后即时触发，或每周一次

四、改造成本量级估算

五、一句话总结

这套体系和 OpenClaw 的契合度很强。 11 个核心 Skill 中 7 个「开箱即用」，3 个需要钩子适配（pre-flight-check, context-surfing, harness-updater 的自动写入），1 个不适用（CI 变体）。

最大的兼容性差异是钩子系统——Peter 的体系重度依赖 Claude Code 的 SessionStart / PostToolUse 钩子，而 OpenClaw 用 agent:bootstrap 事件 + 内联 SKILL.md 指令代替。需要自建 2-3 个 OpenClaw 原生钩子（handler.ts）来补齐。

但如果只装 Phase 0-2（self-improvement + verify-gate + simplify-and-harden），半小时内就能享受到 80% 的核心价值，零代码改造。