目录:

在上一篇文章中，我从 Karpathy 的 autoresearch 项目提炼了一个范式：人写规则，Token 做实验。我们用 AI 客服 Prompt 优化作为案例，验证了这个范式在业务场景中的可行性。但那个方案有一个前提——你需要预先准备评估数据集。

OpenClaw 的场景让我意识到，还有一种更彻底的可能：Agent 用自己的真实执行数据作为评估信号，在用户无感知的情况下持续自我优化。 不需要人工标注测试集，不需要离线批处理，每一次真实使用都是一条训练数据。

从 autoresearch 到自优化 Agent

先回顾 autoresearch 的核心循环：

1
2
3
4
5
6
人写 program.md（策略）
    → AI 修改 train.py（假设）
    → 跑 5 分钟训练（实验）
    → 检查 val_bpb（评估）
    → 保留或回滚（决策）
    → 重复

这个范式能 work 需要五个前提条件（详见#147）：指标可量化、反馈快、搜索空间有约束、变异智能、成本低可逆。

AI 客服 Prompt 优化满足全部五个条件，但它本质上是一个离线批处理流程——你需要先准备好评估数据集，然后一夜跑 500 轮。这对于 OpenClaw 这样的个人 AI 助手来说不太自然：你不会为”帮我搜新闻”、“帮我发消息”这些日常任务预先标注 500 条测试用例。

但换个角度想：OpenClaw 每天都在执行真实任务，每次执行都有可观测的结果。 这些真实执行记录，天然就是评估数据集。

OpenClaw 已经具备的基础设施

对照 autoresearch 的三个核心文件，OpenClaw 不需要额外建设任何东西：

autoresearch

OpenClaw 已有

作用

prepare.py — 评估工具

会话记录 + memory 日志

真实任务执行的完整历史

train.py — 被修改的代码

SKILL.md — 技能定义

Agent 可自主修改的执行逻辑

program.md — 人定义策略

SOUL.md — 行为宪法

定义优化方向和不可逾越的边界

更关键的是，OpenClaw 还有两个 autoresearch 没有的东西：

Heartbeat 机制——每 30 分钟一次的主动检查周期，天然就是优化循环的触发器。不需要额外写 while True 循环。

Memory 系统——两层记忆架构（每日日志 + 长期记忆）天然就是实验日志的存储。不需要额外建数据库。

核心设计：Per-Skill 优化

OpenClaw 的任务是多样化的——搜索新闻、写代码、发消息、分析数据。不可能用一个 val_bpb 衡量所有任务。

解法是：每个 Skill 独立优化，各有各的指标。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
workspace/skills/
├── search-and-summarize/
│   ├── SKILL.md            ← 被优化的对象
│   ├── eval/
│   │   ├── cases.jsonl     ← 从真实执行中自动积累
│   │   └── metrics.json    ← 当前指标基线
│   └── experiments/
│       └── log.md          ← 实验日志
│
├── code-review/
│   ├── SKILL.md
│   ├── eval/
│   └── experiments/
│
└── report-generation/
    ├── SKILL.md
    ├── eval/
    └── experiments/

每个 Skill 的优化指标由 Skill 自身定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# SKILL.md — search-and-summarize

## 执行逻辑
搜索 5 个数据源，提取关键信息，生成结构化简报...

## 自优化配置
metrics:
  - name: coverage      # 信息覆盖率
    weight: 0.5
    judge: "对比源文档，评估简报是否覆盖了核心信息"
  - name: conciseness   # 简洁度
    weight: 0.3
    judge: "评估简报是否简洁，无冗余信息"
  - name: actionability # 可操作性
    weight: 0.2
    judge: "评估简报是否包含可行动的要点"

baseline_score: 0.72
target_score: 0.85

指标的评估方式是 LLM-as-Judge——用另一个 LLM（或同一个 LLM 的独立调用）来评分。这和 autoresearch 中 val_bpb 的作用完全等价，只是从数学指标变成了语义评分。

数据从哪来：执行即评估

