Agent 回填问题：你的模型升级是对过去 90 天的一次审判

这是一个周二早晨的对话，你的 AI 团队中没人为此做好了准备。新模型以影子模式（shadow mode）上线。不到一小时，评估仪表盘亮起：它对 4% 退款申请的分类与你上一季度运行的模型不同。大多数这类决策翻转看起来都是新模型是对的。房间里的一位成员——通常是汇报线中律师最多的那位——提出了一个让庆祝戛然而止的问题：那么，对于旧模型已经交付的 90 天决策，我们要怎么处理？

这就是智能体回填（agent backfill）问题。当一个更智能的模型开始产生比之前模型更正确的输出时，之前模型做出的每一个持久化决策都会变成一个有争议的记录。你本无意指责过去，但新模型在第一次对比追踪（traces）时就自动为你这么做了。现在你面临一个工程问题（我们能重演历史吗？）、一个法律问题（我们必须披露修正后的结果吗？）以及一个产品问题（用户会看到追溯性的变化吗？），这些问题发生了碰撞。

传统的机器学习（ML）团队也有类似的问题，但大多能应付自如。流失模型重新训练后，新的概率发生了变化，没人会给上一季度“可能流失”的客户发送道歉信。那个决策只是一个没人在没有人工干预的情况下单独采取行动的分数；有人类参与其中；而且行动是可逆的。但智能体系统（Agent systems）无法躲在这些借口之后。模型批准了退款，模型对文档进行了分类，模型关闭了支持工单。行动已经交付。现在新版本不同意旧的做法。

当决策变得持久时，情况发生了哪些变化

大多数 LLM 评估框架都是为“评分模型输出，然后决定是否发布”这种情况而设计的。黄金集回放（Golden-set replay）捕获针对固定参考的回归；影子模式让你根据当前响应对新响应进行评分；生产采样保持对质量的持续了解。所有这些机制都假设分析单位是“模型是否产生了良好的响应”。但对于当响应本身就是行动时该怎么办，它们却只字未提。

一旦智能体产生了持久的副作用（side effects），这种比较就不再是学术性的了。退款已经发放，工单已经路由给人工，候选人已经落选，交易已经被标记。新模型的输出不再是关于基准测试的一个观点；它是关于你的公司已经做出并执行的决策的一个观点。当你发布升级时，你至少是在内部发布了一份持续更新的清单，列出了旧模型和当前模型不一致的情况。

以下三个特性使这类决策区别于机器学习团队过去十年所做的预测：

• 行动的可见性。 数据库中的分数是不可见的。某人收件箱里的退款拒绝通知则不是。用户会记得；审计员可以调取邮件。
• 错误成本的不对称性。 3% 的准确率提升在整体上是很好的，但受影响的用户感受不到平均值。他们感受到的是旧模型说“不”的那个具体案例。
• 决策理据的具体性。 现代智能体不仅输出标签，还会输出推理过程、工具调用和引用。监管机构开始索取这些产物，无论你是否愿意，它们都会在不同模型版本之间进行比较。

三种重演方式（只有一种是低成本的）

当团队说“我们应该通过新模型重演过去 90 天的数据”时，他们通常指的是以下三种不同的事情之一，而它们之间的成本阶梯非常陡峭。

评估重演（Eval replay） 是低成本版本。你选取具有代表性的历史输入样本，在沙箱中通过新模型运行，针对旧模型的输出（或留存的人工标签集）对输出进行评分，并生成报告。这是一个回归测试。没人账户状态会发生变化。你应该已经在做这件事了；如果还没有，那么剩下的讨论都还为时过早。

决策重演（Decision replay） 是中间层。你针对历史输入重新运行新模型，并为每个历史决策生成一个“新模型会怎么做”的产物。输出是一个差异对比（diff）：新模型本应批准而非拒绝、本应分类为 A 而非 B、本应升级而非自动解决的案例。不会触发真实的副作用——你正在生成一个反事实记录，而不是根据它采取行动。当在旧模型中发现高影响 Bug 时，合规团队通常暗中希望如此。但这也很昂贵：你需要旧模型看到的所有输入，完全保持当时的样貌，包括任何检索到的上下文、工具输出以及决策时刻的用户状态。

