企业官网建设流程全解析

如果你亲手搭过AI代理（Agent），就一定遇到过这种让人抓狂的场面：昨天调通的流程，今天换个输入又卡在同一类问题上，它仿佛完全没记住上次是怎么解决的。反复试了几轮后你会意识到，模型本身不笨，但它确实“失忆”了。最近圈子里讨论度很高的WikiSkill，就是把目标指向这个痛点——让AI代理具备真正的持久记忆，用轻量模型加外部经验库的方式，在很多落地任务上打出了接近大模型的效果。

我第一次看到“WikiSkill”这个名字时，以为只是个花哨的概念包装。顺着线索自己动手做了一遍，才觉得这套思路确实值得拆开聊一聊。它本质上不是去训练一个更大的模型，而是给Agent配一本随时可查、可增删、可复查的“个人经验手册”，让Agent在下次遇到同类问题时直接查手册行动，而不是重新从头推理一遍。

如果你在做Agent产品、在给本地电脑部署小模型、想把模型能力塞进小程序这类受限环境，或者只是想让手里的小模型在专业任务里发挥更大价值，这篇文章适合你。我会尽量把原理讲明白，同时给出可以直接落地的实现路径，以及我实际踩过的坑。

1. WikiSkill在解决什么问题：AI代理的“失忆症”

1.1 一次Agent任务里最容易被丢掉的不是上下文，而是结论

很多人以为，Agent记不住东西是因为上下文窗口太短。这个说法只对了一部分。上下文窗口短确实会丢信息，但真正的问题比这更隐蔽：模型即使看到了完整的历史记录，它也很难把“上次尝试过什么、为什么失败、最后怎么成功”这一类过程性结论，从流水账里提炼出来。换句话说，你给它看一百轮聊天记录，它读到的是零散动作，而不是一条可以复用的经验。

我自己做过一个自动处理报表的Agent，最开始只是接了模型接口，让它一步步读取、清洗、汇总CSV文件。效果不稳定，同一张表换一种日期格式就容易出错。后来我翻看日志，发现它几乎每次都在同一环节卡壳，上一轮明明已经找到正确解析方案，下一轮又回到最笨的尝试路径。这就是Agent失忆的典型表现：短期上下文里有信息，但长期行为上没有任何积累。

WikiSkill这类方案的核心，是想清楚了一个问题：Agent需要的是“长期可检索的行为经验”，而不是单纯的“更长的聊天记录”。工作台上的东西再多，都不如案头放一本按场景分类好的操作手册有用。

1.2 “经验库”到底存什么？跟知识库有什么区别

这两年很多人做RAG，把文档切片后塞进向量库，让模型回答问题时能查到资料。但WikiSkill说的“经验库”并不是另一堆文档知识库，它们解决的问题完全不同。

知识库回答的是“是什么”，比如“这家公司的报销流程是什么”“这个SDK支持哪些接口”。经验库回答的是“这时候该怎么办”，比如“用户上传的报表日期列经常出现斜杠格式，先统一分隔符再解析更稳”“调用那个导出接口时如果超时，不要立刻重试，先检查服务端会话是否过期”。

知识库里放的是事实，经验库里放的是经过验证的动作。事实可以从文档里扒，但动作往往只有实际执行过任务才总结得出来。

所以WikiSkill里的一条经验，并不只是一段文本，它应该带着触发条件、失败尝试、有效动作、验证标准这些结构化信息。一条完整的经验能够回答：什么情况下可以用，试过哪些路不通，哪条路最终走通了，怎么确认走通。有了这些字段，Agent才敢在真实任务里参考它，而不是把它当作空泛的常识提示。

1.3 为什么“小模型+经验库”能打过大模型

先做一个不严谨但容易理解的类比。一位刚毕业的实习生，手边有一本整理得很好的操作手册；另一位资深专家，知识都在脑子里，但每次都要从原理重新推导。当任务高度重复、场景相对固定时，实习生翻手册的效率完全可以超过专家现场从头想。

小模型就是这样一位实习生。它的参数里没装那么多世界知识，复杂推理也容易翻车。可一旦把高频问题的标准处置逻辑放进外部经验库，小模型要做的就只剩检索和套用，推理负担大大下降。原本需要大模型“思考一下”才能回答的流程，现在小模型“查一下”就够了。

