谷歌WikiSkill:为AI智能体构建可持久化、结构化的失败记忆层
谷歌与弗吉尼亚理工提出WikiSkill框架,通过在执行轨迹与技能间引入维基知识层,持久化存储失败诊断与干预记录,避免重复试错。实验显示其显著提升多模型技能演化效果,并支持跨模型迁移。

AI智能体可通过从成功和失败的任务尝试中开发可复用的技能来改进自身行为。但演化这些技能的系统却可能 在演化过程中丢失已学到的知识,迫使其反复重新发现过往的失败。
由谷歌研究院(Google Research)与弗吉尼亚理工学院(Virginia Tech)提出的新框架WikiSkill通过 在智能体原始经验与其所用技能之间添加一个结构化的知识层 来解决这一问题。该框架并非反复从孤立的执行轨迹中推导技能,而是将其从智能体过往经验中收集的信息构建为结构化的维基(wiki),再利用该维基构建未来技能。
在研究人员针对不同领域和模型开展的实验中,WikiSkill均优于现有的技能演化方法。结果还表明,其性能增益可随模型规模扩大而增长,且所演化的技能可在不同模型间迁移。
对于企业级AI团队而言,WikiSkill提供了一种将智能体已生成的执行轨迹转化为可复用知识与技能的途径。
技能演化中缺失的知识层
技能将特定领域的指令、脚本和工作流打包为可复用模块。它们赋予智能体专门的程序性知识,而无需修改模型参数。
然而,技能的创建颇具挑战性。目前许多技能仍需人工编写,这意味着开发者必须预先设想智能体将遭遇的工作流及边缘情况。近期的技能演化框架试图通过让智能体在训练任务上运行、分析成功与失败的执行轨迹,并基于所得经验生成技能更新,从而实现该工作的自动化。
不同系统保留了该过程的不同部分。 Trace2Skill 分别分析成功与失败的轨迹,并将二者经验合并为技能补丁。 EvoSkill 在候选技能程序空间中进行搜索,并向其提案者同时提供失败轨迹以及过往提案的扁平化历史记录。 SkillOpt 采用多阶段反思流水线分析轨迹并更新技能文档。
本文共同作者、谷歌研究员李彦唐(Liyan Tang)表示,即使优化器正确识别出问题所在,有用的诊断信息仍可能消失。“在许多自我改进框架中,优化器可能读取轨迹、提出补丁,随后即丢弃诊断信息,包括哪些修复方案未能通过验证,”唐表示,“这意味着系统会不断重复发现相同失败,并反复提出已被拒绝的修复方案。”
WikiSkill为这些诊断信息及失败干预措施提供了持久化存储位置。即使所提议的技能被拒绝,系统仍会保留促成该提议的知识以及验证测试的结果,使后续迭代能基于该历史记录继续演进,而非每次都从相同信息重新开始。
WikiSkill的工作原理
WikiSkill的灵感源自Andrej Karpathy提出的“LLM Wiki”构想,该构想主张将经验汇编为持久化、可累积的知识。唐如此描述WikiSkill对该概念的适配:“我们保留了Karpathy的设计框架:不可变的源数据、由大语言模型(LLM)维护的维基、索引与日志;但输入变为智能体自身的执行轨迹,输出则为可执行的SKILL.md文件。”
WikiSkill将智能体工作区划分为三层:
原始层(Raw Layer) 原始层 存储不可变的执行轨迹。这些轨迹包括智能体的动作、推理过程、工具调用、工具输出及最终答案。它作为历史记录,如实反映智能体实际所为。
维基层(Wiki Layer) 维基层 将这些轨迹转化为结构化知识。其中包含针对反复出现的失败模式与成功策略的独立页面、演化日志,以及技能影响追踪器——后者记录所提议的技能变更及其是否提升了性能。
技能层(Skill Layer) 技能层 包含智能体在任务执行期间可用的程序性指令。每个技能还反向链接至促使其创建或修改的维基模式。

WikiSkill架构图(来源:arXiv)
每次演化循环包含四个步骤。首先,一个 推理智能体(Inference Agent) 使用当前技能运行训练任务并生成新轨迹。随后,一个 维基维护者(Wiki Maintainer) 然后 分析采样的成功与失败轨迹 并更新维基。接着,一个 技能提议者(Skill Proposer) 读取更新后的维基及选定轨迹,并提议新技能或对现有技能进行编辑。最后,在验证集上评估候选技能集。仅当该变更提升了迄今最佳验证分数时,才予以采纳。
来自ALFWorld(一个文本型模拟环境,智能体在其中完成多步物体操作任务)的案例研究展示了该流程如何运作。在第一轮迭代中,系统识别出一种反复出现的行为:智能体反复拾起、检查并将其放回原位的物体。技能提议者据此创建了一个宽泛的“目标导向动作”技能,但该技能在验证阶段被拒绝。
维基保留了所观察到的行为及被拒绝的提议。在下一轮迭代中,提议者基于同一行为创建了一个更具体的“打破重复循环”技能,其规则为“切勿将物品放回其原始位置”。该变更提升了验证性能并获采纳。当后续轨迹暴露出另一类循环模式时,系统并未从零开始,而是通过增加一条新规则对同一技能进行了细化。
WikiSkill的实际运行效果
研究人员在涵盖数学推理、网络搜索、电子表格、长上下文文档问答长上下文文档问答以及交互式家庭任务。他们测试了Qwen、Gemma和Gemini模型,并将该框架与Trace2Skill、EvoSkill、SkillOpt以及不使用技能的智能体进行了比较。
研究人员发现,WikiSkill在所有被测试模型上均取得了最高的平均分。相较于各模型对应的最强技能演化方法,其优势幅度为3.3至12个百分点。

