做AI Agent开发的朋友大概率都体会过什么叫一觉回到解放前上周调通的工具链这个星期换了个环境就要重新调试上一个会话里Agent已经摸清了API的脾气新开一个Session又变成完全陌生的新手本地部署的小模型虽然省钱省心可在复杂任务上总是差大模型一截。Google WikiSkill这个提法刚在技术社区里热起来的时候我第一反应是会不会又是给 RAG 换了个马甲但顺着它持久记忆经验库的设计逻辑捋完才发现它把Agent记忆问题拆成了几个很工程化的子问题而且确实能让小模型在特定任务范围内追平甚至反超不携带任何历史经验的大模型。这里不打算做论文搬运我只讲自己和团队按照这套思路在本地模型和Agent框架里实际跑过一遍之后的理解它解决什么问题、链路怎么实现、省了多少钱、踩了多少坑。如果你正在做Agent开发或者正纠结要不要为复杂任务升级一个更大的模型这篇文章应该能给你一个更省成本的选项。1. 为什么AI Agent普遍“失忆”先理清持久记忆到底在解决什么问题1.1 三层记忆一层都不能混平时大家聊Agent记忆经常把几个概念混在一起。我习惯把记忆拆成三层来理解。第一层是短期工作记忆也就是触发模型推理的一次请求里携带的上下文Token相当于人脑海中正在处理的信息第二层是会话级记忆通常指一个Session内保留的多轮消息历史第三层是长期经验记忆指跨会话、跨任务甚至跨Agent实例复用的技能与方法论比如调用这个内部接口必须带某种Header否则一定报401这类结论。很多人以为加长上下文窗口就是在给Agent增加记忆这个观点需要纠正。上下文窗口再长也只属于短期工作记忆的范畴它只是让模型这次请求能看得见更多材料窗口一旦清空模型对刚才任务中学到的东西不会有任何存留。会话来来去去模型参数原封不动它就永远没有真正的成长。WikiSkill之所以值得研究正是因为它把记忆落到了第三层经验不再靠模型参数承载而是外置到一个可增长的系统里。1.2 三个让我崩溃的“失忆现场”实际用过Agent处理多步骤任务的人对下面这三个场景应当不会陌生。第一个场景是任务进程重启后一切归零。我做一个自动归档工具时Agent需要依次调用文件解析、格式转换、结果校验等多个工具中途某一步因为网络异常抛了错进程一重启之前所有的试探过程全部丢失它只能靠通用知识重新去猜第一步该做什么。这个问题是任何无状态Agent都躲不开的每一步的中间结论只存在于内存流程一断经验归零。第二个场景是长会话越往后越迷糊。任务链条长了以后上下文里有大量噪音早期确定的关键约束会被逐渐挤到窗口边缘甚至被截断。结果就是Agent处理到后半段开始偏离最初目标还可能在同一个错误策略上反复重试。第三个场景是不同任务之间完全没有经验迁移。今天刚把批量PDF转Markdown的完整链路打通明天来一个Excel批量转CSV的需求Agent照样毫无概念地从零开始探索。其实这两种任务的难点高度相似只要有点经验沉淀第二次处理的成本可以降一大截可惜没有记忆它每一秒都像第一次上班。这三个场景合在一起已经把该做持久记忆的原因说得很透单纯把聊天记录存下来再用RAG翻出来并不能解决任务中断恢复和技能迁移问题。真正要存的是任务如何完成的结构化知识而不是一句句对话带来的表面上下文。1.3 大模型的知识是固化的Agent的经验是可增长的有朋友会问与其搞这么一套经验库为什么不直接换更大模型或者做微调呢这个疑问很合理。大模型参数量大、训练语料广很多通用任务确实比小模型能打。但一个容易被忽略的事实是模型训练完成后知识就冻结在权重里了。你今天项目里遇到的业务逻辑、内网工具的报错模式、团队特有数据规范模型在训练时根本没见过训练结束后也没有任何途径自动更新。经验库正好补充了模型在项目内动态知识上的短板。把知识放在模型之外更新知识时不需要重训模型成本低、风险小。微调也不是不行但我更愿意把它当作经验库跑了一段时间之后的进阶手段当某些高频经验被反复命中确实可以尝试蒸馏进小模型参数但从零开始就用微调来解决记忆问题投入产出比并不理想。大模型是底子好但记性差经验库驱动的小模型是底子一般但愈用愈熟后者在重复性高的真实业务场景里赢面反而更大。2. WikiSkill的经验库到底特别在哪不是聊天记录垃圾场而是技能Wiki2.1 它关心的不是“发生了什么”而是“遇到这种情况该怎么做”WikiSkill这个名字本身很能说明问题Wiki加Skill写的不是日记是一本How to手册。主流RAG做的是找资料回答问题把文档切块后按相似度取回解决的是查资料需求。但Agent在完成任务时真正需要的是按什么流程操作、选哪个工具、传什么参数、避开哪些坑这类方法论。如果只是把聊天记录塞进向量库检索回来的内容难免带着语气词、上下文指代和无关信息模型还得再从一团乱麻里重新提炼效果非常有限。所以我理解中的WikiSkill核心在于把经验当作技能来管理而技能是有结构的。触发条件说明什么时候该用我操作步骤说明具体怎么执行失败模式说明哪儿容易翻车。技能库里既存成功的标准路径也存失败的反面教训。有了这层结构化设计Agent才能在拿到当前任务时快速判断这个我熟并且按图索骥地执行。2.2 一条可以复用的技能至少要有三要素根据实际维护经验一条能真正复用的技能条目至少包含三个核心部分。第一个是触发条件它需要描述任务类型和输入特征例如输入文件扩展名是PDF目标输出是Markdown。没有触发条件后面的步骤写得再好检索召回阶段也找不准。第二个是操作步骤最好是工具调用序列这样比较确定的指令形式而不是一长段自由文本。自由文本留给模型的解释空间太大不同轮次执行结果会变得不稳定。第三个是失败模式也就是把历史踩过的坑提前写清楚。举个具体例子技能库里有一条PDF转Markdown的经验失败模式里写明扫描版PDF没有文本层直接抽取只会得到空字符串需要先接OCR服务。下一次Agent再遇到扫描版PDF时检索到的技能已经把坑标出来了它会直接绕开而不是从头踩一遍。这一条警告的价值往往比十步标准流程还要高因为错误路径省掉的是最昂贵的时间成本。2.3 “小模型加经验库能逆袭大模型”的真实边界在哪里说逆袭之前必须先划清边界它不是全面碾压而是在特定任务集合内部的小胜。小模型受参数量限制单次推理掌握的信息确实不如大模型广但正因为如此它对局部上下文非常依赖。只要经验库能精准地把与该任务高度相关的方法注入上下文小模型实际上是拿着完整的解题手册在做题。大模型能力强但没有手册时面对一件陌生且需要多次试错才能摸清规则的业务任务它每次都得靠通用常识临场摸索。把同一类任务重复几十遍之后带经验库的小模型会越做越稳不带记忆的大模型则每次都像第一次。用一个职场比喻来说就是一个普通工程师坚持维护团队Wiki三年后处理项目内部问题的效率往往超过一个很聪明但不了解项目历史的新人。这个现象不算玄学本质上就是熟能生巧被工程化之后的必然结果。3. 核心链路拆解经验如何采集、存储、检索和更新3.1 经验采集不是只记成功失败经验更值钱把经验库建起来的第一步是回答经验从哪来。实际做法不需要人工整理大段文档而是在Agent每次执行任务时自动留下完整轨迹。我在系统里埋了几个采集点每个工具的名称、入参、出参、异常信息、调用顺序都按统一格式追加到当次任务的Trace里。任务结束后再用一段复盘Prompt驱动模型做总结回答几个固定问题任务目标是什么、实际采用了哪些步骤、中间是否出现和预期不一致的偏差、如果下次再遇到同类任务会怎么调整。要注意的是任务失败同样要沉淀而且失败经验往往比成功经验更具指导意义。一个反直觉的操作是我先入库的反而不是那些顺风顺水的成功案例而是那些踩过坑、绕了远路、最后才找到正确路径的轨迹。失败里挖掘出的此路不通信号能让后续执行直接跳过整个错误分支效率提升比反复确认正确路径还要明显。当然涉及用户隐私的数据在入库前一定要做脱敏处理字段内容能泛化就泛化不要为了经验而牺牲安全底线。3.2 存储结构一份可以直接照抄的JSON Schema经验存成什么结构直接决定后面好不好取用。我使用过好几版结构目前稳定下来的一份Schema大概长这样{ skill_id: pdf-to-markdown-v3, goal: 将PDF文件转换为Markdown格式并保留章节结构, trigger_conditions: [ 输入包含.pdf格式文件, 目标输出为markdown格式 ], workflow: [ {step: 1, action: 检查PDF是否包含文本层, tool: pypdf}, {step: 2, action: 逐页抽取文本与标题信息, tool: pymupdf}, {step: 3, action: 按标题层级切分内容段落, tool: python-re}, {step: 4, action: 输出.md文件并补齐表格分隔符, tool: builtin} ], key_parameters: { scan_mode: false, min_heading_length: 2 }, failure_modes: [ {symptom: 扫描版PDF无文本层, action: 先接OCR服务识别文本} ], tags: [pdf, conversion, document], confidence: 0.95, success_count: 19, fail_count: 1, last_used_at: 2026-06-18T11:30:00Z }设计这套结构时有几个刻意的选择。workflow用列表而不是自然语言长文本是为了后续可以把它直接当指令序列去执行解析成本低也不容易产生歧义。success_count和fail_count不是装饰字段它们是计算置信度的基础也是自动淘汰劣质技能的主要依据。confidence字段用来控制检索阶段是否把这条技能放出来如果一条技能此前失败率很高检索时宁可不返回它也不能让它误导当前任务。3.3 检索策略先理解任务再混合召回技能入库之后怎么在关键时刻找回来是整个系统里最讲究的部分。传统RAG用向量相似度匹配就够但WikiSkill面对的Query往往是一段任务描述这类文本和技能条目里的抽象表述在字面上差别很大。比如用户会写帮我整理一下昨天销售部发来的那些表而技能库里存的是多源Excel报表合并与汇总。如果直接拿原始描述去做向量检索匹配效果不会理想。我的做法是给检索前面加一道任务理解工序。先让一个小模型把用户任务解析成结构化要素包括目标动作、输入数据类型、期望输出格式、约束条件。然后同时拿解析结果和原始描述做两组向量检索再用关键词和标签做一次精确召回最后用重排序模块选出最优的两三条技能注入当前上下文。经验库规模不大时这套混合召回在毫秒级就能完成完全不会成为整条链路的性能瓶颈。还有一个小技巧是定期做同义扩充把用户在真实使用中产生的不同说法补充到触发条件里面检索命中率会在两三个星期内肉眼可见地上升。3.4 更新与淘汰经验库是活的不是只进不出的垃圾桶经验库如果只增不减很快会被过时和错误的经验塞满最终拖垮检索质量。我维护过程中相当依赖三个机制。第一是置信度每次任务成功会把成功计数加一失败则扣减当置信度跌破阈值时该技能会暂时不参与检索。这种机制能自动屏蔽一些偶发错误导致的坏经验。第二是去重新增经验和已有条目比较时如果两者核心workflow基本一致就不创建新条目而是合并进旧条目顺手把新的失败模式补充进去。第三是下架当编号技能被新版本取代时旧版本不会立刻删除而是标记为superseded保留一段时间便于回溯对比。经验库长了以后需要类似代码重构一样的定期整理。我通常每两星期做一次压缩把多条高度相似的workflow合并成一条带变体的抽象技能把重复冗余的字段清理干净。这一步跟整理个人笔记很相似不整理笔记只会越来越乱整理到位笔记才会变成真正随取随用的武器。4. 从零搭建WikiSkill式Agent一份可落地的工程参考4.1 技术选型别一上来就上重型设施工程落地时选型比想象中简单。很多团队一提到经验库就联想到要搭一套分布式向量数据库其实根本没必要。我自己验证下来技能条目在几千条以内时用SQLite加全文索引就足够结构清晰、备份方便检索速度也在几十毫秒级当技能条目超过五千条且查询语义变化较大时再引入向量库比较划算。模型层面的选择可以考虑兼顾效果和成本的小模型方案。主Agent模型如果希望本地部署可以用Qwen2.5-7B-Instruct这类中文能力均衡的量化版本显存开销大概六七GB消费级显卡就能跑语义向量模型可以用BGE-small系列。如果任务偏代码生成代码能力更强的DeepSeek-Coder系列会更适合。这里有一个值得强调的原则不要让本地小模型硬扛所有环节。经验库方案的优势之一是可以把执行和反思拆开在线用小模型完成执行和推理用离线或低频调用的更强模型来生成高质量经验总结。4.2 一次任务的生命周期从零经验到一次检索命中下面这段伪代码基本描述了一条任务在WikiSkill式系统中的完整路径from dataclasses import dataclass, field dataclass class TaskTrace: task_id: str goal: str steps: list field(default_factorylist) success: bool False error: str class AgentMemory: def retrieve(self, raw_task: str) - list[dict]: # 1. 把原始任务解析成结构化目标例如目标动作、输入类型、输出格式 parsed summarize_task(raw_task) # 2. 同时用原始描述和解析结果进行混合召回 candidates hybrid_search(raw_task, parsed) # 3. 重排序后只保留两到三条 return rerank(candidates, top_k3) def store(self, trace: TaskTrace): # 1. 基于任务轨迹生成结构化技能条目 skill reflect(trace) # 2. 先去重相同workflow的新经验合并进旧技能 if similar_exists(skill): merge_into_existing(skill) else: insert(skill) memory AgentMemory() task_queue load_tasks() while task_queue: task task_queue.pop(0) skills memory.retrieve(task.description) agent create_agent(extra_skillsskills) # 把命中的经验注入system prompt result_trace agent.run(task) memory.store(result_trace)首次执行某一类任务时经验库里没有可命中的技能Agent只能靠基础模型能力从零开始探索这是正常现象。关键是要保证整个探索过程被完整追踪。任务结束后反思模块把它总结成一条新技能入库。从第二次遇到同类型任务开始Agent就能检索到历史经验直接用上版本路径试错次数会断崖式下降。4.3 我跑过的一次内部快速测试效果和边界都观察到了为验证思路我用本地Qwen2.5-7B跑过一个办公自动化场景的实验任务集合包括文档格式转换、报表合并、数据清洗和简单摘要生成共设计20条代表性任务。对照组有三个无经验库的7B小模型、带经验库的7B小模型、纯API大模型但不带经验库。每组任务执行三轮记录首次尝试成功率与平均单任务耗时。结果很有意思。前几轮任务中7B模型明显挣扎首次成功率不到大模型的一半。但跑到第15条任务左右带经验库的7B模型已经开始逼近大模型水平。等到三轮任务全部结束带经验库的7B模型在首次尝试成功率上反超了大模型平均耗时也更低。这个结果发布前我必须坦诚说明边界实验任务集中在高度重复的办公自动化工序上任务的类型多样性有限所以带经验库的模型有充分机会积累对应技能。如果换成开放性极强、每个问题都完全不同的场景这个优势不会这么明显。4.4 成本算一笔账为什么这对中小团队更友好成本大概是很多团队真正关心的问题。我以5000次Agent调用为一个比较周期估算过两种方案。假设单任务平均消耗5000个Token如果全部调用顶级大模型API累计Token消耗大约2500万按市场价算是一笔不小的月度支出而本地部署一个7B量化小模型硬件投入是一次性的日常只有电费和运维成本。再加上经验库使小模型首次成功率上升、重试次数下降实际Token消耗还有进一步压缩的空间。这套方案的另一个隐性收益是数据安全。业务数据在处理过程中不出本机经验库也完全由自己掌控这在涉及内部报表和客户信息的场景里非常友好。很多团队不敢把内部流程交给需要外传数据的Agent方案而WikiSkill式架构天然规避了这一层顾虑。成本更低、数据可控、效果不差这三点组合起来就是它有落地吸引力的关键。5. 实践中躲不开的坑和排查思路5.1 被污染的经验比没有经验更危险经验库最严重的事故不是检索不到经验而是检索到一条错误经验且照着执行。我自己就栽过一次某次任务实际上没被正确执行但因为外部信号没有校验到位系统误判成功还把一段错误路径写成了正例技能。后续连续几个同类任务全部沿着错误路径走效果比完全没有经验库还要差因为它不再从零搜索而是自信地重复一个错误方案。从此我设置了一条强制规则只有经过外部结果强验证成功的任务才允许写入成功类技能。所谓外部验证可以是工具返回值、文件内容校验、接口状态码或者任务结果通过独立规则校验。总之不能单看Agent自己说我完成了就入库。每一条技能第一次写入时置信度也应当从一个较低的数值起步连续两三次成功后再逐步提升给错误经验留出被纠正的窗口期。5.2 小模型输出的结构化内容总是不稳定解析连续翻车小模型生成JSON时偶尔会少一个右括号或者把布尔值写成字符串这在刚上手时极其折磨。踩过几次之后我的习惯是要么为模型启用JSON Mode或Function Calling选项让解码过程受约束要么把提示模板换成严格的Few-Shot在示例里写出完整JSON结构而不是让模型自行发挥。只要Schema不做得太深解析稳定性会大幅改善。复盘总结这种关键步骤也不必强迫小模型本地完成可以把这个任务交给更强大的模型异步处理。毕竟经验库的写入频率远低于执行频率调用更强模型产生的成本占比很低却能换回高质量的结构化总结这笔投入非常划算。我在实践中还会给解析环节加重试逻辑第一次解析失败就重新请求一次三次失败再放弃写入并保留原始Trace避免因为偶尔的解析错误而丢失一整条有价值的执行记录。5.3 检索命中率低真正的问题往往在Query侧另一个高频问题是明明存了经验可到用的时候死活搜不到。排查过程中我发现问题多数不出在向量库配置而出在Query的表达方式上。用户原始描述和技能条目的抽象表述之间隔着一条语义鸿沟突破鸿沟的办法是上文中提到的任务预解析。需要确保检索时不只拿原始描述去匹配还把解析出的目标动作、输入类型、输出格式拼成一个结构与目标表达式用这份更高抽象程度的文本做向量抽取。再补充一条接口边界技巧当技能条目有明确Tags时关键词和标签的精确匹配在部分场景中会比向量检索更可靠很多工程问题的答案其实就藏在索引字段设计上。日常维护时我还建议把同义请求及时反哺到触发条件经验库越用越准不完全是模型能力变强了一部分功劳应该记在触发条件字典越补越全上。5.4 经验库不断膨胀查询变慢且噪声变大经验库运行数月后条目数量可能超过预期。技能多了之后检索结果里的相似条目会变多排序阶段开始犹豫把不够相关的经验注入进来反而会干扰Agent判断。这个问题的解法不是简单加一台更大的数据库而是定期做技能合并与下架。我的做法是每月跑一次冲突检测找出那些成功计数都很高、但workflow互相冲突的条目。出现冲突通常意味着触发条件的刻画还不够细原本看似同类的任务实际需要分叉处理这时候就拆成两条更细的技能。再把多条高度相似的workflow合并成一条带有变体的抽象技能变体之间通过输入条件区分。经验库本质上和代码库一样如果不持续重构一定会慢慢腐烂掉守规矩的维护机制比一个惊艳的初始设计更加重要。把WikiSkill这整套思路理清楚之后我发现它背后的道理并不神秘模型的能力虽然静态Agent的能力却可以动态成长前提是给它配上一套能持续积累、整理和运用经验的机制。我在本地模型上试过这条路之后最大的感受是经验库驱动的Agent很可能比单纯换大模型走得更远因为它贴近真实工程里熟能生巧这个朴素规律。如果你准备上手我也不建议一上来就搭全套重型系统先挑一种出现频率较高的业务任务跑两到三个星期回头观察经验命中率和任务成功率的变化再逐步把这个机制铺开到更多场景。经验库跟团队Wiki一样只有持续维护整理它才会产生真正的复利效果。