最近一篇名为 SkillClaw 的论文在 HuggingFace 上冲到了热榜第二，看到标题的瞬间感觉有点“撞名”。点进去才发现，这可不是重名，阿里 DreamX 团队提出的这套框架，正在尝试解决一个我们在实际使用 Agent 系统时经常会遇到的痛点：技能库一旦部署就成了“化石”，无法从用户的真实使用经验中学习和进化。
你是否遇到过这样的场景？让 Agent 去执行一个任务，失败了。排查后发现是某个工具的 API 端口配错了，或者是输出文件的路径格式不对。你修改一下，任务跑通了。然后呢？然后这件事就结束了——你的改进留在了那次临时的会话里。当下一个用户、甚至是你自己下一次执行类似任务时，很可能在同一个地方重新“掉坑”。
SkillClaw 瞄准的正是这个核心问题：如何让一个 Agent 系统能够从所有用户的失败经验中集体学习，而不是让每个用户都去当一遍“探路先锋”。
静态技能库的瓶颈在哪里？
在以 OpenClaw 为典型代表的 Agent 系统中，技能是核心构建模块。用户提出需求，Agent 查找相关技能，技能则定义了如何使用工具、操作顺序以及异常处理。这套机制很高效，但它有个根本性的局限：技能在部署后基本是静态的。
用户当然能发现问题，也能在单次会话里通过反复试错找到临时解法。但这些宝贵的经验，却无法沉淀到技能定义本身。于是，同一类任务的失败模式在不同用户间反复上演——错误的参数格式、缺失的验证步骤、特定环境下工具调用的异常——系统的整体能力被“锚定”在初始水平，不会随着使用量的增长而进化。
从信息论角度看，这是巨大的浪费。每一次用户交互，都产生了关于“这个技能在此情此景下有效还是失效”的明确信号。遗憾的是，在绝大多数现有系统中，这些信号随着会话结束而彻底消失了。
现有两条路，为何都走不通？
想让 Agent 系统具备自适应能力，目前主要有两个方向。
第一条是 Memory-based（基于记忆） 路径：将历史执行轨迹存储下来，需要时检索相似的案例作为参考。这个方向有很多探索，但存在一个根本问题——记忆停留在实例层面，没有被提炼成可复用的技能改进。一个用户花了两个小时才找到的解决方案，下次同一个用户都不一定能成功检索到，更不用说惠及其他用户了。
第二条是 Skill-based（基于技能） 路径：将经验压缩成结构化的流程描述。这更接近 SkillClaw 的思路，但现有的方法大多将技能库视为静态资源——技能由人工或一次性自动化流程创建，之后便固定不变。
问题在于，要可靠地改进一个技能，你需要足够坚实的证据，以区分一个改动究竟是普适性的优化，还是只在特定会话里侥幸成功的“特例修复”。单个用户产生的数据太稀疏、噪音太大，很难做出这种高置信度的判断。
而这，恰恰是多用户环境价值所在的地方。
SkillClaw 的核心解法：从集体失败中学习
SkillClaw 的核心洞见非常巧妙：不同用户使用同一个技能，在不同的环境和任务上产生不同的执行结果，这本质上构成了一场自然的对照实验。技能定义是唯一的“控制变量”，跨用户的成功与失败对比，能直接暴露技能的边界——在哪些情况下有效，在哪些情况下会失效，以及失效的根本原因是什么。
集体汇聚：从零散会话到结构化证据
SkillClaw 会记录每次用户与 Agent 交互的完整因果链：用户请求 → Agent 的每一步操作（包含工具调用）→ 工具反馈 → 中间错误 → 最终结果。
记录完整的中间过程而不仅是最终结果，至关重要。因为大多数技能级别的失败是“过程性”的——一个错误的参数格式、一个缺失的前置检查、一个不当的工具调用顺序。这些问题只能从“动作-反馈”的轨迹中识别，单纯看最终回复是看不出来的。
所有会话会按照其调用的技能进行分组。一个技能对应一个会话组，系统的“进化器”会同时分析这个组里的成功会话（定义了“哪些行为不能破坏”）和失败会话（定义了“哪些问题需要修复”）。
那些没有调用任何已有技能的会话会被单独归类——这里可能隐藏着反复出现的流程模式，有潜力被创建为全新的技能。
图1：SkillClaw 系统架构概览。左侧多用户的实时交互产生会话轨迹，汇聚成共享证据库。Agentic Evolver 分析每个技能相关的会话组，产出候选更新。经过夜间验证后，通过的改进会被同步给所有 Agent。
Agentic Evolver：开放式诊断，而非硬编码规则
技能更新不走“规则触发”的老路——那需要你预先知道所有可能的失败模式。SkillClaw 使用一个 LLM Agent（称为 Evolver） 来进行开放式的根因诊断。
Evolver 拿到一个技能相关的所有会话证据（包含成功与失败案例），并自主决定采取三种动作之一：
- Refine（修正）：修复现有技能中识别出的具体缺陷。
- Create（创建）：从重复出现的模式中提炼出全新的技能。
- Skip（跳过）：证据不足，保持现状。
这个设计解决了一个关键工程难题：如果只分析失败案例，很可能在修复一个问题时，无意中破坏了之前运转良好的部分。联合分析成功与失败，成功的会话定义了“不变量”——哪些行为已被反复验证有效，不应该被改动。
夜间验证：确保进化单调向好
候选的技能更新不会直接上线。系统会在每晚从当天的交互数据中抽取相关任务，让候选版本和当前的最佳版本在真实的 Agent 环境中“同台竞技”，比较整体任务完成质量。只有被验证为明显更优的候选更新才会被接受，并同步给所有用户。
这套机制确保了技能池的进化是单调改进的，不会因为某次不靠谱的“突变”而导致整体能力倒退。
从实验数据看进化轨迹
为期六天的持续进化
论文中的主实验模拟了真实部署环境：8个并发用户，连续6天使用系统完成 WildClawBench 中的任务。系统则每晚处理收集到的轨迹、生成候选技能、验证后更新技能库。
实验结果（如下表所示）显示，不同类别技能的进化并不同步，存在明显的速率差异：
- 社交交互（Social Interaction） 类技能在第二天就完成了主要改进（54.01% → 60.34%），随后趋于稳定。瓶颈在于一个工作流可执行性问题，当核心技能被改写成显式的分步流程后，性能立刻跃升。
- 搜索与检索（Search & Retrieval） 的进化分两步走：先是解决了基础的“文件操作前存在性检查”，随后在此基础上实现了“约束感知的检索规划”。这说明更高层的推理能力，需要底层的可靠性作为基石。
- 创意合成（Creative Synthesis） 早期的性能跳跃，竟源于一个非常基础的修复——工作空间目录初始化问题。这揭示了一个常见现象：很多高级任务失败的根本原因，往往藏在环境设置这类基础环节。
- 安全与对齐（Safety & Alignment） 的提升出现最晚，且主要体现在执行可靠性上（如 Git 认证回退、目录克隆协议优化），而非显式的安全规则。这类改进可能不会直接拉高基准测试分数，但能显著降低边缘情况下的失败率。
表：六天进化轨迹。Day 1 为基线水平，Day 2-6 反映每晚进化验证后的最佳技能池状态。各类别的改进速率和时间点各不相同。
受控实验：从 28% 到 100% 的飞跃
为了更直接地验证进化机制本身，作者设计了针对具体已知失败模式的测试。
例如，“保存报告（save report）”任务的基线成功率只有 28%，原因是 Agent 对输出文件路径格式的处理时有错误。一旦技能进化机制在技能中显式编码了正确的路径处理逻辑，成功率直接飙升至 100%。
“基础信息提取（basic extraction）”任务提升了 47.8%，说明这类失败也多源于程序性知识的缺失。
而“截止日期解析（deadline parsing）”任务仅提升了 6.9%，这表明对于需要复杂语义推理的失败，技能进化能提供的帮助相对有限。
这个对比颇具启发性：技能进化对根因清晰、可被编码的程序性失败效果显著；而对于需要深度推理的复杂问题，其作用边界则比较明显。
总结与思考
SkillClaw 这篇论文有一个在我看来至关重要的设计：联合推理成功与失败的会话。这看似自然，却极易被忽略。大多数“从错误中学习”的系统只盯着失败案例，结果往往是修好了A，却悄悄破坏了B。SkillClaw 用成功会话来锚定“不变量”，有效避免了这类回退。
“save report”任务从 28% 到 100% 的飞跃，代表了该框架最擅长处理的问题类型。而“deadline parsing”任务仅 6.9% 的提升，则清晰地标出了其能力边界。
当然，目前实验规模仍相对较小（8用户，6天）。真实的 Agent 系统通常用户更多、使用周期更长、技能依赖关系更复杂。规模化后进化机制是否依然稳定，是一个有待验证的开放性问题。
另一个现实考量是夜间验证的成本。每次进化都需在真实环境中执行候选技能进行对比，当用户量极大时，这部分开销会非常显著。但从另一个角度看，这笔“保险费”是为了确保技能池的改进质量——相比于部署一个未经验证的更新而后再处理大规模回退，这或许是一个合理的权衡。
这项研究为构建具备持续学习能力的 Agent 系统提供了新的思路。其核心代码已在 GitHub 开源：https://github.com/AMAP-ML/SkillClaw ，对于关注 Agent 技能进化与多智能体学习的开发者而言，是一份非常值得参考的技术文档 和实践素材。如果你对这类能让系统“越用越聪明”的机制感兴趣，不妨去 云栈社区 的 人工智能 板块看看，那里有更多关于 Agent、大模型应用的前沿讨论和技术分享。
发表于 1 小时前
|
查看: 2|
回复: 0
