278 篇博文 含有标签「reliability」

一个运行时间较长的 Agent 在第 3 步生成了一个计划。计划的内容大致是：“如果第 1 步中 get_order 返回的订单状态为 shipped，则向客户发送一封物流追踪邮件；否则开启退款工单。”Agent 自信地选择了邮件分支。但客户从未收到追踪号码，因为订单实际上处于 pending 状态。你查看 Trace，期望能发现幻觉。但你发现的情况更糟：第 1 步的工具结果已经不在上下文中了。Pruner 在第 2 步和第 3 步之间将其剔除了——因为它在最近性排名中较低，而且为了给 12KB 的对话记录腾出空间。计划仍在运行。分支仍被选中。现在的决策指向了一个根本不存在的证据。

这在通常意义上并不是模型失败。模型生成了语法正确的计划，按顺序执行，并做出了分支决策。分支是基于一个曾经在上下文中但现在已不在其中的事实做出的。思维链编码了条件（if status == "shipped"）；而实际的状态在传递到需要它的步骤时被丢弃了。计划看起来是确定性的，但它已经被悄悄地从证据中剥离了。

你添加了搜索工具，接着是日历工具，然后是 CRM 工具，接着是四个数据库封装器（wrappers）和一个计算器。仪表盘的变化正如你所愿：任务完成率上升，延迟保持稳定，“我不知道”率从 14% 下降到 4%。这看起来像是能力的提升。事实并非如此。规划器并没有学到更多知识；它只是学会了减少拒答（abstention）。现在每个问题看起来都是可以回答的，因为总有 某个 工具的模式能与查询充分匹配并被调用。你消除的那 10 个百分点的“我不知道”并没有转化为正确的答案 —— 它们变成了自信的错误答案，分布在无人仔细评审的长尾场景中。

这就是工具表面扩展带来的“伪能力陷阱”（false-competence trap）。这是团队在庆祝改进时，发布了性能退化（regression）最常见的方式。评估准则衡量的是 Agent 是否尝试了任务并产生了一个形状合理的答案；它并不衡量 Agent 是否应该拒绝回答。拒答并非没有成本，但它是目前能获得的最廉价的正确行为，而一旦你的工具集变得足够大，以至于总有 某个 工具会被触发，你就再也看不见这种行为了。

集群完全按照我们的指令行事。流量在 45 秒内降至零，队列深度指标也归于平寂，KEDA 将副本数从 1 改为 0，90 秒后，节点自动扩缩容工具回收了 H100 Pod。图表看起来很干净。Slack 频道一片寂静。成本看板上的数字跳低了半美分。

一小时十二分钟后，一封客户支持工单送达：一个长时间运行的文档分析任务——一个预算为 28 分钟解码时间的 180k-token 推理任务——消失了。客户端 SDK 没报错。应用程序日志没异常。只有网关访问日志中埋着的一行 499，时间戳大致就在调度器判定 Pod 空闲并将其回收的时候。

一个超级用户在第三天早上 9 点就耗尽了你的月度 token 预算。熔断机制（kill-switch）准确触发——网关返回 429，模型停止调用，账单停止增长。与此同时，智能体（agent）已经订好了机票，发送了确认邮件，并将支持工单标记为已解决。仪表盘显示“支出已停止”。用户却问：“为什么要为我从未要求的行程扣费？”两者都没错。预算上限阻止了模型思考，但它没能阻止世界的改变。

这是几乎每个智能体预算护栏都会携带的失效模式：上限信号位于 支出 平面，但损害发生在 行动 平面，而这两个平面在连接时并没有共享的事务边界。告诉模型停止并不等同于告诉世界撤销模型刚刚所做的一切。

传呼机在 UTC 时间 14:02 响了。不是因为延迟，也不是因为错误——而是因为开销。费用仪表盘显示出一条垂直线：三分钟的输入 Token 计费大约是过去一小时平均水平的九倍，然后又恢复了正常。没有发布回归版本。没有新租户上线。流量精确到分钟来看都是平稳的。唯一改变的是，一个单一的 Prompt 前缀——集群中每个 Agent 共享的 14K Token 系统消息——在提供商端悄悄过期了，一千个 Worker 全都在同一个 200ms 的窗口内认定，自己就是那个需要将其写回的人。

