SkillClaw 到底值不值得看：它解决的不是“会不会用工具”，而是“Agent 怎么把经验真正积累下来”

很多 agent 项目都在谈“自我进化”。但真把它放进生产环境，你很快会碰到一个更现实的问题：

不是 agent 会不会进化，而是它学到的东西，能不能留得住，能不能传得开，能不能被别人复用。

SkillClaw 想解决的，就是这件事。

它不是一个新的大而全 agent 框架，也不是一个取代 Hermes、OpenClaw 这类 agent 的东西。按照官方仓库和论文里的定义，它更像是一层“经验收集 + 技能演化 + 群体共享”的外置基础设施：前面接 agent，后面连共享存储和演化服务，把原本散落在不同用户、不同会话、不同 agent 实例里的经验，慢慢整理成可以反复复用的 Skill。

如果一句话概括：

SkillClaw 不是在教 agent “第一次怎么做”，而是在解决 agent “做过之后，怎么别白做”。

SkillClaw 是什么

基于 GitHub 仓库里的 README、代码结构和 arXiv 论文，SkillClaw 主要由两部分组成：

1. 本地 Client Proxy
2. 共享的 Evolve Server

Client Proxy 跑在用户本地，暴露的是常见的 API 入口，比如 /v1/chat/completions、/v1/messages，代码里还实现了 /v1/responses。它会拦截 agent 发给模型的请求，在请求进入上游模型之前做几件事：

• 注入本地可用技能
• 记录会话轨迹和工具调用相关信息
• 在启用时做 PRM 式反馈打分
• 把技能和会话数据跟共享存储同步

Evolve Server 则是后面的“技能工厂”。它从共享存储里读取会话数据，按 skill 相关性做归纳，然后把结果变成新的技能，或者更新旧技能，再写回共享存储。

官方文档里给了两个演化引擎：

• workflow：固定三段式流程，Summarize → Aggregate → Execute
• agent：通过 OpenClaw 驱动的 agent 工作区，直接改 skill

这套设计的核心意思很清楚：

前端每个人继续正常用 agent，后端单独有一套机制，专门处理“经验怎么变成技能”这件事。

它到底在解决什么问题

1. 解决“经验孤岛”

现在很多 agent 都能在单次任务里表现得不错，但问题在于，经验大多停留在这一次会话里。

A 用户踩过的坑，B 用户还得再踩一遍。 一个团队里五个人分别找到了五个有效工作流，最后很可能谁也没把它们沉淀成统一能力。

SkillClaw 的出发点就是： 把跨用户、跨时间的真实使用轨迹，当成最重要的训练信号。

这点很关键。很多系统强调 prompt engineering，或者强调单次任务内的反思，但 SkillClaw 更关心“持续运营中的经验沉淀”。这也是它和很多只在单 agent、本地 profile 内自学习的设计不一样的地方。

2. 解决“技能是静态文件，不会跟着使用演化”

大多数 skill 系统本质上还是一个知识包管理系统：

• 人写一个 skill
• 放进 skills 目录
• agent 读它
• 用完结束

这当然有用，但它更像“手工维护文档”，不是“运行中持续进化的系统”。

SkillClaw 想做的是把技能从静态资产，变成动态资产。

论文摘要里说得很直接：现有系统缺少一种机制，能把不同用户、不同场景下的异构经验，转换成可靠的技能更新。SkillClaw 的目标就是补上这一步。

3. 解决“多 agent / 多框架环境下，能力没法共享”

现实里很多团队不会只跑一种 agent。

有的地方用 Hermes，有的地方用 OpenClaw，有的产品前端接的是 OpenAI 兼容接口，有的又需要 Anthropic 风格接口。

SkillClaw 在这点上有明显工程取向：它不是强行要求大家换框架，而是走代理层兼容。

从 README 和代码看，它至少做了这些事情：