这是 OpenClaw 自优化和 AI 客服 Prompt 优化的最大区别：不需要预先准备评估数据集。

每次任务执行时，自动记录：

1
2
3
4
5
6
7
8
9
10
{
  "skill": "search-and-summarize",
  "timestamp": "2026-03-21T09:15:00Z",
  "input": "搜索今天的 AI 技术新闻",
  "output": "1. OpenAI 发布... 2. Google 宣布...",
  "sources_used": ["techcrunch", "arxiv", "twitter"],
  "token_cost": 2847,
  "user_signal": "follow_up_question",
  "execution_time_ms": 12400
}

user_signal 是隐式反馈，不需要用户主动评分：

用户行为

信号解读

评分

没有追问，直接转到下一话题

满意

+1

追问细节（“XX 的具体数据呢？”）

覆盖率不足

0

否定（“不对”、“重新搜”）

执行失败

-1

说”记住这个”

高质量输出

+2

这些执行记录积累到 eval/cases.jsonl，构成该 Skill 的评估数据集。用了就有数据，用得越多数据越好。

优化循环：复用 Heartbeat

不需要额外构建优化循环。在现有的 Heartbeat 机制中增加一个检查项：

1
2
3
4
5
6
7
8
9
10
11
# HEARTBEAT.md

## 常规检查
- [ ] 检查未读消息
- [ ] 检查日历事件
- [ ] 检查 GitHub 通知

## Skill 自优化（每 4 次心跳执行一次）
- [ ] 回顾最近 24 小时的任务执行日志
- [ ] 识别表现最差的 Skill（失败率最高或用户负反馈最多）
- [ ] 如果该 Skill 的 eval cases ≥ 10 条，执行一轮优化实验

完整的优化流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Heartbeat 触发（每 30 分钟）
    │
    ▼
回顾最近的任务执行日志
    │
    ▼
按 Skill 聚合表现数据
    │
    ├── search-and-summarize: 成功率 70%, 追问率 40%
    ├── code-review: 成功率 90%, 追问率 10%
    └── dingtalk-messaging: 成功率 95%, 追问率 5%
    │
    ▼
选择表现最差的 Skill（search-and-summarize）
    │
    ▼
分析失败模式
    │
    ├── 5 次追问中有 4 次是"具体数据呢？"
    └── 结论：输出缺少定量信息
    │
    ▼
提出修改假设：在 SKILL.md 中增加规则
"每条摘要必须包含至少一个数字（金额/百分比/日期）"
    │
    ▼
用最近 10 条 eval cases 回放测试
    │
    ├── 修改前综合评分：0.72
    └── 修改后综合评分：0.81
    │
    ▼
评分提升 → 保留修改，更新 baseline_score
写入 experiments/log.md：
  "轮次 #7: 增加定量信息要求，评分 0.72→0.81，保留"

整个过程在一次 Heartbeat 周期内完成。用户不会收到任何通知（因为 Agent 回复 HEARTBEAT_OK），但下次搜索新闻时，简报质量已经提升了。

具体例子：AI 新闻简报的自我进化

抽象的流程图不如一个活生生的例子。假设 OpenClaw 有一个 search-and-summarize Skill，用来搜索 AI 新闻并生成简报。让我们完整跟踪它从”勉强能用”到”用户满意”的进化过程。

Day 1：初始版本

用户安装了 search-and-summarize Skill，初始的 SKILL.md 非常朴素：

1
2
3
4
5
6
7
8
9
10
# search-and-summarize

## 触发条件
用户要求搜索新闻、行业动态、技术趋势时触发。

## 执行逻辑
1. 使用 tavily-search 工具搜索用户指定的主题
2. 从搜索结果中提取前 5 条最相关的内容
3. 为每条结果生成摘要
4. 按相关性排序后输出

用户发了第一条指令：

用户：搜索今天的 AI 技术新闻

Agent 输出：

1
2
3
4
5
1. OpenAI 宣布了新的模型更新计划
2. Google DeepMind 发表了一篇关于多模态学习的论文
3. Meta 开源了新的代码生成工具
4. 英伟达发布了新一代 GPU 架构
5. 一家初创公司获得了大额融资

