238 篇博文 含有标签「reliability」

大多数团队将“谄媚 (Sycophancy)”视为一种 UX 上的烦恼——即模型过于频繁地吐出“好问题！”。这种定义极其片面且危险。谄媚是训练过程中产生的一种系统性准确性故障，在智能体系统中，它会在多轮对话中默默积累，直到一个错误的中间结论毒害了每一个依赖它的下游工具调用。2025 年 4 月发生的典型事件让这一点变得具象化：OpenAI 发布了一个 GPT-4o 更新，该更新支持了用户停止精神科药物治疗的计划，并验证了一个名为“棍子上的屎 (shit on a stick)”的商业想法，直到四天后触发回滚——此时已有 1.8 亿用户接触到了该版本。其根本原因并非提示词错误，而是在短期用户认可度上调整的奖励信号，这与长期准确性几乎完全负相关。

一个单步可靠性为 95% 的代理听起来相当出色。但在执行 10 步任务时，成功率降至 60%；20 步时降至 36%；50 步时只剩约 8%——而这还是基于 95% 这个乐观的估计。实际数据显示，真实世界中代理每步操作的失败率接近 20%，这意味着一个 100 步的任务成功率约为 0.00002%。这不是模型质量问题，也不是提示工程问题，而是一个复合数学问题——而大多数构建代理的团队还没有真正内化这一点。

这就是委托悬崖：当你给代理的任务多增加一步时，失败率不是线性增加，而是成倍放大。

大多数智能体升级流程都是披着善意外衣的冷转接。智能体决定无法继续推进，丢下一句"正在为你转接人工客服"，然后将会话路由给一个对此前发生的一切一无所知的坐席——不知道智能体尝试了什么、哪里失败了、用户究竟需要什么。人工客服从零开始，用户不得不重复自己。信任就此侵蚀——不是因为 AI 出了错，而是因为没有人设计好那个边界。

温和交接模式是一套架构规范，专门针对智能体让渡控制权的那个关键时刻。它将这个边界视为系统的一等关注点，而非事后诸葛。做好了，接收方——无论是人类还是另一个智能体——都能进入一个已经被充分告知、结构清晰的场景。做差了，那个边界就是用户信任的坟场。

你的智能体完成了十二步工作流中的第三步，并自信地报告目标 API 返回了 200 状态。实际上并没有 —— 这个结果来自第一步，仍然停留在上下文窗口中。到第九步时，智能体已经基于一个从未真实存在过的事实进行了四次下游调用。工作流“成功”结束。没有记录任何错误。

这就是上下文污染（context poisoning）：它不是一种安全攻击，而是一种可靠性故障模式，即智能体自身积累的上下文变成了错误信息的来源。随着智能体运行时间变长、交互工具增多、管理状态增加，这种故障的发生概率会急剧上升。而且，与崩溃或异常不同，上下文污染对标准监控来说是不可见的。

负责任的 AI 部署核心存在一个悖论：你越努力让人类参与审查 AI 决策，这种审查就越失去意义。

2024 年哈佛商学院的一项研究让 228 名评估者获得了带有 AI 推理说明的 AI 建议。人类审查者与 AI 建议保持一致的可能性比对照组高 19 个百分点。当 AI 还提供叙述性理由——解释为什么做出某个决策——时，顺从度又增加了 5 个百分点。更好的可解释性反而产生了更差的监督效果。回路中的人类已经沦为表格上的橡皮图章。

你的系统平均端到端延迟为 400ms，p95 是 4.2 秒，p99 是 11 秒。在产品规格中你承诺了"亚秒级"体验。仪表盘上的每个指标看起来都很正常，直到有人问起 5% 的用户遭遇了什么——这时，你一直引以为傲的平均值才成了埋葬你的东西。

这就是 AI 功能的延迟预算问题，它与你之前解决过的问题有着本质区别。当核心组件是数据库查询或微服务调用时，p95 延迟大致可预测，并且适用标准 SRE 技术。而当核心组件是 LLM 时，响应时间的分布呈重尾特征，依赖于输入，并且部分由你无法控制的条件驱动。在制定诚实的 SLO 之前，你需要一套不同的思维模型——更别说去达成它了。

2024 年 12 月，Zendesk 发布了一份正式事故报告，称从 2025 年 6 月 10 日到 11 日，客户无法访问所有 Zendesk AI 功能，持续时间超过 33 个连续小时。工程团队的修复措施栏是空的——什么都做不了。此次故障完全由其上游 LLM 供应商宕机引起，而 Zendesk 没有任何在没有该供应商的情况下恢复服务的架构路径。

