SkillClaw：让 Agent 技能库在夜间自动进化的闭环框架

很多 Agent（智能体）系统并不是只靠大语言模型直接完成任务。为了稳定处理复杂工作流，系统通常会给 Agent 配一组可复用的 Skill（技能）：例如怎样调用某个工具、怎样处理接口报错、怎样拆分检索步骤、怎样保存结果文件。

问题在于，技能库一旦部署，往往就变成静态资产。用户在日常使用中踩过的坑、修过的流程、验证过的工具调用方式，通常只留在单次会话里，无法自动沉淀成系统级能力。

SkillClaw 解决的就是这个问题：让多用户 Agent 系统在正常使用过程中持续收集交互轨迹，后台自动分析成功和失败模式，夜间生成并验证技能更新，第二天再把通过验证的技能同步给所有用户。

它的关键目标不是让某一个 Agent 在某一次任务里变聪明，而是让整个 Agent 生态的共享技能库持续变好。

静态技能库为什么会成为 Agent 的瓶颈

Agent 使用技能时，技能承担的是“过程性知识”。

这类知识不是简单的一句提示词，而是完成任务所需的操作流程，比如：

• 某个 API（应用程序编程接口）需要使用哪个端口；
• 调用工具前必须先检查文件是否存在；
• 检索任务要先筛候选，再读取全文；
• 多条件筛选时必须逐条验证约束，不能只找一个看起来接近的结果；
• 生成报告时要把输出路径、文件格式、目录创建流程固定下来。

如果这些流程只存在于一次会话里，系统会不断重复同样的低级试错。

可以把问题抽象成这样：

flowchart LR
    A[用户 A 会话中发现正确流程] --> B[只保留在当前会话]
    C[用户 B 执行相似任务] --> D[重新试错]
    E[用户 A 再次执行相似任务] --> F[仍可能重新试错]

    B -.没有沉淀为共享技能.-> D
    B -.没有更新技能库.-> F

现有思路大致有三类，但都有边界：

SkillClaw 的切入点是“共享技能库的持续进化”：一个用户交互中暴露的问题，如果被系统识别并验证，就可以转化成所有用户都能使用的新技能或改进技能。

SkillClaw 的整体架构

SkillClaw 的系统闭环可以概括为：

多用户交互 → 会话轨迹收集 → 按技能聚合证据 → 自动进化技能 → 夜间验证 → 同步部署

这张系统图展示了 SkillClaw 如何把多个用户的 Agent 会话聚合起来，并把分析结果反向写回共享技能库。

图中的核心路径是一个闭环：白天多个用户正常使用 Agent，系统记录会话轨迹；后台把轨迹按涉及的技能分组；自主进化器分析每个技能相关的成功和失败案例，生成候选技能更新；验证器在真实执行环境中比较旧技能和新技能，只有通过验证的版本才会进入共享技能仓库。

用流程图表示会更直接：

flowchart TD
    U1[用户 1 使用 Agent] --> T[会话轨迹池]
    U2[用户 2 使用 Agent] --> T
    U3[用户 N 使用 Agent] --> T

    T --> P[结构化处理轨迹]
    P --> G[按技能分组证据]
    G --> E[自主进化器分析]
    E --> C1[精炼已有技能]
    E --> C2[创建新技能]
    E --> C3[跳过不可靠更新]

    C1 --> V[夜间验证]
    C2 --> V
    V -->|Accept| S[共享技能库]
    V -->|Reject| R[候选记录保留但不部署]
    S --> A[同步给所有 Agent]
    A --> U1
    A --> U2
    A --> U3

如果设共享技能集为：

S = {s1, s2, ..., sM}

每次用户交互产生一条轨迹 τ，轨迹包含提示词、Agent 动作、工具返回、环境反馈和最终响应。SkillClaw 的任务就是根据跨用户轨迹集合 T = {τ1, τ2, ...} 更新共享技能集 S，让局部交互中的经验转化为全局可复用能力。

会话轨迹如何变成可用证据

SkillClaw 不只是保存最终回答，而是保存完整执行过程。原因很简单：技能失败往往不是最终文本的问题，而是中间流程的问题。

例如：

• 工具参数格式错误；
• 文件路径解析失败；
• 缺少目录创建步骤；
• 调用顺序不对；
• API 端口配置错误；
• 没有处理认证失败、CUDA 不可用、资源缺失等边缘情况。

