不重训不动权重：让AI Agent通过技能自演进实现终身学习

做了这么久的Agent落地，我越来越觉得"让Agent持续变强"这件事的真正难点不在模型能力，而在系统架构。最近半年我几乎把精力全压在一个方向上：在不重训、不动权重的前提下，让AI Agent拥有可塑性，通过技能自演进实现终身学习。说白了就是同一个模型，同一个权重文件，随着使用越来越懂业务、会越来越多新技能。

这个方向听起来有点反直觉——大家习惯了"能力不够就换大模型、调优就微调"，可真实工程场景里，权重更新这件事又贵又脆，很多时候根本不是最优解。这篇文章我把这条技术路线拆开讲：不改权重的架构长什么样，技能如何自演进，边界在哪里，以及我实操中踩过的坑和沉淀下来的判断。想给正在做Agent长期运营、或者考虑Agent自适应能力的同学一个完整参考。

1. 为什么说"不改权重"才是Agent终身学习的正路

1.1 灾难性遗忘：模型持续训练的终极代价

先聊聊为什么很多人一提到"让Agent学会新东西"，第一反应就是"继续训练模型"。这个思路在单任务场景下没问题，可一旦Agent要面对的是持续变化的业务环境，问题就接踵而至。

最核心的痛点是灾难性遗忘。模型在学习新任务的时候，更新权重往往会对旧知识造成不可控的覆盖。你今天用一批新样本让模型学会处理新版退货规则，明天再拿旧产品线的工单回来测试，可能发现它把三个月前训练进去的老规则忘得一干二净。遗忘不是丢弃了某些词向量那么简单，它会悄悄改变模型的判断倾向，让你根本定位不到是哪次训练引入的问题。

就算不考虑遗忘，权重更新的工程成本也高得吓人。一份高质量训练集从采集、清洗、标注、审核到最终可用，没有两周下不来；训练完成后还要做全量回归评测，因为模型一个细小的行为漂移，可能让上游十几个依赖它的模块全部出问题。更麻烦的是模型版本管理——业务方临时要加一个技能，你总不能为这点事就重开一轮训练，然后让所有下游排队升级。

我一直觉得，Agent做终身学习的第一性原理应该是：把"学习"这件事从"改变模型内部参数"迁移到"改变模型外部可编排的结构"上，权重的每一次变动都应该带来质变，而不是被日常琐碎消耗掉。

1.2 从"学在权重里"到"学在架构里"

如果学习不发生在权重里，那发生在哪里？答案是：发生在Agent的运行架构里。我把这称为从"学在权重里"到"学在架构里"的范式转移。

"学在权重里"的模式是——能力以隐式方式存在于模型的参数分布中。优点是泛化性强，缺点是每次改动都不可观测、不可回滚、不可审计。一个小改动可能影响所有行为域，你无法精准地说"把这个技能删掉"。

"学在架构里"则完全不同。Agent的每个技能都以显式的对象存在：可能是一段提示词模板、一份代码模块、一个工具注册表条目，或者一套多步骤工作流。模型权重只是一个通用的推理引擎，而具体业务能力全部挂在外部结构上。

这样一来，学习新技能就不再需要动权重，只需要在外部结构中新增一个对象。旧技能不会损失，新技能可以单独测试，出问题可以精准回滚。对系统负责人来说，这种可审计、可回滚、可组合的学习方式，在工程上是一种降维打击。

权重内学习 vs 架构内学习

1.3 谁需要这种方案

不是所有场景都需要"不改权重"的终身学习，但这三类场景我明确建议走架构路线。

第一类是客服、售后、运营工单类Agent。这类Agent面对的是持续变化的业务规则，每个月都有新产品、新政策、新话术。我以前做过一个内部工单处理Agent，业务方每周都会提"现在新增一个流程"的需求，如果每次都靠改模型，运维团队根本吃不消。用技能库外置之后，新增一个政策规则就是写一个技能对象的事。

第二类是代码辅助类Agent。新的框架版本、新的内部工具库层出不穷，让Agent学会一个新库的用法，本质就是给它的技能库加一份API使用说明和代码模板。这样它学会新框架的同时，完全不会遗忘三个月前学的旧框架。

第三类是办公自动化、数据分析类的个人助手。这类Agent的使用场景高度个性化，每个人插件的配置都不同，放权重里浪费且不通用，放技能库里则天然适配千人千面的需求。

2. 可塑性架构的拆解：认知控制、技能表达、状态记忆三层分离

