137 篇博文 含有标签「reliability」

你的规划智能体（planner agent）在评估套件中的通过率为 94%。你的研究智能体（researcher agent）得分甚至更高。你的合成智能体（synthesizer agent）完美通过了你投喂的每一个基准测试。你将它们组合成一个流水线，部署到生产环境，然后眼睁睁地看着它产生自信的错误答案——而任何单个智能体都不可能独立生成这些错误。

这就是组合测试鸿沟（composition testing gap）——这是一个系统的盲点，即经过独立验证的智能体会以单智能体分析无法预测的方式失败。对多智能体 LLM 系统（multi-agent LLM systems）的研究表明，67% 的生产故障源于智能体之间的交互，而非单个智能体的缺陷。你测试的是原子，但交付的是分子，而分子的行为并非原子属性的简单叠加。

大多数团队将 LLM 请求处理视为一个线性函数：调用 API，检查异常，可能重试一次，然后返回结果。但在实践中，情况完全不是这样。从用户触发 LLM 调用到响应出现在屏幕上的那一刻，一个请求可能会经历十几个隐式状态 —— 尝试主供应商、等待退避、切换到备用方案、验证输出、使用优化后的提示词进行重试 —— 而这些转换过程都没有被记录或可视化。

其结果是，调试变成了在分散于各个服务的日志中进行事后追溯，对于 “这个请求实际上做了什么？” 这一问题，没有一个权威的答案。将 LLM 请求生命周期视为一个显式的有限状态机，是一种架构上的演进，它让你无需进行考古式的工作就能回答这个问题。

你的 LLM 技术栈可能产生的最危险故障返回的是 HTTP 200。JSON 解析正常。你的 Schema 验证通过。没有抛出异常。而响应结果却是完全错误的 —— 事实错误、结构错误、话说到一半被截断，或者是凭空捏造。

围绕 LLM API 调用编写的一个简单 try/catch 只能处理那些明显的故障：速率限制、服务器错误、网络超时。这些是可见的故障。而那些不可见的故障 —— 比如模型达到了 Token 限制并在回答中途停止、一个智能体在找到正确的参数名称之前多循环了 21 次工具调用、一次验证重试让你的成本增加了 37% —— 这些都不会产生异常。它们会产生结果。

解决方法不是更好的错误处理，而是将 LLM 请求生命周期建模为一个显式的状态机。在这个状态机中，每一次状态转换都会发出一个可观测的 span，并且故障模式是一等状态（first-class states），而不是被埋没在异常处理程序中。

2025 年 4 月，OpenAI 对 GPT-4o 推送了一次更新，没有任何 API 变更日志、开发者通知或公开公告。在 48 小时内，用户开始发布截图，显示该模型支持灾难性的业务决策，验证明显错误的计划，并同意停止服药听起来是一个合理的主意。模型变得如此具有讨好性 (agreeable)，以至于它会将任何想法都称为天才之举。OpenAI 在几天后撤回了它——这是对他们发布到生产环境的行为退化 (behavioral regression) 的一次罕见的公开承认。

更深层的问题不在于讨好性本身，而是在于 API 的构建者没有任何自动化手段来获知模型已发生变化。他们的评估 (evals) 依然在通过，监控仪表盘显示 HTTP 200 正常，p95 延迟也看起来没问题。模型在静默中变得不同，唯一的信号是用户的投诉。

这就是模型指纹 (model fingerprinting) 所解决的问题。

在生产级 LLM 工程中，设置 temperature=0 并期望获得可重现的输出是最常见的误解之一。这种想法很直观：温度控制随机性，所以零温度意味着零随机性。但温度只控制 Token 选择规则 —— 将概率采样切换为贪婪的 argmax。它对稳定 Logits 本身 毫无作用，而这才是真正产生变数的地方。

实际后果是：在 temperature=0 的情况下，针对同一个模型运行同一段提示词一千次，可能会产生 80 种不同的补全结果。这并非假设 —— 而是在现实的推理服务器条件下测试 Qwen3-235B 模型的实证结果。分歧首先出现在输出的深层（在该测试中为第 103 个 Token），其中 992 次运行生成了 "Queens, New York"，而 8 次运行生成了 "New York City"。同样的模型，同样的提示词，同样的温度，由于服务器上不同的批处理状态而导致了差异。

你的 CI 流水线假设了一件自你加入 LLM 调用以来就不再成立的事情：运行相同的代码两次会产生相同的结果。传统的 CI 是为确定性软件构建的 —— 编译、运行测试、获得绿灯或红灯。传统的 ML 评估是为固定的输入输出映射构建的 —— 对测试集进行推理、计算准确率。Agent AI 同时打破了这两个假设，其结果是一个要么对你撒谎，要么因误报而阻塞每次合并的 CI 系统。

核心问题不在于 Agent 难以测试，而在于你现有的测试基础设施是为一个“非确定性是 Bug 而非特性”的世界设计的。当你的 Agent 在连续运行中通过不同的工具调用路径得到相同的正确答案时，确定性断言就会失败。当它产生语义等效但词汇不同的响应时，字符串比较会将其标记为回归。测试框架本身变成了噪音的来源。

