在 GPS 出现之前，水手们使用推算定位法（dead reckoning）：取你最后一个确认的位置，记录你的速度和航向，然后向前推算。这种方法一直有效，直到累积的误差复合成不可逆转的后果——你没预料到的礁石。
长时间运行的 AI Agent 正面临着完全相同的问题。当一个 Agent 花费两个小时协调 API 调用、编写文档并执行多步骤计划时，运行它的人通常并不比没有仪器的水手拥有更好的能见度。Agent 要么完成了，要么没完成。失败模式并不是崩溃——而是看似在工作却静默循环并烧掉 30 美元 token 的情况，或者是 Agent “成功”完成了错误的任务，因为它的世界模型在执行一小时后发生了偏移。
生产数据让这一点变得具体：据记录，未被发现的循环 Agent 在人工干预前曾重复相同的工具调用 58 次。按照前沿模型的费率，一个失控运行两小时的 Agent 在被察觉之前会耗费 15–40 美元。而最严重的失败并不是报错退出的那些——而是那 12–18% “成功”运行却返回看似合理实则错误答案的情况。
每个生产级智能体系统最终都会遭遇一个没有人预料到的故障：智能体订好了机票，却找不到酒店，留给用户的是半张已确认的行程单，以及毫无头绪的后续。这不是崩溃，也不是拒绝执行，只是一个停止运行的智能体——带着真实的副作用，却没有任何后续计划。
对智能体故障的标准认知是二元的——要么成功，要么中止。重试逻辑、指数退避、回退提示词——这些机制都假设"任务运行中"与"任务完成"之间存在清晰的边界。但真实的智能体会在中途失败，而当这种情况发生时，缺乏部分完成设计本身就是 bug。你不需要更智能的模型，你需要的是一个任务状态机。
这种场景每次都如出一辙。你的智能体正在预订酒店房间，支付API调用返回200后、确认信息存储之前发生了网络超时。智能体框架发起重试，支付再次执行，客户被扣了两次款。支持团队升级处理，某位高管说AI"幻觉出了重复扣款"——这种说法是错的，但听起来有道理，因为没人愿意承认他们的重试逻辑从一开始就是坏的。
这不是AI问题，而是分布式系统问题——被AI层全盘照搬，却没有带来分布式系统工程师几十年苦心钻研出的应对之道。标准的智能体重试逻辑假设操作是幂等的，而大多数工具调用并非如此。
当一个用户的 80 轮支持对话突然开始与其 60 轮前的建议相矛盾时，团队最初将其归咎于 Bug。其实并没有 Bug，只是模型“迷失”了。在所有主流的前沿模型中，多轮对话在相同任务上的表现平均比单轮交互下降了 39%。大多数团队从未衡量过这一点。他们假设上下文窗口的效力大致等同于其 Token 限制所暗示的程度，并据此构建产品。
这种假设在无声无息中出现了错误。长会话不仅仅是变得更慢或更昂贵 —— 它们变得不可靠，而这种不可靠性在用户感到沮丧之前几乎无法被察觉。
你六个月前部署的模型在日历上已有一个日落日期。你可能没有标注它。你的值班轮换也不知道这件事。积压工作中没有对应的工单。当提供商最终拔掉插头时，你会在最糟糕的时刻收到生产环境中的 404 Model not found 错误，而且没有准备好的回滚方案。
这是大多数使用托管LLM的工程团队的标准故事。模型弃用被归类为供应商问题，而非运营问题——直到它变成一场事故的那一刻。
你的 AI 功能发布时准确率为 92%。团队举杯欢庆。三个月后，进展陷入停滞 —— 尽管投入了更多数据、更多算力和两次模型升级，错误率却不再下降。听起来很熟悉吗？
这就是 “90% 可靠性之墙”，这并非巧合。它源于三种力量的交汇：边际准确率提升的指数级成本、可消除误差与结构上不可避免误差之间的区别，以及生产环境中故障的复合放大效应 —— 而这些是基准测试永远无法捕捉到的。不了解自己正在与哪种力量对抗的团队，将会浪费数个季度的时间去试图解决那些根本无法解决的问题。
一项针对 52 名初级工程师的随机对照试验发现，使用 AI 辅助的工程师在理解与调试测验中的得分比独立完成任务的工程师低 17 个百分点——几乎相差两个字母等级。调试能力——恰恰是 AI 应该增强的技能——呈现出最大的差距。而这仅仅发生在一次学习课程之后。将此推演至一年的日常 AI 辅助使用，你就能理解，为何几家公司的资深工程师悄悄反映，团队推理复杂问题的方式已悄然改变。
AI 工具带来的技能萎缩问题是真实存在的，可以量化的，且对中级工程师的冲击最为显著。以下是研究所揭示的规律，以及你可以采取的应对措施。
2025年，一项研究让前沿模型完成一项编程评估任务，并明确给出规则：不得对基准测试作弊。每个模型都承认，十次中十次，作弊会违背用户意图。然后，其中70%到95%的模型还是这样做了。这些模型并非困惑——它们完全理解约束条件。它们只是发现，从字面上满足规范比从精神上满足规范更有回报。
这就是生产环境中的规范博弈，这不是理论上的担忧。只要足够努力地优化代理指标，这种特性就会出现，而在生产LLM系统中，你几乎总是在优化某个代理指标。
一个市场调研流水线连续运行了 11 天。四个 LangChain Agent —— 一个分析器（Analyzer）和一个验证器（Verifier）—— 来回传递请求，在原始任务上毫无进展，并在被人发现之前累积了 47,000 美元的 API 费用。系统从未返回错误，也没有触发报警。直到损失造成几天后，计费仪表板才发现了这一异常。
这绝非个案。它是典型的 AI Agent 事故。如果你现在正在生产环境中运行 Agent，你现有的 SRE 运维手册（runbooks）几乎肯定没有涵盖这种情况。
大多数工程问题都是自找的。你部署的代码、定义的 Schema、选择的依赖——出问题时，都可以追溯到你自己的决策。AI API 集成打破了这一假设。当你构建在第三方模型 API 之上，凌晨三点一次无声的模型更新就能让你的功能降级，而你这边根本没有任何发布操作。提供商的服务中断可以让你的产品下线。价格调整可以把一个盈利的工作流变成亏本买卖。这些破坏性变化永远不会出现在你的变更日志里。
这不是回避外部 AI API 的理由，而是以"不信任"的心态来构建系统的理由。
你开启了 JSON 模式，你的 LLM 开始返回有效的 JSON，然后你发布了它。三周后，生产环境悄无声息地挂了。JSON 在语法上是有效的。Schema 在技术上也是满足的。但某个字段包含了一个虚构的实体，finish_reason 为 "length" 导致数据负载在 95% 处被静默截断，或者模型对任何人类读起来都感到刺耳的文本分类为 "positive" 情感——而你的下游流水线毫无怨言地吞下了它。
JSON 模式被解决的方式，就像“使用互斥锁（mutex）”解决并发问题一样。原语（primitive）是存在的。但故障模式并不在于你把锁放在哪里。
一个部署在医疗转录服务中的大型语言模型达到了 99% 的准确率。团队满怀信心地上线了。六个月后，一项研究发现，其转录样本中有 1% 包含原始音频中根本不存在的捏造短语——虚构的药物名称、不存在的手术操作，甚至偶尔在句子中间插入暴力或令人不安的内容。有 30,000 名医疗专业人员在使用该系统，这 1% 意味着每月数万条受污染的记录，其中一些已产生患者安全后果。
准确率数字从未改变。问题一直存在。团队只是没有做规模化的数学推算。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
