作者：傅榕锋 OceanBase 高级技术专家，seekdb M0 研发团队负责人

过去一年，Agent 的能力进步很快。但真正进入生产场景后，一个问题越来越明显：很多任务明明做成功过一次，下一次遇到相似目标，还是像冷启动一样重新摸索。执行路径不会明显收敛，踩过的坑也很难稳定绕开。

这说明问题往往不在于 Skill 不够多，而是系统缺少一套把成功轨迹沉淀成可复用能力的机制。上个月，seekdb M0 先解决了跨 session 记忆的问题
。这一次，我们进一步把经验拆成了 Experience + Skill，目标不是让 Agent 记住更多历史，而是让它从过去的工作中真正学到东西。简单说，上一个版本解决的是“别忘了”，这一次解决的是“要学会”。

如果这套设计有效，那么价值就不该只体现在记住了什么，而应该体现在真实任务里能不能做得更好、更快、更省。基于这个判断，我们把验证放到了更接近真实工作的 AppWorld 上。

先放结论。我们在 AppWorld（一个业界公认很难的 Agent benchmark）上做了严格对照实验：

• 同一份蒸馏源数据，分别喂给 M0 和 Hermes原生方案
• GPT-4o 通过率从 24% 提升到 39%（相对 +62%）
• 平均步数从 9.5 步降到 6.2 步（-35%）
• Token 消耗从 2.56M 降到 1.74M（-32%）

下面讲讲我们为什么要把「经验」这件事重新想一遍。

从 locomo 到 AppWorld：陪聊型 Agent 和干活型 Agent 是两回事

先说为什么要跑 AppWorld 测试。

M0 早期版本一直在 locomo 上跑。locomo 是一个对话记忆的 benchmark——用户和 agent 聊一段时间，之后能不能正确回忆起之前聊过的事。这种测试对「陪聊型」agent 有意义，但不适合今天的 OpenClaw、Hermes Agent 这类工作型 agent。

工作型 agent 的特点是：不是陪你聊天，而是帮你干活。干活意味着调工具、多步推理、处理 API 返回的结构化数据。一个「能记住你上周说过你喜欢 TypeScript」的 agent，和一个「能帮你在 Spotify 上建一个Taylor Swift歌单」的 agent，评估维度完全不同。

AppWorld 就是为后者设计的。它模拟了 9 个日常应用（相当于音乐、笔记、购物、社交这类），提供 457 个 API，以及 750 个自然任务。

举个例子。任务是「帮我建一个Taylor Swift歌单」，Agent 至少要完成六步：

1. 登录 Spotify 账号（类似于国内网易云音乐等音乐应用）
2. 搜索「Taylor Swift」
3. 过滤出真正是Taylor Swift的结果（搜索结果里可能混着歌名包含「Taylor Swift」的别人的歌）
4. 翻页收集更多结果（搜索接口通常是分页的）
5. 创建空歌单
6. 把歌一首首加进去

每一步都有坑。搜索结果的字段判别、分页逻辑、加歌时要不要跳过需要会员的歌曲——这些不是 skill 文档里写了就能解决的，是实战经验。

AppWorld 难在哪？它的评测是基于状态的单元测试——不只看最后输出对不对，还要检查有没有产生意外副作用（比如把人家原有歌单搞乱了）。而且它允许多种完成路径，不是死记硬背接口就能过。

GPT-4o 裸跑 AppWorld，通过率不到 10%。加上 ReAct 提示词工程，通过率 24%。2024 年论文发布时，这已经是 SOTA。换句话说：这个 benchmark 很难，以前大家不太敢跑。

经验是什么，为什么要拆

M0 早期版本里，「经验」是一个统一概念。跑真实工作流时我们发现，这个词实际上包装了两种性质完全不同的东西。

看两条经验：

经验 A：「Spotify 的列表接口（show_song_library / show_album_library / show_playlist_library）都需要分页，page_limit 默认只有 5，必须显式设为 20。循环调用，直到返回空列表才能拿到全部数据。」（这条经验在 M0 中存为结构化 Skill，包含 4 个步骤和 2 个坑点）

经验 B：「要找用户播放最多的 R&B 歌曲，不能只查歌曲库——还需要从专辑库和播放列表库分别收集 song_id，去重后逐个调 show_song 获取 genre 和 play_count 字段。只查 show_song_library 会漏掉大量歌曲。」

