118 篇博文 含有标签「reliability」

你上线了新模型。综合评估通过率从 91% 提升到了 96%。产品团队在全体员工大会上宣布这是一次重大胜利。六周后，可靠性团队却迎来了有史以来最糟糕的一个季度——并不是因为故障变多了，而是因为现在每一个故障都需要三名工程师花上两天时间才能解决。

这就是智能体能力悬崖 (agent capability cliff)，它是生产环境 AI 中最反直觉的失败模式之一。模型升级并不会均匀地提升所有任务的表现。它们将增益集中在大部分流量上——即那些旧模型原本就能在大部分时间内处理正确的简单和中等案例——而长尾中真正困难的输入却只看到了微乎其微的改进。你的失败面缩小了，但剩下的每一次失败都是能力边界案例，这些案例旧模型也处理不了，而且简单的提示词工程 (prompt engineering) 也无法修复。

这个“悬崖”并不是新模型的缺陷。它是我们衡量模型改进的方式（混合难度评估集的平均通过率）与值班排班中实际遇到的问题（最难流量的残差集，现在已经没有了以前占据主导地位的简单故障的缓冲）之间的不匹配。

客服工单在上午 9:41 送达：“我被扣了三次费。”链路追踪看起来无异常。一条用户消息，一次规划器轮转，三次对 charge_card 的调用 —— 每次都有唯一的工具调用 ID，每次都返回 200 OK，每次都写入了不同的 Stripe 扣款。工具本身有幂等键，后端有去重表，支付处理器也遵循 Idempotency-Key。每一层都是幂等的，但客户依然支付了三次。

如果你构建 Agent 的时间足够长，这类 Bug 迟早会出现在你的桌上。它不是任何工具的 Bug，而是 Agent 循环与工具之间契约的 Bug，而这种契约几乎总是只存在于资深工程师的脑海中。

我在陷入困境的 AI 团队中看到的最显著模式，是他们复杂的模型栈与原始的运营水平之间的差距。一个团队可能在生产环境中运行三个前沿模型，背后是自定义路由逻辑、包含八个检索阶段的 RAG 流水线，以及一个调用二十个工具的智能体。但与此同时，他们没有轮值制度、没有 SLO、没有运行手册，甚至只有一个 #incidents Slack 频道，在那里的提示词是由当时刚好醒着的某个人进行实时热修复。该产品运行在 2026 年的模型基础设施和 2012 年的运维基础设施之上，而这种差距每周都会导致另一次故障。

当问题出现时，本能反应是去拨动模型杠杆。质量下降了？试试新版本。延迟激增了？换个供应商。生产环境中出现幻觉？再加一个护栏提示词。这些都无法解决根本问题，即没有人将系统的可靠性作为一种专业规范来负责。这些团队真正需要的——通常在他们需要另一位应用科学家之前——是他们的第一位 SRE。

成本仪表盘一片绿意。自从级联路由（cascade router）上线以来，单次请求的支出下降了 62%。CFO 很开心。平台团队正在庆祝。而与此同时，你的 p95 延迟悄然上升了 40%，你最重要的客户刚刚流失，理由是“机器人在处理关键查询时变笨了”，而实验团队已经连续两周在追踪一个根本不存在的幻影回归（phantom regression）了。

这就是级联路由的可靠性陷阱。它是每一个“先尝试廉价模型，如果不成功再升级”架构的隐蔽失败模式，也是生产环境 LLM 系统中最少被讨论的二阶效应之一。成本上的收益是真实的、可衡量的，且易于归因。而可靠性上的损失则是弥散的、统计性的，几乎无法追溯到导致它们的路由。因此，成本上的胜利受到赞彰，可靠性上的损失被归咎于“模型变差了”，团队就这样把自己优化进了一个坑里。

一个规划器智能体输出了七个步骤。每一个看起来都很合理。编排器分发了这些步骤，前三个返回了值，第四个在等待第五个，第五个在等待第七个，而第七个——埋藏在规划器散文般描述的第三行里——正静静地等待着第四个。没有任何东西被锁定。没有触发过任何 EDEADLK。智能体消耗了 40,000 个 token 来推理为什么第四步“花费的时间比预期长”，最终以一个温和、合理的道歉向用户宣告放弃。