• 对外提供 OpenAI 风格接口
• 兼容 Anthropic /v1/messages
• 实现了 /v1/responses 的转换路径
• README 声称支持 Hermes、OpenClaw，以及更多 Claw 系 agent
• 代码里已经有 Hermes、OpenClaw、CoPaw、IronClaw、PicoClaw 的适配逻辑

这意味着它更像一个“可插拔的进化层”，而不是一套要你重写产品架构的东西。

它是怎么工作的

如果把 SkillClaw 的逻辑拆开看，其实并不玄学，反而挺工程化。

第一步：每个用户照常用自己的 agent

用户机器上跑的是 SkillClaw client proxy。

它不要求用户改工作方式。README 里反复强调的一点是：你还是像平常一样聊天、跑任务；客户端侧的记录与同步尽量做成透明流程，而真正的自动技能演化需要再接上 evolve server。

第二步：代理层拦截请求，记录有价值的轨迹

本地 proxy 会接住 agent 请求，把技能注入系统提示里，再把请求转发给上游模型。

在这个过程中，它会记录：

• 当前会话的轨迹
• 本轮注入了哪些 skill
• 工具调用相关信息
• 可选的 PRM 反馈分数

代码里还能看到一个比较实在的设计：不是所有流量都会被一股脑拿去做主训练信号。比如 side task 和 main turn 在处理上就有区分。这说明它不是简单“全量日志堆起来”，而是想尽量保留更有价值的样本。

第三步：技能先在本地和共享存储之间同步

SkillClaw 使用的 skill 格式是 SKILL.md，并且兼容 AgentSkills / OpenClaw 那套目录结构。

共享存储支持：

• 本地文件系统
• Alibaba OSS
• S3 兼容存储

也就是说，它不是把“经验”塞进一个黑盒数据库，而是把沉淀结果落成相对标准化的技能文件。这对工程团队很重要，因为可检查、可回滚、可迁移。

第四步：Evolve Server 把会话变成技能更新

workflow 引擎的主流程，在代码里写得很直白：

1. 读取待处理会话
2. 总结会话
3. 视情况补 session judge 分数
4. 按 skill 做聚合
5. 对已有 skill 做演化，或者从无 skill 的会话里创建新 skill
6. 上传 skill，更新 registry，再确认已处理会话

这里最值得注意的是，它不是只会“新建 skill”，也会对已有 skill 做 merge 和更新。出现内容冲突时，workflow 引擎还会尝试 merge，而不是简单覆盖。

第五步：如果你担心自动演化太激进，还可以加验证层

这是 SkillClaw 一个比较成熟的地方。

它不是默认所有候选 skill 直接进共享目录。服务端有两种 publish mode：

• direct：直接发布
• validated：先进入验证任务，再决定发不发

验证机制也不是纯口头说说。代码里已经做了：

• 服务端把候选 skill 变成 validation job
• 选择加入的客户端只有在本地代理空闲时才会去接 job
• 客户端会对 candidate 和 baseline 做 replay 对比
• 再结合阈值、均分、拒绝次数等条件决定接受还是拒绝

而且验证 worker 默认关闭、只在共享模式下启用，还有限制每日 job 数量。这套设计明显是在尽量避免“为了进化，把在线用户体验搞坏”。

SkillClaw 解决了什么行业难题

我觉得它碰到的是 agent 产品化里几个很典型、但很少有人认真补的坑。

难题一：Agent 结果看起来聪明，但组织层面并不变强

单个 agent 一次次完成任务，不等于整个系统在变强。

如果能力沉淀只留在当前对话、当前实例、当前用户目录里，那系统整体还是在重复交学费。

SkillClaw 想解决的是“组织级别的学习”，不是“单回合表现优化”。

难题二：经验很多，但没有可靠办法转成可复用资产

真实世界里的 agent 轨迹非常脏：

• 有成功有失败
• 有些场景通用，有些场景只适合局部
• 不同用户说法不同，但本质在做相似事情

