WikiSkill：给 Agent 技能进化补上一本"永不回滚"的 Wiki

第 3 轮迭代的 Skill Proposer，正在把第 0 轮刚被验证集拒绝的方案原样再提一遍——因为没有任何机制告诉它，这条路已经死过一次了。Google 的 WikiSkill 用一本永不回滚的 Wiki 治好了技能进化的失忆症，顺手把五个模型全部推上 SOTA。

一、技能进化的共同盲区：失忆

Agent skill 这条线这两年非常热。Trace2Skill、EvoSkill、SkillOpt——三家的套路几乎一样：让 agent 跑任务、分析执行轨迹、提出 skill 修改、用验证集把关。它们都验证了一件事：从 agent 自己的经验里挖技能，是真实有效的。

但它们有一个共同的盲区：引导 skill 进化的洞察，散落在优化历史里，没有被系统性沉淀。

拆开看一个典型的进化循环：每一轮，agent 跑完训练集，分析失败原因，改一版 skill，进入下一轮。但"上一轮哪个提议被验证集打回去了""哪些错误反复出现""哪些方案已经证明无效"——这些信息要么塞在当前轮的上下文里用完即弃，要么根本不存在。跨迭代的信息流，基本为零。

后果很具体：第 3 轮的 Proposer 很可能把第 0 轮刚被拒绝的方案换个措辞再提一遍。每一轮进化都从近似零开始，迭代次数越多，浪费越大。

WikiSkill 的解法简单到近乎常识：在 skill 旁边放一本持久化的 Wiki，把每轮的经验编译成结构化知识，让后续所有轮次踩在它上面。常识归常识，结果是全 SOTA。

二、三层架构：三种知识，三种生命周期

WikiSkill 把 agent 工作区切成三层。这个设计最值得细品的不是"分层"本身，而是每一层有不同的写入规则和回滚策略：

几处设计值得点出来。skill 目录里除了 SKILL.md 还有一个 PURPOSE.md——把每条技能映射回激发它的 wiki pattern。技能不是凭空长的，每条都能溯源到具体的经验证据。

更关键的是 wiki 里的 skill-impact.md：由外层 harness 程序化写入，记录每次 skill 提议的 diff、验证分数、接受或拒绝的结果。这不是 LLM 写的，是代码写的——所以它是客观的、防篡改的审计轨迹。Proposer 后续读它，就不会重蹈覆辙。

三、进化循环：四个角色，一条铁律

每轮迭代四步。Inference Agent 带着当前 skill 跑训练集，产出不可变轨迹；Wiki Maintainer 抽样成功和失败轨迹做根因分析，把新模式写进 patterns/、把过程写进 logs.md；Skill Proposer 读完 wiki 和最新轨迹，提出 skill 更新；最后 Gating 在验证集上把关——分数涨就接受，跌就整体回滚到上一个可用版本，并把裁决写入 skill-impact.md。

注意系统状态的二元性：(S_k, W_k) 中，skill 是"可逆的、条件性更新"，wiki 是"复利的、永不重置"。被拒绝的提议不丢人——它作为知识留了下来，变成下一轮的地基。

但这个循环里藏着一条容易被忽略的铁律：训练 rollout 时，Inference Agent 禁止读 wiki。为什么执行者不能接触这本知识库？答案在消融实验里，而且是全文最精彩的发现——先按下不表。

四、主实验：五战场全胜，且越强的模型受益越大

五个 benchmark 覆盖五种截然不同的能力：数学推理（LiveMath）、网页搜索（SealQA）、表格操作（SpreadSheet）、长文档问答（OfficeQA）、具身任务（ALFWorld）。五个模型横跨开源与闭源：Qwen-3.5-4B/9B、Qwen-3.6-27B、Gemma-4-31B、Gemini-3.5-Flash。每个配置独立进化三次取平均，配对 bootstrap 检验显著性。

Table 1 重建：五个模型 × 四种 skill 进化方法 + 无 skill 基线，三跑平均。橙色行为 WikiSkill，全部为各模型最佳平均分。

三个发现值得展开。

