CursorBench 3.2：多文件 Agent 的成功率与成本

历史资料说明

本页正文保留 2026-09-08 采集的历史研究记录。页面上方编辑摘要与条件已于 2026-09-20 复核；正文中的“当前”、排名和动态数值均指原采集快照，不代表今天的实时结果。请在决策前打开原始来源核对。

一句话结论

在 CursorBench 3.2 的当前榜单中，Gemini 3.8 Flash High 为 69.2%（列出的 60 个配置中第 9），平均每题 $2.38、81,524 tokens、161 steps；Medium 为 67.0%（第 14），每题 $1.93、61,603 tokens、136 steps。相较同页 Gemini 3.7 Flash，3.8 在 High/Medium 分别高 7.6/8.0 个百分点，但也几乎消耗两倍 token 和成本；这只说明其在 Cursor 的模糊多文件 Agent 任务上有更高分和更高工作量，不能外推为通用编码能力或 API 性价比。

适用场景

• 适合观察的任务：来自真实 Cursor 会话的模糊、多文件代码任务；代码库理解、规划、修复、重构、代码审查，以及 CursorBench 3.2 新增的指令遵循和高级工具使用。

• 不适合直接推断的任务：单文件算法题、中文编程、通用 API 调用、非 Cursor 工具链、长时间无人值守 Agent、生产稳定性或所有软件工程任务。

• 适用的模型版本：榜单明确列出的 Gemini 3.8 Flash High 与 Gemini 3.8 Flash Medium；不能延伸到未公开的 API snapshot、其他 provider 或 Gemini 3.8 Flash Cyber。

• 适用的客户端、Agent 或 API：Cursor Agent 的 CursorBench 3.2 harness；不是 Gemini API、Gemini App 或自建 coding Agent 的端到端成绩。

• 推荐档位：复杂多文件任务可优先测试 High；预算和步骤敏感的任务可测试 Medium。原页没有公开足以复现的 temperature、system prompt、工具 schema、重试或上下文配置。

测试环境与方法

• 任务来源：Cursor 的方法说明称，CursorBench 使用 Cursor Blame 将已提交代码追溯到生成代码的 Agent 请求，从而获得开发者查询与标准答案解决方案的配对；许多任务来自内部代码库和受控来源，以降低训练污染风险。

• 任务形态：任务描述刻意保持简短、信息不充分且可能有歧义，更接近开发者对 Agent 的真实请求，而不是公开仓库中写得很完整的问题单。CursorBench-3 相比初始版本大致增加了代码行数和平均文件数，并覆盖 monorepo 多工作区、生产日志排查和长时间运行实验等更复杂场景。

• 评测版本：当前结果页为 CursorBench 3.2；变更记录显示 2026-07-08 加入指令遵循和高级工具使用问题。3.1 曾加入代码库理解、找 bug、规划和代码审查任务，并改进部分编辑任务的评分标准。

• 评分维度：Cursor 说明实际会评估解决方案正确性、代码质量、效率和交互行为；当前公开榜单只提供一个综合 SCORE，没有公开 Gemini 3.8 Flash 的分维度得分、题目数量或逐题评分。

• 成本口径：原页说明平均每题成本按模型公开的输入、缓存读取、缓存写入和输出单价，乘以每题实际使用的 token 计算：

  平均每题成本 = Σ（各类 token 数 × 对应的每百万 token 价格）

• 在线/离线边界：方法文章称 Cursor 还用真实流量上的受控在线分析补充离线 CursorBench，用于发现“评分器判对但开发者体验更差”的回退；当前榜单没有公开 Gemini 3.8 Flash 的在线指标，因此本文只报告 3.2 离线结果。

结果数据

CursorBench 3.2 当前榜单

同页相邻配置中，Gemini 3.8 Flash High 的 69.2% 略低于 Fable 5.1 High 的 69.4% 和 Opus 5 Extra High 的 69.3%；Gemini 3.8 Flash Medium 的 67.0% 略低于 GPT-5.6 Sol Max 的 67.2%，高于 Opus 5 High 的 66.7%。这些配置不是统一模型快照或同一推理档位，不能把相邻小差异当作稳定胜负。

3.8 与 3.7 的同页差异

这些是榜单行之间的描述性差值，不是控制变量后的升级因果估计。Cursor 页面特别提示结果存在方差，小分差未必具有统计意义。

结论

1. 3.8 在该 Agent 任务集上明显高于 3.7：High 从 61.6% 到 69.2%，Medium 从 59.0% 到 67.0%；方向与 CursorBench 3.2 面向多文件、工具使用和模糊请求的任务设计一致。