两条经验讲的是同一个领域（Spotify 歌曲查询），但性质完全不同。

经验 A 是操作级知识——告诉你「这个 API 具体怎么调、有什么坑」。它天然有结构：步骤（初始化参数→调用→判断→循环）、坑点（page_limit 默认值太小）。它跨用户通用，适合共享。

经验 B 是策略级知识——告诉你「这件事该怎么做」。它不涉及具体的参数和返回值，而是引导整体方向：要查三个库、要去重、要逐个查详情。没有这个策略，Agent 会漏查专辑和播放列表里的歌，导致结果不完整。

把这两种东西塞进同一个池子，会出两个实际问题：

检索信号互相干扰。 操作级知识往往很长（一个完整的 Spotify 登录+分页流程可能有十几行代码示例），策略级知识很短。向量检索时，长文本的语义特征更丰富，容易挤掉真正需要的短策略。

上下文管理失控。 我们在测试中观察到一个反直觉的现象：把完整的操作手册一次性塞进 Agent 的上下文，GPT-4o 的表现反而变差了。模型开始「照着手册念」，而不是根据当前状态灵活判断。这在后面的对照实验中得到了验证。

拆成 Experience + Skill

这次升级做的就是把这两种东西拆开：

• Experience：策略级知识。一两句话描述「做什么、注意什么」。轻量，注入上下文成本低。
• Skill：操作级知识。结构化的步骤流程（steps + pitfalls + prerequisites），有明确的操作路径。

两者通过 skill_refs 字段关联。一条 Experience 可以引用多个 Skill，例如：

Experience："Spotify 操作需要先登录，所有列表接口都要分页（每页最多 20 条），搜索结果需要按 artist 字段过滤"

