AI 智能体技能进化的新范式：SkillClaw 如何用集体经验驱动 Agent 能力持续成长

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

核心结论：SkillClaw 是高德地图机器学习团队（AMAP-ML）开源的一个 AI 智能体技能集体进化框架。它的核心价值在于——让 AI 智能体在日常使用过程中自动积累经验、提炼技能，并将这些技能跨设备、跨用户、跨团队地共享，实现"集体进化"。在 WildClawBench 基准测试中，经过 6 轮进化，创意合成类任务的成功率相对提升了 88.41%，特定定制化查询单轮平均提升 42.1%。整个进化过程对用户完全透明，不需要任何额外操作。

关键信息速览：

• 项目名称：SkillClaw
• 开源地址：https://github.com/AMAP-ML/SkillClaw
• 核心论文：arxiv.org/abs/2604.08377
• 核心机制：多用户交互数据 → 自动提炼技能 → 去重优化验证 → 云端同步全团队
• 支持框架：OpenClaw、Claude Code、Codex、Hermes、QwenPaw 等主流 Agent 框架
• 安装方式：pip install skillclaw 或 bash 脚本一键安装

想看完整拆解，往下翻。

一、AI Agent 的根本困境：静态技能库之殇

如果你用过 OpenClaw、Claude Code 或者其他 LLM 驱动的智能体，大概率踩过这个坑：

你花了半个小时，终于搞清楚怎么让智能体正确地调用某个 API、怎么处理某种特定的文件格式、怎么绕过某个工具的已知 bug。你的智能体这次做到了，任务完成。然后……第二天换个环境，或者换了台机器，一切又从零开始。上次积累的那些经验，没有被任何地方保存下来。

团队里更惨。张三踩过的坑，李四、王五还得一个接一个地踩。没有任何机制能把"张三今天学到的东西"自动传递给其他人。而且这种重复踩坑不是因为团队成员不勤奋——问题是根本没有一个系统能把张三的踩坑经验实时同步给李四。你不可能要求每个人每解决一个问题都去更新一次共享文档，那会把人逼疯的。这就是今天要聊的这个开源项目想要解决的核心问题。

这个问题的根源在哪里？在于当前 AI Agent 生态里的技能（Skill）几乎全部是静态的。

什么叫静态技能？简单说，开发者在部署智能体之前，手写一批 SKILL.md 文件，描述智能体应该怎么处理各类任务。这批文件一旦写好，就固定下来了。用户在使用过程中发现了更好的处理方式、踩到了边界情况、找到了工具的隐藏 bug，这些经验统统散落在会话记录里，没有任何机制把它们"提炼"成下一版技能。

这就好比一家公司，雇了一百个员工，但公司没有任何培训机制、没有知识库、没有经验传承系统。每个人都在单打独斗，前人的教训无法被后人吸收。一旦有人离职（会话结束），他的经验也随之消失。

值得注意的是，这个问题会随着智能体使用频率的提升而变得越来越严重。用的越多，积累的"未被记录的有效经验"就越多，同时重复踩坑的机会也越多。这是一个效率越用越低的反直觉现象——明明用了很长时间，积累了很多使用经验，但每次开新会话，智能体还是从同一个起点出发，对这一切一无所知。

在论文里，研究团队把这个问题称为"技能生态的静态性"（static skill ecosystem）。用户在交互过程中发现的有效方案，往往被局限在当前会话。相似的工具调用模式、类似的失败场景，不同用户在反复经历，系统却毫无学习可言——每个人都在重新发明"轮子"。

这不是个小问题，而是影响整个 AI Agent 落地效果的根本性缺陷。智能体能力的上限，被锁死在部署那一刻手工编写的技能文件里，而不会随着真实使用而成长。

SkillClaw 要解决的，正是这个问题。

二、技能（Skill）是什么？理解 OpenClaw 生态的基石

在聊 SkillClaw 之前，有必要先搞清楚"技能（Skill）"在这个语境里到底是什么东西——因为这是整个体系的基础概念。

在以 OpenClaw 为代表的现代 LLM 智能体框架里，技能（Skill）是一种模块化的能力封装单元。每个技能，本质上是一个目录，里面包含一个核心文件——SKILL.md。