2. 提升伴随更高执行量：3.8 High 平均 161 steps、81,524 tokens，远高于 3.7 High 的 99 steps、38,448 tokens；更高分不能单独解释为“更快”或“更便宜”。

3. High 的额外分数有成本：相对 3.8 Medium，High 高 2.2 个百分点，但每题多 $0.45、19,921 tokens 和 25 steps。由于页面不提供置信区间和逐题结果，不能断言这 2.2 个百分点在统计上可靠。

4. 它测的是 Cursor 工作流中的 Agent：任务来源、Cursor 工具环境、评分器和公开价格成本共同决定结果。脱离 Cursor harness 后，69.2% 不能直接当作 Gemini 3.8 Flash 的裸模型代码正确率。

局限与边界

• 平台方基准的独立性边界：CursorBench 由 Cursor/Anysphere 设计、运行和发布，虽然比较的是 Google 等外部模型，但不是无利益关系的中立实验室评测；产品方的 Agent harness 和任务分布会影响结果。

• 题集不可完全复现：任务来自真实 Cursor 会话、内部代码库和受控来源，页面未公开完整题目、仓库、标准答案、评分器、题目数量、运行次数或逐题输出。

• 配置不完整：榜单只公开 High/Medium 标签及汇总分数、token、steps 和成本；未公开 API snapshot、system prompt、temperature、上下文窗口、工具权限、随机种子、重试和失败处理。

• 榜单位置不是模型排名：当前表格把同一模型的多个推理档位也作为独立配置行；“第 9”是 60 个配置中的位置，不是 60 个不同模型的排名。

• 成本不等于账单：成本由公开 token 价格和评测中实际 token 计算，可能与用户账户的缓存命中、provider 路由、折扣和并发账单不同；steps 也不是 API 请求次数的通用定义。

• 统计不确定性：原页明确说结果存在方差，小分差可能没有统计意义；未提供 Gemini 3.8 Flash 的置信区间、单次得分或失败样本。

• 版本与时间：3.2 的变更记录为 2026-07-08，本文按 2026-09-08 打开的当前榜单记录；页面后续可能重算价格或刷新结果，不应与其他版本混写。

• 范围有限：虽然方法文章提到线上受控分析，但当前公开表只提供离线榜单数字；这不覆盖真实用户满意度、长时段自主任务成功率、中文语境和生产级代码安全性。

复现建议

1. 固定 CursorBench 3.2 的题集版本、仓库 commit、工具权限、Agent system prompt、模型 snapshot、推理档位、上下文上限、停止条件和重试策略；若无法取得内部题集，应明确标为“CursorBench 风格独立复测”。

2. 在同一题集上分别运行 Gemini 3.8 Flash High、Medium 和 Gemini 3.7 Flash；保存每次规划、工具调用、修改 diff、测试结果、token、steps、等待时间和失败恢复。

3. 采用多次运行并报告均值、方差或置信区间；不要只复述 69.2% 或相邻名次。

4. 将解决方案正确性、代码质量、效率和交互行为分开评分，并单独记录越权修改、未验证声明、人工接管和返工时间。

5. 成本按输入、缓存读写和输出 token 分项计算；同时报告实际账单口径，不能把 CursorBench 的 $2.38/题 当作任意 Gemini API 请求价格。

原始证据与数据

• CursorBench 3.2 原始榜单：https://cursor.com/cursorbench。页面定义任务为来自真实 Cursor 会话的模糊、多文件任务，并列出 Gemini 3.8 Flash High 69.2%、$2.38、81,524 tokens、161 steps，Medium 67.0%、$1.93、61,603 tokens、136 steps；同时列出 3.7 High 61.6% 和 Medium 59.0%。

• 同一榜单的变更记录显示 2026-07-08 的 CursorBench 3.2 加入 instruction following 与 advanced tool use problems；页面还说明平均每题成本按公开 token 价格和每题 token 使用量计算，并提示小分差可能无统计意义。

• Cursor 方法说明：https://cursor.com/blog/cursorbench。文章说明任务用 Cursor Blame 从真实提交回溯 Agent 请求，许多任务来自内部代码库和受控来源；任务保持信息不充分，覆盖多文件、monorepo、生产日志和长时间运行实验，并以线上受控分析补充离线基准。

来源摘录或观察（仅做合规短引）

CursorBench 原页将任务概括为“ambiguous, multi-file tasks from real Cursor sessions”，方法文章则强调离线评测与真实流量在线分析结合。它支持的核心判断是 Cursor 工作流中的多文件 Agent 表现，不是 Gemini 3.8 Flash 的通用代码能力总分。