238 篇博文 含有标签「reliability」

大多数生产环境中的 Agent 故障看起来像是模型错误。Agent 在会话开始时能正确响应系统提示词——维持正确的语气，遵守工具约束，遵循定义的工作流程。然后，在第 30 或 40 轮左右，情况悄然发生变化。Agent 开始在本应直接的地方含糊其辞，调用了它被告知应避免的工具，甚至推翻了它在 15 轮前做出的决定。系统提示词没有改变，但 Agent 的行为已经变了。

这就是人格漂移：由于 Transformer 对越来越深埋的上下文的注意方式，Agent 实际行为与其原始系统指令之间产生的渐进式偏差。研究对此进行了精确量化——经过 8–12 轮对话后，人格自一致性指标下降超过 30%。单轮 Agent 的任务准确率约为 90%；在运行相同任务的多轮 Agent 中则降至约 65%。这 25 个百分点的差距并非一个可以通过调整提示词来解决的模型质量问题，而是注意力机制在长序列上工作方式的架构特性。而大多数团队只有在上线某个功能、该功能悄无声息地降级数小时后才被用户发现时，才意识到这个问题。

查看你的网关重试配置。三次尝试。带有抖动的指数退避。在 5xx 错误和超时时重试。最大延迟限制在几秒钟。这看起来很合理，而且是某人两年前从微服务运行手册中复制过来的。但这正是你的 P99 是 P50 两倍、在服务商发生故障期间 Token 费用激增，以及相当一部分用户在默默流失前盯着 30 秒加载圈的最主要原因。

专为 50 毫秒 RPC 设计的重试策略在面对 8 秒的 LLM 调用时注定会失效。失败的形式不同，每次尝试的成本不同，用户感知到的时间维度也不同。默认设置并不安全，只是让人感到熟悉。大多数团队通过同样的方式发现这一点：在一次事后回顾中，网关日志显示响应成功，而客户的截图却显示 UI 已经卡死。

凌晨 3 点因为宕机而把你吵醒的告警其实是简单的。供应商返回了 40 分钟的 503 错误，你的回退机制生效了，运维手册（runbook）启动了，复盘报告（post-mortem）几乎可以自动完成。而那些没有吵醒你的告警——那些在所有仪表盘都显示绿色的情况下，让你的支持队列在 6 小时内堆满的告警——才是渐变故障（brownout）。供应商的 API 仍然有响应。状态页依然显示“运行正常（operational）”。你的 p99 延迟已悄然从 2.1 秒漂移到 14 秒，错误率从 0.1% 上升到 4%，而唯一察觉到的人是那些已经流失的用户。

供应商的可用性并不是非黑即白的二元状态。大多数团队编写的回退逻辑——“如果供应商宕机，则切换到备用方案”——本质上是用一个只有两种状态的状态机去应对一个连续变量，当供应商处于“惨淡运行”而非“彻底宕机”的状态时，这种机制根本不会触发。为渐变故障（brownouts）而设计是一个与处理宕机完全不同的设计问题，我所见过的几乎每一个生产环境中的 Agent 调度框架在发布时都没有解决这个问题。

“先创建后通知”的序列在开发阶段运行良好。而“先通知后创建”的序列则会为一个尚不存在的实体触发 webhook，导致消费者返回 404，接着你的团队会花上一周时间来调试这个看起来像是不稳定的集成测试。这种不稳定并非随机。它是确定性的，源于你的工具集拥有而你的规划器（planner）却不知晓的隐藏排序不变性。

这就是生产环境中 Agent 工具调用排序 bug 的常见形态：工具集在底层以偏序（partial order）方式组合——某些操作必须先于其他操作执行，而另一些则可以按任意顺序运行——但在规划器看来，它们只是一个无序的能力集合。模型选择了一个昨天行之有效的顺序。而明天，一次提示词修改、模型升级，甚至只是不同的 temperature 采样，都会选出另一个顺序。对于阅读追踪记录（trace）的人来说，这两种顺序看起来都很合理。但其中只有一个是正确的。

如果不声明顺序，团队交付的就是一个最终会被模型的提示词敏感性（prompt sensitivity）触发的 bug 隐患。