这个 SKILL.md 文件的结构很简单：YAML 格式的元数据头（描述技能的名称、触发条件、适用场景等），加上一段自然语言写成的操作指令（告诉智能体遇到什么情况该怎么做、用哪些工具、注意哪些坑）。必要时还可以附带辅助脚本或参考文件。

用一个比喻来理解：如果说 LLM 是一个通用的大脑，那技能就是这个大脑接受的"专业培训材料"。智能体启动时会读取所有技能文件，把它们整合进自己的上下文，从而知道"在这种场景下，应该按照这个步骤来操作"。

举个具体的例子。假设你有一个用于数据分析的智能体，你给它安装了一个"CSV 数据清洗"技能。这个技能的 SKILL.md 里写着：遇到用户上传 CSV 文件并要求分析时，先检查编码格式、处理空值、识别异常值，然后输出清洗报告。有了这个技能，智能体就知道这套固定流程，不需要每次都从头摸索。

技能的优势是什么？可复用、可分发、可叠加。一个技能写好之后，可以安装给任意多个智能体实例使用。ClawHub（OpenClaw 的公开技能注册中心）上已经有超过一万三千个社区贡献的技能，覆盖了从文件处理到 API 调用、从代码调试到邮件自动化的方方面面。

但问题就出在这里：这些技能，从写好的那一刻起就固化了。用户用它的时候发现它在某种边界条件下会失败，这个发现不会自动更新回技能文件。技能库的质量，完全取决于最初编写者的经验和预见性，而不会从真实使用中学习成长。

这就是 SkillClaw 介入的切入点。

在进入正题之前，先多说一点技能生态的现状背景。ClawHub 是 OpenClaw 框架对应的公开技能注册中心，截至 2026 年初，上面已经有超过一万三千个社区贡献的技能，覆盖从自动化收发邮件、管理日历，到调用 GitHub API、处理 CSV 数据的方方面面。

但这一万三千个技能，全都是某一个人或某一个团队在某个时间点写下来的静态文档。它们发布之后，大概率就没有被系统性地更新过。你安装一个两年前写的技能，里面的工具调用方式可能早就过时了，对应的 API 参数也许已经调整，但技能文件本身浑然不知。你用它、踩坑、绕过去，然后这个经验就消失在当前会话里——没有任何地方记录下来，也没有任何机制把它反哺给技能本身。

更麻烦的是，在组织级别的部署场景里，不同团队成员各自在维护一套本地技能配置，彼此之间几乎没有知识流通。你在 A 项目里调试出来的最优参数配置，B 同事在做类似任务时完全不知道，还得自己重新试一遍。这种知识孤岛问题，随着团队规模扩大会越来越严重。

SkillClaw 的出现，正是为了从根本上打破这个僵局。

# 一个典型 SKILL.md 文件结构（示意）

---
name: csv-data-cleaner
description: 当用户上传 CSV 文件并要求数据分析或清洗时使用本技能。
triggers:
  - "分析这个 CSV"
  - "清洗数据"
  - "处理这个表格"
---

## 操作流程

收到 CSV 文件后，按以下顺序处理：

1. 检测文件编码（优先 UTF-8，其次 GBK）
2. 识别并处理空值（数值列填充均值，文本列标记为"未知"）
3. 检查异常值（数值列使用 IQR 方法）
4. 输出清洗报告，包含原始行数、清洗后行数、处理说明

注意：遇到编码错误时，尝试 latin-1 编码作为兜底。

以上这个例子，莫潇羽@无忆研习社 用来说明一个真实的技能文件长什么样子。它是静态的——写完就是这样了，不管用了多少次、遇到了多少新边界情况，内容都不会变化。

用这套技能处理日常任务，效果通常还不错——毕竟大多数 CSV 数据清洗的流程大同小异，技能里写的那几条规则能覆盖八九成的场景。但剩下的一两成呢？比如某个 CSV 文件的编码是 BIG5，不是 UTF-8 也不是 GBK，也不是 latin-1；或者某个字段的日期格式是非标准的中文日期写法"二〇二四年三月五日"；或者空值不是空字符串而是"N/A"、"-"、"无"这些自然语言词。

这些边界情况，原始技能文件里通通没有覆盖。你遇到了，想办法解决了，但你的解决方案只存在于当前会话里。下次遇到同样的问题，还是得重新解决一遍。

