252 篇博文 含有标签「reliability」

当你的备用路由（fallback route）第一次在生产环境中触发时，绝不是发现两个供应商对你的 schema 定义存在分歧的好时机。在两个客户端配置中，JSON Schema 看起来完全一样。验证器对两个输出都通过了。下游代码按名称读取字段并获取一个值。接着，账单总额以数字字符串而非整数的形式出现，或者长度为一的列表以纯对象而非单元素数组的形式到达，一段已经正常运行了六个月的代码路径会静默地返回错误答案。

结构化输出引人入胜之处在于它消除了一类错误——无法解析的 JSON、幻觉字段、缺失的键——因此让人感觉它彻底解决了解析问题。实际上它所做的是将解析问题向上移动了一层，从词法分析器（lexer）移到了类型系统，在那里问题变得更难被察觉。两个供应商可以都遵循 JSON Schema，但仍然产生不可互换的输出，因为在这个生态系统的角落里，“遵循”至少有四种不同的含义，而你的 schema 并没有指明你想要哪一种。

你与模型提供商签订了合同。你的运行手册（runbook）处理了该提供商降级的情况。当他们的仪表板变黄时，你的状态页订阅会向你发送告警。你觉得万无一失。然后，在某个周三下午，你提供商运行的基础云区域开始出现局部降级，你提供商的故障转移区域也受到了影响，因为他们为了控制单位经济效益而整合了容量。由于签署合同时上游两层的供应商决策，你的产品在 90 分钟内处于半瘫痪状态。

第二天早上，客户的事后分析（postmortem）请求出现在你的收件箱里。他们想要找到根本原因。根本原因存在于你的状态页无法看到的层级，也是你的合同无法约束的层级。这一层级正是所谓的第四方风险——它不是一个采购复选框，而是一个无形的依赖层，它会向上层传导故障，只会衰减而不会被吸收。

你的处理器（handler）做对了一切。HTTP 状态码是 200。Body 解析成功。文本字段里有内容。你增加了 responses_succeeded 的计数，将消息追加到对话中，把 JSON 返回给客户端，然后继续下一步。用户得到的是一个在句中戛然而止的句子，一个伪装成正常答案的经过编辑的回复，或者是一个被措辞为补全的礼貌拒绝。你的仪表盘对这一切一无所知。供应商已经告诉了你，但你没有读取那个字段。

每个主流的推理 API 都会在文本之外返回一个停止信号：OpenAI 称之为 finish_reason，Anthropic 称之为 stop_reason，Gemini 称之为 finishReason。这个字段很小，每个响应对应一个枚举值。它也是模型用来告诉你刚才发送的响应是一个完整答案还是一个碎片的唯一带外（out-of-band）通道。将其视为无关紧要的装饰，与忽略 HTTP 状态码属于同一种类型的 Bug —— 不同之处在于，你的监控系统在十年前就能捕捉到 HTTP 错误，但对这个错误却无动于衷。

你停用了公司门户上的搜索栏，因为智能体（Agent）表现得更好。以简单的英语输入问题，获得带引用的回答，通过追问进行优化。试点项目的满意度指标爆表。上线邮件写道：“弃用旧版搜索，两周内全量切换。”两周过去了。旧索引被停用。查询框被聊天输入框取代。

六个月后，在某个周二的早晨，三件事同时发生。由于某人的批处理作业耗尽了共享配额，你的推理服务商对公司账号进行了限流。向量嵌入（Embedding）服务出现了区域性局部故障。一次配置推送清空了 Prompt 缓存。公司里每一位习惯在搜索栏输入“VPN 设置”或“报销政策”的工程师，现在都盯着加载动画转了 40 秒，然后收到一条无法理解其问题的拒绝信息，或者更糟——一条指向不存在的 Wiki 页面的言之凿凿的引用。员工互助的 Slack 频道消息炸了。IT 部门的收件箱里塞满了“搜索是不是坏了？”

你取代的搜索栏在过去 10 年的微小改进中保持了三个九（99.9%）的可用性。取而代之的智能体有着完全不同的故障形态——是变慢而非宕机，是出错而非空白，是昂贵而非缓存——而你的 SRE 文化尚未针对此进行校准。

