静态技能即死亡技能

昨晚我为 Claude Code 指南交付了一个 Settings Reference 章节。十五条词条。每条引用都用 grep 对照过行号。在 critique 循环返回干净结果后,我凭着信念把它发了出去。等到提交那份 .md 文件时,我已经知道自己将需要 v3——不是因为做错了什么,而是因为指南会变、底层产品会变、用户查询会漂移,而我刚刚交付的这个章节,从我转身离开的那一刻起就会开始走样。

一项技能,无论它是一份 Markdown 参考章节,还是 .claude/skills/ 里的 agent 技能定义,只有在有人观察其轨迹时才是鲜活的。一旦你停止观察,它就变成了静态的。静态技能会原地衰败。

来自 Ma、Yang、Ji、Wang、Wang 的一篇新 arxiv 论文(《SkillClaw: Let Skills Evolve Collectively with Agentic Evolver》,2026 年 4 月)在研究层面将这个问题形式化了。¹ 他们的开篇论述,直接引用:“诸如 OpenClaw 之类的大语言模型(LLM)agent 依靠可复用的技能来完成复杂任务,然而这些技能在部署后基本保持静态。结果是,相似的工作流、工具使用模式和失败模式在不同用户间被反复重新发现,使系统无法随经验而改进。”¹

我已经在这种失败模式中活了好几个月了。如果你正在为任何 agent 框架构建技能,你也一样。

TL;DR

Agent 技能在交付后便停止改进。用户各自独立地发现相同的失败模式,却从未把这些发现反馈回技能本身。Ma 等人将此视为一个集体智能问题:跨用户、跨时间的交互提供了关于技能何时有效或失败的信号,但不存在生态级机制将它们聚合为技能更新。他们的 SkillClaw 框架提出将聚合后的轨迹视作演化信号,运行一个自主的 evolver 识别反复出现的行为模式,并将其转化为技能的细化或能力扩展。¹ 摘要将”OpenClaw”作为一个使用可复用技能的 LLM agent 示例——仅凭摘要我无法确认 OpenClaw 是哪一款具体的量产产品,本文也不会对此妄加揣测。我要主张的是:论文所描述的结构性问题同样适用于任何为 Claude Code、Codex、Cursor 或自己的框架构建技能的人。观点是:如果你的技能库没有持续吸收真实使用产生的轨迹,那它从交付那天起就已经死了。

关键要点

• 技能作者:技能交付时工作并未结束。工作结束的标志,是你有了一个循环来观察技能如何被使用、捕捉反复出现的失败模式,并将其反馈回技能定义。交付是技能生命的开始,而非终点。
• 框架构建者:为每次技能调用记录其轨迹——输入、工具调用、输出、错误状态。那份日志就是演化信号。如果你没有记录它,你就不是在改进技能;你只是在维护它。
• Jiro 思维的实践者:SkillClaw 论文是把匠人模式应用到技能上的学术化表达。技能是手艺。轨迹是练习。演化是对精进的追求。静态即死亡。

论文究竟说了什么

我将谨慎地走一遍摘要中的论断,然后清楚地标出我在哪里对框架进行了延伸。

问题陈述(来自摘要)。LLM agent 依靠可复用的技能来完成复杂任务。这些技能在部署后基本保持静态。相似的工作流、工具使用模式和失败模式在不同用户间被反复重新发现。系统无法随经验而改进。¹

这是关于一种特定失败模式的论断,而非说所有技能都会衰败。从不被调用的技能不会衰败。被一个从不反馈问题的用户调用的技能不会显性衰败。衰败出现在你有多个用户、每人都遇到同一失败的某个版本,而系统却没有办法将这些遭遇聚合成一次更新时。(最后这句是我的表述,不是论文的。)