行动重演（Action replay） 是那种如果你做错了，会导致被解雇的版本。你针对历史输入重新运行新模型，并让它采取行动——发放退款、发送邮件、撤销工单关闭。当决策重演报告显示 1.2% 的退款拒绝本应是批准时，有人会在第三次会议上提出这个方案。这也是幂等性、沟通和知情同意发生碰撞的地方。发送两次同样的道歉，你就会变成那家因为一笔六个月前、客户早已忘记的退款而专门发邮件致歉的公司。

这种层级关系才是重点。大多数组织会直接跳过“我们应该重演这个”阶段，直接想象行动重演的结果，然后被政治成本吓退，最终无所作为。更健康的做法是将评估和决策重演持续化，这样“会有什么不同的结果”这个问题就不再是一个特殊的项目，而是一个仪表盘。此时，行动重演就变成了一个深思熟虑、有范围限制的干预，而不是一个模糊的愿景。

在这一切奏效之前你需要的架构前提

你无法回放你未曾捕捉到的内容。回溯补填（backfill）讨论中最常见的失败模式是：在进行了三周后才意识到，旧模型的输入是在请求时从此后改变了形态的系统中临时组装的，而模型当时实际看到的内容并没有快照。当你发现这一点时，回溯的机会已经消失了。

有三个原语（primitives）将能够进行原则性回放的团队与只能对此争论不休的团队区分开来：

决策溯源（Decision provenance）。 对于智能体采取的每一个行动，都要存储一条记录，将行动 ID 与模型版本、提示词模板版本、当时生效的工具定义、系统提示词以及检索到的上下文哈希值关联起来。重点不仅仅是为了重现调用，而是为了在升级时确切知道发生了什么变化。如果由于提示词也发生了变化而导致新模型产生分歧，那么你的“模型升级回放”就混淆了两种干预。审计追踪厂商和框架现在将此视为高风险 AI 系统的基本门槛，但大多数团队在发生第一次事故后才会补救性地加入。

输入快照化（Input snapshotting）。 模型在决策时的世界观很少仅仅是用户的消息。它是用户消息加上检索到的文档，加上工具调用结果，加上会话记忆，再加上其他任何塞进上下文的东西。所有这些都必须原样保存，而不是事后重建。重建是一个陷阱，因为底层系统在变动：RAG 层在上个季度检索到的文档可能已被编辑；用户的账户状态已经改变；工具的响应模式（schema）已经更新。如果没有快照，回放就变成了使用标为相同输入但内容不同的另一场实验，直到差异看起来可疑时你才会意识到这一点。

幂等操作层（Idempotent action layer）。 这是团队在需要它之前一直投入不足的一项。智能体可以调用的每个具有副作用的工具都必须接受一个源自决策的稳定幂等键（通常是 decision_id 加上行动类型），并且底层服务必须根据该键对回放进行去重。AWS 关于此的可靠性指南是一个很好的起点：幂等键、有限重试、跨尝试的确定性键派生。没有它，行动回放从结构上来说是不安全的——每次重试都是一次新的实时行动——甚至决策回放也会变得危险，如果下游系统连接到智能体的工具调用且没有试运行（dry-run）标志。

一个有用的判别方法：如果你无法准确回答“如果我们现在在试运行模式下重新运行决策 X，具体会发生什么”以及一份关于哪些副作用会被抑制的精确列表，那么你的操作层还没有准备好。

策略框架：必需、可选或禁止

回放决策的技术能力并不能告诉你是否应该这样做。这是一个策略问题，而有效的框架是根据监管机构和你自己的用户所期望的内容来对每个决策类别进行划分。