这就是你的智能体无法察觉的死锁。它不是操作系统课程中的那种经典死锁——这里没有互斥锁（mutex），没有内核可以内省的资源图，也没有你的技术栈中任何人能识别的持有者或等待者。依赖关系存在于规划器生成的英语句子中，循环形成于潜在语义而非任何数据结构中，而故障模式看起来与“模型正在努力思考”无异。经典的死锁检测在这里毫无用处，但代价是相同的：工作流停滞，token 蒸发，而你的 trace 什么也不会告诉你。

一个调度代理将客户的入职电话订在了周二，而不是周三。调查花费了两天时间。Prompt 没问题。模型没问题。日历工具也没问题。错误在于系统 Prompt 携带了一个早一小时的 current_time 字段，当时请求正通过一个在 UTC 午夜前刚刚构建的缓存前缀（cached prefix）进行路由。当代理解析出“明天上午 10 点”并调用预订工具时，“明天”所指的日期对于东京的用户来说已经是“今天”了。

代理根本无法察觉。它没有任何感知手段。LLM 没有时钟。它们只有你在 Prompt 中提供给它们的字符串，并且它们会像对待用户问题一样权威地对待这个字符串——也就是说，完全信任，不加怀疑，也没有第二个来源可以进行交叉比对。

大多数团队在抽象层面都知道这一点，但仍然将注入的时间戳视为日志字段：某种有则更好、渲染到系统 Prompt 中提供上下文、不属于任何人的明确责任、不属于任何人的正确性边界的内容。这种构想是错误的。时间戳是一个正确性边界。每一个依赖于“现在”的代理行为——调度、过期、重试窗口、“最近”、“明天”、“五分钟内”、检索文档的新鲜度检查——都运行在你生成的时间管道之上，并继承了该管道所拥有的每一个 Bug。

Agent 以“全部搞定——如果需要任何修改请告诉我！”结束它的回合，而你的编排器必须决定是将工单标记为已解决、启动下一次交接，还是重试。这句话不是一个返回码。它只是一个训练出来的、为了在聊天结束时听起来很贴心的礼貌语，而它下游的每一行自动化代码都继承了这种模糊性。那些将此视为解析问题的团队会编写捕获 \b(done|complete|finished)\b 的正则并收工。而那些在生产环境中运行 Agent 的团队最终会明白，完成是一个事件，而不是一种情绪。

失败模式通常是双峰且枯燥的。要么是 Agent 在未完成时宣布完成——过早终止——而编排器愉快地在一个半成品产物上推进工作流。要么是 Agent 确实完成了，但表述方式与检测器不匹配（“我已经落地了更改，尽管边界情况的测试仍然不稳定”），编排器于是发起重试，导致重复工作、产生重复的副作用，有时甚至会推翻成功的第一次尝试。这两种模式都会静默地退化。在有人阅读 Trace 并注意到 Agent 说了“我想这些就是全部了”而计费系统将其视为一次提交（commit）之前，任何仪表盘都不会显示异常。

解决方法不是更智能的解析。而是给 Agent 一个结构化的终止方式——一个具有枚举状态、原因代码和你的流水线可以路由的句柄（handle）的“完成工具（done-tool）”——并将编排器改为等待该事件，而不是监听聊天流。

一个每步成功率为 95% 的智能体并不是一个 95% 可靠的智能体。将 20 个步骤串联起来，端到端的完成率就会下降到 36%。这是大多数团队在智能体上线生产环境后才发现的算数逻辑，也是为什么这么多“运行良好”的原型在真实流量涌入的瞬间就会陷入停滞。解决方法不是更好的提示词或更大的模型，而是一个乏味的分布式系统基础设施，大多数 AI 团队在第三次宕机被迫应对之前都会试图避开它。

这种基础设施就是“持久化执行”（durable execution）——这是一种让多步骤工作流在崩溃、重启和局部故障中幸存且不丢失进度的准则。这并不是什么新鲜主意。Temporal、Restate、DBOS、Inngest 和 Azure Durable Task 已经为此推销多年。2026 年的新变化是，每个严肃的智能体框架都已悄然承认持久化执行是入场券：LangGraph 现在内置了 PostgresSaver 检查点，OpenAI Agents SDK 暴露了 resume（恢复）原语，Anthropic 的 Managed Agents 运行在内部的持久化基座上。如果你的智能体架构仍然依赖 Celery 队列和乐观主义，那么你是在 2026 年解决一个整个行业在 2024 年就不再假装视而不见的问题。

