为什么 AI 代理通过 QA 测试却仍然在生产中失败

持续学习正在成为一种工程学科，用于在部署后改进代理，而不会破坏已经工作的内容。

AI 代理可以通过每个预发布评估，但仍然可能在生产中一周后失败。这不是一个矛盾。评估集反映了团队在发布前知道要测试的内容。生产是缺失的案例出现的地方：奇怪的短语，缺失的上下文，工具边缘情况，急躁的用户，冲突的政策和工作流程，没有任何基准设计师想象过的。

代理不断被用户纠正。它让用户失望。然后会话结束，日志被存储，下一个用户遇到基本上相同的系统。

这是为什么持续学习成为代理工程的核心。它不是一个产品的功能。它是一类方法，用于从经验中改进代理，同时保留已经工作的内容。经典的 持续学习研究将问题定义为随着时间的推移而学习，没有灾难性的遗忘。代理使得问题变得更广泛。可能发生变化的东西可能是一个模型，但也可能是一个提示，一个工具，一个技能，一个工作流程或内存。

这种区别很重要，因为大多数代理失败并不是通过首先更新模型来解决的。

微调反射太狭窄

当团队谈论如何使 AI 系统变得更好时，缺省计划通常听起来像这样：收集失败，标记更好的答案，微调模型。这种直觉是可以理解的。监督微调， 直接偏好优化， 群体相对政策优化，以及参数高效的方法，如 LoRA，是当模型本身需要改变时有用的工具。

但是，许多生产失败并不是模型权重失败。它们是系统失败。

代理可能依赖于过时的内存，跳过一个必需的确认，调用一个工具带有错误的参数，或者将一个案例路由到错误的工作流程。通常，问题不是基础模型的能力。它是上下文，内存，工具接口或工作流程包围着它。

现代代理有多个层次。模型推理和生成。包围它的工具定义了提示，工具，技能，代码，路由和工作流程。内存携带事实和学习的程序跨会话。持续学习是决定哪个层次应该改变，改变可以多小，以及如何验证改变实际上有帮助的学科。

有时正确的修复是一个内存写入。有时它是一个提示编辑。有时它是一个工具包装，一个路由规则或一个工作流程补丁。微调应该保持可用，但它不应该是每个失败的第一个答案。

基准是有用的，但生产很少给你一个

有关于优化代理工具本身的令人兴奋的工作。方法如 GEPA， Meta-Harness，以及相关的提示或工作流程优化方法将代理视为可以被改变和测试的系统。它们可以提出编辑提示或其他工具组件的候选项，运行候选项，并保留评分更好的版本。

这是正确的方向。它将改进从“更新权重”的狭窄框架转移到“改进代理”的更广泛的框架中。

但是，有一个问题：这些方法通常假设一个基准。它们需要一个可以重复运行的任务和一个评估器来判断候选项 A 是否比候选项 B 更好。没有它，优化就变成了带有更好的工具的猜测。

这不是大多数团队在生产中拥有的东西。

他们拥有的日志。他们有跟踪，用户纠正，支持票， thumbs-down 事件，升级注释和偶尔的专家反馈。这些信号是有价值的，但它们还不是一个基准。它们告诉你发生了什么。它们不自动告诉你如何重放它，什么样的成功应该是什么样的，或者如何评分一个提出的修复。

这就是许多持续学习努力停滞的地方。团队有经验，但还没有学习环境。

日志不是教训

生产日志记录了一个交互的路径。用户要求航班。代理搜索。用户说日期是错误的。这是失败的证据，但这还不够来学习。

日志不定义反事实。代理应该要求确认吗？它应该从早期上下文中推断日期吗？它应该调用一个不同的工具吗？它应该拒绝继续，直到模糊性得到解决吗？人类可能在阅读跟踪后知道答案，但系统不会免费获得这种结构。

为了使持续学习有效，原始失败必须转化为可以重放的东西。这意味着代理可以再次面对的任务，用户或模拟器可以重现相关模式，工具代理可以调用，以及评估器可以定义成功。评估器可能会检查最终答案，工具调用，策略边界，延迟，成本或所有这些。

这是工作的不太可见的部分，但它是使改进变得真实的部分。一旦失败成为可重放的环境，人们就可以提出一个具体的问题：提出的改变实际上是否修复了行为？

没有这一步，团队基本上只是从记忆中修补。

David Silver 和 Richard Sutton 描述了一个即将到来的 经验时代，在那里，代理主要从与世界的交互中学习，而不是从静态的人类数据中学习。对于企业代理来说，这个愿景取决于将混乱的生产经验转化为可以重放，评分和重用的环境。

经验本身是不够的。它必须变得可测试。

回归是隐藏的成本

即使失败变得可测试，仍然存在最困难的部分：在不破坏其他东西的情况下修复它。

任何人都曾经维护过一个复杂的代理，都见过这种模式。你添加一个指令，使代理升级攻击性的退款请求。现在它升级了应该快速处理的常规退款。你减少了一个工作流程中的工具调用。现在另一个工作流程跳过了一个必需的检查。你修复了一个过时的内存。现在代理过度概括了对不同产品线的更正。

每个补丁在本地都有意义。系统仍然在全球范围内漂移。

这是代理版本的灾难性遗忘。通常，神经网络中的这个短语指的是新的训练覆盖了旧的能力。在代理中，失败更广泛，通常更难以看到。忘记可能发生在提示，工具，内存，路由和工作流程中。它表现为一个用户说：“这曾经有效。”

这就是为什么回归控制不能只是最终审查步骤。它必须在学习循环本身内。

目标不是简单地最大化最新失败的性能。目标是改进新案例，同时保留旧案例。每个有效的修复都应该成为代理日益增长的必须保持工作的行为的记忆。实际上，这意味着旧的失败成为回归测试。代理的历史成为一个约束，而不仅仅是一个存档。

这就是持续学习变得更像严肃的软件工程，而不是提示调整的地方。改变不是因为听起来更好。它是因为它改进了一个测量的行为，并且不会使系统已经获得的行为发生回归。

什么是实用的持续学习要求

生产就绪的持续学习循环需要四个属性。

首先，失败必须是可重放的。一次性失败是一个轶事。可重放的环境是一个测试。直到代理可以再次面对相同的模式，否则无法证明修复有效。

第二，诊断必须是整体的。修复可能属于模型，但也可能属于内存，提示，工具层或工作流程。最佳修复通常是解释失败的最小耐用变化。

第三， 学习必须是终身的。代理不应该通过悄悄地撤销上周辛苦获得的行为来改进本周的行为。以前的成功应该在优化期间成为约束，而不是部署后出现的惊喜。

第四，循环必须是高效的。如果每次改进都需要一个季度的重新训练项目，系统将永远无法跟上生产。循环必须首先尝试廉价的修复，仅在需要时升级，并将验证保持在更改附近。

这并不意味着代理应该盲目地更新自己。它的意思是相反的。改进应该变得可测量的。每个改变都应该有一个测试，一个之前和之后的评分，以及一个回归检查。

这就是将持续学习从模糊的愿望转变为工程学科的东西。

代理的未来不会仅仅由更大的上下文窗口，更强大的基础模型或更多工具来定义。这些都会很重要。但更重要的问题是部署后会发生什么。

当代理明天失败时，系统能否将该失败转化为测试？能否将修复路由到正确的层？能否证明修复有效？能否证明没有其他东西破坏了它？

如果答案是没有，代理并没有真正地从生产中学习。它正在积累风险。

下一个重要的代理将做得更好。他们将会复合。