过去一年，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%）
下面讲讲我们为什么要把「经验」这件事重新想一遍。
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.把歌一首首加进去
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 条失败。
公平蒸馏对比（核心实验）
我们还做了基线对齐验证——两个框架在不带任何经验的条件下跑 GPT-4o，通过率完全一致（都是 13/54 = 24%），排除了框架本身的差异。
任务级分析
复盘下来，可以看到全量注入反而有害。Hermes 的 SKILL.md 方案把完整操作手册一次性注入 system prompt。我们在测试中观察到，这对 GPT-4o 产生了明显的负面效果——步数增加了 11%，通过率甚至低于基线。
分析原因：
44 个 SKILL.md 总共几千字，一次性塞进 system prompt，大量的操作细节淹没了模型的注意力
模型开始「照着手册走」，而不是根据当前任务的具体状态灵活决策
当手册里的步骤与实际 API 返回值略有出入时（比如字段名大小写不一致），模型反而更困惑
M0 的 progressive loading 避免了这个问题。Agent 首先只看到 Experience 的一行摘要——「Spotify 需要先登录，列表接口要分页」。这足以引导策略方向。当 Agent 实际执行到需要翻页的步骤时，才通过 skill_refs 拉取完整的分页代码模板。
上下文不是越多越好，而是在对的时间给对的信息。
评测数据里藏着一个有意思的数字：
步数减少 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 都自动受益。
每条公共经验会记录贡献者列表。多个用户独立发现同一个知识点时，系统通过向量去重自动合并，贡献者记录叠加。这不是「投稿-审核」的人工流程，而是蒸馏过程中自然发生的知识聚合。
老实说，这次升级还有一些没做完：
检索还可以更精准。目前的 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。全程无需手动操作。