WikiSkill性能(来源:arXiv)
相较于无技能基线,WikiSkill的平均增益随Qwen模型尺寸增大而提升。 唐(Tang)表示:“我们观察到的并非瓶颈效应:在Qwen系列中,增益随规模扩大而增长——在4B、9B和27B模型上,使用其自行开发的技能时分别提升了+12.3、+17.5和+23.9分。”与此同时,技能可在一定程度上弥补模型尺寸差异带来的差距:启用WikiSkill的Qwen-3.5-9B达到47.4%的平均准确率,而未启用技能的Qwen-3.6-27B仅为39.4%。
在某些情况下,技能还能跨模型迁移。当Qwen-3.5-9B使用由Qwen-3.6-27B演化出的技能时,在ALFWorld上的得分为70.2%,而使用其自身演化出的技能时得分为63.4%。
企业团队可从WikiSkill借鉴的内容
该论文提供了演化算法以及Wiki Maintainer(维基维护者)和Skill Proposer(技能提议者)所用提示词,使得该架构在概念层面易于复现。
核心模式是完整保留全部执行轨迹,从中提取反复出现的成功与失败模式并存入独立知识库,维护一份尝试改进的审计日志,并利用另一智能体将所积累的知识转化为具体的程序性微调。这些调整须通过一项独立验证步骤后,方可纳入活跃技能集。
对于生产系统而言,维基与可执行技能之间的分离亦是一项推理成本决策。唐(Tang)表示:“记忆需详尽完备,而生产环境中的提示词则需精简高效,因此二者合并将导致效果更差的折衷方案。相反,我们完全将维基排除在推理智能体的上下文之外,使生产环境仅需为紧凑型技能付费——在我们的实验中,此类技能长度约为45至129行。”
该论文的消融实验支持这一设计。在基于Gemini-3.5-Flash于四个基准测试上的实验中,标准配置(即Skill Proposer可访问持久化维基,但Inference Agent不可访问)平均得分为63.7%,而当Skill Proposer无维基访问权限且Wiki Maintainer被移除时,得分降至48.7%;若同时向Inference Agent开放维基访问权限,则得分进一步降至60.9%。研究人员指出,若推理智能体能直接从维基知识中解决训练任务,则其运行轨迹所揭示的关于技能本身缺陷的信息将减少。
权衡之处在于技能演化阶段需额外投入工作量。WikiSkill采用ReAct式Skill Proposer,该模型在检查维基与执行轨迹以提出变更前,需在推理与工具调用之间交替进行。在实验中,每次演化迭代需约10至20次ReAct轮次,外加一次Wiki Maintainer调用。然而,由于研究人员将整个训练集以单一批次处理,每次迭代所需的优化器大语言模型调用次数并未随训练样本数量增加而增长。
该架构最适用于反复执行多步工作流、并能积累足够历史数据以显现重复性失败模式与成功策略的智能体。唐(Tang)指出,将维基排除在推理过程之外可在大规模部署时节省计算资源;而更复杂的应用场景未来或可受益于为运行时智能体同时提供技能及精选维基知识——但这需要审慎决定各层应包含的内容,以确保维基对技能文件起到补充而非重复作用。
该论文仍未解答若干生产环境相关问题。WikiSkill将活跃技能直接注入模型提示词,因此未测试随着技能库扩大而产生的技能检索或触发机制;其验证门禁仅接受能立即带来性能提升的变更,即便某些变更虽无即时收益却可能促成后续增益;维基持续增长而缺乏自动化剪枝机制;且实验未涵盖需执行数百个动作或持续数小时的任务。
论文将自动化维基剪枝及长时运行任务中的在线技能自适应列为待解开放问题。唐(Tang)表示,团队已在探索该方向:“实际上,我们当前正研究这一过渡过程,或许只需假以时日即可实现。”
JOTO 企业落地观察
- 对企业部署而言,WikiSkill将维基完全隔离于推理智能体上下文之外,使生产环境仅加载精简技能(45–129行),显著降低推理成本;消融实验证明该设计比混合式记忆方案平均高2.8分,提示企业应明确区分‘训练态知识沉淀’与‘运行态技能交付’。
- 对智能体工程而言,WikiSkill首次系统性解决了技能演化中诊断信息丢失问题——被拒技能的成因、验证失败项及原始轨迹均被结构化存入维基,使后续迭代可基于审计日志精准演进;这要求工程团队建立三层数据契约(原始轨迹→维基页面→SKILL.md),而非仅维护技能文件。
- 对FDE落地而言,该框架依赖足够多历史轨迹以识别重复模式,适用于高频、多步、可复现的工作流场景(如ALFWorld任务);但论文未解决长时任务(数小时)、技能库膨胀后的检索触发、以及无即时收益却具长期价值的变更采纳机制,这些恰是企业真实FDE项目中最常卡点的环节。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


