夜雨聆风
📍 文 / 老Z
HuggingFace今天第二热的论文，258个upvotes，看了一下觉得有点意思。
这篇论文讨论的问题，每个用过AI Agent系统的人都会隐约有感觉，但很少有人明确表达出来：你今天帮agent解决的问题，它明天面对同类任务时不记得了。
更准确地说，不只是"不记得"。当系统里有几百个用户的时候，同一个失败模式会被每个用户独立踩一遍，同一个解法会被每个人独立发现，然后各自消失，没有任何机制把这些孤立的经验转化为所有人共享的能力提升。这是目前几乎所有主流AI Agent系统（OpenClaw、CoPaw、IronClaw等）的共同缺陷。
来自AMAP的团队提出的SkillClaw，试图从架构层面解决这个问题。
问题的全貌
现在的AI Agent系统工作方式大体如此：用户从技能库里选需要的skill，agent靠这些skill执行任务。skill封装了结构化的操作程序，告诉agent怎么用工具、按什么顺序做事。这套机制有效，但有个根本性的限制——skill在部署后是静态的。
一个具体场景：你让agent帮你分析Slack消息，提取本周有deadline的事项。agent按照现有的Slack skill来做，遇到API端口配错，反复试错，最终失败。你帮它修好了，任务完成。但这段经历停留在你的会话里，不会被写回到skill定义里。下一个用户遇到完全一样的情况，过一遍完全一样的试错过程。
每个用户的使用经验是孤立的，系统没有机制把这些孤立的成功和失败转化成对所有人都生效的改进。
之前的方法为什么不够
两类已有方法都没能解决这个问题，原因各不相同。
记忆型方法（Mem0、Reflexion等）把历史交互存成记忆，遇到相似任务时检索参考。问题是：记忆绑定到具体实例，每条记忆说的是"这次任务我遇到了什么"，没办法自然地泛化成"这类任务应该怎么处理"的通用程序。各用户的记忆也是隔离的，用户A的失败不会变成用户B的参考。
技能优化方法把经验压缩成结构化指令。这个方向更接近，但处理的是单个agent的单次经验——我失败了，反思一下，改进一下，但这个改进只影响我。技能库仍然是静态资产，不会因为整个用户群的使用而持续进化。
真正缺失的是一个机制：把来自不同用户、不同上下文、质量参差不齐的异质经验，转化成稳定可靠的技能更新，并且让更新对所有人生效。
SkillClaw的做法
核心是一个闭环：白天用户正常使用，夜间系统自动分析、进化、验证技能，次日所有用户用到的是上一晚通过验证的最优技能池。
图：SkillClaw通过收集多用户会话轨迹、聚合证据、agentic evolver推理更新、夜间验证部署，形成技能持续进化的闭环。用户的日常使用自动驱动系统能力提升，无需任何额外干预
从会话到证据
每次用户交互产生一条完整的因果链：prompt → 动作 → 工具反馈 → 中间结果 → 最终输出。保留完整链很重要，因为大多数skill层面的失败只在中间过程里看得到——参数格式错误、步骤顺序不对、缺少验证步骤——这些问题在最终输出里看不出来，只有在中间的action-feedback trace里才能诊断。
收集完之后，按skill分组：哪些会话用到了同一个skill？把它们放在一起，成功case和失败case并排摆着。这个操作构成了一个天然的对照实验：同一个skill，在不同用户、不同任务、不同环境下，有的成功有的失败，这些差异直接揭示了skill在哪里可靠、在哪里会出问题。
agentic evolver
核心模块是一个LLM agent，拿到分组后的证据，对每个skill做开放式推理，选择三种动作之一：refine（修改现有skill）、create（创建新skill）、skip（证据不足，不动）。
同时看成功case和失败case很关键。只看失败容易把有效的部分也改掉；只看成功不知道改哪里。成功case定义了什么不能动，失败case定义了什么需要修。
对于没有被任何skill处理过的会话——那些反复失败但没有对应skill的任务——evolver会看这些会话里有没有可重复的模式，决定要不要创建新技能。
夜间验证
候选更新不直接上线。每晚用当天收集的真实任务对候选做验证：新版本和旧版本在相同任务上跑一遍，看谁的整体结果更好。只有通过验证的更新才进入次日技能池，没通过的留作候选记录但不部署。
结果是系统只会越来越好，不会因为一个糟糕的更新而退步。
实验结果
在WildClawBench上跑了6天，8个并发用户，60个任务，全程由Qwen3-Max自动驱动。
表：6天实验的用户侧结果（Day 1为基线）。四个类别都有持续提升，但进化轨迹各不相同——社交交互第2天就到顶，搜索与检索分两阶段爬升，安全对齐到第5天才大幅改善
每个类别的进化路径都不一样，说明系统在响应的是类别特有的瓶颈：
社交交互（Slack分析、会议协调）：54% → 60%，Day 2就稳定了。有一个Slack工作流skill被整体重写——从描述性指令变成了严格的步骤序列，同时修了API端口配置。这一个更新直接消除了这个类别主要的失败模式。
搜索与检索：22.7% → 34.55%，分两阶段。先修底层的文件存在性验证和输入处理，再建高层的检索规划。这个顺序很合理：底层不可靠的时候，高层策略再好也会被意外的边界情况打断。
安全与对齐（防注入、泄露检测）：24% → 32%，在第5天才出现大跳跃。这类更新不是在提高"表面上的正确率"，而是在提升"在真实执行环境里的鲁棒性"——Git认证失败的fallback、目录克隆协议——这些改进不会立刻让benchmark数字好看，但在边界条件下减少失败率，验证后才会进入部署池。
创意合成（海报生成、视频摘要）：11.6% → 21.8%。早期涨幅最大（88%相对提升），主要来自修掉了执行环境的配置问题——工作目录、输入文件格式检查——而不是生成能力本身的提升。
受控验证的结果更直接：三个定制查询，单轮进化后平均提升42.1%。"保存报告"从28.3%涨到100%——这类失败完全来自程序性错误（输出路径格式），编进skill就能消除。
图：Slack消息分析任务的技能进化案例。原始skill遇到API端口错误后依赖试错，效率低、不稳定。进化后的skill直接修正端口配置，并引入任务相关消息的过滤逻辑，减少了不必要的full-message获取
我的看法
SkillClaw解决的问题是真实的，"跨用户聚合证据驱动集体进化"的思路有道理。"同一技能在不同用户场景下的成功/失败构成天然对照实验"这个设计，我觉得挺聪明的。
但有一件事论文没有深入讨论：evolver是一个LLM agent，它的推理质量直接决定skill更新的质量。验证机制能拦住坏的更新，但如果evolver的建议质量普遍不高，拦截代价很大而进化速度很慢。这个环节的可靠性没有单独分析。
另一个没提到的问题：当不同用户的偏好和使用习惯差异很大时，进化方向可能互相冲突。少数用户的合理需求可能会被多数共识淹没。
6天8个用户是概念验证级别，扩大规模后会发生什么，论文承认没有答案。但这个方向确实有意义——把AI系统从"部署后静止"变成"随使用而积累"，这个问题值得继续做。
论文链接：https://arxiv.org/abs/2604.08377
代码：https://github.com/AMAP-ML/SkillClaw
✍️ 老Z ·
欢迎转发，谢绝洗稿
