手把手教你在 OpenClaw 搭建技能进化工作流:把 SkillOpt 方法论落地-夜雨聆风

手把手教你在 OpenClaw 搭建技能进化工作流:把 SkillOpt 方法论落地

📌 技能推荐 | 上一期我们拆解了微软 SkillOpt 的四步进化循环，这篇就手把手教你在 OpenClaw 里把这个流程跑起来。不需要改框架源码，纯 Skill 配置就能实现。

前情回顾：SkillOpt 四步循环

如果你还没看过前一篇，核心就四步：

Rollout（执行记录） — Agent 跑任务，记录每一步
Reflect（分析成败） — 拆解成功/失败模式
Bounded Edit（小步修改） — 一次只改一个点
Gate（验证门控） — 改完先验证，没好就退回

这套方法论的精髓是：技能文档 = Agent 的外部可训练参数，它不该写一次就封存，而应该像训练神经网络一样不断迭代。

好，理论够了，来看怎么落地。

先看全貌：OpenClaw 里长什么样

┌────────────────────────────────────────────┐
│        技能进化工作流（全自动化）              │
├────────────────────────────────────────────┤
│                                            │
│  ① 定时任务触发 → ② Agent 跑任务并记日志    │
│  → ③ 分析日志找模式 → ④ 生成修改建议        │
│  → ⑤ 用验证集测试修改 → ⑥ 生效或退回        │
│                                            │
└────────────────────────────────────────────┘

下面一步步来拆解。

第零步：准备工作

你需要先建几个文件：

skills/my-agent/
├── SKILL.md              # 你的主技能文档（要进化的对象）
├── HISTORY.md             # 版本变更日志
├── validator/             # 验证集目录
│   ├── case-01.md
│   ├── case-02.md
│   └── ...
└── logs/                  # 执行日志（自动生成）

这不会动到 OpenClaw 框架，全是 Skill 层的事。

第一步：执行记录（Rollout）

目标

让每次 Agent 执行任务时，自动把关键信息写进日志。

做法

在你的主 Skill SKILL.md 里加上一段执行日志指令：

▪️ **记录执行日志**
每次执行关键步骤（工具调用、中间结果、最终输出），
同时追加写入 skills/my-agent/logs/exec-{YYYYMMDD}.md。
日志格式：
  - 时间戳：YYYY-MM-DD HH:mm
  - 用户输入：简要概括
  - 调用工具：<工具名>
  - 结果状态：✅ 成功 / ❌ 失败
  - 上下文备注：关键观察

💡 核心思想：日志不是给人看的，是给下一轮分析的 Agent 看的。所以格式要结构化、机器可读。

实操示例

跑 5 次任务后，日志文件大概长这样：

# 执行日志 2026-06-03

## 任务 1：用户想查 OpenClaw 最新版本
- 调用：web_search → 成功
- 结果：查到了 v2026.6.1
- 备注：搜索关键词准确，一次命中

## 任务 2：用户想生成一篇版本更新文章
- 调用：feishu_create_doc → 成功
- 调用：wenyan_publish → 失败
- 结果：文档已创建，发布时报错
- 备注：封面图 429 限速导致发布中断

第二步：分析成败（Reflect）

目标

定期分析日志，找出共性错误模式。

做法

创建一个分析 Skill，专门用于分析日志：

skills/my-agent/reflect.skill.md

▪️ **分析执行日志并生成改进建议**
你是一个技能进化分析师。

任务：
1. 读取日志目录 skills/my-agent/logs/ 下的最新日志
2. 统计成功/失败比例
3. 对失败案例做分类（如：网络错误、格式错误、逻辑错误）
4. 对成功案例提炼共同特征（如：哪个 Prompt 模板效果最好）
5. 输出一份分析报告，包含：
   - 总体成功率
   - Top 3 失败模式
   - Top 3 成功模式
   - 初步改进建议（仅限修改 1 个点）

关键原则

「分别分析」 很重要。不要笼统地说「效果不好」，要把成功和失败的样本拆开看：

失败样本 → 找共性错误（比如「封面图 URL 带 token 导致 429」）

成功样本 → 找可复用模式（比如「加特定关键词后搜索准确率翻倍」）

第三步：有边界的修改（Bounded Edit）

目标

根据分析结果，对主 Skill 做最小粒度的增删改。

做法

创建一个修改 Skill，专门执行「建议→改动」的转换：

skills/my-agent/edit.skill.md

▪️ **对主技能文档执行最小修改**
你是一个 Skill 文档编辑专家。

规则：
- 一次只修改 1 个点（遵循小步快跑原则）
- 修改前先完整读取 skills/my-agent/SKILL.md
- 修改后生成修改说明，追加写入 skills/my-agent/HISTORY.md
- 修改说明格式：

v1.3 → v1.4（2026-06-03）

修改点：为 web_search 步骤增加重试逻辑
原因：日志中 30% 失败由网络超时导致
效果待验证：等待验证集测试


⚠️ 禁止一次性修改多处！一次只改一个点。

实操原则

修改类型	例子	风险
新增规则	加一句「如果 429 则等待 5 秒重试」	🟢 低
删除冗余	去掉一个不必要的工具调用步骤	🟢 低
替换 Prompt	把「请生成文章」改成「请用营销风格生成文章」	🟡 中
重构流程	调整工具调用的先后顺序	🔴 高 — 建议实测后确认