这些问题如果只看最终回答，通常很难诊断。只有看到中间工具调用和环境反馈，才能知道技能到底在哪一步出了问题。

SkillClaw 对轨迹做两层处理。

1. 单次会话结构化

一条原始会话会被整理成结构化证据，包含：

这样的结构化轨迹把一次交互变成了可分析的执行样本。

2. 按技能聚合

对于每个技能 s，系统会收集所有调用过它的会话，形成证据组：

G(s) = {所有调用过技能 s 的会话轨迹}

没有调用任何技能的会话会被放入特殊分组：

G(∅)

这个分组很关键。多个用户在不同任务里调用同一个技能，产生了不同结果，这些差异天然构成了对技能行为的对比实验：

SkillClaw 不是孤立地看某一次失败，而是把跨用户、跨任务的轨迹放在一起比较。这样更容易判断一个问题是偶发异常，还是应该写进技能库的通用流程。

自主进化器如何更新技能

SkillClaw 的核心模块是 Agentic Evolver，也就是自主进化器。它本身是一个由 LLM（大语言模型）驱动的 Agent，输入包括：

• 当前技能定义；
• 与该技能相关的结构化会话证据；
• 成功案例和失败案例；
• 可执行的进化动作集合。

它不是按固定规则匹配错误类型，而是用开放式推理分析轨迹。这种设计的好处是，系统不必提前为所有失败模式编写规则。例如路径缺失、API 配置错误、文件格式不一致、认证失败、约束验证不完整等问题，都可以通过轨迹证据被识别出来。

进化器有三种动作。

对于已有技能，进化器会同时分析成功和失败轨迹。成功案例用于确认技能中不能破坏的部分，失败案例用于定位需要修正的部分。

这点非常重要。如果只盯着失败样本，技能更新可能会修好一个场景，却破坏原来已经成功的场景。SkillClaw 通过“成功样本约束 + 失败样本修正”的方式，让候选更新更保守。

可以把技能进化过程写成伪代码：

输入：
  S：当前共享技能库
  T：白天收集到的用户会话轨迹集合

过程：
  1. 将 T 转换为结构化证据 E
  2. 按引用技能分组，得到 G(s1), G(s2), ..., G(sM) 和 G(∅)
  3. 对每个技能 s：
       a. 读取当前技能定义
       b. 分析 G(s) 中的成功与失败案例
       c. 从 Refine / Create / Skip 中选择动作
       d. 生成候选技能更新
  4. 对 G(∅)：
       a. 查找反复出现但尚未被技能覆盖的流程
       b. 生成候选新技能
  5. 将候选技能送入验证阶段
  6. 只部署验证通过的技能
输出：
  更新后的共享技能库 S'

夜间验证如何保证技能池不退化

SkillClaw 不会把进化器生成的候选技能直接上线。所有候选更新都要经过夜间验证。

验证方式是把旧技能 s 和候选新技能 s' 放到相同任务、相同环境、相同工具链中执行，然后比较结果。验证不只看最终答案，还会关注完整多步骤执行过程，包括工具调用是否稳定、是否能处理环境反馈、是否完成硬约束。

验证结果只有两类：

这个机制带来一个很实用的性质：部署给用户的技能池不会因为一次错误进化而变差。候选技能必须在真实执行条件下超过旧版本，才有资格进入共享仓库。

完整闭环如下：

sequenceDiagram
    participant User as 多个用户
    participant Agent as Agent
    participant Trace as 轨迹收集器
    participant Evolver as 自主进化器
    participant Validator as 夜间验证器
    participant SkillRepo as 共享技能库

    User->>Agent: 白天正常使用
    Agent->>Trace: 记录提示词、动作、工具反馈、结果
    Trace->>Evolver: 提供按技能分组的证据
    Evolver->>Validator: 生成候选技能更新
    Validator->>Validator: 对比旧技能与新技能
    Validator-->>SkillRepo: Accept 的技能入库
    Validator-->>Evolver: Reject 的技能仅保留记录
    SkillRepo->>Agent: 次日同步技能

这种设计把“自动更新”和“上线安全”分开：进化器可以积极探索候选改动，验证器负责守住部署质量。

WildClawBench：真实环境中的复杂 Agent 任务

SkillClaw 使用 WildClawBench 做评测。这个基准包含 60 个真实世界 Agent 任务，覆盖六类能力。