当然，这不是说小模型在什么场景都能逆袭。只有在任务可以被模式化、执行路径可以被沉淀的场景里，这套组合拳才有效。写一首天马行空的诗、做一次开放式的头脑风暴，这些场景经验库帮不上太多忙，它们依赖的还是模型本身的生成和联想能力。看清这个边界，你就知道WikiSkill真正擅长什么。

在实际选型的时候，这会带来一个直接好处：很多内部工具、本地脚本、自动化流程，根本不需要外接一个几百亿参数的大模型API，本地跑一个小参数模型加一本经验库，数据不出内网，速度和成本反而更优。这也是“本地电脑部署的小模型”越来越受关注的原因之一。

2. 一条经验从形成到复用的完整链路

WikiSkill的完整闭环，我自己是在代码里跑通的。它由四个环节组成：任务执行、经验抽取、组织检索、注入决策。前两步负责“把经历变成经验”，后两步负责“让经验参与下一次决策”，缺一不可。

2.1 经验抽取：不是把日志扔进库，而是压缩成决策片段

最早我做记忆功能时走了一个弯路：把Agent每次执行完的完整日志直接塞进向量库，想着以后检索到原文就能参考。结果效果很差，一是日志太长太杂，检索到的片段经常落在无关细节上；二是模型看到的是原始过程，里面根本没有“哪一步起到了关键作用”的提炼，参考意义有限。

后来我照着WikiSkill的思路，每次任务结束后多跑一个抽取步骤，把执行记录压缩成一条结构化经验。这里分享一个我现在在用的字段模板：

trigger: 触发条件（什么场景下这条经验会被用到） goal: 这条经验想达成的目标 context: 关键背景（模型、工具、版本、环境限制） failed_attempts: 试过但无效的做法（避免重复踩坑） successful_actions: 最终有效的动作序列 validation: 怎么确认动作有效 boundary: 不适用的情况

可能有人觉得，任务跑完之后还要多一次“总结”的开销，是不是太慢了。实际上这个步骤可以做得非常轻。执行日志已经在内存里，只需要让Agent按上面的模板回答几个固定问题，一次成本很低，但收益非常大。因为一旦沉淀成这种结构化卡片，后边的检索和注入都会干净很多。

失败的尝试这一栏尤其重要。Agent跟人一样，很多时候不是不知道正确做法，而是被以前失败过但看起来很“合理”的路径反复吸引回去。如果经验库里明确写了“这样做不行”，模型在决策时就能少走一大段弯路。

2.2 组织与检索：没有索引的经验库只是另一个垃圾堆

经验抽取完之后，面临的第二个挑战是：数量多起来之后怎么快速找到最相关的那条。第一批经验我全塞在一个文档里，后来到几百条时，检索质量明显下降。问题不是模型变笨了，而是我根本没有给经验做分类和索引。

WikiSkill名字里的Wiki其实点出了一个好习惯：经验像维基页面一样，需要有标题、标签、关联链接，而不是一堆无法组织的碎片。我后来的做法是给每条经验打上几类标签：领域标签（金融报表/电商订单/运维告警）、任务类型标签（数据清洗/API调用/文件转换）、工具标签（Excel/微信小程序/某个内部接口）、风险级别（涉及删除操作时尤其重要）。

检索链路我也做了分级，不是一上来就上重型向量库。在小规模经验库里，先做标签精确命中，再做关键词词形匹配，都不行才走向量召回。倒排之后取并集，再按标签重合度和更新时间排序。这套多级检索流程在几百条经验的规模下很稳，延迟只有几十毫秒，没有任何外部依赖。

很多教程会让你直接搭向量数据库，但我的体会是：如果你只维护一个私人的、几百条规模的经验库，文件系统加倒排索引已经非常够用，省掉一堆中间件带来的运维负担。等经验库真正涨到几千条、几万条，再迁移到向量检索也不迟。提前迁移只会让一个简单的项目过早复杂化。

2.3 注入与决策：把“先例”放进提示词的正确姿势

经验检索出来之后，怎么让它影响模型行为，这一步同样讲究。直接把查出来的十几条经验全塞进提示词，效果反而会变差。经验太多会让模型无所适从，它不知道该优先听哪条，甚至可能在两个矛盾的经验之间反复横跳。

