WikiSkill：将智能体经验编译为持久知识以实现技能演化 WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution
把智能体经验编译进永不回滚的Wiki知识库，与技能协同进化，全面超越现有技能进化方法
前置知识
Agent Skills（智能体技能）
一种轻量、开放的模块化格式：把领域程序性知识（操作流程、脚本、注意事项）打包成文件系统目录，核心是含元数据（唯一名称+简短描述）与完整指令、适用条件的 SKILL.md 文件。智能体执行任务时把技能内容注入提示词，无需更新模型参数即可获得专业能力，并支持渐进式披露（只在需要时加载相关内容）以节省上下文空间。
本文的全部目标就是自动“进化”这种技能目录，理解技能的文件结构与注入方式是读懂 WikiSkill 三层架构的前提。
执行轨迹（Trajectory）
智能体完成一个任务时与环境多步交互的完整记录 $\tau = (o_1, a_1, \ldots, o_T, a_T)$，包含推理、工具调用、工具输出与最终答案 $\hat{y}_i$，其质量由领域评分函数 $f(\hat{y}_i, y_i) \in [0,1]$ 评判。技能进化方法通过分析成功与失败轨迹提炼经验，是本文 Raw 层存储的不可变原料。
Wiki 维护者与技能提议者的所有分析都建立在轨迹之上，轨迹的不可变存储与按需读取是框架数据流的基础。
验证门控（Validation Gating）
在验证集上评估候选技能修改后的分数 $R(\mathcal{T}_{val,k})$，只有超过历史最优阈值 $R_{best}$ 才接受新技能集，否则回滚到上一版本。这是防止技能进化“越改越差”的保守策略，EvoSkill 与 SkillOpt 等前作同样采用，保证对比公平。
WikiSkill 的关键设计是：技能可回滚但 Wiki 永不回滚，理解门控机制才能体会这种不对称设计的意义与代价。
ReAct 范式
推理与行动交替的智能体运行方式：模型先思考，再调用工具（如 read_file），观察返回结果后继续推理，循环直至产出答案。它让智能体以自主代理形式按需检索信息，而非被动接收一次性给定的固定上下文。
WikiSkill 的技能提议者以多轮 ReAct 方式运行，主动查阅 Wiki 模式页与原始轨迹，这一设计让它规避了长执行历史导致的上下文窗口耗尽。
研究动机
智能体技能大多依赖人工编写，作者需要预先猜测智能体完成任务所需的流程知识，成本高且难以覆盖。近期自动技能进化工作（EvoSkill、Trace2Skill、SkillOpt）让智能体在训练任务上执行、分析成败轨迹、迭代修改技能，但指导技能开发的洞见散落在各轮优化的历史产物中：EvoSkill 只累积提案与评估结果的流水账；Trace2Skill 从轨迹中整合教训却没有独立的演化知识表示；SkillOpt 依赖被拒编辑的反馈信号。没有统一、可演化的中间知识层，被拒绝的方案可能在后续轮次被反复重提，跨轮复现的错误也难以系统追踪，导致经验无法长期复利，这是现有方法在高迭代次数下收益受限的根因。
本文的目标是论文想回答一个问题：智能体经验能否像 Karpathy 提出的 LLM Wiki 理念那样，被编译成持久、可复利的知识来支撑长期技能进化？具体目标有三：一是在原始执行经验与可执行技能之间引入一个结构化、跨迭代积累的知识层（Wiki），让每轮技能开发都建立在被验证和整合过的知识之上；二是设计完整的协同进化闭环，保证技能更新有门控、知识更新不回滚；三是在五个基准（LiveMath 数学推理、SealQA 网络搜索、SpreadSheetBench 表格操作、OfficeQA 长文档问答、ALFWorld 具身任务）和五个模型（Qwen-3.5-4B/9B、Qwen-3.6-27B、Gemma-4-31B、Gemini-3.5-Flash）上全面超越 Trace2Skill、EvoSkill、SkillOpt 三个最先进技能进化方法。
与已有工作不同的是，已有方法都把“学到了什么”与“技能本身”混在一起：知识要么以原始轨迹形式散落存在，要么内嵌在技能文档的修改历史里。WikiSkill 受 LLM Wiki 思想启发，独特地提出三层分离——不可变的 Raw 层存轨迹（永久、只写一次）、复利增长的 Wiki 层存结构化模式与演化日志（永不重置）、可回滚的 Skill 层存程序性技能（可逆的条件更新）。最关键的差别是引入 skill-impact.md 审计追踪：每次提案的 unified diff、验证分数、接受或拒绝结果都由外层框架程序化客观记录，技能提议者可据此避免重蹈覆辙；且即使技能因验证分下降被回退，Wiki 依然单向积累，保证跨迭代的知识保留。
核心方法
直觉上，WikiSkill 把智能体工作区当成“实验室+图书馆”：实验室的原始记录（轨迹）不可篡改，图书馆（Wiki）持续把记录整理成模式卡片与演化日志，技能（skills/）则是从图书馆提炼的操作手册。技术上，工作区分三层：Raw 层存不可变轨迹；Wiki 层含 patterns/ 模式页、index.md、logs.md 演化日志与 skill-impact.md 审计追踪；Skill 层含 SKILL.md 与追溯来源模式的 PURPOSE.md。每轮迭代四个组件串成闭环：推理智能体执行 rollout（$\tau_i \sim \pi(x_i; S_{k-1})$）、Wiki 维护者固化模式（$W'_k \leftarrow \mathcal{M}_{WM}(W_{k-1}, \mathcal{T}_{sample,k})$）、技能提议者给出原子提案（$P_k \leftarrow \mathcal{M}_P(W'_k, S_{k-1}, \mathcal{T}_{train,k})$）、门控按验证分 $R(\mathcal{T}_{val,k}) > R_{best}$ 决定接受或回滚。系统从空状态 $(S_0, W_0) = (\emptyset, \emptyset)$ 出发，联合演化 $(S_k, W_k)$ 共 $K$ 轮。
核心创新是把“经验”与“技能”解耦，并让中间知识持久复利。与前作的本质区别有三：其一，Wiki 层是独立、持续演化的知识表示，模式页记录失败根因、成功策略与可操作解法，而 EvoSkill 等只保留提案流水；其二，skill-impact.md 由外层框架程序化写入，客观记录每个提案的 diff、目标技能、验证分数与接受结果，被拒方案（如第 0 轮因过于抽象被拒的 goal-directed-action）不会被再次提出——Figure 3 的案例显示第 1 轮被接受的 break-repetition-loop 正是吸收这次拒绝教训的产物；其三，Wiki 永不回滚，即使技能集因验证分下降被回退到 $S_{k-1}$，跨轮积累的模式、日志与审计记录依然完整保留，为后续提案提供越来越充分的历史上下文，这是“复利”二字的真正含义。
方法步骤详情
第 1 步技能供给：推理智能体的提示词完整注入技能集 $S_{k-1}$（全注入，排除技能触发失败的干扰），但禁止访问 Wiki——消融显示训练时开放 Wiki 会降低轨迹信息量。第 2 步 Wiki 维护：按预算分层采样成败轨迹得 $\mathcal{T}_{sample,k}$，Wiki 维护者对失败做根因分析、对成功提炼策略，用补丁式编辑创建或更新 patterns/ 模式页，修订 index.md 并向 logs.md 追加本轮摘要。第 3 步技能提案：提议者以 ReAct 方式运行，初始只拿到 Wiki 索引、skill-impact.md 与任务成败摘要，用 read_file 按需深挖模式页和轨迹做诊断，产出一个针对单一技能的原子提案（新建或补丁修改）。第 4 步门控回滚：候选技能集 $S'_k = Apply(S_{k-1}, P_k)$ 在验证集评测，仅当 $R(\mathcal{T}_{val,k}) > R_{best}$ 才接受并更新阈值（$R_{best}=1.0$ 提前终止），否则回滚；随后框架程序化向 skill-impact.md 写入 diff、验证分与结论，完成 $W_{k-1} \to W_k$ 转移。
技术新颖性
新颖性体现在架构与机制两个层面。架构上，三层分离让不可变性（Raw）、复利性、可回滚性各得其所，避免了把原始轨迹直接塞进优化器上下文导致的窗口爆炸——Wiki 维护者只看采样轨迹，提议者靠 ReAct 按需读取控制上下文。机制上，skill-impact.md 是程序化写入的客观审计追踪（含完整 diff 与验证分），与 LLM 自主维护的 logs.md 形成主客观互补，使“避免重复失败提案”有据可依；PURPOSE.md 把每个技能映射回激发它的 Wiki 模式，形成从知识到技能的可追溯链路。相较之下，Trace2Skill 虽也跨轨迹整合教训，但缺少持久独立的中间知识层与门控审计；SkillOpt 的被拒编辑反馈只是弱信号，远不如完整 diff 加分数记录信息丰富；EvoSkill 的历史累积没有结构化组织，难以支撑跨迭代的诊断式推理。
实验结果
在 5 基准 × 5 模型上各跑 3 次独立进化并做配对 bootstrap 检验（1000 次，$p<0.05$），WikiSkill 在所有模型平均分第一：相对最强对手领先 3.3（Qwen-3.5-4B，38.5% 对 35.2%）、5.1（9B，47.4% 对 42.3%）、10.0（27B，63.3% 对 53.3%）、5.8（Gemma-4-31B，54.9% 对 49.1%）、12.0 分（Gemini-3.5-Flash，68.1% 对 56.1%）。收益随规模放大：Qwen 系相对无技能基线提升从 4B 的 +12.3 增至 27B 的 +23.9；且技能可补偿规模——9B 加技能（47.4%）反超无技能 27B（39.4%）。单项上，Gemini-3.5-Flash 的 LiveMath 从 33.0% 升至 72.6%、SpreadSheet 从 50.5% 升至 76.6%，27B 的 ALFWorld 从 52.8% 升至 77.6%；基线不稳定，如 EvoSkill 把 Gemma-4-31B 的 LiveMath 拖到 29.8%。迁移（Table 2）：27B 技能把 9B 的 SpreadSheet 从 24.3% 提到 50.5%（自进化仅 33.6%），4B 技能把 Gemma 的 LiveMath 提到 73.1%；也有负迁移，4B 技能把 Gemini-3.5-Flash 的 SpreadSheet 拖到 18.1%。消融（Table 3）：给提议者 Wiki 使平均分从 48.7% 升至 63.7%（+15.0），给推理者开放 Wiki 反而降到 60.9%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| LiveMath 数学推理（Gemini-3.5-Flash） | 准确率 % | 72.6 | 无技能 33.0；最强基线 SkillOpt 49.7 | +39.6 / +22.9 |
| SpreadSheet 表格操作（Gemini-3.5-Flash） | 准确率 % | 76.6 | 无技能 50.5；最强基线 SkillOpt 66.1 | +26.1 / +10.5 |
| ALFWorld 具身交互任务（Qwen-3.6-27B） | 成功率 % | 77.6 | 无技能 52.8；最强基线 EvoSkill 64.2 | +24.8 / +13.4 |
| 五基准平均（Qwen-3.6-27B） | 平均准确率 % | 63.3 | 无技能 39.4；最强基线 EvoSkill 53.3 | +23.9 / +10.0 |
| 五基准平均（Gemini-3.5-Flash） | 平均准确率 % | 68.1 | 无技能 49.5；最强基线 EvoSkill 56.1 | +18.6 / +12.0 |
| SpreadSheet 跨模型迁移（27B 技能 → 9B） | 准确率 % | 50.5 | 无技能 24.3；自进化 33.6 | +26.2 / +16.9 |
| LiveMath 跨模型迁移（4B 技能 → Gemma-4-31B） | 准确率 % | 73.1 | 无技能 33.9；自进化 56.7 | +39.2 / +16.4 |
| Wiki 消融（Gemini-3.5-Flash，4 基准平均） | 平均准确率 % | 63.7（提议者有 Wiki，推理者无） | 无 Wiki 累积 48.7；推理者也开 Wiki 60.9 | +15.0 / +2.8 |
局限与改进
作者承认四点局限：技能全量注入提示词，未评估技能检索与触发，技能数量增多时不可扩展；门控要求每次接受都必须提升验证分，排除了短期中性、却为后续收益铺路的提案；Wiki 层缺乏自动修剪机制，长期运行会无限膨胀；基准不覆盖跨越数百步、数小时的超长视野任务。我的补充观察：整个框架依赖带标签的训练/验证/测试划分，每轮门控都要额外跑完整验证 rollout，加上每方法 3 次独立重复，API 与算力成本相当可观（附录 D 专门分析了各框架优化器的调用复杂度）；OfficeQA 上小模型无法执行多步检索流程——Qwen-3.5-4B 反而从 30.2% 降到 28.5%——说明技能收益与模型执行能力强耦合，弱模型消费技能时会退回默认行为；此外进化在固定离线数据集上进行，与真实生产环境中任务分布漂移的情形仍有差距。
独立分析的弱点
首先是全注入设定的可扩展性硬伤：Table 4 显示 SpreadSheet 技能平均长达 142.5 行，多个技能叠加会迅速吃满上下文，论文完全回避了技能选择问题，工程落地必须补上检索层。其次是 Wiki 膨胀风险：每轮都新增模式页并追加日志，Qwen-3.5-4B 平均创建 8.8 个模式、编辑 18.4 次，数百轮之后提议者光读索引和 skill-impact.md 就可能超窗，需要模式合并、过期淘汰或检索式 Wiki 访问。第三，负迁移缺乏防护：4B 技能因编码了单行 Python 命令、字符串转换等低级 workaround，并引入碎片化诊断流程耗尽交互预算，把 Gemini-3.5-Flash 的 SpreadSheet 从 50.5% 拖到 18.1%，框架没有任何机制区分“通用流程”与“模型特定补丁”。第四，门控信噪比：小验证集上的分数提升可能来自采样方差，且严格阈值排除了中性但奠基性的提案。改进方向包括给技能添加适用模型范围元数据、为验证分引入置信区间、让提案者通过 RAG 访问 Wiki。
未来方向
作者提出的方向包括：把技能检索/触发与技能质量研究结合；设计更灵活的接受准则，允许中性提案换取后续收益；为 Wiki 增加自动修剪与知识压缩；覆盖单次长 rollout 内的在线技能自适应。基于本文成果还可延伸：其一，skill-impact.md 的审计追踪天然适合做技能谱系分析与因果归因，可系统研究哪类 Wiki 模式真正驱动分数提升；其二，迁移实验中“外来技能反超自进化”（9B 用 27B 技能在 ALFWorld 达 70.2% 对 63.4%）提示技能发现与技能执行是两种独立能力，可构建“技能市场”——强模型专职进化技能、弱模型付费消费；其三，把 Wiki 层与非参数记忆、模型微调等参数化记忆做对照，检验程序性知识两种载体的样本效率边界；其四，多智能体共享同一 Wiki 时的知识冲突检测与合并策略；其五，把三门控标准放宽为允许不伤害下游上限的中性重构。
复现评估
复现难度中等。有利条件：五个基准全部公开（LiveMath、SealQA、SpreadSheetBench、OfficeQA、ALFWorld）；四个开源权重模型（Qwen-3.5-4B/9B、Qwen-3.6-27B、Gemma-4-31B）可用 vLLM 部署，Gemini-3.5-Flash 走 API；附录提供了完整算法（Algorithm 1）、数据集统计、轨迹采样预算与分层准则（附录 C）、优化器调用复杂度对比（附录 D），方法叙述相当细致，公式与流程图齐备。不利条件：论文未提及开源代码，Wiki 维护者与技能提议者的提示词模板、模式页格式、补丁编辑的容错处理都需要自行摸索；每轮需要训练加验证两套 rollout，5 模型 × 5 基准 × 3 次独立运行的总量意味着不小的 API/算力开销；显著性检验需 1000 次配对 bootstrap。建议复现者先在信号最强的 ALFWorld（4B 提升 +29.3）上用小模型跑通闭环，再逐步扩展到其余基准。
论文图表
把各模型与各基准被接受的技能更新按早期（第 0–1 轮）、中期（第 2–4 轮）、后期（第 5–7 轮）分组统计：模型维度上早期占 39%–52%，其余持续分布在中后期；基准维度早期占 39%–58%，其中 SealQA 上 33% 的接受更新发生在中期、28% 在后期，说明技能精化贯穿整个进化过程。
支撑“技能精化依赖持久知识持续进行”的论点：若没有 Wiki 保留复现错误与历史证据，后期难以继续产出被接受的更新。