WildClawBench 和普通问答基准的差别在于，它要求 Agent 在真实 Linux 容器里完整执行任务，而不是只输出一段文本。任务可能包含文本、代码、图像、视频等多模态输入；每个任务有 3 到 27 个聚合指标；任务链路可达到 15 到 50 步；某些硬约束一旦失败，直接记为零分。

实验模拟了一个持续运行的多用户系统：

这个设置更接近真实 Agent 产品的运行方式：用户白天产生数据，系统晚上消化数据，第二天让所有用户使用经过验证的新技能。

6 天部署结果：技能池持续单调改进

四个类别的白天部署结果如下。这里的分数代表用户实际使用到的技能池表现，而不是离线挑选出的最好结果。

这些结果有几个特点。

社交互动：一次关键流程修正带来早期跳升

社交互动从 Day 1 的 54.01% 提升到 Day 2 的 60.34%，之后保持稳定。主要原因是 Slack 跨部门消息汇总技能被改写：旧版本更像描述性指令，新版本变成了明确的过程性工作流。

当技能从“你应该分析消息”变成“先预览消息、再筛选相关内容、再检索全文、最后抽取行动项”，Agent 的执行路径会稳定很多。

搜索与检索：先修底层可靠性，再改善高层规划

搜索与检索从 22.73% 提升到 34.55%，变化呈阶梯状。改进不是由单次大改造成的，而是连续修复多个执行瓶颈：

1. 文件存在性验证；
2. 路径解析；
3. 检索前的约束识别；
4. 基于约束的检索规划。

这说明检索类任务对底层可靠性很敏感。如果路径、文件、API 调用这些基础步骤不稳定，高层推理再强也很难发挥作用。

创意合成：环境初始化是主要瓶颈

创意合成从 11.57% 提升到 21.80%，相对提升 88.41%。这类任务的主要问题不一定是生成能力本身，而是执行环境搭建，例如：

• 工作目录是否正确；
• 输入文件是否可访问；
• 多模态流水线是否初始化；
• 输出文件是否保存到指定位置。

这些流程一旦被写成稳定技能，Agent 就能少花很多时间处理环境错误。

安全对齐：改进较晚，但更偏向系统稳定性

安全对齐在 Day 5 从 24.00% 提升到 32.00%。这类改进更多和真实执行环境有关，例如 Git 认证失败的回退策略、目录克隆流程修正等。

它不一定让模型看起来更会推理，但能减少系统级失败。对于长期运行的 Agent 来说，这类可靠性改进同样重要。

Skill Evolve Lite：隔离技能进化本身的作用

为了单独观察技能进化机制的影响，实验还设置了 Skill Evolve Lite，对三个定制查询做受控验证。

“保存报告”从 28.3% 到 100.0%，说明它的失败主要来自缺失环境流程，例如输出路径、文件格式、目录创建等。这种问题非常适合被编码成技能。

“基本提取”也有明显提升，说明反复出现的执行模式可以被技能进化捕捉。

“截止日期解析”提升较小，因为它更依赖细粒度语义理解和推理，而不是固定流程。这个结果能帮助判断 SkillClaw 的适用边界：它最擅长修复过程性知识缺失或错误，对纯推理失败的帮助会弱一些。

四个案例：技能到底怎么变好

Slack 消息分析：从盲目检索变成三阶段流水线

这张图对比了 Slack 消息分析任务中技能进化前后的执行路径。

旧流程的问题是 Agent 会直接检索大量消息，一旦遇到 API 端口配置错误，就在运行时反复试错。进化后的技能把任务拆成三步：

1. 先用消息预览过滤相关内容；
2. 再按需检索全文；
3. 最后提取行动项。

同时，正确的 API 配置被固化进技能，不再依赖 Agent 临场摸索。这个案例体现了 SkillClaw 对三类问题的修正能力：任务拆分、错误前置、选择性检索。

ICCV 2025 论文分析：把启发式匹配改成结构化解析

这张图展示了 ICCV 2025 oral 论文统计任务中的技能变化。

旧技能使用大学名称做启发式匹配，容易把非第一机构也算进去。进化后的技能把“第一机构”的定义绑定到官方 PDF 首页结构上，并把论文记录与 OpenAccess 数据对齐，再解析机构块。

这种改动的关键不是“多检索一点信息”，而是把统计口径写进流程里。对于学术统计、合规分析、事实核验等任务，明确口径比宽泛搜索更重要。