我的经验是，一次最多带两到四条最相关的先例就够了。先例不是圣旨，它们更像参考判例，Agent需要综合当前任务做判断。为了让模型清楚哪些该学、哪些不该学，我会在提示词里把经验条目和当前任务分隔开，用“参考先例”和“当前任务”两个区块来写。

下面是一个简化版的提示词结构，你可以直接套用到自己的项目里：

system_prompt = f""" 你是一个负责处理{task_type}任务的AI代理。 下面是你过去处理类似问题时沉淀的经验条目，请把它们当作参考先例来阅读。 如果当前任务情况与某条先例高度一致，优先遵循先例中的动作序列。 如果情况明显不同，先按实际情况判断，不要强行照搬。 参考先例： {json.dumps(retrieved_experiences, ensure_ascii=False, indent=2)} 当前任务： {user_request} """

核心要领在于把“先例”放在前面、当前任务放在后面，因为很多模型的注意力对上下文开头和结尾更敏感。当前任务放在“经验参考”之后，模型在生成时能同时记住两者，又不会让经验淹没任务本身。

另外我习惯在提示词里加一句“不要强行照搬”，这是吃过亏才加的。有些情况下，检索回来的经验和当前任务看着相似，实际条件已经变了，模型如果刻舟求剑地照做，反而会把本来是正确的事情办坏。

3. 把“小模型+经验库”落到本地电脑和移动端

前面聊的是机制，这节说点能直接抄作业的内容。我对这套方案最满意的一点是，它的硬件门槛很低，不用A100，不用高配集群，一台普通电脑，甚至一个移动端环境，就能跑起来。结合现在很多人在做的“本地电脑部署的小模型”和“微信小程序运行深度学习模型”，我把落地路径拆成四步。

3.1 端侧模型怎么选：不要贪大，要看任务难度

本地部署小模型，第一个问题就是选多大参数规模。很多人有个执念，觉得模型越大越好，本地能跑开14B就不想用7B。但如果你把经验库做扎实了，模型要负担的核心推理量已经少了一大截，选型思路完全可以反过来：能用小的，就不用大的。

参考配置大概是这样，具体还看机器和量化方式：

我自己在普通笔记本上常用的是7B左右的量化模型，内存占用控制在4到6GB之间，跑起来不会影响日常使用。当你面对的任务比较单一，比如只做信息抽取、意图判断，1B级别的模型加经验库也完全能完成。别小看这些小模型，它们背后靠着几十条高质量经验时，很多固定流程会做得非常稳定。

3.2 检索结构怎么搭：能用文件，就别先上数据库

本地部署的另一个原则是依赖越少越好。我很早以前为了方便，一上来就装了向量数据库，结果索引还要维护服务，项目重启一次要等半天，体验非常差。后来我清理掉重做，把经验库全改成“一个经验一个Markdown文件”的目录结构。

每个文件名本身就包含可检索的关键信息，比如pdf_parse_invoice_date.md、wechat_mini_program_login_expired.md。文件头部带元信息，正文是完整字段。检索的时候，我给目录写了一个轻量索引：先读所有文件的标签字段，按标签过滤候选，再用文件名和正文做关键词匹配。需要跑向量召回时，才临时加载一个几十MB的本地嵌入模型。

这样的好处非常多：经验库可以用Git管理，可以手动打开修改，删除、合并条目非常直观，还能把文件分享给其他开发者。比起锁在数据库里的二进制记录，这种纯文本经验的形态更贴近“知识维基”的原始理念。经验本身应该像维基一样，随时能被人类阅读和编辑，而不是藏在系统内部的一个黑盒。

等到经验库规模真的大到文件检索变慢，再来做迁移也来得及。在此之前，用文件系统来维护经验，是最划算的选择。

3.3 最小实现流程：从任务到经验回写的循环

如果你想快速验证这套方法，我建议用下面这个流程搭一个最小实现。核心是打通四个环节：任务执行、日志抽取、经验入库、经验检索。

我自己写过一个最小可运行的脚本骨架，逻辑大概是这样的：

