静态技能即死技能

昨夜我为Claude Code指南发布了一个Settings Reference章节。十五条条目。每一处引用都通过grep比对过行号。在批判循环返回干净结果后，我凭信念将其推送上线。就在我提交.md文件之际，我已经知道自己还需要v3版本——不是因为哪里做错了，而是因为指南在变化，底层产品在变化，用户查询在迁移，而我刚刚发布的这一章节，从我离开它的那一刻起便会开始漂移。

一项技能（无论是一份Markdown参考章节，还是.claude/skills/中的某个agent技能定义），只有在有人观察其轨迹时才算活着。一旦你停止观察，它便沦为静态。静态技能原地衰减。以下这篇文章属于AI engineering系列，记录agent基础设施在生产环境中如何演化。

静态的AI agent技能之所以失效，是因为它们一上线就停止了学习。如果没有一条反馈回路来摄入真实的调用轨迹（实际使用中的输入、工具调用、输出与错误状态），技能便无法适应不断变化的产品、流转的用户查询，或是反复出现的失败模式。多位用户各自独立地重新发现相同的变通方案，而技能定义始终原地冻结。解法在于：持续的轨迹聚合，将使用模式转化为自动化的技能更新。

Ma、Yang、Ji、Wang与Wang于arxiv上发表的新论文（《SkillClaw: Let Skills Evolve Collectively with Agentic Evolver》，2026年4月）在研究层面对这一问题进行了形式化。¹他们的开篇表述，原文直引：“Large language model (LLM) agents such as OpenClaw rely on reusable skills to perform complex tasks, yet these skills remain largely static after deployment. As a result, similar workflows, tool usage patterns, and failure modes are repeatedly rediscovered across users, preventing the system from improving with experience.”¹

我已经在这种失败模式中生活了数月。若你正在为任何agent框架构建技能，你也一样。

TL;DR

Agent技能在发布之后便停止改进。用户各自独立地发现相同的失败模式，却从未将这些发现反哺回技能本身。Ma等人将其框定为一个集体智能问题：跨用户与跨时间的交互本是关于某项技能何时奏效、何时失败的信号，但目前不存在生态系统级的机制来将它们聚合为技能更新。他们提出的SkillClaw框架将聚合后的轨迹视为演化信号，运行一个自主演化器来识别反复出现的行为模式，并将其转化为技能精修或能力扩展。¹摘要中以”OpenClaw”作为LLM agent的示例。仅凭摘要，我无法确认OpenClaw究竟是哪款已上线的产品，因此本文不作臆测。我要主张的是：该论文所描述的结构性问题，映射到了任何为Claude Code、Codex、Cursor或自有agent框架构建技能的人身上。要点：若你的技能库没有持续摄入真实使用中的轨迹，那它从发布那天起就是死的。

关键要点

• 技能作者：工作不在技能发布时结束。工作在于你拥有一条回路——能够观察技能如何被使用、捕捉反复出现的失败模式，并将其反馈回技能定义。发布是技能生命的起点，而非终点。
• 框架构建者：为每一次技能调用记录其轨迹：输入、工具调用、输出、错误状态。这份日志就是演化信号。若未记录，你便不是在改进技能，而仅仅在维护它们。
• Jiro心智的实践者：SkillClaw论文是用学术语言表达的Shokunin模式在技能上的应用。技能即手艺。轨迹即修炼。演化即对大师之境的追求。静态＝死亡。

论文实际上说了什么

我将审慎地逐条梳理摘要中的主张，然后清晰地标注出何处是我本人对框架的延伸。

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

作者所针对的是一种特定的失败模式，而非”所有技能都会衰减”这一普适论断。从未被调用的技能不会衰减。某位用户调用而从未报告问题的技能也不会以可见的方式衰减。衰减显现于多位用户各自遭遇同一失败的不同版本，而系统无从将这些遭遇聚合为单一更新之时。（最后这句是我的表述，并非论文原话。）

既有的缺口（出自摘要）。摘要指出，尽管跨用户交互”provide complementary signals about when a skill works or fails, existing systems lack a mechanism to convert such heterogeneous experiences into reliable skill updates.”¹承重性的论断就在此处。缺口并非无人思考过技能改进。缺口在于：不存在生态系统级的机制来聚合轨迹、识别反复出现的模式，并将其转化为更新。

SkillClaw流水线（出自摘要）。摘要描述了一条持续流水线：SkillClaw”aggregates trajectories generated during use and processes them with an autonomous evolver, which identifies recurring behavioral patterns and translates them into updates to the skill set by refining existing skills or extending them with new capabilities.”¹系统在共享仓库中维护更新后的技能，并在用户间进行同步，使得在某一情境下发现的改进能在系统内传播，无需用户付出额外努力。¹

