跳转至

阿里SkillClaw:让 Agent 技能在真实使用中集体进化

Ch04.312 阿里SkillClaw:让 Agent 技能在真实使用中集体进化

📊 Level ⭐⭐ | 8.0KB | entities/skillclaw.md

阿里SkillClaw:让 Agent 技能在真实使用中集体进化

大家好,我是PaperAgent,不是Agent! 当前 LLM Agent(如 OpenClaw)依赖可复用的技能(Skills)来完成复杂任务。用户从 Skill Hub 安装技能后,Agent 就能调用这些结构化流程来协调工具使用、执行多步推理。 但这里存在一个根本性问题:技能在部署后基本保持静态。当 Agent 在实际使用中遇到失败(比如参数格式错误、工具调用顺序不对、环境配置缺失),它可能通过多轮试错最终找到解决方案,但这些改进只停留在当前会话,不会被固化到技能库中,也无法传递给其他用户。 本质上,每个用户都在独立地"重新发现"同样的解决方案,系统层面的知识无法累积。 这正是 SkillClaw 要解决的问题:如何让 Agent 技能在真实使用中持续进化,并将一个用户的经验转化为全系统的共享能力?

相关实体

原文存档

深度分析

SkillClaw揭示了当前Agent技能体系的一个根本矛盾:技能在部署后基本保持静态,而用户在真实使用中不断产生改进信号。这种矛盾的本质是知识流动的单向性——改进只停留在当前会话,无法传递给技能库或其他用户。SkillClaw的解法是将多用户交互视为对技能行为的"自然消融实验":不同用户在不同场景下调用同一技能时产生的成功/失败模式,构成了该技能行为边界的经验证据。这意味着单个用户的数据不足以区分"通用改进"和"特例修复",但聚合多用户证据后,稳定的进化方向就会浮现。

SkillClaw的核心是Agentic Evolver——一个配备结构化Harness的LLM Agent,负责对共享技能库进行开放推理式更新。给定技能及其会话组,Evolver执行三种操作:Refine(基于失败模式精炼技能)、Create(当发现未覆盖的可复用子流程时创建新技能)、Skip(证据不足时保持不变)。关键设计是Evolver始终联合分析成功和失败会话——成功会话定义"不变量"(必须保留的有效部分),失败会话定义"目标"(需要修正的具体行为)。这种联合分析防止了"修一个bug引入三个新bug"的常见失败模式,是SkillClaw区别于简单规则修复的核心机制。

夜间验证是SkillClaw保证单调部署行为的关键机制。进化后的候选技能不会直接上线,而是进入夜间验证阶段:在真实环境中同时执行旧技能和新候选技能,比较整体任务成功率和执行稳定性,仅当新技能确实优于旧技能时才接受。这保证了已部署的技能池不会随时间退化——用户始终与"前一晚验证通过的最佳技能池"交互。这是一个保守但稳健的工程决策:通过昼夜循环把进化延迟固定为一个"夜间验证周期",既给足了证据积累时间,又防止了未充分验证的技能进入生产。

实验结果揭示了技能进化的异质性特征。社交交互最早提升(Day 2即达稳态),因为存在高影响的工作流瓶颈,一旦修复即广泛受益;搜索检索呈阶梯式提升,先解决输入验证问题,再构建高层检索规划能力;创意合成早期跃升最大(+88%),但瓶颈不在内容生成本身,而在环境配置和文件处理;安全对齐提升较晚,聚焦于真实环境下的执行可靠性。这些差异说明技能进化的效果取决于失败模式与程序性知识的相关性——当失败源于缺失或不正确的程序性知识时,技能进化特别有效。

受控实验进一步显示,单轮进化平均提升+42.1%,但提升幅度高度依赖于任务类型。基础提取从21.7%提升到69.6%(+47.8%),截止日期解析从41.1%提升到48.0%(+6.9%),保存报告从28.3%提升到100.0%(+71.7%)。这说明对于依赖程序性知识的任务,技能进化效果显著;但对于依赖细微推理的任务,程序性更新较不敏感。这为实际应用提供了重要参考:SkillClaw最适合那些"失败源于缺失或不正确程序性知识"的场景。

实践启示

建立会话到技能的闭环映射机制。 SkillClaw的前提是将每个交互会话转化为结构化轨迹(Trajectory),并按引用技能分组。没有这套追踪机制,多用户证据就无法被聚合,技能进化就失去了信号源。系统设计早期就要考虑如何将用户会话与技能调用关联起来。

成功和失败会话必须联合分析,缺一不可。 单独分析失败会话容易过度修正(修一个bug引入三个新bug),单独分析成功会话无法发现需要修正的边界。Evolver的设计将成功定义为"不变量"、失败定义为"目标",这个框架值得在任何技能改进系统中借鉴。

夜间验证周期是保守但稳健的工程选择。 把进化延迟固定为一个验证周期,既给足了证据积累时间,又防止了未充分验证的技能进入生产环境。在设计类似系统时,不要低估"不进化"的安全感价值——技能池单调提升是用户信任的基础。

技能进化的优先级应该由失败模式的程序性知识含量决定。 根据实验结果,创意合成的环境配置问题、搜索检索的输入验证问题,这些程序性知识的修复效果远好于依赖细微推理的任务。如果系统中有多个技能待改进,应该优先处理那些失败模式与程序性知识相关的技能。

技能的命名规范和版本策略要提前设计。 随时间��移,能力目录会膨胀,技能的数量、版本、owner、权限、废弃流程都需要提前规划。参考SkillClaw中"Refine/Create/Skip"的显式操作分类,可以为技能库建立清晰的演进状态机。

SkillClaw × Nacos 团队共享闭环

来源:墨松,阿里云云原生,2026-06-01。

核心问题

SkillClaw 论文关注的是"单个用户的经验如何进化",但另一个问题是:有了进化后的 Skill,团队怎么用上?

问题 SkillClaw 解决 Nacos AI Registry 解决
产生之困 从真实 Agent 会话中提炼 Skill
共享之困 注册/版本/审核/分发/回滚

治理流水线

  1. SkillClaw 生成候选 Skill,不做最终发布决策
  2. Nacos 承接 draft → review → online 的治理流程
  3. Agent 运行时只读取 Skill,不持有发布和删除权限
  4. 敏感信息、危险命令、越权工具等检查通过 Nacos Pipeline 和 skill-scanner 插件接入

7 步 QuickStart

部署 Nacos → 启动 SkillClaw Proxy + Evolver → 启动 Agent 对话 → Evolver 生成 Skill → Nacos 查看 Registry → 新会话测试复用 → 停止恢复

未来方向

  • 打通生成链路与会话追踪:每次版本变更记录基于哪次会话、验证得分
  • 将自动演化从 Skill 扩展到 AgentSpec(模型配置、Skill 集合、Prompt 引用、安全策略)