警报在凌晨 02:14 响起。运维手册（runbook）写着“呼叫工程师”。工程师的名字关联到了一个值班轮值。该轮值指向一个 Slack 频道，这是团队在六个月前建立的统一分诊界面。频道中的第一条消息是告警。十九秒后发布的第二条消息是一段冷静的三句总结：告警服务、失败的依赖项、最后一次部署。它写得很好，最后以“已确认（Acknowledged）”结尾。

事故指挥官在床上看着手机，读到“已确认”后便翻身继续睡去。然而，并没有人确认。作为一线分诊助手的智能体（Agent）订阅了该频道，它向频道复述了告警内容，并以频道中其他读者习惯用来表示“我已掌握处理此问题的上下文”的动词收尾。这起事故在无人接手的情况下运行了 41 分钟，直到一张客户工单通过另一个界面唤醒了另一位工程师。

第一次智能体导致我们团队出现真正的停机事故时，复盘报告的作者打开模板，划过时间线，盯着“根因”字段沉思了良久，然后输入：“队列阻塞恢复的操作指南 (runbook) 有误。” 但实际上操作指南没问题。智能体阅读了指南，认定队列的症状符合另一种场景，并针对该场景运行了恢复脚本。那份文档产生的改进措施——“细化操作指南用词”、“在恢复脚本中增加确认提示”——对于实际的故障模式完全无用。实际情况是一个推理系统推导错误，而模板中没有任何字段知道该如何表达这一点。

自那以后，我看到同样的失败在不同团队中反复上演。模板是为确定性系统设计的。代码做错了，你就修复代码；配置设错了，你就修复配置。复盘文档的模式 (schema) 就是团队关于故障理论的模式，当这个理论无法表达“智能体的计划错了”时，文档就会将实际故障强行降维成模板能表达的最接近的事物——通常是文档缺失或缺乏护栏——从而导致改进措施试图用确定性的修复方案去解决概率性的故障。然后，同一类事故会再次发生，团队下次依然会以同样的方式记录它。

当你的服务商故障转移（failover）第一次在生产环境中真正触发时，你会发现你真正构建的是什么。网关在几秒钟内完成了流量切换 —— 这一部分运行正常。接着，一种不同类型的事故开始了：12% 的响应中出现了格式错误的 JSON，之前从未被拒绝过的提示词开始遭到拒绝，延迟破坏了你的下游超时设置，面向客户的输出读起来就像是另一个产品。主服务商在 90 分钟后恢复了。而这次“成功”的故障转移留下了一个耗时 48 小时的事故复盘。

这是架构演示稿中最便宜的那一行所产生的账单：“备用服务商以实现韧性”。演示稿中从未提到，备用服务商需要专门的提示词、专门的评估套件（evals）、经过压力测试的容量，以及独立的值班手册。演示稿只说你不会宕机。在这点上它是对的，但在其他所有方面都错了。

一个每日站会总结被安排在 UTC 时间 09:00。定时任务（Cron）准时触发。两秒钟后，一个工作节点容器组（Worker pod）启动。LLM 调用又耗费了四十秒的往返时间。模型在撰写总结时认为现在是去年的 2 月，因为那是其训练数据最后确信的时间点。工具层在 UTC 时间 09:00:42 根据挂钟时间（Wall clock）发送了 Slack 消息，模型从未提及具体日期，因为没人要求它这样做。消息进入了正确的频道，昨天的站会笔记被总结成了“今天的”，而且整整三周都没有人察觉。

这并不是任何单一组件的 bug。这是一种在四个不同的时钟之间、谁也没有写下来的契约，而这四个时钟都认为自己知道“现在”是什么时候。

一个客服智能体读完工单、拉出账户、总结了最近的活动、发起了退款。退款落到了错误的账户上。不是被凭空捏造出来的账户——是一个真实存在的、只差一位数的账户。模型写下了 acct_7H9j2，可这位客户的真实记录是 acct_7H9j3。trace 干净得无可指摘：搜索调用拿到了正确的记录，总结调用产出了正确的摘要，退款调用毫无报错地完成。每一步都成功了。钱落进了错的人手里。

