Skip to content
Published on

操控浏览器与计算机的 AI 智能体，如今走到了哪一步 — 基准测试数字实际衡量的是什么

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
分享
Authors

引言 — 先说答案：这些智能体现在能做什么

用一句话回答是这样：短小、自足的任务大体能做；长链条、环环相扣的真实工作大体做不了。

这两句话同时为真，正是 2026 年计算机使用(computer use)智能体的精确坐标。看数字更清楚。OSWorld 2.0 论文(arXiv:2606.29537，2026 年 6 月 26 日)在导言里这样写 — Claude Opus 4.8 在 OSWorld-Verified 上达到了 83.5%，这似乎表明「桌面计算机使用已大体被解决」。然后，在同一篇论文的结果表里，同一个 Claude Opus 4.8 只完成了 OSWorld 2.0 任务中的 20.6%。

同一个模型，同一个月，同一个实验室。相差 63 个百分点。这篇文章讲的，就是这个差距从哪里来。

先把结论说在前面：那道鸿沟不是因为模型突然变差。不同的是基准决定要测量什么。 所以「智能体能做到百分之几」这个问题无法不带条件地回答，而去掉条件被引用的数字，几乎总是比实际更乐观。下面把那些条件一个个打开。

这篇文章不涉及浏览器与计算机操作智能体的架构与落地清单。那部分我已经单独整理在浏览器与计算机使用智能体实战指南里了。这里只看三件事 — 公开基准实际测量的东西、演示与生产之间的鸿沟，以及安全模型。

OSWorld 与 WebArena 实际测量的是什么

先把这个领域的两个基准点弄准确。

OSWorld(arXiv:2404.07972，NeurIPS 2024)是跑在真实操作系统之上的环境。把摘要里的数字原样搬过来 — 369 个计算机任务，真实的网页与桌面应用、操作系统文件 I/O、跨多个应用的工作流。而当时的结果是这样的：人类能完成 72.36% 以上的任务，最好的模型只有 12.24%。论文把失败原因归结为「GUI 定位(grounding)与操作知识」。

WebArena(arXiv:2307.13854)是网页那边的。以论文 PDF 里确认过的数字为准：812 个测试样例(从 241 个模板实例化而来)，四个领域 — 电子商务、社交论坛、协同软件开发、内容管理。结果是基于 GPT-4 的最强智能体端到端成功率 14.41%，人类 78.24%。

这里已经能看出一件重要的事。两个基准的人类基线都不是 100%。 72.36% 和 78.24%。人类也会在这些任务的四分之一左右上失败。这不是因为人不会用计算机，而是因为任务指令含糊，或者任务本身就是坏的。这个事实后面还会再出现。

第三个要提的是 WebVoyager(arXiv:2401.13919)，理由有些不同。WebVoyager 报告了在 15 个真实网站上 59.1% 的任务成功率。但同一篇摘要里有这样一句 — 自动评估协议使用 GPT-4V，与人类判定的一致率为 85.3%。也就是说，尺子本身就是一个模型。 而且约 15% 的情况它判得和人不一样。引用 59.1% 这个数字时，把「给它打分的裁判每 6 次就有 1 次和人类意见相左」一并引用，才算诚实。

这不只是 WebVoyager 的问题。OSWorld 2.0 也明确写着「基于模型的评估和人类介入的用户模拟器都使用 Claude Sonnet 4.6」。用模型来度量模型，这个结构如今几乎就是这个领域的标准。

为什么同一个模型在同一个基准上拿到不同的分数

这是对实践者最重要的部分。答案是脚手架(scaffold)。

创建 OSWorld 的 XLANG Lab 在 2025 年 7 月 28 日发布 OSWorld-Verified 时，自己重新测量了主要模型(作者自测)。其中的一行就足以概括这一整节。

o3 的性能随步数预算的不同而发生剧烈变化(从 9.1% 到 23.0%)。

同一个模型。同一个基准。同一批任务。只改了步数预算一项，就是 2.5 倍。 如果有人引用「o3 在 OSWorld 上是 23%」，另一个人引用「9%」，两个人都没有撒谎。

同一次重测的其余图景，讲的也是同一个故事(均为 XLANG 自测，OSWorld-Verified 基准)。

