大多数团队都在契约的错误一端设置了漂移监控（drift monitoring）。他们盯着模型——当供应商发布新的 checkpoint 时发生的性能偏移、提示词重写后的输出分布变化，或是预示着安全过滤器重新调整的拒绝率激增。仪表板非常详尽，告警已接入 PagerDuty，团队也准备好了针对“模型变了”的运维手册。然而，当模型没变而仪表板依然报红时，这些都无济于事，因为真正发生偏移的是你的用户。
用户侧概念漂移是几乎所有评估流水线（eval pipeline）都会忽略的一种问题。你的提示词、模型和工具与发布当天完全一致。你的黄金测试集（golden test set）依然保持 91% 的通过率。但在第一周达到 91% 的提示词，在第三十周的实际效果可能只有 78%，因为底层的输入分布已经发生了变化——用户了解了产品并改变了提问方式、词汇发生了演变、出现了季节性的任务类型、竞争对手重新定义了品类，或者某个热门帖子教给用户一种表达相同意图的新方式。模型和提示词稳住了，契约也稳住了，但契约所针对的那个世界变了。
评估套件显示绿色（通过）。仪表盘显示绿色。一周后，支持团队淹没在同样的投诉中：“助手一直拒绝预订会议。”你打开评估工具（eval harness），重放失败的追踪记录，结果它运行正常。非常完美。每一次都成功。Bug 不在你的评估中，也不在你的模型中。Bug 在于：你的评估所测量的 Agent 和你的客户正在交谈的 Agent 已经不再是同一个系统了，而目前还没有人意识到这一点。
评估与生产环境偏移（Eval-prod drift）是指评估工具加载到 Agent 中的内容与推理栈在请求时实际组装的内容之间，发生的缓慢且难以归因的发散。提示词（Prompts）、固定的模型版本（model pins）、工具架构（tool schemas）、护栏配置（guardrail configs）和功能标志（feature flags）分别通过不同的部署路径流入 Agent —— 代码合并、配置推送、提示词注册中心的回调、实验平台、运行时上线 —— 几乎没有团队拥有一个能够协调这些内容的单一事实来源。因此，评估工具最终测量的是存在于某人 PR 分支中的 Agent 版本，而生产环境运行的则是昨日热修复、上周的功能标志变体，以及工具团队在没告知任何人的情况下推送的任何内容的集合。
这不是一种理论上的失效模式。它是任何运行超过三个月、且配置分布在多个代码库中的 Agent 系统的默认状态。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
