WikiSkill 深度解读：Google Research 把 Agent 经验编译进持久知识层，让 Skill 越用越强还能跨模型迁移

WikiSkill 深度解读：Google Research 把 Agent 经验编译进持久知识层，让 Skill 越用越强还能跨模型迁移

看完你会怀疑之前做 Agent Skill 的方式可能一直是错的。先收藏，做 Agent 工程早晚用得上。

本文提纲

  1. 问题：现有 Skill 进化方案的知识散落在优化历史里，无法系统化复用
  2. WikiSkill 三层知识架构：Raw → Wiki → Skills，灵感来自 Karpathy 的 LLM Wiki 设想
  3. 四大进化组件：Inference Agent、Wiki Maintainer、Skill Proposer、Gating & Rollback
  4. 实验一：5 个模型 × 5 个 benchmark，WikiSkill 全面胜出，大模型收益更大
  5. 最有意思的发现：9B 带进化 Skill 吊打裸 27B；跨模型迁移 Skill 比自进化更强
  6. 消融实验与案例分析：持久 Wiki 是核心，Agent 推理时访问 Wiki 反而有害
  7. 和 Warp Skills、Claude Skills 体系的关联与区别
  8. 对工程落地的启发：为什么你的 Agent Skill 仓库应该加一个 Wiki/

问题：为什么之前的 Skill 进化方案总是差点意思

Agent Skill 这个概念大家应该都不陌生了——把领域知识、工作流、脚本打成可复用的文件系统模块，Agent 跑任务时按需加载，不需要改模型参数。Claude Code Skills、Warp Improver 体系、我们之前报道过的 OpenOPC 技能都属于这条路线。

但 Skill 有个老大难问题：怎么让 Skill 自己越变越好？

过去的方案大致三种：
- EvoSkill：保存历史所有 proposal + 评估结果，下次进化时参考
- Trace2Skill：从成功/失败轨迹里抽经验，合并进 Skill 更新
- SkillOpt：用被拒绝的编辑反馈 + epoch 级元引导做优化

Google Research 的作者点出了它们的共同软肋：学到的洞见散落在优化历史里，没有形成独立、持续演化的知识表示。 每次进化都像是在"重新发现轮子"，因为上一轮学到的模式没有被系统地沉淀下来供下一代 Skill 构建者直接使用。

论文引用了 Karpathy 2026 年的"LLM Wiki"观点——把经验编译进持久、可复利的知识库。WikiSkill 把这个想法落地成了具体的工程框架。

WikiSkill 三层知识架构

WikiSkill 的第一个创新是把 Agent 工作区严格分成三层。简单理解就是"数据 → 知识 → 行动"的层层递进。

MERMAID_BLOCK_0

层 目录 内容 特性
Raw Layer (raw/) 原始执行轨迹 完整 step-by-step 交互：推理、工具调用、工具输出、最终答案 不可变，写后只读，像仓库的 git log
Wiki Layer (wiki/) 结构化知识库 模式（patterns）、反模式（anti-patterns）、适用条件（applicability conditions） 持久、跨轮迭代复利，不会被 rollback
Skills Layer (skills/) 可执行过程知识 每个 Skill 是一个目录：SKILL.md（frontmatter 含唯一名称+简短描述 + 过程指令 + 适用条件） + 资源脚本 可被 gating 回滚，是过程知识的"发布版本"

三层的核心关系是：
- Raw 层是"证据"，不做解释，只忠实记录
- Wiki 层是"经验总结"，从证据里提炼出通用模式和禁忌，永远只增不减
- Skills 层是"可执行的操作手册"，根据 Wiki 的积累来编写和优化

为什么一定要有 Wiki 这一层？因为直接从 Raw 轨迹生成 Skill 会反复犯同样的错误——没有统一的知识层，Skill 提案者每次都像第一次做这件事。Wiki 的存在让第 20 轮进化能站在之前 19 轮的肩膀上。

四大进化组件：Wiki 是怎么被维护的，Skill 是怎么被提出来的

在每一轮进化迭代中，WikiSkill 跑四个独立 Agent 组件，组成一个闭环。

组件一：Inference Agent — 带 Skills 跑 rollout，但被禁止访问 Wiki