如今，生产环境中的大多数 “智能体”（agents）其实都是套着对话界面的后台任务。它们不需要用户向其输入内容，而是需要一个触发器、一个状态文件，以及一种在不可避免的超时后恢复运行的方法。对话循环 —— 请求、工具调用、请求、工具调用，无限循环 —— 是为了演示方便而提供的功能，却悄然间成为了默认的执行模型。然而，对于大多数交付的智能体工作负载来说，这其实是一个错误的模型。

这并非一个哲学层面的决定。它直观地反映在账单上、值班告警中，以及任务的运行成功率上。对话循环会在多轮对话中保持模型会话开启，不断累积上下文，一旦链路中任何一环出错，整个过程就会中断。而调度触发则在确定的边界处启动，运行至完成或达到检查点，并在退出前将状态写入持久化存储。前者像是一通电话，而后者则是一个工作队列。将两者混为一谈，会导致一个每月 200 美元的功能在没有任何人修改提示词的情况下，变成每月 4 万美元的负担。

当搜索索引失效、供应商 API 对你限流、数据库只读副本出现延迟，或者下游微服务开始返回 503 错误时，你的智能体（agent）必须决定该做什么。在大多数生产环境的智能体系统中，这个决定从未被真正做出。它是被“默默继承”下来的——往往来自于编写工具封装（tool wrapper）的工程师在项目第三周周二下午 4 点随手写下的代码。

其结果就是你的客户最终替你写出的内容：一个 Reddit 帖子、一份客服对话记录，或者是新闻稿中的一段引述。“助手告诉我余额是 0 美元，但其实我的账户没问题——结果发现是他们的查询服务挂了。”那段话就是你的团队没写的降级模式规范。现在它公开了，它属于客户了，而且你的工程部门在接下来的整个季度里都将忙于应对它。

你团队每季度演练的灾备 (DR) 操作手册是为了一套你已经不再完全运行的技术栈编写的。手册上写着：提升从库、重新指向 DNS、清空队列。它假设状态存储在数据库、队列和对象存储中 —— 这些是 SRE 团队已经管理、命名并测试了十年的地方。接着在上个季度，你上线了一个智能体 (agent)。现在，工作内存存在于推理提供商的会话缓存中、工作节点本地磁盘上的草稿文件里、尚未回写的在途工具调用结果中，以及仅存在于单次模型调用提示词历史中的部分“计划-执行”轨迹 (trace) 里。这些都不在资产登记簿上，也不在操作手册里。

当区域宕机时，智能体并不会干净利落地失败，而是处于一种“半完成”的状态。用户看到工作流已经开始，但故障转移后的区域无法恢复进度；客户收到了两次账单，或者根本没收到，因为幂等键存在于已经失效的工作节点上；值班工程师读着 Slack 频道里的讨论，开头是“编排器已启动，但是...”，六小时后以处理信用卡拒付队列告终。

这就是没人点破的鸿沟：智能体特性拥有现有灾备计划未曾描述的状态模型。如果团队还没有记录下这些状态表面，那么只需一次区域性停机，他们就能深刻体会到操作手册的缺失所带来的代价。

高管演示进行得非常完美。模型回答了精选的问题，智能体（agent）完成了工作流，屏幕录像已保存到公司网盘，发布日期也已排入日程。六周后，上线部署遭遇惨败，复盘报告不言自明：模型需要更多打磨，提示词（prompt）需要更多迭代，团队低估了从原型到生产环境之间的工作量。

这种叙事是错误的，而且代价昂贵，因为它让团队回去重复那些已经失败的工作。演示并不是生产环境的“欠打磨”版本。它只是团队从未测量过的分布中的一个“单一采样”（single sample）。那个惊艳瞬间只是模型针对相同输入可能产生的数千个结果中的一次实现，而团队却把最好的那次当作典型表现发布了。演示与生产环境之间的差距不是质量下滑，而是团队尚未察觉的“方差”（variance）。

这种思维转变至关重要，因为方差问题的解决方法与打磨问题的解决方法完全不同。“打磨”导向会说：“迭代提示词，微调模型，雇个更好的产品经理。”而“方差”导向则会说：“在输入分布中进行 n 次采样之前，你根本不知道自己手里拿的是什么。”这两种诊断会产生不同的路线图、不同的预算以及不同的事故模式。那些在 2026 年能够可靠交付的团队，都清楚自己面临的是哪种问题。