skill_refs: [#3 Spotify-Login, #7 Spotify-Pagination]

Agent 看到这条 Experience 时，先理解整体策略（要登录、要分页、要过滤）。需要具体操作步骤时，再通过 skill_refs 展开对应 Skill 的完整内容。

这个「先摘要后展开」的设计是核心。 我们称之为 progressive loading。

四路混合搜索

拆分后，Experience 和 Skill 各自建了独立的 OceanBase 表，每张表有 title 和 description 两个字段，分别做了向量索引和全文索引。搜索时四路并行：

title_vector + description_vector + title_fulltext + description_fulltext
          ↓                                                ↓
                    RRF 融合（Reciprocal Rank Fusion, k=60）
                                  ↓
                          最终排序结果

为什么要四路？标题匹配找的是「名字对得上」的经验，描述匹配找的是「内容相关」的经验，向量和全文互补——向量擅长语义理解（「建歌单」和「创建播放列表」是同一件事），全文擅长精确匹配（API 名称、错误码）。

蒸馏：Skill 先行，Experience 跟进

从一段对话轨迹中提取知识，我们的流程是：

1. 先提取 Skill：从轨迹中识别出操作流程，结构化为 steps/pitfalls/prerequisites

2. 存储 Skill：去重（向量相似度 > 0.75 的自动合并）、内容审核、写入数据库

3. 构建 Skill 上下文：把新存储的 Skill 列表传给下一步

4. 再提取 Experience：LLM 在提取 Experience 时能看到已有的 Skill 列表，自然地在 Experience 里引用 Skill ID

5. 存储 Experience：同样去重、审核、写入，skill_refs 字段记录引用关系

这个「Skill 先行」的设计保证了 Experience 和 Skill 之间的引用关系不是人工维护的，而是蒸馏过程中自然产生的。

公平对比实验

为了搞清楚这套设计的真实效果，我们做了一次严格的对照实验。

为什么要强调「公平」？ 因为不同系统用各自的强模型跑各自的任务去积累知识，然后说「我的方案更好」，这不公平——也许只是因为你的强模型轨迹质量更高。

实验设计：

1. 用 Hermes + GPT-5.4（跑一次完整 AppWorld dev 集（54 个任务），记录所有轨迹——34 条成功 + 20 条失败。

2. 同一份轨迹分别喂给两个系统做蒸馏：

• M0 的 distill_all() → 产出 85 条 experience（含 skill_refs 引用关系）
• Hermes 的 extract_skill() → 产出 44 个 SKILL.md 文件

3. 让 GPT-4o 分别使用两边蒸馏出的知识去跑 AppWorld，15 步上限

变量：蒸馏算法 + 存储检索机制。模型一样，任务一样，步数上限一样。

公平蒸馏对比（核心实验）

框架	模式	通过数	通过率	增益	平均步数	步数变化	Token	Token 变化
—	GPT-4o 基线	13/54	24%	—	9.5	—	2.56M	—
M0	+Experience→Skill	21/54	39%	+8 (+15%)	6.2	-35%	1.74M	-32%
Hermes	+SKILL.md	12/54	22%	-1 (-2%)	10.4	+11%	—	—

强模型基线（GPT-5.4，蒸馏源数据）

框架	通过率	平均步数	蒸馏产出
Hermes（no-skill, 15 步）	34/54 (63%)	12.4	54 条轨迹
→ M0 蒸馏	—	—	85 experiences
→ Hermes 蒸馏	—	—	44 SKILL.md

基线对齐验证

我们还做了基线对齐验证——两个框架在不带任何经验的条件下跑 GPT-4o，通过率完全一致（都是 13/54 = 24%），排除了框架本身的差异。

框架	通过率	步数
M0 ReAct	13/54 (24%)	9.5
Hermes tool-calling	13/54 (24%)	9.4

任务级分析

M0 Experience→Skill 救回的任务（基线 FAIL → +经验 PASS）：

任务 ID	类型
23cf851_1、23cf851_3	Spotify 相关
37a8675_3	跨 App
4ec8de5_1 / 2 / 3	Spotify 高级查询
50e1ac9_1 / 2	Spotify 聚合
68ee2c9_1	跨 App
fac291d_1	Venmo 相关

共救回 10 个任务，丢失 2 个（396c5a2_1 / 3），净增 +8。

Hermes SKILL.md 的变化：救回 6 个任务（383cbac_1 / 3、50e1ac9_1 / 2、6171bbc_3、d4e9306_1），丢失 7 个任务（396c5a2_3、4ec8de5_1、b119b1f_1 / 3、d4e9306_3、fac291d_1 / 3），净变化 -1。

为什么 M0 这次能有效

把 M0 和 Hermes 放到同一张表里对照，方案差异一目了然：

维度	M0 Experience→Skill	Hermes SKILL.md
存储	OceanBase（向量 + 全文索引）	本地文件系统
检索	4 路混合搜索（title_vec + desc_vec + title_ft + desc_ft → RRF 融合）	文件名 / tag 匹配
知识结构	Experience（策略摘要）+ Skill（操作步骤），通过 skill_refs 关联	单一 SKILL.md（完整操作手册）
加载方式	Progressive loading：先注入 experience 摘要，需要时按 skill_refs 展开	全量注入匹配的 SKILL.md 到 system prompt
去重	向量相似度 + LLM merge	同名文件覆盖
通过率增益	+15%	-2%
步数变化	-35%	+11%
Token 变化	-32%	未记录

复盘下来，可以看到全量注入反而有害。Hermes 的 SKILL.md 方案把完整操作手册一次性注入 system prompt。我们在测试中观察到，这对 GPT-4o 产生了明显的负面效果——步数增加了 11%，通过率甚至低于基线。

分析原因：

• 44 个 SKILL.md 总共几千字，一次性塞进 system prompt，大量的操作细节淹没了模型的注意力
• 模型开始「照着手册走」，而不是根据当前任务的具体状态灵活决策
• 当手册里的步骤与实际 API 返回值略有出入时（比如字段名大小写不一致），模型反而更困惑

M0 的 progressive loading 避免了这个问题。Agent 首先只看到 Experience 的一行摘要——「Spotify 需要先登录，列表接口要分页」。这足以引导策略方向。当 Agent 实际执行到需要翻页的步骤时，才通过 skill_refs 拉取完整的分页代码模板。

上下文不是越多越好，而是在对的时间给对的信息。

效率红利：强模型教一次，弱模型一直用

评测数据里藏着一个有意思的数字：

指标	基线	+Experience→Skill	变化
平均步数	9.5	6.2	-35%
总 Token	2.56M	1.74M	-32%

步数减少 35%，Token 减少 32%。这意味着什么？

即使任务最终仍然失败，有经验的 agent 也用更少的步骤和 token 去尝试——经验帮助 agent 跳过了不必要的探索步骤。

效率数字里藏着一个很有商业价值的含义：强模型教会，弱模型干活。

算一下账。AppWorld 54 任务跑一遍：

• GPT-5.4 跑一次：约 57.6 美元（$22.5 / 1M tokens）
• GPT-4o 基线裸跑：2.56M token，约 25.6 美元（$10 / 1M tokens）
• GPT-4o + M0 经验：1.74M token，约 17.4 美元（$10 / 1M tokens）

你用 GPT-5.4 或 Claude Sonnet 4.6 让它先把这件事情干成一次，M0 自动把行为轨迹蒸馏成 Experience 和 Skill 存到云端。之后同类任务交给 GPT-4o 甚至更便宜的模型就够了——通过率反而比原来裸跑更高，步数更少，账单更便宜。

这对实际生产场景是降维打击。一个常见的 agent 产品，70% 的请求都是重复模式。你不需要每次都用最贵的模型去处理——只需要用强模型「教一次」，后续请求自动享受经验红利。之前有用户反馈用 Hermes Agent 跑调研任务时单次消耗很大，问能不能只在第一次用强模型。这套机制就是回答：可以，而且这是推荐用法。

经验也能共享进化

也许有人会问这和 Hermes 的「自进化」是不是一回事？

概念上类似——都是让 agent 从实践中学习、积累可复用知识。但具体路径则不同：

• Hermes 只有 skill 一层，skill 是完整的操作手册
• M0 经验系统拆成 Experience+ Skill，策略和操作分离；检索从文件名匹配升级到四路混合向量检索；加载从全量注入升级到按需展开

不同算法不同数据结构，在同一 benchmark 上的结果是 39% vs 22%。AppWorld 是一个很难掺水的测试集——它不测「记忆召回准确率」这种代理指标，直接测「任务是否完成」。这类 end-to-end 评测里，中间每个环节的设计差异最终都会折算成最终通过率上的差。

M0 的经验系统不是单用户闭环。当一条 Experience 经过足够多的正向反馈验证后，可以发布到公共空间。所有接入 M0 的 Agent 都能从公共池中检索到这条经验。

这意味着：你踩过的坑，别人不用再踩。 一个用户在 Spotify 上发现了「搜索结果需要按 artist 过滤才能去掉同名歌曲」这个知识点，发布后所有用户的 Agent 都自动受益。

每条公共经验会记录贡献者列表。多个用户独立发现同一个知识点时，系统通过向量去重自动合并，贡献者记录叠加。这不是「投稿-审核」的人工流程，而是蒸馏过程中自然发生的知识聚合。

写在最后

M0 上个月发布时，我们解决的是「记忆不丢」的问题——让 agent 在 session 之间保留对用户的认知。

这次升级解决的是「经验能用」的问题——让 agent 在实际工作中真的变得更聪明、更快、更便宜。

AppWorld 这个测试集两年前没什么人敢跑，通过率太难看。今天我们拿着 M0 升级版跑到 39%，绝对值还有很大提升空间。但相对于 GPT-4o 基线 +62% 的增益、-35% 的步数、-32% 的 token——这些数字说明：在同一个模型、同一份任务下，经验系统能带来的工程价值是真实存在的，并且是可度量的。

诚实说，这次升级还有一些没做完：

检索还可以更精准。 目前的 4 路搜索对标题和描述做了双索引，但没有利用 Skill 内部的结构化字段（steps、pitfalls）做细粒度匹配。比如用户遇到一个具体错误码，理想情况下应该直接命中 pitfalls 里的对应条目。

AppWorld 通过率还有提升空间。 39% 虽然相对基线提升了 62%，但绝对值还不够高。一部分原因是蒸馏质量——从失败轨迹中提取的经验质量参差不齐；另一部分是检索召回——有些任务类型在经验池中没有覆盖。

也欢迎你接入 M0，让你的 OpenClaw Agent 开始积累自己的 Experience 和 Skill。第一个踩过的坑，以后不用再踩第二遍。

上手试一试

对现有 M0 用户，这次升级是自动生效的。Agent 在日常使用中会自动积累 Experience 和 Skill，无需手动配置。

如果你还没接入，告诉你的 OpenClaw Agent：

阅读 https://m0.seekdb.ai/SKILL.md 并按说明安装与配置 m0。

把这句话发给你的 OpenClaw Agent，它会自己读文档、申请 Access Key、下载插件、改配置、重启 Gateway。全程无需手动操作。