2026 年 9 月 18 日

1 / 3

Anthropic 首次量化“AI 帮助制造下一代 AI”：Claude 已主导 26% 的内部模型研发任务

Anthropic 9 月 17 日公开了一组少见的内部生产指标。它没有再用 benchmark 分数表示模型进步，而是试图测量前沿实验室的生产过程：AI 已经参与多少下一代模型研发、这些内部 Agent 能否被有效监督，以及训练算力中有多少投入安全工作。按照 Anthropic 的 R&D Automation Index，截至 2026 年 8 月，Claude 在 26% 的 AI R&D 工作中达到 AL4“leads”——即人类给出高层目标并监督，模型可以端到端完成任务的大部分工作；2 月这一比例还低于 1%。超过 90% 的研发工作至少达到 AL3“collaborates”，但没有任何被测任务达到 AL5，即完全没有人在环的自主研发。Anthropic 原始报告

这个 26% 的测量方法本身很值得细看。Anthropic 从 Slack 和内部文档抽样出约 1.5 万个具体研发任务，再把它们组织成一个包含 542 个节点、378 个叶节点的工作树，里面已经出现“eval platform defect diagnosis and fixes”“RL sandbox egress and network policy”“serving incident postmortems”这类相当具体的工作。每个节点由 Claude research agent 搜集证据，再由独立 Claude judge 按 Epoch AI 提出的 AL0–AL5 automation scale 评级，最后按人类投入的 person-time 加权。

这里自然存在一个问题：Claude 在给 Claude 的工作打分。Anthropic 因此让负责相应工作的员工在不知道模型证据和判断的情况下独立评级。结果模型与人的 exact agreement 是 59%，而人和人之间只有 35%；如果允许相差一个 automation level，模型与人的一致率达到 97%。这并不能消除 self-judge bias，尤其“collaborates”和“leads”的边界本身具有主观性，但至少使 26% 不只是员工随手估出的一个数字。Anthropic 也明确提出，未来这类指标应该由第三方或其他开发者的模型验证。

更有意思的是 Agent 规模。Anthropic 称，在其最常用的内部研发平台上，任意时刻大约运行着 30,000 个 research / engineering agents。所有动作在执行前都会经过 online monitor，执行后又全部进入 offline monitor。2026 年 8 月超过 10 亿次 Agent 决策中，online monitor 阻止了 0.002%，约每 47,000 次一次；offline monitor 每周先筛出约 10 万条 transcript，再由分类器过滤，最终约 50 条升级到人工检查。Anthropic 原始报告

这个数字的解释边界也很重要。0.002% 不能直接读成“Agent 出错概率”，它测的是被当前 online monitor 判定需要阻止的动作；漏检行为不会进入分子。真正有意义的监控指标至少还需要 monitor coverage、检测召回率、review latency 和 escalation rate 一起看。Anthropic 自己也因此提出开发者应该公开已知 misbehavior 被 monitor 捕获的比例，并允许第三方独立 red-team 监控系统。

第三个数字是算力。Anthropic 对 7 月 13–20 日的一周计算资源做分类，称 AI R&D compute 中约 6% 用于 safety；如果只看 AI-driven AI R&D，这个比例约为 12%。它同时承认 compute 并不是安全投入的理想代理变量：许多安全研究主要消耗研究人员时间，而一次 frontier training run 天然消耗大量 GPU。因此这个指标更适合看同一实验室随时间的变化，或者在各实验室使用统一分类方法之后横向比较。Anthropic 原始报告

对 eval 来说，这份报告提供了一个此前很少被量化的对象：模型能力评测之外，还可以评测“模型在研发闭环中实际承担了多少工作”。如果一个模型在 coding benchmark 上提高 5 分，却没有增加能独立完成的真实 R&D task 比例，两者代表的技术意义不同；反过来，如果 benchmark 改善有限，但 AL4 工作比例快速增长，则说明 harness、工具和组织流程可能把能力转化成了更强的自动化。Anthropic 的数据目前只有单个实验室、单套自建方法，下一步真正有价值的证据是 OpenAI、Google DeepMind 等实验室按可比较方法发布相同指标。

2 / 3

AutoTuneBench：Agent 报告的 10.6× kernel 加速，在严格基线下只剩 2.03×

9 月 16 日提交、17 日更新的 AutoTuneBench 专门研究一种越来越现实的 Agent 工作：让 LLM 自动修改 GPU kernel 或 vLLM、SGLang 这样的 serving engine，然后运行 benchmark，保留更快的版本。作者 Li Chen 从一个持续四天、包含 619 次模型调用的 pilot corpus 中发现，问题往往不在 Agent 不会优化代码，而在 Agent 同时拥有“修改系统”和“证明自己变快了”的能力。AutoTuneBench 论文

