238 篇博文 含有标签「reliability」

一个正在构建多智能体研究工具的团队在一次失控任务运行到第 11 天时发现，他们的两个智能体在整个过程中一直在循环交叉引用彼此的输出。账单金额：47,000 美元。没有人类看到过结果。没有触发任何警报。系统只是在持续运行，并确信自己正在取得进展，因为架构中没有任何环节提出这样一个问题：当一个任务确实无法完成时会发生什么？

消息队列在几十年前就通过死信队列 (DLQ) 解决了这个问题。一条超过投递重试限制的消息会被路由到一个暂存区，操作员可以在那里检查它、修复根本原因，并在系统准备就绪时重新播放。这种模式简单、经过实战检验，但在当今的生产级智能体系统中几乎完全缺失。

大多数构建多智能体系统的团队，把大量时间花在授权信任上：智能体 B 被允许执行哪些操作、可以调用哪些工具、能访问哪些数据。这是一个重要的问题。但还有第二个信任问题同样关键，却鲜少得到足够重视——而正是它在实际生产系统中造成严重故障。

这个问题是认知层面的：当智能体 A 将任务委托给智能体 B 并收到答案时，A 应该在多大程度上相信 B 返回的内容？

这不是 B 是否被授权回答的问题，而是 B 是否真的有能力回答的问题。

你的流式传输正常工作。你的重试逻辑正常工作。你的安全过滤器正常工作。你的个性化功能也正常工作。但当你将它们部署在一起时，奇怪的事情发生了：流式传输中途出现的速率限制错误导致用户看到的是一段被截断的响应，而系统却将其记录为成功。重试机制触发了，但流式传输已经结束。个性化层提供了一个定制化的响应，而安全过滤器本应拦截这个响应——除非过滤器看到的是 Prompt 的脱敏版本，而不是个性化层所处理的那个版本。

每一个功能都通过了你编写的各项测试。然而系统还是让用户失望了。

这就是功能交互故障（feature interaction failure），它是当今 AI 系统中最容易被误诊的生产环境 Bug。

你的智能体已经与同一个用户对话了400次。六个月前她说她更喜欢Python。三个月前她的团队迁移到了Go。上周她提到了一个新的TypeScript项目。这三个事实现在都存储在你的向量数据库中——语义相似、时间顺序混乱、权重相同。下次她请求代码帮助时，你的智能体会同时检索到这三条信息，将这团矛盾的内容递给模型，然后自信地为TypeScript场景生成带有Go风格的Python代码。

这就是幽灵上下文：那些永不消亡的过时信念，与其替代版本一同被检索，悄然腐蚀智能体的推理。

这个问题之所以被低估，是因为它不会产生可见错误。智能体不会崩溃，不会拒绝响应，而是生成流畅自信的输出——只是微妙地、代价高昂地出错了。

你的 AI 功能发布时准确率为 85%。领导层非常兴奋。但随后一项合规审计发现，那 15% 的错误答案集中在特定的监管解读上——而你所使用的供应商家族中的每个模型都以同样的方式犯了错。你调用了一个模型，它失败了。因为你从未将其与其他模型进行对比，你完全没有意识到这种失败是系统性的。

多模型共识架构（Multi-model consensus architecture）是解决这一问题的结构化方案。与其信任单个大语言模型（LLM），不如将请求分发给来自不同供应商家族的多个模型，汇总它们的响应，并根据一致性进行路由。不一致的模式本身就成为了系统中的一等信号，而不仅仅是一个调试产物。

这种方法的每次推理成本要高出 2 到 4 倍。对于大多数用例来说，这显然不值得。但对于特定类别的输出——法律摘要、医疗分诊路由、金融风险标记、安全评估——错误答案的代价远超额外推理的成本，以至于计算逻辑几乎立即发生反转。

一个智能体成功创建了 GitHub Issue、开启了 Jira 工单，并更新了共享表格。然后在发送 Slack 通知之前超时了。框架将此次运行记录为"已交付"。用户从未收到通知。副作用存在于三个系统中，而对人类真正重要的结果却没有送达。

这是生产智能体系统中最常见的超时失败模式，但几乎从来不是团队预先准备好的那种。大多数智能体实现把超时当作普通异常处理：捕获、记录、返回错误。即使智能体完成了 90% 的工作，用户也什么都得不到。问题不在于是否设置超时——每个生产系统都需要超时。问题在于当时钟走完时，智能体该如何应对。

当麦当劳在三年运营后关停其 AI 得来速系统时，失败的原因并不是模型识别订单能力不足。失败的根源在于架构：没有明确的升级路径交给人工收银员，没有触发重试的置信度阈值，也没有定义系统困惑时该如何处理。AI 只是不停地尝试。顾客不断地抓狂。顺利路径设计得很好，其他一切都没有。