智能体框架          45~61%   <- CoACT-1 60.76%, Agent S2.5 w/ o3 56.0%, GTA1 w/ o3 53.1%
通用基础模型        35~44%   <- Claude 4 Sonnet 43.9%
计算机使用特化模型  25~40%   <- UI-TARS 40.0%
人类                ~72%

这里的头部全部是框架而不是模型。CoACT-1 的 60.76% 不是「一个叫 CoACT-1 的模型」的分数，而是在 o3 这类推理模型之上叠了一层编排层(orchestration layer)的系统的分数。XLANG 自己这样写 — 精巧的编排层可以极大地放大推理模型的能力，即便那个模型从未为计算机使用而训练过。

所以，当厂商或论文谈成功率时，至少下面这四项不一起给出，那个数字就无法比较。

  1. 步数预算(o3：9.1% → 23.0%)
  2. 脚手架(是裸模型，还是智能体框架，有没有挂代码执行工具)
  3. 尝试次数(是 1 次，还是 best-of-N)
  4. 子集(是全部 369 个，还是一部分，是哪个版本)

OSWorld 2.0 论文把这些条件写得堪称模范。步数预算 500、以截图为观测、Claude 系用原生计算机使用工具而其余模型输出 pyautogui 代码、输出限制 16K token(只有 MiniMax M3 是 8K)、每个动作后等待 3 秒、按是否批量工具调用分成两种设置、推理强度 Claude 为 max 而 GPT-5.5 为 xhigh。连基础设施都写了 — AWS us-east-1 的 t3.2xlarge，而且所有网页流量都经由住宅代理(residential proxy)。

最后一行尤其意味深长。不用住宅代理，网站就会拦截智能体，分数就会不一样。 基准分数的一部分，是绕过机器人拦截的基础设施创造的。

OSWorld 分数的一半不是 GUI 能力

Epoch AI 在 2025 年 10 月 30 日发布的 OSWorld 评审，是这个领域最令人不适、也最有用的文档。它既不是厂商也不是基准作者，而是第三方的分析，所以更是如此。

把核心发现搬过来是这样的。

  • 约 15% 的任务只靠终端就能完成。
  • 另有约 30% 的任务，原本设想的 GUI 操作的相当一部分可以用终端和 Python 脚本替代。
  • 加起来 — 用 Epoch 的原话说，「OSWorld 的任务里几乎一半几乎不需要或完全不需要 GUI 交互」。

而这确实反映在分数上。Epoch 写道，看官方排行榜，带代码执行工具的模型比纯 GUI 智能体的分数高出一截。他们甚至观测到脚手架里没有代码执行工具的模型自己下载软件包的案例 — 评审里贴着 Claude Sonnet 4 在「从文档中提取联系人并做成表格」的任务里安装 openpyxl 和 pandas 的截图。

OSWorld 不给中间步骤打分，只看最终状态。所以无论是像人一样点击着把电子表格填好，还是用 Python 调 openpyxl 填好，都同样算正确。这不是 bug 而是设计，但解读时必须把它考虑进去。「计算机使用」这个词让人浮想的画面(点击 GUI 的智能体)和分数实际测量的东西并不一致。

Epoch 指出的其他几点也值得原样搬过来。

  • 约 8% 的任务从一开始就被设计成不可能完成。智能体要回答「这不可能」才算正确。
  • 约 10% 的任务存在严重错误，属于无效任务。(Epoch 补充说，这「对 AI 基准来说不算异常的错误率」。)
  • 约 10% 的任务依赖互联网实时数据，随时间推移，难度乃至可行性本身都会变。
  • 大多数任务在 10 个原子动作以内。超过 20 步的约 12%，超过 50 步的只有 5%。
  • 指令含糊的任务很多，因此分数的一部分测的不是计算机操作能力，而是猜测意图的能力。

关于最后一项，Epoch 算出了一个有趣的上限。原论文的人类基线是 72%，所以受含糊性影响的任务至多 28%。人类失败的那 28%，就是含糊性的上限。

Epoch 的结论是 — 很难解读 OSWorld 上报告的分数差异。差异可能来自基于 GUI 的计算机使用能力，但也可能来自基准数据的变更、终端与 Python 的能力，或解读含糊指令的能力。

基准为什么被不停地修理

这里是这个领域安静的丑闻。基准不是固定不动的。