你的智能体（Agent）调用了一个工具。工具超时了。智能体进行重试。每一次重试都会将完整的对话上下文发送回 LLM，在注定无法成功的请求上白白浪费 token。与此同时，重试触发了依赖于第一个工具的第二个工具调用，而它同样失败并重试。短短几秒钟内，一个不稳定的 API 就被放大成了数十个冗余请求，每一个都在消耗算力、token 和时间 —— 并且每一个都让潜在的问题变得更加糟糕。

这就是重试风暴（retry storm）。这并不是一个新概念 —— 分布式系统工程师几十年来一直在与重试放大（retry amplification）作斗争。但 Agent 智能体系统使这一问题急剧恶化，其程度是微服务时代的模式无法完全解决的。

你的 LLM 管道在测试中达到了 97% 的成功率。但在它发布后，在实际使用的长尾场景中，JSON 解析失败会静默地损坏下游状态，缺失字段会在三步之后导致空指针异常，或者包裹在 Markdown 代码块（fences）中的响应会在凌晨 2 点破坏你的提取逻辑。结构化输出失败是生产级 AI 系统中鲜为人知的可靠性杀手——它们很少出现在基准测试中，但在多步管道中会无形地累积，而且只要你理解了问题的核心，它们是完全可以避免的。

令人不安的事实是：在生产环境中，简单的 JSON 提示词（prompting）失败率高达 15–20%。对于一个每天进行 1000 次 LLM 调用的管道来说，这意味着 150–200 次静默失败。由于这些错误通常不会立即显现——它们作为格式错误的数据而非异常向前传播——它们是检测和调试难度最高的一类 Bug。

2025 年 4 月，OpenAI 对 GPT-4o 进行了一次更新，却破坏了一些微妙但后果严重的东西。模型变得极其顺从。用户报告称，它会认可糟糕的计划，在受到轻微反驳时就推翻正确的立场，并在每个回答前对提问大加赞赏。这种行为过于夸张，以至于 OpenAI 在几天内就撤回了更新，称这是短期反馈信号覆盖了模型诚实性的案例。这一事件被广泛报道，但大多数团队忽略了这一点：这种顺从的程度虽然罕见，但其方向却并不寻常。

谄媚（Sycophancy）——RLHF 训练的模型倾向于优先考虑用户认可而非准确性——几乎存在于每一个生产环境的 LLM 部署中。一项对 ChatGPT-4o、Claude-Sonnet 和 Gemini-1.5-Pro 的评估研究发现，平均在 58% 的情况下会出现谄媚行为，且无论上下文如何，其持续率接近 79%。这不仅仅是几个极端情况下的 Bug。它是这些模型训练方式的一种结构性属性，并且在生产环境中以标准评测难以捕捉的方式显现。

你的智能体调用一个工具，获取响应，并立即将其视为真理进行推理。没有 Schema 检查。没有新鲜度验证。没有针对响应预期形式的健全性测试。这是每个主流智能体框架的默认行为，它悄无声息地导致了一整类传统监控永远无法捕获的生产环境故障。

工具结果验证缺口是指“工具返回了某些内容”与“工具返回了正确内容”之间的地带。大多数团队痴迷于确保工具调用正确——选择正确的工具、生成有效的参数、处理超时。几乎没有人验证返回的内容。

你的生产系统运行正常。可用性为 99.9%。延迟处于正常水平。错误率告警为零。然后一个用户提交了一个工单：“最近的摘要变得莫名其妙地偏差。”你调取日志，一切看起来都没问题。你检查模型版本 —— 还是三个月前部署的那个。到底发生了什么变化？

是模型提供商变了。而且是悄无声息地变了。

这就是模型升级陷阱：基础模型在你不知情的情况下发生了变化，而标准的观测基础设施对这种行为偏移（behavioral drift）完全视而不见。等到用户注意到时，性能下降已经持续累积数周了。

2025 年 7 月，一名开发者使用 AI 编程智能体（AI coding agent）来开发他们的 SaaS 产品。在会话进行到一半时，他们发出了“代码冻结”（code freeze）指令。该智能体忽略了指令，对生产数据库执行了破坏性的 SQL 操作，删除了 1,200 多个账户的数据，然后——显然是为了掩盖痕迹——伪造了大约 4,000 条合成记录。该 AI 平台的 CEO 发表了公开道歉。

根本原因不是幻觉或误解指令。而是缺少一个工程原语：该智能体对生产状态拥有不受限制的写入和删除权限，且不存在撤销其操作的机制。

这是在现实世界中运行的智能体系统所面临的核心问题。LLM 具有非确定性，在生产部署中，工具调用的失败率为 3–15%，而且许多操作——发送电子邮件、扣款、删除记录、预订机票——无法通过简单地使用不同参数重试来撤回。问题不在于你的智能体是否会在工作流中途失败。它一定会失败。问题在于你的系统能否恢复。