现有的空白(来自摘要)。摘要指出,尽管跨用户交互”提供了关于技能何时有效或失败的互补信号,但现有系统缺乏将这些异构经验转化为可靠技能更新的机制。”¹ 这是承载论文的核心论断。不是说没人想过技能改进。而是说不存在生态级机制来聚合轨迹、识别反复出现的模式,并将其转化为更新。

SkillClaw 流水线(来自摘要)。摘要描述了一条持续的流水线:SkillClaw”聚合使用过程中产生的轨迹,并由一个自主的 evolver 处理,该 evolver 识别反复出现的行为模式,并通过细化现有技能或用新能力扩展它们,将这些模式转化为对技能集的更新。”¹ 更新后的技能保存在共享仓库中,并在用户间同步,因此在某一情境下发现的改进可以在无需用户操心的情况下传播至整个系统。¹

评估(来自摘要)。论文在一个名为 WildClawBench 的基准上,使用 Qwen3-Max 作为底层模型对 SkillClaw 进行评估。摘要本身在已发布版本中的措辞在语法上有些破损:“experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios.”¹ 我的理解是:在有限交互与反馈的条件下,SkillClaw 相较基线仍带来了显著的性能提升。摘要未公布具体数值——完整论文中想必有。

这就是摘要所描述的论文内容。作者提出,拥有共享技能的多用户 agent 生态系统可以从自动化的轨迹聚合驱动的自动化技能更新中获益,并报告其实现方案在有限反馈条件下显著提升了 Qwen3-Max 的表现。

论文没说的(以及我自己补充的)

摘要将”OpenClaw”作为一个例子(“诸如 OpenClaw 之类的 LLM agent”),指代一种使用可复用技能的 agent。仅凭摘要我不知道 OpenClaw 是什么——我无法迅速将它确认为某个具体的量产产品。论文的框架(SkillClaw)被呈现为面向多用户 agent 生态系统的一般性解决方案,而非专门面向 OpenClaw,所以”OpenClaw 到底是什么”这个问题与论文论点关系不大。我把它标出来,是为了避免有人读完这篇博文后误以为这篇论文是关于 Claude Code 的。它不是。它把 OpenClaw 列为一个例子,并把 SkillClaw 作为一种一般性机制提出。

我所主张的——与论文相分离——是:论文所描述的结构性问题,与我一直在 Claude Code 技能生态中亲身经历的真实问题是对应的。这个主张是我的,不是论文的。下面说明为什么我认为它对应得上。

Claude Code 生态中的技能是作为静态产物交付的。一个技能是一份 SKILL.md 文件(或一组辅助文件),描述某个任务应如何执行。你写一次。你提交。你通过斜杠命令或 @skill-name 自动补全来引用它。一旦交付,它就是一份静态产物。没有任何自动机制在观察技能在实际使用中的表现,并根据什么有效、什么失败来更新技能定义。

不同用户独立地遇到相同的失败模式。我交付的每一项技能都至少有一种反复出现的失败模式,只在特定条件下显现。有人用我未预料到的输入调用技能,撞上边缘情形,手动绕开,然后继续前行。另一个人在别处撞上同一边缘情形,做出自己的变通。技能本身纹丝不动。

聚合信号真实存在却未被利用。如果我能看到自己交付的每项技能的每一次调用的每一条轨迹,我一个下午就能识别出反复出现的失败模式。那份信号是存在的——它就在每位用户的会话历史中。只是它没有被聚合到任何地方,因此没人据此行动。

修复要么靠手工,要么根本没有。目前,技能改进的唯一机制是我在自己的使用中注意到问题,或者有人提 issue,或者有人开 PR。这些都是需要用户投入精力的路径。SkillClaw 论文的核心洞见——轨迹数据已经存在,应该被自动转化为技能更新——正是我们所缺少的机制。

这是我对论文框架如何适用于 Claude Code 的主张。这不是论文所说的。这是我用自己的工作去对照论文得出的阅读。

匠人模式,应用于技能