把这些异构经验提炼成可复用 skill，本来就不容易。

SkillClaw 走的办法不是一步到位，而是拆成：记录、汇总、聚合、验证、发布。这个流程比“让模型直接从日志里自动学”要保守，但更适合生产环境。

难题三：跨框架共享很难

很多产品团队既不想被某个 agent 框架绑死，也不希望每换一个 agent 就把技能系统重做一遍。

SkillClaw 的代理层路线，实际是在解决“框架变化快，但技能沉淀要稳定”这个问题。

它的优势到底在哪

1. 它强化的是“群体学习”，不是单体学习

Hermes 这类 agent 自己也能通过 skill、memory 和 user profile 形成内建学习闭环；但它们公开文档主要描述的是单个部署内部的持续学习，而不是像 SkillClaw 这样把多用户、多实例轨迹汇入独立共享层统一演化。

SkillClaw 的优势在于，它把这些经验拉到一个共享层里，允许一个用户踩出来的路径，变成整个群组能复用的技能。

这不是能力替代，而是能力放大。

2. 它把“进化”从 agent 内核里抽了出来

这点工程价值很高。

如果进化逻辑完全绑在某个 agent 框架内部，那你换框架、换模型接口、换部署方式，学习机制很可能就断了。

SkillClaw 把它抽成 proxy + evolve server + shared storage 后，进化层和 agent 执行层就没那么强耦合了。

3. 它对生产环境更谨慎

从代码能看出来，SkillClaw 不只是“会自动更新技能”，它也在认真处理上线风险：

• 可以 direct，也可以 validated
• 验证只在 idle 时跑
• 有每日额度
• 有阈值、均分、拒绝数限制
• 有 manifest、sha256、版本更新这些比较传统但很重要的治理手段

这意味着它不是 demo 风格的“自动进化一下看看”，而是在往可运营系统靠。

4. 它不是只能服务一种产品形态

只要你的产品本质上是：

• 多用户
• 会持续产生 agent 轨迹
• 希望把经验沉淀成可复用工作流
• 又不想被单一 agent 框架彻底锁死

SkillClaw 就有接入意义。

哪些产品比较适合接 SkillClaw

我觉得最适合的是下面几类。

1. 多租户 Agent 产品

比如面向企业的 AI 助手、客服辅助、运营 Copilot、销售助理、研发助手。

这类产品最痛的地方不是“第一天能不能跑起来”，而是“半年后是不是还在重复同样的问题”。

2. 团队内部共享工作流很重要的系统

比如运维、数据分析、投研、内容生产、自动化运营。

这些场景里，最有价值的不是单次回答，而是那些慢慢磨出来的做事套路。SkillClaw 正好适合把这些套路变成共享 skill。

3. 同时跑多种 agent 框架的组织

如果你的团队里 Hermes 和别的 agent 都在用，那 SkillClaw 这种外挂式、代理式方案就比在每个框架里各自做一套进化逻辑更省事。

4. 想先本地用，后面再扩成群组协作的团队

README 里这一点写得很清楚：

• 你可以先只装 client
• evolve server 以后再加
• 从单用户升级到多用户，主要变化就是共享配置

这对落地很重要，因为它降低了试错成本。

Hermes-agent 已经有进化能力了，为什么还需要 SkillClaw

这是最值得聊的部分。

Hermes 本身确实已经有“闭环学习”能力，而且还不弱。

从 Hermes README 和文档看，它已经具备：

• 持久化 memory
• 持久化 user profile
• 任务后沉淀 skill
• skill 在后续会话中继续复用
• 跨会话检索和 recall
• agent 在使用过程中对 skill 做更新

所以如果你的使用场景是：

• 单用户
• 单 profile
• 主要在自己的 Hermes 环境里工作
• 更看重 agent 个人助手体验

那 Hermes 自己那套能力，很多时候已经够了。

但 SkillClaw 补的是 Hermes 原生机制不主打的几件事。