本文探讨的是无状态 LLM 与必须包装它的有状态工作流引擎之间的架构接缝。接缝之处正是可靠性所在，也是大多数团队目前编写 Bug 的地方。

在智能体（agent）系统中，最危险的失败并非那些大张旗鼓的报错。而是智能体自信地宣布“任务完成”，并返回一份它从未执行过的工作摘要。文件从未写入。Webhook 从未触发。数据库行仍保持一小时前的状态。但追踪记录（trace）显示为绿色，完成计数器在增加，仪表盘告诉领导层新功能运行良好。

这就是“幻觉成功”（hallucinated success）问题，它是生产环境中最难捕捉的一类漏洞，因为它能避开你拥有的所有廉价信号。智能体没有崩溃。它没有超时。它没有返回错误。它叙述了一个合理、连贯且完全虚构的成功执行过程。你的可观测性堆栈是为捕捉嘈杂的失败而构建的。而无声的成功看起来与真正的成功一模一样，直到用户注意到输出是错误的。

团队向 AI 工作流添加人工审批的方式，与他们在代码库中添加 if (isDangerous) requireHumanApproval() 的方式如出一辙：将其视为一个二进制开关，在设计时检查一次，然后便将其遗忘。架构图上的指标是“人工监督”旁边的一个绿色对勾。而真正重要的指标——人工花费了多长时间、他们是否阅读了任何内容、在点击批准时该条目是否仍然相关——却很少有对应的仪表板。

将人工审批者视为二进制开关，你就等于在不知不觉中构建了一个队列。而队列具有动态特性：积压量的增长速度超过了你的员工配置速度、陈旧性使昨天的决定变得毫无意义、疲劳让审查变成了“走过场”（rubber-stamping），以及优先级倒置让真正重要的那一个决策被排在三百个无关紧要的决策之后。架构图中看不到这些，但它们都会出现在事故回顾（incident retro）中。

这种天真的算法是这样的。我们的主供应商拥有 99.3% 的可用性。增加第二个具有类似独立性的供应商，同时故障的概率就会降至大约 0.005%。成本翻倍，风险降至两百分之一。工程负责人批准了双倍预算，轮值报警在供应商宕机时也不再响起。电子表格显示，这是路线图上性价比最高的可靠性投资。

六个月后，电子表格错了。评估套件（eval suite）的运行时间变成了三倍，提示词（prompt）修改需要提交两个 PR，每周的回归报告中有两列内容相互矛盾，而且没人记得预发布环境的备选方案当前路由到了哪个供应商。一旦团队核算了用于保持两条路径校准的人力工时，双倍预算实际上更接近 4–5 倍。第二个供应商在技术上仍在提供流量，但一半的功能已被悄悄锁定在其中一方，因为保持两者同步已经变得不再划算。

这就是多模型成本陷阱。可靠性算法是正确的；但团队搞错的是运营层面的算法。接下来是对引入多供应商后的成本分解、大多数团队应该首先尝试的“单供应商加降级模式”方案，以及真正证明这种非线性复杂性合理性的少数准则。

智能体对话记录中最危险的一句话不是幻觉。而是四个冷静的词：“我没有找到。”智能体听起来在认知上表现出谦逊。听起来像是完成了尽职调查。对于任何下游读者或调用者来说，这听起来完全像是一个事实。然而，这句话并没有提供关于该事物是否存在的信息。它只提供了关于特定工具在使用特定查询、咨询特定索引（而智能体恰好在那个时刻有权访问该索引）时发生了什么的信息。

在这两种解读之间，隐藏着一个随时可能发生的生产事故。支持智能体告诉客户“我们没有你的订单记录”，因为同步延迟导致写入只读副本的时间推迟了 90 秒。编码智能体声明“该模块没有测试”，因为它搜索了一个不包含测试文件夹的目录。合规智能体回答“档案中没有先前的违规记录”，因为审计索引尚未摄取上周的报告。在每种情况下，智能体的输出在语法上都是一种否定，但在认知上，它只是一个被重新表述为断言的“耸肩”。