WikiSkill这个方向最近讨论热度很高。它要解决的事情可以用一句话概括Skill管“会做”Wiki管“记得”。以前的Agent Skill本质是把一段成熟做法固化下来让模型拿到任务后不用重新推理整套流程但Skill很少记录执行过程中真正有用的经验比如哪个参数在哪种输入下会不稳、哪个报错其实可以忽略、哪个输出格式调整一下下游就能直接用。WikiSkill就是在Skill之上加一层经验库把真实任务里沉淀出来的结论写成Wiki词条下次遇到同类任务时先检索、再执行。如果你正在做LLM Agent有自己的Skill库或者用过带技能能力的编码工具这个思路值得关注。它的价值在于不要求换底层模型也不要求重写Skill只需要在Skill和任务执行之间插一层Wiki经验检索。表面上是加存储实际上是改变Skill的使用方式。下面按实际落地顺序拆开讲不试图复刻论文重点是Wiki层该存什么、怎么组织、怎么注入执行流程、怎么验证效果以及最常见的几个坑。1. 先搞清楚WikiSkill在解决什么问题1.1 Skill的现状能用但不太会积累理解WikiSkill之前要先理解Skill本身的限制。Skill在LLM Agent里通常表现为一段提示词模板、一套脚本或者一组标准化流程说明。它的作用是让模型在特定任务里不用从零开始推理。比如一个处理CSV清洗的Skill会写明“先读表头再处理空值最后统一编码输出”。这是好事因为稳定、可复用。问题在于Skill是静态的。写完就固定了执行过程中产生的经验不会自动回流到Skill里。同一个任务第一次跑得很顺不代表第二次顺。第二次踩了坑修改了输入格式但Skill本身没有记录“原来这个字段还有这种变体”。下次遇到同样的情况模型还要重新试一遍。我遇到过很典型的一个例子用Skill处理带BOM的CSV文件。Skill里写了标准流程第一次跑没问题第二次遇到带BOM的表头模型折腾了三轮才发现是编码问题。但这次踩坑的结论没有留下来。第三次遇到同类文件又重复排查了一遍。这个问题不是模型不够强而是经验没有沉淀。1.2 Wiki层补上的关键能力WikiSkill的核心动作是在Skill之外增加一个Wiki层。这个Wiki不是百科也不是泛泛的知识库而是“经验型知识库”。它保存的是某类任务在执行过程中验证过的做法、踩过的坑、确认有效的参数组合、不适用的情况。这样Skill保持相对稳定Wiki不断更新两者分离。运行逻辑变成这样任务到达识别该用哪个Skill。执行前先去Wiki目录里检索与该Skill相关的经验词条。把命中的词条注入到模型的提示词上下文中。模型带着“历史经验”去执行任务而不是从零开始处理。任务执行完把新的有效结论再写入Wiki供下一次使用。Skill负责“怎么按标准流程做”Wiki负责“上一次实际遇到的情况和结论”。这就是它和普通提示词工程最大的区别Skill是存量知识Wiki是增量经验。1.3 和RAG、记忆模块的区别很多人会把WikiSkill和RAG混淆。从形式上看都是“检索外部内容再注入上下文”。但两者解决的问题不同。RAG通常检索的是外部文档、手册、知识库内容是相对稳定的事实性知识。WikiSkill检索的是Agent自己在执行过程中产生的操作经验带有很强的“怎么处理、边界在哪、失败后怎么修”的属性。记忆模块则偏向保存对话历史让模型记得用户说过什么。Wiki更关注“这一类任务怎么做更稳”不是某一次聊天提到了什么。三者可以共存。RAG负责查资料记忆模块负责维持上下文连贯Wiki负责沉淀操作经验。WikiSkill不是要替代它们而是补上“经验没有回流”这个缺口。2. Wiki层该存什么不该存什么2.1 值得写入Wiki的四类内容第一类成功案例。不是记录“这次成功了”就完事而是要写清楚任务背景、输入样例、处理步骤、输出样式、用到的关键参数。让后续模型知道“按这个套路走是通的”。第二类失败记录。这比成功案例更重要。报错信息是什么、为什么失败、最后是通过什么方法解决的。模型看到这类词条能避开真实的坑。第三类边界条件。哪种输入格式不支持数据量到多少会超时哪类场景必须降级处理。很多“效果不稳定”的问题其实是因为词条里没写边界条件模型在小数据量上跑通后遇到大数据量依然按同一套参数处理然后就出问题。第四类环境依赖。依赖版本变了、底层模型换了、某个API接口行为不一致。这些信息短期内可能用不上但一旦踩中能省很多排查时间。2.2 不要写入Wiki的内容原始日志和完整对话不要直接进Wiki。噪音太大检索时容易把模型带偏。我见过有团队把一次任务的完整日志贴进Wiki结果模型看了一千多字日志反而忽略了真正的结论。临时性内容不要写。一次性文件路径、临时生成的密钥、即将失效的接口地址这些内容过期后就是垃圾信息。无法验证的猜测不要写。模型自己推断出来的“可能原因”如果没有通过实际验证不要直接入Wiki。经验库一旦混入不准确结论后续任务会被带进更深的坑。敏感信息和个人信息必须隔离。这是底线不用多讲。2.3 存储粒度和推荐格式一个词条对应一个“可复用的经验点”不是一段时间的流水账。我建议每个词条包含这些字段场景标签方便检索比如 csv 编码、batch 任务、长文本截断。触发条件什么情况下这条经验适用。结论一句话说清楚应该怎么做。步骤可执行的步骤编号排列。适用范围哪些环境下验证过。验证状态已验证、待验证、已失效。下面是一个示例词条实际内容可以按你的领域改--- tags: [csv, encoding, bom] status: verified --- # CSV带BOM时如何判断编码 触发条件打开CSV后第一行表头出现 \ufeff 前缀 结论读取时使用 utf-8-sig不要直接使用 utf-8 步骤 1. 先读取文件前三个字节判断是否存在BOM。 2. 如果存在读取时指定编码为 utf-8-sig。 3. 输出前再统一编码避免中间格式混乱。 适用范围Python pandas / csv 模块均可Node.js 下需额外处理 stream 编码。 验证状态已验证两次第二次在Windows环境通过。这种结构的好处是模型检索到词条后能快速定位“触发条件”是否匹配再看“结论”和“步骤”执行。而不是从大段描述里自己提炼。2.4 该存多少合适不需要一上来就攒几百条。新项目建议3到5个词条起步先把“写入、检索、注入、验证”这条链路跑通再根据实际踩坑情况逐步增加。词条宁少勿多因为每条都会占用上下文空间低质量词条越多干扰越大。3. 用最小结构跑通“Skill Wiki”闭环3.1 环境与前置条件我不建议为了做这件事专门引入一个重型框架。你可以用任何一个已经能跑的Agent流程在外部加一个Wiki目录再写一个检索函数。下面给的是通用示例不绑定具体框架。需要准备的东西很基础一个能调用LLM的Agent流程无论是API还是本地模型。一个存放Skill的目录里面是Markdown或标准化文本格式的技能说明。一个存放Wiki词条的目录目录名和Skill名称保持一致方便检索。一个检索器最低要求是关键词匹配后续可以升级成向量检索。3.2 目录结构示例project/ ├── skills/ │ ├── csv-clean/ │ │ └── SKILL.md │ └── web-summary/ │ └── SKILL.md └── wiki/ ├── csv-clean/ │ ├── BOM编码处理.md │ └── 空值策略边界.md └── web-summary/ ├── 长网页截断方案.md └── 抓取失败时的重试策略.mdWiki目录和Skill目录一一对应这是最简单也最不容易出错的组织方式。等词条数量足够大再考虑按领域分标签初期不需要设计得很复杂。3.3 最小闭环流程整个闭环可以分为八个环节任务到达识别任务类型并匹配Skill。进入Skill流程后先读取任务的关键词、场景标签。在对应的Wiki目录下检索词条。把命中词条注入到系统或用户的提示词末尾。模型执行任务。执行结束后判断本次是否有新经验值得沉淀。如果有生成新词条写入对应Wiki目录。下次同类任务到达时新词条参与检索。对应的伪代码很简单def run_task(task, skill_id): skill load_skill(skill_id) wiki_entries retrieve_wiki(skill_id, task.text) prompt build_prompt(skill.template, wiki_entries, task.text) result llm_call(prompt) maybe_write_wiki(skill_id, task, result) return result核心就两步执行前取Wiki执行后写Wiki。3.4 检索策略怎么选最低成本的做法是关键词匹配。先用Skill目录过滤掉无关词条再在词条标题和标签里匹配任务关键词。这样做的好处是不需要额外引入嵌入模型也没有延迟成本。缺点是召回率有限同义词和概念相近的内容可能搜不到。如果词条数量超过一百条或者检索不到可靠词条再考虑升级成向量检索。嵌入模型会把词条内容和任务文本都转成向量按相似度返回。常用工具可以用轻量级的向量数据库也可以直接用数组和相似度计算函数。低配置环境下不推荐一开始就上向量检索。检索结果注入的位置也很重要。我建议放在Skill模板之后、用户任务之前。这样模型先看到“应该怎么执行”再看到“上一次执行时的经验”然后才是具体任务。如果放到用户任务之后容易被任务本身的指令稀释。3.5 写入策略与自动写入阈值最安全的是半自动模型生成建议词条人确认后再写入。等跑了一段时间确认链路稳定再改成规则化的自动写入。自动写入不能无条件执行。建议设一个最低阈值同一个问题至少成功两次才允许写成经验词条。只跑一次就写入很可能是偶然现象不值得固化。也要给“不值得写入”留出口。如果本次任务只是正常执行了一遍没有任何异常、参数也全部是默认值那就不要写入。不是每次执行都必须产生新词条那样只会制造噪音。3.6 示例配置下面是一个通用配置示例字段名可以按你的流程调整wiki: dir: ./wiki retriever: keyword # keyword 或 vector top_k: 3 max_context_chars: 2000 min_success_runs: 2 auto_write: false # false 为半自动 archive_threshold: 100 # 超过100条后提示归档这个配置表达的是默认从Wiki目录里检索3条词条单次最多注入2000字符同一个经验至少成功两次才考虑写入初始阶段不自动写。实际参数以你的环境和任务复杂度为准。4. 怎么验证“提升效果”不是错觉4.1 先准备一组固定测试集验证WikiSkill效果时最忌讳用已经写过Wiki词条的任务来测。因为词条里可能已经包含了答案测试结果自然好看说明不了泛化能力。建议准备两组任务一组是已经掌握的任务用来验证“经验是否被正确注入并沿用”。另一组是同类型但没见过的任务用来验证“经验是否帮助模型应付新情况”。两组任务数量都不要太少至少各10个。太少的话一次随机波动就会掩盖真实效果。4.2 开Wiki与关Wiki做对照最直接的验证方式是对比测试同一组测试任务在开启Wiki与关闭Wiki的情况下各跑一轮。需要记录的指标包括首次成功率第一次执行不报错、不需要人工修正的比例。平均交互轮数模型完成同一任务时需要的多轮对话或工具调用次数。失败重试率遇到报错后模型是否能根据Wiki经验自我修正。输出一致性同一任务跑三次输出结构是否稳定。上下文占用注入Wiki词条后增加的token数量。下面是一个示例表格里面的数值只是示意真实效果要以你的测试任务为准指标关闭Wiki开启Wiki怎么判断首次成功率50%左右85%左右提升明显说明经验注入有效平均交互轮数4轮2轮轮数下降说明模型更少试探失败重试率60%20%重试率低说明避开已知坑输出一致性不稳定基本一致结构稳定词条边界清晰上下文增量0约1500字符增量大于2000字符就要压缩关注重点不是某一次的绝对分数而是趋势开启Wiki后首次成功率是否更高交互轮数是否更少失败重试是否明显下降。4.3 交叉任务和长周期验证单任务测完还不够。交叉任务是指用A任务积累的词条去测试相近但不同的B任务。如果B任务效果也能提升说明Wiki经验没有过拟合到具体任务上。如果只对A有效对B无效说明词条写得太死缺少泛化性。长周期验证更关键。Wiki的特点是会持续增厚今天只试了10条词条三个月后可能变成200条。这时要定期检查词条变多之后检索准确率是上升还是下降。如果发现命中结果越来越不准或者上下文长期超限说明词条质量和检索策略都需要重新整理。我一般建议至少观察一周。每天记录同一组任务的表现。累计的数据比单次测试靠谱得多。4.4 需要记录哪些信息记录不需要很复杂但要固定。建议在每次测试后保存这几项任务编号和类型。是否开启Wiki。命中了哪些词条。执行结果成功、失败、超时、需要人工介入。模型在什么步骤出现偏离。上下文总共消耗了多少token。这些信息既能用于验证效果也是后续排查问题的依据。5. 参数、策略与资源占用怎么取舍5.1 关键参数怎么定WikiSkill最需要调的不是模型参数而是检索和注入相关的参数。下面这几个字段在实际使用中优先级最高。top_k也就是检索返回的词条数量。初始建议设3。太少可能漏掉关键经验太多上下文容易被低相关词条挤占。词条质量差的时候top_k设为5或10不会有本质帮助反而让模型在几条互不相关的经验里纠结。max_context_chars控制注入文档的总长度。这个必须设上限。长文本任务和短文本任务对这个字段的敏感度差异很大。如果单条经验最多500字top_k为3那么2000字符的上限够用。如果词条写得又长又杂上限会被一下打满。min_success_runs控制自动写入的严格程度。设1写入快但噪音大设2更可靠但需要更多重复任务触发。我建议从2开始。等词条质量稳定后可以按任务类型分别调整。archive_threshold词条数量逼近这个阈值时应该做一次归档或清理。它在配置里是一个软提醒不是自动清理开关。超过阈值时去检查重复、过期和矛盾词条能避免Wiki逐渐变成垃圾堆。5.2 上下文窗口与注入量的平衡注入Wiki内容本质上是拿上下文换经验。如果模型上下文只有8000 token注入2000 token的Wiki内容占比已经达到四分之一。这时必须考虑压缩策略。压缩方向有三个减少top_k从3降到2保证只注入最相关经验。精简词条每条控制在300到500字以内丢弃“背景”和“过程”只保留“结论”和“步骤”。做摘要把多条相关词条合并成一条摘要词条再注入。我不建议一开始就上向量检索来解决上下文问题。检索方式只影响命中质量不代表注入更多内容。上下文超限的本质是词条太多或太长该做的是压缩不是换检索方式。5.3 不同场景的参数配置建议下面这个表只作为参考起点不是标准答案。场景top_kmax_context_charsauto_write检索方式学习Demo21000false关键词个人日常任务32000false关键词小团队协作43000true关键词或向量高精度生产任务32000false向量检索高精度生产任务反而不建议把top_k设得太大。注入越少模型越能专注执行经验质量高的话两三条就够。5.4 低资源环境的替代方案如果机器配置不高或者没有多余算力跑嵌入模型WikiSkill依然可以做。最低配置是一个普通文件夹加一个文本搜索命令。词条用Markdown存检索时按文件名称和关键词匹配。很多轻量级场景根本不需要向量数据库。词条数量在几十条级别时关键词检索的准确率完全够用。还可以用SQLite或JSON文件做存储检索用简单字符串匹配。这样做的优点是部署简单、备份方便、没有额外依赖。缺点是当词条数量继续增长到几百条以上检索质量就很难靠规则维持那时候再考虑向量检索也不迟。5.5 什么时候应该归档或重置Wiki不是只增不删的数据集需要定期维护。出现下面几种情况就应该做归档或重置词条数量超过200条但检索命中率下降每次返回的结果都不太相关。同一个问题出现了10条以上互相矛盾的经验。底层模型或工具链升级后旧经验大面积不适用。多人协作时没有统一规范出现大量同名不同内容的词条。归档不等于删除。把旧词条移到wiki-archive/目录保留历史记录但不再参与检索。这样既不影响当前效果也方便以后回溯。6. 常见问题与排查链路6.1 经验没有生效先查什么最可能的原因是模型根本都没看到Wiki内容。排查第一步看Skill实际执行时拼出来的提示词确认里面到底有没有Wiki词条。很多“没生效”其实是检索条件没匹配上返回结果为空或者注入代码写错把Wiki内容丢弃了。排查第二步检查检索关键词和词条标题、标签是否对得上。比如词条标题是“BOM编码处理”任务关键词是“CSV 乱码”如果只用完全匹配这个词条就搜不到。解决方案是给词条补充更多触发标签。排查第三步检查词条内容是否可操作。如果词条只是记录了“遇到了乱码”但没说“用什么编码解决”模型拿到也没用。词条必须是“触发条件 结论 步骤”的结构。排查第四步看注入顺序。Wiki内容如果放在很后面可能被其他系统提示词覆盖。建议放在用户任务之前作为中间优先级内容。6.2 上下文被Wiki内容撑爆怎么办现象是任务本身很短但一加上Wiki内容请求就超限或者执行速度明显变慢。这时候不要急着加大模型上下文先看这句话对不对注入的Wiki内容是“经验”不是“文档”。经验词条应该短、准、直接不需要保留完整执行过程。把长词条拆成多个小词条每条只讲一个结论是更合理的做法。如果单个词条已经精简过还是超限就把top_k调小从5调到3或者从3调到2。宁可少注入一条也不要让模型在一堆内容里分心。6.3 Wiki越攒越乱怎么处理词条数量增加后最常见的两个问题一是同名词条越来越多二是同类经验散布在多个文件里。解决办法是在写入阶段就做好约束每个Skill目录下一个主题只保留一个active词条。同主题的新经验先更新旧词条而不是新建一个词条。如果旧词条和新经验冲突用status字段标记为superseded。定期跑一次重复检查把相似词条合并。人这一环很关键。自动写入可以降低整理成本但完全依赖自动系统词条质量大概率会下滑。6.4 单条Skill跑得好交叉场景却变差这说明Wiki经验可能过拟合了。过拟合指的是词条里的经验只适用于写这条经验时遇到的那一类具体输入换一个相近但不完全相同的输入模型反而被固定思路束缚住。要降低过拟合写作时就得多写“触发条件”和“适用范围”。比如“数据量小于10万行时用这个方案”而不是“用这个方案”。模型看到前提条件遇到超出范围的输入时会自己做判断而不是照搬。6.5 新旧经验冲突时听谁的经验冲突在长期使用中几乎必然出现。模型升级、依赖版本变化、输入格式变化都可能导致旧经验不再成立。处理原则是显式的、新验证过的经验优先级更高。在词条里用status区分verified已验证有效。superseded已被新经验替代。archived不再参与日常检索。检索时默认只返回verified状态。这样新经验不会被旧内容淹没也为以后回溯留下记录。7. 落地路线与最后几条经验7.1 新手可以先这样起步如果你是第一次接触WikiSkill我不建议一开始就设计一套复杂的存储和检索系统。更稳妥的路线是选一个你自己最常用的Skill。用一个文件夹当Wiki目录手动写3到5条经验词条。在现有Agent流程里加一段检索逻辑关键词匹配就行。跑一周记录单任务成功率和方法轮数的变化。确认链路稳定后再增加第二个Skill并考虑半自动写入。这套路线的重点是先跑通而不是一开始就追求自动化。手动写词条虽然费时间但能让你明确感受“什么内容才值得沉淀”。7.2 团队落地时多考虑协作规范如果多人同时往同一个Wiki写词条规范就很重要。需要提前定好的内容包括Skill目录和Wiki目录怎么对应、词条文件怎么命名、谁来审核自动写入的内容、词条状态由谁更新。没有规范时Wiki会迅速变成一团乱麻。一个可行的做法是词条写入走PR式审核合并前必须补充“触发条件”和“适用范围”。审核不是卡进度而是保证后续检索质量。7.3 最后几条经验把方法落地过程中我自己最深的感受是这几条不要一开始就自动写入。模型自动生成的词条经常缺少边界条件真出了问题反而难排查。不要把Wiki做成日志备份。经验词条要提炼过不是把执行记录复制一份。不要一次塞太多词条。top_k在3以内通常够用重点看命中词条质量而不是数量。遇到“好像比以前更差了”的情况先检查旧经验是不是不再适用。模型或工具升级后旧词条可能是负资产及时归档比继续搜出来注入更有价值。WikiSkill真正值得做的地方不是“多了一个Wiki目录”而是让Skill从静态脚本变成带记忆的动态流程。Skill解决的是能力的标准化Wiki解决的是知识的时间积累。两者配在一起Agent才开始有一点“越用越顺”的迹象。如果你的Skill库目前只有脚本没有经验回流建议先从3个词条开始补起来。