这就是技能静态化的实际代价，不是什么抽象的系统设计问题，是真实的效率损耗，一次次发生在每个认真使用 AI Agent 做实际工作的人身上。

三、SkillClaw 的核心理念与整体架构

SkillClaw 的论文标题叫《Let Skills Evolve Collectively with Agentic Evolver》，直译过来是"让技能与智能进化器一起集体进化"。这个名字已经把核心思路说得很清楚了。

SkillClaw 的核心洞察是这样的：不同用户在不同场景下使用同一个技能，会从不同角度揭示这个技能的行为边界——什么条件下它有效，什么条件下它会失败。单个用户产生的信号往往不足以区分"可泛化的改进"和"特定场景的补丁"；但如果把跨用户的交互证据聚合起来，就能为稳定的技能进化提供充分依据。

用更口语的方式说：你一个人踩坑，只能证明你自己踩坑了；八个人踩同一个坑，才能证明这个坑确实存在，值得填上。

基于这个洞察，SkillClaw 构建了一套循环流水线：

多用户实时交互
       ↓
  会话数据收集（Client Proxy 层）
       ↓
  按技能分组的交互证据聚合
       ↓
  Agentic Evolver 自主分析与进化决策
       ↓
  候选技能更新的夜间验证
       ↓
  通过验证的技能同步回所有 Agent
       ↓
  影响下一轮用户交互（产生新的进化证据）

这个循环不停地转，每一轮都让整个技能库向前进化一步。从用户的视角来看，这一切都在后台静默运行，不需要做任何额外操作。

值得注意的是，SkillClaw 的论文在 2026 年 4 月发布在 arXiv（arXiv:2604.08377），作者团队来自高德地图的机器学习部门（AMAP-ML），项目在 GitHub 上开源后迅速获得了大量关注，Star 数在短时间内突破了千颗。之所以能这么快引起共鸣，是因为这个问题——AI Agent 技能不会随使用进化——实在是太普遍、太真实了，而 SkillClaw 提供的方案又足够优雅：不改变用户的使用习惯，不增加操作负担，在幕后自动完成所有的学习和进化工作。

四、三大核心组件深度拆解

SkillClaw 的系统由三个核心组件构成，它们共享同一个存储层和统一的 SKILL.md 技能格式，在功能上可以互补、在部署上彼此独立。

4.1 Client Proxy：本地代理层（必须安装）

Client Proxy 是 SkillClaw 的"神经末梢"，部署在每台用户机器上，以本地 API 代理的形式工作。它的对外接口与标准 LLM API 完全兼容（/v1/chat/completions 和 /v1/messages），这意味着你的智能体不需要改任何代码，只需要把 API 调用的 base URL 指向本地代理就行。

Client Proxy 在后台默默做三件事：

拦截并记录会话数据：每次智能体发起 API 调用，代理都会在中间截获请求和响应，把完整的会话内容——包括用户输入、智能体的中间推理步骤、工具调用及其返回结果、最终答案——全部以结构化格式记录下来。这是后续进化分析的原始材料。

管理本地技能库：代理负责维护本地的技能文件目录，在每次启动时把最新的技能注入到智能体的上下文里。

与共享存储同步：通过配置的存储后端（支持阿里云 OSS、AWS S3 或本地文件系统），代理负责把本地积累的会话数据上传出去，同时把进化完成的新技能拉取回来。

# Client Proxy 的核心操作命令

skillclaw setup      # 生成本地配置文件
skillclaw start      # 启动本地代理（默认监听 8080 端口）
skillclaw status     # 查看代理运行状态
skillclaw config show  # 查看当前配置

配置好之后，你只需要在使用智能体时把 OPENAI_BASE_URL 或 ANTHROPIC_BASE_URL 指向本地代理地址，一切就自动运行了。

4.2 Workflow Evolve Server：固定三阶段工作流进化服务器

Workflow Evolve Server 是 SkillClaw 提供的第一种进化引擎，采用固定的三阶段 LLM 工作流。这种设计的优点是稳定、可预测、Token 消耗相对可控。

三个阶段分别是：

Summarize（总结阶段）：读取收集到的会话数据，对每个技能关联的所有会话做结构化摘要。提炼出：这个技能在哪些场景下被调用了，成功了几次，失败了几次，失败的共同模式是什么。

