1. 为什么“不改权重”成了AI Agent落地的硬约束先讲一个我实际遇到过的场景。某公司上线了一款智能客服Agent，核心模型在部署前做了完整评估，各项指标都漂亮。结果上线三个月，业务方提了一个新需求——“用户问能不能开发票，你得直接帮我查订单然后答复”。这需求在模型训练时根本不存在，Agent自然也不会。这时候摆在团队面前的选择通常是两条路：重新训练/微调模型，或者在系统层做处理。第一条路一听就很重——收集数据、标注、训练、回归、灰度、上线，一个流程走完，业务早就等不及了。更麻烦的是，你今天为“开发票”微调一次，明天业务又提“改地址”，每条需求都动一次权重，整个系统就永远在追赶需求的路上。这就是“不改权重”被越来越多人提及的根本原因。在AI Agent的落地场景里，权重不是不能改，而是不该轻易改。模型权重本质上是模型的“出厂设定”，一旦更新，影响的不是某一个功能，而是模型在所有任务上的表现分布。业界把这种副作用叫“灾难性遗忘”——模型在拟合新数据时，会把旧知识一点点挤出去。客服场景里特别典型：你教会它新政策，它开始忘旧政策；你让它更擅长处理退货，它处理售前的语气可能就变了。而且权重更新的成本不只是算力，数据回流、效果回归、灰度验证、上线窗口，一环扣一环。对于很多中小团队来说，根本没有这种“改权重的权利”。所以真正的破局思路变了：与其改“大脑”，不如改“行为”。让模型权重保持不变，但让它获取信息、使用工具、组织思考的方式可以持续变化。这个概念在圈子里有各种叫法——参数冻结、上下文工程、记忆增强、工具调用、技能库管理——但本质上是一个东西：把学习从“训练阶段”搬到“运行阶段”。模型的能力上限由权重决定，但Agent的实际表现由“权重+记忆+工具+策略”共同决定。权重不动，后面的部分都可以动，这才是Agent“终身学习”的真正含义。这种思路适合谁来参考？如果你在做Agent应用开发、AI产品落地、RAG系统、自动化工作流，或者你只是好奇“不重训练模型，AI怎么能越用越聪明”，这篇文章应该能给你一个比较完整的框架。内容不会太学术，偏实战，我会把架构原理、运转逻辑、以及我踩过的坑都拆开讲。2. 可塑性架构的核心：把“学习”从模型层搬到系统层2.1 权重是智力，架构是能力，别把两者混为一谈先理清一个基础概念。模型权重决定的是“这个模型有多聪明”——它的常识水平、推理深度、语言表达能力。而Agent的架构决定的是“这个系统能做多少事”——它能记住什么、能调用什么、能把信息组织到什么程度。传统思路把学习和聪明程度绑在一起，觉得“想让它更聪明，就得改权重”。但对Agent来说，这个等式不成立。真正影响用户体验的，往往不是模型聪明不聪明，而是系统能不能找到正确的信息、调用正确的工具、组织出正确的回答。打个比方，一个人记忆力再强，没看过某份文件就是不知道文件内容；他再聪明，不会用某个软件就是没法完成某项操作。这时候你需要的不是给他做脑部手术（改权重），而是给他一份文档（记忆注入）、教他用一个工具（工具调用）、或者帮他梳理一套操作步骤（工作流）。AI Agent也是一样。你把模型当作一个“高智力但无经验的新员工”，架构就是他的办公环境——档案柜、通讯录、工具台、操作手册。档案柜里的资料可以持续增加，工具台上的工具可以持续添置，操作手册可以持续修订。新员工的大脑没变，但他的“工作能力”肉眼可见地涨。这就是“可塑性架构”最核心的设计理念：系统具备持续吸收新知识、新技能而不触碰模型参数的能力。2.2 三层记忆：工作记忆、情景记忆、语义记忆记忆系统是可塑性架构的第一块基石。一个没有记忆的Agent，每次交互都是“初遇”，哪怕你上周刚教过它某条规则，这周它照样忘干净。这显然谈不上“终身学习”。我的实践是把记忆拆成三个层次，借鉴了认知科学的分类方法，但做了工程化简化：工作记忆（Working Memory）：指当前会话的上下文窗口。LLM的context内信息，对话轮次中的用户意图、中间推理过程、临时变量。特点是生命周期极短、访问极快、容量有限。对应到工程上就是上下文窗口管理——把重要的信息放在靠近当前推理的位置，把远古对话压缩或摘要。情景记忆（Episodic Memory）：指历史交互的记录，也就是“这个Agent之前遇到过什么、做过什么、结果如何”。它存储的是具体事件，比如“上周三用户问过产品退换货规则，当时我们给出了1.0版本的话术，用户确认满意”。情景记忆适合用向量数据库存储，按语义相似度检索。作用是让Agent在遇到相似问题时能“想起来”上次怎么处理的，避免重复犯错。语义记忆（Semantic Memory）：指结构化、抽象化的知识，比如业务规则、产品手册、政策文档、技能说明。它不依附于具体事件，而是独立存在的“常识性”业务知识。语义记忆通常来自知识库、文档库、规则引擎，可以通过RAG的方式注入，也可以预加载到系统提示词中。三层记忆对应到生活里就是便利贴、日记本和百科全书。便利贴记当前要做的事，日记本记过往的经验教训，百科全书提供通用的背景知识。Agent的学习能力，很大程度取决于这三层记忆能否高效协作——从情景记忆中提炼经验，沉淀到语义记忆里成为规则，再在工作记忆中被实时调用。2.3 技能层：能力可以被“插拔”记忆负责“知道什么”，技能层负责“能做什么”。一个Agent在没有技能层的情况下，只能靠模型的通用能力生成文本。但现实业务里，Agent需要查数据库、调API、执行计算、发送消息、操作文件。这些能力不可能靠权重学到——模型参数里没有你的业务系统接口。所以要让Agent具备这些操作能力，必须通过工具调用来实现。可塑性架构里，每一项工具都被封装成一个“技能”。技能不只是一个API地址，而是一个完整的描述单元，通常包含：技能名称、功能描述、触发条件、需要的入参、调用方式、输出的解析方式、使用注意事项。这个技能单元会被注册到技能库中，Agent在接到任务时先检索技能库，匹配合适的技能，然后按照技能说明执行调用。关键是，这个技能库是可动态扩展的。今天你的Agent不会查发票，没关系，你把查发票的接口封装成一个新技能丢进技能库，明天它就会了。全程不动模型权重，不重新训练，不改核心代码。这种“插拔式”的能力扩展，就是可塑性架构的第二个基石。后面我会详细讲技能自演进的闭环是怎么跑起来的，这里先记住一个结论：架构的可塑性，本质上就是记忆层和技能层的可扩展性。3. 技能自演进：闭环是怎样转起来的3.1 从“固化经验”到“生成技能”的三级跳技能自演进这个词听起来很玄，拆开看其实就三个阶段：记录经验、提炼流程、封装技能。第一阶段，记录经验。Agent在执行任务的过程中，会产生大量的交互记录——问题、行动、中间结果、最终答复、用户反馈。这些记录默认散落在日志里，不经过处理就是死数据。自演进的第一步，是把这些原始记录结构化，存成情景记忆。比如一次成功的退货流程，需要把“用户问题是什么”“调了哪个接口”“传了什么参数”“返回了什么结果”“最终话术是什么”整理成一条结构化记录。这一步是地基，没有结构化记录，后面所有提炼都无从谈起。第二阶段，提炼流程。光有记录还不够，因为记录是零散的。系统需要在一定量的记录基础上，识别出重复出现的模式。比如发现“退换货查询”这个任务一周出现了47次，每次的处理路径几乎一致：解析订单号→调用订单查询接口→核对退货状态→生成答复。这个模式被提取出来后，就不再只是单条记录，而是一段可复用的流程描述。第三阶段，封装技能。流程描述再往前走一步，就变成技能：明确触发条件、参数规范、调用步骤、输出格式，注册进技能库。到这里，一个从经验中生长出来的新技能就诞生了。下一次Agent再遇到类似任务，不再需要从零推理，直接从技能库调这个封装好的流程，速度和准确率都会提升。这就是“技能自演进”的完整路径：经验→模式→技能。3.2 触发演进的信号：什么时候该生成新技能不是所有经验都值得变成技能。如果系统对每一条对话都生成技能，技能库很快就会爆炸。我在实操中总结了几类比较可靠的触发信号：高频重复：同一类型的任务在单位时间内反复出现，说明这是一个稳定的需求场景，值得封装。具体阈值需要根据业务量调整，我一般设置一周内出现30次以上。多步操作但路径稳定：如果某个任务Agent每次都需要3步以上的规划才能完成，而且这3步的路径高度一致，说明可以压缩成一步技能调用。这有点类似人的“肌肉记忆”——熟练之后不再需要一步步思考。错误修正后：Agent在某个任务上出错了，经过纠错后成功完成。这类“知错能改”的经历非常宝贵，说明流程中有一个坑被填上了，应该把修正后的路径固化成技能，防止下次再踩。高频但低效：任务不复杂，但Agent每次都要花大量tokens去检索信息、反复推理。这种情况封装技能的收益最大——把固定动作变成单次调用，延迟和成本同时下降。反过来也要设置过滤条件：低频偶发任务不值得封装，一次性任务更不值得。封装技能是有维护成本的，技能库里躺着大量“僵尸技能”，反而会在调度阶段增加检索噪声。3.3 技能也讲究“新陈代谢”：评估、去重、淘汰技能自演进不只是“新增”，还包括“更新”和“删除”。我把技能库看作一个活体，它需要持续的新陈代谢。如果一个技能被调用100次，成功率只有40%，但它占了技能库30%的检索流量，这时候就应该标记为低效技能，进入观察名单。如果连续观察期后成功率没有改善，就应该下线或者降级。为什么需要淘汰机制？因为技能库会影响Agent的决策。技能检索通常基于embedding相似度或规则匹配，技能太多、太杂，相似的技能之间会互相干扰，导致Agent匹配到错误的技能，或者匹配到了但参数不对。这就像你的工具箱里同时放了一把大号螺丝刀和一把中号螺丝刀，不加区分地堆放，真正用的时候你反而要犹豫拿哪把。去重也是一个必须做的动作。技能自演进过程中，很容易出现“重复发明轮子”——不同时间的经验固化出两个功能完全相同的技能，只是描述措辞不同。这种重复技能需要定期合并，保留描述更清晰、调用记录更好的那个，被合并的降级为别名或直接删除。这个工作用人工做最靠谱，也可以写一个周期性任务，利用embedding相似度做初筛，人工确认后合并。技能质量评估的几个关键指标：调用成功率、平均耗时、参数错误率、用户负面反馈率、人工纠正率。这些指标需要持续记录，出了问题才能定位是技能本身的问题、参数解析的问题还是触发条件过宽/过窄的问题。4. 实操：搭一个最小可用的技能自演进Agent4.1 架构选型：别一上来就上重武器先声明一点，下面要讲的不是一个大厂级分布式系统，而是一个你可以在自己项目里复现的“最小闭环”。核心组件就四个：一个LLM推理服务（负责语言理解和生成）、一个向量数据库（负责记忆存储与检索）、一个技能注册表（负责技能元信息的登记、匹配、调度，可以用JSON文件或轻量数据库实现）、一个调度执行模块（承上启下的胶水代码）。就这些，不需要K8s，不需要消息队列，不需要繁琐的中间件。我见过很多团队一上来就规划微服务架构，各种模块拆得飞起，结果三个月过去了还在搭基建。做Agent系统的第一原则应该是：先让闭环跑起来，再谈工程优化。最小闭环的代码可能只有几百行，但每条数据链路都是通的，后面再逐步替换掉不合理的组件，比一开始就“完美设计”要高效得多。而且小方案在迭代过程中能让你快速发现瓶颈，比如你很快会知道检索是不是够快、技能匹配是不是够准，这些参数只有真实数据才能告诉你。4.2 技能注册表：一切能力的元信息中心技能注册表是整个自演进架构的核心。每个技能在注册表里是这样一条记录：id: "skill_invoice_query_01" name: "发票查询" description: "根据订单号查询用户的发票信息，包括发票抬头、金额、开票状态" trigger_keywords: ["发票", "开票", "invoice"] trigger_condition: "用户明确表达查询发票需求，且提供了或可获取订单号" parameters: - name: "order_id" type: "string" description: "订单号，可以从对话中抽取，也可以询问用户" required: true steps: - "调用订单系统发票查询接口" - "解析返回的开票状态、发票链接" - "组装回复内容，附上发票链接" output_format: "文本回复+链接" evaluation: success_criteria: "用户获得有效的发票链接，或明确的未开票说明" success_rate: 0.0 call_count: 0 version: "1.0.0" status: "active"这不是一个花架子。每个字段都有实际用途：description和trigger_keywords是调度时的匹配线索；parameters指导LLM从对话中抽取入参；steps是可执行的动作序列；evaluation是这个技能的生命体征，用于自演进判断。调度模块在接到新任务时，先做技能检索，如果匹配度超过阈值，就按技能定义执行；如果匹配不上，就退化到通用规划模式。4.3 记忆层的读写实现记忆层的写入，建议在每次会话结束后做异步处理。一个比较实用的做法是把会话中“有结果”的片段提取出来——不要全量存，会污染记忆库。比如用户问了发票问题，Agent成功给了发票链接，这条交互是有明确产出的，值得写入情景记忆。但如果用户只是闲聊了几句，这种就没有记忆价值。写入时要做结构化抽取，典型字段包括：用户意图、处理动作、调用工具、工具返回摘要、最终答复、结果状态（成功/失败/部分成功）。把这些字段作为一个JSON对象存入向量库，同时生成对应的embedding。读取的时候，用当前任务的问题做embedding，在记忆库里做相似度检索，取top-k条。这里有一个关键经验：检索阈值不要设得太死。相似度低于0.6的结果基本没用，但0.65和0.75之间的结果往往有其参考价值，尤其是当记忆稀缺的时候。我通常的做法是把阈值设为0.65，然后要求LLM在参考历史记忆时判断——哪些是真正相关的，哪些只是表面相似。4.4 核心循环：任务执行与技能沉淀整个系统的核心循环可以用伪代码表示：def run_agent(user_request): # 1. 先从技能库中检索是否有匹配技能 skills = search_skill_library(user_request) if skills and skills[0].match_score > threshold: # 命中技能，按技能流程执行 return execute_skill(skills[0], user_request) else: # 未命中技能，走通用规划 result = general_reasoning(user_request) # 会话结束后，评估本次执行是否值得沉淀 evaluate_and_consolidate(user_request, result) return result其中evaluate_and_consolidate是自演进的关键切入点。执行成功后，系统会评判：这个任务是否高频相似、路径是否稳定、成功率是否可靠。如果满足封装条件，就生成新技能条目写入注册表。这个过程是异步、滞后触发的，不会阻塞当前任务。这里还要注意一个问题：别让Agent每次完成任务后都“自嗨”式地生成技能。技能生成必须经过质量门槛。我的做法是引入一个“置信度评估”的环节——生成后的技能需要经过一段观察期，观察期内它会进入沙盒（shadow mode）状态，可以参与匹配，但执行结果只记录不影响主流程。当观察期内的成功率达到设定标准（比如70%以上），才升级为正式技能，参与正常任务调度。4.5 一个具体例子：从“不会”到“会”假设你的Agent开始时不支持查发票。用户第一次问“我的发票怎么开”，Agent走的是通用推理：先理解需求，发现没有可用工具，只好回复“抱歉，我还不能处理发票相关问题”。会话结束后，系统记录了这次交互，结果状态是失败。后来你接入了发票查询API，把这个能力封装成一个工具，但只是一个原始工具，还不是“技能”。Agent在系统提示词里知道有发票查询接口可以用。下一次用户再问发票，Agent调用接口成功，返回了发票信息。会话结束后系统记录：这是一次成功的“解析需求-调用接口-输出结果”的完整路径。重复了若干次这样的成功路径后，系统检测到这类任务高频出现且步骤高度一致，于是自动生成一个技能条目：触发条件、参数、步骤、评估标准全部就绪。再下一次任务到来，技能命中，Agent不再需要一步步规划，直接按技能流程执行。这就是一个完整的自演进循环：缺工具→补工具→积累成功案例→提炼技能→高效执行。整个过程我没有动过一行权重。5. 常见问题与排查实录5.1 技能库检索总是召回不到正确技能这个问题的出现频率极高。第一反应先查embedding模型对领域术语的表征能力。业务术语往往和通用语义有偏差，比如“退票”和“退款”在业务里是两个完全不同的流程，但通用embedding模型可能认为它俩语义相近，导致匹配混乱。解决办法一：在技能描述的编写时，把同义词、近义词全部写进trigger_keywords；解决办法二：给技能添加标签分类，比如“售后类”“订单类”“发票类”，检索时先过一层规则分类再做向量匹配。我的经验是：纯向量匹配在技能数量超过30-50个时，精度下降非常明显。这时候一定要引入规则层做预过滤。规则层可以是简单的关键词，也可以是基于正则的意图分类。先缩小候选集，再做向量检索，效果会好很多。5.2 技能膨胀：技能越多，Agent反而越迟钝这是一个反直觉但很常见的问题。技能库200个技能，检索延迟飙升，匹配准确率下降。原因是向量检索在高基数候选集上，相互干扰严重。有一次我被这个问题折磨了一周——技能库从40个涨到120个之后，Agent开始频繁用错技能，比如把“优惠券查询”匹配到“退款进度查询”上去，用户投诉明显增加。排查后发现两个问题：一是部分技能的description写得太泛，互相重合；二是没有淘汰机制，大量低质量技能占用了检索空间。解法：对被调用次数少于5次的技能做标记，人工审核是否合并或删除；同时对description做重写，强调每个技能的独特适用场景。我还加了一道“场景白名单”机制：特定场景下只开放部分技能库，比如在“售前咨询”场景下，售后相关的技能不可见。这大幅降低了检索噪声。5.3 上下文窗口永远不够用不改权重的架构里，上下文就是一切。一旦上下文被塞满，Agent的注意力就会被稀释，表现断崖式下跌。这里要区分两种情况：一种是记忆注入过多，把大量的历史记录、技能说明一股脑塞进system prompt；另一种是长期对话过程中对话轮次累积太多。解法各有不同。记忆注入过多，要做的是“检索后压缩”——取回的记忆先经过一个LLM摘要步骤，只保留最核心的几行，再注入上下文;不要 langsung把原始JSON全部塞进去。对话轮次过长，要做的是“对话摘要+关键细节保留”——在上下文快要接近限制时，把前面的对话总结成一段摘要，保留用户需求、承诺事项、正在处理的任务等关键信息，其余细节丢给情景记忆层。我一直建议团队给上下文使用情况加监控指标，把它当成线上服务的资源利用率来管理。上下文不是取之不尽的，它是最贵的“工作记忆”。你要像精算师一样规划每一块空间。5.4 “学错了”：坏技能被固化比没技能更可怕的是错误的技能被固化。有一次我处理过一个案例：Agent在处理“发票重开”请求时，调用了开票接口，但因为参数里传错了发票类型，导致生成了一张错误发票。由于接口返回成功，Agent认为任务完成，系统也把这个流程记成了“成功案例”，后续在观察期内居然还达到了70%的成功率门槛，被升级成了正式技能。等到发现问题的时候，这个坏技能已经被调用了上百次。这个问题怎么防？两个核心手段：结果验证和延迟确认。结果验证要求在每次工具调用后，不只看接口返回码，还要对输出做一层业务校验，比如发票类型是否符合用户要求；延迟确认则是在技能升级前加入人工抽检环节——观察期内的成功案例，按一定比例人工抽查，抽检通过才允许升级。听起来繁琐，但这是防止坏技能扩散的必要代价。6. 边界思考：不改权重能走多远6.1 可塑性架构的天花板在哪说完了好处，也得说限制。不改权重的架构不是万能的，它有明确的天花板。第一个限制是推理能力本身。如果你的LLM本身不擅长复杂的多步推理，那无论你怎么搭配记忆和工具，它的推理上限就摆在那里。系统层可以补充知识和技能，但替代不了模型自身薄弱的基础能力，比如长链条逻辑推理、复杂的数学计算、深度的代码生成。这些问题靠架构层面的优化来补救会非常吃力。第二个限制是记忆和技能的表示能力。记忆层靠向量检索和文本存取，本质上是不精确的。对于高度结构化、强约束的知识，比如复杂的业务规则树、敏感数据访问控制、需要严格因果推导的流程，文本向量就扛不住了。这时候需要外接规则引擎或图数据库来补足，不能只用可塑性架构硬撑。第三个限制是维护成本。技能库、记忆库都会持续增长，需要持续的治理。一个无人看管的自演进系统，一两周内就能长出大量垃圾技能和冗余记忆，反而拖垮Agent表现。可塑性不是“建好就完事”，而是“持续经营”。6.2 什么时候应该“改权重”那改权重什么时候还有必要？我的判断是：当问题出在“模型理解不了语言和领域背景”时，而不是“系统缺少信息和工具”时。比如一个法律领域的Agent，如果模型本身对法言法语的理解不够，无论你怎么注入法条、怎么封装法律工具，它的归纳和推理还是会在浅层打转。这种情况下，对模型做领域适配的微调或预训练，效果立竿见影。一个比较理性的策略是：先系统层，后模型层。先用可塑性架构把记忆、工具、技能全部搭好，把能通过系统解决的问题全部解决。把问题清单过滤一遍，剩下的、确实瓶颈在模型智力本身的，才考虑做模型侧的更新。这样能用最低的成本满足大多数需求，同时把模型更新的频率降到最低，避免频繁动权重带来的灾难性遗忘和运维复杂度。6.3 未来方向：可塑性与模型进化双轨并行从我观察到的趋势来看，可塑性架构不会替代模型训练，而是和它并存。模型的迭代周期会越来越长，但Agent系统的奔跑速度会越来越快——因为真正让Agent“适配业务”的，不是模型参数，而是系统层的持续学习。这有点类似计算机的发展历史：CPU的架构更新是慢周期，但操作系统、应用软件、驱动程序的迭代是快周期。两者各有其位。对于中小团队，我认为价值点和发力点非常清晰：不要一开始就想着训练模型，先把系统层的记忆、技能和自演进闭环做扎实。这是一条成本更低、见效更快、可迭代性更强的路径。等你跑通了这套架构，积累了足够多的业务经验数据，再去反哺模型侧的优化，会顺畅得多。最后分享一个我个人的小习惯：每搭建完一个Agent系统，我会安排一个“复盘日”，专门盯着技能库和记忆库当天新增了多少条目、哪些技能调用了多少次、有没有异常的低成功率。这个习惯帮我及早发现过好几次自演进跑偏的问题。系统会自己长大，但你要是完全放手不管，它可能长成你认不出来的样子。可塑性建立的是“成长的能力”，而不是“免维护的特权”——这把尺子，每一个做Agent的团队都应该握在自己手里。
1. 为什么“不改权重”成了AI Agent落地的硬约束先讲一个我实际遇到过的场景。某公司上线了一款智能客服Agent，核心模型在部署前做了完整评估，各项指标都漂亮。结果上线三个月，业务方提了一个新需求——“用户问能不能开发票，你得直接帮我查订单然后答复”。这需求在模型训练时根本不存在，Agent自然也不会。这时候摆在团队面前的选择通常是两条路：重新训练/微调模型，或者在系统层做处理。第一条路一听就很重——收集数据、标注、训练、回归、灰度、上线，一个流程走完，业务早就等不及了。更麻烦的是，你今天为“开发票”微调一次，明天业务又提“改地址”，每条需求都动一次权重，整个系统就永远在追赶需求的路上。这就是“不改权重”被越来越多人提及的根本原因。在AI Agent的落地场景里，权重不是不能改，而是不该轻易改。模型权重本质上是模型的“出厂设定”，一旦更新，影响的不是某一个功能，而是模型在所有任务上的表现分布。业界把这种副作用叫“灾难性遗忘”——模型在拟合新数据时，会把旧知识一点点挤出去。客服场景里特别典型：你教会它新政策，它开始忘旧政策；你让它更擅长处理退货，它处理售前的语气可能就变了。而且权重更新的成本不只是算力，数据回流、效果回归、灰度验证、上线窗口，一环扣一环。对于很多中小团队来说，根本没有这种“改权重的权利”。所以真正的破局思路变了：与其改“大脑”，不如改“行为”。让模型权重保持不变，但让它获取信息、使用工具、组织思考的方式可以持续变化。这个概念在圈子里有各种叫法——参数冻结、上下文工程、记忆增强、工具调用、技能库管理——但本质上是一个东西：把学习从“训练阶段”搬到“运行阶段”。模型的能力上限由权重决定，但Agent的实际表现由“权重+记忆+工具+策略”共同决定。权重不动，后面的部分都可以动，这才是Agent“终身学习”的真正含义。这种思路适合谁来参考？如果你在做Agent应用开发、AI产品落地、RAG系统、自动化工作流，或者你只是好奇“不重训练模型，AI怎么能越用越聪明”，这篇文章应该能给你一个比较完整的框架。内容不会太学术，偏实战，我会把架构原理、运转逻辑、以及我踩过的坑都拆开讲。2. 可塑性架构的核心：把“学习”从模型层搬到系统层2.1 权重是智力，架构是能力，别把两者混为一谈先理清一个基础概念。模型权重决定的是“这个模型有多聪明”——它的常识水平、推理深度、语言表达能力。而Agent的架构决定的是“这个系统能做多少事”——它能记住什么、能调用什么、能把信息组织到什么程度。传统思路把学习和聪明程度绑在一起，觉得“想让它更聪明，就得改权重”。但对Agent来说，这个等式不成立。真正影响用户体验的，往往不是模型聪明不聪明，而是系统能不能找到正确的信息、调用正确的工具、组织出正确的回答。打个比方，一个人记忆力再强，没看过某份文件就是不知道文件内容；他再聪明，不会用某个软件就是没法完成某项操作。这时候你需要的不是给他做脑部手术（改权重），而是给他一份文档（记忆注入）、教他用一个工具（工具调用）、或者帮他梳理一套操作步骤（工作流）。AI Agent也是一样。你把模型当作一个“高智力但无经验的新员工”，架构就是他的办公环境——档案柜、通讯录、工具台、操作手册。档案柜里的资料可以持续增加，工具台上的工具可以持续添置，操作手册可以持续修订。新员工的大脑没变，但他的“工作能力”肉眼可见地涨。这就是“可塑性架构”最核心的设计理念：系统具备持续吸收新知识、新技能而不触碰模型参数的能力。2.2 三层记忆：工作记忆、情景记忆、语义记忆记忆系统是可塑性架构的第一块基石。一个没有记忆的Agent，每次交互都是“初遇”，哪怕你上周刚教过它某条规则，这周它照样忘干净。这显然谈不上“终身学习”。我的实践是把记忆拆成三个层次，借鉴了认知科学的分类方法，但做了工程化简化：工作记忆（Working Memory）：指当前会话的上下文窗口。LLM的context内信息，对话轮次中的用户意图、中间推理过程、临时变量。特点是生命周期极短、访问极快、容量有限。对应到工程上就是上下文窗口管理——把重要的信息放在靠近当前推理的位置，把远古对话压缩或摘要。情景记忆（Episodic Memory）：指历史交互的记录，也就是“这个Agent之前遇到过什么、做过什么、结果如何”。它存储的是具体事件，比如“上周三用户问过产品退换货规则，当时我们给出了1.0版本的话术，用户确认满意”。情景记忆适合用向量数据库存储，按语义相似度检索。作用是让Agent在遇到相似问题时能“想起来”上次怎么处理的，避免重复犯错。语义记忆（Semantic Memory）：指结构化、抽象化的知识，比如业务规则、产品手册、政策文档、技能说明。它不依附于具体事件，而是独立存在的“常识性”业务知识。语义记忆通常来自知识库、文档库、规则引擎，可以通过RAG的方式注入，也可以预加载到系统提示词中。三层记忆对应到生活里就是便利贴、日记本和百科全书。便利贴记当前要做的事，日记本记过往的经验教训，百科全书提供通用的背景知识。Agent的学习能力，很大程度取决于这三层记忆能否高效协作——从情景记忆中提炼经验，沉淀到语义记忆里成为规则，再在工作记忆中被实时调用。2.3 技能层：能力可以被“插拔”记忆负责“知道什么”，技能层负责“能做什么”。一个Agent在没有技能层的情况下，只能靠模型的通用能力生成文本。但现实业务里，Agent需要查数据库、调API、执行计算、发送消息、操作文件。这些能力不可能靠权重学到——模型参数里没有你的业务系统接口。所以要让Agent具备这些操作能力，必须通过工具调用来实现。可塑性架构里，每一项工具都被封装成一个“技能”。技能不只是一个API地址，而是一个完整的描述单元，通常包含：技能名称、功能描述、触发条件、需要的入参、调用方式、输出的解析方式、使用注意事项。这个技能单元会被注册到技能库中，Agent在接到任务时先检索技能库，匹配合适的技能，然后按照技能说明执行调用。关键是，这个技能库是可动态扩展的。今天你的Agent不会查发票，没关系，你把查发票的接口封装成一个新技能丢进技能库，明天它就会了。全程不动模型权重，不重新训练，不改核心代码。这种“插拔式”的能力扩展，就是可塑性架构的第二个基石。后面我会详细讲技能自演进的闭环是怎么跑起来的，这里先记住一个结论：架构的可塑性，本质上就是记忆层和技能层的可扩展性。3. 技能自演进：闭环是怎样转起来的3.1 从“固化经验”到“生成技能”的三级跳技能自演进这个词听起来很玄，拆开看其实就三个阶段：记录经验、提炼流程、封装技能。第一阶段，记录经验。Agent在执行任务的过程中，会产生大量的交互记录——问题、行动、中间结果、最终答复、用户反馈。这些记录默认散落在日志里，不经过处理就是死数据。自演进的第一步，是把这些原始记录结构化，存成情景记忆。比如一次成功的退货流程，需要把“用户问题是什么”“调了哪个接口”“传了什么参数”“返回了什么结果”“最终话术是什么”整理成一条结构化记录。这一步是地基，没有结构化记录，后面所有提炼都无从谈起。第二阶段，提炼流程。光有记录还不够，因为记录是零散的。系统需要在一定量的记录基础上，识别出重复出现的模式。比如发现“退换货查询”这个任务一周出现了47次，每次的处理路径几乎一致：解析订单号→调用订单查询接口→核对退货状态→生成答复。这个模式被提取出来后，就不再只是单条记录，而是一段可复用的流程描述。第三阶段，封装技能。流程描述再往前走一步，就变成技能：明确触发条件、参数规范、调用步骤、输出格式，注册进技能库。到这里，一个从经验中生长出来的新技能就诞生了。下一次Agent再遇到类似任务，不再需要从零推理，直接从技能库调这个封装好的流程，速度和准确率都会提升。这就是“技能自演进”的完整路径：经验→模式→技能。3.2 触发演进的信号：什么时候该生成新技能不是所有经验都值得变成技能。如果系统对每一条对话都生成技能，技能库很快就会爆炸。我在实操中总结了几类比较可靠的触发信号：高频重复：同一类型的任务在单位时间内反复出现，说明这是一个稳定的需求场景，值得封装。具体阈值需要根据业务量调整，我一般设置一周内出现30次以上。多步操作但路径稳定：如果某个任务Agent每次都需要3步以上的规划才能完成，而且这3步的路径高度一致，说明可以压缩成一步技能调用。这有点类似人的“肌肉记忆”——熟练之后不再需要一步步思考。错误修正后：Agent在某个任务上出错了，经过纠错后成功完成。这类“知错能改”的经历非常宝贵，说明流程中有一个坑被填上了，应该把修正后的路径固化成技能，防止下次再踩。高频但低效：任务不复杂，但Agent每次都要花大量tokens去检索信息、反复推理。这种情况封装技能的收益最大——把固定动作变成单次调用，延迟和成本同时下降。反过来也要设置过滤条件：低频偶发任务不值得封装，一次性任务更不值得。封装技能是有维护成本的，技能库里躺着大量“僵尸技能”，反而会在调度阶段增加检索噪声。3.3 技能也讲究“新陈代谢”：评估、去重、淘汰技能自演进不只是“新增”，还包括“更新”和“删除”。我把技能库看作一个活体，它需要持续的新陈代谢。如果一个技能被调用100次，成功率只有40%，但它占了技能库30%的检索流量，这时候就应该标记为低效技能，进入观察名单。如果连续观察期后成功率没有改善，就应该下线或者降级。为什么需要淘汰机制？因为技能库会影响Agent的决策。技能检索通常基于embedding相似度或规则匹配，技能太多、太杂，相似的技能之间会互相干扰，导致Agent匹配到错误的技能，或者匹配到了但参数不对。这就像你的工具箱里同时放了一把大号螺丝刀和一把中号螺丝刀，不加区分地堆放，真正用的时候你反而要犹豫拿哪把。去重也是一个必须做的动作。技能自演进过程中，很容易出现“重复发明轮子”——不同时间的经验固化出两个功能完全相同的技能，只是描述措辞不同。这种重复技能需要定期合并，保留描述更清晰、调用记录更好的那个，被合并的降级为别名或直接删除。这个工作用人工做最靠谱，也可以写一个周期性任务，利用embedding相似度做初筛，人工确认后合并。技能质量评估的几个关键指标：调用成功率、平均耗时、参数错误率、用户负面反馈率、人工纠正率。这些指标需要持续记录，出了问题才能定位是技能本身的问题、参数解析的问题还是触发条件过宽/过窄的问题。4. 实操：搭一个最小可用的技能自演进Agent4.1 架构选型：别一上来就上重武器先声明一点，下面要讲的不是一个大厂级分布式系统，而是一个你可以在自己项目里复现的“最小闭环”。核心组件就四个：一个LLM推理服务（负责语言理解和生成）、一个向量数据库（负责记忆存储与检索）、一个技能注册表（负责技能元信息的登记、匹配、调度，可以用JSON文件或轻量数据库实现）、一个调度执行模块（承上启下的胶水代码）。就这些，不需要K8s，不需要消息队列，不需要繁琐的中间件。我见过很多团队一上来就规划微服务架构，各种模块拆得飞起，结果三个月过去了还在搭基建。做Agent系统的第一原则应该是：先让闭环跑起来，再谈工程优化。最小闭环的代码可能只有几百行，但每条数据链路都是通的，后面再逐步替换掉不合理的组件，比一开始就“完美设计”要高效得多。而且小方案在迭代过程中能让你快速发现瓶颈，比如你很快会知道检索是不是够快、技能匹配是不是够准，这些参数只有真实数据才能告诉你。4.2 技能注册表：一切能力的元信息中心技能注册表是整个自演进架构的核心。每个技能在注册表里是这样一条记录：id: "skill_invoice_query_01" name: "发票查询" description: "根据订单号查询用户的发票信息，包括发票抬头、金额、开票状态" trigger_keywords: ["发票", "开票", "invoice"] trigger_condition: "用户明确表达查询发票需求，且提供了或可获取订单号" parameters: - name: "order_id" type: "string" description: "订单号，可以从对话中抽取，也可以询问用户" required: true steps: - "调用订单系统发票查询接口" - "解析返回的开票状态、发票链接" - "组装回复内容，附上发票链接" output_format: "文本回复+链接" evaluation: success_criteria: "用户获得有效的发票链接，或明确的未开票说明" success_rate: 0.0 call_count: 0 version: "1.0.0" status: "active"这不是一个花架子。每个字段都有实际用途：description和trigger_keywords是调度时的匹配线索；parameters指导LLM从对话中抽取入参；steps是可执行的动作序列；evaluation是这个技能的生命体征，用于自演进判断。调度模块在接到新任务时，先做技能检索，如果匹配度超过阈值，就按技能定义执行；如果匹配不上，就退化到通用规划模式。4.3 记忆层的读写实现记忆层的写入，建议在每次会话结束后做异步处理。一个比较实用的做法是把会话中“有结果”的片段提取出来——不要全量存，会污染记忆库。比如用户问了发票问题，Agent成功给了发票链接，这条交互是有明确产出的，值得写入情景记忆。但如果用户只是闲聊了几句，这种就没有记忆价值。写入时要做结构化抽取，典型字段包括：用户意图、处理动作、调用工具、工具返回摘要、最终答复、结果状态（成功/失败/部分成功）。把这些字段作为一个JSON对象存入向量库，同时生成对应的embedding。读取的时候，用当前任务的问题做embedding，在记忆库里做相似度检索，取top-k条。这里有一个关键经验：检索阈值不要设得太死。相似度低于0.6的结果基本没用，但0.65和0.75之间的结果往往有其参考价值，尤其是当记忆稀缺的时候。我通常的做法是把阈值设为0.65，然后要求LLM在参考历史记忆时判断——哪些是真正相关的，哪些只是表面相似。4.4 核心循环：任务执行与技能沉淀整个系统的核心循环可以用伪代码表示：def run_agent(user_request): # 1. 先从技能库中检索是否有匹配技能 skills = search_skill_library(user_request) if skills and skills[0].match_score > threshold: # 命中技能，按技能流程执行 return execute_skill(skills[0], user_request) else: # 未命中技能，走通用规划 result = general_reasoning(user_request) # 会话结束后，评估本次执行是否值得沉淀 evaluate_and_consolidate(user_request, result) return result其中evaluate_and_consolidate是自演进的关键切入点。执行成功后，系统会评判：这个任务是否高频相似、路径是否稳定、成功率是否可靠。如果满足封装条件，就生成新技能条目写入注册表。这个过程是异步、滞后触发的，不会阻塞当前任务。这里还要注意一个问题：别让Agent每次完成任务后都“自嗨”式地生成技能。技能生成必须经过质量门槛。我的做法是引入一个“置信度评估”的环节——生成后的技能需要经过一段观察期，观察期内它会进入沙盒（shadow mode）状态，可以参与匹配，但执行结果只记录不影响主流程。当观察期内的成功率达到设定标准（比如70%以上），才升级为正式技能，参与正常任务调度。4.5 一个具体例子：从“不会”到“会”假设你的Agent开始时不支持查发票。用户第一次问“我的发票怎么开”，Agent走的是通用推理：先理解需求，发现没有可用工具，只好回复“抱歉，我还不能处理发票相关问题”。会话结束后，系统记录了这次交互，结果状态是失败。后来你接入了发票查询API，把这个能力封装成一个工具，但只是一个原始工具，还不是“技能”。Agent在系统提示词里知道有发票查询接口可以用。下一次用户再问发票，Agent调用接口成功，返回了发票信息。会话结束后系统记录：这是一次成功的“解析需求-调用接口-输出结果”的完整路径。重复了若干次这样的成功路径后，系统检测到这类任务高频出现且步骤高度一致，于是自动生成一个技能条目：触发条件、参数、步骤、评估标准全部就绪。再下一次任务到来，技能命中，Agent不再需要一步步规划，直接按技能流程执行。这就是一个完整的自演进循环：缺工具→补工具→积累成功案例→提炼技能→高效执行。整个过程我没有动过一行权重。5. 常见问题与排查实录5.1 技能库检索总是召回不到正确技能这个问题的出现频率极高。第一反应先查embedding模型对领域术语的表征能力。业务术语往往和通用语义有偏差，比如“退票”和“退款”在业务里是两个完全不同的流程，但通用embedding模型可能认为它俩语义相近，导致匹配混乱。解决办法一：在技能描述的编写时，把同义词、近义词全部写进trigger_keywords；解决办法二：给技能添加标签分类，比如“售后类”“订单类”“发票类”，检索时先过一层规则分类再做向量匹配。我的经验是：纯向量匹配在技能数量超过30-50个时，精度下降非常明显。这时候一定要引入规则层做预过滤。规则层可以是简单的关键词，也可以是基于正则的意图分类。先缩小候选集，再做向量检索，效果会好很多。5.2 技能膨胀：技能越多，Agent反而越迟钝这是一个反直觉但很常见的问题。技能库200个技能，检索延迟飙升，匹配准确率下降。原因是向量检索在高基数候选集上，相互干扰严重。有一次我被这个问题折磨了一周——技能库从40个涨到120个之后，Agent开始频繁用错技能，比如把“优惠券查询”匹配到“退款进度查询”上去，用户投诉明显增加。排查后发现两个问题：一是部分技能的description写得太泛，互相重合；二是没有淘汰机制，大量低质量技能占用了检索空间。解法：对被调用次数少于5次的技能做标记，人工审核是否合并或删除；同时对description做重写，强调每个技能的独特适用场景。我还加了一道“场景白名单”机制：特定场景下只开放部分技能库，比如在“售前咨询”场景下，售后相关的技能不可见。这大幅降低了检索噪声。5.3 上下文窗口永远不够用不改权重的架构里，上下文就是一切。一旦上下文被塞满，Agent的注意力就会被稀释，表现断崖式下跌。这里要区分两种情况：一种是记忆注入过多，把大量的历史记录、技能说明一股脑塞进system prompt；另一种是长期对话过程中对话轮次累积太多。解法各有不同。记忆注入过多，要做的是“检索后压缩”——取回的记忆先经过一个LLM摘要步骤，只保留最核心的几行，再注入上下文;不要 langsung把原始JSON全部塞进去。对话轮次过长，要做的是“对话摘要+关键细节保留”——在上下文快要接近限制时，把前面的对话总结成一段摘要，保留用户需求、承诺事项、正在处理的任务等关键信息，其余细节丢给情景记忆层。我一直建议团队给上下文使用情况加监控指标，把它当成线上服务的资源利用率来管理。上下文不是取之不尽的，它是最贵的“工作记忆”。你要像精算师一样规划每一块空间。5.4 “学错了”：坏技能被固化比没技能更可怕的是错误的技能被固化。有一次我处理过一个案例：Agent在处理“发票重开”请求时，调用了开票接口，但因为参数里传错了发票类型，导致生成了一张错误发票。由于接口返回成功，Agent认为任务完成，系统也把这个流程记成了“成功案例”，后续在观察期内居然还达到了70%的成功率门槛，被升级成了正式技能。等到发现问题的时候，这个坏技能已经被调用了上百次。这个问题怎么防？两个核心手段：结果验证和延迟确认。结果验证要求在每次工具调用后，不只看接口返回码，还要对输出做一层业务校验，比如发票类型是否符合用户要求；延迟确认则是在技能升级前加入人工抽检环节——观察期内的成功案例，按一定比例人工抽查，抽检通过才允许升级。听起来繁琐，但这是防止坏技能扩散的必要代价。6. 边界思考：不改权重能走多远6.1 可塑性架构的天花板在哪说完了好处，也得说限制。不改权重的架构不是万能的，它有明确的天花板。第一个限制是推理能力本身。如果你的LLM本身不擅长复杂的多步推理，那无论你怎么搭配记忆和工具，它的推理上限就摆在那里。系统层可以补充知识和技能，但替代不了模型自身薄弱的基础能力，比如长链条逻辑推理、复杂的数学计算、深度的代码生成。这些问题靠架构层面的优化来补救会非常吃力。第二个限制是记忆和技能的表示能力。记忆层靠向量检索和文本存取，本质上是不精确的。对于高度结构化、强约束的知识，比如复杂的业务规则树、敏感数据访问控制、需要严格因果推导的流程，文本向量就扛不住了。这时候需要外接规则引擎或图数据库来补足，不能只用可塑性架构硬撑。第三个限制是维护成本。技能库、记忆库都会持续增长，需要持续的治理。一个无人看管的自演进系统，一两周内就能长出大量垃圾技能和冗余记忆，反而拖垮Agent表现。可塑性不是“建好就完事”，而是“持续经营”。6.2 什么时候应该“改权重”那改权重什么时候还有必要？我的判断是：当问题出在“模型理解不了语言和领域背景”时，而不是“系统缺少信息和工具”时。比如一个法律领域的Agent，如果模型本身对法言法语的理解不够，无论你怎么注入法条、怎么封装法律工具，它的归纳和推理还是会在浅层打转。这种情况下，对模型做领域适配的微调或预训练，效果立竿见影。一个比较理性的策略是：先系统层，后模型层。先用可塑性架构把记忆、工具、技能全部搭好，把能通过系统解决的问题全部解决。把问题清单过滤一遍，剩下的、确实瓶颈在模型智力本身的，才考虑做模型侧的更新。这样能用最低的成本满足大多数需求，同时把模型更新的频率降到最低，避免频繁动权重带来的灾难性遗忘和运维复杂度。6.3 未来方向：可塑性与模型进化双轨并行从我观察到的趋势来看，可塑性架构不会替代模型训练，而是和它并存。模型的迭代周期会越来越长，但Agent系统的奔跑速度会越来越快——因为真正让Agent“适配业务”的，不是模型参数，而是系统层的持续学习。这有点类似计算机的发展历史：CPU的架构更新是慢周期，但操作系统、应用软件、驱动程序的迭代是快周期。两者各有其位。对于中小团队，我认为价值点和发力点非常清晰：不要一开始就想着训练模型，先把系统层的记忆、技能和自演进闭环做扎实。这是一条成本更低、见效更快、可迭代性更强的路径。等你跑通了这套架构，积累了足够多的业务经验数据，再去反哺模型侧的优化，会顺畅得多。最后分享一个我个人的小习惯：每搭建完一个Agent系统，我会安排一个“复盘日”，专门盯着技能库和记忆库当天新增了多少条目、哪些技能调用了多少次、有没有异常的低成功率。这个习惯帮我及早发现过好几次自演进跑偏的问题。系统会自己长大，但你要是完全放手不管，它可能长成你认不出来的样子。可塑性建立的是“成长的能力”，而不是“免维护的特权”——这把尺子，每一个做Agent的团队都应该握在自己手里。