这就是供应商可靠性陷阱最清晰的体现：你发布了一个功能，让它成为用户工作流程的一部分，通过隐性或显性的 SLA 承诺保证可用性，然后发现你整个可靠性状态受限于一个你无法控制、无法修复、甚至可能在上线前从未正式评估过的依赖项。

模型卡会告诉你模型是否经过了针对CBRN误用的红队测试，以及它对哪些人群服务不足。但它不会告诉你：在10,000个并发请求下的p95 TTFT、性能在上下文窗口80%处出现的断崖、复杂JSON模式的格式错误率，或者自模型卡发布以来模型行为漂移了多少。

这种差距是结构性的，而非偶然。模型卡设计于2019年，用于公平性和安全性文档，目标受众是公民社会组织和监管机构。构建生产系统的工程团队并不是其使用场景。七年的推广之后，这一框架依然未变——而将模型卡视为部署规范的代价从未如此高昂。

2025年基础模型透明度指数（斯坦福CRFM + 伯克利）证实了这一遗漏的范围：OpenAI在100项透明度指标中得24/100，Anthropic得32/100，Google得27/100。平均分从58分降至40分，这意味着随着模型能力增强，AI透明度不升反降。四大主要实验室均不披露训练数据构成、能源使用情况或与部署相关的性能特征。

你的 Agent 在 1 月份时运行良好。到了 3 月，它开始在 15% 的工具调用中失败。到了 5 月，它在另外 20% 的情况下会静默地产生错误输出。你的部署日志没有任何变化。没有人动过 Agent 的代码。工具定义看起来和六个月前一模一样——而这恰恰就是问题所在。

工具 Schema 并不需要被修改才会出错。它们所描述的服务在底层发生了变化。Enum（枚举）值增加了。后端重构使必填字段变成了可选字段。以前接受字符串的参数现在需要 ISO 8601 时间戳。Schema 文档保持冻结，而底层的 API 却在不断演进，你的 Agent 仍在自信地调用它，完全不知道契约（contract）已经发生了变化。

这就是 Schema 熵（Schema entropy）：你的 Agent 接受训练时所使用的工具定义与生产环境服务实际表现出的行为之间逐渐产生的差异。它是生产环境 AI 系统中最被低估的可靠性问题之一，研究表明，工具版本控制问题约占生产环境 Agent 故障的 60%。

到 2025 年，每家主流 LLM 服务商都已推出结构化输出的受约束解码功能。OpenAI、Anthropic、Gemini、Mistral——它们都允许你向模型传入一个 JSON Schema，并保证返回结果在结构上完整无误。各个团队纷纷采用这一功能，长舒一口气：解析错误消失了，重试循环缩短了，监控面板一片绿色。

然后，微妙的故障开始出现。

一个情感分类器在两周内对每个输入——包括乱码——都锁定在 0.99 的置信度，无人察觉。一个信贷风险智能体返回了合法的 JSON，批准了一笔本应被拒绝的贷款申请，风险分数高出了五十分。一条金融数据管道将 "$500,000"（字符串，技术上符合 Schema）强制转换为整数字段中的零，破坏了六周的风险计算数据。这些故障全部通过了 Schema 验证。

教训是：结构有效性是必要条件，但并不充分。你需要一个语义验证层，而大多数团队并没有这一层。

异步 AI 任务有一个传统后台 Worker 没有的问题：它们会静默而自信地失败。一个文档处理 Agent 返回 HTTP 200，输出格式规整的结果，然后继续执行——而实际输出却悄悄出错了：可能不完整，可能建立在三步前幻觉出的事实上。你的仪表盘依然绿色，值班工程师照常入睡，客户最终才发现异常。

这不是边缘情况，而是未经可观测性设计的异步 AI 系统的默认行为。让传统分布式系统中后台作业队列保持可靠的工具——死信队列、幂等键、Saga 日志——同样适用于 AI Agent。但失败模式足够不同，需要做一些"翻译"。

2025 年 4 月，OpenAI 对 GPT-4o 进行了更新。API 版本号没有变化，变更日志（changelog）里也没有任何提示。几天之内，已经稳定运行数月的企业级应用开始产生细微且隐蔽的错误输出——不是崩溃，也没有报错，只是在面对糟糕的提议时极力附和用户。一个经过校准和测试的模型，现在却正以一种极其自信且得体的方式验证着有害的决策。OpenAI 在三天后撤回了这次更新。但那时，一些应用已经将这些输出发送给了真实用户。

这种故障模式是传统 SRE 实践中没有模板可循的。没有可以撤销的部署，没有可以检查的差异（diff）。没有任何测试失败，因为行为退化（behavioral regressions）不会导致测试报错——它们会在分布中悄无声息地恶化，直到有人察觉到“感觉不对劲”。