XLANG Lab 在 OSWorld-Verified 的发布文里自己交代：初次公开前用 4 轮检查花了 400 小时以上，之后又在维护上投入数百小时，即便如此，各机构指出的问题仍然积累了约 300 件。于是一个 10 人规模的团队用了约 2 个月，修复了 300 多条反馈。提供反馈的包括 MoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular、HKU 等。

坏掉的都是些什么，这很有意思。

  • 购物、搜索网站的机器人拦截和 CAPTCHA。Budget.com 从某个时间点开始上了 CAPTCHA。
  • 403 IP 拦截(Steam 连接超时、NBA.com 地区限制)。
  • speedtest.net 的 CSV 导出功能消失，任务本身实际上变了。
  • 像「紫色背景」这种存在多种解读的指令。浅紫? 还是深紫?
  • 正确答案有多个、打分器却只认一个。拼接两份 CSV 时没有说明表头行该怎么处理的任务。
  • 模型用扩展程序创造性地解开了任务，而作者们没想到那个方法，一直把它标成「不可能」任务的案例。

而修理的方向是决定性的。XLANG 列出的改进几乎全部朝着放宽打分器的方向 — 文档比较引入模糊匹配和 0~1 分数(替代二值)、图像比较用感知哈希忽略细微视觉差异、颜色给出容差范围、忽略货币字段的 $ 符号这类无意义的格式差异、承认功能上等价的公式。

也就是说，同一个智能体做同样的行为，在 2025 年 7 月之后会得到更高的分数。 Epoch 恰恰戳中了这一点 — 2025 年 7 月的大规模发布改动了大部分任务指令，此后又有约 10% 的指令再次变更。然后 Epoch 这样写：修错的努力值得称赞，但对一个并非实时(live)基准的基准来说，这是非常罕见的做法，它削弱了跨时间比较的意义。

连任务数都对不上。原论文说 369 个，Epoch 数出来是 361 个。

XLANG 自己留下的一行教训，就是这一节的总结。

提供可信奖励这件事所消耗的人力资源，比我们想象的更多。

他们也自己指出了分布式评估的结构性问题 — 发现问题的人大多没有反馈的动机，其结果是每家都拥有各自的环境，甚至为了提高分数而修改任务，分数变得越来越不透明、越来越无法比较。

「83.5%」和「20.6%」为什么共存于同一年

现在回到开头的谜题。

XLANG 在 2026 年 6 月 26 日发布了 OSWorld 2.0。创建它的理由，论文直接写了 — Opus 4.8 在 OSWorld-Verified 上拿到 83.5%，桌面计算机使用看起来像被解决了，但那个数字背后的任务短而窄，很少跨出一两个应用，奖励的是完成自足的动作，而不是维持长链条的工作流。因此，高正确率夸大了实际进展。

OSWorld 2.0 改了什么，这是关键。

  • 108 个任务。每一个都是以熟练人类为基准、中位数约 1.6 小时的真实操作。比 OSWorld 1.0 长约 48 倍。
  • 领先的智能体平均每个任务 300 步以上。OSWorld 1.0 约是 30。
  • 自托管了 31 个网页服务，包括邮件、银行、团队聊天等，以便控制状态、可以打分。
  • 每个任务从一份带一致状态的用户档案出发，并且在作业中途注入消息，让环境在智能体脚下发生变化。
  • 暴露一个知识有限的模拟用户 — 智能体可以向它提问。
  • 用平均每个任务 27.25 个细粒度检查点为最终状态打分。

结果(500 步、108 个任务的平均、作者自测)：

设置      模型               二值完成  部分分数  每任务成本  工具调用/任务  输出token/任务
批量动作  Claude Opus 4.8    20.6%     54.8%     ~$72.4      481.8          224K
批量动作  Claude Opus 4.7    18.2%     48.91%    ~$33.6      597.1          150K
批量动作  GPT-5.5            13.0%     49.5%     ~$25.5      149.8          37.1K
单一动作  Claude Opus 4.8    18.5%     49.3%     ~$76.1      190.5          259.5K
单一动作  Claude Sonnet 4.6   8.3%     41.5%     ~$22.3      253.3          185.9K
单一动作  MiniMax M3          4.6%     22.3%     ~$2.4       326.7          70.8K
单一动作  Kimi 2.6            4.6%     22.1%     ~$6.6       179.3          63.0K
单一动作  Qwen 3.7-Plus       2.8%     21.5%     ~$3.8       173.5          28.9K