这就是缓存雪崩（Cache Stampede）。这是自 2003 年 memcached 发布以来，运维人员一直在写事故复盘报告的那个老问题。2026 年的新变化在于，发生雪崩的缓存不再属于你。它存在于你的模型提供商内部，你无法检查其状态，而且每一次未命中（Miss）消耗的是真金白银，而不仅仅是几次额外的数据库查询。数据库工程师在二十年前就学会通过抖动（Jitter）来化解的同步 Bug，已经悄然出现在了一个没人想过要防御的账单细目中。

一位用户询问我们的支持智能体：“为什么发票 INV-2025-08-44719 在 4 月 3 日被扣了两次款？”45 分钟和 18 次工具调用之后，智能体自信地回复道：该账户在该季度没有任何重复计费的证据。用户理所当然地投诉了。当我们回放追踪记录（trace）时，答案变得显而易见。智能体在第九轮对话时对内容进行了压缩（compacted）。摘要显示用户“在询问 4 月初的一笔重复收费”。其中并不包含字符串 “INV-2025-08-44719”。随后的每一次工具调用——账本查询、退款 API 查询、审计日志扫描——都是针对转述后的意图发出的，而不是用户输入的字面意义上的发票编号。

Bug 不在工具里，也不在模型的推理中。问题在于我们的上下文管理器（context manager）与每个下游组件之间都有一个契约，但没有人把它写下来。契约写着：“我会保留语义。”而组件需要的是：“我会保留字符串。”

CI 测试只有一个断言：相同的模型、相同的温度、相同的提示词、相同的种子（seed）、相同的输出字符串。它在每个开发者的笔记本电脑上都通过了，在前一百次 CI 运行中也通过了，但在三周内每五十次运行就会出现一次随机失败（flake），直到最后有人承认这种模式是真实存在的。第一个假设是显而易见的——测试工具中某处存在非确定性依赖——三天的调查却一无所获。实际原因隐藏在供应商 API 参考文档的一个脚注中：“seed 提供尽力而为的确定性。”团队读到了参数名称，并将其视为一种契约。而供应商记录的只是一个提示。

这是托管推理的一种特定失败模式，它困扰着那些围绕单一心智模型设计测试基础设施的团队：模型是其输入的纯函数，而 seed 是使函数具有可重现性的关键。在生产环境中，这个模型的这两个部分都是错误的。API 表面与底层物理原理之间的差距如此之大，以至于团队在供应商明确否认的假设之上，构建了整个评估和回归测试栈。

升级工具曾是最后一道安全网。当智能体的置信度降至阈值以下时，它会调用 escalate_to_human，随后请求滑入工单队列，并向用户礼貌地回复“专家稍后会跟进”。工程团队在发布清单上完成了闭环确认。值班表上也列出了负责接收的人员。

六个月后，一次审计对该路径进行了回溯。升级工具打开了一个 Zendesk 工单。Zendesk 队列由客服团队为了维持 SLA 响应时间而设立的预审智能体进行分拣。预审智能体由于找不到可以直接解决的政策匹配，调用了自己的 delegate_to_specialist 工具——该工具将案例路由给了一个专家智能体。而专家智能体在不确定时，又调用了 escalate_to_human。追踪轨迹形成了一个闭路。审计抽样调查的升级案例中，没有任何人类接触过。发布文档中描述的人机协作（human-in-the-loop）实际上并不存在。

升级接口并没有失败。它的每一次跳转都得到了执行。失败的是“接收系统是自然人”这一假设。

Agent 调用 fetch_order，参数为 order_id: "ORD-739241"。Schema 接受了它 —— 三个字母、一个连字符、六位数字，完全符合模式。工具返回了 404。Agent 开始含糊其辞，生成了 "ORD-739242" 并再次调用，又得到一个 404，接着又生成了 "ORD-739243"。你的仪表盘记录了三次成功的工具调用和三次干净的 Schema 校验。客户在等待。在追踪记录的某个地方，安全栈的每一层都报告为绿色，而模型正在全速虚构标识符。

