678 篇博文 含有标签「ai-engineering」

你的智能体平台连续一年每季度都达到了 99.9% 的“响应成功率”SLO。但工单量增加了 40%。受智能体引导的用户群体的留存率却在下降。轮值运维感到无聊，产品经理在恐慌，而管理层评审一直在问，为什么仪表盘显示一切正常，而支持队列却显示情况一团糟。仪表盘没有撒谎。它只是衡量了错误的东西 —— 因为编写 SLO 的 SRE 将成功定义为“模型 API 返回了 200”，而这正是遥测系统最初唯一能表达的成功定义。

这是智能体可靠性工程的核心问题：成功的信号不是状态码。它是一种关于智能体是否针对特定任务做了正确事情的判断，而这种判断在请求时是无法获得的，通常在会话时也无法获得，有时只有在几天后，当用户提交工单、修改输出或悄无声息地流失时，才能揭晓。你无法在一个尚不存在的列上标记“200 对比 500”的布尔值。

常见的反应是等待获得基准真相（ground truth）后再宣布 SLO。这是错误的。可靠性工作不会在你构建标注流水线时暂停。正确的做法是针对你明知不完美的代理指标（proxies）编写错误预算，将它们命名为代理指标，设定团队在指标触发时的响应策略，并在产生基准真相后将其回填到计算中。这篇文章将探讨如何在不自欺欺人的情况下做到这一点。

一个编程智能体在凌晨 2 点合并了一项变更，导致客户的生产数据库下线了 90 分钟。一个客户服务智能体在循环被终止前，向外发送了 1.4 万封措辞错误的退款拒绝邮件。一个自主对账工作流对 2800 张卡进行了重复扣款。损失是真实的，审计追踪指向了你的公司，你的财务团队针对六周前续签的网络保险保单提出了理赔。保险公司的回复是一封礼貌的信函，解释说该保单涵盖的是“恶意第三方的未经授权访问”和“对员工的社交工程攻击”——而该智能体是经过身份验证的，其行为是经过授权的，且没有员工被欺骗。理赔被拒。损失只能由你的资产负债表承担。

这并非假设性的极端案例。它是未来 18 个月内最典型的理赔画像，保险业深知这一点。网络保险（Cyber）、职业责任险（E&O）和董事高管责任险（D&O）的保单条款是根据一种威胁模型校准的，在该模型中，泄露的严重程度取决于记录外泄的数量，而事故响应则取决于计费的取证小时数。智能体 AI（Agentic AI）产生的事故并非这种形态。它产生的是一种精算师没有任何基准数据可参考的形态，而保险公司在缺乏精算基准时的第一反应，就是将这种风险敞口完全排除在保单之外。

我上个季度合作的一个团队连续拒绝了三名进入 AI 工程师流程的候选人。三个人都挂在了编程筛选环节 —— 就是那种让你在 35 分钟限时内实现一个滑动窗口去重器的题目。团队随后录用了通过该环节的候选人。四个月后，正是这位工程师交付了一项功能，其 eval（评估集）在 CI（持续集成）中得分高达 92%，但上线后的第二天，支持队列就爆满了。那个 eval 衡量的是与精选测试集的精确匹配。而生产环境的用户提问方式完全不同。招聘小组里没有人问过候选人他们会如何捕捉到这一差距。

这就是 Bug 的轮廓。面试流程筛选的是工作中价值最低的技能，却对最重要的技能视而不见。团队没有“判断力”面试轮次。他们只有编程轮、系统设计轮和行为面试轮，运行的还是 2021 年的那套循环 —— 那套为编写针对稳定库的确定性代码的工程师量身定制的流程。

2025 年 8 月，当 OpenAI 试图从 ChatGPT 中移除 GPT-4o 时，遭遇了强烈的抵制——有组织的标签、付费用户威胁取消订阅、几天内的公开反转——最终迫使公司将其恢复为默认选项，并承诺在未来任何移除之前提供“实质性通知”。替换它的模型在团队关注的每一项基准测试中都表现得更好。但这并不重要。用户已经花了几个月的时间来了解该模型的怪癖，根据其失效模式校准自己的判断，并将它的特定措辞整合进团队从未检测过的工作流中。用“更好的版本”替换它，会让这种校准归零。

这种失效模式是标准的弃用策略手册所未涵盖的。下线一个常规的 SaaS 功能——宣布、迁移、灰度发布移除、退役——假设用户契约是 API 接口。而对于 AI 功能，契约是模型的观察行为：措辞、倾向、失效模式，以及它处理歧义的特定方式。用户在这些行为之上构建了“脚手架”，而这些脚手架大多存在于他们的头脑中、笔记本电脑上以及你的团队从未触及的下游系统中。