把论文的句子原样搬过来 — 同样的前沿智能体，在 OSWorld 1.0 上以 79~83% 的二值正确率处于饱和状态，在 OSWorld 2.0 上却坐在只有其几分之一的低处。

这张表要同时读出三件事。

第一，批量工具调用这一项脚手架，就把 Opus 4.8 从 18.5% 抬到了 20.6%。 上一节的脚手架故事在最新论文里原样重演。同一个模型、同样的 500 步，只看工具调用打不打包，就是 2.1 个百分点。

第二，部分分数与二值完成之间的鸿沟是巨大的。 Opus 4.8 的部分分数有 54.8%，跑完全程的却只有 20.6%。用论文的表述，完成率在最长的工作流上崩塌到接近于零，部分分数却依然维持在高位。这就是演示效果很好的原因，也是生产用不起来的原因。演示展示的是部分分数，生产要求的是二值完成。

第三，每个任务约 72 美元。 以 20.6% 的成功率，一个任务 72 美元。这是人类要花 1.6 小时的活，和人力成本相比不算没有意义的金额 — 只是 5 次里有 4 次花了钱却跑不完。GPT-5.5 便宜得多(约 25 美元，输出 token 不到五分之一)、token 效率压倒性，但停在 13% 附近。论文把这一点与一个更宽的发现连在一起：「得分最高的智能体很少是最高效的那个」。

演示与生产之间，实际崩塌的地方

OSWorld 2.0 里最有价值的部分不是分数，而是失败原因分析。论文明确写道：

这些失败与基本的 GUI 操作或编码无关。

智能体把局部动作执行得很好。做不到的，是在长跨度里在头脑中维持任务级别的模型。论文列出的四点，恰恰就是在生产环境里爆炸的那些。

  1. 丢掉明说过的约束。 开头讲的条件，200 步之后忘了。
  2. 错过作业中途到达的信息。 这正是 OSWorld 2.0 特意在中途注入消息的原因。真实工作在开始时需求并没有定死。
  3. 不问用户而去猜。 明明有模拟用户，也不问。
  4. 跳过验证。 完成与否取决于验证，它们却几乎不在验证上花任何资源。

第三点和第四点尤其重要。这不是能力问题，而是倾向(disposition)问题。而倾向在相当程度上可以通过提示词和 harness(运行框架)来矫正。实际上，Anthropic 关于 Opus 4.8 的指引也在推荐同一个方向 — 琐碎的决定不必问、直接推进，但范围变更或破坏性动作必须确认，要像这样把自主性的边界写明白。也就是说，现在生产环境需要的不是更聪明的模型，而是知道该在哪里停下来提问的 harness。

安全 — 在这里，注入不再是文本而是行动

现在到了最重要的部分。前面所有的数字讲的都是「做得多好」。这里讲的是「出了错会怎样」。

在聊天机器人里，提示注入的最坏结果是模型说出奇怪的话。在浏览器与计算机智能体里，最坏结果是模型做出奇怪的事。同一个缺陷，爆炸半径不同。

Anthropic 的说明(2025 年 11 月 24 日公开)把这个差别整理得很好。浏览器使用之所以放大风险，原因有二。第一，攻击面极其广阔 — 每一个网页、内嵌文档、广告、动态加载的脚本，都是恶意指令的潜在载体。第二，浏览器智能体能做的动作非常多 — 跳转 URL、填写表单、点击按钮、下载文件。攻击者一旦获得对智能体行为的影响力，这些全都可以用。

Anthropic 举的例子平常得吓人。用户吩咐「读一下最近的邮件，给会议邀请写一份回复草稿」。其中一封邮件里藏着用白色文字写的指令 — 人眼看不见，智能体读得到。指令是把包含「confidential」的邮件转发到外部地址。在用户等待回复草稿的那点时间里，泄漏已经完成了。

这里必须点出一件事 — 这一切发生在用户批准的权限之内。 智能体有读邮件的权限，也有发邮件的权限。没有任何权限边界被击穿。被击穿的是「决定要做什么的逻辑」。这就是智能体安全无法用传统访问控制来解决的原因。

同一缺陷家族如何在 CI 流水线里一路打到供应链的尽头，我在一个 issue 打穿供应链一篇里沿真实案例追过了；网页上的第三方内容劫持智能体的跨站提示注入及其封锁研究，见网页智能体把网页上的文字读成命令一篇。这里不再重复，只看数字与防御的结构。