SAM3 推理：让技能感知不完整环境

这张图展示了 SAM3 推理任务中，技能如何处理缺文件、缺路径、无 CUDA 等环境问题。

旧技能默认执行环境已经准备好：文件存在、路径正确、GPU 可用、输出目录已创建。一旦这些假设不成立，任务就容易失败。

进化后的技能会先做轻量级工作区检查：

• 判断输入资源是否存在；
• 搜索附近可能相关的文件；
• 把缺少输出目录视为可修复问题；
• 遇到 CUDA 不可用时降级为 CPU 执行；
• 区分阻塞错误和非阻塞异常。

这个案例说明，很多 Agent 失败并不是模型“不知道怎么做”，而是技能没有把真实执行环境的不确定性纳入流程。

多条件产品筛选：从“凑答案”改成逐条验证约束

这张图展示了多条件产品选择任务中的技能进化。

旧流程会寻找一个看起来最接近的候选，然后把部分满足条件的产品当成最终答案。进化后的技能改为逐条验证：

• 芯片组；
• 卫星通信能力；
• 电池容量；
• 发布时间；
• 权威来源证据。

如果没有候选同时满足所有条件，Agent 会明确说明没有完全匹配结果，并给出部分匹配分析，而不是强行输出一个错误答案。

这个案例对应的是约束满足问题。对这类任务来说，正确行为不一定是“给出一个答案”，有时是识别无解并解释哪些条件无法同时满足。

SkillClaw 的三个系统属性

SkillClaw 的设计可以归纳为三个系统属性。

这三个属性合在一起，构成了一个数据飞轮：

flowchart LR
    A[更好的共享技能] --> B[更稳定的 Agent 执行]
    B --> C[更高质量的会话轨迹]
    C --> D[更可靠的技能进化证据]
    D --> E[更好的候选技能]
    E --> F[夜间验证]
    F --> A

技能越稳定，Agent 产生的轨迹越干净；轨迹越干净，进化器越容易识别真正有价值的更新；经过验证的更新再回到技能库，形成持续改进循环。

适合与不适合的场景

SkillClaw 不是通用的“让模型变强”方案，它更适合改善 Agent 的过程性执行能力。

使用时需要注意的坑

SkillClaw 的核心难点不在“让 LLM 生成一个新技能”，而在如何安全地把技能放进真实系统。

1. 轨迹必须足够完整

如果只保存最终回答，进化器很难知道失败发生在哪里。至少需要记录：

• 工具名称；
• 调用参数；
• 返回结果；
• 错误堆栈或环境反馈；
• 技能引用关系；
• 最终任务评分或成功标记。

轨迹越完整，技能更新越有依据。

2. 证据不足时不要强行更新

如果一个技能只在极少数会话中出现，而且失败原因不明确，创建或修改技能可能带来副作用。SkillClaw 设计了 Skip 动作，就是为了避免这种情况。

3. 验证环境要接近真实部署环境

很多 Agent 错误只会在真实工具链中暴露，例如权限、路径、网络、依赖版本、GPU 可用性。如果验证只用简化环境，候选技能可能在线上失效。

4. 成功案例也要进入分析

只看失败案例容易过拟合。成功轨迹能告诉系统哪些步骤必须保留，哪些约束不能破坏。技能进化不是无限改写，而是基于证据的保守编辑。

5. 过程性技能和推理能力要分开看

SkillClaw 对保存文件、检索流程、环境初始化、API 调用这类问题帮助更明显。对于高度依赖模型内部推理的任务，技能进化能提供结构化辅助，但不能替代基础模型能力。

开源与兼容信息

SkillClaw 已开源，资源地址如下：

• 论文：https://arxiv.org/abs/2604.08377
• 代码仓库：https://github.com/AMAP-ML/SkillClaw

框架兼容 OpenClaw、CoPaw、IronClaw、PicoClaw、ZeroClaw、NanoClaw、NemoClaw 等 Claw 系列 Agent 系统，并支持多种存储后端：

SkillClaw 的核心价值在于把 Agent 的使用过程变成技能库的训练信号。用户不需要专门标注数据，也不需要手动维护每个技能；系统通过真实交互轨迹发现流程问题，再用验证机制控制上线风险。对于多用户、长时间运行、任务流程复杂的 Agent 平台，这种“白天使用、夜间进化、次日同步”的模式能让技能库从静态配置变成持续演化的共享资产。