在 AI 工程领域流传着一个隐秘的神话：模型的一次“小幅”升级——比如 claude-x.6 到 claude-x.7，或者 gpt-y.0 到 gpt-y.1，甚至是按日期推进的补丁级快照更新——都应该是无缝替换的。厂商发布的更新日志里谈论着推理能力的提升、更低的延迟以及更好的工具调用。版本号轻轻跳动，没有任何迹象表明这些改动会破坏现有系统。
然后更新上线了。值班频道随即被各种警报点亮：摘要生成器莫名其妙多出了一段以前没有的话；JSON 提取器开始对以前不处理的 Unicode 字符进行转义；Agent 循环在以前只需三次调用就能完成的任务上，现在却触碰到了最大步数限制。从整体上看，评估得分似乎没什么问题，但用户可见的功能却在细微之处出了错。
一个平台团队在周三下午发布了他们的每周智能体 (agent) 版本。内部更新日志写得很尽职：三次系统提示词 (system-prompt) 提交，模型别名从 -0815 快照升级到 -1019，四处工具描述修改，新的评估准则 (eval-rubric) 权重，以及更新后的检索器索引。到了周五，支持队列里出现了 18 个工单，平台团队中没人能把这些工单与变更对应起来。工单 2 和 7 说 “机器人突然拒绝总结私有仓库”。工单 11 说 “输出中的每个代码块现在都带有语言标签，我们的下游解析器因此崩溃了”。工单 15 说 “在长输入下工具 X 的调用频率翻了一番，我们触及了速率限制”。
这些工单没有一个提到更新日志中的任何一行。平台团队的发布说明是一份文件移动清单。集成方的工单是一份行为变更清单。这两份文档互不交集，而信任就在这个鸿沟中流失。
我上个月交流过的一个团队，在四个星期内将一项新的 Agent 功能从 1% 的用户灰度推广到了 50%。聚合质量指标保持在噪声范围内，延迟也保持在 SLA 之内。他们正在准备 100% 全量发布的备忘录时，支持队列突然“起火”了——一个拥有六工具研究工作流的客户，自 10% 灰度阶段以来就一直在接收静默损坏的输出。困难查询（Hard queries）一直存在，均匀地分布在每个分群中，被平均化到了底噪中。直到一个高频用户在大规模使用中撞上了这些问题，大家才发现。
这不是监控失败，而是灰度发布维度的失败。功能标志工具（Feature flag tooling）——包括 LaunchDarkly、Flagsmith、Unleash 和 Cloudflare-Flagship 等所有此类工具——都假设爆炸半径（blast radius）随接触到的人数成比例扩大。对于确定性软件，这在很大程度上是正确的：一个空指针异常（NullPointerException）要么影响所有人，要么谁都不影响，将其暴露给 1% 的用户会将可见的爆炸范围限制在 1%。但对于 AI 功能，爆炸半径并不在“人”这个维度上扩展，而是在“输入”维度上扩展。而几乎没有人会在输入维度上进行灰度发布。
你的 AI 路线图的瓶颈不是 GPU 容量、模型可用性或 Prompt 工程的品味。它是那一两个真正懂得如何构建能发现回归（regression）的评估（eval）的工程师的日程表。每个负责功能的产品经理都在他们的队列中。每一次模型升级都在他们的队列中。每一次群体漂移、每一次 Prompt 修改、每一个“这个评审模型（judge）是否仍然校准”的问题，最终都会进入同一个收件箱。而这位工程师在本季度已经说了三次“不，这还没准备好”，两次被否决，眼睁睁看着回归在生产环境中复合增长，现在正在更新他们的 LinkedIn。
这就是评估瓶颈，大多数组织在被咬到之前都意识不到它的存在。到 2025 年为止，显而易见的工作重点是 AI 工程师——招聘 AI 工程师、发布 AI 功能、迭代 Prompt、更换模型。到了 2026 年第一季度，吞吐量问题下移了一层。将 AI 团队人数翻倍的团队发现，增加更多功能工程师并没有让功能发布得更快，因为每个功能仍然需要一个评估（eval），而负责评估的工程师还是那个人。
我认识的一个团队花了六个月的时间去追踪一个并不存在的回归 (regression)。每一次发布都通过了评估 (eval)。每一次发布都上线了。但每个季度，AI 服务群组的 NPS 都会下降一个点。最终，一名实习生在对黄金数据集 (gold dataset) 进行例行审计时发现，一名早已离职的合同标注员标注了 11% 的数据项，而这些项在团队一直试图修复的一个特定故障模式上，系统性地表现得更加宽松。评估结果显示模型正在变好。但模型并没有变好。评估结果被一个人的校准漂移悄悄地倾斜了，而没有人监督标注员，因为没有人认为标注员是一个威胁面。
这就是评估集毒丸 (eval-set poison pill)。大多数团队将他们的评估集视为一个值得信赖的产物：标签是由人类评分的，数据来自生产环境，而回归仪表盘是组织在发布时一致同意参考的唯一指标。但标注流水线是一个人类供应链，而人类供应链是可以被操纵的。如果不对评估集的输入应用供应链卫生管理，就将其视为真值 (ground truth)，那么你就是在信任一个你无法辩护其来源 (provenance) 的数字。
目前你的系统中有一个损坏的 prompt 影响了约 3% 的流量，但你的仪表盘根本察觉不到它的存在。p99 延迟图表是绿色的。错误率保持平稳。模型调用成功率指标高达四个九。唯一的故障迹象出现在一张平台团队无法复现的客户支持工单中，而等这张工单进入调试环节时，相关的 trace 已经因为采样而被丢弃了。
这不是监控缺失，而是一个分类错误。你正在运行的 APM 是为维度受限（如 endpoint、status_code、region、service）的世界设计的，在这种情况下，增加一个标签的成本最多只是增加几个新的时间序列。LLM 工作负载完全不符合这种模式。真正有趣的维度是用户的 prompt、检索到的 context ID、工具调用序列、模型版本、prompt 模板版本、租户（tenant）、语言区域（locale），以及请求所属的 eval bucket。每一个维度都是高基数（high-cardinality）的，只要你用其中任何一个子集来标记 span，指标存储瞬间就会爆炸。
在你的技术栈中，每一个设计良好的 HTTP API 都会返回分页结果。没有人会把一百万行数据加载进内存并祈祷一切顺利。然而，你的智能体（agent）所调用的工具却会返回整个列表，而智能体也会尽职尽责地阅读它，因为函数签名写的是 list_orders() -> Order[]，且智能体不像人类用户那样拥有“滚动并加载更多”的协议。
智能体在原本可以跳过的行上浪费了 Token。拥有 50K 记录的长尾客户遇到了中等规模客户从未见过的上下文窗口失败。工具作者无法从追踪（trace）中判断智能体是需要所有这些行，还是仅仅因为无法请求更少的数据。而且，在你评估套件的某个地方，原本会标记这种退化的回归测试从未运行，因为每个测试固件（test fixture）的记录都少于 100 条。
分页不是一种 UI 交互功能。它是一种负载卸载（load-shedding）原语 —— 而在没有分页的情况下使用工具的智能体，正在重新犯下你们公司的 API 设计师们花了十年时间才学会避免的每一个 SELECT * FROM orders 错误。
事故报告读起来就像一个单元测试的恐怖故事。一次 Prompt 编辑作为“前置说明清理（preamble cleanup）”的一部分，删除了一段五行的安全条款。测试套件中的每个 Eval（评估）都通过了。每个 Judge（裁判）评分都保持在容差范围内。两周后，一个面向客户的助手产生了一个本该被拒绝的响应，这种响应会在深夜 11 pm 触发信任与安全（Trust & Safety）页面的报警。复盘将这次回归追溯到了一个 PR 中的单处删除，而当时没有任何人标记它，因为负责捕捉回归的套件对安全条款是否存在没有意见——它只对模型在套件记得询问的情况下的表现有意见。
这就是行为评估（behavioral evals）与结构正确性之间的鸿沟。Eval 衡量的是模型生成的内容；它们不衡量 Prompt 本身是什么。而 Prompt 就像代码一样，有一个独立于行为而存在的结构层——必须存在的章节、必须解析的引用、必须插值的变量、必须遵守的长度预算、以及绝不能出现的弃用标识符。当结构层断裂时，行为表现通常会在一段时间内保持绿色，直到生产环境中的某个边缘情况将故障暴露为事故。
评估套件在凌晨 2 点运行。流量很低。缓存是冷的，但队列是空的。供应商的连续批处理程序有空闲插槽，并将以接近其 TTFT（首 Token 延迟）底线的水平处理每个请求。延迟分布很紧凑，评测模型分数稳定，仪表盘显示一片绿色。团队发布上线。
六个小时后，太平洋时间上午 8 点，同样的 Prompt 在美国早高峰期间进入生产环境。p95 延迟是评估报告的 2.4 倍。相当一部分请求从一个供应商那里收到了 529 错误，并回退到另一个供应商的较小路由层级。流式传输的节奏更加断断续续。评测模型（当天晚上对生产环境追踪样本进行重新运行）给出的中位数得分比凌晨 2 点给出的相同 Prompt 的得分低了半分。代码库没有变化。Prompt 没有变化。只是挂钟时间变了。
必须意识到的架构真相是：LLM 调用不是其输入 Token 的纯函数。它是一个随机分布式系统调用，其输入包括挂钟时间、供应商集群的负载、Prompt 缓存的状态、当前解码批次的大小，以及供应商负载均衡器在你的请求到达的那一毫秒所做出的路由决策。在凌晨 2 点运行评估的团队，是在一种用户永远无法体验到的条件下校准仪器。
一个功能发布时通过率为 92%。发布演示稿（Launch deck）为此庆祝。12 个月后，同样的功能通过率降到了 78% —— 没有事件报告，没有部署失败，没有任何单一的变更可以追责，仅仅是无人负责监控的缓慢侵蚀。团队将其归咎于“幻觉”或“用户行为转变”，选了一名初级工程师去调查，并设定了一个“提高质量”的季度 OKR。OKR 没能达成。该功能上线了一个道歉对话框，告诉用户 AI 有时会犯错。六个月后，它被弃用，取而代之的是一个发布时通过率为 91% 的新版本，循环再次开始。
这并非运气不好。这是 AI 功能运行的“第二时钟”，一个在发布时没有人会在日程表上标注的时钟。传统软件也有功能衰减 —— 依赖漂移、代码库腐化、缓慢积累的半成品重构 —— 但这些衰减是发生在工程团队已经理解并预留预算的时钟上。AI 功能具备上述所有问题，此外还有一系列传统摊销假设无法建模的并行衰减源：模型弃用、厂商权重轮换、用户输入的分布偏移、不断叠加的 Prompt 补丁、评估器（Judge）校准偏移，以及不再能代表生产流量现状的评估集的悄然老化。
在下一个 AI 功能发布之前，而不是之后，必须落地的架构认知是：AI 功能具有非零的基础维护成本。功能在发布时并没有“完成”。它已经进入了一个无法逃避的维护周期，而那些没有为这个周期预留预算的团队，终将通过惨痛的方式发现这一点。
团队承诺“在本季度交付 AI 摘要生成器”，在第十周通过了技术门槛，在全员大会上庆祝胜利，然后正式上线。六周后，遥测曲线开始向错误的方向弯曲——无声且缓慢，没有人为其制作仪表盘，因为没有人负责这个曲线的走向。OKR 已经被标记为绿色。下个季度的 OKR 已经围绕新功能的发布起草好了。摘要生成器现在成了某个人的次要维护工作，到季度末评审时，团队开始纳闷，为什么在没有任何明显变化的情况下，该功能的客户满意度下降了 15 分。
这不是团队的缺陷，而是运营模式的缺陷。季度 OKR 是为软件校准的，在这种模式下，一个功能可以被界定范围、构建、交付，然后很大程度上就可以不管它，直到下一次重大版本更新。AI 功能不具备这种特性。它们有一条上线曲线和一条持续曲线，而持续曲线才是大部分价值——以及大部分风险——真正所在。将它们视为带有发布日期的交付物的 OKR 模板，悄悄地产生了一系列在下一个规划周期之前就已失效的演示产品。
页面告警在凌晨 2:47 响起。智能体（Agent）正向客户支持工单发送语气错误的回复，延迟仪表盘显示平稳，错误率正常，而且由于过去 12 小时内没有进行过任何部署，没有任何东西可以回滚。值班工程师打开了运维手册（runbook），滑过了“重启工作线程池”和“扩容队列”，直到翻到底部，也没发现任何能与眼前告警相匹配的内容。他们在凌晨 3:04 开始阅读系统提示词（system prompt）。到凌晨 3:31，他们仍在阅读。
这是全新的故障形态。那些为“高延迟意味着重启 Pod，5xx 错误增加意味着回滚部署，队列深度增加意味着扩容工作线程池”而设计的轮值制度，已无法应对此类问题。第一直觉——回滚部署——是错误的，因为根本没有部署：模型在版本化别名（versioned alias）后静默升级了，第三方工具的响应结构发生了偏移，提示词版本在不同区域间出现了偏差，或者评估集在几周前就已失效，而回归问题一直在持续累积。告警是真实的。运维手册却保持沉默。AI 值班现在已经成为一门独立的学科，试图将其强行套入现有的轮值体系，只会产生那种在告警发生时，所有人第一步都是在通话中相对无言、第一次开始阅读提示词的方案。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