推理 Agent 带着当前活跃的 Skills 在训练任务上跑 rollout，产出 Raw 轨迹。

反直觉设计：推理时刻意不让 Agent 访问 Wiki。论文的消融实验证实了这个设计——如果推理 Agent 在任务执行时能查 Wiki，最终 Skill 质量反而下降。这是因为模型会养成"过度依赖 Wiki 查经验"的惰性，不再认真通过 Skill 学习内化出好的执行习惯。

组件二：Wiki Maintainer — 把轨迹合并进 Wiki

这是整个系统最"知识工程"的角色。它做的事：
1. 读取本轮 Raw 轨迹，分析成功和失败的模式
2. 去重和合并：已存在的 Wiki 条目在证据支持下迭代，而不是重复写新条目
3. 结构化分类：新发现的模式归到 patterns，踩了的坑归到 anti-patterns，什么情况下该用某条知识归到 applicability conditions
4. 这个 Agent 不能回滚：Wiki 是持久层，写入就保留

这一步的产物是知识库"越来越厚"，且支持是被验证过的——每条 Wiki 条目背后都可以追溯到真实轨迹证据。

组件三：Skill Proposer — 基于 Wiki + Traces 做 ReAct 提案生成 Skill 更新

Skill 提案者可以同时看 Wiki 和本轮 Raw 轨迹，用 ReAct（Thought-Action-Observation）模式提出 Skill 的编辑提案（新增、修改、删除某个 skill 或其内容）。Wiki 在这里的作用是告诉提案者"已经知道什么、试过什么、哪些方式行不通"，提案者不需要从零开始猜，相当于站在前 N 轮的集体经验之上。

论文还特别提到 Skill Proposer 可以用"Wiki-informed"的方式——当它想提一个新过程知识时，先查 Wiki 里有没有相关模式的支撑或反例，避免白费力气。这和我们直接让模型 rewrite SKILL.md 的无脑进化方案形成了本质差距。

组件四：Gating and Rollback — 只保留验证集上有提升的 Skill 更新

Skill 提案不是直接生效。Gating Agent 在验证集上跑一次更新后的 Skills，如果分数提升就保留，否则回滚 Skill。但注意：Wiki 不回滚——哪怕这次的 Skill 更新失败了，Wiki Maintainer 写入的模式和反模式依然保留，下一轮提案者可以利用"上次这样改不行"这条知识，提出不同的更新方向。

MERMAID_BLOCK_1

这张图就是论文的灵魂：Skills 可能会被回滚，但 Wiki 永远向前，持续积累。系统就像一个不断变聪明的组织——即使某一次尝试失败了，这个失败本身变成了知识库中一条可复用的教训，帮助下次做得更好。

实验一：5 Benchmark × 5 Model，WikiSkill 全面压竞品

测试集

Benchmark 领域 说明
LiveMathematicanBench 数学推理
SealQA Web 搜索问答
SpreadSheetBench 表格操作
OfficeQA 长文档 QA
ALFWorld 具身交互任务

覆盖了从纯文本推理到多轮工具使用到具身环境的不同能力维度。

模型

Qwen-3.5-4B、Qwen-3.5-9B、Qwen-3.6-27B、Gemma-3-12B、Gemini-1.5-Flash，从 4B 到 27B 跨三个模型家族。

对比基线

No Skills（裸 Agent，没有任何 Skill 辅助）、EvoSkill、Trace2Skill、SkillOpt，加上 WikiSkill。

核心结果

论文给出了一个很强的结论：WikiSkill 在绝大多数模型-benchmark 组合中优于三个 SOTA 方案和 no-skill baseline，且模型越强提升越明显。

Qwen 家族内的缩放效应（按论文原文数据）：
- Qwen-3.5-4B：WikiSkill 相对 no-skill 平均提升 +12.3%
- Qwen-3.5-9B：提升 +17.5%
- Qwen-3.6-27B：提升 +23.9%

这个发现很有意思：Skill 进化和模型缩放是互补的，不是替代关系。 越大的模型，越能从"经过进化的好 Skill"中拿到收益。这反过来也意味着，把 Skill 做好对于小模型更有经济意义——因为好的 Skill 能让小模型越级打。

最炸裂的两个发现

发现一：9B + 进化 Skill 吊打裸 27B

