目录:
在上一篇文章中，我从 Karpathy 的 autoresearch 项目提炼了一个范式：人写规则，Token 做实验。我们用 AI 客服 Prompt 优化作为案例，验证了这个范式在业务场景中的可行性。但那个方案有一个前提——你需要预先准备评估数据集。
OpenClaw 的场景让我意识到，还有一种更彻底的可能：Agent 用自己的真实执行数据作为评估信号，在用户无感知的情况下持续自我优化。 不需要人工标注测试集，不需要离线批处理，每一次真实使用都是一条训练数据。
从 autoresearch 到自优化 Agent
先回顾 autoresearch 的核心循环：
人写 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 独立优化，各有各的指标。
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 自身定义：
# 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 优化的最大区别：不需要预先准备评估数据集。
每次任务执行时，自动记录：
{
"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 机制中增加一个检查项：
# HEARTBEAT.md
## 常规检查
- [ ] 检查未读消息
- [ ] 检查日历事件
- [ ] 检查 GitHub 通知
## Skill 自优化（每 4 次心跳执行一次）
- [ ] 回顾最近 24 小时的任务执行日志
- [ ] 识别表现最差的 Skill（失败率最高或用户负反馈最多）
- [ ] 如果该 Skill 的 eval cases ≥ 10 条，执行一轮优化实验
完整的优化流程：
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 非常朴素：
# search-and-summarize
## 触发条件
用户要求搜索新闻、行业动态、技术趋势时触发。
## 执行逻辑
1. 使用 tavily-search 工具搜索用户指定的主题
2. 从搜索结果中提取前 5 条最相关的内容
3. 为每条结果生成摘要
4. 按相关性排序后输出
用户发了第一条指令：
用户：搜索今天的 AI 技术新闻
Agent 输出：
1. OpenAI 宣布了新的模型更新计划
2. Google DeepMind 发表了一篇关于多模态学习的论文
3. Meta 开源了新的代码生成工具
4. 英伟达发布了新一代 GPU 架构
5. 一家初创公司获得了大额融资
用户看完后追问：
用户：OpenAI 具体更新了什么？融资那个是哪家公司，多少钱？
这两次追问被自动记录为 user_signal: "follow_up_question"，写入 eval/cases.jsonl。
Day 2 心跳轮次 #1：诊断"信息太薄”
下一次 Heartbeat 触发时，Agent 回顾最近的执行日志：
分析最近 24 小时 search-and-summarize 执行记录：
- 共执行 3 次
- 2 次被追问细节（追问率 67%）
- 追问内容分析：
- "具体更新了什么？" → 缺少细节
- "哪家公司，多少钱？" → 缺少关键数据点
- 结论：摘要过于笼统，缺少定量信息和关键细节
Agent 提出假设并修改 SKILL.md：
## 执行逻辑
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. 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：发现"太长了"
经过几天使用，新的模式浮现：
分析最近 72 小时 search-and-summarize 执行记录：
- 追问率从 67% 降到 15% ✅（轮次 #1 的修改有效）
- 新问题：用户 3 次对话中有 2 次只回复了前 2 条的内容
→ 推测用户没有读完全部 5 条
- 平均每条摘要 45 字，总输出 225 字
- 结论：信息密度足够，但格式不利于快速扫读
Agent 提出假设：增加"一句话要点"（TL;DR）在最前面：
## 输出格式
**先输出一句话总结**（20 字以内），概括今天最值得关注的一件事。
然后输出 5 条详细摘要，每条包含具体数字和关键实体。
回放测试：
| 指标 | 修改前 | 修改后 |
|---|---|---|
| 信息覆盖率 | 0.78 | 0.75 |
| 简洁度 | 0.72 | 0.85 |
| 可操作性 | 0.60 | 0.78 |
| 综合 | 0.72 | 0.79 |
简洁度和可操作性显著提升，覆盖率几乎不变。保留修改。
Day 8 心跳轮次 #6：一次失败的尝试
Agent 注意到用户主要关注 LLM 和 Agent 领域的新闻，尝试增加个性化排序：
## 排序策略
根据用户历史关注领域（从 MEMORY.md 读取），
优先展示匹配度高的新闻，低匹配的放在末尾。
回放测试发现问题——一条关于芯片出口管制的重要新闻因为"不在用户关注领域"被排到最后，但这条新闻实际上对整个 AI 行业影响巨大。LLM-as-Judge 的覆盖率评分反而下降了。
| 指标 | 修改前 | 修改后 |
|---|---|---|
| 信息覆盖率 | 0.75 | 0.68 |
| 综合 | 0.79 | 0.74 |
回滚。 记录失败原因：“个性化排序会导致重要但跨领域的信息被降权，信息茧房风险。”
Day 10 心跳轮次 #8：修正方案
从上次失败中学到了教训，Agent 换了一个更温和的方案：
## 排序策略
按新闻重要性排序（影响面 × 时效性）。
在每条摘要末尾用标签标注与用户关注领域的相关性：
[直接相关] [间接相关] [行业背景]
不删除、不降权任何类别。
回放测试：
| 指标 | 修改前 | 修改后 |
|---|---|---|
| 信息覆盖率 | 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. OpenAI 宣布了新的模型更新计划
2. Google DeepMind 发表了一篇关于多模态学习的论文
3. Meta 开源了新的代码生成工具
4. 英伟达发布了新一代 GPU 架构
5. 一家初创公司获得了大额融资
Day 14 输出：
💡 今日要点：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，同一类查询，但输出质量从勉强能用变成了信息密度高、结构清晰、快速可扫读。用户全程没有手动修改过任何配置。
完整的进化轨迹
把上面的具体例子压缩成时间线，可以更清晰地看到优化的节奏和效果：
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 的自优化也有不可触碰的边界：
# 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 的用户不需要做任何额外的事情。 正常使用 = 提供优化信号。这是最低摩擦的自优化方案。
更深一层：三代优化范式
回顾整个演进，我们实际上在看三代不同的优化范式：
第一代：人工优化
人观察 → 人假设 → 人实施 → 人评估 → 人决策
周级循环，依赖专家经验
第二代：Token 批处理优化（autoresearch / AI 客服）
人定义规则 → AI 假设 → AI 实施 → AI 评估 → AI 决策
分钟级循环，依赖预设的评估数据集
第三代：Agent 自闭环优化（OpenClaw）
人定义边界 → 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 轮实验"，而是"每一天的使用都是一轮实验"。