可塑性这个词听起来玄乎，落地时我把它拆成三个清晰的层次：认知控制层、技能表达层、状态记忆层。三者职责分离，彼此不纠缠，架构才谈得上"可塑性"。

2.1 认知控制层：LLM只做决策，不做记忆

认知控制层是Agent的大脑，也就是那个固定权重的LLM。它在这套架构里只有一个职责：根据当前任务和可用技能，做出决策。

这里有个非常关键的设计约束——不要让LLM承担它不擅长的记忆工作。模型的上下文窗口再大也是有限的，如果你指望它把所有业务规则都"背"下来，那和不改权重做终身学习的初衷就背道而驰了。正确做法是让LLM在需要时通过检索主动获取知识，用完即弃。它的角色更像一个指挥官，而技能库和记忆库是它的作战地图和粮草辎重。

我用一个"决策不看全文"的原则来约束所有流程：LLM的每次决策输入必须精炼，只包含当前任务的相关技能说明、必要上下文和约束条件，其他一概不喂进去。这样做的好处不仅是省token，更重要的是让决策信噪比保持高位，减少幻觉。

2.2 技能表达层：技能为什么必须落盘成显式对象

技能表达层是整个架构的核心，也是"可塑性"的直接承载者。一个技能在系统里是一个有结构、有版本、有元信息的显式对象，而不是模型参数里一个模糊的分布。这个设计决策，我是在一次事故之后彻底确认的。

当时我们为了让Agent多掌握一个场景，直接改了系统提示词里的一段自然语言描述。结果效果时好时坏，团队里谁也说不清那句话起了多大作用。后来我把所有技能统一改造成结构化对象，每个技能都包含触发条件、执行步骤、绑定工具、注意事项和版本号。从此之后，再没有一个Agent行为是"说不上来为什么"的。每一次行为变化都能追溯到具体的技能版本，这让我意识到，显式化不是可有可无的工程洁癖，而是可塑性架构的地基。

技能对象的最小结构大致长这样：

{ "skill_id": "return-policy-v3", "name": "处理新版退货申请", "version": "3.2", "description": "适用于2024年Q3后创建订单的退货场景", "trigger_condition": "用户输入命中退货关键词，且订单日期晚于2024-07-01", "workflow": [ "校验订单来源渠道", "根据渠道匹配退货政策", "调用库存系统查询退货可用性", "生成退货方案并回到用户" ], "api_bindings": ["order_system.query", "return_system.create"], "constraints": ["仅限中国大陆地区订单", "金额超过2000元需人工审批"], "provenance": { "source_case": "case-99231", "reflection_log": ["v3.1修复了预售订单误判问题"] } }

看到没有，一个技能一旦变成这样，它就是可测试、可回滚、可讨论的。业务方甚至可以直接阅读技能对象，指出哪个步骤不对，这个特性在纯权重方案里是完全做不到的。

2.3 状态记忆层：短期工作区与长期向量库的分工

记忆层和技能层经常被混为一谈，但它们必须分开设计。技能是"怎么做一件事"的可复用方法，记忆是"这件事当前进行到哪了"的状态信息。

我把记忆分成两块：短期工作区负责单个会话内的上下文维持，接住对话历史、临时变量和中间结果，一般用事务性存储即可，做完即清；长期记忆负责跨会话的持久信息，存的是用户偏好、历史案例、项目背景这类需要长期引用的内容，通常用一个向量库加混合检索来组织。

长期记忆和技能库有一个容易混淆的点。技能库里的技能往往也"来自过去"，那它和记忆有什么区别？我的区分标准是：可复用且被抽象过的是技能，具体且与时间绑定的才是记忆。一次成功的解决过程本身是记忆，把它去场景化、抽取出通用步骤之后才升格为技能。这个"升格"动作，正是技能自演进机制的核心环节，下一章细讲。

2.4 一个贯穿始终的示例Agent

为了后面几章讲得具体些，我引入一个贯穿全文的示例：一个处理跨境电商售后工单的Agent，代号就叫"工单Agent"吧。它跑在一个中等规模的电商后端系统里，对接订单系统、物流系统、客服工作台，核心模型是一个固定权重的通用大模型。

这个Agent刚上线时只会处理三类工单：退款、改地址、查物流。业务变化很快，它需要学会处理新品类的质量退款、多件合并退货、跨境税费争议等新场景。如果每新增一类工单就要动一次模型权重，这件事就直接做死了。用可塑性架构来解，我们要做的其实是三件事：持续沉淀新技能、持续优化旧技能、让技能之间可以组合出新玩法。