Aggregate（聚合阶段）：把多个用户对同一技能的使用情况汇总，识别重复出现的行为模式。哪些失败是偶发的，哪些失败是系统性的。哪些成功路径可以被泛化提取出来。

Execute（执行阶段）：根据前两阶段的分析结果，决定对技能做什么操作——修改、新建还是保留——然后把结果写回存储层。

# 启动 Workflow 进化服务器

skillclaw-evolve-server \
  --port 8787 \
  --interval 300 \              # 每 300 秒运行一轮进化
  --storage-backend oss \       # 使用阿里云 OSS 作为共享存储
  --oss-endpoint "$EVOLVE_STORAGE_ENDPOINT" \
  --oss-bucket "$EVOLVE_STORAGE_BUCKET" \
  --group-id my-team            # 团队标识，用于隔离不同团队的技能库

--interval 参数控制进化频率。300 秒（5 分钟）是一个合理的默认值，实际可以根据团队的使用量调整。使用量大的团队可以设短一点，让进化更及时；小团队可以设长一点，避免积累的数据量不够就触发进化导致质量不稳。

4.3 Agent Evolve Server：OpenClaw 驱动的自主进化服务器

Agent Evolve Server 是 SkillClaw 的第二种进化引擎，也是论文中重点介绍的 Agentic Evolver 的实现。与 Workflow 版本的固定三阶段流程不同，这个版本由一个完整的 OpenClaw 智能体驱动，通过开放式推理来分析会话数据并自主决定如何进化技能。

它的优势在于灵活性——智能体可以针对每个技能的具体情况，做出更细腻、更有针对性的判断。它有直接读取和编辑技能文件的能力，可以完全自主地完成整个进化流程，不依赖预定义的规则。

# 先安装 OpenClaw（Agent Evolve Server 的依赖）
npm install -g openclaw

# 启动 Agent 进化服务器

skillclaw-agent-evolve-server \
  --port 8787 \
  --interval 300 \
  --no-fresh \                  # 不清空历史，累积进化
  --storage-backend oss \
  --oss-endpoint "$EVOLVE_STORAGE_ENDPOINT" \
  --oss-bucket "$EVOLVE_STORAGE_BUCKET" \
  --group-id my-team

两种进化服务器的选择逻辑可以参考下面这个对比表：

三个组件（Client Proxy + 任选一个进化服务器）共用同一套存储层和 SKILL.md 格式，可以灵活组合，甚至在不同团队节点上分别部署不同的进化服务器，数据互通。

五、集体进化全流程：从一次对话到全局技能升级

这一节是整篇文章的核心，我自己折腾完整个流程之后，觉得最值得详细拆解的就是 SkillClaw 的进化机制到底是怎么工作的——因为它并不是简单地"把会话记下来然后总结一下"，而是有一套相当严谨的设计。

5.1 第一阶段：从孤立会话到共享证据

SkillClaw 首先把每次交互记录为一个结构化的因果链，格式大致如下：

用户输入（Prompt）
    → 智能体行动（包含工具调用序列）
        → 中间反馈（工具返回结果、报错信息、用户响应）
            → 最终答案

为什么要保留完整的中间过程？因为大多数技能层面的失败都是程序性的。参数格式错了、缺少了某个验证步骤、工具调用顺序搞反了——这些问题在最终答案里看不出来，必须从中间的行动-反馈链里才能诊断出来。只看输入输出是不够的。

收集完会话之后，系统按照技能调用情况对会话进行分组：

• 调用了技能 A 的所有会话，归入技能 A 的证据组
• 调用了技能 B 的所有会话，归入技能 B 的证据组
• 没有使用任何技能的会话，放入独立组（用于发现"应该有一个技能但目前还没有"的空白区域）

分组的巧妙之处在于：当多个会话调用了同一个技能但产生了不同的结果时，这个技能本身就成了"控制变量"。一个技能，用户 A 用成功了，用户 B 用失败了，而两人的任务背景相似——这种对比给了系统一个天然的"自然实验"，可以精准定位：技能在什么条件下会失败。

5.2 第二阶段：Agentic Evolver 如何做决策

这是整个流程里技术含量最高的部分。

