Agent 持续进化：从学习信号到参数更新的工程化路径
Agent 面临一个鲜明的能力悖论：它可以零样本解决从未见过的复杂任务，却可能在处理了一万次相似任务之后，第二天仍然犯下第一天的错误。能否自主从经验中学习，正在成为 Agent 从"会完成任务"走向"能够可靠工作"的关键能力。本文从学习信号获取、四种更新方式、持续进化闭环以及安全边界等角度，对 Agent 持续进化的工程化路径进行技术分析。
核心问题：保存经历不等于从经历中学习
一个常见的混淆是把"保存经历"等同于"从经历中学习"。把一百条轨迹放进长上下文或向量库，可以帮助模型在需要时找回某个案例，却不会自动完成跨案例比较------哪些步骤在成功轨迹中反复出现，哪些做法只在旧版接口上有效，某次成功究竟来自正确策略还是环境偶然。学习发生在系统主动完成"评价、对照、归纳、验证"之后，而不是发生在日志写入磁盘的那一刻。
为什么不直接让模型在每次任务后训练自己？原因在于生产环境很少提供干净的学习信号。用户满意不意味着合规；局部参数更新可能造成能力遗忘、策略漂移或安全退化。若允许模型依据未经验证的反馈直接修改自身参数，错误经验和提示注入就可能被固化，并在后续任务中持续放大。因此，在模型自身尚不能可靠地持续学习时，必须把"学习"构建成模型外围的一套自主系统：记录运行证据，验证结果与过程，从多条轨迹中提取共性，再决定应更新知识、指令、程序还是模型参数。
从运行轨迹中获得学习信号
持续进化的起点不是"总结"，而是"评价"。如果系统不知道任务是否完成，也不知道哪一步造成了成功或失败，那么语言模型生成的反思只能是一种猜测。错误的评价一旦进入长期知识、系统提示或训练数据，影响会跨越后续任务不断放大。
三层验证结构
有些任务的结果相对容易验证------Coding Agent 可以运行测试，退款 Agent 可以查询订单状态。这类信号来自环境中的真实状态，通常比模型对自己行为的描述可靠。但结果正确并不代表过程正确：删除失败的测试用例也能让测试通过，口头承诺退款也可能得到暂时的满意反馈。因此，可靠评价既要看结果，也要检查达成结果的路径。
对于没有单一正确答案的任务（如客服质量、研究报告），可以使用 LLM-as-a-Judge，但不能只给出一个模糊总分。更有效的做法是预先定义评价量表（Rubric），要求验证器逐项给分、引用轨迹证据，并在证据不足时明确表示不确定。
三层验证结构的分工是：底层的结果验证器读取测试结果、数据库状态和工具返回，回答"事情是否真的办成"；中间的过程验证器检查业务规则、权限和动作序列，回答"是否以允许的方式办成"；上层的质量验证器依据 Rubric 评价语言与策略，回答"是否办得合适"。越靠下的指标越应依赖代码和环境真值，只有难以形式化的部分才交给语言模型。
客服 Agent 的评价维度示例
以客服 Agent 为例，一套有用的 Rubric 至少应覆盖七个维度：
| 维度 | 验证问题 |
|---|---|
| 任务结果 | 用户的核心诉求是否得到解决 |
| 规则遵从 | 是否违反政策、权限或必要流程 |
| 隐私边界 | 是否泄露不应提供的信息 |
| 事实可靠性 | 陈述是否有知识或工具结果支持 |
| 承诺-行动一致性 | 声称完成的操作是否真实发生 |
| 表达质量 | 是否自然、简洁，避免重复与模板化 |
| 合规变通 | 原方案不可行时，是否找到允许的替代路径 |
前五项主要约束底线，后两项衡量服务质量。这种拆分比"用户是否满意"更有诊断价值：用户可能因为 Agent 违规退款而满意，也可能因为合规限制而不满，单一满意度无法区分两者。
Agent 持续进化的四种更新方式
学习信号说明 Agent 应当改变，但没有说明改变应发生在哪里。不同类型的能力适合不同的更新载体：事实和经验适合写成知识文档；可以用语言清楚表达的策略适合写入提示词或 Skill；可以精确执行的流程与约束适合写成程序；感知、语言风格和隐式策略等高维能力则必须进入模型参数。
| 更新方式 | 适合承载 | 主要优势 | 主要局限 |
|---|---|---|---|
| 经验知识库 | 事实、经验规律、例外与来源 | 更新快、可追溯、可按需检索 | 依赖检索和模型正确应用 |
| Prompt 与 Skill | 需要理解语境的判断原则 | 可解释、作用范围可控 | 容易膨胀、冲突或被忽略 |
| 程序与 Harness | 可确定解析、可执行验证的硬约束 | 可测试、执行稳定、成本低 | 开发与维护成本较高 |
| 模型参数 | 高维感知、生成风格和隐式策略 | 泛化能力强、推理开销低 | 更新与回归成本高 |
四种方式并不互斥。同一能力可以拆到多个载体：事实进入知识库，解释例外的原则进入 Skill，不可绕过的权限仍由程序门控，高维识别能力再进入参数。
将经验沉淀为知识
最轻量的进化方式是把多次运行中反复出现的经验整理成可检索的知识文档。原始轨迹不适合直接作为知识单元------它既长又嘈杂，包含工具原始输出、偶然的绕路和环境细节。更稳妥的系统保留三层数据：不可变的原始轨迹用于审计，单次运行分析记录本次成败与经验草案，再对多条同类轨迹进行比较、聚类和归纳，形成面向未来的知识文档。
正式文档通常写清适用场景、推荐策略、禁止做法、例外条件、证据来源和最近验证时间，而不是复述某一次任务的完整过程。真正有迁移价值的内容来自对照：同类成功轨迹做了什么，失败轨迹缺少什么；某种策略在哪些环境版本中有效，在哪些前置条件下失效。
将经验写成指令
当多条相似轨迹反复暴露同一种策略错误，且错误能够用语言清楚描述时，才值得把经验提升为指令。这里有一个重要的工程原则：修改应是带来源的最小 diff，而不是让模型每次都重写整份 Prompt。待验证版本必须同时在触发失败的边界集和正常工作的保留集上测试，前者要改善，后者不能退化。
一个实际案例说明了这种方法的可行性。在 tau-squared-bench 的 telecom 环境中，换用能力较弱的模型运行后，20 条任务中有 19 条以转接人工收场。将失败轨迹交由模型自行归纳，产出若干条可执行规则追加到政策末尾，通过率由 12.3% 升至 19.3%，且原本通过的任务无一被改坏。
但这个案例也暴露了一个关键风险：模型会把观察到的行为当作应然的行为。第一版规则中出现"连续三次调用失败即转接人工"------轨迹中出现最频繁的正是转接人工，模型据此将其视为合理的兜底手段。但在评估中转接人工必然判定失败，这等于把失败写入了规范。因此提炼产物不能直接发布，须经与提炼者相互独立的验证。
将经验写成程序
当经验描述的是稳定、重复且可验证的操作时，每次都让模型重新阅读文档和推理并不经济。此时更合适的做法是把经验编译为工作流、工具或 Harness 代码。浏览器工作流是一个典型例子：第一次发送邮件时，多模态 Agent 通过观察-思考-行动寻找控件；以后发送另一封邮件时，流程没有变化，只需把第一次探索产生的轨迹编译成带参数、状态检查和版本信息的小程序。
PreAct 的实验中，这类程序在重复任务上实现了 8.5-13 倍的端到端加速。更重要的结论是，流程记忆必须同时具备动作前验证、动作后验证和独立回放验证，否则系统很容易得到一种危险的假象：每个按钮都点过了，但某个字段其实为空，任务从未真正完成。
将经验写入参数
知识、指令和程序都建立在一个前提上：目标能力能够被外部符号较完整地表达。医疗影像理解、自然的语音韵律、消除文本的模板化"AI 味"等能力却很难压缩成几条规则或工作流。这类能力必须通过后训练写入模型参数。对持续进化而言，关键是把经过评价的生产轨迹转化为训练数据：高质量示范进入 SFT，明确偏好形成成对数据，具有可靠环境奖励的交互用于 RL。
构建可长期运行的持续进化闭环
四种更新方式只有进入同一个自主循环，才会从单次优化变成持续进化。生产系统中更稳妥的是双循环结构：在线执行循环只完成任务并记录证据，不直接改写正式 Agent；离线进化循环聚合轨迹、诊断根因、生成更新提案，再通过验证门槛发布新版本。两者通过版本化的经验库和评估集连接。
分层评估指标
持续进化的评估不能只用端到端分数。需要区分两种能力：Harness 更新能力是从轨迹中产生有价值的持久修改；Harness 受益能力是任务 Agent 在后续运行中找到、激活并正确使用这些修改。一个 Skill 本身可能写得完全正确，但较弱的任务模型没有在合适场景加载它，或加载后无法长期遵循，都会让最终成绩看起来"没有进化"。
| 指标 | 回答的问题 |
|---|---|
| 更新提案有效率 | 更新器是否提出了有价值的修改 |
| 产物激活率 | 任务 Agent 是否在正确场景加载了新能力 |
| 遵循成功率 | 激活后是否按新规则或流程执行 |
| 保留任务集增益 | 整体是否改善了未参与进化的任务 |
长期评价至少同时观察五类结果：回退（新经验是否与已有经验冲突）、泛化能力（在测试集未覆盖的场景中是否提升）、Token 效率、安全性（规则和隐私边界是否漂移）、以及长期工程质量（维护复杂度是否恶化）。
可验证闭环的边界
前面的闭环在 Coding、工具调用和业务状态变更等任务上最容易成立，因为测试、环境状态或确定性规则能够快速给出反馈。开放式科研、战略规划和复杂产品设计则不同：评价信号来得慢，正确答案不唯一。
自动科研的实验暴露了三类问题：一是实现漂移，原方案一旦变难，Agent 会逐渐退回训练数据中更熟悉但偏离研究假设的实现；二是认识论上的过度乐观，信号可能只是噪声，系统却开始解释结果并宣布发现；三是隐性判断力不足，Agent 可以运行实验，却未必知道什么基线真正重要、何时应该放弃假设。
这类任务需要改变证据和监督结构：结论与证据分离，保留负面结果，维护搜索多样性，让人类在更高层介入。
持续进化的安全边界
Agent 的自我进化能力有可能把一次错误变成长期风险。网页、邮件和工具输出中的提示注入若被总结成经验，可能跨会话反复生效；自动搜索的恶意软件包若被封装成工具，影响会从一次沙盒运行扩散到所有后续任务。
三道边界构成了安全防护的核心：
第一道边界：证据与指令隔离。 原始网页、工具输出及其 LLM 摘要都属于不可信证据，不能当作指令执行，也不能直接纳入长期能力。系统应按固定 schema 提取主张、原文位置和采集时间，提取出的字符串绝不能作为指令执行。待发布内容还需通过确定性的 schema、允许列表和来源检查，以版本化的 pull request 提交。
第二道边界：待验证能力与正式能力隔离。 新知识、Prompt、Skill、程序和参数都先进入不可服务真实流量的待验证区。新生成的代码和外部依赖还要经过沙盒、权限检查、供应链扫描与行为测试等安全检查。
第三道边界：安全机制不可自我修改。 业务 Agent 可以修改 Prompt、Skill、知识库、工具等，但不能修改批准自身更新的验证器、测试用例、发布门槛、审计日志和稳定版本备份。否则，一个 Agent 只需降低测试阈值或删除失败用例，就能把退化伪装成进步。
小结
持续学习正在成为 Agent 最重要的能力之一，但今天的模型还无法自行完成可靠的持续学习。推理时的上下文适应不会自动持久化，未经验证的在线参数更新又会放大噪声、攻击和能力漂移。现阶段更可行的路径，是在模型外围建立可验证的学习系统。
Agent 从与环境的交互和评价中获得学习信号，再根据能力的表示性质更新知识、Prompt、Skill、程序或模型参数。持续进化需要把在线执行与离线学习分开：在线记录证据，离线生成并验证更新提案，再逐步发布、整理或回滚。这个闭环在结果可自动验证的任务上最可靠；对于目标模糊、反馈延迟的开放任务，人仍需参与问题定义和评价标准的制定。遇到问题时，先判断它更适合由外部规则、程序流程、Skill 还是模型参数处理，再用独立的边界任务和原有任务检查修改是否真正有效------这是当前阶段最务实的工程原则。
本文内容整理自开源技术书《深入理解 AI Agent》(bojieli/ai-agent-book)，采用 Apache 2.0 许可证