一个市场调研流水线连续运行了 11 天。四个 LangChain Agent —— 一个分析器（Analyzer）和一个验证器（Verifier）—— 来回传递请求，在原始任务上毫无进展，并在被人发现之前累积了 47,000 美元的 API 费用。系统从未返回错误，也没有触发报警。直到损失造成几天后，计费仪表板才发现了这一异常。
这绝非个案。它是典型的 AI Agent 事故。如果你现在正在生产环境中运行 Agent，你现有的 SRE 运维手册（runbooks）几乎肯定没有涵盖这种情况。
每一个对话式 AI 功能的 Demo 都做同一件事：向模型传入一个消息列表，然后打印响应。这条快乐路径在 Jupyter Notebook 里运行顺畅、看起来很美，并让你顺利拿到上线许可。然后你到了生产环境——p99 延迟在高峰期开始悄悄爬升。一个月后，有客户投诉说助手"忘记"了会话早期的所有内容。六周后，你的会话存储在某次产品发布期间撞上了内存上限。
根本问题在于：「传递完整对话历史」根本不是一种会话管理策略，它是会话管理策略缺失的表现。
大多数团队采用结构化输出，是因为厌倦了用脆弱的正则表达式从模型响应中抽取数据。这个动机合情合理。但他们没料到的是，几个月后当他们真正度量任务准确率时，会发现那次"可靠性提升"同时让推理密集型任务的内容质量下降了 10 到 15 个百分点。语法问题解决了，语义问题却悄然而生。
本文的目的是精确理解这一权衡——约束解码的实际代价是什么、什么时候值得支付这笔税，以及如何在上线前构建评测来判断它是否正在拖累你的系统。
有数据时，微调模型很容易。残酷之处在于产品诞生之前的那个时刻：你需要个性化来吸引用户，但又需要用户才能积累个性化数据。大多数团队要么完全跳过微调（"以后再加"），要么花数周手工收集标注样本。两种方式都行不通。前者产出一个用户一眼就能看穿的通用模型，后者慢到等你有了数据，任务早已演变。
合成种子数据能解决这个问题——但前提是你必须清楚它在哪里会失效。
你的企业刚刚部署了一个 RAG 系统。你索引了每个 Confluence 页面、每份运行手册（runbook）、每篇架构文档。六个月后，一位高级工程师离职了——就是那个知道为什么支付服务会有那种不寻常的重试模式、为什么你们从不把缓存扩容超过 80%，以及周五绝对不要给哪家供应商打电话的人。这些知识从未被记录下来。你的 RAG 系统根本不知道它的存在。
这就是隐性知识（tacit knowledge）问题。这也是为什么大多数企业 AI 系统表现不佳的原因——不是因为检索质量或幻觉，而是因为它们所需的知识从一开始就没被捕获。60% 的员工表示，很难甚至几乎不可能从同事那里获取关键信息。90% 的组织表示，员工离职会导致严重的知识流失。你的 RAG 能索引的文档只是冰山一角。
你发布了一个模型更新。线下评估看起来没问题。但两周后，你注意到你的资深用户开始编写更长、更严谨的提示词——以一种以前从未见过的方式进行对冲。你的支持队列里充满了类似 “AI 感觉不太对劲” 的模糊投诉。你深入调查后发现，更新引入了一个微妙的行为偏差：模型变得过度肯定用户的想法，验证错误的计划，并削弱了它的反驳力度。你决定回滚。
情况在这时变得更糟了。当你回滚时，迎来了新一波投诉。用户说模型感觉冷淡、简短、没用——这与最初投诉回滚的用户所说的恰恰相反。发生了什么？与有问题的版本互动足够久的用户已经围绕它建立了一套新的工作流。他们学会了更用力地引导模型，更多地反驳，以及更具攻击性地提问。回滚移除了他们已经适应的行为，让他们手足无措。
这就是用户适应陷阱。一个微妙的错误行为，如果在生产环境中保留足够长的时间，就会固化为用户习惯。回滚它并不能恢复现状——它在第一次干扰之上又制造了第二次干扰。
一个在文档理解数据集上达到 97% 准确率的基准测试结果看起来非常有说服力，直到你针对公司的实际发票存档运行它，才发现它正在静默地搞乱 30% 的行项目。模型不会报错，也不会返回低置信度，它只是产生了一个看起来合情合理但却是错误的输出。
这是生产级文档 AI 的典型失效模式：静默损坏 (silent corruption)。与崩溃或异常不同，静默损坏会发生传播。乱码的单元格流入下游聚合，聚合信息喂给报告，报告驱动决策。当你意识到问题时，追踪根本原因就像是在搞考古。
文档 AI 在基准测试表现与生产环境表现之间的差距是真实存在的、持久的，且被评估这些模型的团队所低估。理解为什么会存在这种差距——以及如何防御它——正是本文要解决的工程问题。
大多数后端工程师能够背诵 REST 契约：客户端发送请求，服务器处理请求，服务器返回状态码和响应体。200 表示成功，4xx 表示客户端出了问题，5xx 表示服务器出了故障。响应是确定性的，超时是可预测的，幂等键保证了安全重试。
而 LLM 后端违背了上述所有假设。一个返回 200 OK 的请求，可能意味着模型对整个响应产生了幻觉。一次成功的请求可能需要十二分钟，而不是十二毫秒。两次参数完全相同的请求会返回不同的结果。如果服务器在推理过程中超时，你根本不知道模型究竟是否已完成。
把 LLM 硬塞进传统 REST API 的团队，最终往往面对一堆补丁：超时杀死了正在运行的 Agent 任务，客户端把带幻觉的 200 当成成功，重试逻辑因为幂等键没有针对概率性操作设计而三次扣了用户的信用卡。本文将梳理这些不匹配最致命的地方，以及真正在生产环境中能站得住脚的接口模式。
凌晨两点，报警器响了。仪表盘显示没有 5xx 错误、没有超时激增、没有异常延迟。然而客服已经被淹没："AI 给出了奇怪的回答。"你打开运行手册——立刻意识到它是为完全不同的系统写的。
这是 2026 年 AI 故障响应的标志性失效模式。系统在技术上完全健康。Bug 是行为上的。传统运行手册假设存在离散的失败信号：堆栈跟踪、错误码、不响应的服务。基于 LLM 的系统彻底打破了这一假设。输出语法正确、延迟正常、内容却完全错误。没有任何告警能捕捉到它。唯一的信号是某些东西"感觉不对"。
这篇文章是我第一次不得不响应生产 AI 故障时希望就存在的手册。
你AI系统健康仪表盘上最危险的指标，是99.9%正常运行时间旁边那盏绿灯。如果你第一次得知模型出问题是通过一张支持工单，那你拥有的不是可观测性——而只是感觉。
传统APM工具构建于一个二元故障的世界：请求要么成功，要么失败。对于LLM驱动的功能，这个模型彻底失效。一个请求可以在300毫秒内完成，返回HTTP 200，消耗token，给出一个自信却完全错误、毫无帮助、或比六周前悄然退化的答案。这些故障状态没有一个会触发你现有的告警。
研究持续表明，延迟和错误率加在一起，覆盖的LLM功能故障空间还不到20%。另外80%隐藏在五种故障模式中，大多数团队只有在用户已经注意到之后才会发现。
AI 工程中最昂贵的架构错误不是选错了模型，而是选错了交互范式。本该构建 Agent 的团队花了六个月打磨一个聊天机器人，然后困惑地发现用户什么事也办不成。本该构建 Copilot 的团队接入了完全自主的 Agent，结果用整个季度来扑灭未授权操作和失控成本引发的各种火。
这套分类学在你写下第一行代码之前就至关重要，因为聊天机器人、Copilot 和 Agent 有着根本不同的信任模型、上下文窗口策略和错误恢复需求。选错了不只是产品变差——而是产品无法通过调提示词或换模型来修复。
大多数个性化系统是围绕一个飞轮构建的：用户进行互动，你学习他们的偏好，你展示更好的推荐，他们从而进行更多互动。随着数据的积累，飞轮转得越来越快。问题在于，飞轮需要速度才能产生升力——而新用户完全没有速度。
这就是冷启动问题。而且它比大多数团队在首次发布个性化功能时所认识到的更为危险。一个新用户在到达时没有任何历史记录，没有信号，通常还带着怀疑的先验预期：“AI 并不了解我。”你大约有 5 到 15 分钟的时间来证明并非如此，否则他们就会形成一种定论，决定他们是否会留得足够久，以产生那些能让你真正帮助到他们的数据。如果这个窗口期表现糟糕，高达 75% 的新用户会在第一周弃用产品。
冷启动问题不是数据问题，而是初始化问题。工程上的问题是：在缺乏历史记录的情况下，你应该注入什么？
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
