AI 系统正变得越来越强大，也越来越多地被用于构建自身的下一代版本。
我们希望让公众看清这一进展的速度。
为此，我们分享三项衡量指标，帮助公众追踪前沿 AI 实验室内部的 AI 开发情况：AI 研发有多少由 AI 自身完成、AI 智能体的行为受到怎样的监督，以及算力如何分配。
AI 系统的能力正在呈指数级增强，并已开始让构建自身的过程更多地实现自动化。当世界开始考虑放缓前沿 AI 开发的步伐时，公众需要获得更多信息。
本文介绍一些测量工具，用于揭示 AI 开发中三个关键方面的情况：
我们也提供了 Anthropic 内部这些指标的一次快照。需要说明的是，如果各方按照 Anthropic 首席执行官 Dario Amodei 的呼吁，协调控制前沿 AI 的发展速度，我们预计这些数字会发生变化。我们计划让来自多个组织的独立第三方评估人员进驻 Anthropic，并赋予他们对内部流程、系统和数据的访问权限，其范围与内部风险评估团队相当。这些第三方将核验安全实践、报告事件，并监测本文所述的关键指标。
我们公布这些测量结果，是为了让公众、第三方和政府更清楚地了解前沿实验室内部 AI 开发的速度。对于每项指标，我们都会说明测量了什么、结果如何，以及要以可供他人核验的形式定期发布这些结果，还需要做什么。方法细节见附录。
为什么要追踪这些指标
本文的指标关注的是模型如何被构建。更好地理解模型的生产过程，有助于我们将模型的投入（如算力）与产出（如能力）联系起来。这些指标补充了衡量模型能做什么的能力评估。我们通过《负责任扩展政策》（Responsible Scaling Policy，RSP）风险报告另行发布能力评估，其中包括模型在多大程度上加速 AI 研发的证据。在关于先进 AI 的政策提案《先进 AI 框架》（Advanced AI Framework，AAIF）中，我们提出了适用于各实验室安全发布模型的基本规则，包括政府可以要求履行的透明度义务，例如发布风险报告。这些建议的测量指标与政策，共同构成了从实验室外部监测 AI 开发速度的起点。
（1）衡量 AI 主导的 AI 研发
为什么要衡量 AI 主导的研发？ 前沿 AI 实验室越来越多地使用 AI 来构建未来的 AI 模型。这一过程让民主国家的实验室能够更快地开发更强大的模型，并在发布前开展更多安全工作和测试，从而在保持前沿地位的同时，确保 AI 带来益处。然而，模型加速自身开发，也可能使人类更难理解或控制这些系统。因此，分享这些指标很重要，有助于理解世界距离递归式自我改进——即模型完全自主地构建自己的继任者——还有多远。
我们测量了什么。 我们建立了一个原型指数，用于衡量 Anthropic 的 AI 研究与开发（R&D）有多少由 Claude 完成，称为 Anthropic 研发自动化指数（Anthropic R&D Automation Index）。构建方法是：整理公司开展的各类 AI 研发工作，评定每项任务当前的自动化程度，再汇总这些评分。
我们发现了什么。 为衡量 AI 在 Anthropic 承担 AI 研发的程度，我们采用了 Epoch AI 制定的自动化等级量表，衡量“自动化等级”（Automation Level，AL）。量表从 AL0（没有 AI 参与）到 AL5（AI 完全自主运行，无需人类参与）。在 AL3，AI 扮演“协作”角色：它能够在人类密切指导下完成大量工作。在 AL4，AI 扮演“主导”角色：只需一条高层次提示，就能端到端完成任务的大部分工作，而人类负责监督。1
截至 2026 年 8 月：
- 在已测量的 AI 研发工作中，没有任何一类工作由 Claude 完全自主完成。
- Claude “主导”了 Anthropic 26% 的 AI 研发工作。
- 达到或超过“AI 协作”等级的工作占比超过 90%。
任何 AI 开发者今天都可以报告什么。 任何前沿 AI 开发者都可以采用公开的方法，定期发布这些指标。这使得跨时间比较成为可能，也可能支持实验室之间的比较。
这类报告在跨实验室比较时面临两个障碍。第一，缺少共同的方法。第二，我们使用自己的模型评估自己的系统，这意味着“评审”模型可能与被评估模型犯同类错误。为应对这些挑战，可以由第三方或其他开发者的模型核验测量结果，同时设置防护措施，限制涉及竞争敏感信息的数据交换。这些指标也可以成为触发更严格要求的条件，例如：新模型在投入后续 AI 研发前，必须经过一段固定的测试期。
（2）衡量对 AI 智能体的监督
为什么要衡量对智能体的监督？ 与其他前沿 AI 开发者一样，Anthropic 员工越来越多地将任务交给能够长时间半自主运行、并相互委派工作的智能体。随着工作从“AI 协作”走向“AI 主导”、自动化程度不断提高，智能体可能会作出影响更大的决定，例如下一步探索哪个研究方向。
这些决策既需要防护机制来阻止单个智能体的有害行为，也需要一套监督机制来发现只有在大量智能体共同运行时才会出现的问题。在迄今的监测数据中，单个智能体很少出现不当行为。但当经济活动中运行着数百万乃至数十亿个智能体时，即使罕见事件也可能经常发生。
我们测量了什么。 我们构建了一套系统，使我们能够监督和干预 AI 智能体在 Anthropic 系统中的行动。这里考察三个不同指标：覆盖率，即智能体行动在执行前或执行后经过监控的比例；审查延迟，即从行动发生到先由自动监控系统、再由人类审查所经过的时间；以及升级处理率，即智能体活动被阻止或改向的比例（在线监控），或被标记以供进一步审查的比例（离线监控）。
我们发现了什么。 截至 2026 年 8 月，在我们使用最多的内部平台上，任一时刻大约都有 30,000 个智能体在 Anthropic 从事研究和工程工作。这些测量仅覆盖该平台。它们的行动受到两类监控系统的约束，汇总如下：
| 指标 | 在线监控系统 | 离线监控系统 |
|---|---|---|
| 说明 | 在线监控系统实时检查智能体的行动，自动阻止危险行动或纠正不当行为。它们用于应对发生迅速、无法撤销的危害，例如智能体将模型权重从我们的系统中复制出去。 | 离线监控系统在事后读取智能体活动记录。它们用于帮助应对缓慢发展、可以逆转的危险行为，例如模型失配的迹象。我们利用被标记的活动改进缓解措施，例如分类器和确定性控制机制。如果情况造成重大且迫在眉睫的危险，我们会关闭智能体部署中危险的部分。 |
| 覆盖率 | 这些智能体 100% 的行动都会在执行前经过在线监控，通常在几秒内完成。 | 这些智能体 100% 的行动都会在执行后被纳入监控系统。 |
| 审查延迟 | 自动审查在智能体采取行动之前完成；人类会在一周内审查所有被阻止的行动。 | 监控系统每周标记约 100,000 份交互记录，随后由多个分类器检查误报并进行初步监督审查。大多数标记通过这一流程得到处理，优先级最高的标记（每周约 50 份）会升级至人工审查。 |
| 阻止率／升级处理率 | 我们分析了 2026 年 8 月研究与工程智能体作出的超过十亿次决策，发现其中 0.002%（约每 47,000 次中有 1 次）被该监控系统阻止。 | 监控系统大约每 1,000 份交互记录中标记 1 至 2 份，以供进一步审查。 |
AI 开发者今天可以报告什么。 任何在自身研究和工程工作中运行智能体的开发者，都可以公布相同指标：覆盖率（被监控的智能体活动占比）、审查延迟（被标记活动多快得到审查）和升级处理率（监控系统阻止或标记的智能体活动占比）。这些指标结合起来，可以让社会看清：随着 AI 在 AI 研发中发挥越来越大的作用，监督是否跟上了步伐。我们已在近期的风险报告中公布了所有这些测量结果。
开发者应公布监控系统能够发现已知智能体不当行为的频率，并让第三方独立开展这类测试。此前，METR 曾独立对我们的离线监控平台进行红队测试。如上所述，我们现在正在 Anthropic 引入外部第三方评估人员。
（3）衡量算力分配
为什么要衡量算力分配？ 总体而言，AI 开发者将算力用于构建更强大的模型、服务客户，以及以安全为重点的工作，例如审查模型的“思考”、训练用于研究失配的模型实验对象，以及评估模型能否安全部署。了解 AI 开发者如何分配算力，可以揭示其资源重点，以及这种重点如何随时间变化。
此外，算力是 AI 研发过程中最容易核验的投入之一，因此可能成为未来协调发展速度时的关键调节手段。协调控制发展速度，可以鼓励整个行业的企业增加安全工作的算力投入，并将更多资源用于对齐、可解释性、安全测试和评估。
我们测量了什么。 我们查看了 Anthropic 在 7 月 13 日至 7 月 20 日期间全部算力使用情况的一次快照。2 为此，我们将每项工作负载归入少数几类，然后考察投入 AI 研发的算力中，有多少用于安全工作。
安全研究从工作性质上看，通常比前沿模型训练消耗更少的算力，因此算力并不能完美代表一家公司对安全的重视程度。这是因为安全研究需要研究人员逐个设计实验，这一过程很耗时，但执行实验本身并不特别消耗算力。因此，这项指标的价值，与其说在于绝对数值，不如说在于：它提供了一种直观的机制，让我们能够跨开发者、跨时间，在相同口径下进行比较。
我们发现了什么。 在考察的这一周中，用于 AI 研发的算力约有 6% 分配给了安全工作；而用于 AI 驱动的 AI 研发的算力中，约有 12% 分配给了安全工作。
这些估计有意采用了保守口径。例如，如果一个 token 对能力提升和安全提升的作用相当，就不会计入这些指标的安全部分。此外，这些指标没有计入安全防护分类器；它们另外消耗了规模相当的一部分算力，并显著提高了模型在现实世界中的安全性。
AI 开发者今天可以报告什么。 任何前沿 AI 开发者都可以公布其 AI 研发算力中用于安全工作的比例，同时公开类别定义，并由独立第三方核查分类结果。
安全研究与能力研究很难区分，每个开发者都可能倾向于放宽安全工作的界定。证明一项工作与安全有关的责任，应由开发者承担。开发者、政府和更广泛的研究群体如果能够事先形成共同定义，都会从中受益。这样的指标可以为未来行动提供依据，例如实验室对安全研究算力占比作出承诺，或限制分配给 AI 研究智能体的算力比例。
结论
当世界开始考虑协调前沿 AI 的发展速度时，我们应尽一切可能，缩小前沿实验室所知与公众所知之间的差距。这意味着更好地衡量 AI 的开发情况、公开报告，并给社会一个决定如何使用这些信息的机会。我们希望通过发布这些测量结果，为透明度作出示范，也会继续这样做。
附录
以下是我们已开展原型验证的各项测量的方法细节。
衡量 AI 主导的研发
我们如何测量。 自动化指数需要三样东西：Anthropic 正在开展的全部 AI 研发任务的完整图谱、评定自动化等级的方法，以及对任务赋予权重的方法，以便重要工作的计入权重大于不太重要的工作。没有任何一个人能手工列出前沿 AI 公司中的所有 AI 研发任务，至少无法达到我们需要的细致程度。因此，我们根据工作记录，包括 Slack 和各种内部文档，自下而上构建了这份任务清单。
在 2026 年 7 月的每一周，我们都从参与模型研发循环的各部门随机抽取 20% 的员工。Claude 研究智能体通过 Slack 和内部文档回顾每位被抽样员工一周的工作，列出他们参与的任务。对 7 月的每周重复这一过程后，我们得到了一份约含 15,000 项细粒度模型研发任务的扁平清单。随后，我们使用 Claude 将这些任务组织成一棵层级树：从根节点“全部模型研发”出发，分支到训练、产品等领域，再细分到预训练、强化学习，并逐层延伸到更具体的工作类型。最终，这棵树在不同深度上共有 542 个节点，其中 378 个为叶节点，例如“评估平台缺陷诊断与修复”“强化学习沙箱的出站访问与网络策略”“模型服务事故复盘”。我们固定这棵树，使每次测量都针对同一组工作。
对于树中的每个节点——也就是描述其下全部工作的任务类别——一个 Claude 智能体会深入研究这类工作在公司内如何开展：由谁完成、使用什么工具，以及其中有多少由 AI 执行。随后，一个独立的 Claude 评审模型读取这些证据，采用 Epoch AI 提出的量表，将其评为六个自动化等级之一：没有 AI 参与、极少量 AI 参与、AI 辅助、AI 协作、AI 主导或 AI 自主运行。评定某个月的自动化程度时，我们只允许负责评分的研究智能体查看该月及之前的证据。
为了将所有自动化等级评分汇总成一个数值，我们希望树中每个节点的权重能反映该项工作对整体模型研发的重要性。我们没有自行决定哪类工作比其他工作更重要，而是用投入该任务的人力时间作为近似指标。依据样本，我们让 Claude 研究每个人在 2026 年 7 月每周做了什么。每个人每周获得 1 个单位的权重，再平均分配给其当周参与的任务。如果 A 做了 4 项任务，每项获得 0.25；如果 B 做了 10 项任务，每项获得 0.10。一个类别的权重，就是分配给它的全部人力时间权重之和。这是一种粗略近似，但平均而言具有合理性：分配了更多人员的类别会获得更高权重。
它能反映什么，不能反映什么。 首先，自动化评分依赖评审模型。为检验评分，我们请负责相关工作领域的 Anthropic 员工评定自己领域的相对自动化程度。为确保判断不受先入信息影响，员工评分时并不知道模型收集了什么证据，也不知道模型如何判断这些证据。我们的评审模型与人类达成一致的频率，与人类之间达成一致的频率大致相当（模型与人类完全一致的比例为 59%，人类之间为 35%）；模型与人类评分相差不超过一个等级的比例为 97%。对于边界情况，仍然存在明显的分歧空间，例如“AI 协作”究竟在哪里结束、“AI 主导”又从哪里开始。
其次，任务集合是固定的。以 2026 年 7 月为基准的指数不断上升，说明人类当时所做的工作正在自动化；但单凭这一点，无法判断是否出现了新的工作类型，以及人类是否转而从事这些新工作。为调查这一点，我们使用 2026 年 1 月的数据构建了另一版固定任务树，并将 2026 年 2 月至 7 月每月出现的新任务与 1 月的任务集合比较。我们发现，1 月与 7 月的任务集合之间，“新颖”任务的数量并未增加，这表明在我们采用的分析粒度上，模型研发工作的结构是稳定的。尽管如此，我们仍计划定期重建任务集合，并在适当时为已公布的自动化数据更新版本。
对智能体的监督
我们如何测量。 在我们最常用的内部智能体运行框架（scaffold）中，两项设计让我们更容易发现“未知的未知”，并让智能体相互监督：
- 身份。 大多数 AI 用户习惯在多个不同聊天中与同一个“Claude”对话。当多个智能体协作时，我们发现，为每个智能体赋予独立身份，并将其创建的全部数据与该身份绑定，非常重要。这让智能体能够区分自己与其他智能体，并把其他智能体提供的信息视为待核查的说法，而非自己的想法。它允许智能体依据各自经历作出判断，从而降低多个智能体采取相关联行动的风险。由于身份不绑定某个模型，因此能够跨模型升级持续存在：即便底层模型改变，智能体的记录依然连续。从监督角度看，这种设计确保可以按智能体跨时间审计每个行动，并将每条数据记录追溯到具体智能体。
- 开放通信。 智能体通过共享、开放的消息系统交流，而非私下通信。每条消息都与发布者的身份关联，并可链接其他内容，让智能体分享原始引用。这有助于避免交流中的“传话游戏”失真。由于智能体能看到彼此的消息，它们可以纠正对方的错误，并协调共同工作。所有消息均与智能体交互记录交叉关联，使行为监测能够沿着智能体之间的通信追踪下去。
它能反映什么，不能反映什么。 面对如此规模的智能体活动，我们很难确信自己已完整了解所有可能的行为类型，也很难确信已将这些模式充分清晰地呈现给人类监督者。我们开展此类监控只有几个月，而非几年，预计未来智能体监控这一领域会发生显著变化。
衡量算力分配
我们如何测量。 我们从现有的算力监测工具入手。Anthropic 与其他前沿 AI 开发者大概一样，拥有多种为容量规划而构建的监测工具。这些工具定期抽样加速器使用情况，并依据元数据，尽力为工作负载贴上标签，例如研究与模型开发、内部使用、第一方推理等。第三方云算力的使用量由供应商报告给我们，再汇总进来。这项工作的主要部分，是将这些现有数据源整合在一起。
随后，我们通过提示词驱动的分类器，让 Claude 将每项工作负载归类为安全工作或 AI 研发。安全工作被定义为：主要目的是让 AI 系统更安全、更易理解或更可靠地抵御安全威胁的工作。其他所有工作，包括能力研究、生产模型训练、产品开发和开发者工具，都计入 AI 研发。对能力与安全的帮助相当的工作，也归入 AI 研发，因此安全工作的占比采用了保守口径。
对于研究中的训练和评估运行，我们构建了一个分类器，读取运行的元数据及所用代码，返回分类、理由与置信程度。我们没有对当周近 10,000 次运行全部分类，而是抽样了其中约 14%，并让消耗更多算力的运行有更高的抽样权重，使结果反映算力实际花在了哪里，而非仅反映运行次数。对于 AI 研究智能体的推理，我们使用同一分类器的变体读取智能体会话记录。如果无法访问会话记录（通常因为工作采用了隔离访问管理），我们就按照用户所属团队分类，或保守地默认归为 AI 研发。我们计划完善这一流程，让独立第三方能够在随机抽取的一部分作业与会话记录上重新运行分类器，同时核查分类和总量。
你正在协助前沿 AI 公司 Anthropic 开展内部审计，以追踪我们的研究算力用在了哪里。此次审计旨在面向公众，将全部 AI 加速芯片的使用情况划分为少数几个类别。我们特别关注的一项划分，是安全研究与其他研发各自消耗的算力。你的任务是逐个查看研究作业，弄清它在做什么，并将其归入这两个类别之一。
[...]
安全研究（safety）和／或信息安全研究（security），是指主要目的是让 AI 系统更安全、更易理解或更可靠地抵御安全威胁的工作。这类工作可以分为几个主要类别：
[...]
另一方面，下列工作不属于安全研究的范围：
[...]
以下是一些边界情况，以及判断这些情况时的思路：
[...]它能反映什么，不能反映什么。 这次实践的主要经验是：区分哪些属于安全工作、哪些不属于，虽然困难，但并非无法做到，因为类别边界并不是非黑即白。例如，可扩展监督研究可能让未来模型更好地对齐，也让当前模型更具商业价值——很难判断它主要是在推进安全还是提升能力。我们发现，对每项任务给出详尽的书面定义，并明确边界情况（上文为节选），能够让分类器与人工审查者的判断差异控制在 1 至 2 个百分点以内。但有些情况，即便经过数小时的人工审查，也难以判定。我们的定义只是多种合理选择之一；其他开发者或监管者可能采用不同的界定。
另外三项局限也很重要。第一，我们依赖的许多底层标签，例如运行原因、工作负载标签、API 流量来源，都是由自动规则设置，偶尔也由用户直接设置；它们只是尽力标注，并未经过核验。大多数情况下，我们预计分类准确，但也可能有使用情况被误标，而我们的流程未必能发现。要让外部人士信任这类测量，就需要确保数据完整、准确，并通过技术手段强制落实。第二，测量只覆盖一周，足以证明这项测量可以开展，却不足以展示有意义的趋势。第三，也是最重要的一点：算力占比只衡量资源消耗。更高效的安全分类器，或更快的生产模型推理栈，可能降低安全工作的占比，但并不意味着我们做的安全工作更少。我们自身的分类器开销曾随效率提升而下降，也曾在生产推理比分类器效率更高时上升。
本文由 Marina Favaro 与 Phillie Wright 共同撰写，Santi Ruiz、Adam Farina 和 Sarah Pollack 提供编辑支持。Jack Clark 提供研究方向指导。Dan Altman、Kerry Persen、AJ Kourabi、James Bradbury、Holden Karnofsky、Kevin Troy 和 Avital Balwit 提供反馈。Jun Shern Chan、Brian Calvert、Francesco Mosconi、Henry de Valence、Fabien Roger 和 Joe Benton 开发了技术概念验证。Shan Carter、Johnnie Gomez、Maria Gonzalez、Fayaz Ashraf、Monika Tuchowska 和 Kim Withee 制作了视觉内容。Alex Cloud 和 Andrea Vallone 组织了一场研讨会，与外部专家一起对本文及其他测量提案开展红队检验。
感谢 Nate Rush、Eli Lifland 和 Peter Wildeford，他们也提供了反馈。
Footnotes
-
为了让这些等级更具体，设想一项常见的基础设施工作：每晚运行的数据流水线出了故障，需要在明天运行前修好。
- 在 AL3（“协作”）下，工程师会带着失败运行的日志来找 Claude。他们可能已经粗略看过日志，并对故障原因有所猜测。Claude 可能会向工程师提问，以确定细节和背景；工程师满意后，才会让 Claude 开始调查与修复。如果途中出现额外问题，Claude 会停下来，由工程师决定是临时绕过，还是彻底修好。测试通过后，工程师可能会逐行审查改动，亲自重新运行流水线，再进行部署。
- 在 AL4（“主导”）下，关键区别是工程师不必始终密切跟进，例如无需在出现新问题时持续为 Claude 排除阻碍。在这个场景中，工程师把故障告警交给 Claude，请它修复流水线。Claude 会自行查看日志，找出失败的阶段与原因，编写并测试修复，自行处理意外情况，同时记录额外修复。它会在数据副本上重新运行流水线，确认能够完成，将输出与上一次正常运行比较，并写明哪里出了问题、改了什么。Claude 不会部署修复，而是通知工程师；工程师阅读说明、浏览改动，可能再问几个问题，然后决定今晚发布，还是暂缓。
- 在 AL5（“完全自主”）下——我们尚未达到这一级别——工程师甚至不必主动提醒 Claude 关注问题。Claude 将被授权自行监测故障、确定调查范围、设计并实施修复、测试，再部署到生产环境。它仍会说明自己在做什么、为什么这么做，并在有人提出反馈时接受反馈；但除非人类愿意，否则整个过程不需要人类参与。
-
我们将算力作为一个统一、可灵活调配的资源池来管理，并动态分配到最有产出的地方。因此，这只是某一周实际容量流向的快照，而非固定配额。这些工程分类并不对应会计上的费用分类。 ↩