第一，SkillClaw 更强调跨用户共享

Hermes 的 skill、memory 和 user profile 当然能持久化，也支持跨会话 recall；但它的公开设计重点仍是单个 Hermes 体系内的连续性，而不是跨多个独立用户/实例的共享技能运营。

SkillClaw 的重点则是把不同用户的真实轨迹汇到共享存储，再通过 evolve server 变成群体可用技能。这是“个人成长”和“组织学习”的区别。

第二，SkillClaw 更强调框架无关

Hermes 的进化能力天然服务于 Hermes 自己。

SkillClaw 则是想做在 Hermes、OpenClaw 以及 OpenAI / Anthropic 兼容接口之上的一层公共进化基础设施。对于同时维护多个 agent 产品线的团队，这个差别非常大。

第三，SkillClaw 更像有治理层的技能供应链

Hermes 的强项在 agent 体验本身：工具、平台接入、记忆、技能、子代理、cron，都很完整。

SkillClaw 的强项则在技能供应链：

• 如何收集轨迹
• 如何聚合成候选 skill
• 如何做共享分发
• 如何验证后再发

如果说 Hermes 更像“一个会成长的 agent”，那 SkillClaw 更像“一个给 agent 集群做技能运营的系统”。

第四，SkillClaw 能把 Hermes 的本地成长放大成群体成长

这也是两者最合理的关系：不是二选一，而是叠加。

Hermes 负责把单个用户面前这台 agent 用顺、用强；SkillClaw 负责把不同 Hermes 实例积累下来的有效经验，抽成共享技能，扩散到更多实例上。

也就是说：

• Hermes 更像前台执行者
• SkillClaw 更像后台演化层

SkillClaw 和 Hermes 里“相似逻辑”的区别

两边确实有重叠：都会围绕 skill 做沉淀、复用、更新。

但落点不同。

Hermes 的同类逻辑更偏“会话内外的个人连续性”

Hermes 把 memory、user profile、skill、session search 这些东西串起来，重点是让同一个 agent 越来越懂同一个用户，也越来越适应同一个环境。

SkillClaw 的同类逻辑更偏“群体经验外化”

SkillClaw 更关心的是：

• 一个 skill 是否被反复注入
• 它效果如何
• 多个用户是否反复暴露出相似模式
• 这些模式能不能升级成共享技能
• 升级后是否值得发布给更多 agent

所以两者的核心差异，不是有没有“进化”，而是谁在进化、为了谁进化。

• Hermes：以 agent 和用户的长期关系为中心
• SkillClaw：以 agent 群体和共享技能库为中心

这套东西有什么边界

SkillClaw 不是没有代价。

从仓库设计看，想把它用到完整形态，至少要接受几件事：

• 多一层代理
• 多一套共享存储
• 真正发挥价值时，还要跑 evolve server
• 如果要更稳，还要加 validation worker

所以它不是“装完马上所有 agent 都变聪明”的魔法包。

如果只是一个人本地折腾几个小任务，它可能有点重。

但如果你在做的是线上 agent 产品，或者至少是一个多人、多实例、持续运行的 agent 系统，那这套成本是讲得通的，因为它对应的是长期复利。

最后怎么判断它值不值得接

我觉得判断标准很简单。

如果你现在最痛的是：

• agent 本身还不够能干
• 工具链还没接好
• 单个实例都没跑顺

那先别急着上 SkillClaw，先把基础 agent 能力跑通。

但如果你已经进入下一阶段，开始遇到这些问题：

• 用户一多，重复问题开始堆
• 不同实例学到的经验传不开
• skill 还停留在人工维护文档
• 你需要一层更稳定的技能分发和演化机制

那 SkillClaw 就值得认真看。

它最有价值的地方，不是让 agent 看起来更聪明一瞬间，而是让一个 agent 系统有机会随着使用人数增加，真的越用越强。

对单个 agent 来说，这叫学习。 对一个产品来说，这叫复利。