评估（出自摘要）。论文在名为WildClawBench的基准上对SkillClaw进行了评估，底层模型采用Qwen3-Max。摘要在已发表版本中的表述语法不完整：“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”作为一个示例（”LLM agents such as OpenClaw”），代表一款使用可复用技能的agent。仅凭摘要，我不知道OpenClaw究竟是什么；我也无法迅速确认它是哪款已上线的产品。论文的框架（SkillClaw）面向的是一般意义上的多用户agent生态，而非专门针对OpenClaw——因此”OpenClaw是什么”这个问题与核心论点基本无关。我在此标注出来，是为了避免读者读完本文后误以为该论文是关于Claude Code的。它不是。它将OpenClaw作为示例提及，并将SkillClaw作为通用机制提出。

我在此所主张的——独立于该论文——是：论文所描述的结构性问题，映射到了我在Claude Code技能生态中正亲历的真实问题。这一主张归我所有，而非论文本身。以下是我认为可以映射的理由。

Claude Code生态中的技能以静态产物的形式发布。一项技能是一份SKILL.md文件（或配套文件包），描述某任务应如何执行。你编写一次，提交一次。你通过斜杠命令或@skill-name快捷输入来引用它；构建自定义技能的机制十分直接。一旦发布，它便是一件静态产物。没有任何自动机制去观察技能在实践中如何被使用，或根据何者奏效、何者失败来更新技能定义。

不同用户各自独立地遭遇相同的失败模式。我所发布的每项技能，至少都有一种只在特定条件下浮现的反复性失败模式。有人以我未曾预料的输入调用该技能，撞上边界情况，手动变通，然后继续前行。另一人在别处撞上同一边界情况，做出自己的变通。技能本身始终未变。

聚合信号真实存在但未被利用。倘若我能看到我所发布的每项技能每一次调用的每条轨迹，我可以在一个下午识别出反复出现的失败模式。该信号存在于每一位用户个人的会话历史中。只是它从未在任何地方被聚合，所以无人据其采取行动。

解法要么靠人工，要么干脆缺失。眼下，技能改进的唯一机制，是我自己在使用中注意到问题、或有人提交issue、或有人发起PR。所有这些路径都需要用户付出努力。SkillClaw论文的核心洞见——轨迹数据早已存在，理应自动反哺技能更新——恰恰是我们缺失的机制。

这就是我关于论文框架如何适用于Claude Code的主张。它并非论文所说。它是我以自身工作为镜来阅读这篇论文的方式。

Shokunin模式，应用于技能

每当我思考手艺时，总有一个参照不断浮现。寿司大师小野二郎即是典范。六十年如一日，从事同一件工作。每天，他观察柜台前发生的一切，调整技法，精修米饭的温度、刀的角度、握寿司的时机。工作本身即是训练信号。从业者即是聚合器。

我此前写过Shokunin／质量回路的框架。核心在于：手艺即反馈回路。你做这件事，你观察它，你注意到哪里出了问题，你调整，你再做一次。周而复始。大师之道栖于”你所期望”与”实际发生”之间的差值，以及你将此差值带入下一次尝试的意愿。

静态技能打破了这条回路。你发布技能。你停止观察。技能所期望与实际发生之间的差值，在你永远看不到的上百段会话里不断累积。技能不会变好，因为匠人已经不在柜台前。

SkillClaw论文提出了一种自动化的聚合器：不是要取代人，而是一种机制——它观察所有轨迹，注意到跨会话中出了什么问题，并提出对技能定义的更新建议。这一雄心并不疯狂。事实上，如果你想让一项技能在自身部署之后还能存活，这就是最低门槛。

在实践中这意味着什么

若我想为自己今天维护的Claude Code技能构建SkillClaw模式，我会需要以下条件：

1. 针对每一次技能调用的轨迹日志。每次技能运行时，记录输入、它所发起的工具调用、输出、错误状态，以及最终归宿（用户接受了结果？回退了？重写了？）。Claude Code中已存在会话级日志；问题在于它是否在会话间进行聚合，并为技能所有者进行抽取。

2. 一个模式检测器。能够读取轨迹日志并识别反复出现的模式：同一输入类别导致同一失败、同一工具调用以同样方式失败、同一边界情况在不同用户情境下反复出现。所需的是针对结构化轨迹数据的聚类，而非AGI。

3. 一个提议生成器。对检测到的模式，起草一条候选的技能更新：新的处理分支、额外的示例、SKILL.md正文中多加一条约束。这项更新是一条提议，而非已发布的变更。

4. 一道闸门。每条提议的更新都须经过人工评审、事实核验（与我对其他一切事物施加的硬闸门相同），以及批判循环，才能发布。自动化完成的是聚合，而非发布。

5. 分发。当一条提议的更新被接受后，它会传播给该技能的每一位用户。在中心化生态中这微不足道（更新规范版本的技能，所有人拉取即可）。在分布式生态中则更棘手。

其中大部分Claude Code中已经具备：会话日志、版本化的技能定义、可运作的批判循环。所缺失的那一块，是将会话轨迹与技能更新连接起来的聚合与模式检测层。命令、技能、子agent与规则的组织分类学已经提供了结构性基础；缺失的是让每一类别在部署之后仍保持活力的反馈通道。

令人不适的推论