团队承诺“在本季度交付 AI 摘要生成器”，在第十周通过了技术门槛，在全员大会上庆祝胜利，然后正式上线。六周后，遥测曲线开始向错误的方向弯曲——无声且缓慢，没有人为其制作仪表盘，因为没有人负责这个曲线的走向。OKR 已经被标记为绿色。下个季度的 OKR 已经围绕新功能的发布起草好了。摘要生成器现在成了某个人的次要维护工作，到季度末评审时，团队开始纳闷，为什么在没有任何明显变化的情况下，该功能的客户满意度下降了 15 分。

这不是团队的缺陷，而是运营模式的缺陷。季度 OKR 是为软件校准的，在这种模式下，一个功能可以被界定范围、构建、交付，然后很大程度上就可以不管它，直到下一次重大版本更新。AI 功能不具备这种特性。它们有一条上线曲线和一条持续曲线，而持续曲线才是大部分价值——以及大部分风险——真正所在。将它们视为带有发布日期的交付物的 OKR 模板，悄悄地产生了一系列在下一个规划周期之前就已失效的演示产品。

一个 AI 功能在周二出现了回归。评估（eval）CI 是绿色的。护栏（guardrail）仪表盘很干净。检索（retrieval）P95 指标正常。模型供应商没有任何故障。然而，支持队列中挤满了用户，他们反映助手“本周感觉变差了”。产品经理（PM）是房间里唯一能说出哪里回归的人，但即便是她也无法告诉你哪个仪表盘能捕获到这个回归。欢迎来到“接缝 Bug”（seam bug）的世界——这种故障中，每个单独的产出物负责人（artifact owner）都能证明自己的部分没问题，但集成后的体验依然是坏的。

这是 AI 功能人员分配方式的必然结果。纸面上的负责人名单看起来很合理：提示词作者负责系统提示词，评估负责人负责离线测试集和 CI 门禁，工具/检索负责人负责函数调用和搜索索引，护栏负责人负责审核和策略过滤器。此外，还有一个模型选择决策，通常游离在这四者之外——有时归属于平台团队，有时归属于最近提交采购单的那个工程师。五个负责人，却没人对“这个功能对用户是否有用”负责。

我认识的一个团队花了六个月的时间，在他们标准的资深工程师面试流程中额外增加了一个“AI 环节”。他们面试了 70 名候选人，录用了 3 名。但这三个人中，没有一个交付的 Agent 能在生产环境平稳度过一个周末。团队将此归咎于人才市场。但人才市场没问题，问题出在面试流程。

标准的工程面试是为这样一套技术栈校准的：正确性可验证，性能可通过基准测试衡量，优秀的工程师是那些能将问题分解为确定性组件，并根据已知规范推导边缘情况的人。那套技术栈依然存在，那些技能依然重要，但预测交付 LLM 产品能力的技能群与此基本是正交的。你的流程是在为错误的职位询问正确的问题。

这是一个结构性问题，而非校准上的微调。在为确定性系统设计的流程中加入 45 分钟的“AI 环节”，并不能筛出 AI 开发者——它筛出的是既擅长经典系统又精通 LLM 的候选人交集，这是一个极其微小的群体。这导致了长达六个月的失败招聘，而大家还在纳闷 AI 工程师都去哪儿了。

针对 Agent 类产品，生产环境下最常见的投诉通常是某种形式的“它忘记了我们刚才说的话”。这种投诉往往出现在第 8 轮、第 15 轮或第 30 轮——绝不会在第 2 轮出现。团队的第一反应往往如出一辙：扩大上下文窗口。但这其实是错误的直觉，因为 Bug 不在模型本身，而在于团队将对话历史视为了终端的滚动回放（scrollback）——追加一行、渲染尾部、满了就截断。实际上，他们不知不觉中构建的是一个读多写少的数据库，具有仅追加写入、热工作集、隐藏在截断规则中的淘汰策略，以及取决于所提问题类型的查询模式。一旦你接受了这一点，整个问题的本质就改变了。

滚动回放模式之所以如此诱人，是因为聊天界面看起来就像一份对话记录。消息向下流动，用户自上而下阅读，而喂给模型的自然方式就是将最新的 N 轮对话拼接到提示词中。这种数据结构感觉是“免费”的：没有 Schema，没有索引，没有查询——只需追加、渲染、重复。在最初的几轮对话中，任何架构都表现良好。模型拥有完整的上下文，费用低廉，演示效果极佳。

