238 篇博文 含有标签「reliability」

在值班文档的表格上，搜索工具的错误率为 2%。事故审查报告称，在三个小时的时间窗口内，Agent 平台的故障率为 20%。没人对这两个数字有异议。搜索团队没有过错。平台团队也没有发布 Bug。这两个数字之间的差距就是故事的全部，而这是一个关于算术的故事，而不是工程能力的平庸。

重试逻辑是 Agent 系统中最常被借用且最少针对性调整的模式之一。团队从他们的 REST 客户端复制 tenacity 装饰器，将它们堆叠在 SDK、网关和 Agent 循环中，然后直接上线。每一层单独看都是合理的。但这种组合就像是一件指向集群中最不稳定依赖项的攻城武器，而且它恰恰在那个依赖项最需要降低负载的时刻开火最猛烈。

本篇文章将探讨这种数学逻辑是如何运作的，为什么 Agent 循环比请求-响应系统更剧烈地放大错误，以及如何通过重试规范防止瞬时波动演变成印着你自己公司 Logo 的关联性宕机事故。

询问一个 Agent 团队他们的工具调用成功率是多少，你会得到一个答案。但如果你问他们的工具幻觉率（tool-hallucination rate）是多少，全场就会陷入沉默。大多数团队并不追踪这一指标，而那些追踪的团队通常也只计算最灾难性的版本——即目录中不存在的函数名——而那些更隐蔽、代价更高的变体则在生产环境中未受监控地运行。

幻觉化的工具调用不仅仅是指模型凭空捏造了 delete_orphaned_users(older_than="30d") 导致你的分发器（dispatcher）抛出 ToolNotFoundError。这是简单的情况。更复杂的情况是，虚假的调用通过模糊匹配隐匿地指向了一个相邻的真实工具，或者工具名称正确，但 Agent 捏造了一个参数，而你的 Schema 因为将其标记为可选而愉快地接受了它。这两种情况都能通过你的“工具调用是否成功”仪表盘，但都不是用户真正想要的。

生产环境 Agent 中最危险的 Bug 不是那些会抛错的 Bug。而是这种：工具描述写着 returns user_id，但后端在两个 Sprint 前悄悄开始返回 account_id，而模型在后续推理中仍在愉快地凭空捏造 user_id —— 因为清单（manifest）是这么写的，Few-shot 历史加强了这一点，而且循环中没有任何环节去获取真实情况（ground truth）。

这就是清单漂移（manifest drift）：工具描述所声称的内容与端点实际行为之间缓慢且无声的分歧。它很少产生堆栈跟踪（stack traces）。它产生的是带有干净审计线索的错误决策 —— 这是 Agent 系统中最糟糕的一类 Bug。

十一个智能体在同一秒内启动。在第一个工具调用返回之前，就有三个阵亡了。那 27% 的失败率不是模型问题、提示词问题或工具问题。这是一个调度问题 —— 就像操作系统在五十个进程同时唤醒并争抢单个 CPU 时所解决的问题一样。区别在于，操作系统拥有四十年的智慧积累，而智能体运行时只有大约两年。

任何连接过超过几个并发 LLM 工作节点的人都见过类似的情况。你在 02:00 启动一个定时任务，三十个智能体同时启动，它们在 200 毫秒内同时请求同一个提供商，结果大多数都以 429、502 和连接重置告终。幸存者只能获得承诺的一半速率配额，因为提供商的公平共享逻辑已经开始对你的 API 密钥进行节流了。到 02:05 时，幸存的智能体运行结束，你的仪表盘显示的完成率足以让一个刚写出第一个生产者-消费者的计算机专业大一学生感到汗颜。你的值班人员会争论是该增加重试、增加队列，还是干脆减少运行数量。

这些方法本身都不是正确答案。正确答案是：一个智能体集群是一个小型分布式系统，需要按照分布式系统的方式进行设计。

每个部署过分布式系统的工程师都曾直面CAP定理并做出抉择：当网络分区时，你是继续提供陈旧数据（可用性），还是拒绝服务直到获得一致的答案（一致性）？该定理告诉你，二者不可兼得。