3. 技能自演进的内循环：注册、检索、执行、复盘、沉淀

"自演进"是标题里最有分量的词，也是最容易被包装成玄学的部分。我把它落地成一条清晰的内循环：注册、检索、执行、复盘、沉淀。这五个环节每跑完一圈，Agent的技能体系就进化一次。

3.1 第一步：把一次成功执行固化为"技能草案"

技能从哪来？很多人以为是靠人工预设，那就失去了自演进的意义。我的答案是：技能的第一版，来自Agent自己的一次成功执行。

举例，工单Agent某天遇到一个全新的工单——买家申请多件合并退货，涉及三个子订单、两个不同仓库。Agent翻了规则文档和类似案例，一步一步完成了退货审批，用户没有投诉，业务侧也没有驳回。这次执行的全过程被系统完整记录下来。

演进系统的任务就是判断"这是一次值得固化的成功"。判定条件有几个：执行链路完整无中断、关键节点有明确的正反馈信号、涉及的规则可以被抽象成一般性步骤。满足后，系统自动生成一份"技能草案"，它的雏形就是第2.2节那种结构，只不过provenance字段里记录了这次原始案例。

这里有个容易被忽视的细节：草案不等于正式技能。草案必须经过一轮"去场景化"处理，把具体订单号、具体金额、具体用户ID全部替换成变量，把"这个用户的三单合并"提炼成"同一收件人的多子订单合并"。不做这步抽象，技能库存进的只是日志，不是能力。

3.2 第二步：检索与复用，让技能库越用越准

技能草案进入技能库后，接下来要解决的是"下次遇到类似任务时，能不能想到用这个技能"。这一步决定整个自演进系统是正向循环还是死水一潭。

我的做法是给每个技能都做两层索引。第一层是语义索引，将技能描述和触发条件embedding化，任务来临时做向量相似度检索；第二层是规则索引，用显式的关键词、正则、业务标签做硬匹配。两层结果做完融合排序再交给LLM做最终选择。之所以保留规则索引，是因为很多业务场景的触发条件非常精确，比如"订单日期早于某天"，这类边界靠向量检索会糊掉，必须用规则钉死。

复用阶段还有一个"顺手"设计：每次成功复用技能完成任务后，系统会把这次执行的反馈增量写回技能对象的provenance字段。同一个技能被成功复用的次数越多，它在检索排序里的权重就越高。这套机制让技能库呈现出一种"自然选择"的特性——用得多的技能越来越靠前，长期用不上的技能逐渐沉底。

3.3 第三步：复盘机制——从"做对了"到"为什么对"

如果自演进只停留在"记住成功做法"，那它只能复制过去，无法应对变化。真正的进化发生在复盘的环节。

我给工单Agent设计了一个反思步骤：每个关键任务执行完成后，系统会启动一个独立的"复盘LLM调用"，该调用看不到原任务的具体对话，只输入执行轨迹、业务反馈、当前技能定义三样东西，输出一份反思日志。日志要回答三个问题：这次执行暴露了技能的哪个缺陷；哪些步骤可以更高效；规则是否在边界情形下失效。

举个例子，技能"跨境税费争议处理"反复被使用，复盘模块发现凡是涉及"关税起征点调整后"的工单，成功率明显下降。它进一步分析，发现问题出在技能里的阈值参数是硬编码的，没随政策变更更新。于是它自动生成一条技能更新建议，附带修改后的参数。人工审核通过后，技能演进到v1.1。这一步说完你们就明白了：自演进不是全自动，而是自动发现、半自动确认，这在工程上是负责任的做法。

3.4 第四步：评估与淘汰，技能库的熵管理

技能库如果不加节制的膨胀，很快就会变成维护噩梦。第3.1节那种"成功即沉淀"的机制如果失去控制，系统里会堆满大量互相覆盖、过时甚至互相冲突的技能。

所以第四步是残酷且必要的：评估与淘汰。我给每个技能设置了四个指标：使用频率、执行成功率、业务反馈分、版本迭代活跃度。每周跑一次离线分析，把连续一段时间"零使用且低相关"的技能标记为休眠状态，休眠超过一段时间后自动归档。对于评估指标持续下滑的技能，系统会优先考虑更新而不是删除，只有更新后仍无法改善的才进入淘汰候选名单。