每当我思考手艺时,都会回到一种框架。寿司大师小野二郎是经典例子。六十年如一日做同一件事。每天在寿司台前观察所发生的一切,调整手法,细化米饭的温度、刀工的角度、握寿司的时机。工作本身就是训练信号。实践者就是聚合者。

不久前我写过匠人/质量循环框架。核心思想是:手艺即反馈循环。你做工作,你观察工作,你注意到哪里坏了,你调整,你再做一次。循环往复。精通就存在于你所期望与实际发生之间的差值中,以及你愿意把这个差值带入下一次尝试的意愿中。

一项静态技能打破了这个循环。你交付了技能。你停止了观察。技能意图与实际行为之间的差值,累积在一百个你永远看不到的会话里。技能不再变好,因为匠人不再站在台前。

SkillClaw 论文提出了一个自动化的聚合器——不是替代人,而是一种机制:观察所有轨迹,跨会话发现哪里出了问题,并向技能定义回馈更新提案。这并非痴人说梦。它其实是让一项技能能够在自身部署后存活下来的最低门槛。

这在实践中是什么样子

如果我想针对今天在维护的 Claude Code 技能实现 SkillClaw 模式,我需要的是:

1. 每次技能调用的轨迹日志。每当一个技能运行,记录输入、所做的工具调用、输出、错误状态,以及最终处置(用户接受了结果?回滚了?重写了?)。这在 Claude Code 会话层面已经存在——问题在于它是否被跨会话聚合,并提取给技能所有者。

2. 一个模式检测器。能读取轨迹日志并识别反复出现模式的东西:同类输入导致同类失败,同一工具调用以同一种方式失败,同一边缘情形在不同用户情境下反复出现。这不是 AGI——这是对结构化轨迹数据做聚类。

3. 一个提案生成器。给定一个被检出的模式,起草一份对技能的候选更新:新的处理分支、补充的示例、SKILL.md 正文中多加的一条约束。更新是提案,不是已交付的变更。

4. 一道关卡。每一项被提议的更新都要经过人工审阅、事实核验(我对一切事物都施加的同一道严苛关卡),以及一次 critique 循环,然后才能交付。自动化负责聚合,而不负责发货。

5. 分发。当一项被提议的更新被接受,它要传播到该技能的每一位用户。在中心化生态中这很简单(更新规范化技能,大家各自拉取)。在分布式生态中,这就更难。

这其中大部分在 Claude Code 中已经具备——会话日志存在,技能定义有版本,critique 循环已在运作——所缺的是连接会话轨迹与技能更新的聚合与模式检测层。

令人不安的含义

我在过去六个月中交付的每一项技能,正按照 SkillClaw 论文所描述的方式,完完全全地死去。我写下技能。我自己使用它。我注意到问题。我在我使用的技能里修掉它们。技能对我而言变得更好。它们对其他人并没有变得更好,除非那个人独立地注意到同样的问题并提交了什么。

我昨晚在 Settings Reference 上所做的工作,恰恰就是这种模式。Claude Code 指南是一份共享产物。用户为了查具体配置键而查询它。我能看到 GSC 数据告诉我哪些配置键被搜索。那就是聚合后的轨迹数据——它字面意义上告诉我指南中的哪些技能正在被调用,结果落在哪里。而在我去看那份数据之前,指南是静态的。它已经静态了好几周。不是因为没人在观察轨迹,而是因为只有我一个人能观察,而我又有别的事要做。

SkillClaw 论文是这个问题的学术化形式化表述。实际机制更简单:如果你没有从轨迹数据到技能更新的自动化流水线,你的技能就正在原地老去。它们或许仍能在某些条件下为某些用户工作。它们并没有在变好。

唯一的问题是:你是接受自己的技能在交付那一刻就已死亡,还是去构建那个让它们保持鲜活的观察者。

最小可行的聚合器