每个 LLM 团队最终都会收到主管发来的同一封邮件：“Anthropic 发布了新的 Sonnet。用我们的流量跑一下测试，周五前告诉我是否应该切换。”团队打开生产环境的追踪（trace）存储，调取上个月的请求，并针对新模型排队运行——但在运行三小时后，有人发现工具调用环节的差异评分看起来非常离谱。答案是：没有人以原始形式捕捉工具的响应。追踪记录忠实地记录了模型的“回复”，并存储了每个工具返回内容的一行摘要。回放这些请求并不能回放旧模型实际看到的内容；它回放的是一段被严重压缩的投射。迁移评估并不是在衡量新模型，而是在衡量新模型如何与一个不同的现实对话。

这就是我想讨论的失败模式。大多数生产环境的 LLM 日志都是“以输出为导向”的：它们能很好地回答“模型说了什么？”，但只能模糊地回答“模型看到了什么？”。这种不对称性在你需要针对新模型回放历史数据之前是隐形的——到那时，它就成了整个问题的关键，因为日志记录与实际发送内容之间的差距，正是真实评估与虚假评估之间的差距。

称之为反事实日志（counterfactual logging）：今天就捕捉那些你明天询问“如果用另一个模型处理这个完全相同的请求，它会做什么？”时所需的输入。标准不是“我们记录了请求”，而是“我们可以针对不同的模型重新执行该请求，并确信结果是有意义的”。

一家中型 SaaS 公司的资深工程师在上个季度花了整整两天时间去排查一个部署 bug，结果发现竟然是智能体的错。该智能体读取了一份最后更新于 2023 年的运行手册（Runbook），忠实地执行了第三步，并运行了一个在当前部署工具中已不再存在的命令。这份运行手册在 Wiki 中依然渲染良好——甚至截图也依然清晰可见——但它已经悄然变得对那些无法察觉环境已过时的读者充满敌意。人类作者完全没意识到，这份文档现在已经成了每个新员工的 AI 助手的关键输入。

这就是过去 18 个月里大多数工程团队中发生的悄然转变：内部 Wiki 累积了第二批受众。同样的 Confluence 页面、同样的架构图、同样的“我们如何部署”的 Gist，现在正由两个截然不同的消费者阅读——工程师本人和工程师使用的 AI 助手。这两类读者在完全不同的约束条件下消费同样的文字，并且当文档在编写时仅考虑了第一类读者时，会产生系统性的不同故障模式。

绿色 CI 并不意味着“这个提示词有效”。绿色 CI 的本质是“编写评测的工程师想不出这个提示词会如何出错”。这是两个截然不同的断言，而它们之间的差距正是生产事故的温床。一个评测套件并不是对模型的测量——它是对编写者的冰冷写照。他们的方言、领域知识、资历、偏好的失败模式，以及他们在编写测试用例时恰好使用的模型。根据构造，工程师没想到的测试内容统统未经测试。更糟糕的是：他们会从同一个视角不断扩展套件，因此随着套件的增长，盲点并不会缩小，反而会变得根深蒂固。

这就是评测作者单一化（eval-author monoculture）问题，也是当今 AI 工程中讨论最少、风险最高的可靠性问题。团队痴迷于裁判偏差、位置偏差、冗长偏差、泄漏和污染——但上游偏差其实是最初决定测试用例的人的偏见。其他任何评测误差来源都会被它放大。如果你的套件是由一个人编写的，那么你就拥有了一个带有性格的基准测试，而这种性格正是你的 CI 能够捕获风险的无形天花板。

商业计划书中每一个“如果需要，我们会直接更换供应商”的计划，其预算表中都有提示词改写的支出。但没有一个计划包含评估套件的预算。这就是问题所在。提示词是显性耦合——那是你编写的部分，你可以通过 grep 搜索到的部分，也是一个初级工程师在一个下午就能改写的部分。而评估框架（eval harness）则是隐性耦合，当你真正尝试迁移时，它会吞掉你四分之一的路线图进度。

这种模式在议价能力变得至关重要时就会显现。你的合同到期了。竞争对手发布了一个在你的领域基准测试表现更好的模型。输出 token 的定价发生了变化。你准备让候选模型跑一遍评估套件来做决定，结果不到一天你就发现，你无法信任该框架产生的任何评分，因为框架本身是针对现有供应商编写的。你不是在比较模型，而是在拿一个模型与一个针对另一个模型校准过的测量工具进行比较。