第一，全面领先，且带来更稳的改善。WikiSkill 在所有五个模型上拿到最高平均分，比各模型上最强对手分别高 3.3、5.1、10.0、5.8、12.0 个点。基线方法会翻车——EvoSkill 让 Gemma 在 LiveMath 上从 33.9 掉到 29.8，SkillOpt 让 Gemini 在 SealQA 上从 29.4 掉到 28.2——而 WikiSkill 的负向波动小得多。

第二，skill 进化和模型 scaling 是互补关系，不是替代关系。Qwen 家族内，WikiSkill 的提升随规模单调增大：4B +12.3、9B +17.5、27B +23.9。SpreadSheet 上最夸张：+6.5、+9.3、+40.9。强模型有足够的能力去"写好并执行好"更复杂的技能，所以从经验里榨出的价值更多。

反方向同样成立：skill 可以兑换模型规模。Qwen-3.5-9B + WikiSkill（47.4%）打赢无 skill 的 27B（39.4%）；甚至 4B + WikiSkill（38.5%）也逼近无 skill 的 27B。对部署侧的含义很直接：小模型 + 好技能，可能比大模型裸跑更划算。

第三，不同任务的"可进化性"差异巨大。LiveMath 和 ALFWorld 几乎稳赚（各模型普遍 +20 以上）；SpreadSheet 两极分化（27B 上 +40.9，4B 上只有 +6.5）；OfficeQA 对小模型甚至轻微负收益——4B 执行不了长文档多步检索的工作流，干脆退回默认行为。技能进化的红利，需要执行能力去兑现。

五、跨模型迁移：外来和尚会念经，也会砸场子

如果进化的 skill 只对进化它的模型有用，那这条路线的天花板就很低。Table 2 的答案乐观得多：skill 跨模型、跨家族迁移不仅可行，常常比自进化的更好。

Table 2 精选重建：绿色为超过自进化的迁移结果，红色为负迁移（Qwen-3.5-4B 的 skill 让 Gemini-3.5-Flash 在 SpreadSheet 上从 50.5 暴跌到 18.1）。Gemini-3.5-Flash 在 ALFWorld 上因验证集满分提前终止，无 skill 来源。

最刺眼的三组数字：Qwen-3.5-9B 用 27B 进化的 skill 在 ALFWorld 拿 70.2%，自进化只有 63.4%；Gemma-4-31B 用 27B 的 skill 在 SpreadSheet 上 72.0% 对自进化 68.0%；小模型的 skill 也能反向输出——4B 的 skill 把 Gemma 的 LiveMath 从 33.9 拉到 73.1。作者由此给出一个干净的判断：发现好技能和执行好技能，是两种不同的能力。

但迁移不是免费的。Qwen-3.5-4B 的 skill 让 Gemini-3.5-Flash 在 SpreadSheet 上从 50.5% 暴跌到 18.1%。错误分析揪出两个原因：其一，4B 的技能里塞满了"单行 Python、字符串转换"这类绕坑技巧——它们帮小模型躲开执行失败，却捆住了强模型写完整端到端脚本的手脚；其二，碎片化的诊断步骤带来冗余工具调用，耗光了 Flash 的交互预算。技能里编码的是通用程序还是模型特定的 workaround，决定了它是通行证还是绊脚石。

还有一处"利他"现象：Qwen-3.5-4B 在 OfficeQA 上进化的 skill 让自己从 30.2 掉到 28.5，却把 Qwen-3.6-27B 从 42.1 推到 52.9。为别人做嫁衣——这在自进化范式里是不可见的盲区，交叉评估才能暴露。

六、消融：全文最值钱的一张表

用 Gemini-3.5-Flash，独立开关 Inference Agent（训练时）和 Skill Proposer（开发时）的 wiki 访问权，四种配置：

Table 3 重建（Gemini-3.5-Flash）。首行 = 无持久知识的近似基线（等价于 40.4）。末行为 WikiSkill 默认配置。

第一个结论在预期内：持久化知识值 +15 分。Proposer 拿到 wiki 后平均 48.7% → 63.7%，LiveMath 51.3% → 72.6%，SpreadSheet 49.9% → 76.6%。没有跨迭代的累积知识，Proposer 对付不了复杂的失败模式——每一轮都在重新发明轮子。