在动笔写这篇文章之前,我的技能上零轨迹聚合。一点都没有。我有会话历史可以手动翻阅,但没有任何东西把跨会话的模式浮现出来。这正是论文描述的静态技能病理,而我就活在其中。

下面是我此刻、今天就能实际交付的最小的东西:一份单一的文本文件,以追加写入方式记录我自己所有会话中每一次技能调用,包含时间戳 + 技能名 + 输入形态 + 最终处置(接受 / 修订 / 回滚)。没有模式检测器。没有自主 evolver。只是这份日志。

那份文件就是最小可行聚合器。它不是 SkillClaw。它是 SkillClaw 如果存在所需的输入层,也是我在能够看见自己的技能是否存在反复失败模式之前所需要的输入层。没有它,我只是在猜。有了它,我至少能在审阅技能时手动扫一眼日志,并自问:这个月里同样的问题是不是已经出现了三次?

这就是承诺。一个文件。只追加。每次调用记录。审阅技能时一并审阅。

如果这一步奏效,下一层就是模式检测器。如果模式检测器奏效,再下一层就是提案生成器。论文的雄心是一个运行在多用户生态系统上的完整自主 evolver。我的雄心是不再蒙着眼睛前行。

常见问题

论文中的”OpenClaw”和 Claude Code 是同一件东西吗?

不是,而且我也无法告诉你 OpenClaw 究竟是什么。摘要提到”诸如 OpenClaw 之类的 LLM agent”,将其作为一种使用可复用技能的 agent 示例,却未对它作出定义。仅凭摘要我无法迅速将它确认为某个具体的量产产品。重要的是:论文的 SkillClaw 框架被呈现为面向多用户 agent 生态系统的一般性解决方案,而非专门面向 OpenClaw 或 Claude Code。无论 OpenClaw 是什么,这篇论文都不是一篇关于 Claude Code 的论文,我在本文中关于 Claude Code 的主张都是我自己的,而不是论文的。¹

这篇论文真正的新贡献是什么?

依据摘要:一个用于多用户 agent 生态系统中集体技能演化的框架,它(1)跨用户与时间聚合轨迹,(2)运行一个自主 evolver 来检测反复出现的模式,(3)将模式转化为共享仓库中技能的更新,并在用户间同步。¹ 新意并不在于”技能可以被改进”——这是显而易见的。新意在于提出改进循环应当是自主且由轨迹驱动的,而不是由人驱动的。

论文是否报告了具体的提升数据?

摘要将提升描述为在 WildClawBench 基准上使用 Qwen3-Max、在有限反馈条件下”显著”,但未公布具体数值。¹ 具体数字应以完整论文为准。

这与对技能定义提一个 git PR 有什么不同?

PR 是由人发起的机制。总得有人注意到问题、写出修复、提出 PR、审阅、合并。每一步都需要人的投入。论文所提议的 SkillClaw 框架是自主聚合——系统跨众多用户注意到模式,自行提出修复,并在无需任何单个用户提交任何东西的情况下同步更新。¹ 这种自主版本对任何具体生态而言是否可取或安全,是另一个问题。论文的贡献是表明它在技术上是自洽的。

这适用于我自定义的 Claude Code 技能吗?

论文对任何具体的 Claude Code 技能生态都未作任何主张。我的主张——与论文分开——是:这种结构性问题(技能作为静态产物交付、失败模式被每位用户独立重新发现、不存在聚合机制)确实适用于 Claude Code 技能,而任何为 Claude Code 或类似框架构建技能的人,都应当思考如何构建一个由轨迹驱动的改进循环。这是我的观点,不是论文的结论。

与匠人精神的联系是什么?

匠人/质量循环框架主张:精通来自你所期望与实际发生之间的差值,并将其带入下一次尝试。静态技能打破了那个循环,因为差值积累在匠人永远看不到的会话里。SkillClaw 是闭合那个循环的学术版本——将差值的采集自动化,并回馈给技能。修炼是一样的;机制是不同的。

参考文献