推荐的修改节奏：每次只改前两列（新增规则和替换 Prompt），改完一轮后再考虑重构。

第四步：验证门控（Gate）

目标

修改后的技能必须跑一遍验证集，效果没变好就退回。

做法

准备几个验证用例，放 validator/ 目录：

skills/my-agent/validator/case-01.md

# 验证用例 1：版本查询
用户输入：「OpenClaw 现在最新版本是多少？」
期望行为：
1. 调用 web_search 搜索 GitHub Release
2. 返回版本号 + 发布日期
3. 如果 429 限速，自动切换备用 URL

skills/my-agent/validator/case-02.md

# 验证用例 2：文章生成
用户输入：「写一篇 v2026.6.1 的版本更新文章」
期望行为：
1. 获取版本更新内容
2. 生成符合营销风格的 Markdown
3. 创建飞书文档
4. 发布到公众号草稿箱

然后创建验证 Skill：

skills/my-agent/validate.skill.md

▪️ **运行验证集并评估修改效果**
你是一个验证测试工程师。

任务：
1. 用修改后的 SKILL.md 依次执行所有验证用例
2. 对照每个用例的「期望行为」逐项检查
3. 输出验证报告：
   - 通过数 / 总数
   - 每项：✅ 完全通过 / ⚠️ 部分通过 / ❌ 未通过
   - 失败原因分析

规则：
- 如果通过率下降 → 标记为「退回」，撤回归改前版本（从 HISTORY.md 恢复）
- 如果通过率不变 → 标记为「持平」，可选择退回或保留
- 如果通过率提升 → 标记为「生效」，确认保留修改
- 被退回的修改记录到 HISTORY.md 的「退回记录」区

把它们串起来：一个 Cron 搞定

有了上面四个 Skill，你只需要一个 OpenClaw Cron 定时任务 把它们串起来：

每天早上 8:00：
  ① 读取昨日日志（rollout）
  ② 分析日志生成改进建议（reflect）
  ③ 执行最小修改（edit）
  ④ 跑验证集测试（validate）
  ⑤ 回写修改结果到 HISTORY.md

Cron 配置

# 添加到 openclaw cron
schedule: "0 8 * * 1-5"     # 工作日早上 8 点
sessionTarget: "isolated"
prompt: >
  执行技能进化工作流：
  1. 读取 skills/my-agent/ 下所有文件
  2. 按 reflect → edit → validate 顺序执行
  3. 将本次进化报告输出到 skills/my-agent/HISTORY.md
  4. 如果验证通过率提升，保留修改；否则退回

注意：第一次建议手动跑，确认流程无误后再开自动化。

完整工作流一图流

每天 8:00 Cron 触发
        │
        ▼
┌────────────────┐
│  ① Rollout     │  ← 读取昨日日志（已由 Agent 执行时自动记录）
│  执行记录       │
└───────┬────────┘
        ▼
┌────────────────┐
│  ② Reflect     │  ← 分析日志，找失败模式 + 成功模式
│  分析成败       │
└───────┬────────┘
        ▼
┌────────────────┐
│  ③ Bounded Edit│  ← 一次只改 1 个点，记录到 HISTORY
│  小步修改       │
└───────┬────────┘
        ▼
┌────────────────┐
│  ④ Gate        │  ← 跑验证集，通过率提升才保留
│  验证门控       │
└───────┬────────┘
        │
        ├─ ✅ 通过 → 保留修改，SKILL.md 更新为 v1.x
        └─ ❌ 退回 → HISTORY.md 记录退回原因，SKILL.md 回滚

进阶玩法

多级验证集

validator/
├── quick/          # 快速验证（3 个基础用例，每次必跑）
├── full/           # 完整验证（10 个覆盖用例，每周跑一次）
└── stress/         # 压力测试（边缘场景，大版本更新前跑）

日常进化用 quick 集（3 分钟跑完），周度深度检查用 full 集。

负例记忆

被退回的修改不要删，保留在 HISTORY.md 的「退回记录」区：

## 退回记录
- v1.2→v1.3（2026-06-01）：尝试增加冗余重试逻辑，
  导致 Agent 在简单任务上过度思考。验证通过率从 80%→65%。
  教训：重试应在工具层处理，不在 Skill 层加。

下次 Reflect 分析时，Agent 可以读到退回记录，避免重复踩坑。

跨 Skill 进化

如果你的 Agent 有多个 Skill，可以把所有日志聚合到同一个分析 Skill：

reflect 分析日志时：
  - Skill A 日志 → 改进 SKILL_A.md
  - Skill B 日志 → 改进 SKILL_B.md
  - 跨 Skill 失败模式 → 添加全局规则到系统 Prompt

最后说几句

这套工作流的核心理念就一句话：

技能文档不是静态说明书，Agent 跑得越多，它越应该自己变强。

你不需要改 OpenClaw 源码，也无需部署额外服务——就靠 Skill 配置 + Cron，就能把 SkillOpt 的进化方法论变成日常习惯。

前一篇我们说「下一期聊聊怎么在 OpenClaw 里搭建这个工作流」——话兑现了 🖐️

本文由 OpenClaw 研习社出品，带你用好 OpenClaw，用好 AI。
📮 关注我们，获取更多 AI 工具使用技巧。