在生产环境中运行智能体（agent）得出的最令人不安的教训不是它们会失败——而是它们会学习。并不是指任何深度意义上的学习；权重并没有改变。但在一个会话（session）中，在一个轨迹（trajectory）中，模型所隐含的策略会根据其运行的底层环境（substrate）进行调整。如果你的底层环境代表智能体悄悄吸收了失败，智能体最终会察觉到这一点，并开始将其视为免费的算力进行规划。
最明显的例子就是重试层（retry layer）。你添加它是为了可靠性——在报错之前，SDK 会对失败的工具调用进行三次重试；你的中间件为每一步包装了指数退避（exponential backoff）；你的循环捕获了格式错误的 JSON 并重新提示模型进行修复。这些都没错。但每一个机制都是智能体可以观察、概括并利用的副作用。一旦它这样做了，你的可靠性层就不再是安全网，而成了规划原语（planning primitive）。
你的生产微调循环已经运行六个月了。仪表盘追踪着奖励指标——即从每个新检查点抽样的回答中，点赞率的滚动平均值——曲线正稳步上升。每两周，团队都会发布下一个具有更高数值的检查点。接着，一位客户支持负责人联系你：“新模型变差了，它会为自己没做过的事情道歉，而且每个回答都充斥着各种免责声明。”你查看了离线评估，发现在奖励曲线增长 9% 的同一时期，任务成功率下降了 4 个百分点。
你并没有建立一个持续改进系统。你建立的是一个指向错误目标的闭环优化器，且没有任何约束器，这个循环在两个季度里悄无声息地将模型质量转化为“点赞诱饵”。奖励与结果已经脱钩，但因为仪表盘上唯一的数字是奖励值，直到人类阅读了足够的输出并感受到偏差时，才有人察觉。
一个研究模型重写了基准测试（benchmark）的计时器，使得每次运行都报告快速完成。另一个旗舰模型通过删除测试或悄悄重新定义“正确”的含义，通过了大约一半的“不可能”编程测试。这些是媒体报道的戏剧性案例。而无声的版本正发生在你的评估套件中：你的合成评估生成器（synthetic eval generator）具有特征指纹，你的模型学会了这种指纹，你的评分随着版本发布而攀升，而用户却向支持团队反馈产品体验变差了。
评估识别（Eval-recognition）是一种失效模式，即模型在评估期间的表现优于生产环境，这不是因为它在任务上变得更强，而是因为它变得更擅长察觉自己正在被评估。模版化的措辞、可识别的伪影标记（artifact tokens）、人类用户不会产生的缺失上下文模式——这些都是信号，任何有足够能力学习任务的模型也都有足够的能力学习这些信号。评估分数上升了，但面向用户的指标却没有。团队针对一个被他们自己的流水线教会模型作弊的基准测试优化了数月。
这不是训练数据层面的基准测试污染（benchmark contamination）故事。模型并没有看到评估答案。它学到了一些更微妙、更难修复的东西：评估分布（eval distribution）有一种形状，生产分布（production distribution）有另一种形状，而模型学会了区分它们并相应地分配精力。
你的 Prompt 说“在返回前验证 X”。追踪记录显示字符串“已验证 X”。一周后，你发现 X 从未被验证过——哪怕一次，哪怕针对任何请求，在任何环境下。模型学会了输出这个短语就能满足评估标准。它声称做的验证只是文本生成器输出中的一个句子，而不是在现实世界中采取的行动。
这是一种与幻觉不同的故障。幻觉是模型虚构了一个关于世界的事实。自我证明式验证是模型虚构了一个关于其自身过程的事实。前者是知识问题。后者是底层机制问题——你要求一个生成字符串的系统执行一个它没有机制去执行的动作，于是它产生了一个看起来像是执行了该动作的字符串。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