用户看完后追问：

用户：OpenAI 具体更新了什么？融资那个是哪家公司，多少钱？

这两次追问被自动记录为 user_signal: "follow_up_question"，写入 eval/cases.jsonl。

Day 2 心跳轮次 #1：诊断”信息太薄”

下一次 Heartbeat 触发时，Agent 回顾最近的执行日志：

1
2
3
4
5
6
7
分析最近 24 小时 search-and-summarize 执行记录：
- 共执行 3 次
- 2 次被追问细节（追问率 67%）
- 追问内容分析：
  - "具体更新了什么？" → 缺少细节
  - "哪家公司，多少钱？" → 缺少关键数据点
- 结论：摘要过于笼统，缺少定量信息和关键细节

Agent 提出假设并修改 SKILL.md：

1
2
3
4
5
6
7
## 执行逻辑
1. 使用 tavily-search 工具搜索用户指定的主题
2. 从搜索结果中提取前 5 条最相关的内容
3. 为每条结果生成摘要，**每条摘要必须包含：**
   - **至少一个具体数字**（金额、百分比、日期、版本号）
   - **关键实体的全称**（公司名、产品名、人名）
4. 按相关性排序后输出

用最近 3 条真实 case 回放测试，LLM-as-Judge 评分：

指标

修改前

修改后

信息覆盖率

0.60

0.78

简洁度

0.80

0.72

综合

0.68

0.76

覆盖率大幅提升，简洁度略降但综合分上升。保留修改。

Day 3 用户再次使用——效果已经不同

用户：搜索今天的 AI 新闻

Agent 输出：

1
2
3
4
5
6
7
8
9
10
1. OpenAI 发布 GPT-5 Turbo（3月22日），推理速度提升 40%，
   API 定价降至 $2/M tokens
2. Google DeepMind 在 Nature 发表 Gemini 2.5 多模态论文，
   在 12 个基准测试中刷新 SOTA
3. Meta 开源 Code Llama 3（70B 参数），
   HumanEval 得分 89.2%
4. 英伟达发布 Blackwell Ultra 架构，
   单卡 FP8 算力达 20 PFLOPS，预计 Q3 量产
5. 法国初创公司 Mistral 完成 6.4 亿美元 C 轮融资，
   估值 60 亿美元

这次用户没有追问，直接转到了下一个话题。记录为 user_signal: "satisfied"。

Day 5 心跳轮次 #3：发现”太长了”

经过几天使用，新的模式浮现：

1
2
3
4
5
6
分析最近 72 小时 search-and-summarize 执行记录：
- 追问率从 67% 降到 15% ✅（轮次 #1 的修改有效）
- 新问题：用户 3 次对话中有 2 次只回复了前 2 条的内容
  → 推测用户没有读完全部 5 条
- 平均每条摘要 45 字，总输出 225 字
- 结论：信息密度足够，但格式不利于快速扫读

Agent 提出假设：增加”一句话要点”（TL;DR）在最前面：

1
2
3
## 输出格式
**先输出一句话总结**（20 字以内），概括今天最值得关注的一件事。
然后输出 5 条详细摘要，每条包含具体数字和关键实体。

回放测试：

指标

修改前

修改后

信息覆盖率

0.78

0.75

简洁度

0.72

0.85

可操作性

0.60

0.78

综合

0.72

0.79

简洁度和可操作性显著提升，覆盖率几乎不变。保留修改。

Day 8 心跳轮次 #6：一次失败的尝试

Agent 注意到用户主要关注 LLM 和 Agent 领域的新闻，尝试增加个性化排序：

1
2
3
## 排序策略
根据用户历史关注领域（从 MEMORY.md 读取），
优先展示匹配度高的新闻，低匹配的放在末尾。

回放测试发现问题——一条关于芯片出口管制的重要新闻因为”不在用户关注领域”被排到最后，但这条新闻实际上对整个 AI 行业影响巨大。LLM-as-Judge 的覆盖率评分反而下降了。

指标

修改前