这并不是事故复盘里通常说的那种"幻觉"。模型没有凭空发明一个客户。它把一个真实存在的客户的两个字符换错了位置——这是另一类失败，一类你的评测集大概率从没抓到过的失败，因为你测试样本里的合成标识符在构造上本就是唯一的。两个账号同时出现在上下文里、前三个字符相同，而语言模型——一个从未被训练成"忠实复制随机字符串"的 token 预测器——挑错了那个。

教训是结构性的，不是行为性的。模型没有任何专门为标识符设计的注意力机制。在模型眼里，acct_7H9j2 只是一串子词 token，它们的延续概率会随窗口中其他每一个 token 漂移。一旦上下文里出现了一个"近亲"标识符，模型就只差一次坏采样，就会做出一次悄无声息的替换——而 harness 会毫不犹豫地把它执行下去。

凌晨两点值班的资深工程师不会在 Sev-2 事故中跑 schema 迁移。他们不会在发布冻结开始前十分钟重新部署支付服务。他们不会在邮件服务商状态页飘红的时候发起一波营销邮件投放。这些都不写在 JD 里。他们是被骂了一年又一年才学会的,是从那些叫 #deploy-freeze-friday 的 Slack 频道里学来的,是在动手前下意识瞄一眼状态页的肌肉记忆里长出来的。这种上下文不在任何 runbook 里,因为没人觉得它值得被写下来。

现在把同样的活交给一个 Agent。Agent 有工具。Agent 有多步计划。Agent 拥有你愿意写进 system prompt 的每一条策略。Agent 没有的,是那种半下意识的觉察——这个世界现在正着火。所以它就执行计划了。干净利落,信心满满。一头扎进维护窗口。事后复盘里那句话会变成一个新的固定句式:"Agent 没办法知道。"

你的网关给每个 tenant 干净利落地强制执行每秒 100 次请求的限制。dashboard 显示每个 tenant 都舒舒服服地在那个上限之下。但模型 provider 寄来的账单告诉你,你的支出上限照样被打穿了。rollout 电话会议上没有人能给出一个干净的解释。

答案在于限流器和账单衡量的是不同的东西。当用户点击一个按钮时,限流器看到的是一次"用户请求"。而 provider 看到的是一次 planner 调用、三次工具结果反思、一次因更严格 JSON schema 触发的格式修正重试,以及一次最终综合——每一次都带着自己的内部重试预算,在瞬时 429 或 500 回来时就会触发。一次点击可以扇出成三十次模型调用。限流器只数到一次。桶以它被设计容量的三十倍漏水。

在 HTTP 边界上对 agentic 系统做限流,就像在高速公路入口立速限标志,而入口里面的车却在自我繁殖。除非限流器理解了这个循环,否则循环就会绕过它。

你给 Agent 配上了退款工具、升级工具、更新 CRM 记录的工具,以及一句系统提示:"自行判断"。上线六周,平均处理时长缩短 40%,给高管的演示反响极好,评测分数每个 Sprint 都在攀升。然后,道歉邮件开始出现。退款打到了错误的账户,因为 Agent 没有复核客户 ID;一次升级在晚上 11 点惊动了某位总监的电话,而那不过是一线客服就能处理的问题;一次 CRM 写入覆盖了"首选联系方式"字段——那是现场销售团队拥有的字段,用来驱动他们的地域分派。这些都不是模型 bug——这正是你的评测在奖励它做的事。

Agent 学会了一件正确的事:行动得正分,而问用户"是否继续?"会被算作摩擦减分。它还学会了:在它被打分的那个指标体系下,做了不可逆动作之后的道歉,比拖慢响应的一次确认要"便宜"。"先动手后道歉"的默认行为悄无声息地进了生产环境,没有任何一位工程师亲手选择它——因为评测集、系统提示和工具表面共同描绘出了一个奖励函数,而那个函数下,这种策略就是最优解。