这个机制很像人的记忆整理：有些技能不用则废，有些技能越用越新。一个能自演进的Agent，技能库必须是在动态平衡中的，有进有出，而不是只进不出。

4. 支撑自演进的关键工程细节

前面讲的是架构逻辑，但真正把自演进系统跑起来，还有很多工程细节决定成败。这一章挑四个我印象最深的展开。

4.1 技能库的数据结构与索引设计

技能库物理上建议用支持Schema约束的文档数据库加向量索引的组合来存储。文档数据库存技能对象的完整JSON，保证字段结构的强约束；向量索引负责语义检索。有些人直接用向量库存一切，我认为不推荐，因为向量库对结构化字段的过滤能力偏弱，而技能检索经常需要"规则条件+语义相似度"联合过滤，双存储才能两全。

索引设计上，我给每条技能维护三组索引：技能ID主键、keywords标签列表用于精确匹配、embedding向量用于语义匹配。检索时先通过规则索引粗筛出候选集，再做向量精排，最后把TopK技能描述放进LLM上下文让Agent自行选定。这个流程可以把检索精度提升一个量级，比单纯向量检索稳定得多。

4.2 如何让Agent判断"什么时候该更新技能"

自演进系统最微妙的问题就是更新时机：太激进会让技能库振荡，太保守会让Agent面对变化无动于衷。我把触发信号分成了两类：显式信号和隐式信号。

显式信号来自业务侧，比如政策文档更新、产品规则变更、新增对接接口，这些事一旦发生，相关技能必须被标记为"待复核"。我的做法是给技能挂维护策略，技能对象声明里写明它依赖哪些外部规则源，当规则源版本变化时自动触发技能体检。

隐式信号来自执行反馈，最常见的就是同一类型任务连续失败、用户重复追问、业务方驳回率上升。系统会给这些信号加权评分，分数超过阈值才发起技能更新流程，避免因为单次偶发失败就大动干戈。这个阈值要根据每个技能的历史数据动态调整，技能越成熟，触发标准越严格。

4.3 安全护栏：技能库的权限与隔离

自演进能力越强，安全风险越值得重视。技能对象从草案到正式版，必须经过明确的审批链。我在系统里设置了三级权限：自动生成的草案任何人可直接创建；但草案转正必须有业务管理员审核；正式技能的版本更新必须走变更记录审批。所有技能对LLM的暴露也做了最小化设计——Agent只能检索到被授权可见域的技能。

还有一个容易被忽略的隔离点：多租户隔离。我做的某个系统同时服务几个不同业务线，技能库如果混在一起，A业务线的高频技能会污染B业务线的检索结果。解决方案是在所有技能和知识对象上强制标注scope字段，检索时把scope作为硬过滤条件。没有这个隔离，自演进系统规模一大就会乱套。

4.4 评测集先行：没有测试集就不存在进化

这是我在项目里摔过最大的跟头，也最想强调的工程原则。一开始我们兴致勃勃地做技能自演进，结果每次技能更新都不知道好还是坏，凭感觉走，最后变成盲人摸象。后来痛定思痛，补了一个"评测集先行"的规范：每进入一个新业务场景，第一件事不是设计技能，而是造一批覆盖典型场景和边界情况的离线评测用例。

评测集由三部分组成：正常流程用例，验证技能的主路径；边界用例，验证数量、时间、金额等阈值边缘；异常用例，验证规则覆盖不到的场景下Agent是否合理拒绝或求援。每次技能库有任何变更，系统自动把评测集跑一遍，产出一份通过率对比报告，只有不比上一版差的更新才允许合入。

有了这套机制，自演进才真正长出"地心引力"——每个技能版本的进化方向都朝向评测通过率提升，而不是只朝向某个孤立的成功案例。

5. 不改权重的边界：哪些能力确实长不出来

必须承认，不改权重不是万能药。架构外置能解决知识、流程、工具组合的问题，可有些能力的上限是被模型权重先天锁死的。讲清楚边界，比吹捧方向有意义得多。

5.1 推理能力的窗口局限

不改权重最明显的天花板是单步推理的深度和上下文长度。模型能处理的问题复杂度，受限于它在一次推理内能够规划和关联的上下文窗口。虽然我们可以通过"思维链+外部记忆"把长任务切成多段，但切段本身会增加出错概率，且模型在多步规划之间的连贯性会受影响。