Agentic Evolver 是一个配备了结构化执行框架（Harness）的 LLM 智能体。它接收到的输入是：某个技能的当前定义 + 该技能关联的所有会话证据（成功的和失败的都有）。

Harness 提供了结构化的输入格式，但不限制推理过程。Evolver 可以用开放式推理去分析这些证据，自己判断问题所在，自己决定怎么处理。这种"固定框架 + 开放推理"的分离设计，让系统可以处理各种形态的失败模式，而不需要为每种情况预先写规则。

最终，Evolver 对每个技能选择三种操作之一：

┌─────────────────────────────────────────────────────────┐
│                  Agentic Evolver 决策树                  │
├──────────────┬──────────────────────────────────────────┤
│   Refine     │ 发现了可改进点：修正错误、增加鲁棒性、    │
│   （精化）   │ 补充边界情况的处理逻辑                   │
├──────────────┼──────────────────────────────────────────┤
│   Create     │ 发现了独立组里存在重复的子流程，当前没有  │
│   （新建）   │ 技能覆盖 → 创建一个新技能                │
├──────────────┼──────────────────────────────────────────┤
│   Skip       │ 证据不足，无法支持稳定的修改决策         │
│   （跳过）   │ → 保持当前技能不变，等待更多证据         │
└──────────────┴──────────────────────────────────────────┘

这里有个细节非常关键：Evolver 始终联合分析成功会话和失败会话。

成功会话定义了"不变量"——技能里哪些部分是真正有效的，不能动；失败会话定义了"需要修复的目标"——哪里出了问题，怎么改。这种联合视角防止了一个常见的反面教材：为了修一个问题，把原本好好工作的部分给改坏了。进化必须是累积性的，不能是两步走一步退。

还有一个细节：Evolver 不强制要求每次都做修改。Skip（跳过）是一个完全合法的决策，而且往往是正确的决策。当证据不充分时，强行修改可能引入不稳定；只有当多个用户的多次会话都指向同一个问题，且失败模式足够清晰，Evolver 才会信心十足地选择 Refine 或 Create。这种"宁可不动，不要瞎动"的保守策略，是保障技能库质量的重要机制。

你可以把 Evolver 的工作方式想象成一个经验丰富的技术 Leader 在 Code Review：不是每个提交都需要改，看起来没问题的就过；有明显问题的，要说清楚改哪里、为什么改；发现了一个系统性空白，才考虑新建一个模块（技能）来覆盖。这种有节制的更新策略，是 SkillClaw 能保持技能库质量"单调不降"的根本原因。

5.3 第三阶段：夜间验证与同步部署

Evolver 生成候选技能更新之后，这些更新不会立刻上线。SkillClaw 有一套验证机制，在夜间（利用用户不活跃的时间段）对候选技能进行测试。

验证逻辑很直接：针对同一个技能的当前版本和候选新版本，从当天收集的交互数据里挑选相关任务，在相同环境下分别运行两个版本，对比结果。只有新版本的表现优于旧版本，才会被接受并同步到共享仓库；被拒绝的更新只作为候选记录保留，等待下一轮更多证据的积累。

这个验证步骤引入了一个重要的特性：单调部署行为（Monotonic Deployment）。因为只有更好的更新才会被采纳，技能库的整体质量只会随时间单调递增，不会出现"因为某次进化引入了新问题"导致整体退步的情况。

技能版本演进的单调性保证：

Day1 技能版本  →  Day2 技能版本  →  Day3 技能版本
   (v1.0)              (v1.1)              (v1.2)

   性能: 54%          性能: 60%          性能: 62%

每一个版本的性能，都不低于前一个版本 ✓

从用户的角度看，这一切都是透明的：你只是在正常使用智能体，后台悄悄地完成了证据收集、进化分析、夜间验证、技能同步，第二天你的智能体就多了一些"经验"，在之前容易出问题的地方变得更稳了。

六、双循环架构：让进化真正"无感知"

我觉得 SkillClaw 设计上很聪明的一点，是它把整个系统分成了两个明确分离的循环：

任务时间循环（Task-Time Loop）：这是用户直接感知的那一层。你跟智能体对话、交代任务、等待结果——和普通使用完全一样。Client Proxy 在这一层静默工作，只做一件事：记录每次交互的完整过程。