论文直接给出了对比：

配置 平均准确率
Qwen-3.6-27B，无 Skill 39.4%
Qwen-3.5-9B，WikiSkill 进化 Skill 47.4%

9B 模型比 27B 模型小了整整 3 倍的参数量，但通过 WikiSkill 进化出的一套 Skill，综合表现反超 8 个百分点。换算到本地推理成本上——9B Q4 量化不到 6GB，消费级 Mac 就能流畅跑；27B Q3 需要 12GB+ 内存，在同一台机器上慢得要死。如果 9B 能跑出更好的结果，谁还会用 27B 裸模型做 Agent 任务？

发现二：跨模型迁移 Skill，可能比模型自己进化更好

这是整篇论文中最令人意外的结果。作者把 A 模型在某个任务上进化好的 Skill，让 B 模型直接用（不重新进化），看效果。

以 ALFWorld 为例：
- Qwen-3.5-9B 用自己进化的 Skill：63.4%
- Qwen-3.5-9B 直接用 Qwen-3.6-27B 进化好的 Skill：70.2%（+6.8 pp）

27B 模型发现的 Skill，让 9B 模型直接用，效果比 9B 自己从零进化还强。这说明——

技能发现（Skill Discovery）和技能执行（Skill Execution）是两种可以分离的能力。

大模型因为推理能力更强，更擅长"发现正确的过程知识"并将其写成可执行 Skill；写好之后，小模型一样可以按步骤执行，而且效果不差。这个结论对团队落地具有非常现实的意义：完全可以用最强模型（GPT-4o/Claude Opus 级）在私有任务集上进化 Skill 库，然后在便宜的小模型上部署使用。 这把 Skill 从"模型附带品"变成了真正的"可交易资产"。

消融实验：持久 Wiki 是核心；推理时给 Wiki 反而害了模型

论文做了两组关键消融：

消融 1：Persistent Wiki vs 无 Wiki（只用 traces）

对比两种变体：
- WikiSkill Full（完整方案，有持久 Wiki）
- No Wiki（去掉 Wiki 层，Skill Proposer 只能看历史 traces 而没有结构化知识库）

结果是 No Wiki 版本性能显著下降。作者在论文图中明确展示了 Wiki 的持久积累让 Skill 进化曲线始终高于没有 Wiki 的对照组。这验证了最初的假设：把经验编译成结构化、可复利的知识表示，对 Skill 进化的质量至关重要。

消融 2：Inference Agent 推理时允许访问 Wiki

对比：
- 正常配置：推理 Agent 只能用 Skills，不能查 Wiki
- Allow Wiki Access：推理时也给 Agent 开放 Wiki 查询

结果反直觉——开放 Wiki 访问后最终 Skill 质量反而下降。原因是模型在推理时"走捷径"：本来应该通过内化的 Skill 流程学会正确执行，现在变成了"遇事不决查 Wiki"，结果技能本身的掌握程度下降，对 unseen task 的泛化就更差了。

这对工程实践的暗示非常直接：Wiki 应该给 Skill 维护者看，不应该给执行端的 Agent 直接看。执行端的 Agent 必须严格通过 Skill 层与知识交互，才能保证 Skill 本身是经过验证且自包含的。

案例分析：Wiki 如何一步步引导 Skill 进化

论文 5.3 节有一个非常漂亮的 anatomy 案例，展示了多轮进化中 Wiki 和 Skill 的联动动态。我用文字版还原一下：

  • 第 0 轮：没有 Skill，没有 Wiki。Agent 在 100 个训练任务上裸跑，产出 100 条 traces，其中 30 条成功。
  • Wiki Maintainer 写入第一轮 Wiki：从成功的 30 条里抽了"Task 类型 A 通常先调用 X 工具"、"参数 P 不填默认值 Q 会失败"等模式；从失败的 70 条里提炼了"直接调用 Shell 命令处理 CSV 时容易溢出"等反模式。
  • Skill Proposer 看 Wiki + traces，提出第一个 Skill：CSV-Agent，里面写着用 X 工具处理 CSV 的标准流程，并明确注明不要用默认 Q 参数。
  • Gating 验证通过（验证集分数上升），CSV-Agent Skill 被接受。
  • 第 2 轮：推理 Agent 带着 CSV-Agent 再跑 100 个任务，成功率从 30% 提升到 55%。新的失败里暴露了一种之前没见过的"CSV 带 Unicode 字符"的场景。
  • Wiki Maintainer 追加一条新 anti-pattern 和 对应 pattern，不回滚之前的 Skill。
  • Skill Proposer 这次能直接从 Wiki 中看到 "CSV Unicode 是已知坑"，提出对 CSV-Agent 的编辑：在步骤 2 增加字符清洗预处理。
  • Gating 再次通过，新版本 Skill 正式生效。