# 1. 执行任务并记录动作日志 action_log = execute_task(user_request) # 2. 任务结束后，用小型模型抽取结构化经验 experience_card = extract_experience_card( task=user_request, log=action_log, template=EXPERIENCE_TEMPLATE ) # 3. 把新经验写入对应目录下的 markdown 文件 save_experience_to_wiki(experience_card, path="experience_wiki/") # 4. 下次收到新请求时，先从经验目录检索候选 candidates = retrieval_experiences(user_request, top_k=3) # 5. 把候选经验注入提示词，让模型基于先例做决策 final_result = agent_run_with_experiences( request=user_request, experiences=candidates )

这段代码看起来简单，但它只要跑通，就已经具备WikiSkill的最小闭环。可以在某一次任务结束后，人工打开生成的Markdown文件，看看抽取质量如何，必要时手动改两笔，更新回经验库。这个人工参与的过程很重要，它保证了经验库里沉淀的是高质量经验，而不是垃圾循环。

我通常会在先期用一小批任务做校准，观察Agent按新经验执行后是否明显少犯同一类错误。如果连续几次都没有改善，说明问题可能出在抽取质量或检索匹配上，需要回去调那边的逻辑。

3.4 微信小程序这类弱环境怎么塞

热词里有一个很接地气的方向：微信小程序运行深度学习模型。小程序环境资源非常受限，模型包动辄几百MB很容易被卡脖子，但WikiSkill的经验库方案反而给了这个场景一条活路。

拆开来看，小程序里需要做的事可以分成两部分：模型计算和经验检索。模型不用一股脑全放端上，我见过比较有效的做法是端云结合：把高频、小体积的能力放到端上，比如用0.5B到1B的量化模型做意图识别、关键词抽取，输出结果很少，计算量也可控；把真正需要生成或复杂推理的请求带到统一的服务端接口，拿到结果后再回传。

经验库的部署也有分层策略。通用高频经验可以打进小程序包里或者放在一个相对固定的公共接口后面，打开即用；用户个人习性或私有环境相关的经验，比如用户习惯把报表导成什么格式、当前设备上次处理到哪一步，这些则放在本地存储，只有当前设备自己能读取。这样既照顾了隐私，又保证了速度。

需要注意的是，端上小模型的能力边界是真实的，不要指望它在一个几百毫秒内完成高质量长文生成。把端上模型定位成“理解入口”，把经验库定位成“决策支撑”，把云端接口定位成“生成出口”，这个组合既现实的，也很耐用。小程序里能承载的深度学习任务和复杂模型之间天然有差距，经验库正好能补上这部分决策质量的缺口。

另外，模型包在小程序平台上要特别留心压缩。有些平台对主包大小有严格限制，模型作为分包或远程加载方案都可能涉及加载耗时。用WikiSkill的文本经验代替一部分模型“记忆能力”，等于把占用参数空间的知识搬到了外部，模型规格降下来之后，包体压力会小很多。

4. 常见问题与排查实录

从理论走向实操，几乎每个环节都会遇到问题。这里把我被卡住过的一些典型场景整理出来，如果你也照着这套思路落地，可以少走一些弯路。

4.1 检索召回了，但模型根本没用上

最让人困惑的情况是：程序跑通了，候选经验也检索出来了，但Agent的表现没有丝毫变化，感觉经验库白建了一样。

遇到这种问题，先不要怀疑模型笨，先查你注入提示词的内容是否完整。很多人在拼prompt时把检索结果放在一个很靠后的位置，模型生成长文本时关注力已经被前面的占满，后边的经验自然被忽略。把经验条目提到靠近开头的位置，效果往往会立竿见影。

还要检查检索结果与当前任务的相似度是否足够。如果召回的前几条和当前任务重合度很低，模型读了也觉得“这跟手头的事有什么关系”，自然不会参考。这种情况要做的是优化检索环节，而不是调整提示词。

4.2 经验库越加越大，效果反而开始倒退

经验库不是越大越好，这是一条反直觉但真实存在的规律。我做到几百条规模时发现一个问题：旧经验之间开始互相打架，不同时期沉淀的做法在新版本工具下已经失效，但没被清理出去，模型一检索就容易同时命中矛盾条目，行为变得很不稳定。

