8 月 14 日，Turing 发布了对 3,600 次 Terminal-Bench 3.0 试验的分析，发现一类常见错误：前沿 Agent（智能体）能执行任务，却可能误解要求，甚至通过自己的检查后仍然答错。在全部失败中，65.4% 以「自信的假完成」收场：Agent 跑了自己的检查、把结果读成通过、然后宣布成功。
Turing 同期还发布了 CompanyBench，一个把 Agent 放进真实金融科技公司五年运营数据里干活的 benchmark。两项工作提出了同一个评测问题：Agent 能否发现自己的错误，与它是否完成任务，并不完全一致。只依靠自检，可能漏掉这两者之间的差异。
新版终端任务更难，模型成绩也受评测框架影响
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 也是主要贡献组织之一。
Agent 误读要求后，自检可能沿用同一个错误前提
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 把同一主题推进到更贴近生产的环境。它用一家金融科技公司五年的真实运营历史——数百张数据库表、数千个文件、数百万条 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 次试验的原始轨迹与判定标准——在此之前，「自信地出错」的精确发生率应被当作待验证的假设，而非定论。