论文总结出四类会制造虚假提升的机制。第一是 strawman baseline：如果比较对象本身配置得很差，Agent 很容易产生惊人的倍数；第二是绝对 latency 不可跨机器直接比较；第三是任务已经碰到共同的性能上限时，两个配置实际上没有可测差异；第四是基础设施缺陷会被误认成算法改进。作者给出的一个例子非常直观：同一个“最佳 kernel”相对 naive baseline 看起来快 10.6×，换成他们认为合理的 baseline 后只剩 2.03×。另一配置在一台机器得到 1.174×，换机器后只剩 1.0049×。

AutoTuneBench 的做法因此不是再增加一个 judge，而是把测量协议移到 Agent 无法修改的控制面。protocol 以代码冻结；数据库 validator 拒绝不符合协议的结果；anti-cheat checks 放在 Agent modification surface 之外；比较指标预先注册；实验使用 paired-seed statistics，并要求跨运行 coefficient of variation 不超过 5%。换句话说，Agent 可以自由修改被优化对象，但不能自由修改“什么算赢”。

这套约束改变了不少结论。作者对 KernelBench Level-1 重新检查后，只有 51% 的任务能够进入有效比较，而这些任务相对 PyTorch eager 的 median speedup 只有 1.0001×。一个预注册的 on/off 实验得到 2.4840 ms 对 2.4957 ms，在共同性能墙上基本没有差异。论文同时发布了 vLLM、SGLang 两套 serving-engine corpus 和完整 audit trail。AutoTuneBench 论文

这个问题和普通 LLM-as-Judge 的偏差不完全相同。这里 evaluator 甚至可以是精确的计时器，结果仍然可能错，因为实验对象改变了 baseline、机器条件或测量路径。对 Agent benchmark 来说，这提示了一种更一般的设计原则：凡是 Agent 可以修改环境的任务，都应该明确划出 immutable evaluation surface。文件系统任务可能是隐藏 tests，浏览器 Agent 可能是外部状态验证器，业务 Agent 可能是独立 transaction log；否则 Agent 的优化空间里可能悄悄包含 evaluator 本身。

3 / 3

Agent Waste Index：34 万条 coding trajectory 显示，模型与 harness 制造的是两类不同浪费

9 月 17 日公开的 Agent Waste Index 从 11 个公开 coding-agent trajectory 数据集汇总了 341,054 次运行，包括 SWE-smith、SWE-rebench、Open-SWE-Traces 等，再用统一 detector 检查循环、blind retry、超大 tool output、被放弃的运行以及不同 trajectory 长度的估算成本。它不是新的能力 leaderboard，而是在已有轨迹上重新测量“Agent 把 token 和步骤浪费在哪里”。Hugging Face 研究说明

最清楚的结果是两类浪费来源不同。loop 和 blind retry 更像模型能力问题：基于 2024 年 Llama 的 Agent 中，这类行为占 14%–22%，Claude 3.7 Sonnet 已低于 1%，Qwen3-Coder-480B 低于 1.3%。但 oversized tool output 明显跟 scaffold 走：同属 Open-SWE-Traces 系列的数据，经 mini-swe-agent、OpenHands 和 SWE-agent 产生超过 20,000 字符 observation 的比例分别约为 0.1%、50% 和 55%。模型没有改变，harness 就能把 context consumption 拉开两个数量级。

另一个值得继续验证的观察是 trajectory 长度。按步骤数划分后，最长的 20% 运行消耗了约 40% 的估算成本，但 resolution rate 只有最短 20% 的 0.15–0.91 倍。这个结果不能直接推出“长 trajectory 应该提前终止”，因为困难任务天然可能既更长、又更容易失败；如果不按 task difficulty 配对，长度和失败之间存在明显混杂。更合适的下一步是对同一道题的多次 rollout 比较：当 Agent 超过某个相对步数或重复动作阈值之后，继续运行的 marginal success probability 是否已经低于成本。

这批数据和前两天 Real-SWE 暴露的问题可以放在同一个实验框架里，但不需要合并成一个分数。能力 eval 测 Agent 最终有没有解决任务，trajectory audit 则测它用了怎样的路径、多少无效动作和多少 context。对同一模型跨 harness 同时记录 resolution、token / tool cost、loop rate、oversized observation 和 step distribution，才有可能区分“模型变聪明了”和“脚手架减少了浪费”这两种改善。