团队认为 Schema 拦截了错误。Schema 确实拦截了它能拦截的东西：形状（shape）。它检查了参数是否为字符串，是否匹配正则表达式，以及必填字段是否存在。Schema 无法检查 ORD-739241 是否对应数据库中的真实订单，因为 Schema 根本不知道数据库的存在。这种差距 —— 句法上的合理性与语义上的正确性之间 —— 正是大多数生产环境工具调用 bug 的所在地，而且这种失败非常隐蔽，唯一的信号就是客户的困惑。

运维手册上写着“禁用代理”。值班人员照做了。43 分钟后，当紧急开关终于通过配置服务传播开来时，该代理已经提交了 1,200 张错误的工单，调用了 8,000 次计费 API，并向根本没有订阅任何服务的客户发送了邮件。运维手册是正确的，但它也是徒劳的，因为没有人衡量过当代理每秒钟都在造成破坏时，“禁用代理”实际上需要多长时间。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E5%B8%A6%E6%9C%89%E5%BB%B6%E8%BF%9F%E9%A2%84%E7%AE%97%E7%9A%84%E7%B4%A7%E6%80%82%E5%BC%80%E5%85%B3%EF%BC%9A%E4%BD%A0%E7%9A%84%E6%95%85%E9%9A%9C%E5%A4%84%E7%90%86%E4%BB%8E%E6%9C%AA%E8%BE%BE%E6%A0%87"]

大多数 AI 功能都配有紧急开关，就像大多数建筑都配有灭火器一样：有人签字确认它的存在，却没人计时到达它需要多久。合规审查会问“是否有紧急开关？”，答案是肯定的。而故障现场会问“止血有多快？”，答案则取决于底层管道恰好需要的时间——团队中从未有人针对该功能造成破坏的速度测量过这个数字。

这种不匹配正是问题的核心。一个遏制时间长于其破坏扩散时间的功能，交付的只是“遏制剧场”（Containment Theater）。

AI 平台团队有四名工程师。他们七个月前发布的内部 Agent 现在每天为 200 名员工回答问题。在第一个月，创始工程师亲自处理了每一个 Slack 消息——周二晚上 11 点，周日上午，甚至公司团建的晚上。随后，她因推动采用率方面的贡献而晋升为资深工程师（Staff Engineer），三周后，她在下午 6 点后就不再查看频道了，因为那是资深工程师该做的。原本打算取代她的值班轮换（on-call rotation）从未正式化，因为运营模式总是打算在“试点之后”再解决。

当 Agent 针对四分之一的用户静默降级的那天——一个悄然落后的检索索引，或者改变了拒绝行为的模型版本切换，或者是架构轮换后现在返回空数组的工具——投诉并不会降临到平台团队的传呼机（pager）上。它们落在帮助台队列中，由那些无法访问 Agent 追踪（traces）、不知道什么是系统提示词（system prompt）、并且被 IT 部门告知该 Agent “由 AI 团队负责”的人员处理。从第一个用户投诉到第一位工程师查看 trace，中间过去了 16 个小时。平台团队没有人玩忽职守；只是根本就没有人在执勤。

用户正与你的助手进行一场关于受控物质处方模式的谨慎对话，已经进行了十二轮。模型表现得很有分寸，提出澄清性问题，引用指南，并拒绝进行文献之外的推演。在第十三轮，用户提出了一个后续问题，按理说应该得到与前十二轮相同的回应。然而，他们得到的却是一个生硬的拒绝：“我无法提供相关帮助。”对话结束了。他们怒气冲冲地给支持团队写信——他们并没有问任何不同的内容，助手刚才还在帮助他们，到底发生了什么变化。

你的日志解释了变化的原因。在第十三轮进行到一半时，你的主供应商在流式传输过程中返回了 503 错误。你的网关按照配置执行了操作：在请求的剩余部分故障转移（failover）到了备用供应商。备用供应商对该类查询的拒绝阈值校准得比主供应商更保守。用户并没有问任何不同的问题——他们在同一个品牌下对不同的模型提出了相同的问题，而新模型说了“不”。