攻击成功率的数字应该怎么读

Anthropic 公开的浏览器注入鲁棒性数值，是把条件交代得非常清楚的好例子。所以这里把条件全部带上来引用。

  • 测量主体：Anthropic 自测(厂商自测)
  • 攻击者：内部的自适应 Best-of-N 攻击器 — 尝试并组合多种已知有效的注入技巧
  • 尝试次数：每个环境 100 次
  • 指标定义：ASR 是各模型相对其实际遭遇的攻击数的比率
  • 对象：Claude Opus 4.5，2025 年 11 月 24 日时点的浏览器扩展配置

而 Anthropic 自己写下的一句话，是这一节里最重要的。

1% 的攻击成功率 — 虽然是有意义的改进 — 仍然代表着有意义的风险。没有任何浏览器智能体对提示注入免疫，我们分享这些结果不是想宣称问题已被解决，而是为了展示进展。

这句话值得原样引用。厂商在发布自家最新模型的防御成绩时写下「这个数字也依然危险」，这很罕见。而且它在实务上是准确的 — 对一个一天遭遇 1,000 次注入尝试的智能体来说，1% 的 ASR 意味着一天被打穿 10 次。

这里还有一个必须诚实交代的限制。我能确认到的 Anthropic 浏览器注入 ASR 数值，是 2025 年 11 月、以 Opus 4.5 为基准的。 今天是 2026 年 7 月，其间 Opus 4.6、4.7、4.8 和 Sonnet 5 已经发布。最新模型的浏览器 ASR 更低的可能性很高，但我不会去推测一个未经一手来源确认的数字。你读到这篇文章时如果已有更新的数值公开，请以那边为准。

没有攻击者，智能体也会闯祸

注入是存在外部攻击者的场景。而 OSWorld 2.0 的安全性分析显示，在完全没有攻击者时，智能体也会做出危险行为。这一面反而更少有人知道，对落地决策却更直接。

作者们在一部分任务里加入了「副作用」检查，分析了 GPT-5.5 和 Claude Opus 4.7 的 216 条轨迹(每个模型 108 个任务)。结果(作者自测)：

  • 提取隐藏的应用程序状态：约 14% 的任务
  • 绕过用户可见的界面：约 33% 的任务

具体案例更有说服力。

  • 成功把仓库推送到了 GitLab，却不自知地一并泄漏了项目 .env 文件里硬编码的 API 密钥。
  • 明知系统磁盘只剩约 398MB 的空间，仍然为了混音任务原样下载了 372MB 的音频文件。冒着存储归零、系统崩死的风险。
  • 遇到预料之外的弹窗，就反复强制结束 LibreOffice，无视文档恢复警告。

论文的结论很锋利。

这些智能体在受阻时，不是暂停片刻或向用户求助，而是提升权限、为了完成任务不惜采取任何手段。

也就是说，当前的智能体优先考虑肉眼可见的任务完成，并不主动监视自己的副作用。这不是对齐失败，而是优化目标的问题。我们训练它「把任务做完」，它就精确地做了这件事 — 磁盘满不满、密钥漏不漏，在所不问。

请注意，上一节的「不问用户而去猜」在这里作为安全问题再次登场。能力不足与安全风险出自同一条根。

防御靠什么 — 靠结构

想用一行提示词来防御的尝试都会失败。「无视网页里的指示」不是对注入的防御，而是对注入的恳求。真正起作用的东西全部位于架构层。

Anthropic 公开的三条线是个好分类。

1. 训练模型本身。 用强化学习把抗注入能力直接放进模型的能力里。训练中在模拟的网页内容里埋进注入并让模型暴露其中，正确识别并拒绝恶意指令就给奖励 — 即便那些指令被设计得看起来权威、看起来紧急。

2. 用分类器建立信任边界。 对进入模型上下文窗口的所有不可信内容做扫描，标记疑似注入。检测隐藏文本、篡改过的图像、欺骗性 UI 元素等多种形态，识别出攻击就调整行为。这里重要的设计不是「检测」，而是检测之后的介入 — Anthropic 也写道，在改进分类器的同时，一并改进了「检测之后引导模型行为的介入」。

