Google Research 提出了一个名为 WikiSkill 的框架：让 AI Agent 把踩过的坑变成会积累的技能，自我进化
让 AI Agent 把执行任务中的经验和教训沉淀为持久 Wiki，持续进化出更强的可执行技能。
- WikiSkill 把 Agent 经验沉淀为持久 Wiki，让技能能够持续进化。
- Raw、Wiki、Skills 三层分开：Skill 可以回滚，经验不会跟着消失。
- WikiSkill 在五个测试模型上平均分均领先现有基线，9B 加技能还能超过无技能的 27B。
Google Research 和弗吉尼亚理工大学提出了一个名为 WikiSkill 的框架，核心目的是让 AI Agent 能够将执行任务中的经验和教训，沉淀为像维基百科（Wiki）一样的持久知识库，进而持续进化出更强大的可执行技能。
也就是研究如何让 AI Agent 从一次次任务中学习，并把零散经验逐步变成以后可以直接使用的能力。
为什么需要 WikiSkill？（背景与痛点）
今天的 AI Agent 已经能根据执行记录自动生成 Skill。比如它做表格时反复写错公式，系统可以总结出一条“写入后必须重新读取并校验”的操作规则，放进下一轮 Prompt，让它以后少犯同类错误。
问题在于，以往的技能进化方法主要在优化“当前这份 Skill”，并没有单独维护一套持续增长的知识。EvoSkill 会保存历次提议及其评测结果，Trace2Skill 会从轨迹中提炼经验，SkillOpt 会利用被拒绝的修改继续优化；但这些信息大多留在优化历史里，或者被直接压缩进新版 Skill。
这会带来三个问题：
- 经验很难跨轮次复用：第六轮遇到的错误，系统未必知道第二轮已经分析过相似根因。
- 失败修改的价值容易丢失：某次 Skill 更新虽然让分数下降，但它暴露出的错误模式仍然有用。只回滚 Skill，系统下次可能提出近似方案，再付一次验证成本。
- Skill 承担了过多职责：它既要保存经验，又要作为执行时的简洁指令。经验越积越多，Skill 越容易膨胀；压缩得太狠，又会丢掉形成规则的原因和适用边界。
WikiSkill 引入的 Wiki，就是为了解决这层知识断档。它把“发生过什么”“从中学到了什么”“执行时具体遵守什么”拆开保存，让失败经验也能成为下一轮优化的输入。
WikiSkill 的“三层知识架构”
WikiSkill 的设计重点不只是一套新 Prompt，而是一个分层工作空间：
- 原始层（Raw Layer）保存证据：这里记录完整执行轨迹，包括推理过程、工具调用、工具返回和最终答案。文件只写不改，保证后续分析看到的是当时真实发生的过程，而不是被事后总结改写过的版本。
- 维基层（Wiki Layer）保存认识：Wiki Maintainer 会把多条轨迹中的共同模式整理成独立页面，例如某类失败为什么发生、哪些做法有效、有什么可执行的修复办法。
logs.md记录每轮发现，skill-impact.md记录每次 Skill 修改、验证分数以及接受或拒绝结果。 - 技能层（Skills Layer）保存动作规则：执行 Agent 真正读取的是这里的
SKILL.md。配套的PURPOSE.md会指出这条 Skill 源自哪些 Wiki 模式，使一条简短规则仍然能追溯到背后的证据和原因。
三层分别解决“可追溯、可积累、可执行”。Raw 防止事实被覆盖，Wiki 防止经验随版本消失，Skills 则保持执行指令足够集中。Skill 可以回滚，Wiki 不回滚；系统因此可以撤销一次无效改动，同时保留“为什么这次改动无效”的知识。
论文原图：三层资产和四步循环
Figure 2 把 Raw、Wiki、Skill 三层与执行、归纳、提案、验证回滚四步放在同一张图里。正文最重要的解释是：执行阶段只读 Skill，失败时回滚 Skill，不回滚 Wiki。
系统是如何循环演进的？（四步工作流）
一次完整迭代分为四步：
- 推理执行（Inference Agent）：Agent 带着当前 Skill 去做训练任务，所有过程写入 Raw Layer。论文刻意禁止它在这一步读取 Wiki，因为 Wiki 是给“改进技能的人”使用的分析资料，直接交给执行者可能让它绕过 Skill 完成任务，产生失真的训练轨迹。
- Wiki 维护（Wiki Maintainer）：系统从本轮轨迹中抽取最多 8 条样本，最多包含 5 条失败和 3 条成功。失败轨迹用于定位根因，成功轨迹用于提炼有效策略、避免把已经正确的行为改坏。新的发现会新增或修订
patterns/页面，并写入演进日志。 - 技能提议（Skill Proposer）：Proposer 先看到 Wiki 索引、历史修改结果和本轮任务成败摘要，再通过 ReAct 主动选择要读取的模式页面与原始轨迹。它每轮只创建或修改一个 Skill，避免一次改动混入太多变量，导致验证失败后无法判断是哪条规则出了问题。
- 门控与回滚（Gating & Rollback）：候选 Skill 要在验证集上超过历史最好成绩才能保留；持平或下降都会回滚。无论结果如何，修改差异、验证分数和接受结论都会写进
skill-impact.md，成为下一轮提议时可查询的历史。
这个循环的价值可以用一个具体过程理解：某轮发现 Agent 在环境中反复把物品拿起、检查、放回原处，于是提出一条修复规则，但验证没有提升，Skill 被回滚；Wiki 仍保留“循环行为”和“这条修复无效”的记录。下一轮 Proposer 在此基础上提出更具体的“不要把物品放回原位”，验证通过后再加入 Skill。后续遇到新的循环变体，还能继续细化为“同一物品的每种操作只做一次”。
点击“验证通过”或“验证失败”，可以看到一次迭代中 Raw、Wiki 和 Skills 三层分别发生什么变化。
验证结果不同，回滚的对象也不同
点击一种验证结果，比较 Raw、Wiki 和当前 Skill 怎样变化。
本轮成功与失败轨迹写入 raw/，保持不可变。
patterns、演化日志和 Skill 影响记录继续更新。
候选修改成为新的活动 Skill。
通过时，知识和执行规则同时前进；原始证据仍保留。
验证通过：Raw、Wiki 和新 Skill 都保留，本轮修改进入下一轮执行。
验证失败：Raw 与 Wiki 保留，候选 Skill 回滚到上一版。
核心实验结论与高价值发现
研究覆盖五类差异很大的任务：数学推理 LiveMath、网页搜索 SealQA、表格操作 SpreadSheet、长文档问答 OfficeQA，以及需要连续采取行动的具身环境 ALFWorld。测试模型包括 Qwen 4B、9B、27B、Gemma 31B 和 Gemini-3.5-Flash；对比对象包括无 Skill、Trace2Skill、EvoSkill 和 SkillOpt。所有结果都来自三次完整进化流程的平均值，并用配对 Bootstrap 检验差异。
第一，WikiSkill 的优势不是集中在某一个模型上。 五个模型的平均分都超过其他技能进化方法。相比每个模型各自最强的竞争方法，WikiSkill 分别再提高 3.3、5.1、10.0、5.8 和 12.0 个百分点。Gemini-3.5-Flash 在 LiveMath 上从无 Skill 的 33.0 提升到 72.6，在 SpreadSheet 上从 50.5 提升到 76.6；Qwen-27B 在 ALFWorld 上从 52.8 提升到 77.6。
论文原表：五个模型上的主结果
Table 1 不是点缀，它是这篇论文最硬的证据：五个模型的平均分全部由 WikiSkill 领先，其中 9B 加 WikiSkill 还能超过 27B 无 Skill。
第二，模型变大和 Skill 进化会相互放大。 Qwen 系列从 WikiSkill 获得的平均增益随规模增加：4B、9B、27B 分别提高 12.3、17.5 和 23.9 个百分点。更强的模型不仅能总结出更好的程序性规则，也更能稳定执行复杂 Skill。同时，Skill 又能部分补偿模型规模：带 WikiSkill 的 Qwen-9B 平均分为 47.4，高于不带 Skill 的 Qwen-27B 的 39.4。
第三，技能可以跨模型迁移，但迁移方向不能想当然。 Qwen-27B 进化出的表格 Skill，让 Qwen-9B 在 SpreadSheet 上从 24.3 提升到 50.5，明显高于它使用自进化 Skill 时的 33.6。Qwen-4B 形成的 OfficeQA 检索 Skill 对自己没有帮助，成绩从 30.2 降到 28.5；交给 Qwen-27B 执行时，却能把 42.1 提高到 52.9。这说明“从经验中发现规则”和“把规则执行好”是两种不同能力。
迁移也可能失败。Qwen-4B 的表格 Skill 会让 Gemini-3.5-Flash 从 50.5 降到 18.1。论文检查轨迹后发现，小模型为了避免自身执行错误，写入了单行 Python、字符串转换等低层补丁；这些规则能保护小模型，却限制了强模型使用完整脚本，还会制造多余工具调用，提前耗尽交互预算。可迁移的是通用程序，针对某个模型弱点形成的权宜办法则可能变成束缚。
论文原表：跨模型迁移矩阵
Table 2 同时保留了正迁移和负迁移。别只看最亮眼的那几格，18.1 那个反例同样关键。
第四，消融实验验证了 Wiki 应该服务于技能进化，而不是直接参与做题。 当 Inference Agent 不读 Wiki 时，Skill Proposer 可以读 Wiki，Gemini-3.5-Flash 的四项平均分为 63.7；把 Proposer 的 Wiki 也拿掉，平均分降到 48.7。相反，如果 Inference Agent 和 Proposer 都读取 Wiki，平均分只有 60.9。论文的解释是：执行 Agent 如果能直接从 Wiki 获得任务知识，就可能在 Skill 不完善的情况下也做对训练题，留下的轨迹反而无法准确暴露 Skill 缺了什么。
切换 Wiki 访问权限，看最终 Skill 质量怎样变化
切换两类 Agent 的 Wiki 访问权限，比较四种配置的实测分数。
默认配置：执行 Agent 不读 Wiki，提案者读取 Wiki。平均分最高，为 63.7。
| 执行 Agent | 提案者 | 四项平均分 |
|---|---|---|
| 不读 | 不读 | 48.7 |
| 读取 | 不读 | 45.3 |
| 不读 | 读取 | 63.7 |
| 读取 | 读取 | 60.9 |
查看论文 Table 3 原表
Table 3 同时列出两类 Agent 的四种 Wiki 访问配置。默认 WikiSkill 配置是 Inference Agent 不读、Skill Proposer 读取。
实验也显示，Skill 进化并非对所有任务和模型都同样有效。Qwen-4B 在 OfficeQA 上使用 WikiSkill 后从 30.2 降到 28.5，因为它在超长文档中难以持续遵循多步检索流程。Gemini-3.5-Flash 在 ALFWorld 的验证集起点已经达到 100%，系统直接提前停止，因此各方法在测试集上都保持 85.9。WikiSkill 改善的是“可以通过程序性经验修正的错误”，无法保证每个组合都上涨。
局限性与未来方向
WikiSkill 证明了持久知识可以帮助 Agent 进化 Skill，但它距离运行中的 Agent 自主成长还有几道明确边界：
- 没有解决 Skill 检索：实验把全部活跃 Skill 直接注入系统 Prompt，以排除触发失败这个变量。Skill 数量扩大后，如何为当前任务选对 Skill，仍需要独立的检索与路由机制。
- 门控标准过于严格：候选 Skill 必须立刻超过历史最好验证成绩才能保留。某些短期持平、但能为后续改进打基础的修改会被拒绝，进化可能卡在局部最优。
- Wiki 会持续膨胀：当前系统没有自动合并重复模式、处理冲突知识或清理过时页面的机制。迭代时间拉长后，知识库本身也需要治理。
- 实验属于离线、多轮进化：系统先跑训练任务，再维护 Wiki、修改 Skill、做验证。论文没有测试一个持续数小时、包含数百次环境动作的任务中，Agent 能否边执行边学习并立即调整策略。
因此，这篇论文展示的是一套“经验进入知识库、知识再编译成 Skill”的可验证进化机制。它让 Agent 的失败不再只是一次性日志，也让被回滚的方案仍能留下可利用的经验；但这种学习目前发生在任务批次之间，还不是 Agent 在真实工作过程中实时改写自己的能力。