Benchmark 幻觉:榜单高分的 AI Agent,到你的真实业务里为何只剩 3–4 成成功率
公开榜单上,顶级 AI Agent 的分数一个比一个亮眼;可一旦接入你自己的私有系统,成功率往往骤降到三四成。本文用三组本周一手基准数据——真实私有企业代码库的 38.8% pass@1、77.4% 到 53.0% 的一致性缺口、长任务 73.4% 的失败率——拆解"演示很惊艳、上线就翻车"的三层差距,并说明为什么补上私有语境(而非追逐更高榜单分)才是企业落地的真正杠杆。
TL;DR: 最强的前沿 AI Agent,在真实私有企业代码库上的单次通过率(pass@1)也只有约 38.8%——换句话说,同一个在公开榜单上名列前茅的 Agent,一旦接入你自己的系统、数据与业务规则,十件事里往往做砸六件。差距主要来自三层:缺私有语境(它不懂你的内部系统与业务约定)、一致性不足(同一任务重复跑不一定次次成功)、以及长任务失控(步骤一多、链条一长就崩)。公开榜单分数衡量的是通用能力,不等于你的业务分数;真正决定落地效果的,是有没有把私有语境补进去。本文用三组本周一手基准数据把这三层差距量化,并给出企业该怎么补的答案。
这是《为什么企业 AI Agent 会在生产环境翻车》的数据版姊妹篇:那篇讲"为什么会翻车",本文用基准数字回答"翻车到什么程度、差距具体在哪、怎么补"。
一、公开榜单分数,能代表你的业务成功率吗?
不能——而且差距比多数人想象的大。
问题的关键在于基准题目取自哪里。多数广为人知的高分,来自公开的开源仓库任务;而 Real-SWE Benchmark(Specific Labs) 换了个更接近现实的口径:题目全部来自向真实公司授权的私有生产代码库,涉及计费、报税、客户迁移这类"改错一步就有业务后果"的改动。在这个更真实的口径下,榜首的 Claude Code 也只拿到 38.8% 的 pass@1(每个任务独立跑 8 次取平均),其后依次是 GPT-6 Astra 33.8%、Gemini CLI 31.2%、GLM 5.3 + Claude Code 28.8%、Kimi K3 18.8%。
也就是说,即便是当下最强的前沿 Agent,面对真实私有企业代码,也只能解决不到四成的任务。榜单叙事里的"接近可用"和你实际部署后看到的成功率,根本不是同一个数字。
| 维度 | 公开榜单给你的印象 | 你的真实私有企业场景 |
|---|---|---|
| 任务来源 | 公开开源 issue(语境自洽、边界清晰) | 授权私有生产代码库(计费/报税/客户迁移,有业务后果) |
| 最强 Agent 成功率 | "已接近可用"的高分叙事 | pass@1 约 38.8%(Real-SWE 榜首) |
| 失败集中区 | 短平快的 demo 型任务 | 长任务(跨系统、多步、长链条) |
| 评估口径 | 单次 / 首过即算成功 | 每任务 8 次取平均,还要看一致性 |
这张表是本文的主线:接下来三个问题,分别对应表里"评估口径"和"失败集中区"两栏背后的真实机制。
二、为什么演示时很惊艳,真跑起来只有一半靠谱?
因为"能做成一次"和"每次都能做成"是两回事——中间隔着一道一致性缺口。
IBM Research 在 Hugging Face 上的一篇文章 《Your Agent Aced the Task. Will It Do It Again?》 把这个问题量化得很清楚:一个基于 GPT-4.1 的 ReAct agent 在 AppWorld 基准上平均成功率 77.4%,听起来相当能打;但如果要求"同一任务连续跑 5 次全部成功",达标率骤降到 53.0%——两者之间是 24.4 个百分点的一致性缺口(consistency gap),在难任务上这道缺口甚至扩大到 30 个百分点。而"多数基准只报第一个数字",于是演示时你看到的是 77.4% 的那一面,上线后遇到的是 53.0% 的那一面。
这解释了"演示惊艳、真用就不行"的体感:演示是精心挑过的一次成功,生产是同一动作反复执行。IBM 的文章直言不讳——"对一笔金融交易做对账、或检查一份合同里的义务条款……(偶尔错一次)就可能是压垮生产的那根稻草。"在有业务后果的场景里,五次里错一次,就是一次真实的生产事故。
三、长任务是主要失败区吗?
是。任务越长,Agent 越容易在中途失控。
同一份 Real-SWE 数据从时长维度给出了很直接的信号:10 分钟以内就能完成的短 rollout,失败率明显偏低;而更长的 rollout,失败率高达 73.4%。长任务,是失败最集中的区域。
这一点对企业尤其关键,因为真实业务里"有价值的活"几乎都是长任务:一次客户数据迁移、一条跨多个内部系统的对账链路、一个牵涉若干审批环节的合规改动——都是多步、跨系统、长链条。演示里那种"一句话、一步到位"的任务,恰恰是 Agent 表现最好、也最不像真实工作的那一类。你越是把它放到真实业务的长链条上,它离榜单分数就越远。
四、上线之后,怎么不烧钱地持续确认 Agent 没退化?
不必每次改版都重跑全量测试——用自适应的抽样评估,能以极小成本守住效果。
Agent 上线不是终点:模型在换、提示词在改、依赖在升级,每一次变动都可能让效果悄悄退化。但"每次都重跑全量基准"成本高到没人愿意做。arXiv 上的一项研究 《Efficient Benchmarking in Production: A Study of an Evolving LLM Agent》(2609.21267) 给出了更省的做法:研究对象是一个月活数万的生产级分析型 agent,用它 574 次历史运行按时间切分来做实验。结论是,采用多维 2PL 自适应测试(IRT,一种按题目难度动态选题的评估方法)保真度最好——只跑 200 道题(全量的 38.5%),就能把评估误差控制在 1.03 个百分点(MAE)。实际部署时他们进一步选了工程更简单的"难度分层固定子集",不仅能零重标定迁移到另外 5 个 agent 家族,连校准窗口短到 1 天都依然稳定。
评估之外,如何定位问题也有更省的路径。前面提到的 IBM Research 那套方法配了一个 Consistency Analyzer:只需一条已记录的运行轨迹(trace)、无需人工标注答案,就能找出"离另一种行为只差一次采样"的易翻车决策点,据此生成改进指引,把一致性缺口从 24.4pp 砍到 12.0pp(同任务 Pass⁵ 提升 16.0pp),而且平均准确率不下降。
把这两件事合起来看:**持续复评不必昂贵,但必须持续。**低成本的抽样评估负责"守住不退化",轨迹分析负责"定位在哪退化"——这套闭环,才是让 Agent 在生产里长期可信的基础设施。
五、那企业到底该怎么补上这 60% 的差距?
答案不在"换一个榜单分更高的模型",而在"把它缺的私有语境补进去"。
回看前面三组数据:Real-SWE 之所以把成功率打到 38.8%,是因为题目来自 Agent 从未见过的私有生产代码库;IBM 之所以强调金融对账、合同审查错一次即事故,是因为这些场景高度依赖你独有的业务规则。这两点指向同一个结论——榜单分数衡量的是通用能力,业务分数取决于私有语境:你的内部系统怎么调、数据契约长什么样、业务规则的边界在哪、哪些是不能碰的边界案例。这些,恰恰是任何公开基准都不包含、也无法替你补上的东西。
而补上私有语境,正是 Forward Deployed Engineer(FDE,前置部署工程师) 的核心价值。FDE 不是把一个通用 Agent 交付给你就结束,而是驻进你的真实场景,把私有语境一层层注入模型能力:
- 需求语境化——把模糊的业务目标翻译成 Agent 能执行的、带边界条件的任务;
- 建私有 eval 集——用你自己的真实任务(而非公开题目)建立评估基线,让"业务分数"可被度量;
- 持续复评闭环——用上一节那套低成本抽样评估 + 轨迹分析,守住效果不随迭代退化。
这也是为什么在 6AM TECH,我们把"落地效果"而不是"榜单排名"当作交付标准:公开分数是起点,私有语境才是护城河。如果你想知道自己的场景离"可用"还差多少,可以先做一次免费的 AI 落地诊断,我们会帮你评估现有差距在私有语境、一致性还是长任务上。想更系统地理解 Agent 为何在生产翻车,也可以读姊妹篇《为什么企业 AI Agent 会在生产环境翻车》。
数据来源:Real-SWE Benchmark / Specific Labs、IBM Research @ Hugging Face、arXiv 2609.21267。