进化循环（Evolution Loop）：这是后台的那一层，用户完全不可见。每次任务完成后，在约定的时间节点（通常是深夜），进化服务器启动，读取积累的会话数据，运行 Evolver，产出候选技能，验证后同步回来。

这两个循环的分离，带来了一个很实际的好处：进化不会影响使用。Evolver 的运行不占用用户正在进行的对话的计算资源，进化的 Token 消耗也在非高峰期进行，不会抢占正常使用的额度。

graph LR
    A[用户发起对话] --> B[Client Proxy 拦截记录]
    B --> C[LLM API 正常响应]
    C --> D[会话数据写入共享存储]
    D --> E{达到进化触发条件？}
    E -- 是 --> F[进化服务器启动 Evolver]
    F --> G[分析会话证据]
    G --> H[生成候选技能更新]
    H --> I[夜间验证对比]
    I --> J{新版本更优？}
    J -- 是 --> K[写回共享存储并同步所有节点]
    J -- 否 --> L[保留候选记录，等待下一轮]
    K --> M[下一次用户对话，加载升级后的技能]
    M --> A
    E -- 否 --> A

对于团队使用场景，上面这个循环还有一个额外的维度：N 个用户同时在产生会话数据，同时在消费进化后的技能。用户 A 调试了一个数据库连接问题，Evolver 从他的会话里提炼出更鲁棒的数据库技能；用户 B 和用户 C 还没遇到这个问题，但下次他们遇到时，会自动使用已经进化过的版本，直接绕过那个坑。这就是"集体进化"的实际效果。

莫潇羽@无忆研习社 觉得，这个设计比"共享文档"或者"团队知识库"强的地方在于：它是全自动的。你不需要指定谁来写知识库，不需要有人专门总结踩坑记录，系统自己来。

这里值得展开讲一个对比场景：很多团队会专门建一个 Notion 或 Confluence 空间，用来记录智能体使用过程中的"最佳实践"和"注意事项"。这个机制的问题是什么？它依赖有人主动记录、主动更新、主动同步。现实情况是：大多数人在解决了问题之后，不会特意回去补文档。任务压力一大，知识库就开始腐烂——里面的内容越来越旧、越来越不准，反而成了一个"看起来有用但实际上可信度存疑"的地方。

SkillClaw 绕过了这个人的惰性问题。它不要求任何人"记得去更新技能"，进化完全由系统驱动。你只要正常用，经验就在积累。这个设计哲学——让正常的使用行为本身产生改进信号——我觉得是整个框架最值得称道的地方，比任何具体的技术细节都更重要。

还有一个细节值得提：同一个用户在不同机器上的智能体实例，也能通过 SkillClaw 共享技能进化成果。举个具体场景：你在家用的机器上调试出来了一套处理某类 API 错误的有效流程，进化后的技能被同步到共享存储；过几天在公司机器上接入同一个 group 的 SkillClaw，执行一次 skillclaw skills sync，你在家调出来的那套经验就到了公司机器上。两个环境的智能体能力直接拉平，整个过程不需要你手动做任何迁移操作。

七、WildClawBench 实验结果与案例分析

光说理论不够，来看实际数据。

7.1 实验设置

SkillClaw 的研究团队在 WildClawBench 上做了系统评测。WildClawBench 是一个贴近真实场景的 AI Agent 基准测试，包含 60 个复杂任务，覆盖六个领域：生产力流程、代码执行、社交互动、信息检索、创意生成、安全对齐。

与那些用模拟 API 响应的基准测试不同，WildClawBench 要求在真实的 Linux 容器环境中端到端执行——智能体有真实的 bash 终端、真实的文件系统、真实的网络请求。当网页搜索返回意外结果、Python 包抛出没文档的错误，智能体得自己应对，就像真实用户一样。这样测出来的结果，比"模拟环境里的成绩单"可靠得多。

实验设置：模拟多用户部署场景，连续运行 6 天（6 轮）。每天分白天的"交互阶段"和晚上的"进化验证阶段"。8 个并发用户同时参与交互，所有执行、进化和验证都由 Qwen3-Max 驱动。

7.2 六轮进化的数据表现

几个值得关注的细节：

