WikiSkill：把智能体经验编译成可持续演化的技能
WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution
- 发表日期
- 机构
- Google Research × Virginia Tech
- 作者
- 6 位
展开全部作者（6）
Liyan Tang · Cyrus Rashtchian · Chun-Sung Ferng · Andrew Tomkins · Da-Cheng Juan · Tu Vu
3 层
Raw / Wiki / Skill
5 × 5
基准 × 推理模型
68.1%
Gemini-3.5-Flash 均分
+23.9pt
Qwen-3.6-27B 增益
+15.0pt
Proposer 读取 Wiki 消融
11–21
每轮优化器 LLM 调用
TL;DR · 60 秒速览
这篇论文到底说了什么
WikiSkill 不把每轮成功与失败直接揉进一份越来越乱的 SKILL.md，而是在原始轨迹与可执行技能之间增加一个永久 Wiki：Raw 保存证据，Wiki 沉淀模式与更新历史，Skill 只保留通过验证的程序性规则。技能更新失败时会回滚，Wiki 仍记住失败。它在 5 个基准、5 个模型上都取得最高平均分；Qwen-3.6-27B 的五任务均分从 39.4% 提到 63.3%，而让 Skill Proposer 读取 Wiki 带来 15.0 个百分点的消融增益。更重要的是，技能能跨模型迁移，甚至外部演化技能优于自演化技能——但迁移也可能严重负收益，说明“发现规则”和“执行规则”是两种不同能力。
摘要（编译）
智能体技能把领域知识、工作流和工具使用规则封装为可复用的文件系统模块，但现有自动技能演化方法通常把经验散落在轨迹、提案与反馈历史中，难以跨迭代积累。本文提出 WikiSkill：以不可变 Raw Layer、持续累积的 Wiki Layer 和可回滚的 Skill Layer 分离执行证据、结构化知识与程序性指令；Inference Agent 产生轨迹，Wiki Maintainer 提炼模式，Skill Proposer 基于 Wiki 与按需读取的轨迹提出原子更新，再由验证集门控接受或回滚技能。五个基准与五种模型的实验显示，WikiSkill 的平均性能优于无技能及 Trace2Skill、EvoSkill、SkillOpt；演化技能还可跨模型与模型家族迁移。消融表明，持久 Wiki 对技能演化至关重要，同时也揭示 Wiki 不应直接暴露给执行任务的 Inference Agent。
01 · The Problem
技能会更新，不等于系统真的积累了知识
Agent skill 是比微调更轻的能力载体：一组带 SKILL.md 的目录，把任务说明、脚本和参考资料装成可审计、可复用、按需加载的模块。难点不在“能不能改文件”，而在连续多轮优化后，系统是否还知道为什么曾经这样改、哪些提案失败过、某条规则由哪些轨迹支持。
EvoSkill 保留累计提案历史，Trace2Skill 从轨迹汇总教训，SkillOpt 记录被拒编辑与逐轮指导，但论文认为这些信息仍散落在优化产物中，没有成为一份独立、持续演化的知识表示。直接把所有经验塞回技能也会混淆两件事：Wiki 负责保留仍待验证的认识，Skill 负责向执行 Agent 暴露已经验证的程序。
这一区分很关键：WikiSkill 的 Wiki 不是推理时给 Agent 查答案的长期记忆，而是技能开发器的持久状态。默认配置中，执行任务的 Inference Agent 只能看到已接受的技能；Wiki 只服务于 Maintainer 和 Proposer。
论文真正增加的不是另一种反思提示词，而是一个位于原始经验与可执行规则之间、不会随失败更新一起消失的知识层。
02 · Three Layers
三种存储，三套不同的保留语义
Raw Layer（raw/）写入完整执行轨迹，包括推理、工具调用、输出与最终答案；它只追加、不改写，承担证据与追溯。Wiki Layer（wiki/）把跨轨迹模式写成独立 markdown 页面，同时维护 index.md、按时间记录发现的 logs.md，以及由外层程序写入验证分数、提案 diff 与接受结果的 skill-impact.md；它持续累积，从不因技能回滚而清空。
Skill Layer（skills/）才是 Inference Agent 会消费的执行接口。每个技能含 SKILL.md 与 PURPOSE.md：前者给出可执行流程，后者把技能链接回促成这次更新的 Wiki 模式。技能是可逆、条件接受的；Wiki 则允许保留“目前有证据、但尚未形成有效规则”的知识。
03 · Evolution Loop
四步闭环：执行、归因、提案、门控
每轮先由 Inference Agent 在训练集上运行当前技能，产生新轨迹；其系统提示直接注入全部活跃技能，但默认禁止访问 Wiki。随后 Wiki Maintainer 从训练轨迹中最多抽样 8 条（最多 5 条失败、3 条成功，每条截断至 15,000 字符），对失败做根因分析、从成功提炼策略，并以增量 patch 更新模式目录和演化日志。
Skill Proposer 不一次性吞下全部长轨迹。它先得到 Wiki 索引、skill-impact 历史与所有训练任务的结果摘要，再以 ReAct 方式按需读取模式页和原始轨迹；每轮只提出一个原子提案——创建一个技能，或修改一个既有技能。这个约束让验证结果能更清楚地归因到单次变更。
最后在独立验证集上重跑候选技能。分数必须严格高于历史最好值才接受，否则回滚 Skill Layer；无论接受还是拒绝，Wiki 都追加提案 diff、分数与判定。因此系统可以忘掉一次坏实现，却不会忘掉它为什么坏。验证分数达到 100% 时可提前终止。
S_k = S'_k if R_val(S'_k) > R_best; otherwise S_{k−1}严格单调门控只回滚技能；Wiki 的模式、日志与提案审计记录在两种结果下都会保留。
04 · Evaluation
一套框架横跨五种任务，但训练与验证集都很小
作者在数学推理、网页搜索、表格操作、长文档问答和交互式具身任务上评测 5 个模型：Qwen-3.5-4B、Qwen-3.5-9B、Qwen-3.6-27B、Gemma-4-31B-It 与 Gemini-3.5-Flash。所有技能从空集合开始，并与无技能、Trace2Skill、EvoSkill、SkillOpt 比较。
每个方法完整演化 3 次，主表报告 3 组最终技能在测试集上的平均表现；论文还用 1,000 次配对 bootstrap、p < 0.05 判断统计并列。这里要同时看到一个风险：验证集只有 10–40 题，而每个候选更新都靠它做严格门控；重复运行缓解了结果方差，但不能消除小验证集对搜索路径的选择噪声。
| 基准 | 任务形态 | Train | Val | Test | 工具 |
|---|---|---|---|---|---|
| LiveMath | 单步数学推理 | 35 | 18 | 124 | 无 |
| SealQA | 多步事实检索 | 16 | 10 | 85 | web_search / read_file |
| SpreadSheet | 表格操作 | 80 | 40 | 280 | bash |
| OfficeQA | 长文档问答 | 50 | 24 | 172 | glob / grep / read |
| ALFWorld | 交互式决策 | 39 | 18 | 134 | 可行动作集合 |
05 · Main Results
五个模型的平均分都第一，且优势随模型能力放大
WikiSkill 在五个推理模型的跨基准平均分上都高于三种技能演化基线。与无技能相比，Qwen-3.5-4B、9B、Qwen-3.6-27B、Gemma-4-31B 和 Gemini-3.5-Flash 分别提高 12.3、17.5、23.9、13.6、18.6 个百分点；与每个模型最强的既有演化方法相比，仍领先 3.3–12.0 个百分点。
提升并非每个单元格都为正：例如 Qwen-3.5-4B 在 OfficeQA 从无技能的 30.2% 降到 28.5%。更准确的结论是，WikiSkill 的跨任务平均收益更强、更稳定，不是给任何模型、任何任务加上 Wiki 都必然提升。Gemini 在 ALFWorld 的无技能验证分已达 100%，演化会提前停止，测试分因此维持 85.9%。
| 推理模型 | 无技能 | 最强既有方法 | WikiSkill | 相对无技能 |
|---|---|---|---|---|
| Qwen-3.5-4B | 26.2 | 35.2 (SkillOpt) | 38.5 | +12.3 |
| Qwen-3.5-9B | 29.9 | 42.3 (EvoSkill) | 47.4 | +17.5 |
| Qwen-3.6-27B | 39.4 | 53.3 (EvoSkill) | 63.3 | +23.9 |
| Gemma-4-31B | 41.3 | 49.1 (SkillOpt) | 54.9 | +13.6 |
| Gemini-3.5-Flash | 49.5 | 56.1 (EvoSkill) | 68.1 | +18.6 |
06 · Scaling
技能演化不是小模型补丁：强模型反而吃到更多红利
Qwen 系列的平均增益从 4B 的 +12.3pt、9B 的 +17.5pt，继续扩大到 27B 的 +23.9pt；SpreadSheet 上三者的提升更从 +6.5、+9.3 拉到 +40.9pt。论文据此提出“技能演化与模型扩展互补”：更强模型既更会从经验发现有效流程，也更能稳定执行多步技能。
反方向同样成立：有效技能可以补偿相当大的参数差距。Qwen-3.5-9B + WikiSkill 的五任务均分是 47.4%，超过无技能 Qwen-3.6-27B 的 39.4%。但这不表示技能能普遍替代模型规模——OfficeQA 中较小模型会被长上下文分散注意，甚至不按复杂搜索流程执行；技能的价值受执行者能力约束。
07 · Cross-Model Transfer
技能发现者不必是最佳执行者，自演化也不一定最优
作者把一个模型演化出的技能直接注入另一个模型，发现迁移技能经常超过无技能和自演化技能。Qwen-3.6-27B 产生的 SpreadSheet 技能把 Qwen-3.5-9B 从 24.3% 提到 50.5%，高于其自演化的 33.6%；同一来源的 LiveMath 技能把 Gemma-4-31B 从 33.9% 提到 73.7%，也高于 Gemma 自己演化的 56.7%。
这把“从轨迹中发现程序”和“在新任务上执行程序”拆成两种能力。来源模型不必更大：Qwen-3.5-4B 的 ALFWorld 技能也能把 Gemma-4-31B 提到 66.9%，超过其自演化 64.4%。但迁移并不单调，技能也会编码模型特定的补丁；4B 模型为表格任务学到的单行 Python 与字符串转换规则，会限制 Gemini 使用完整脚本并消耗交互预算，使其 SpreadSheet 从 50.5% 暴跌到 18.1%。
| 目标模型 / 基准 | 无技能 | 自演化 | 外部技能 | 技能来源 |
|---|---|---|---|---|
| Qwen-3.5-9B / SpreadSheet | 24.3 | 33.6 | 50.5 | Qwen-3.6-27B |
| Qwen-3.5-9B / ALFWorld | 34.7 | 63.4 | 70.2 | Qwen-3.6-27B |
| Gemma-4-31B / LiveMath | 33.9 | 56.7 | 73.7 | Qwen-3.6-27B |
| Gemini-3.5-Flash / LiveMath | 33.0 | 72.6 | 73.9 | Qwen-3.6-27B |
| Gemini-3.5-Flash / SpreadSheet | 50.5 | 76.6 | 18.1 | Qwen-3.5-4B（负迁移） |
08 · Ablation
Wiki 应该给技能开发器看，不应该替技能替执行者答题
最关键的消融在 Gemini-3.5-Flash 上进行，并排除因验证集满分而无法演化的 ALFWorld。Inference Agent 不读 Wiki 时，让 Skill Proposer 读取持久 Wiki，四基准均分从 48.7% 提到 63.7%，增加 15.0 个百分点；LiveMath 从 51.3% 提到 72.6%，SpreadSheet 从 49.9% 提到 76.6%。
反过来，在 Proposer 已读 Wiki 的情况下，再让 Inference Agent 也读 Wiki，均分从 63.7% 降到 60.9%。作者的解释是：执行者可直接从 Wiki 借到任务知识，训练轨迹便不再准确暴露技能本身的缺陷，Proposer 得到的学习信号被污染。知识层可以比产品接口更丰富，但评测产品接口时必须保持隔离。
这项消融还需谨慎解读：关闭 Proposer 的 Wiki 访问时，实验同时移除了 Wiki Maintainer，因此 +15.0pt 证明的是“持久知识维护 + Proposer 访问”这一整套机制有效，而不是某一个文件或某一种 Wiki 格式的纯因果贡献。
| 配置 | Inference 读 Wiki | Proposer 读 Wiki | Avg. |
|---|---|---|---|
| 无技能 | — | — | 40.4 |
| 无持久 Wiki，执行者读取 | 是 | 否 | 45.3 |
| 无持久 Wiki，执行者隔离 | 否 | 否 | 48.7 |
| WikiSkill，双方读取 | 是 | 是 | 60.9 |
| WikiSkill 默认配置 | 否 | 是 | 63.7 |
09 · Case Study
一次失败提案，如何在四轮后变成更具体的技能
ALFWorld 案例展示了“持久”具体保存了什么。Iteration 0 中，Wiki 识别出拿起—检查—放回—重复的循环，Proposer 提出抽象的 goal-directed-action，但验证分没有提高，技能被拒绝；skill-impact.md 仍保留完整 diff、0.72 分与拒绝结果。
Iteration 1 的 Proposer 看到这段失败史后，改为创建更具体的 break-repetition-loop，写出“不要把物品放回原位置”的规则，验证分升至 0.78 并被接受。之后 Wiki 又积累同一物品上重复操作的新证据；Iteration 4 再把技能细化为“每种操作对每个物品只做一次”。PURPOSE.md 将最终规则反向链接到促成它的模式与旧提案。
这个案例说明 Wiki 的价值不是让文档无限变长，而是保存跨轮信用分配：同一失败模式出现过几次、哪些抽象修复已经试过、哪次具体修改真正过了验证。论文的统计也显示更新没有只发生在首轮：不同模型仍有 11%–21% 的已接受修改落在 Iteration 5–7。
10 · Cost & Complexity
“每轮 O(1)”只指优化器调用次数，不等于总成本恒定
Wiki Maintainer 每轮用 1 次 LLM 调用汇总抽样轨迹，Skill Proposer 通常进行 10–20 个 ReAct 回合；在作者采用的 full-batch 设置 B = N_train 下，每轮优化器调用因此是 11–21 次，调用数量不随训练题数变化。相较之下，EvoSkill、SkillOpt 按 minibatch 工作，Trace2Skill 还逐条分析轨迹，其优化器调用随训练集增长。
但论文的复杂度口径只统计 optimizer API call。Inference Agent 对全部训练题的 rollout、候选技能的验证、单次请求的 token 长度、Wiki 全文规模与 Proposer 按需读取轨迹的 I/O 都没有消失；把整个训练集塞进一次 full batch 也会把规模转移到单次请求或外部文件读取。__准确说法是优化器调用数对 N_train 为 O(1)，不是端到端计算、token 或延迟为 O(1)__。
当前 Wiki pattern 没有数量上限，也没有自动合并、过期和剪枝；实验中每轮只向 Maintainer 注入最多 8 条轨迹，控制了短期上下文，却没有解决长期知识库持续膨胀后的检索质量与维护成本。这正是方法从 8 轮实验走向长期生产前最需要补的一层。
11 · Boundaries
论文证明了技能质量，不等于已经解决技能平台
- 检索未测所有活跃技能都被完整注入系统提示，刻意排除了 skill retrieval 与 triggering；当技能库变大后，选对技能、控制上下文和处理冲突仍是独立难题。
- 门控短视候选必须严格提高当前验证分，性能持平但能为下一轮铺路的基础修改会被拒绝；组合更新也被“每轮一个原子提案”限制。
- 验证噪声验证集仅 10–40 题，反复门控可能选择偶然波动；三次完整演化与测试集 bootstrap 提高报告稳健性，却不能完全消除搜索过程中的选择偏差。
- Wiki 无剪枝pattern、evolution log 与 proposal diff 只积累不压缩；论文没有自动去重、冲突消解、置信度衰减或遗忘机制。
- 时域有限基准没有覆盖数百步或持续数小时的任务，也没有在单条长执行中在线改技能；当前是离线分轮的 train → propose → validate 流程。
12 · Commentary
点评：Agent 自我改进需要知识编译器，不只是更长的记忆
WikiSkill 最有价值的思想是把 Agent 经验的生命周期做成编译流水线。原始轨迹像源数据，Wiki pattern 像带证据的中间表示，SKILL.md 像面向执行模型的产物，validation gating 则像测试与发布门。失败编译不会污染线上技能，但诊断信息仍进入下一轮；这比“把最近几条失败放进 memory”更适合长期优化。
对实际系统，最值得直接复用的是三个边界：执行者只读已发布技能，维护者保留成功与失败证据，提案者必须给出可审计的单次 diff。下一步则应把论文刻意拿掉的平台问题接回来：技能检索与版本依赖、模式的证据强度和冲突、Wiki 压缩与过期、离线回放加线上 canary，以及对跨模型负迁移的兼容性测试。
因此这篇论文并没有证明 Agent 会无限自我进化；它证明了一个更朴素也更可靠的命题：只要把经验、知识和执行规则分层，并让每次发布接受独立验证，文件系统技能就能成为可积累、可回滚、可迁移的能力资产。
Raw 是证据账本，Wiki 是可修订的假设库，Skill 是通过测试的发布接口；把三者混成一份提示词，就同时失去可追溯性、可探索性与执行稳定性。