给 Inference Agent 训练时开 wiki 权限，最终 skill 反而变差（63.7% → 60.9%，LiveMath 掉 7.8 个点）。当执行者能直接从 wiki 拿答案，轨迹就不再暴露真实的知识缺口——skill 进化需要的是暴露问题的失败，而 wiki 把失败提前治愈了，可学习的信号就没了。

这个逻辑和评测领域的"数据污染"完全同构：你不能让被优化的对象提前看到答案，否则你测到的、学到的都是假象。它对 self-improving agent 的一般性启示是：进化回路中，任何"让执行者直接接触元知识"的捷径，都可能掏空进化本身的信号源。

七、解剖一次进化：被拒绝的提议如何滋养后续

论文第 5.3 节给了 ALFWorld 上 Qwen-3.6-27B 的完整案例，值得逐步走一遍。

第 0 轮，Wiki Maintainer 在轨迹里发现 agent 有"拿物品 → 检查 → 放回 → 再拿"的循环行为，存为 pattern。Proposer 读了 pattern 后提出 goal-directed-action 技能——验证集 0.72 分，拒绝。关键在下一步：skill-impact.md 记下了这个 diff 和拒绝结果。

第 1 轮，Proposer 读到这段审计记录，不再重提旧案，转而提出更精准的 break-repetition-loop，内含一条具体规则："永远不要把物品放回原位"。0.78 分，通过。第 2 到 4 轮，新型循环（multi-operation-loop）的证据继续在 wiki 里累积，Proposer 据此在第 4 轮给技能补上第二条规则："每种操作对每个物品只做一次"。再次通过。

一次失败没有被浪费，它变成了知识，变成了下一轮的地基。这就是"wiki 永不回滚"的直接回报。

Appendix 的统计进一步佐证：接受的有效更新并非集中在早期——各模型 39%-52% 的接受更新发生在前两轮，其余持续分布在中后期（SealQA 上 28% 的接受更新发生在第 5-7 轮）。没有持久知识，这种持续精化是不可能发生的——失忆的 proposer 在后期只会重复早期的自己。

八、局限：诚实，且指明了下一步

作者承认四点。技能是全量注入 prompt 的，没有测检索和触发——skill 数量一多这就是真问题（也是 Anthropic skill 架构里 description 触发机制要解的题）。验证门控只接受涨分提议，"短期持平但打开后续空间"的中性提案会被系统性拒绝。wiki 没有自动修剪机制，跑长了会膨胀——pattern 目录只进不出，遗忘机制缺席。此外实验局限在五个 benchmark 的离线进化，没有测在线、非平稳环境下的持续进化。

这几个坑恰好是下一批论文的空间：skill 检索、软门控、wiki 遗忘。谁能把"给知识库加遗忘曲线"做扎实，谁就拿到下一篇。

九、搬回自己的 agent 系统里

我自己的 agent 框架里就维护着一个 skills/ 目录，这篇论文几乎是照着痛点写的。三条可以直接搬走：

第一，把 memory 和 skill 分层，并给它们不同的回滚策略。大多数系统的失败不是没有记忆，而是记忆和技能纠缠：技能改坏了连带污染经验库，经验库太吵又淹没技能。WikiSkill 的答案是三种东西三种生命周期——经验只写、知识只增、技能可逆。状态一旦可回滚就要问一句：回滚的应该是技能，还是知识？答案不同，架构就不同。

第二，给 skill 修改建审计日志。skill-impact.md 的设计便宜到不能再便宜——外层 harness 追加一条记录而已——但它杜绝了同一个坑掉两次，还天然构成对齐审计所需的 trail。做 self-improving agent 的安全设计，这是第一块砖。

第三，进化过程中隔离被优化对象的信息源。训练 agent 不许读 wiki，这条铁律值得写进每个自改进系统的设计守则。

从轨迹里挖技能（Trace2Skill），到给进化加门控（SkillOpt / EvoSkill），再到给进化加记忆（WikiSkill）——这条路线的下一步，大概会轮到给 wiki 加遗忘。而再往后呢？也许真正的答案不是更聪明的机制，而是承认：一个能持续变好的 agent，需要的第一样东西是一个不会失忆的地方。