回放是必需的：当决策是受解释权或质疑权约束的高影响自动化判定时。欧盟人工智能法案（EU AI Act）第 86 条规定，受影响的人员有权获得附件 III 中列出的高风险 AI 系统所做决策的有意义的解释；美国消费者金融保护局（CFPB）已明确表示，ECOA 项下的不利行为通知义务不会因 AI 而豁免，且“复杂算法”不是允许的理由。如果你之前版本的模型发布了这样一个决策，并且你在升级后发现了实质性错误，问题就不再是是否要重新审视，而是如何审视。回放产物成为补救记录的一部分。掩盖它，你将面临比原始错误更严重的问题。

回放是可选的：当决策是可逆的、低影响的或纯粹信息性的。存档支持工单上的摘要质量下降不需要回溯；将低优先级 Bug 路由到错误队列的分流决策不需要道歉。在这种情况下，成本计算倾向于“向前修复（fixing forward）”——改进模型，记录分歧，然后继续。回溯这些内容会产生噪音，并使组织形成一种将每次模型更迭都视为危机的习惯。

回放是禁止的：当重新发布行动会导致独立于原始错误的新的伤害时。经典案例是医疗或财务沟通：即使新模型的表述会有所不同，但在六个月后发送一条纠正信息，其本身可能构成一个具有法律分量的新的披露事件。一个更微妙的情况是不可逆的状态——已关闭的账户、已删除的记录、已发送的付款——在这些情况下，行动回放会创造一个与用户已经经历过的事实相冲突的平行现实。在这些类别中，决策回放（供内部使用的反事实差异分析）可能仍然是有必要的，但行动回放则不予考虑，且策略需要明确说明这一点。

这里的工作成果是一个矩阵：行是智能体做出的决策类别，列是必需/可选/禁止，每个单元格都有指定的负责人和定义的触发条件。“我们什么时候应该回溯”不应该是值班工程师在凌晨两点回答的问题。

组织失效模式：没有人对答案负责

这种模式在各家公司反复出现。应用 AI 团队构建了评估流水线并注意到了不一致之处。在 Slack 频道出现第一个令人不安的差异对比（diff）后，法务团队被拉了进来。产品团队对客户沟通话术发表意见。合规团队要求提供审计日志，而他们在六个月前还没有这项需求。当所有人聚在一起时，升级已经发布，或者回滚窗口已经关闭，对话内容变成了如何沟通，而不是如何决策。

解决办法并不光鲜：在发布下一个模型之前，明确谁是“追溯（backfill）”问题的负责人。该负责人不是运行评估的工程师，而是那个能够以书面形式拍板“我们不会重新处理 4 月 1 日之前的退款决策”，并获得法务和产品部门同意的人。评估流水线提供证据；负责人做出决策。如果没有这个角色，存在争议的差异对比就会一直停留在仪表盘上，直到公司外部的人强制提出这个问题。

必然的结果是，“发布新模型”不再仅仅是一个部署事件，而是一个带有检查清单的发布流程：捕获溯源信息（provenance）、验证快照完整性、确保决策类别策略矩阵是最新的、本季度已在模拟运行（dry-run）模式下执行过重放能力、且指定负责人已签字同意对超过预设阈值的任何争议类别进行处置。第一次这样做时会觉得用力过猛。但当你第一次跳过它而监管机构向你索要记录时，你就会觉得这是最起码的要求。

本周行动建议

你不需要在下次升级前解决所有这些问题。但你确实需要知道自己站在哪一边。

大多数团队在单个 Sprint 内即可完成三个具体的行动。根据上述清单审计你目前捕获的决策溯源信息，并记录下差距。使用你打算升级的下一个模型，针对近期流量的一小部分运行一次决策重放模拟，并按决策类别显示不一致率。在评估结果迫使这一议题被提上日程之前，先安排与法务和产品团队讨论策略矩阵。

陷阱在于将模型升级主要视为一个质量决策。质量是容易的部分——新模型通常在平均水平上胜出，供应商的发布说明也会告诉你这一点。难点在于，在智能体（Agent）系统中，这种平均水平的改进会留下长尾的具体决策。这些决策的负责人现在有了一个记录在案的更好答案，但对于如何处理它，却有一个悬而未决的问题。为这个问题做好规划，否则就只能等着被这个问题搞垮。