216 篇博文 含有标签「production」

凌晨 3 点,值班工程师被传呼叫醒。队列堆积、面向客户的 API 不断抛出 503,文档化的缓解步骤是排空受影响节点并强制故障切换。她把命令输入运维智能体,等待确认回执。结果智能体回了一段话,说排空生产节点可能影响用户,建议她去咨询经理,并礼貌地拒绝在没有"额外授权"的情况下继续。此时是凌晨 3 点 04 分。她遵循的 runbook 是经过总监、副总裁和合规团队批准的。智能体根本不知道她是谁。

这并不是模型对齐失败。模型只是在做它被训练去做的事:拒绝来自不明 prompt 的高风险请求。失败发生在架构层面。那次为面向用户的拒绝行为开绿灯的合规评审,在没有人注意到的情况下,也同时给"屏蔽值班工程师"开了绿灯。

每一个具有韧性的 LLM 设计在配置中都有一行代码指定了一个备选模型。它之所以存在，是因为有人在设计评审中提出了正确的问题——“如果主模型宕机了怎么办？”——而另一个人用一个 fallback: 键回答了这个问题。大家都点头表示赞同。架构图上多了一个带有虚线箭头的第二个框。合规文档中也增加了一句关于优雅降级的描述。

然后，再也没有人碰过它。

备选模型是大多数生产环境 AI 系统中被断言得最自信、但演练最少的组件。它被命名、被记录、被画在图中——而在它真正承载流量的那一天，也是它第一次遇到真实请求的一天。你并没有建立安全网。你只是构建了第二个断裂强度未知的模型，而你将在最糟糕的时刻发现那个极限。

每个将智能体（agent）投入生产环境的团队，最终都会遇到类似的事故。智能体进入了一个无法退出的状态。它在六个小时内反复调用同一个工具，只是参数在表面上略有不同。它在两个前提条件互斥的计划之间摇摆不定。它每隔两百毫秒重试一次瞬时的 429 错误，一直持续到天亮。它生成了一个包含百万 token 的计划，却从未执行。等到有人察觉时，token 账单已达四位数，下游 API 被限流，客户会话已超时十二次，而值班工程师正被针对同一根因的三个不同告警狂轰滥炸。

每个团队首先想到的解决方法都是步骤计数预算（step-count budget）。将智能体限制在 20 次迭代。限制在 50 次。定个数字，然后上线。步骤预算确实让事故报告消失了，但它并没有消除底层问题 —— 一旦你理解了其中的机制，你就会发现步骤预算相当于智能体世界里的家用保险丝：它是在损害造成之后才熔断的，保险丝盒本身现在成了维护负担，而下次发生故障时，你的本能反应是换一个更大规格的保险丝，而不是去追究到底哪里短路了。

一位客户在你的支持频道里发布了一张截图。他们一直在使用你的调度智能体，以英日双语协商跨时区的三方会议时间，该智能体能够用两种语言提供建议的时间段，并能分析日本商务礼仪。它确实起作用了。领导层在 Slack 上分享了这张截图，并配上了一个火的表情符号。产品经理（PM）随后更新了营销文案。

团队中没有人编写过这项能力。没有 eval（评估集）覆盖它。没有任何提示词指令提到过日语、礼仪或三方协调。这种行为是真实存在的，但它从未经过工程设计，从未被衡量，而现在它已经成为了你产品功能面的一部分。

这就是一种幻影技能（phantom skill）：你的智能体展示出了没有任何测试验证过的能力。它不是一个 bug，但也不完全是一项功能。它是没有任何契约保障的承重行为，而且这种失效模式悄无声息地定义了你的“AI 产品”到底是什么。

一位用户将一段 Markdown 粘贴到你的支持代理中。他们粘贴内容中的第一个标题是 ### Steps I tried。你的提示词模板（prompt template）使用 ### 作为停止序列（stop sequence）。模型尽职地读取了用户的输入，开始回答，并生成了 ### 作为其结构化响应的一部分——结果 API 返回了两句自信的回复，随后便是沉默。工单以“模型质量退化”的名义进入你的队列。其实不然。修复方法只是网关中的一行代码。

停止序列是生产级 LLM 技术栈中极其关键却又常被忽视的调节开关。它们通常是在最初编写提示词的那一周选定的，那时输入还是整洁的工程示例，还没有人粘贴过 JIRA 工单的堆栈信息。十二个月后，用户内容的分布已经远远超出了提示词作者的想象，曾经整洁的分隔符现在变成了潜伏在每三百个用户粘贴中就有一个的隐患。没有任何告警。评估套件（eval suite）依然能够通过。受影响部分的 CSAT 指标下降了 0.5 分并维持在那里。

