围绕让 Agent 根据执行轨迹自动修改 Skill，近期已经出现了一批相似思路的方法：先执行任务，分析成功与失败轨迹，再生成 Skill 修改，并通过验证集决定是否保留。真正棘手的是多轮演化后的经验管理——系统不仅要维护当前 Skill，还要持续记录哪些失败反复出现、哪些修改已经尝试但被拒绝，以及这些经验如何继续影响下一轮更新。
Google Research 与 Virginia Tech 在论文「WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution」中提出的 WikiSkill，关注的正是这层跨轮累积的知识状态。它在原始执行轨迹与可执行 Skill 之间增加了一层持久 Wiki，把“发生过什么”“从中学到了什么”与“现在应该怎么做”分开管理。核心问题也随之收束为：多轮执行产生的经验，如何沉淀为持续支持 Skill 演化的知识？
Raw、Wiki 与 Skill 使用不同的生命周期管理
WikiSkill 将 Agent 工作区拆分为 Raw、Wiki 和 Skill 三层：
Raw 层 保存完整且不可修改的执行轨迹，包括 Agent 的推理、工具调用、工具返回和最终答案，相当于整个演化过程的原始证据，只写入一次。
Wiki 层 负责从原始证据中持续整理知识。其中，
patterns/保存失败模式与成功策略，index.md提供知识模式索引，logs.md记录演化历史，skill-impact.md则保存每次 Skill 修改的 Diff、验证成绩以及接受 / 拒绝结果。随着新的执行证据出现，已有知识模式还会继续被增量修订。Skill 层 保存当前真正提供给执行 Agent 的程序性知识，包括
SKILL.md和PURPOSE.md。候选 Skill 必须通过验证才能成为新的有效版本，效果没有提升时则回滚。
这三层真正重要的区别在于生命周期，Raw 写入后保持不变，Wiki 跨迭代持续保留并维护，Skill 则经过验证后更新，并允许回滚。换句话说，Raw 留证据，Wiki 维护知识，Skill 承载当前经过验证的执行规则。
WikiSkill 的关键并不只是增加一个 Wiki，而是给证据、知识和执行规则定义了不同的生命周期。这里的 Wiki 也不能简单理解成任务执行 Agent 的长期记忆。论文默认限制训练阶段的执行 Agent 访问 Wiki，它主要服务于 Skill 演化过程中的知识整理和后续修改。
WikiSkill 先将执行经验整理成结构化知识
Agent 每执行一轮任务都会产生大量执行轨迹。WikiSkill 没有把完整的历史执行轨迹一次性塞给 Skill Proposer，而是先由 Wiki Maintainer 将执行经验整理成结构化知识，再让 Proposer 按需回查相关知识模式和原始轨迹。
在每轮迭代中，Wiki Maintainer 最多抽取 8 条轨迹，其中最多 5 条失败轨迹用于根因分析、最多 3 条成功轨迹用于提炼有效策略，单条日志最多保留 15,000 字符，再据此创建或更新 Wiki 中的知识模式。
Skill 提案器最开始只获得 index.md、skill-impact.md 和本轮训练结果摘要，随后以 ReAct 方式调用 read_file，按需查看相关的知识模式和原始轨迹，最后针对单个 Skill 提出创建或增量修改。
从知识加工的主路径看，Raw、Wiki 和 Skill 形成了 执行事实 → 结构化知识 → 可执行程序性知识 的递进关系。
但这并不是一条完全封闭的线性链路。Proposer 在生成修改时仍能按需回查原始轨迹，因此 Wiki 并没有完全取代原始轨迹；结构化知识与原始执行证据都会参与后续 Skill 修改。
被拒绝的修改仍会影响后续 Skill 演化
Skill Proposer 提出修改后，候选 Skill 会在验证集上重新测试。只有成绩严格高于当前最佳结果，修改才会保留；否则 Skill 回滚至此前的有效版本。Wiki 不会随 Skill 一起回滚。本轮修改方案、Diff、验证成绩和最终接受 / 拒绝结果状态仍会写入 skill-impact.md，供后续迭代参考。
论文在具身交互基准 ALFWorld 上给出了一个直观案例。Iteration 0 中，Agent 出现重复操作行为，Proposer 提出 goal-directed-action，但没有改善验证成绩，因此被拒绝；后续记录也将这一方案概括为过于抽象。相应修改方案、Diff 和验证结果仍然保留在 Wiki 中。
下一轮，Proposer 基于此前的信息提出更具体的 break-repetition-loop，加入 Never Return an Item to Its Origin Location 等明确动作规则，并通过验证。此后新的循环模式继续出现，Wiki 累积新证据，并在后续迭代继续修改已有 Skill。
失败的修改虽然没有成为当前生效的 Skill，但仍可能成为指导后续演化的知识。Skill 保存“当前应该怎么做”，Wiki 则保留这些规则为什么出现、哪些方案已经试过，以及过去的修改产生了什么结果。
Wiki 的访问边界会影响最终 Skill 的演化效果
论文在 Gemini-3.5-Flash 上对 Wiki 机制进行了消融验证。
当系统移除 Wiki Maintainer 和持久 Wiki，使 Skill Proposer 无法使用跨轮累积知识时，4 项基准测试的平均成绩为 48.7%；完整 WikiSkill 默认配置达到 63.7%，相差 15.0 个百分点。
需要注意的是，这组实验验证的是整套持久 Wiki 机制的贡献。Proposer 不访问 Wiki 的设置中，作者同时移除了 Wiki Maintainer，因此不能把 15.0 个百分点简单理解成“仅给 Proposer 增加 Wiki Access”的独立收益。
当 Proposer 保持 Wiki Access，同时让训练阶段的 Inference Agent 也访问 Wiki 后，最终 Skill 的平均成绩从 63.7% 降到 60.9%。
作者推测，如果执行 Agent 可以直接利用 Wiki 中的知识完成任务，生成的训练轨迹可能无法充分暴露当前 Agent 与 Skill 的缺陷，从而降低后续 Skill 修改获得的信息量。这提示 Skill 演化在设计训练阶段的信息访问权限时，需要同时考虑两个目标：当前任务表现，以及轨迹对 Skill 缺陷的诊断价值。
当前任务得到更多知识辅助，并不一定意味着产生的轨迹更适合后续 Skill 演化。不过，这一机制仍然属于作者解释，而不是已经被单独验证的因果结论。
Skill 与模型能力呈现互补关系
论文在 Qwen-3.5-4B / 9B、Qwen-3.6-27B、Gemma-4-31B 和 Gemini-3.5-Flash 共 5 个模型，以及 LiveMath、SealQA、SpreadSheet、OfficeQA、ALFWorld 共 5 个基准测试上进行了评测。
对照方法包括 Trace2Skill、EvoSkill 和 SkillOpt。所有报告成绩来自完整演化流程的 3 次独立运行平均，并在最终测试结果上进行了成对 bootstrap 显著性检验。
按每个模型的五任务平均成绩看，WikiSkill 都取得了最高平均分；相比各模型对应的最强竞争方法，分别领先 3.3、5.1、10.0、5.8 和 12.0 个百分点。这里比较的是跨基准测试的平均成绩，并不意味着 WikiSkill 在每个“模型 × Benchmark”单项上都排名第一。
至少在论文测试的 Qwen 系列中，模型规模增加并没有让 Skill 的收益消失。WikiSkill 相比无 Skill 的五任务平均增益分别为：
Qwen-3.5-4B：+12.3 个百分点
Qwen-3.5-9B：+17.5 个百分点
Qwen-3.6-27B：+23.9 个百分点
另一方面，有效 Skill 也能弥补部分模型能力差距。Qwen-3.5-9B 使用 WikiSkill 演化 Skill 后，五任务平均成绩为 47.4%，高于不带 Skill 的 Qwen-3.6-27B 的 39.4%。
这并不意味着 9B 模型全面超过 27B，而是说明在论文实验条件下，模型基础能力与程序性知识呈现出互补关系。
跨模型实验进一步揭示了 Skill 与模型之间更复杂的关系。
Qwen-3.6-27B 演化出的 SpreadSheet Skill，可以让 Qwen-3.5-9B 从无 Skill 时的 24.3% 提升到 50.5%，高于其使用自演化 Skill 时的 33.6%。
但 Qwen-3.5-4B 演化出的 SpreadSheet Skill 迁移给 Gemini-3.5-Flash 后，成绩却从无 Skill 时的 50.5% 降到 18.1%。
作者对 Qwen-3.5-4B 在 SpreadSheet 上的执行轨迹进行分析后发现，其 Skill 中包含单行 Python、字符串转换和更碎片化的诊断流程等低层规避策略。这些策略可能帮助源模型避开自身容易出现的执行失败，却会限制更强模型采用完整的端到端方案，同时增加额外工具调用、消耗交互预算。
这些结果提示，演化出的 Skill 可能同时混合两类内容：任务本身较通用的程序性知识，以及为了补偿源模型能力缺口形成的特定策略。论文并没有对两类内容进行独立标注或量化，但负迁移案例说明，后一类策略换到另一种模型上时，可能从源模型的“有效经验”变成新的执行约束。所以，能够迁移，并不代表一个 Skill 与模型无关。
论文也据此将 Skill 发现能力与 Skill 执行能力区分开来理解：一个模型能够从经验中发现有效的程序性知识，并不意味着它自己就是最擅长执行这些知识的模型。
WikiSkill 仍未解决长期运行中的完整问题
WikiSkill 当前主要研究持久知识如何帮助 Skill 演化，因此仍然简化了一些真实系统问题。
首先，实验直接将所有当前生效的 Skill 注入执行 Agent 的系统提示词，没有测试 Skill 库扩大后的检索与触发。验证门控又要求候选 Skill 必须立即严格超过当前最佳成绩，因此可能错过一些短期保持持平、但可能为后续演化提供基础的中间修改。
其次，Wiki 会跨迭代持续积累知识模式、演化记录和 Proposal Diff，但目前没有自动 Pruning 机制。实验也没有覆盖持续数百个环境动作或数小时的超长任务，因此尚不能说明这套方案在真正长期在线演化中的表现。
实验评估也存在现实边界。SealQA 的验证集只有 10 个样本，LiveMath 和 ALFWorld 各为 18 个，小规模验证集可能给每轮 Skill 验证门控带来一定评估噪声。作者通过 3 次独立运行完整 Evolution Pipeline，并对最终 Test Performance 使用 paired bootstrap 检验提高结果稳健性，但这并不能完全消除中间门控决策 Decision 的不确定性。
成本方面，论文附录只比较了 Skill 优化阶段的 LLM API 调用复杂度。WikiSkill 在实验中采用全批次设置，即每轮把整个训练集视为一个批次；Wiki Maintainer 调用 1 次 LLM，再由 Skill Proposer 运行约 10～20 轮 ReAct。因此，在这一实验配置下，优化器部分的 LLM 调用次数不会随着训练样本数量线性增加。
但这并不意味着 WikiSkill 的整体成本是常数。任务执行、模型推理、工具和环境交互都不包含在这项复杂度统计中，论文也没有提供统一的 Token、GPU 或美元成本对比，因此不能据此判断 WikiSkill 更便宜。
WikiSkill 补上的是 Skill 演化过程中一层独立的知识状态——Raw Trace 保留原始证据，Wiki 持续整理和修订经验，Skill 只承载当前经过验证的执行规则。
当 Skill 开始根据 Agent 的真实执行自动演化后，需要管理的已经不只是某个 SKILL.md 的最新版本，还包括这些规则从哪里来、哪些尝试已经失败、哪些知识能够跨模型迁移，以及哪些规则可能只是源模型为了弥补自身能力缺口形成的特定策略。Skill 的持续演化，也需要一套与 Skill 本身分离的知识演化机制。
参考资料
WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution.