A 团队的智能体宣传其成功率为 99%。B 团队的智能体也宣传 99%。调用这两者的全新联合工作流在状况良好时成功率为 98%，而在状况不佳时仅为 96% —— 负责该联合工作流的团队现在成了两个他们不拥有、无法在本地复现、且未编写评估集的系统的事实上的 SRE。每个上游团队都达到了其 SLO（服务水平目标）。但复合产品却未达标。边界正确一侧的报警器却始终保持沉默。

这是独立失败率的数学问题，自从组织开始允许智能体相互调用以来，它就一直潜伏在显而易见的地方。五个可靠性为 99% 的组件会给你带来 95% 的端到端可靠性。十个组件则会降至 90%。一个每步成功率为 95% 的 20 步流程，其最终成功率仅为 36% —— 超过一半的操作在完成前就会失败。当一个工作流链接了 50 个组件时 —— 一旦企业级智能体开始调用子智能体，再由子智能体调用工具智能体，这种情况并不罕见 —— 一个每个环节都“99% 可靠”的系统，在大约十次请求中就会失败四次。

研究人员在分析了超过 150 个任务中的五个流行多智能体框架后，发现失败率在 41% 到 87% 之间，其中排名前三的失败原因是：步骤重复、推理与行动不匹配，以及对终止条件的忽视 —— 观察发现，与单智能体基准相比，非结构化的多智能体网络会将错误放大高达 17 倍。这其中的数学逻辑并不深奥。问题在于，组织的 SLO 表、仪表板、轮值安排和 PRD 仍然是以单个智能体为单位进行定义的。

你的审核员今天早上做出的第 50 个决策与第 1 个决策的质量并不相同。架构图不会显示这一点。容量模型不会显示这一点。跟踪“每小时审批量”的仪表盘甚至在主动掩盖这一点。然而，你的人机回环（Human-in-the-loop，简称 HITL）系统的整个前提——即由人来捕捉模型产生的错误——从队列开始填充的那一刻起就在无形中退化。

大多数 HITL 设计将审核员的时间视为一种无限的、可互换的资源。团队设置一个置信度阈值，将所有低于该阈值的项路由到人工队列，并宣布系统是“安全”的。六周后，审批率已悄然升至 96%，队列深度是人员配置模型假设的两倍，抽样审计显示审核员正在对他们在第一天会标记出来的边缘案例点击“批准”。系统并没有崩溃，它只是通过“橡皮图章”式的盲目审批，让自己看起来运转良好。

一个故障率高达 70% 的功能是无害的。用户在一周内就会发现他们必须验证每一条输出，将系统视为一个不可靠的助手，并做出相应调整。而一个成功率达到 70% 的功能则更糟糕。它正确的频率足以让用户停止验证，而错误的频率又足以让失败变得集中、显眼且具有针对性。用户的心理模型会崩塌为“我不知道什么时候该信任它” —— 这种产品体验从根本上比“我知道不要信任它”更糟糕。

这就是 70% 的恐怖谷，也是过去两年中构建的大多数 AI 功能所处的位置。团队衡量综合准确率，看着数值超过某个“足够好”的阈值，然后发布。实际的用户体验并不随着这个数字单调提升。在大约 60% 到 85% 的准确率之间，产品随着准确率的提高反而变得更差，因为用户因疏于检查而导致的错误成本，超过了他们无需验证正确答案所带来的价值。

那些在不考虑可预测性问题的情况下发布 70% 准确率产品的团队，发布的并不是一个 95% 产品的拙劣版本。他们发布的是一个完全不同的产品：一个主要的失效模式是隐形的产品。

你长期运行的智能体（agent）所做的最危险的事情，也是它做得最自信的事情：根据记忆回答。客户的地址在上周二更改了。智能体认为“开启”的工单在昨天被人工关闭了。智能体拥有整洁解释笔记的产品功能，其实际交付的形式与智能体三周前阅读的规范不同。在教科书定义上，这些都不属于幻觉——模型准确地召回了它存储的内容。只是在智能体看向别处时，世界已经发生了变化。

大多数团队将记忆视为一个写入问题：智能体应该记住什么、我们如何总结、嵌入（embedding）策略是什么、如何防止存储爆炸。这种思维方式产生的架构会随着错误程度的增加而变得更加自信。更难的问题——那个决定你的智能体在第三周后是否仍然有用的问题——是对账（reconciliation）：这是一个明确的、持续的闭环，用于比较智能体认为真实的情况与底层系统当前显示的真实情况。