举个例子，工单Agent需要处理一个极度复杂的case，跨市场、跨结算周期、涉及退款+税费+物流赔偿多条链路的联动。就算技能库再完善，LLM在上下文窗口内同时协调的变量数量也是有限的。这种情况下，只能靠人工程序编排把任务拆到更细的粒度，或者接受更保守的输出。我常说，外置架构决定Agent的视野半径，模型权重决定它的认知马力，两者不是一个维度的事。

5.2 技能库膨胀的熵增问题

即使有淘汰机制，技能库的膨胀速度还是超出我的预期。业务每多一个场景，技能库可能长出三五个变体；每过半年，总有一批历史技能在角落积灰却因为历史数据"看起来有用"而难以删除。

这个问题单靠定期清理很难根治，更有效的方法是在注册环节提高标准。我把"技能通用性"作为草案转正的核心指标：一份草案如果只适用于单一具体场景，几乎不抽象不出共性，就拒绝入库，宁可让Agent现场推理，也不允许它沉淀成"伪技能"。质量永远比数量重要，一个通用性强、覆盖率高的技能库，远胜过一百个精确但相互重叠的技能碎片。

5.3 与权重更新的共存：混合学习策略

我并不是说权重更新应该被彻底抛弃。在实际运营中，最优策略往往是混合的：日常技能演进靠外部架构，让Agent能跟上业务的小步快跑；阶段性的能力跃迁靠谨慎的权重更新，让模型本身的通用推理能力上一个台阶。

什么时候触发权重更新比较合理？我的判断标准是：当评测集里相当大比例的失败案例，根因是"模型理解不了技能描述""多步规划能力不足"，而不是"缺少某个具体技能"时，说明外部结构已经无法兜住模型的推理短板，这时候才值得启动一次权重更新。这个思路反过来也成立——好的可塑性架构能让模型权重更新的频率大幅降低，为团队节省大量成本。

6. 落地过程中的经验与体感

文章最后，分享一些从真实项目里磨出来的体感，都是常规技术文档里不会写的部分。

6.1 最容易翻车的几个细节

第一个要注意的是不要让技能库变成黑箱。技能对象必须保持人能读懂的状态，哪怕系统能自动生成技能，也要确保它生成的是结构化、有注释、业务方看得懂的文档。如果技能库变成了只有机器能懂的黑箱，出了问题就没人敢动，自演进就翻车了。

第二个坑是"复盘调用的上下文污染"。最开始我让复盘模块直接复用任务执行时的完整对话历史，结果反思结果总带着原任务的情绪倾向，质量很差。后来改成只输出去标识化的执行轨迹，效果立竿见影。复盘过程必须与被复盘的对象保持距离，这也是我强调"独立复盘调用"的原因。

第三个是技能优先级冲突。当两个技能同时命中一个任务时，Agent常常出岔子。解决办法是为每个技能增加priority字段，同时在技能描述里显式声明"本技能不适用于XXX情况"，用互斥声明减少检索和决策阶段的冲突。

6.2 从零到一：搭一个最小可用的可塑性Agent

如果你想快速验证这个方向，不需要一上来就把全部机制做满。我建议按这个最小闭环起步：

第一步，先做一个简单的技能库，用结构化对象存10到20个手工编写的技能，配一个向量检索接口。第二步，在Agent执行链路里加入"任务到技能"的检索路由：每次来任务先查技能库，把命中的技能描述注入提示词。第三步，加日志，完整记录每次任务的技能命中情况和结果反馈。第四步，加一个最简单的复盘模板，定时把低频反馈转化为技能更新建议。这四步做完，你就已经拥有了一个"能沉淀、能复用、能改进"的可塑性Agent雏形，后续再逐步补权限、补评测集、补淘汰机制。

6.3 个人实测下来的真切感受

最后说点体感。用这套架构跑了一段时间之后，最明显的变化是，Agent的日常行为不再需要跟着每次需求变更反复调整。业务新加一个流程，运维只需做一次技能录入，Agent第二天就能稳定处理该类工单，且旧业务完全不受影响。产研团队不再被"为什么模型上周还正常这周就疯了"这种问题反复折磨，因为每次变更都看得见、查得着、能回滚。

当然，这套方案不是没有代价，它把一部分模型侧的工作量转移到了架构和工程侧，技能库设计、评测集维护、复盘链路建设都需要持续投入。但以我个人的经验来说，当Agent承担的任务数量级超过一百个场景之后，这笔投入的回报是指数级的。可塑性不是一种花哨的特性，而是Agent从玩具走向生产力工具必须跨过的那道门槛。