演示到生产的悬崖：为什么准确率 90% 的智能体发布率为 0%

有一种特定的会议，通常发生在令人印象深刻的智能体（Agent）演示大约六周后。原型演示了订机票、重构模块、核对发票——现场演示，一次成功，就在利益相关者面前。大家都认为它可以上线了。接着有人调取了生产数据，发现那个“好用”的智能体每完成 40 个任务就会产生一张工单，每几百次就会产生一笔退款，还留下了一堆没人能解释的半成品状态。项目没被砍掉，但它卡住了。而且到现在还卡在那儿。

这就是从演示到生产的悬崖，也是智能体项目失败最常见的方式。悬崖并非由糟糕的模型或懈怠的团队造成的。它源于一个度量错误：将 90% 的成功率视为完成了 90% 的上线工作。事实并非如此。一个 90% 准确率的智能体是一场成功的演示，但对于大多数真实工作流来说，它是一个无法上线的产品。2025 年登上头条的 MIT NANDA 报告指出，95% 的企业生成式 AI 试点项目没有产生可衡量的损益（P&L）影响——这就是在大规模范围内统计出的悬崖现状。

这种差距之所以感觉如此巨大，是因为缺失的 10% 并非你想象的那样。直觉上，“90% 成功率”听起来像是“运行良好，只需小幅修饰”。但缺失的那部分并不是均匀分布的小麻烦。它是一个长尾——一系列自信的错误动作、无声的局部完成和无法恢复的状态。长尾里的每一个条目都不是粗糙的边缘，而是一张工单、一笔退款、一个合规警告，或者一个流失的用户。你并没有发布一个 90% 的时间都能正常运行的产品。你发布的是一个在 10% 的时间里会造成昂贵失败的产品，而演示恰恰从未触及那个长尾。

演示前没人算的数学题

从算术开始，因为这是最容易被忽略的部分。智能体不会只执行一个动作。它们执行的是一系列链式动作：读取上下文、调用工具、解释结果、做出决策、调用另一个工具。链条的可靠性是乘法叠加的。如果每一步独立成功的概率是 90%，那么一个包含五个步骤的任务成功率就是 0.9⁵——约 59%。一个十步任务的成功率约为 0.9¹⁰——大约 35%。

即使把每一步的成功率提高到演示级别的 95%，情况依然严峻：十步工作流的成功率接近 60%，而二十步工作流的成功率仅为 36% 左右。超过一半的操作在完成前就会失败。这就是为什么人们将智能体的可靠性描述为“复利式”的：你不是在增加错误，而是在乘以生存概率。乘以小于 1 的数字，会让乘积降至零的速度远超任何人的直觉预期。

演示之所以能掩盖这一点，是有结构性原因的。演示是单一的轨迹。它是理想路径（Happy path），通常经过排练，且几乎总是很短。生产环境则是轨迹的全分布——长的、怪异的、第三步返回空列表而智能体从未见过空列表的。演示采样的是分布的中心。而悬崖存在于长尾中。你无法通过从中间抽取一个样本来观察长尾。

因此，第一条准则要诚实：在批准任何项目之前，写下实际工作负载中真实的步骤数，并将每步的成功率提高到相应的幂次。如果答案没有远高于你对失败的容忍度，那么你面临的就不是修饰问题。你拥有的是一个尚不存在的产品，任何程度的提示词调优（Prompt tuning）都无法弥合这种本质上由链条长度导致的差距。

提高准确率是错误的目标

对 35% 的端到端成功率，本能的反应是“让模型变得更好”。这就是陷阱。面对乘法惩罚，每一步准确率的提升所带来的收益会迅速递减。将每步准确率从 90% 提高到 95%，确实能让十步任务的端到端成功率翻倍——但从 95% 提高到 99% 是一个极其困难的工程和成本问题，而且它仍然会让十步任务在大约十分之一的时间里失败。当指数很大时，你无法通过乘法算出一份可靠性。没有任何一种每步准确率能让足够长的链条变得安全。

真正能让产品上线的思维转变是：停止试图消除失败，开始让失败变得“廉价”。当失败是不可察觉、不可逆、爆炸半径不受限且无法转交给人类处理时，它是昂贵的。当系统能立即察觉失败、所采取的动作可以撤销、造成的损失预先受限，并且由人来进行清晰的接手而非处理烂摊子时，失败就是廉价的。

注意这其中的变化。“提高准确率”是模型的属性。而“让失败变得廉价”是围绕模型的系统的属性——这是你的团队完全可以控制的。一个每步准确率 90% 但失败代价廉价的智能体是可以上线的。一个准确率 98% 但失败代价昂贵的智能体则不行。智能体的生产就绪性取决于失败处理机制，而非成功率。

四个杠杆可以让失败变得廉价，它们都是设计决策，而非模型训练：

