8 月 14 日，Turing 发布了对 3,600 次 Terminal-Bench 3.0 试验的分析，得出一个反直觉的结论：能干的前沿 Agent 越来越多地不是「执行不了」，而是「执行了错误的问题」——甚至在通过自己的检查时依然答错。在全部失败中，65.4% 以「自信的假完成」收场：Agent 跑了自己的检查、把结果读成通过、然后宣布成功。
Turing 同期还发布了 CompanyBench，一个把 Agent 放进真实金融科技公司五年运营数据里干活的 benchmark。两件事指向同一个评测方法论问题：当「验证」由 Agent 自己执行时，它测的是模型能不能发现自己的错误，而不是模型有没有做对——这两件事在更强的模型身上，反而越可能分离。
Terminal-Bench 3.0：从一个饱和的基准，到更难的下一代
Terminal-Bench 由 Stanford 与 Laude Institute 合作运营，用容器化的终端任务衡量 Agent 能否完成有价值的计算机工作。2.1 版本已被前沿 Agent 打到 75%–84% 的解决率，接近饱和，难以再区分模型。因此团队把新一代 benchmark 更名为 Terminal-Bench 3.0（曾用名 Frontier-Bench），8 月初发布 v0.1：74 个任务、7 个领域、31 个子领域。官方公告称，最佳模型只有约 34% 的通过率。
这个数字随评测框架不同而浮动。Snorkel 维护的 leaderboard 上，Claude Opus 5 配 mini-SWE-agent 达到 42.7%，用 Codex 的 GPT-5.6 Sol 是 34.6%、Claude Code 的 Fable 5 是 34.1%，随后跌到 Grok 4.6 的 26.5%、Opus 4.8 的 21.1%。同样的「harness 敏感性」正是一周前本栏目讨论 DeepSeek V4 Flash 复现时的主题；3.0 把基准线整体压低，但并不能消除框架差异。
这次改版不只是「更难」。官方公告强调三项结构性变化：语义化版本与结果迁移，让任务可以被重跑、重评而不必重做整套 benchmark；把 agent 容器与 verifier 容器分离，防止 agent 通过篡改评测环境刷分；把「好任务」的定义从「难」改为「难在正确的理由上」。Scale 自称贡献了首发集中最多的任务，Turing 也是主要贡献组织之一。
自检为什么测不出「解错了题」
Turing 的 3,600 次试验分析，是这轮发布中最值得注意的部分，因为它量化了一个此前只有定性描述的失败模式。关键数字不在失败率本身，而在失败与检查之间的关系：
- 98.2% 的失败仍产出一个「可用但内容错误」的成品，只有 1.8% 失败在交付环节——失败几乎从不表现为「什么都没做出来」；
- 无论成败，Agent 运行自检的比例几乎相同：通过组 76.4%，失败组 76.8%。「有没有跑检查」几乎不携带任何关于正确性的信息；
- 失败时 Agent 声称成功的比例（84.3%）反而略高于成功时（80.6%）；
- 65.4% 的失败以「自信的假完成」收场。
机制很直接。Agent 先对任务形成一个解读，再基于这个解读去求解、去构造检查。当解读错了，解法和检查都是这个错误解读的下游——检查继承了解读里的同一个错误，于是「通过」只证明解法与解读一致，不证明解法与任务一致。这也解释了为什么「多加自检」无效：如果检查与解法共享同一个错误前提，再多的检查也只能确认错误。
Turing 把最大的失败来源归为「范围」而非「逻辑」：38.4% 源于误读问题本身，28.8% 源于对某条明确要求的欠建模，22.1% 源于漏掉一个明确的数字门槛。这与 Scale 在任务设计中的观察一致——模型「执行」没问题，缺的是第一步：读懂问题结构、选对约束，而不是抓最顺手的方法。
CompanyBench：把同一个问题放进真实企业
CompanyBench 把同一主题推进到更贴近生产的环境。它用一家金融科技公司五年的真实运营历史——数百张数据库表、数千个文件、数百万条 Slack 消息、邮件和 Jira 工单，全部做 PII 脱敏——构造了 64 个长时程任务，每个任务跑 10 次。结果 GPT-5.5 完成 44%、Claude Opus 4.8 完成 36%。
四个反复出现的失败模式里有三个与推理无关：不查文档就猜、去搜根本不存在的文档、套用过滤器把有效数据悄悄删掉。第四个更尖锐——算出了正确答案，却没完成最后一步，比如没有把结果发到 Slack 或没有提交工单。一个在终端里「答对」的 Agent，在真实工作流里仍然可能是失败。
这些数字能说明什么，不能说明什么
首先要明确来源边界。Turing 既是 benchmark 的贡献者，也是评测数据与训练数据的卖家；「3,600 次试验」的方法学细节——如何判定一次失败属于「假完成」、是否区分模型自检与外部校验——尚未公开。65.4% 是厂商自述数字，需要独立复现才能成为稳定结论。CompanyBench 同样有外部效度问题：它来自单一金融科技公司，五年历史数据能否代表「企业知识工作」的多样性存疑，脱敏处理是否改变任务真实难度也未见说明。
但即使把这些打折，「自检盲区」这个命题本身并不依赖 Turing 的数字。它对应一个朴素的工程常识：验证必须独立于被验证的对象。对 Agent 而言，这意味着把「检查」从它手里拿走——用独立于模型解读的 verifier 去测模型没想到要测的东西，而不是让它复述自己的解读。Terminal-Bench 3.0 把 agent 容器与 verifier 容器分开，正是朝这个方向的机制性修正。
对评测实践者，最直接的含义是：「通过自检」不能作为正确性的证据；报告需要把「模型自评」和「独立验证」分开计数，否则相当比例的失败会在「全部通过」的表象下静默发生。下一项值得观察的变量，是 Turing 是否会公开 3,600 次试验的原始轨迹与判定标准——在此之前，「自信地出错」的精确发生率应被当作待验证的假设，而非定论。
