异步 AI 任务有一个传统后台 Worker 没有的问题：它们会静默而自信地失败。一个文档处理 Agent 返回 HTTP 200，输出格式规整的结果，然后继续执行——而实际输出却悄悄出错了：可能不完整，可能建立在三步前幻觉出的事实上。你的仪表盘依然绿色，值班工程师照常入睡，客户最终才发现异常。
这不是边缘情况，而是未经可观测性设计的异步 AI 系统的默认行为。让传统分布式系统中后台作业队列保持可靠的工具——死信队列、幂等键、Saga 日志——同样适用于 AI Agent。但失败模式足够不同，需要做一些"翻译"。
你的团队花了三天时间迭代系统提示词。评估分数从 82% 提升到了 85%。你上线了。三周后，生产指标毫无变化。发生了什么？
简短的答案是：你的评估欺骗了你。不是恶意为之，而是样本量不足加上忽视了方差。在 100 个样本的测试集上提升 3 个百分点，完全在大多数 LLM 系统的噪声底线以内。在这个规模下，你无法区分信号与随机性——但几乎没有人会在采取行动之前做这个数学验证。
这就是 LLM 评估中的统计功效问题，它正在悄无声息地腐蚀大多数 AI 产品团队的迭代循环。
最有望从 AI 中获益的团队，往往是最晚部署 AI 的。一家能够利用 AI 实时发现用药错误的医疗机构，其 AI 采纳率仅为 39%；而一家运行 AI 代码审查的软件公司，采纳率高达 92%。两者的 ROI 差距悬殊——然而采纳率却完全颠倒。这就是 AI 采纳悖论，而且它绝非偶然。
人们的本能是将这种差距解释为规避风险、监管恐惧或官僚惰性。这些因素确实存在。但更深层的原因是结构性的：在高风险领域释放价值所需的准确率阈值，从根本上高于自主部署所能证明合理的水平，而大多数团队尚未构建出弥合这一差距的架构。
每一项微调工作最终都会达成同样的直觉：更好的数据意味着更好的模型，而更好的数据意味着更高质量的样本。因此，团队会构建复杂的标注流水线，以过滤掉平庸的输出，只保留金标准回复，并基于让他们引以为傲的数据集进行训练。然而，由此产生的模型在那些最初推动项目启动的具体用例中表现不佳。这种失败如此普遍，以至于值得拥有一个专属名称：课程陷阱（curriculum trap）。
这个陷阱在于 —— 仅策划你最好、最自信、最权威的输出并不能教会模型变得更好。它教会模型的是无论是否合理都要表现出自信。你创造出的东西在演示中看起来令人印象深刻，但在生产环境中却漏洞百出，因为生产环境充满了你的策划过程系统性排除掉的混乱边缘情况。
大多数 AI 产品复盘都聚焦于同一个故事：模型错了，用户发现了，信任瓦解了。修复方法显而易见——提高准确率。但有一种更隐蔽的失败模式，复盘很少能捕捉到，因为标准的准确率指标无法反映它：模型是正确的，但原因却是错误的，而那些检查了推理逻辑的高级用户再也没有回来。
称之为“过度声明陷阱”（overclaiming trap）。在这种失败模式下，正确的最终答案是由捏造的、事后修补的或结构不合理的推理链支撑的。它比普通的错误更危险，因为它看起来像是成功，直到你最专业的用户开始悄悄离开。
一个团队上线了一条 JSON 提取流水线。在开发环境中运行完美：98% 的准确率、干净的结构化输出、可预测的 token 数量。他们推送到生产环境后，模型开始产生多余的空白字符，JSON 解析器开始报错，API 账单是原型阶段估算的 2.3 倍。模型没变。提示词没变。
是 tokenizer 变了——更准确地说，他们对它的假设从一开始就是错的。
分词（Tokenization）是你的输入经历的第一次转换，却是工程师在调试时最后才想到要检查的地方。大多数团队把它当作已解决的问题：文本进去，token 出来，模型完成其工作。但字节对编码（BPE，Byte Pair Encoding）——大多数生产级 LLM 背后的分词算法——在结构化输出生成、前缀缓存、成本估算和多语言部署中做出的决策，会产生连锁影响。一旦你知道该往哪里看，这些影响完全是可以预测的。
你上线了一个 AI 功能。模型表现良好——你量化过它。精确率达 91%，召回率扎实，P99 延迟低于 400ms。三个月后，产品分析给出了一个令人沮丧的数字：高级用户已将其完全关闭，而另一批用户则不加修改地接受每一条建议，包括那些明显错误的。
这就是信任校准差距。它不是模型问题，而是设计问题——而且比大多数 AI 产品团队愿意承认的更为普遍。
在你最优秀的提示词工程师转岗到新项目六个月后，一个面向客户的 AI 功能开始出现异常。响应质量下降了，输出格式偶尔损坏，还有一个说不清道不明但持续存在的语气问题。你打开提示词文件，里面是 800 字的自然语言。没有变更日志，没有注释，没有测试用例。写下它的人确切地知道每一段话存在的意义。但那份知识已经消失了。
这就是提示词考古问题，它已经让团队付出了真金白银的代价。一家全美抵押贷款机构最近发现，文档分类的准确率下降了 18%，原因可以追溯到三周前有人在所谓的“常规工作流优化”中向提示词添加的一句话。两周的调查，大约 340,000 美元的运营损失。而那次修改的作者早已离开了。
在大多数 RAG 架构中都存在这样一种信念：如果检索返回了正确的区块（chunks），LLM 就会生成正确的答案。团队在嵌入模型选择、混合检索策略和重排序流水线方面投入了巨资。然而，在部署到生产环境三个月后，回答质量悄然下降——这不是因为模型变了，也不是因为查询模式发生了剧变，而是因为底层的语料库腐烂了。
企业级 RAG 的实施失败率约为 40%，而从业者最容易低估的失败模式既不是幻觉，也不是检索召回率低，而是文档质量。一项分析发现，通过引入文档质量评分，一个实施方案在不改变嵌入模型或检索算法的情况下，将搜索准确率从 62% 提高到了 89%。语料库是唯一的变量。语料库一直都是变量。
生产环境中的 LLM 给出了一个错误的答案。一张支持工单到来。你翻查日志，只看到提示词、补全内容和延迟指标——却没有任何信息说明检索系统到底拉取了哪些文档、哪些块进入了上下文窗口，或者模型在综合答案时最依赖的是哪段内容。你只能像做考古一样：重新对一个已经更新过的语料库跑一次查询，祈祷结果还和之前一样，同时不知道问题究竟出在检索、分块、文档本身还是模型推理上。
这就是数据溯源的缺口，而大多数 AI 团队直到掉进去才意识到它的存在。
大多数运行 LLM 推理的 GPU 集群正在浪费 30% 到 50% 的可用算力。这并非因为工程师粗心，而是因为调度问题本身极为困难——而大多数团队首先想到的工具根本不是为此设计的。
标准做法是搭建 Kubernetes，为每个 Pod 申请完整的 GPU，然后让调度器自行处理。这对训练任务运行良好。但对于处理异构模型集合的推理场景，这种方式会悄悄摧毁利用率。一个运行三个不同 7B 模型且流量稀疏的集群，每个 GPU 的实际繁忙时间可能不足 15%，同时却处于完全"已分配"状态，拒绝调度任何新任务。
根本原因在于 Kubernetes 理解 GPU 的方式与 LLM 推理实际需求之间的错配。
在一个金融科技团队推出 AI 编程智能体来处理日常后端任务的三个月后，一位资深工程师离职去了另一家公司。当团队试图还原六周前做出某些身份验证决策的原因时，却发现没有人能做到。PR 描述写着“按讨论实现”，提交信息写着“根据需求”。AI 智能体做出了选择，代码正常运行，而背后的推理过程却消失得无影无踪。
这并非文档记录的失败。当原本用于传递理解的渠道——工程师之间的往复沟通、解释带来的摩擦、向他人证明决策合理性的压力——被一个优化输出而非优化理解的系统所取代时，必然会发生这种情况。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