AI智能体面临着同样的权衡，然而几乎没有人在明确地做出这一选择。当你的LLM调用超时、工具返回垃圾数据、下游API不可用时——你的智能体会怎么做？在大多数生产系统中，答案是：它会猜测。悄无声息地。信心满满地。而且往往是错的。

故障模式并不戏剧化。日志中没有异常。智能体"回答"了用户。两周后才有人问起，为什么系统订了错误的航班、提取了错误的实体，或者自信地告诉客户一个已不存在的价格。

你的 Agent 在隔离测试中表现完美。你对每个步骤都做了基准测试，测量得到每步精确率为 95%。向利益相关者演示时效果很好。然后你上线了，用户反映几乎有一半时间它都会失败。

这个失败不是任何单个组件的 bug，而是数学。

大多数 AI 流水线故障并非模型问题。模型运行正常，输出看起来也是 JSON，但下游阶段却悄然崩溃——原因可能是字段被重命名、类型发生变化，或者嵌套对象新增了一个下游阶段根本不知道如何处理的必填属性。流水线执行完毕并报告成功，而某个数据仓库里的数字已经悄悄出错。

这就是 AI 流水线的契约测试问题，也是生产 AI 系统中最被忽视的可靠性风险之一。根据近期基础设施基准数据，企业 AI 系统平均每月发生近五次流水线故障，每次解决耗时超过十二小时。主要原因并非模型质量差，而是数据质量和 Schema 契约违规：64% 的 AI 风险存在于 Schema 层。

你见过的每一个 Agent 演示都以干净的结果收尾。工具调用返回了模型预期的数据，响应在两秒内到达，最终答案清晰准确。那是演示。生产环境则是另一回事。

在生产环境中，工具会超时。API 会返回 403，因为某个服务账户上周二被轮换了。第三方数据丰富端点返回 200，但响应体写着 {"status": "degraded", "data": null}。OAuth 令牌在周六凌晨 3 点过期。这些不是边缘案例——这是任何与真实世界交互的 Agent 的正常运行状态。失败模式是可预见的。问题在于，大多数 Agent 架构将它们视为事后补救，而大多数 Agent UI 根本没有向用户传达这些失败的词汇。

大多数AI团队能告诉你他们的遏制率——AI在不转交给人工的情况下处理的交互比例。但很少有团队能告诉你这个数字是否合理。

升级标准是AI增强团队中最重要的设计文档，而大多数团队根本没有这份文档。他们有一个埋藏在YAML文件中的阈值，以及一个隐含的假设：AI知道自己什么时候卡住了。这个假设在两个方向上都是错误的：阈值过高，人工就要花时间返工AI的工作；阈值过低，用户在没有任何补救措施的情况下承受AI的错误。两种失败都是隐性的，直到它们积累成大问题。

一个批量推理任务在六分钟后完成。网络在返回响应时发生了抖动。你的重试逻辑开始介入。两分钟后，任务再次完成——而你的账单也翻了一倍。这只是将传统的幂等性思维应用于 LLM 流水线而不根据随机系统进行调整时，所发生的最温和的情况。

大多数生产团队都是通过惨痛的教训才发现这个问题的：本意是为了从瞬时错误中恢复的重试，却触发了第二次付款、发送了重复的电子邮件，或者在数据库中写入了相互矛盾的记录。解决方案不是更好的重试逻辑，而是一个全新的心智模型——当你的核心组件是概率性的时，幂等性究竟意味着什么。

你构建了一个 AI 功能。你跑了评估。你在测试集上看到了 95% 的准确率。你上线了。六周后，用户对它深恶痛绝，你的团队正在悄悄计划回滚。

这就是最后一公里可靠性问题，它很可能是当今生产环境中 AI 功能失败最常见的原因。这与你的模型不好无关，而与平均准确率指标如何掩盖失败分布有关——以及某些失败无论其统计频率如何都会带来高昂代价。

有一种故障模式会在团队解决了幻觉过滤、输出解析、重试逻辑等较容易的问题之后反复出现：模型给出听起来很自信的错误答案，基于置信度的路由逻辑信任了这些错误答案，系统在生产中悄无声息地出现异常，而评估仪表板看起来一切正常。

这不是提示词问题，而是校准问题，它根植于现代LLM的训练方式之中。