后来我给每条经验加了三个状态字段：创建时间、最后验证时间、置信度。检索排序时，先看标签相关性，再看置信度，最后看时间。过时且低置信度的经验会直接被排在后面，几乎不会被选入每次注入的两三条候选里。

经验库也需要定期“清理”，就像代码库要删废代码一样。我每隔一段时间会批量过一遍目录，把标题相似的经验合并，把已经失效的做法放进“历史归档”目录，避免它们污染常规检索。经验抽取的时候，多花一点时间写清楚“boundary”字段，能有效减轻后续清理压力。

4.3 小模型理解不了经验里的专业术语

小模型的词汇量和理解能力确实不如大模型，特别是经验条目里写满了领域术语时，它容易读不懂、更不会照做。我踩过的一个典型坑是：经验里写“遇到PDF解析失败先检查文件指纹缓存”，结果模型把“文件指纹”理解成了某种安全校验的专有名词，执行路径完全跑偏。

解法是在经验模板里加一个“plain_trigger”字段，用更直白的话描述触发条件。不需要太学术，甚至多写几个近义词，让模型更容易从当前任务描述匹配到这条经验。比如上面的场景，plain_trigger可以写成“用户在群里上传了一个PDF，解析一直失败，可能之前生成过坏缓存”。这样模型在理解上几乎没有障碍。

另一个提升匹配率的做法是，在检索之前先把当前任务改写成一个标准查询格式，再做匹配。小模型做不了太复杂的语义理解，但你给它一个明确的模板，比如“我先抽取出对象、动作、异常、环境这几个字段，然后拿字段向量去和经验库做匹配，效果比直接把原始任务整段丢进去好不少”。

4.4 本地模型的内存和延迟总是不达标

本地部署最容易翻车的不是功能，而是性能。我之前有段时间追求更大的模型参数，结果普通笔记本跑起来，单轮推理耗时几十秒，内存经常告警。后来我把模型切到量化版，并把经验检索从“逐个文件全文扫”改成“先按标签滤掉八成候选再进正文扫描”，延迟一下子降到可接受范围。

性能优化的核心思路是：把重活留给经验和索引，把轻活留给模型。模型只负责最终判断和生成，匹配候选、优先级排序、条件过滤这些工作尽量放到模型之外的代码里完成。很多人在本地部署上遇到的“卡顿”问题，其实都不是机器不行，而是把太多逻辑堆给了模型。

5. 这种方案适合什么任务，不适合什么任务

如果你读完前面内容，已经想在自己项目里试WikiSkill，那最后这部分可以帮你选准第一块试验田。

我在实践中体会到，它最适合的场景有一种共同特征：任务存在较固定的流程，但具体的输入条件经常在变。比如自动处理用户上传的文件、自动生成标准格式的报表、根据告警信息执行排障动作、回答一个垂直领域的高频FAQ。这些任务里，正确答案高度依赖“过去怎么处理成功过”，刚好是经验库的强项。

反过来，如果你的目标是做一个完全开放的创意助手，或者任务本身没有太多规律可言，经验库反而容易帮倒忙。你硬塞给它的经验，会在生成过程中制造不必要的限制，让输出变得套路化。对这种场景，老老实实把模型能力提升上来更实际。

还有一个很值得期待的扩展方向：经验库的团队共享。个人经验库只能让单个Agent变聪明，但如果一个团队维护同一套经验库，所有Agent都能共享其中的“最佳实践”，那这套体系的价值就会放大很多。可以把经验库想象成团队的内部运维手册，Agent只是比人更擅长按手册执行而已。

我自己的感受是，WikiSkill这种方案真正的价值不是“逆袭大模型”，而是让Agent应用回到了一个更务实的路线上：不要试图让一个不可控的大模型记住所有细节，而是把经验和判断分离，让经验归经验，推理归推理，各司其职。这样系统更可控，维护起来也更踏实。

给想入手的你一个建议：不要一开始就把经验库设计得又大又全，先从一条你手里Agent反复犯错的场景开始，把那条经验卡片写到最好，观察效果。如果你连续在十个具体场景里都成功沉淀了一条有效经验，你对Agent的记忆问题的理解，会比看十篇理论文章都深。这种一边跑、一边攒经验、一边变强的过程，本身就是这套思路最有魅力的部分。