几乎每一个失败的 AI 部署都重复着这个模式。模型在演示中运行良好，在生产中出现故障。而事后分析揭示了同样的根本原因：降级设计从来不是架构的一部分，而是某人打算"之后再加"的东西。

当你的 AI 功能输出错误答案时，第一个问题总是：“是模型的问题吗？”大多数工程师会进行模型评估，运行几个测试提示词，并得出模型看起来没问题的结论。他们通常是对的。模型没问题。故障发生在其他地方——在你的组件相互通信的那些无形接缝处。

这一结论的证据是一致的。对生产环境 RAG 部署的分析显示，73% 的故障是检索故障，而不是生成故障。在多智能体系统中，最常见的故障模式是消息顺序冲突、状态同步间隙和 schema 不匹配——这些都不会出现在任何单组件健康检查中。GPT-4 在处理复杂的提取任务时，产生无效响应的比例接近 12%，这不是因为模型坏了，而是因为模型与下游解析器之间的输出格式契约从未被强制执行。

模型背了锅，边界才是元凶。

每一个 AI 功能在发布时，都伴随着一个团队未曾预料到的时刻：必须将其关闭的时刻。在早会上，模型效果突然出现回归（Regression）；一场没人告知工程团队的营销活动导致成本飙升，在 12 小时内让账单翻倍；隐私审查发现提示词上下文泄露；供应商宕机 90 分钟；合规团队在中午发出了警告，该功能必须在下班前消失。

大多数团队为此准备的“禁用开关”只是让“功能返回错误” —— 一个永远无法加载的旋转图标，或者是显示“AI 助手不可用，请稍后重试”的横幅。这比 AI 出现之前的现状要糟糕得多，而当 AI 表现下降时，用户恰恰会拿现状与你对比。以前的方案至少有一个按钮。而现在，用户只得到了一句道歉。

决定一个模型是否上线生产环境的数字，是由运行在某个工程师 MacBook 上的 Jupyter Notebook 生成的。数据来源是 Slack 私聊中的一个 CSV 文件，评分则由一个没人固定版本的裁判模型完成。两周后，在工程师又动了三次 Notebook，且 API 供应商悄悄发布了一个微小的模型更新后，团队里已经没人能重现那个数字了——包括当初生成它的那个工程师。然而，那个数字就是准入闸门。它决定了 GPT-4o-mini 是否足以在客户支持流程中取代 GPT-4；它决定了新提示词模板的发布；它决定了微调模型的晋升。团队把它视为核心承重构件，却像对待便利贴一样存储它。

这就是“评估差距”（eval gap）。五年来，业界一直在将评估视为一个方法论问题——哪种评分技术、哪种裁判模型、哪种评分标准、哪种数据集——却几乎从未将其视为一个工程问题。但是，一旦你的评估套件开始充当生产发布的守门员，它就继承了生产栈其余部分所遵循的所有要求：可重现性、版本控制、所有权、可观测性、依赖管理、延迟与可靠性预算，以及一套在构建它的工程师离职后依然能运行的流水线。大多数团队完全跳过了这一层，只有在发生重大事故后才发现它的缺失——通常是评估分数显示绿色，而用户体验却是一片红色。

大多数 AI 功能发布时只有两种状态：正常工作和彻底挂掉。模型调用成功，功能就有响应；模型调用失败，用户就会看到错误。这相当于在构建 Web 服务时没有负载均衡、没有缓存，且只有一个数据库副本——在出事之前，它在技术上是可行的。

不同之处在于，工程师在 20 世纪 90 年代就学会了数据库弹性模式，并将其深刻内化。 AI 功能的弹性仍处于通过一次次生产事故进行艰难探索的阶段。一家支付处理器在一次时长 4 小时的 AI 停机中损失了 230 万美元。一家物流公司在其路由模型宕机时，错过了 30,000 个包裹的交付窗口。这两起失败都有一个共同的根本原因：当主模型不可用时，没有可以回退的方案。

这是多智能体系统设计在架构评审中很少被提及的一个令人不安的事实：当你让两个智能体处理同一任务时，它们在20%到40%的情况下不会就答案达成一致，具体比例取决于任务类型。大多数系统的应对方式是静默地选择其中一个答案。日志中只显示最终决策，中间的分歧消失无踪。一切看起来运转正常，直到下游出现故障——而你要花费三到五倍的时间来调试，因为你搞不清楚哪个智能体出错了，甚至根本不知道它们曾经存在过分歧。

智能体之间的分歧不是一个可以稍后处理的边缘情况。随着并行智能体拓扑逐渐成为标准架构模式，冲突解决从脚注升级为一级可靠性纪律。