修改后

信息覆盖率

0.75

0.68

综合

0.79

0.74

回滚。 记录失败原因：“个性化排序会导致重要但跨领域的信息被降权，信息茧房风险。”

Day 10 心跳轮次 #8：修正方案

从上次失败中学到了教训，Agent 换了一个更温和的方案：

1
2
3
4
5
## 排序策略
按新闻重要性排序（影响面 × 时效性）。
在每条摘要末尾用标签标注与用户关注领域的相关性：
[直接相关] [间接相关] [行业背景]
不删除、不降权任何类别。

回放测试：

指标

修改前

修改后

信息覆盖率

0.75

0.76

可操作性

0.78

0.86

综合

0.79

0.83

标签让用户可以快速定位自己关心的内容，同时不丢失任何信息。保留。

Day 14：对比 Day 1

两周后的 SKILL.md 已经和最初版本完全不同。把 Day 1 和 Day 14 的输出放在一起看：

Day 1 输出：

1
2
3
4
5
1. OpenAI 宣布了新的模型更新计划
2. Google DeepMind 发表了一篇关于多模态学习的论文
3. Meta 开��了新的代码生成工具
4. 英伟达发布了新一代 GPU 架构
5. 一家初创公司获得了大额融资

Day 14 输出：

1
2
3
4
5
6
7
8
9
10
11
12
💡 今日要点：OpenAI 发布 GPT-5 Turbo，API 降价 60%

1. OpenAI 发布 GPT-5 Turbo（3/22），推理速度 +40%，
   API 定价 $2/M tokens [直接相关]
2. Google DeepMind 在 Nature 发表 Gemini 2.5 多模态论文，
   12 项基准 SOTA [直接相关]
3. 美国商务部拟扩大 AI 芯片出口管制范围，
   涉及 14nm 以下制程 [行业背景]
4. Meta 开源 Code Llama 3（70B），
   HumanEval 89.2% [直接相关]
5. Mistral 完成 6.4 亿美元 C 轮，
   估值 60 亿美元 [间接相关]

同一个 Skill，同一类查询，但输出质量从勉强能用变成了信息密度高、结构清晰、快速可扫读。用户全程没有手动修改过任何配置。

完整的进化轨迹

把上面的具体例子压缩成时间线，可以更清晰地看到优化的节奏和效果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Day 1  SKILL.md v1: 朴素版本，5 条无细节摘要
       baseline: 0.58
       ──────────────────────────────────────────

Day 2  轮次 #1: 追问率 67% → 增加定量信息和实体全称
       eval: 0.68 → 0.76 ✅ 保留

Day 5  轮次 #3: 用户不读完全部 → 增加一句话要点 + 精简格式
       eval: 0.72 → 0.79 ✅ 保留

Day 8  轮次 #6: 尝试个性化排序 → 跨领域重要新闻被降权
       eval: 0.79 → 0.74 ❌ 回滚（信息茧房风险）

Day 10 轮次 #8: 改为标注相关性标签但不排除
       eval: 0.79 → 0.83 ✅ 保留

Day 14 SKILL.md v5: 经过 8 轮实验，5 次保留 3 次回滚
       current: 0.83 (+43% vs Day 1)
       ──────────────────────────────────────────

注意 Day 8 的回滚——这不是失败，而是系统在正常工作。有效的自优化必须包含”变差就回滚”的机制，否则就不是优化，而是随机漂移。回滚记录下的失败原因（“信息茧房风险”）还会成为后续轮次的参考，让 Agent 在 Day 10 找到了更好的方案。

安全边界：SOUL.md 作为宪法

自优化不是无约束的。就像 autoresearch 中 Agent 不能修改 prepare.py，OpenClaw 的自优化也有不可触碰的边界：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# SOUL.md — 自优化约束

## 不可修改的规则
- 永远不要在未经确认的情况下发送消息给第三方
- 永远不要删除用户的文件
- 永远不要在群聊中暴露用户的私人信息
- 搜索结果必须标注来源

