你的智能体通过了每一项测试。CI 流水线显示绿色。你发布了它。
一周后，一位用户报告说他们的批量导出任务悄无声息地只返回了 200 条记录，而不是 14,000 条。智能体访问了分页 API 的第一页，得到了一个干净的响应，以为没有更多内容了，然后就继续下一步了。你的模拟（Mock）一次性返回了全部 200 个条目。而真实的 API 从未告诉智能体还有另外 70 页。
这不是模型的失败。模型的推理是正确的。这是测试基础设施的失败 —— 这种现象在团队构建和测试智能体系统（agentic systems）时非常普遍。
大多数 AI 产品复盘都聚焦于同一个故事：模型错了，用户发现了，信任瓦解了。修复方法显而易见——提高准确率。但有一种更隐蔽的失败模式，复盘很少能捕捉到，因为标准的准确率指标无法反映它：模型是正确的，但原因却是错误的，而那些检查了推理逻辑的高级用户再也没有回来。
称之为“过度声明陷阱”（overclaiming trap）。在这种失败模式下，正确的最终答案是由捏造的、事后修补的或结构不合理的推理链支撑的。它比普通的错误更危险，因为它看起来像是成功，直到你最专业的用户开始悄悄离开。
你的 AI Agent 运行得一切正常，直到某一刻它彻底不行了。某个工具宕机——也许是搜索 API 触发了限流，也许是数据库响应迟缓，也许是代码执行沙箱超时——整个 Agent 随之崩溃。不是部分答案，不是降级响应，而是彻底失败。要么一片空白，要么满是幻觉。
这不是一个 Bug，而是一个设计选择——而且几乎没有人是刻意做出这个选择的。我们今天所构建的 Agent 架构隐式地选择了"彻底失败"，原因只有一个：没有人设计过部分可用路径。如果你有分布式系统的经验，这个模式应该让你感到似曾相识。这正是 CAP 定理，以一副新的面孔出现了。
你的 Agent 完成了一个 25 步的研究任务。最终报告看起来很精美，引用也能对上，推理链条看似连贯。但 Agent 在第 3 步幻觉了一家公司的创立年份，而后续的每一个推断——市场时机分析、竞争定位、增长轨迹——都建立在那个错误的日期上。输出结果自信地、系统性地错了，而你的流水线中没有任何环节捕捉到这个问题。
这就是级联上下文污染：一个错误的中间结论通过后续的推理步骤和工具调用不断传播，最终演变成系统级故障。这是长时运行 Agent 中最危险的失败模式，因为它看起来像是成功的。
你的智能体通过了所有单元测试，完美处理了正常路径，然后在某个周二下午，它试图调用 get_user_preferences_v2——一个在你的代码库中从未存在过的函数。这个调用在语法上看起来完全正确。参数也很合理。唯一的问题是，你的智能体凭空捏造了这一切。
这就是幽灵工具调用：一种不表现为错误文本而表现为错误操作的幻觉。与人类可能在审查中发现的事实幻觉不同，幽灵工具调用会直接命中你的运行时，抛出一个晦涩的 ToolNotFoundError，并使原本运行正常的多步骤工作流脱轨。
2024年，加拿大航空的聊天机器人凭空发明了一项并不存在的丧亲票价退款政策。法院裁定该公司须对机器人的言论负责。根本原因并非传统意义上的模型幻觉——而是优先级反转。系统提示写着"乐于助人"，实际政策写着"遵循已记录的规则"。当用户询问赔偿问题时，模型悄悄地将"高效解决问题"置于"升级投诉"之上，而没有人在这一判断影响公司之前对其进行审计。
这就是利益相关者提示冲突问题。每个生产级LLM系统都至少有三个指令来源：平台层（安全约束和基础模型行为）、业务层（运营商定义的规则、合规要求、品牌声音）以及用户层（实际请求）。当这些层相互矛盾时——它们终将矛盾——模型会选出一个胜者。问题在于，这个选择是由你的工程团队有意为之，还是模型在无人察觉的情况下自行决定的。
一支工程团队构建了一个处理客户请求的 Agent。演示效果非常好。他们将其部署上线。三周后，这个 Agent 悄无声息地以十足的自信向用户传达错误信息，在上下文变长时跳过步骤，还会在模糊输入上偶尔陷入死循环。事后复盘发现，团队从未构建重试逻辑，从未验证输出，也从未定义 Agent 在不确定时该怎么做。当被问及原因，答案耐人寻味："我们以为它会自己处理那些边缘情况。"
"我们以为它会自己处理那些边缘情况"——这句话将拟人化税表露无遗。团队设计这个系统的方式，就像管理一名初级开发者：简要说明任务，信任其判断，等它举手求助时再纠正。但 LLM Agent 不会举手。它们只是生成下一个 token。
你的智能体完美地完成了第一步到第六步。第七步与第二步相矛盾。第八步幻觉出了一个并不存在的工具。第九步自信地提交了垃圾内容。没有程序崩溃，没有抛出错误。智能体只是忘记了它正在做什么 —— 并且无论如何都在继续。
这就是上下文窗口悬崖（context window cliff）：即 AI 智能体积聚的上下文超过其有效推理能力的时刻。它不会优雅地失败，也不会寻求帮助。它会基于部分信息做出自信但错误的决策，而你直到损失造成才会察觉。
你的模型写出了一份详细、结构清晰的分析报告。每个句子在语法上无懈可击，内部逻辑自洽。它引用的具体事实也都是准确的。然而结论却是错误的——不是因为模型缺乏得出正确结论所需的信息，而是因为它在开始推理之前就已经决定好了答案。
这不是幻觉。幻觉是模型凭空捏造事实。伪造问题更为隐蔽，在生产系统中也更难被发现：模型先得出结论，再构建一条听起来合理的证据链来支撑它。事实是真实的。综合分析却是谎言。
大多数构建 AI 代理的团队都在为成功而设计。他们衡量成功率，为代理自主处理 90% 工单而欢呼雀跃，然后在 UI 角落放一个"点击此处覆盖"按钮来应对剩余的 10%，之后便一走了之。
这个按钮不是安全网。它是一种包装成功能的责任。
失败模式不是代理崩溃，而是名义上负责的人类在崩溃发生时无法接管。AI 逐渐吸收了任务——每次一个工作流，每次一个边缘案例——直到过去处理这些任务的操作员已经六个月没碰过它，失去了上下文，却被迫应对一个他们已经无力管理的实时状况。这就是温备问题，它会悄无声息地积累，直到某次事故将其暴露出来。
你的监控仪表板一片绿色。响应时间看起来正常。错误率接近于零。然而你的用户却在提工单投诉垃圾回答，你的 agent 正在做出自信满满的错误决策，你的客服队列里塞满了与任何基础设施告警都不相关的投诉。
欢迎来到在生产环境中依赖 LLM API 的独特地狱。这是一个能在返回完美健康的 200 OK 的同时让你翻车的上游服务。
大多数线上故障的失败，并非因为缺乏工具，而是因为值班工程师在最需要的时刻无法快速获得足够的上下文。凌晨三点，工程师被一墙的触发告警惊醒，先花 20 分钟拼凑出到底哪里出了问题，再花 20 分钟判断该用哪份运维手册，等到真正开始执行修复时，故障已经持续了将近一个小时。而实际的修复动作可能只需要 5 分钟。
AI 能够将这个上下文收集窗口从 40 分钟压缩到 2 分钟以内。这才是真正摆在桌面上的价值。但"LLM 帮助值班工程师"并不是一个单一的产品决策，而是一系列决策的叠加，每一层都有其独特的失效模式，而某些失效模式的后果，远比客服聊天机器人幻觉严重得多。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