过去六个月里我发布的每一项技能，都死在SkillClaw论文所描述的那种意义上。我编写技能。我自己使用它。我注意到问题。我修复了自己使用的那些技能中的问题。我的技能对我变得更好。除非他人独立地注意到相同问题并提交了什么，否则它们不会对任何其他人变得更好。

昨夜我在Settings Reference上所做的工作，正是这一模式。Claude Code指南是一件共享产物。用户针对具体的配置键进行查询。我能看到GSC数据告诉我哪些配置键被搜索。那就是聚合后的轨迹数据，明白地告诉我指南中哪些技能正被调用、结果落在何处。而在我去查看那份数据之前，指南是静态的。它已经静态了数周。并非因为没人观察轨迹，而是因为只有我能观察，而我当时另有要事。

SkillClaw论文是对这一问题的学术形式化。实际机制更为朴素：若你没有一条从轨迹数据到技能更新的自动流水线，你的技能就是在原地老化。它们或许在某些条件下仍对某些用户奏效。但它们并没有变得更好。

唯一的问题是：你是接受”你的技能在发布那一刻便死去”，还是你会去构建那个让它们保持鲜活的观察者。compound context原则在这里同样适用：每一次轨迹观察与下一次复利叠加，技能的价值随其所摄入的反馈非线性增长。反过来说，把context as architecture当作架构来看，意味着认识到：一项技能的结构，从根本上决定了它能否吸收新信息。

最小可行的聚合器

在开始写这篇文章之前，我对自己的技能没有任何轨迹聚合。零。我有可以手动阅读的会话历史，但没有任何东西能跨会话浮现出模式。这正是论文所描述的静态技能病症，而我正身陷其中。

我今天、此刻能够交付的最小实体是：一个单独的文本文件，追加式地记录我自己会话中每一次技能调用，字段包括时间戳＋技能名＋输入形态＋最终归宿（接受／修订／回退）。没有模式检测器。没有自主演化器。只有日志。

这份文件即是最小可行的聚合器。它不是SkillClaw。它是SkillClaw若要存在所需的输入层，也是我在能够看清自己的技能是否存在反复失败模式之前所需的输入层。没有它，我就是在猜。有了它，至少在我评审某项技能时可以手动扫阅日志并发问：本月同一处故障是否发生过三次？

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

若此法奏效，下一层便是模式检测器。若模式检测器奏效，再下一层便是提议生成器。论文的雄心是在多用户生态中运行的完整自主演化器。我的雄心是不再在黑暗中盲飞。

FAQ

论文中的”OpenClaw”是否等同于Claude Code？

不是，而且我也无法告诉你OpenClaw究竟是什么。摘要以”LLM agents such as OpenClaw”将其作为一款使用可复用技能的agent的示例提及，但未加定义。仅凭摘要，我无法迅速将其确认为某款已上线的产品。关键在于：论文的SkillClaw框架面向的是一般意义上的多用户agent生态，而非专门针对OpenClaw或Claude Code。无论OpenClaw是什么，该论文都不是一篇关于Claude Code的论文，而我在本文中对Claude Code所作的主张亦属我个人，不属于论文。¹

论文真正的新贡献是什么？

据摘要所述：面向多用户agent生态的集体技能演化框架——（1）跨用户与跨时间聚合轨迹，（2）运行自主演化器以检测反复出现的模式，（3）将模式转化为对共享仓库中技能的更新，并在用户间同步。¹其新意并非”技能可被改进”（这本就显而易见）。其新意在于提出：改进回路应当是自主的、由轨迹驱动的，而非由人驱动的。

论文是否报告了具体的改进数值？

摘要将改进描述为在名为WildClawBench的基准上、使用Qwen3-Max、在有限反馈条件下”significant”，但未公布具体数值。¹若要数值，须参阅完整论文。

这与对某份技能定义发起一次git pull request有何不同？

PR是一种由人发起的机制。必须有人注意到问题、写出修复、提交PR、评审、合并。每一步都需要人的付出。论文所提出的SkillClaw框架是自主聚合——系统跨众多用户注意到模式、自行提出修复，并同步该更新，无需任何一位用户提交任何东西。¹至于这种自主版本对任何具体生态是否可取或安全，则是另一个问题。论文的贡献在于证明：它在技术上是自洽的。

这是否适用于我自定义的Claude Code技能？

论文并未针对任何具体的Claude Code技能生态作出主张。我的主张——独立于论文——是：这一结构性问题（技能以静态产物形式发布、失败模式由每位用户独立重新发现、缺乏聚合机制）确实适用于Claude Code技能，而任何为Claude Code或类似agent框架构建技能的人，都应考虑如何构建一条由轨迹驱动的改进回路。这是我的观点，不是论文的结论。

与Shokunin的关联在哪里？

Shokunin／质量回路框架主张：大师之境源于”你所期望”与”实际发生”之间的差值被带入下一次尝试。静态技能打破了这条回路，因为差值累积在匠人永远看不到的会话中。SkillClaw则是这条回路闭合的学术版本：将差值的收集自动化，并将其反馈回技能。修行相同；机制不同。

参考文献