多轮之后，你可以想象：Wiki 从空变成了一个关于这个数据集所有"已知正确做法、已知坑、已知适用场景"的完备参考，而 Skills 从空变成了针对该任务类型的一套精简、验证过的操作手册。两者共同成长，且互相支撑。

和 Warp / Claude Skills 体系的关联

这篇论文读下来，我会联想到近期两篇非常有启发的实践文章：

Warp 自改进 Agent（Anthropic 博客，2026.8.26） 中的双层 Skill 架构——内层 Base Skill 执行，外层 Improver Skill 观察反馈提议编辑——恰好是 WikiSkill 思路在生产系统中的一个实例。不过 Warp 方案里没有独立的 "Wiki" 持久层，经验是散落在 AGENTS.md 和改进提案里的。WikiSkill 给了 Warp 一个更完善的下一步：给 Improver 提案者加一个结构化的共享 Wiki。

Claude AI-Native SDLC Playbook（Anthropic，2026.8.21） 中提出的制品链 intent.md → spec.md → plan.md → diff+tests，和 WikiSkill 的三层架构是可以对应上的：intent/spec 属于经验沉淀层（Wiki 类），plan/diff 属于可执行层（Skills 类）。不同的是 Playbook 针对的是软件工程流程，WikiSkill 针对的是 Agent 任务执行。

把这三个东西放在一起看，会发现 2026 年下半年的 Agent 工程有一个明确的趋势：Agent 能力不再只靠模型本身，而是靠持久化的知识体系。

对工程落地的几条真实启发

这篇论文不是那种"原理很美好，工程用不上"的纯研究，里面的设计可以直接抄到你的 Agent 项目里：

  1. 给你的 skills/ 目录加一个同级的 wiki/ 目录。 不要只存 SKILL.md 这种最终产物，所有验证过的模式和反模式写进 wiki/，格式统一（例如每条 pattern 至少有适用条件、反例、轨迹证据引用）。
  2. Skill 进化流程里，永远允许失败的提案留下教训。 团队里常见的误区是：一个 PR 被合入才叫贡献，一个 PR 被拒就当没发生过。WikiSkill 告诉你——"这次这样改验证集分数下降了"本身就是高价值知识，必须写进 Wiki，让下次提案者不会再走同样的死胡同。
  3. 执行端 Agent 不要直连大百科。 文档和 Wiki 是给 Skill 维护者看的，不是给执行时的 Agent 查的。执行端只暴露经过验证、版本化、可回滚的 Skill 接口。这样才能保证 Skill 的质量是可度量的。
  4. 攒一个"大模型发现、小模型执行"的 Skill 共享库。 如果你的团队有 Claude Opus/Claude Code 访问权，先用它在私有任务集上跑 skill 进化，把出来的 skill 库给便宜的 8B/9B 模型用。论文已经证明这通常比小模型自己进化更好，且推理成本差几倍。
  5. 别再用"重写 SKILL.md"当进化手段了。 Trace2Skill 这种直接从轨迹生成 Skill 的模式，没有持久知识做支撑，在论文里被 WikiSkill 稳定压制。正确模式是：先把轨迹沉淀到 Wiki 的结构化知识，再基于 Wiki + 轨迹生成 Skill。

参考文档与链接

论文里有一个结论让我印象最深："9B 带 Skill > 27B 裸奔"。你的 Agent 系统现在是哪种模式？觉得有用点个赞，欢迎评论区聊聊你们是怎么做 Skill 进化的。

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

关注公众号，获取更多 AI 技术干货！

posted @ 2026-08-30 11:25  iTech  阅读(216)  评论(0)    收藏  举报