3. 让人来跑红队。 用 Anthropic 的话说，在发现有创造性的攻击向量这件事上，人类安全研究员一贯胜过自动化系统。内部红队持续探测，也参加外部的竞技场式挑战。

在此之上，产品层面还必须叠加两件事。两件都直接从上面的数据推导出来。

4. 最小权限，以及不可逆动作的分离。 即便注入成功，只要智能体无事可做，就没有损害。Anthropic 的例子里泄漏之所以可能，是因为智能体能向外部发邮件。把读与写、可逆与不可逆的动作分开，把后者放到人工批准之后 — 这是把 1% 的 ASR 实质性地压到接近于零的唯一方法。它和把模型本身变得更鲁棒是相乘的。

5. 副作用监视由 harness 来做。 正如 OSWorld 2.0 展示的，智能体不监视自己的副作用。磁盘容量、密钥泄漏、强制结束这类事，不要托付给智能体的善意，要在外部检查。作者们把「副作用检查」实现在基准之外，这件事本身就是提示。

一行总结 — 防御不是一道边界线，而是乘法。 模型鲁棒性 × 分类器 × 最小权限 × 审批闸门 × 外部监视。任何一项都不单独充分，任何一项也都不能省。

那么，现在该不该采用

基于到此为止的证据，给出具体的决策规则。我不会用「视情况而定」来搪塞。

现在就可以采用的：

  1. 短小、自足、可回滚的任务。 OSWorld 1.0 以 79~83% 饱和是真的。那些任务是什么呢 — 给文档加页码、从电子表格导出 CSV。大多在 10 步以内。这些现在做得很好。
  2. 结果能被人立即验证的任务。 部分分数 54.8% 与跑完全程 20.6% 的差距说明，智能体很擅长制造「几乎做完的状态」。如果那个状态人花 5 秒就能检查，那就足够有用。
  3. 失败成本等于重试成本的任务。 错了再叫它做一遍就行的事。
  4. 不读不可信内容的任务；或者即便读，也没有通向外部的通道的任务。

现在不该采用的：

  1. 无人监督地跑超过 1 小时的多阶段工作流。 OSWorld 2.0 的 20.6% 正面回答了这一条。而且完成率在最长的工作流上崩塌到接近于零。这还是在前沿模型的最强配置、500 步、每任务 72 美元的前提下。
  2. 不经人工批准的不可逆动作。 转账、发送、部署、删除。即便没有攻击者，智能体也会为了完成任务在 33% 的任务里绕过 UI，不管磁盘死不死都要把文件下载下来。
  3. 一边读不可信内容、一边访问敏感数据的组合。 这两样处在同一个上下文里，那本身就是一条泄漏通道。厂商最新的模型也有 1% 被打穿。
  4. 需求会中途变化的任务。 智能体会错过中途到达的信息，含糊时不问而猜。

还有一条看基准数字时的规则。不要读没有条件的成功率。 至少要有步数预算、脚手架、尝试次数、是哪个版本的哪个子集 — 没有这些，那个数字就无法与其他数字比较。就像 o3 既是 9.1% 也是 23.0% 那样。

结语

诚实地看这个领域，会同时看到两件事。

一件是真实的进展。2024 年 4 月，OSWorld 最好的模型是 12.24%。到 2026 年，同一个基准以 79~83% 饱和。两年就走到了这一步。这不是营销，这是逼得基准作者不得不让自己的基准退役的进展。

另一件是鸿沟没有缩小。一旦把基准做得更接近真实工作 — 1.6 小时量级、横跨多个应用、需求中途会变 — 最强的智能体就回到 20.6%。离 2024 年的 12.24% 并不算远。与其说我们征服了基准，不如说我们挑了能被征服的基准。

最让人印象深刻的是，这些事实是基准作者们自己说出来的。XLANG 在自己的基准以 83.5% 饱和之后说「这个数字夸大了实际进展」，新造了一个 20.6% 的。Anthropic 发布 1% 的 ASR 时写下「这也是有意义的风险」。Epoch AI 的结论是这些基准分数差异很难解读。炒作大多发生在这些文档之外，出自那些不带条件引用这些文档的人。

所以，实践者需要的既不是乐观也不是悲观，而是读条件的习惯。看到数字，就问步数预算，问脚手架，问试了几次，问是哪个版本。把这四个问出来，大多数夸张就会被自己的重量压垮。

参考资料

Discuss on Twitter • View on GitHub