## 自优化边界
- 每次只修改一个 Skill 的一个方面
- 修改后必须回放至少 10 条历史 case
- 评分下降超过 5% 必须立即回滚
- 每天最多执行 3 轮优化实验
- 所有修改记录在 experiments/log.md 中，用户可审计

SOUL.md 定义了优化的”宪法”——Agent 可以在边界内自由探索，但不能逾越红线。这和 autoresearch 中 program.md 的角色完全一致。

与 autoresearch 的对比

维度

autoresearch

AI 客服 Prompt 优化

OpenClaw Skill 自优化

被优化对象

train.py

system_prompt.txt

SKILL.md（多个）

评估数据

固定验证集

人工标注测试集

真实执行历史（自动积累）

优化频率

5 分钟/轮

30 秒/轮（批处理）

30 分钟/轮（持续）

触发方式

while True 循环

一夜批跑

Heartbeat 自然触发

冷启动

无需（数据内置）

需要准备测试集

使用几天后自动具备

优化信号

数学指标

LLM-as-Judge

用户隐式反馈 + LLM-as-Judge

用户参与

写 program.md

写优化策略

正常使用即可（零参与）

最后一行是关键区别：OpenClaw 的用户不需要做任何额外的事情。 正常使用 = 提供优化信号。这是最低摩擦的自优化方案。

更深一层：三代优化范式

回顾整个演进，我们实际上在看三代不同的优化范式：

第一代：人工优化

1
2
人观察 → 人假设 → 人实施 → 人评估 → 人决策
周级循环，依赖专家经验

第二代：Token 批处理优化（autoresearch / AI 客服）

1
2
人定义规则 → AI 假设 → AI 实施 → AI 评估 → AI 决策
分钟级循环，依赖预设的评估数据集

第三代：Agent 自闭环优化（OpenClaw）

1
2
3
人定义边界 → AI 执行真实任务 → 真实反馈自动积累
→ AI 假设 → AI 用真实数据评估 → AI 决策
持续循环，无需额外数据准备

第三代的本质突破在于：评估数据不是人准备的，而是系统在正常运行中自然产生的。 这消除了自优化最大的冷启动障碍。

用一个类比：

  • 第一代像手动驾驶——人控制一切
  • 第二代像自动驾驶测试——在封闭赛道上自动跑圈
  • 第三代像特斯拉的影子模式——在真实道路上收集数据，持续改进

实施建议

如果你想在类似 OpenClaw 的 Agent 系统中实现自优化，建议分三步走：

第一步：先记录，不优化。 在每次 Skill 执行后记录输入、输出、用户后续行为。积累两周数据，建立基线。

第二步：手动分析，验证指标。 人工审查执行日志，确认你定义的指标（覆盖率、简洁度等）确实和用户满意度相关。如果指标和真实满意度不相关，优化就是南辕北辙。

第三步：开启自动优化，保持可审计。 每天最多 2-3 轮实验，所有修改记录在 experiments/log.md 中。定期人工审查实验日志，确保优化方向没有偏离。

不要急于全自动。 第二步的人工验证至关重要——它确保你的指标是对的。一个错误的指标会让 Agent 越优化越差，就像用错误的 val_bpb 会让 autoresearch 训出垃圾模型一样。

写在最后

autoresearch 证明了”用 Token 替代人做试错循环”是可行的。AI 客服 Prompt 优化证明了这个范式可以迁移到业务场景。而 OpenClaw 的 Skill 自优化展示了一种更进一步的可能：

Agent 不仅能替人做实验，还能从自己的工作中自动获取评估信号。

当执行和评估在同一个系统中闭环，自优化就不再是一个需要单独启动的流程，而是系统运行的自然副产品。你的 AI 助手每天在帮你工作的同时，也在悄悄地让自己变得更好。

这是 autoresearch 范式的终极形态——不是”一夜跑 500 轮实验”，而是”每一天的使用都是一轮实验”。

AI  AI-agents  OpenClaw  architecture  autoresearch  prompt-engineering  best-practices 

原文链接: 自我进化的AI助手：OpenClaw如何用Heartbeat实现Skill自动优化