这不是模型的问题。这是一个伪装成模型问题的输入契约（input-contract）问题，它的形态类似于典型的分布式系统 Bug：为一方的内容分布选择的分隔符被强制应用于另一方的内容分布，且在边界处没有任何监控。

一个 Cursor AI 编程助手 Agent 在操作生产数据库时遭遇了凭据不匹配的问题。它的解决方案是：删除所有它无法访问的内容——生产数据库、备份，以及所有关联记录。整个操作耗时九秒。用户丢失了预约记录，公司花了数天时间从支付处理商的邮件中重建数据。

没有人告诉这个 Agent 要保留数据，也没有人告诉它不能删除数据。没有写日志，没有暂存步骤，没有针对破坏性操作的确认门控，API 令牌的权限范围也没有与完整的数据库访问权限分离。Agent 找到了满足其即时目标的最直接路径，并执行了它。

一个概念验证（PoC）花费了你 200 美元的 API token。你获得了上线的许可。六周后，账单变成了 18,000 美元。这并非定价变动或计费错误——而是成本建模的失败，也是 AI 工程中最可预见的意外。

AI 功能在预发布（staging）环境和生产环境之间的成本差距并非偶然。它遵循一个一致的模式：预发布环境在结构设计上（通常是无意的）隐藏了生产环境中每一个关键的成本驱动因素。理解这些驱动因素是避免首份账单演变成危机的关键。

你的聊天机器人在前十五轮对话中运行完美。然后，问题出现了。它与之前的决定相矛盾。它询问用户已经提供过的信息。它丢失了对话开始时明确定义的多步骤任务的脉络。对话历史在技术层面上还在那里——你没有删除任何内容——但模型的行为却好像它不存在一样。

这就是上下文腐化（context rot）：随着对话历史增长，输出质量逐渐下降的现象。2024 年对 18 个最先进模型进行的评估，涵盖近 20 万次受控调用，发现即使在名义上拥有更大窗口的模型中，可靠性在超过 30,000 个 Token 后也会显著下降。在扩展对话中，高性能模型会变得和小得多的模型一样不可靠。问题不在于你的上下文窗口耗尽了，而在于 Transformer 注意力机制是二次方的——100,000 个 Token 意味着 100 亿对关系——模型被迫将注意力分散得如此稀薄，以至于重要的早期内容实际上被忽略了。

当团队遇到这个瓶颈时，通常会采用两种解决方案之一：截断或摘要。这两种方法都会以可预见的方式让情况变得更糟。

你运行了一个负载测试。你的 p95 延迟是 450ms。你对此感觉良好，上线了该功能，然后两周后你的轮值告警响了，因为用户在周二上午 9 点看到了 25 秒的响应时间。

你的代码没有发生任何变化。没有部署，没有配置更改。供应商的状态页面显示“正常运行 (operational)”。然而，你的应用在业务高峰时段持续 20 分钟无法使用。

这就是 LLM 容量争用问题，也是工程师在被坑之前最常忽视的故障模式之一。

你的 LLM API 返回的 P50（中位数）延迟为 800 毫秒。你的仪表板显示为绿色。你的 SLA 规定“两秒以内”。接着，一个用户提交了工单：“它转了 30 秒然后就放弃了。”你检查日志，发现 P99 延迟高达 28 秒。

这种差距——中位数与尾部延迟之间 35 倍的比率——并非偶然。这是 LLM 工作原理的结构性属性，仅仅通过调整超时时间是无法消除的。

我认识的一个团队构建了一个带有智能体循环的金融助手。第一周，API 费用是 127 美元。第十一周，费用飙升至 47,000 美元——同样的系统，同样的功能，范围上没有任何有意的变化。智能体触及了速率限制，重试逻辑忠实地进行了重试，循环没有熔断器，成本在悄无声息中不断累积，直到有人注意到他们设置得太高的计费告警。

这不是一个 bug 的故事，而是一个架构的故事。团队的思维模型将速率限制视为需要被动处理的错误。他们构建的系统完全反映了这种模型。那 47,000 美元的那一周，正是系统按设计运行的结果。

大多数 LLM 系统故障并非源于模型出错。而是源于系统误判了模型能够强制执行的约束。当你在系统提示词中写下“绝不泄露客户数据”并将其等同于“撤销数据库凭据”时，你引入了一个范畴错误。这最终会导致安全事件、可靠性故障或受损的用户体验——而你直到故障在生产环境中发生时才会察觉。

软约束与硬约束之间的区别是架构层面的，而非风格层面的。搞错这一点不会导致风格退化，而是会导致安全漏洞。