社交互动类：第 2 天就从 54.01% 跳到了 60.34%，而且此后保持稳定。这说明在这个领域，有一个高影响力的工作流瓶颈在第一轮进化中就被快速定位并修复了。这种"一击即中"的效果，是多用户证据聚合带来的——单个用户可能要踩很多次才能确定问题，但 8 个用户的证据汇总，让问题显现得更快。

创意合成类：88.41% 的相对提升是整个实验里最亮眼的数字。研究发现，这一类任务的主要瓶颈并不是"智能体不会创作"，而是环境配置问题——文件处理路径不对、工作目录配置错误、多模态管道没搭好。这些问题被编码进技能之后，智能体就能一次性绕过，不再卡在环境配置上。

安全对齐类：直到第 5 天才出现明显提升，主要改进集中在执行可靠性上，比如 Git 认证失败的回退策略、目录克隆协议。这反映了一个现实：某些类型的问题需要足够多的交互证据积累，才能让系统准确判断值得修改——Evolver 在证据不足时会选择 Skip，等待更稳定的信号。

7.3 控制验证实验的数据

在控制实验里，针对"基础数据提取"、"截止日期解析"、"保存报告"三个定制查询，单轮进化后平均提升达到 42.1%。

其中最戏剧性的是"保存报告"这个任务：成功率从 28.3% 提升到了 100.0%。初始失败的原因很具体：技能文件里缺少环境特定的流程说明（输出路径是什么、输出格式怎么指定）。一旦这些细节被从真实会话中提炼出来，编码进技能，下次就再也不会失败。

这个数据说明了什么？说明很多 Agent 的失败，根因不在于"模型不够聪明"，而在于技能里缺少足够具体的操作细节。而这些细节，正是真实使用过程中自然积累的。

7.4 案例分析：Slack 消息分析任务的技能进化

论文里有一个很直观的案例，我觉得值得展开说一下。

进化前的情况：智能体在处理 Slack 消息分析任务时，使用了一套朴素的工作流——直接拉取所有消息，然后分析。遇到 API 调用失败（比如端口配置不对），就靠"试错"来解决：多试几个端口，看哪个通。

进化后的情况：Evolver 从多个用户的失败会话里识别出了三个系统性问题，并对技能做了三项对应改进：

改进 1：任务分解
  之前：一次性拉取所有消息
  之后：先扫描消息预览（轻量操作，快速过滤相关内容），
        再选择性地获取完整消息（减少不必要的 API 调用）

改进 2：主动错误纠正
  之前：遇到 API 错误靠试错
  之后：已知的 API 配置错误（如端口号映射）直接编码进技能，
        不再需要在运行时试错

改进 3：选择性检索
  之前：盲目拉取所有内容
  之后：先过滤再获取，减少无效工具调用

这个案例很好地展示了 SkillClaw 进化出来的，并不是一些模糊的"改进"，而是非常具体的、可以直接落地的操作流程优化。这正是 SKILL.md 格式的优势——它是自然语言写的，Evolver 可以用 LLM 的能力对其做细粒度的修改，而不是操作一堆参数矩阵。

7.5 为什么不同任务类别的进化节奏差异这么大？

看完上面的数据，会发现一个有意思的规律：不同任务类别的进化速度差异很大，有的第 2 天就提升显著，有的到第 5 天才动。这背后的逻辑是什么？

社交互动类：提升快，是因为这类任务里"工具调用配置错误"这类问题特征明显——多个用户遇到同一个错误配置，证据聚合后很快就能定位和修复。这类问题属于"易于识别、一次修复即可泛化"的类型。

创意合成类：提升大，但主要是第 2 天就完成了大部分进化。这说明这类任务的主要瓶颈是"环境配置类问题"（文件路径、工作目录、格式要求），而不是"创作能力类问题"。一旦技能里把这些环境配置的具体要求写清楚，成功率就能大幅提升。后续几轮进化提升趋缓，是因为"低垂的果实"已经摘完了，剩下的是更难泛化的问题。

安全对齐类：进化最晚，是因为这类任务的失败往往不是一个简单的配置错误，而是涉及更复杂的执行可靠性问题（如 Git 认证失败的多种情况、不同环境下的目录权限问题）。这类问题需要积累更多的多样化失败案例，Evolver 才能从中归纳出足够通用的改进方案，而不是只针对某个特定场景打补丁