“模型权重冻结，能力还在涨”——听起来像悖论，但确实是当下 AI Agent 落地时最让我着迷的一个方向。大多数团队做 Agent 的第一反应是微调模型、改权重、重新训练，可一旦进入生产环境，模型迭代成本高、周期长，还容易灾难性遗忘。我这两年踩过不少坑之后逐渐确认了一条更务实的路线：让 Agent 在不更新任何参数的前提下，通过外部记忆、工具系统、代码策略和编排机制的协同，实现行为层面的“终身学习”。这个方向通常被叫做可塑性架构，也叫技能自演进。它解决的核心问题特别实在：一个 Agent 怎么在一次又一次任务中越用越顺手，越用越聪明，而模型本身完全不动。这篇文章就围绕“不改权重的终身学习”这条主线展开，适合正在做 Agent 应用的开发者、算法工程师，也适合那些被模型迭代成本压得喘不过气的技术负责人。我会从范式转换讲到架构设计，从技能演进机制讲到可落地的实操步骤，最后附上我在真实项目中遇到的高频问题和排查思路。保证没有废话，全部是能直接拿去用的东西。1. 重新理解终身学习：模型不变，什么在变1.1 从“训练式学习”到“运行时学习”的范式转换传统意义上的机器学习，学习发生在训练阶段。数据收集、清洗、标注、训练、评估、发布，整个流程走一遍，模型才“学会”一件事。而 Agent 一旦上线，面对的是开放世界，任务类型、表达方式、交互环境随时在变。这时候再靠训练流程去迭代，响应速度完全跟不上。运行时学习代表的是另一种思路：模型推理时不动权重，但系统整体在积累经验。举个生活化的类比，一个刚入职的实习生，大脑里的知识结构短时间内不会变，但他可以通过记笔记、翻手册、问前辈、积累案例，让自己的工作表现越来越好。Agent 的可塑性架构就是这套“笔记 + 手册 + 案例 + 方法论”的外化系统。我在实际项目里见过太多团队把这个搞反了。Agent 表现不好，第一反应是“得微调一下模型”，然后花两周准备数据、训一轮，发现新问题又得再来一轮，陷入无休止的迭代循环。而采用运行时学习思路之后，同样的表现问题，往往通过加一条记忆规则、补一个工具函数、沉淀一个技能模板就能解决，周期从天级缩短到小时级。1.2 稳定性与可塑性困境：为什么不能既要又要神经科学里有一个经典概念叫稳定性-可塑性困境。系统如果太稳定，就学不进新东西；如果太可塑，就容易遗忘旧知识。放到 Agent 场景下，这个困境被模型权重冻结这件事彻底绕开了——既然权重不动，稳定性和可塑性不再是一对矛盾，而是被拆分到不同的系统层面。具体来说，稳定性由基础模型本身承担。模型的语言理解能力、推理能力、知识储备是稳定底座，这些不需要变。可塑性则交给模型外部的组件：记忆系统负责积累新信息，工具系统负责执行新技能，编排系统负责组合新策略。这样一来，Agent 的“大脑”稳定，“经验”可变，“行为”可塑，三者各司其职。这个拆分的价值在实际项目中体现得非常明显。我做过一个文档处理 Agent，底层模型从第一版到第三版几乎没换过，但它的处理能力从只能做简单摘要，演进到能自动识别文档类型、抽取结构化信息、生成多格式报告。所有进步都来自外部系统的积累，模型权重始终冻结，效果却一直在涨。1.3 不改权重，到底“学”的是什么明确了范式之后，一个关键问题摆上台面：既然模型参数不动，学习的对象究竟是什么？拆开看其实很清晰。第一层是事实性知识，比如某个私有系统的 API 用法、某个业务域的术语含义、某类任务的偏好格式，这些沉淀在外部记忆中。第二层是程序性技能，比如怎么调用搜索引擎、怎么操作数据库、怎么生成图表，这些封装成工具函数。第三层是策略性经验，比如哪些工具组合适合处理什么任务、遇到边界情况怎么兜底、用户刁钻输入怎么应对，这些存储在案例库和策略模板中。从实现角度讲，这三层正好对应可塑性架构的三个核心模块：记忆系统、工具系统、编排系统。学习不再发生在神经网络的权重空间里，而是发生在这个外部系统的“状态空间”里。每完成一次任务，状态空间就被更新一次，Agent 的行为模式也随之优化。这个过程中，模型一次 forward 和 backward 都没跑过，但系统整体确实“学会了”。2. 可塑性架构的核心设计：四大支柱2.1 外部记忆与上下文工程：Agent 的长期笔记本可塑性架构的第一根支柱是外部记忆。很多 Agent 项目的记忆设计还停留在“把对话历史拼进 prompt”的阶段，这在长周期任务里根本撑不住。上下文窗口再大也有限度，而且塞满历史会让注意力分散，响应质量直线下降。我在项目中用的是分层记忆方案。最底层是原始日志，每次任务的输入、中间步骤、输出结果全部落盘，用于事后回溯和离线分析。往上一层是摘要记忆，每次任务结束后，用模型自身生成一段结构化摘要，包括任务目标、关键决策、最终结果、遗留问题。最上层是核心经验库，只保存那些被验证有效、且具备复用价值的经验条目，每条带上适用条件和使用记录。这套分层设计的核心逻辑是“松耦合”。原始日志解决的是“发生了什么”的问题，摘要记忆解决的是“当时怎么想的”问题，核心经验库解决的是“下次怎么做得更好”的问题。三层之间通过任务 ID 关联，可以追溯，可以沉淀，也可以清理。上下文工程又是另一层功夫。每次任务启动时，不是把整个记忆库都塞给模型，而是根据任务特征检索出最相关的记忆片段。我常用的策略是双通道召回，先基于 embedding 做语义相似度检索，再用关键词规则做精确匹配兜底，最后合并结果做重排。这样既能处理语义相关，又不丢精确命中，实测效果比单通道稳定得多。2.2 工具即技能：把不可言说的知识变成可调用的函数第二根支柱是工具系统，这是技能自演进的物理载体。一个 Agent 的能力上限，很大程度上取决于它的工具箱里有什么。模型本身再聪明，不会调用工具就等于没手没脚。工具设计的核心不是“功能多多益善”，而是“接口稳定 + 描述清晰 + 失败可预期”。我在项目中要求每个工具必须有硬性的描述规范：工具是干什么的、输入参数是什么类型、输出长什么样、会在什么情况下报错。这些描述是模型决定何时调用该工具的依据，写得含糊，模型的调用决策就会跟着含糊。举个例子，我做一个数据报表 Agent 时，给工具写描述一开始特别随意，“获取数据”“处理数据”这种表述。模型经常在需要精确聚合时调错工具，要么取数范围不对，要么聚合方式偏差。后来把所有工具描述重写成结构化格式，明确输入 Schema、输出 Schema、边界条件、典型使用场景，误调率立刻下降了一个量级。工具系统还要考虑一件事：工具本身能注册、能升级、能下架。Agent 在实际使用中发现某个工具调用频率极低、效果偏差，应当在策略评估后被替换掉。这个过程就是技能演进的一部分，工具库的更新迭代不需要动模型一个参数。2.3 代码即策略：动态生成的执行方案如果说工具系统定义了能力单元，代码策略系统就是把这些单元焊接起来的“施工方案”。传统 Agent 用 ReAct 模式让模型逐步思考、逐步调用工具，这在简单任务里够用，但复杂任务会出现规划不稳定、步骤遗漏、上下文过长等问题。代码即策略是我目前最推崇的实践之一。思路是让模型面向任务生成一段可执行的 Python 代码，代码直接调用工具系统的 API，通过解释器运行，运行结果再反馈给模型。这样做的好处很直接：代码本身就是一种高密度的策略表达，比自然语言的逐步推理更精确、更紧凑、更可复用。我在一个自动化测试 Agent 里验证过这个思路。之前用 ReAct 跑一个多步骤测试用例，模型时不时漏掉中间校验步骤。改成代码生成后，模型一次性生成完整个测试流程的代码，解释器逐行执行，失败时模型根据报错信息修复代码再跑。成功率从七成左右提升到九成以上，而且生成的代码可以缓存复用，后续类似任务直接套模板改参数就行。代码策略还有一个隐藏优势：它天然解决了“可塑性”与“确定性”的矛盾。同样的任务，让模型用自然语言描述怎么处理，每次可能描述得不一样；但让模型生成代码，生成后被验证通过的代码就可以固化为标准流程，行为的一致性大幅提升。2.4 编排层：子 Agent 与策略路由第四根支柱是编排层。没有编排的 Agent 是单体式的，所有任务都走一个大脑一套流程，这在复杂工作流里会迅速暴露问题。我在项目中会按任务粒度拆分多个子 Agent，每个子 Agent 只负责一个相对独立的职责域，由编排层统一调度。子 Agent 的拆分标准不是想当然的“好看”，而是看任务的耦合度。一个文档处理 Agent 可以拆出：内容提取子 Agent、结构分析子 Agent、风格改写子 Agent、格式渲染子 Agent。每个子 Agent 有自己独立的工具范围、记忆空间和策略偏好，这样演进时可以单独迭代，不会互相干扰。策略路由负责决定一件任务交给哪个子 Agent、用什么策略执行。这个决策本身也可以演进。初期的路由规则是人工预设的 if-else，后来改成基于少量历史样本训练的分类器，再后来发现直接用模型做路由选择，并附上每个子 Agent 的能力描述，效果反而更好。最终我采用的是“模型路由 + 规则校验”的混合模式：模型做语义级路由决策，规则引擎做边界条件兜底。编排层的最后一块是任务编排的模式。串行执行、并行拆分、条件跳转、循环重试，这些模式需要以声明式的方式配置，而不是硬编码在代码里。我用过基于状态机的编排配置，每个节点定义执行体、输入源、输出目标和跳转条件，清晰直观，也方便 Agent 在实际执行中动态调整路径。3. 技能自演进机制：从经验到能力的四级跃迁3.1 一级跃迁：从任务日志到结构化案例技能自演进的第一步是积累。没有数据支撑的演进都是空谈。每次 Agent 完成任务，原始日志必须完整记录：用户输入、任务拆解、工具调用序列、中间结果、最终输出、成功与否、耗时成本。这些日志是第一手经验素材。但原始日志不能直接用，信息密度太低。需要设计一个沉淀管道，把日志加工成结构化案例。加工动作至少包括三个环节：关键步骤提取、决策路径还原、结果归因分析。这一步我会让 Agent 自己来做，用模型读日志、写案例，配合人工抽检保证质量。结构化案例的字段设计很关键。我的常用模板包含：任务类型、任务目标、环境特征、执行策略、工具序列、关键参数、结果状态、失败原因、可复用性评分。其中可复用性评分是后续演进取舍的重要依据，初期可以人工打标，跑通了之后可以交给模型自动评估。3.2 二级跃迁：从案例到可复用技能当结构化案例积累到一定数量，下一步就是抽象。把多个具有相似模式的案例归纳成一个可复用的技能，这是技能自演进最核心的质量跃迁。做抽象时我常用的动作是“模板化”。读一批成功案例，找出它们共用的工具序列和执行参数，把固定的部分固化成模板，把可变的部分提取成参数占位符。比如多个案例都在做“从网页抓取表格→清洗→生成 CSV”，那就可以抽象出一个技能叫“网页表格抓取”，参数包括 URL、表头映射、清洗规则。抽象后的技能需要进入技能库做统一管理。每个技能包含：技能名称、触发条件、执行模板、参数 Schema、依赖工具、成功率统计、最近使用时间。这个技能库是 Agent 可塑性架构里的“武器库”，也是演进迭代的主战场。技能入库需要经过验证，不能只跑过一次就收录，至少要有三次以上成功执行记录。这里有一个实操中的经验：技能的抽象粒度不能太粗也不能太细。太粗的技能缺乏通用性，换个场景就失效；太细的技能又退化回工具函数，失去了抽象的价值。我一般控制在一个技能能覆盖 3 到 8 种相似任务场景，少于 3 种说明积累不够，多于 8 种说明应该继续拆分。3.3 三级跃迁：从单技能到组合策略单个技能的复用只是基础，真正的能力涌现来自技能的组合。复杂任务往往需要多个技能按特定顺序、特定条件协作完成，这就是组合策略层。我在实际项目里把组合策略分成显式和隐式两种。显式组合是人工或模型明确编排技能调用序列，比如“先摘要、再翻译、最后格式转换”的流水线。隐式组合是模型根据任务描述动态选择技能并规划调用顺序，每次可能不完全相同。技能自演进到高级阶段，系统应当能够自动沉淀高频组合模式。具体做法是周期性分析日志中的技能调用序列，用序列挖掘算法找出频繁出现的子序列。比如发现“技能A→技能C→技能E”序列在大量成功案例中出现，就可以把它固化为一个推荐组合流程，后续类似任务优先提示模型走这个组合。组合策略的固化不等于死板执行。我给每个组合策略配了可选分支。主流程之外，针对常见的边界条件配置替代路径。这样既保证了执行效率，又保留了容错弹性。3.4 四级跃迁：从策略到偏好的内化演进到了组合策略这一层，Agent 处理具体任务的能力已经相当灵活了。最后一层演进更隐蔽但同样重要，就是偏好的内化。偏好指的不是任务处理能力，而是 Agent 在处理方式上的稳定取向：风格、格式、交互方式、边界处理习惯。举个具体场景。一个面向企业用户的日报生成 Agent，用户习惯使用简洁条目式报告，不想要大段文字。这个偏好可以通过积累用户的反馈记录逐步内化到 Agent 的策略模板中。前几次生成的日报可能偏啰嗦，用户反馈“太长了”，系统记录下这个信号。积累几次后，策略模板自动加入“输出格式偏好：条目式，每条不超过一行”的约束，后续日报输出自动满足偏好。偏好内化的机制在实现上不复杂，本质上是对用户反馈信号的统计与分析。我在项目中维护了一套偏好规则库，每条规则带触发条件和置信度。置信度通过反馈事件累积更新，达到阈值后规则自动生效。这套机制让 Agent 从“能干活”走向“干活让人舒服”，体验层面的提升非常明显。4. 实操过程与核心实现：跑通一个最小闭环4.1 环境准备与工具选型理论部分讲了一大堆，下面进入实操环节。我先用一个最小闭环演示“不改权重”的技能自演进到底怎么落地。这里基于某个主流的开源 Agent 编排框架，生态成熟、社区案例多、上手成本低。选它的原因不是我多偏爱它，而是周边配套丰富，记忆、工具、编排都能找到现成组件。基础环境需要三样东西。第一是基础模型服务，需要支持函数调用和代码解释，这是走通代码策略的前提。第二是向量数据库，用于记忆召回和语义检索，选型时重点看检索速度和小样本召回精度。第三是关系型数据库，用于存放结构化案例、技能定义、策略配置，方便做事务性更新。本地开发环境的搭建没太多幺蛾子，Python 3.10 以上版本，把编排框架、模型 SDK、向量库客户端装上就行。我习惯把配置全部写在配置文件里，模型地址、API 密钥、数据库连接串、检索参数，不要散落在代码各处。可以多写一份配置校验脚本，启动时检查必填项是否齐全，省得调试到一半发现密钥没配。4.2 记忆系统实现：分层存储与双路召回先实现记忆系统的最小版本。核心数据结构三张表：原始日志表、摘要记忆表、核心经验表。原始日志表记录每次任务的全量轨迹，字段包括任务请求、执行序列、输出内容、状态标记、时间戳。摘要记忆表存结构化摘要，用任务 ID 与原始日志关联。核心经验表存精选可复用经验，独立维护。写入流程上，任务结束后先落原始日志。然后触发摘要生成，把原始日志的关键内容交给模型压缩成结构化摘要。最后做一次经验评估，如果本次任务执行成功且路径有新颖性，就提取成核心经验入库。这三个步骤做成异步管道，避免阻塞主任务链路。检索流程上，我实现了双路召回。先将任务描述做 embedding，从向量库召回 top-k 相关记忆；同时用关键词规则库做精确召回，比如任务文本里出现“财报”“分析”就精确命中对应的行业分析经验。两路结果合并后做重排，重排逻辑是语义相关度权重七成、关键词命中权重三成，再叠加时间衰减因子，越近的经验排位越高。从实测效果看，双路召回比纯向量召回在长尾任务上稳定得多。纯向量召回容易把语义相近但场景不同的内容混进来，加上关键词兜底之后，精确命中率明显提升，误召回率下降不少。4.3 工具系统与代码策略的联动工具系统的实现要点是注册中心和描述规范。所有工具统一注册到工具中心，框架自动生成工具清单，并在调用请求里把描述、参数 Schema、返回值结构传给模型。这个环节最值得花时间的是描述撰写，多写一句“适合用于什么场景”比多写十行参数说明都管用。代码策略的落地方式我具体说明一下。在任务进入 Agent 主循环时，先让模型判断任务是否适合代码化执行。判断依据包括任务是否涉及多步骤编排、是否有条件逻辑、是否需要循环处理。如果适合，模型先生成一段 Python 代码，代码导入工具中心提供的 SDK，调用具体工具函数完成业务逻辑。生成代码后放进沙箱解释器执行。解释器返回结果后有两个分支。执行成功且结果满足预期，直接进入收尾流程。执行失败时，把报错信息反馈给模型，让模型判断是代码逻辑错误还是工具调用参数错误，修正后重复执行。重试逻辑我设置了上限，同一个任务最多三次修复机会，超过三次就降级为逐步推理模式。联动效果最明显的一类场景是数据批处理。之前用逐步推理处理“读取 20 个文件并分别汇总”的任务，模型会在中间步骤偷懒或者漏文件。改成代码策略后，模型直接生成一个循环遍历的脚本，一次执行搞定，稳定性和速度都大幅提升。4.4 技能库设计与演进闭环技能库是演进的核心载体。设计上我采用了两层结构：技能定义层和技能实例层。技能定义描述技能模板，包括名称、触发条件、执行模板、参数 Schema。技能实例是具体参数化的可执行体，记录每次实际执行的参数和结果。这么拆分的好处是模板复用与实例追溯互不干扰。技能入库的流程是：定时任务扫描核心经验表，聚合相似经验形成候选技能。相似度判定可以用 embedding 聚类，也可以基于工具调用序列的重合度。候选技能经过验证集评估，挑选验证通过且增益明显的收录进技能库。这个流程就是演进闭环的物理实现。演进闭环的运作频率取决于业务量级。我建议至少每天做一次入库评估，每周做一次技能库整理。整理的重点是淘汰低效技能。判断低效的标准很简单：近三十天调用次数低于阈值，或者近十次调用的成功率持续低于目标水平，就标记为“待评估”，确认后归档。4.5 评估指标体系：演进效果怎么度量做演进如果不度量，等于白做。我在项目中建立了一套三层评估体系。第一层是任务成功率，最直接的硬指标，看任务完成状态。第二层是资源效率，包括 token 消耗、调用次数、执行时长，反应策略是否更经济。第三层是演进价值，看同一个任务第二次执行相比第一次，指标提升了多少。演进价值这个指标比较有意思，它体现了学习曲线。具体计算方式是：收集每类任务的多次执行记录，按时间排序，比较前 30 次与后 30 次的任务成功率与 token 消耗中位数。如果后 30 次成功率更高、消耗更少，说明演进在发挥作用。这套评估体系落实以后，我跟团队说的一句很直白的话就是：技能演进不是玄学，每一项优化都能对应到指标变化上。哪些技能有效、哪些策略白费，数据都记得清清楚楚。5. 常见问题与排查技巧实录5.1 上下文膨胀与记忆污染第一种高频问题就是上下文越塞越多，Agent 响应越来越慢、越来越“糊涂”。原因通常是记忆召回时没有做严格的裁剪和排序。我排查时先看召回条件，确认相关性阈值是否设得太低；再看上下文组装逻辑，确认是否把不相关的背景知识也塞进去了。解决办法有一套标准操作。召回环节加重排过滤，去掉低相关度片段；上下文组装时按任务阶段分层，当前执行阶段只需要当前阶段相关的记忆；超出窗口的早期记忆降级为摘要引用。另外周期性压缩不可少，把旧记忆做层级摘要合并，释放上下文空间。5.2 技能库的冗余与冲突技能库规模增长后，会出现两个典型问题：相似技能冗余和高频调用冲突。表现是模型面对任务时不知道该选哪个技能，选了 A 以后发现结果不对，回退再选 B，反复拉抽屉。我的排查习惯是先跑一次技能相似度矩阵，找出 embedding 距离过近的技能对。逐一检查它们的触发条件和执行模板，确认是否存在明确区分边界。如果边界模糊，合并成一个技能，用参数区分场景。如果边界清晰但模型还是选错，问题就指向触发描述不够精准，重写触发条件。冲突问题则要关注技能的执行优先级。我的做法是给每个技能打一个优先级分数，由历史成功率和调用频次加权得出。多个技能命中时默认选高优先级，模型也能根据任务描述覆盖优先级选择。这个机制上线后，技能冲突导致的任务失败率下降了六成以上。5.3 评估漂移与回归问题技能演进了，基础模型的组合能力没变，但某些基础能力突然表现变差——这种“回归”问题必须重视。常见诱因是技能模板过度特化，适配了太多历史场景，导致它偏离了通用能力。排查回归问题的办法是建立回归测试集。我会挑一批覆盖核心能力的标准任务，每次技能库更新后跑一遍。如果某个核心任务的成功率明显下降，就回滚到上一个技能版本做二分定位。这套流程一开始跑起来有点重，但经历过两次线上回归事故之后就离不开它了。5.4 安全边界与防退化设计最后聊一个容易被忽略的问题：技能自演进如果失控，Agent 的行为边界也会漂移。比如用户反馈偏好的规则被恶意输入污染，Agent 开始执行非预期操作。我遇到过几次这样的情况，源头上是反馈信号没有做安全过滤。安全设计必须嵌入演进链路。第一道关是输入过滤，用户反馈进入统计环节前先过敏感词和意图分类器，可疑信号直接隔离人工复核。第二道关是技能变更审批，自动入库的技能先在沙箱环境验证，只有评估指标达标且通过了安全审查才进入生产技能库。第三道关是回滚预案，整个技能库做版本化快照，出问题能快速回到上一个稳定版本。这套安全体系上线之后，我对演进的容忍度高了很多。没有安全网的时候，我每次让 Agent 自动学习都提心吊胆。现在即使出了异常，也能在半小时内定位并回滚，损失可控，演进才能放开手脚做。6. 演进边界与我的实战体会做了一年多的“不改权重”演进实践，最深的体会是：这个方向并不是要取代微调，而是提供了一条更轻量、更敏捷的能力迭代路径。模型还是会换，重大能力跃迁还是需要训练，但在两次模型升级之间的漫长日子里，Agent 不应该原地踏步。我现在看任何一个 Agent 系统，先问三个问题：它的记忆是累积的还是临时的？它的工具库是封闭的还是可演进的？它的策略模板是固定的还是持续优化的？如果三个答案都是前者，这个 Agent 基本属于用一次就废的消耗品。如果能做到后者，它就具备了真正意义上的可塑性。另外一个实在的建议是：演进机制本身要极简。不要一开始就设计花哨的复杂架构，先把单条闭环跑通——完成一个任务、记录一个案例、沉淀一个技能、复用一个策略。这个闭环能稳定运转，再逐步扩展记忆的维度、工具的规模、编排的复杂度。我见过太多项目把架构设计得庞大无比，最后卡在工程复杂度上动弹不得。如果这篇文章让你对 Agent 的“可塑性”有了新的理解，我建议你翻出自己手头最常用的那个 Agent——不管是一个客服助手，还是一个数据处理管道——问一句：它今天比昨天更聪明了吗？这个问题的答案，大概率会引导你做出点有意思的改变。
“模型权重冻结，能力还在涨”——听起来像悖论，但确实是当下 AI Agent 落地时最让我着迷的一个方向。大多数团队做 Agent 的第一反应是微调模型、改权重、重新训练，可一旦进入生产环境，模型迭代成本高、周期长，还容易灾难性遗忘。我这两年踩过不少坑之后逐渐确认了一条更务实的路线：让 Agent 在不更新任何参数的前提下，通过外部记忆、工具系统、代码策略和编排机制的协同，实现行为层面的“终身学习”。这个方向通常被叫做可塑性架构，也叫技能自演进。它解决的核心问题特别实在：一个 Agent 怎么在一次又一次任务中越用越顺手，越用越聪明，而模型本身完全不动。这篇文章就围绕“不改权重的终身学习”这条主线展开，适合正在做 Agent 应用的开发者、算法工程师，也适合那些被模型迭代成本压得喘不过气的技术负责人。我会从范式转换讲到架构设计，从技能演进机制讲到可落地的实操步骤，最后附上我在真实项目中遇到的高频问题和排查思路。保证没有废话，全部是能直接拿去用的东西。1. 重新理解终身学习：模型不变，什么在变1.1 从“训练式学习”到“运行时学习”的范式转换传统意义上的机器学习，学习发生在训练阶段。数据收集、清洗、标注、训练、评估、发布，整个流程走一遍，模型才“学会”一件事。而 Agent 一旦上线，面对的是开放世界，任务类型、表达方式、交互环境随时在变。这时候再靠训练流程去迭代，响应速度完全跟不上。运行时学习代表的是另一种思路：模型推理时不动权重，但系统整体在积累经验。举个生活化的类比，一个刚入职的实习生，大脑里的知识结构短时间内不会变，但他可以通过记笔记、翻手册、问前辈、积累案例，让自己的工作表现越来越好。Agent 的可塑性架构就是这套“笔记 + 手册 + 案例 + 方法论”的外化系统。我在实际项目里见过太多团队把这个搞反了。Agent 表现不好，第一反应是“得微调一下模型”，然后花两周准备数据、训一轮，发现新问题又得再来一轮，陷入无休止的迭代循环。而采用运行时学习思路之后，同样的表现问题，往往通过加一条记忆规则、补一个工具函数、沉淀一个技能模板就能解决，周期从天级缩短到小时级。1.2 稳定性与可塑性困境：为什么不能既要又要神经科学里有一个经典概念叫稳定性-可塑性困境。系统如果太稳定，就学不进新东西；如果太可塑，就容易遗忘旧知识。放到 Agent 场景下，这个困境被模型权重冻结这件事彻底绕开了——既然权重不动，稳定性和可塑性不再是一对矛盾，而是被拆分到不同的系统层面。具体来说，稳定性由基础模型本身承担。模型的语言理解能力、推理能力、知识储备是稳定底座，这些不需要变。可塑性则交给模型外部的组件：记忆系统负责积累新信息，工具系统负责执行新技能，编排系统负责组合新策略。这样一来，Agent 的“大脑”稳定，“经验”可变，“行为”可塑，三者各司其职。这个拆分的价值在实际项目中体现得非常明显。我做过一个文档处理 Agent，底层模型从第一版到第三版几乎没换过，但它的处理能力从只能做简单摘要，演进到能自动识别文档类型、抽取结构化信息、生成多格式报告。所有进步都来自外部系统的积累，模型权重始终冻结，效果却一直在涨。1.3 不改权重，到底“学”的是什么明确了范式之后，一个关键问题摆上台面：既然模型参数不动，学习的对象究竟是什么？拆开看其实很清晰。第一层是事实性知识，比如某个私有系统的 API 用法、某个业务域的术语含义、某类任务的偏好格式，这些沉淀在外部记忆中。第二层是程序性技能，比如怎么调用搜索引擎、怎么操作数据库、怎么生成图表，这些封装成工具函数。第三层是策略性经验，比如哪些工具组合适合处理什么任务、遇到边界情况怎么兜底、用户刁钻输入怎么应对，这些存储在案例库和策略模板中。从实现角度讲，这三层正好对应可塑性架构的三个核心模块：记忆系统、工具系统、编排系统。学习不再发生在神经网络的权重空间里，而是发生在这个外部系统的“状态空间”里。每完成一次任务，状态空间就被更新一次，Agent 的行为模式也随之优化。这个过程中，模型一次 forward 和 backward 都没跑过，但系统整体确实“学会了”。2. 可塑性架构的核心设计：四大支柱2.1 外部记忆与上下文工程：Agent 的长期笔记本可塑性架构的第一根支柱是外部记忆。很多 Agent 项目的记忆设计还停留在“把对话历史拼进 prompt”的阶段，这在长周期任务里根本撑不住。上下文窗口再大也有限度，而且塞满历史会让注意力分散，响应质量直线下降。我在项目中用的是分层记忆方案。最底层是原始日志，每次任务的输入、中间步骤、输出结果全部落盘，用于事后回溯和离线分析。往上一层是摘要记忆，每次任务结束后，用模型自身生成一段结构化摘要，包括任务目标、关键决策、最终结果、遗留问题。最上层是核心经验库，只保存那些被验证有效、且具备复用价值的经验条目，每条带上适用条件和使用记录。这套分层设计的核心逻辑是“松耦合”。原始日志解决的是“发生了什么”的问题，摘要记忆解决的是“当时怎么想的”问题，核心经验库解决的是“下次怎么做得更好”的问题。三层之间通过任务 ID 关联，可以追溯，可以沉淀，也可以清理。上下文工程又是另一层功夫。每次任务启动时，不是把整个记忆库都塞给模型，而是根据任务特征检索出最相关的记忆片段。我常用的策略是双通道召回，先基于 embedding 做语义相似度检索，再用关键词规则做精确匹配兜底，最后合并结果做重排。这样既能处理语义相关，又不丢精确命中，实测效果比单通道稳定得多。2.2 工具即技能：把不可言说的知识变成可调用的函数第二根支柱是工具系统，这是技能自演进的物理载体。一个 Agent 的能力上限，很大程度上取决于它的工具箱里有什么。模型本身再聪明，不会调用工具就等于没手没脚。工具设计的核心不是“功能多多益善”，而是“接口稳定 + 描述清晰 + 失败可预期”。我在项目中要求每个工具必须有硬性的描述规范：工具是干什么的、输入参数是什么类型、输出长什么样、会在什么情况下报错。这些描述是模型决定何时调用该工具的依据，写得含糊，模型的调用决策就会跟着含糊。举个例子，我做一个数据报表 Agent 时，给工具写描述一开始特别随意，“获取数据”“处理数据”这种表述。模型经常在需要精确聚合时调错工具，要么取数范围不对，要么聚合方式偏差。后来把所有工具描述重写成结构化格式，明确输入 Schema、输出 Schema、边界条件、典型使用场景，误调率立刻下降了一个量级。工具系统还要考虑一件事：工具本身能注册、能升级、能下架。Agent 在实际使用中发现某个工具调用频率极低、效果偏差，应当在策略评估后被替换掉。这个过程就是技能演进的一部分，工具库的更新迭代不需要动模型一个参数。2.3 代码即策略：动态生成的执行方案如果说工具系统定义了能力单元，代码策略系统就是把这些单元焊接起来的“施工方案”。传统 Agent 用 ReAct 模式让模型逐步思考、逐步调用工具，这在简单任务里够用，但复杂任务会出现规划不稳定、步骤遗漏、上下文过长等问题。代码即策略是我目前最推崇的实践之一。思路是让模型面向任务生成一段可执行的 Python 代码，代码直接调用工具系统的 API，通过解释器运行，运行结果再反馈给模型。这样做的好处很直接：代码本身就是一种高密度的策略表达，比自然语言的逐步推理更精确、更紧凑、更可复用。我在一个自动化测试 Agent 里验证过这个思路。之前用 ReAct 跑一个多步骤测试用例，模型时不时漏掉中间校验步骤。改成代码生成后，模型一次性生成完整个测试流程的代码，解释器逐行执行，失败时模型根据报错信息修复代码再跑。成功率从七成左右提升到九成以上，而且生成的代码可以缓存复用，后续类似任务直接套模板改参数就行。代码策略还有一个隐藏优势：它天然解决了“可塑性”与“确定性”的矛盾。同样的任务，让模型用自然语言描述怎么处理，每次可能描述得不一样；但让模型生成代码，生成后被验证通过的代码就可以固化为标准流程，行为的一致性大幅提升。2.4 编排层：子 Agent 与策略路由第四根支柱是编排层。没有编排的 Agent 是单体式的，所有任务都走一个大脑一套流程，这在复杂工作流里会迅速暴露问题。我在项目中会按任务粒度拆分多个子 Agent，每个子 Agent 只负责一个相对独立的职责域，由编排层统一调度。子 Agent 的拆分标准不是想当然的“好看”，而是看任务的耦合度。一个文档处理 Agent 可以拆出：内容提取子 Agent、结构分析子 Agent、风格改写子 Agent、格式渲染子 Agent。每个子 Agent 有自己独立的工具范围、记忆空间和策略偏好，这样演进时可以单独迭代，不会互相干扰。策略路由负责决定一件任务交给哪个子 Agent、用什么策略执行。这个决策本身也可以演进。初期的路由规则是人工预设的 if-else，后来改成基于少量历史样本训练的分类器，再后来发现直接用模型做路由选择，并附上每个子 Agent 的能力描述，效果反而更好。最终我采用的是“模型路由 + 规则校验”的混合模式：模型做语义级路由决策，规则引擎做边界条件兜底。编排层的最后一块是任务编排的模式。串行执行、并行拆分、条件跳转、循环重试，这些模式需要以声明式的方式配置，而不是硬编码在代码里。我用过基于状态机的编排配置，每个节点定义执行体、输入源、输出目标和跳转条件，清晰直观，也方便 Agent 在实际执行中动态调整路径。3. 技能自演进机制：从经验到能力的四级跃迁3.1 一级跃迁：从任务日志到结构化案例技能自演进的第一步是积累。没有数据支撑的演进都是空谈。每次 Agent 完成任务，原始日志必须完整记录：用户输入、任务拆解、工具调用序列、中间结果、最终输出、成功与否、耗时成本。这些日志是第一手经验素材。但原始日志不能直接用，信息密度太低。需要设计一个沉淀管道，把日志加工成结构化案例。加工动作至少包括三个环节：关键步骤提取、决策路径还原、结果归因分析。这一步我会让 Agent 自己来做，用模型读日志、写案例，配合人工抽检保证质量。结构化案例的字段设计很关键。我的常用模板包含：任务类型、任务目标、环境特征、执行策略、工具序列、关键参数、结果状态、失败原因、可复用性评分。其中可复用性评分是后续演进取舍的重要依据，初期可以人工打标，跑通了之后可以交给模型自动评估。3.2 二级跃迁：从案例到可复用技能当结构化案例积累到一定数量，下一步就是抽象。把多个具有相似模式的案例归纳成一个可复用的技能，这是技能自演进最核心的质量跃迁。做抽象时我常用的动作是“模板化”。读一批成功案例，找出它们共用的工具序列和执行参数，把固定的部分固化成模板，把可变的部分提取成参数占位符。比如多个案例都在做“从网页抓取表格→清洗→生成 CSV”，那就可以抽象出一个技能叫“网页表格抓取”，参数包括 URL、表头映射、清洗规则。抽象后的技能需要进入技能库做统一管理。每个技能包含：技能名称、触发条件、执行模板、参数 Schema、依赖工具、成功率统计、最近使用时间。这个技能库是 Agent 可塑性架构里的“武器库”，也是演进迭代的主战场。技能入库需要经过验证，不能只跑过一次就收录，至少要有三次以上成功执行记录。这里有一个实操中的经验：技能的抽象粒度不能太粗也不能太细。太粗的技能缺乏通用性，换个场景就失效；太细的技能又退化回工具函数，失去了抽象的价值。我一般控制在一个技能能覆盖 3 到 8 种相似任务场景，少于 3 种说明积累不够，多于 8 种说明应该继续拆分。3.3 三级跃迁：从单技能到组合策略单个技能的复用只是基础，真正的能力涌现来自技能的组合。复杂任务往往需要多个技能按特定顺序、特定条件协作完成，这就是组合策略层。我在实际项目里把组合策略分成显式和隐式两种。显式组合是人工或模型明确编排技能调用序列，比如“先摘要、再翻译、最后格式转换”的流水线。隐式组合是模型根据任务描述动态选择技能并规划调用顺序，每次可能不完全相同。技能自演进到高级阶段，系统应当能够自动沉淀高频组合模式。具体做法是周期性分析日志中的技能调用序列，用序列挖掘算法找出频繁出现的子序列。比如发现“技能A→技能C→技能E”序列在大量成功案例中出现，就可以把它固化为一个推荐组合流程，后续类似任务优先提示模型走这个组合。组合策略的固化不等于死板执行。我给每个组合策略配了可选分支。主流程之外，针对常见的边界条件配置替代路径。这样既保证了执行效率，又保留了容错弹性。3.4 四级跃迁：从策略到偏好的内化演进到了组合策略这一层，Agent 处理具体任务的能力已经相当灵活了。最后一层演进更隐蔽但同样重要，就是偏好的内化。偏好指的不是任务处理能力，而是 Agent 在处理方式上的稳定取向：风格、格式、交互方式、边界处理习惯。举个具体场景。一个面向企业用户的日报生成 Agent，用户习惯使用简洁条目式报告，不想要大段文字。这个偏好可以通过积累用户的反馈记录逐步内化到 Agent 的策略模板中。前几次生成的日报可能偏啰嗦，用户反馈“太长了”，系统记录下这个信号。积累几次后，策略模板自动加入“输出格式偏好：条目式，每条不超过一行”的约束，后续日报输出自动满足偏好。偏好内化的机制在实现上不复杂，本质上是对用户反馈信号的统计与分析。我在项目中维护了一套偏好规则库，每条规则带触发条件和置信度。置信度通过反馈事件累积更新，达到阈值后规则自动生效。这套机制让 Agent 从“能干活”走向“干活让人舒服”，体验层面的提升非常明显。4. 实操过程与核心实现：跑通一个最小闭环4.1 环境准备与工具选型理论部分讲了一大堆，下面进入实操环节。我先用一个最小闭环演示“不改权重”的技能自演进到底怎么落地。这里基于某个主流的开源 Agent 编排框架，生态成熟、社区案例多、上手成本低。选它的原因不是我多偏爱它，而是周边配套丰富，记忆、工具、编排都能找到现成组件。基础环境需要三样东西。第一是基础模型服务，需要支持函数调用和代码解释，这是走通代码策略的前提。第二是向量数据库，用于记忆召回和语义检索，选型时重点看检索速度和小样本召回精度。第三是关系型数据库，用于存放结构化案例、技能定义、策略配置，方便做事务性更新。本地开发环境的搭建没太多幺蛾子，Python 3.10 以上版本，把编排框架、模型 SDK、向量库客户端装上就行。我习惯把配置全部写在配置文件里，模型地址、API 密钥、数据库连接串、检索参数，不要散落在代码各处。可以多写一份配置校验脚本，启动时检查必填项是否齐全，省得调试到一半发现密钥没配。4.2 记忆系统实现：分层存储与双路召回先实现记忆系统的最小版本。核心数据结构三张表：原始日志表、摘要记忆表、核心经验表。原始日志表记录每次任务的全量轨迹，字段包括任务请求、执行序列、输出内容、状态标记、时间戳。摘要记忆表存结构化摘要，用任务 ID 与原始日志关联。核心经验表存精选可复用经验，独立维护。写入流程上，任务结束后先落原始日志。然后触发摘要生成，把原始日志的关键内容交给模型压缩成结构化摘要。最后做一次经验评估，如果本次任务执行成功且路径有新颖性，就提取成核心经验入库。这三个步骤做成异步管道，避免阻塞主任务链路。检索流程上，我实现了双路召回。先将任务描述做 embedding，从向量库召回 top-k 相关记忆；同时用关键词规则库做精确召回，比如任务文本里出现“财报”“分析”就精确命中对应的行业分析经验。两路结果合并后做重排，重排逻辑是语义相关度权重七成、关键词命中权重三成，再叠加时间衰减因子，越近的经验排位越高。从实测效果看，双路召回比纯向量召回在长尾任务上稳定得多。纯向量召回容易把语义相近但场景不同的内容混进来，加上关键词兜底之后，精确命中率明显提升，误召回率下降不少。4.3 工具系统与代码策略的联动工具系统的实现要点是注册中心和描述规范。所有工具统一注册到工具中心，框架自动生成工具清单，并在调用请求里把描述、参数 Schema、返回值结构传给模型。这个环节最值得花时间的是描述撰写，多写一句“适合用于什么场景”比多写十行参数说明都管用。代码策略的落地方式我具体说明一下。在任务进入 Agent 主循环时，先让模型判断任务是否适合代码化执行。判断依据包括任务是否涉及多步骤编排、是否有条件逻辑、是否需要循环处理。如果适合，模型先生成一段 Python 代码，代码导入工具中心提供的 SDK，调用具体工具函数完成业务逻辑。生成代码后放进沙箱解释器执行。解释器返回结果后有两个分支。执行成功且结果满足预期，直接进入收尾流程。执行失败时，把报错信息反馈给模型，让模型判断是代码逻辑错误还是工具调用参数错误，修正后重复执行。重试逻辑我设置了上限，同一个任务最多三次修复机会，超过三次就降级为逐步推理模式。联动效果最明显的一类场景是数据批处理。之前用逐步推理处理“读取 20 个文件并分别汇总”的任务，模型会在中间步骤偷懒或者漏文件。改成代码策略后，模型直接生成一个循环遍历的脚本，一次执行搞定，稳定性和速度都大幅提升。4.4 技能库设计与演进闭环技能库是演进的核心载体。设计上我采用了两层结构：技能定义层和技能实例层。技能定义描述技能模板，包括名称、触发条件、执行模板、参数 Schema。技能实例是具体参数化的可执行体，记录每次实际执行的参数和结果。这么拆分的好处是模板复用与实例追溯互不干扰。技能入库的流程是：定时任务扫描核心经验表，聚合相似经验形成候选技能。相似度判定可以用 embedding 聚类，也可以基于工具调用序列的重合度。候选技能经过验证集评估，挑选验证通过且增益明显的收录进技能库。这个流程就是演进闭环的物理实现。演进闭环的运作频率取决于业务量级。我建议至少每天做一次入库评估，每周做一次技能库整理。整理的重点是淘汰低效技能。判断低效的标准很简单：近三十天调用次数低于阈值，或者近十次调用的成功率持续低于目标水平，就标记为“待评估”，确认后归档。4.5 评估指标体系：演进效果怎么度量做演进如果不度量，等于白做。我在项目中建立了一套三层评估体系。第一层是任务成功率，最直接的硬指标，看任务完成状态。第二层是资源效率，包括 token 消耗、调用次数、执行时长，反应策略是否更经济。第三层是演进价值，看同一个任务第二次执行相比第一次，指标提升了多少。演进价值这个指标比较有意思，它体现了学习曲线。具体计算方式是：收集每类任务的多次执行记录，按时间排序，比较前 30 次与后 30 次的任务成功率与 token 消耗中位数。如果后 30 次成功率更高、消耗更少，说明演进在发挥作用。这套评估体系落实以后，我跟团队说的一句很直白的话就是：技能演进不是玄学，每一项优化都能对应到指标变化上。哪些技能有效、哪些策略白费，数据都记得清清楚楚。5. 常见问题与排查技巧实录5.1 上下文膨胀与记忆污染第一种高频问题就是上下文越塞越多，Agent 响应越来越慢、越来越“糊涂”。原因通常是记忆召回时没有做严格的裁剪和排序。我排查时先看召回条件，确认相关性阈值是否设得太低；再看上下文组装逻辑，确认是否把不相关的背景知识也塞进去了。解决办法有一套标准操作。召回环节加重排过滤，去掉低相关度片段；上下文组装时按任务阶段分层，当前执行阶段只需要当前阶段相关的记忆；超出窗口的早期记忆降级为摘要引用。另外周期性压缩不可少，把旧记忆做层级摘要合并，释放上下文空间。5.2 技能库的冗余与冲突技能库规模增长后，会出现两个典型问题：相似技能冗余和高频调用冲突。表现是模型面对任务时不知道该选哪个技能，选了 A 以后发现结果不对，回退再选 B，反复拉抽屉。我的排查习惯是先跑一次技能相似度矩阵，找出 embedding 距离过近的技能对。逐一检查它们的触发条件和执行模板，确认是否存在明确区分边界。如果边界模糊，合并成一个技能，用参数区分场景。如果边界清晰但模型还是选错，问题就指向触发描述不够精准，重写触发条件。冲突问题则要关注技能的执行优先级。我的做法是给每个技能打一个优先级分数，由历史成功率和调用频次加权得出。多个技能命中时默认选高优先级，模型也能根据任务描述覆盖优先级选择。这个机制上线后，技能冲突导致的任务失败率下降了六成以上。5.3 评估漂移与回归问题技能演进了，基础模型的组合能力没变，但某些基础能力突然表现变差——这种“回归”问题必须重视。常见诱因是技能模板过度特化，适配了太多历史场景，导致它偏离了通用能力。排查回归问题的办法是建立回归测试集。我会挑一批覆盖核心能力的标准任务，每次技能库更新后跑一遍。如果某个核心任务的成功率明显下降，就回滚到上一个技能版本做二分定位。这套流程一开始跑起来有点重，但经历过两次线上回归事故之后就离不开它了。5.4 安全边界与防退化设计最后聊一个容易被忽略的问题：技能自演进如果失控，Agent 的行为边界也会漂移。比如用户反馈偏好的规则被恶意输入污染，Agent 开始执行非预期操作。我遇到过几次这样的情况，源头上是反馈信号没有做安全过滤。安全设计必须嵌入演进链路。第一道关是输入过滤，用户反馈进入统计环节前先过敏感词和意图分类器，可疑信号直接隔离人工复核。第二道关是技能变更审批，自动入库的技能先在沙箱环境验证，只有评估指标达标且通过了安全审查才进入生产技能库。第三道关是回滚预案，整个技能库做版本化快照，出问题能快速回到上一个稳定版本。这套安全体系上线之后，我对演进的容忍度高了很多。没有安全网的时候，我每次让 Agent 自动学习都提心吊胆。现在即使出了异常，也能在半小时内定位并回滚，损失可控，演进才能放开手脚做。6. 演进边界与我的实战体会做了一年多的“不改权重”演进实践，最深的体会是：这个方向并不是要取代微调，而是提供了一条更轻量、更敏捷的能力迭代路径。模型还是会换，重大能力跃迁还是需要训练，但在两次模型升级之间的漫长日子里，Agent 不应该原地踏步。我现在看任何一个 Agent 系统，先问三个问题：它的记忆是累积的还是临时的？它的工具库是封闭的还是可演进的？它的策略模板是固定的还是持续优化的？如果三个答案都是前者，这个 Agent 基本属于用一次就废的消耗品。如果能做到后者，它就具备了真正意义上的可塑性。另外一个实在的建议是：演进机制本身要极简。不要一开始就设计花哨的复杂架构，先把单条闭环跑通——完成一个任务、记录一个案例、沉淀一个技能、复用一个策略。这个闭环能稳定运转，再逐步扩展记忆的维度、工具的规模、编排的复杂度。我见过太多项目把架构设计得庞大无比，最后卡在工程复杂度上动弹不得。如果这篇文章让你对 Agent 的“可塑性”有了新的理解，我建议你翻出自己手头最常用的那个 Agent——不管是一个客服助手，还是一个数据处理管道——问一句：它今天比昨天更聪明了吗？这个问题的答案，大概率会引导你做出点有意思的改变。