• 可检测性（Detectability）。最糟糕的失败是无声的——智能体报告成功，但工作只做了一半。建立验证步骤来确认结果，而不只是确认没有异常。一个知道自己失败了的智能体是可以补救的。一个认为自己成功了的智能体则是一颗定时炸弹。
• 可逆性（Reversibility）。将智能体可以调用的每个工具分类为可逆或不可逆。读取了错误的记录是可以补救的。但删除记录、发送邮件、扣款、向外部发布——这些是不可逆的。将不可逆的动作通过暂存区、软删除、草稿状态或人工确认进行路由，这样一次错误的调用只是一个麻烦，而不是一起事故。
• 受限的爆炸半径（Bounded blast radius）。在最坏情况发生前对其进行限制。设置支出限额、速率限制、行数限制，以及仅触及任务所需内容的受限凭据。智能体应当在结构上无法引发灾难，而不仅仅是被指令要求避免灾难。
• 优雅接手（Graceful handoff）。当智能体不确定或卡住时，正确的做法是停止并向人类提供一幅清晰、完整的图像，说明它做了什么以及为什么要暂停——而不是去猜测，也不是丢出一堆晦涩的堆栈跟踪信息。一次干净的接手能将失败转化为常规的协助。而一次糟糕的接手则会将其变成一场调查。

评估尾部，而非均值

如果断崖式下跌隐藏在失败的尾部，你的评估就必须衡量尾部 —— 而大多数 Agent 评估衡量的却是均值。“85% 的任务成功率”是一个均值。它告诉你那 90% 的规模，却无法告诉你那 10% 的具体情况，而这 10% 才是决定你是否能发布产品的唯一部分。

两个 Agent 的评分可能都是 85%，但它们却是完全不同的产品。Agent A 的 15% 失败案例全是“询问澄清问题并停止运行”；而 Agent B 的 15% 则是“自信地采取了错误的不可逆行动”。同样的表面数据，一个今天就能发布，另一个则是潜在的法律诉讼。均值无法区分它们，你的评估必须做到这一点。

这意味着要对失败进行评分，而不仅仅是计数。对于每一个失败的轨迹，都要对其进行分类：Agent 是否知道自己失败了？该动作是否可逆？它是干净利落地停止还是在反复挣扎？爆炸半径（影响范围）是否受限？然后跟踪这些答案随时间的变化分布。预测你是否能发布的指标不是“成功率上升了”，而是“静默且不可逆的失败比例下降了”。

这也重新定义了什么是好的评估集。演示级别的评估集只是增加了行数的“顺境路径”（happy path）。而生产级别的评估集则是刻意对抗性的：空结果、格式错误的输入、模糊的指令、超时工具、以及长到足以暴露复合错误的复杂多步任务。你不是在试图让 Agent 看起来表现良好，你是在试图在测试环境中找到那个“断崖”，而不是等到它出现在故障频道里。

组织失败模式

“断崖”不仅是技术性的。它具有一种可预测的组织形态，而识别出这种形态就等于成功防守了一半。

情况通常是这样的：领导层看了演示。演示中隐含的成功率 —— 现场演示看起来完美无缺 —— 成了印在每个人脑海中的数字。GA（正式发布）日期根据这个数字设定。工程团队知道真实的分布要难得多，但缺乏一种清晰的表达方式，因为在看起来非常成功的演示面前，说“它还不够可靠”听起来像是在推诿。Agent 发布了，“断崖”准时降临在故障频道，而事后分析的结论是团队“本该进行更多测试”。

解决方法是改变演示的内容。停止演示顺境路径，演示失败处理。展示 Agent 在遇到模糊指令时停下来询问；展示它尝试执行不可逆操作时被护栏拦截；展示 Agent 放弃任务时人类收到的接管界面。能够自信地演示其失败模式的团队才真正了解自己的系统。只能演示成功的团队还没有触碰到自己的“尾部”。

此外，将单一的成功率数字替换为两个：真实步骤下的端到端成功率，以及“代价低廉”的失败比例。第二个数字才是决定是否 GA 的关键。一个 Agent 并不是因为成功频率足够高而成为产品的，它是当其失败的代价不再高昂时，才真正成为了产品。

跨越断崖

2026 年能够将 Agent 投入生产环境的团队，不一定是拥有最佳模型的团队。大家能接触到的前沿模型都大同小异。真正的胜者是那些深刻理解演示衡量了错误指标，并围绕“失败尾部”而非“成功均值”重塑工作的团队。

具体而言，这意味着：在承诺日期之前先算清复合错误。将“提高准确率”视为次要杠杆，将“降低失败代价”视为首要杠杆。在发布前按可逆性对每个工具进行分类，并限制每个环节的爆炸半径。构建一个专门搜寻尾部问题的评估集。演示你的失败处理逻辑，而不是顺境路径，这样领导层脑海中的数字才是真实可靠的。

从演示到生产的“断崖”并非意味着 Agent 无效，而是一个信号，表明我们曾用“均值”来衡量“有效性”，而本该用“尾部”来衡量。一个成功率为 90% 的 Agent 并不等同于完成了 90% 的产品。但是，如果一个 90% 成功率的 Agent，其剩余 10% 的失败是可探测、可逆、受限且能干净利落地移交给人机协作的 —— 那么这就是一个你今天就可以发布的产品。