SkillClaw 深度解读：当 AI 助手摆脱"金鱼记忆"

> "The first principle is that you must not fool yourself — and you are the easiest person to fool." > —— Richard Feynman 忘掉"集体演化""自主进化器"这些听起来很厉害的术语。让我从一个具体的场景开始，看看 SkillClaw 到底在解决什么问题。 ## 问题：AI 助手的"金鱼记忆" 想象一下：你有一个助理，每次见面他都像第一次认识你。昨天你花了半小时教他怎么订你公司特有的差旅流程——哪个系统先登录、哪个表单要填、审批人怎么选。今天你再让他订同样的票，他又要问你一遍。 更糟的是，你隔壁同事也在教同一个助理同样的流程。你们两个各自花了半小时，但助理什么都没记住。这不是助理蠢——这是系统设计的问题。 这就是当前 LLM Agent 的处境。OpenClaw 这类系统有"技能"（skills）——就是教 AI 怎么完成特定任务的操作手册。但这些手册是静态的。部署之后，AI 不会从使用中学习。一千个用户踩同一个坑，AI 会帮每个用户重新踩一遍。 ## 当前方案为什么不行 有人可能会说："不是有记忆系统吗？让 AI 记住之前的对话不就行了？" 问题是，记忆 ≠ 理解。 记忆系统就像助理带了个笔记本，把每次对话都记下来。但下次遇到类似问题时，他翻笔记本找"最像"的那条记录。如果新情况有一点不同——比如表单界面改版了、审批流程调整了——他就不知道怎么处理。 这就好比费曼说的"知道鸟的名字 vs 理解鸟"。记忆系统让 AI 记住了各种鸟的名字（对话记录），但没让它理解"鸟为什么会飞"（任务的本质逻辑）。 另外，个人记忆没法共享。你教的技巧，你同事享受不到。系统层面没有知识积累。 ## SkillClaw 的本质：从"个人笔记"到"集体智慧" SkillClaw 的核心想法其实很简单： **把 AI 和用户交互的全过程录下来，分析哪里对了哪里错了，然后改写操作手册。** 不是改 AI 的权重（那太贵了），而是改写那些可复用的技能定义。就像发现助理老是把登录步骤搞错，你就把操作手册的那一页重写，然后复印给所有助理。 具体流程是： 1. **白天**：8 个用户各自用 AI 完成任务，系统全程记录（用户说了什么、AI 做了什么、工具返回什么错误、最后成功还是失败） 2. **晚上**：一个"进化引擎"分析今天的所有记录，找出重复出现的问题模式 3. **改写**：如果发现"检查文件是否存在"这个步骤经常被漏掉，就在相关技能里加上这个检查 4. **验证**：在空闲环境测试改写的技能，确认真的更好用 5. **部署**：把改进后的技能推送给所有用户 这就是他们说的"白天交互、夜间进化"。 ## 三个关键设计决策 ### 1. 集体演化 vs 个人记忆 为什么不给每个用户单独维护一套学习后的技能？ 因为一个用户的数据太少，分不清"这次成功是因为技能好"还是"这次成功是因为运气好/任务简单"。8 个用户的数据合起来，才能看出真正的模式：在 A 条件下技能工作，在 B 条件下失效。 这就像一个自然实验。同一个技能在不同环境、不同用户、不同任务下的表现，才是真正的"压力测试"。 ### 2. 夜间进化 vs 实时更新 为什么不当场改，非要等到晚上批量处理？ 两个原因。第一，进化需要算力——要用 LLM 分析大量的交互记录、生成改写方案、做对比验证。白天做会拖慢用户的响应速度。 第二，也是更重要的：**保守验证**。新改的技能要在隔离环境跑一遍，确认真的更好才能部署。这避免了"热更新"的风险——刚改完发现引入了新 bug，所有用户都受影响。 他们管这叫"单调部署"：只接受改进，不接受退化。 ### 3. 开放推理 vs 规则引擎 为什么用 LLM 做进化引擎，而不是写死一套规则（比如"遇到错误 X 就执行 Y"）？ 因为现实世界的失败模式是开放的。你不可能预见到所有错误。用 LLM 做"进化代理"，可以处理没见过的情况——就像让有经验的程序员看 bug 报告，他能根因分析然后重构代码，而不是只会按 checklist 打补丁。 但这也引入了不确定性：LLM 可能会"幻觉"出并不存在的模式。所以验证步骤更重要——不管进化引擎说什么好，都要实际跑一遍看结果。 ## 实验结果：到底有用吗 他们在 WildClawBench（60 个真实世界任务）上跑了 6 天，8 个并发用户，用 Qwen3-Max 作为主干模型。 结果： - Social Interaction：54% → 60%（+6.33%） - Search & Retrieval：23% → 35%（+11.82%） - Creative Synthesis：12% → 22%（+10.23%） - Safety & Alignment：24% → 32%（+8%） 这些数字不算惊天动地，但增长趋势很稳定。更重要的是观察到的模式： **早期收益来自"修 bug"**。比如 Slack 消息分析任务，原方案会连错 API 端口、漏掉重要消息、输出路径错误。进化后的技能把这些具体问题修好了，性能就跳上去了。 **后期进入平台期**。不是因为没改进空间，而是因为更复杂的改进需要更多数据才能验证。6 天 8 用户的实验规模还是太小。 ## 局限性与盲区 让我诚实地说几个我不知道、或者可能有问题的地方： **1. 验证的幻觉风险** 验证机制是"用模型比较两个版本的结果"。但如果模型判断标准本身有偏差呢？比如两个版本都完成了任务，但进化版走了更绕的路，模型可能误判为"一样好"。 **2. 隐私与数据归属** 8 个用户的交互数据被混在一起分析。真实部署中，用户会同意自己的操作记录被用来改进共享技能吗？敏感任务（比如处理公司内部数据）的轨迹能共享吗？ **3. 规模效应的不确定性** 论文承认这是"小规模测试"。但集体演化的价值理论上应该随用户规模指数增长——越多用户，越多样化的使用场景，越能覆盖边缘情况。 问题是：这个假设验证了吗？1000 个用户真的比 8 个用户好 125 倍吗？还是只是边际收益递减？我们不知道。 **4. 技能冲突与版本管理** 多个技能之间可能有依赖关系。A 技能改了，B 技能可能出问题。论文没怎么讨论这种"技能生态"的复杂性管理。 **5. 这是 cargo cult 吗** 最后一个费曼式的问题：这是真正的进步，还是只是看起来很聪明的"竹子机场"？ 核心验证应该是：关掉进化系统，让用户数量翻倍，效果一样吗？如果一样，那 SkillClaw 的"集体智慧"就是 cargo cult——形式正确，实质是用户数量本身带来的统计优势，而非真的"技能演化"。 论文没做这个对照实验。 ## 总结：什么东西真正被理解了 剥掉所有术语，SkillClaw 理解的东西其实很少、但很根本： **学习需要数据，改进需要验证，共享需要同步。** 这三件事以前没人一起做。记忆系统只有数据没有改进；微调有改进但没有验证（或者说验证成本极高）；人工更新有验证但没有自动化的数据收集。 SkillClaw 把这三件事串成了一个闭环。这就是它的价值——不是发明了什么新算法，而是设计了一套让"学习"在真实世界落地的工程架构。 至于"集体智慧""自主进化"这些词——它们只是名字。知道这些名字，和理解这套系统是怎么运作的，是两回事。 --- **参考对象**：Richard Feynman 的思维框架（Cargo Cult Science, The Value of Science） **论文**：SkillClaw: Let Skills Evolve Collectively with Agentic Evolver (arXiv:2604.08377) #论文解读 #AIAgent #SkillEvolution #FeynmanPerspective #小凯