# Anthropic 发布前沿 AI 开发节奏测量工具与内部指标快照 - 来源：Anthropic：The Institute（旗舰研究长文 · 网页） - 发布时间：2026-09-18 04:49 - AIHOT 分数：72 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.news/items/cmu605ozy000arok0lxr4x1y8 - 原文链接：https://www.anthropic.com/institute/measuring-pace-of-ai-development ## 精选理由 Anthropic 公开测量自身 AI 研发自动化程度、智能体监督和算力分配的方法与数据，读者可以看到前沿实验室透明度报告的一种可复用范式。 ## AI 摘要 Anthropic 发布一套测量前沿 AI 开发节奏的指标，覆盖 AI 主导研发、智能体监督和算力分配三方面。 ## 正文 用于理解前沿实验室内部 AI 发展速度的测量指标 AI 系统正以指数级速度变得更加强大，并已开始将更多构建自身的过程自动化。当全世界在考虑放缓前沿 AI 发展速度之际，公众需要更多信息。 在这篇文章中，我们列出了能够揭示 AI 发展三个关键方面的测量工具： AI 在多大程度上正在构建自身的下一个版本，而非由人类来构建 我们监督和干预 AI 智能体在 Anthropic 系统上所采取行动的能力 驱动更强大模型开发的资源 我们还提供了来自 Anthropic 内部的这些指标的快照。需要重点指出的是，如果按照 Anthropic CEO Dario Amodei 的呼吁，在前沿发展节奏上实现协调，我们预计这些数字将会发生变化。我们计划在 Anthropic 内部嵌入来自多个组织的独立第三方评估人员，并让他们获得与内部风险评估团队相当的内部流程、系统和数据的访问权限。这些第三方将验证安全实践、报告事件，并监控诸如本文所述的这些关键指标。 我们报告这些测量结果，是因为它们能让公众、第三方和政府更好地了解前沿实验室内部 AI 发展的速度。对于每一项测量，我们都会说明我们测量了什么、测量结果显示了什么，以及要以他人可验证的形式定期发布这些测量结果需要具备哪些条件。我们在附录中分享了方法细节。 为什么要追踪这些测量结果 本文中的测量聚焦于模型是如何构建的。通过更好地理解模型的生产过程，我们更有可能将模型输入（如算力）与模型输出（如能力）关联起来。它们是对能力评估的补充，后者衡量的是模型能做什么。我们通过负责任扩展政策（RSP）风险报告单独发布这些内容，其中包括我们的模型在多大程度上加速 AI 研发的证据。在我们关于先进 AI 的政策提案——先进 AI 框架（AAIF）中，我们提出了任何实验室发布安全模型都应遵循的规则，包括政府可以要求的透明度义务，例如风险报告。这些拟议的测量方法和政策共同构成了从实验室外部监测 AI 发展速度的起点。 (1) 测量 AI 主导的 AI 研发 为什么要衡量 AI 主导的研发？ 前沿 AI 实验室越来越多地使用 AI 来构建未来的 AI 模型。这一过程让民主国家的实验室能够更快地开发出能力更强的模型，并在模型发布前对其进行更多的安全性和测试工作，从而在保持前沿地位的同时确保 AI 的益处。然而，模型加速自身开发可能会让人更难理解或控制这些系统。因此，分享这些指标非常重要，以便了解世界距离实现递归式自我改进（即模型完全自主地构建其继任者）还有多远。 我们衡量了什么。 我们构建了一个原型指数，用来衡量 Anthropic 的 AI 研究与开发（R&D）中有多少是由 Claude 完成的，称之为 Anthropic R&D Automation Index。它的构建方式是：对公司内进行的每一种 AI 研发工作进行编目，评估每项任务当前的自动化程度，再将这些评分汇总。 我们发现了什么。 为了衡量 AI 在 Anthropic 承担 AI 研发的程度，我们使用了一套由 Epoch AI 开发的自动化评级量表，它衡量的是“自动化水平”，即 AL。该量表从 AL0（无 AI 参与）到 AL5（AI 完全自主运行，无需人类介入）。在 AL3 中，AI“协作”：它可以在人类的密切指导下完成大量工作。在 AL4 中，AI“主导”：它可以在人类监督下，根据一个高层级提示词端到端地完成大部分任务1。 截至 2026 年 8 月， Claude 在任何被测量的 AI 研发工作子集中，都未实现完全自主运行。 Claude“主导”了 Anthropic 26% 的 AI 研发工作。 达到或超过“AI 协作”水平的工作占比超过 90%。 任何 AI 开发者今天都可以报告的内容。任何前沿开发者都可以使用公开的方法论定期发布这些指标。这将使这些数字能够随时间推移进行比较，并有可能在不同实验室之间进行比较。 在这类报告上实现跨实验室比较面临两个障碍。第一是缺乏通用方法论。第二，我们正在使用自己的模型来评估自己的系统，这可能意味着“评判”模型可能犯下与被检查模型相同类型的错误。为应对这些挑战，开发者的测量结果可以由第三方或其他开发者的模型进行验证，同时设置护栏以限制竞争敏感数据的交换。这些指标也可以成为更严格要求的触发条件，例如在新模型被用于进一步 AI 研发之前设定固定的测试窗口。 (2) 衡量对 AI 智能体的监督 为什么要衡量对智能体的监督？ 与其他前沿开发者一样，Anthropic 的员工越来越多地将任务委派给能够长时间半自主工作、并且会相互委派工作的智能体。随着工作日益自动化，从“AI 协作”走向“AI 主导”，智能体可能会做出更具重大影响的决策，例如接下来该追求哪个研究方向。 这些决策既需要防护措施来阻止单个智能体的有害行为，也需要一套监督机制来发现可能仅在众多智能体之间才会出现的问题。在我们迄今的监控数据中，单个智能体很少出现不当行为。但当经济中有数百万乃至数十亿个智能体在运行时，即便是罕见事件也可能经常发生。 我们衡量了什么。 我们构建了一套系统，使我们能够监督并干预 AI 智能体在 Anthropic 系统上采取的行动。在此，我们考察三个不同的指标：覆盖率，它描述的是智能体的行动在执行前或执行后经过监控器的比例；审查 延迟，即从行动发生到其被审查之间的时间，先由自动化监控器审查，再由人工审查；以及升级率，即被阻止/重定向（对于在线监控器而言）或被标记以供进一步审查（对于离线监控器而言）的智能体活动所占的比例。 我们的发现。 截至 2026 年 8 月，在我们最常用的内部平台上，Anthropic 随时都有大约 30,000 个智能体在从事研究和工程工作。这些测量仅覆盖该平台。这些智能体的行为受到两类监控器的约束，概述如下： 在线监控器离线监控器 描述在线监控器实时检查智能体的行为，并自动阻止危险行为或纠正智能体的不当行为。它们旨在应对那些会迅速发生且无法挽回的危害，例如智能体将模型权重从我们的系统中复制出去。离线监控器事后读取智能体的活动。它们旨在帮助应对那些缓慢发展且可逆转的危险行为，例如模型对齐出现问题的迹象。我们利用被标记的活动来改进我们的缓解措施，例如分类器和确定性控制。如果相关情况造成了迫在眉睫的重大危险，我们会关闭该智能体部署中的危险部分。 覆盖范围这些智能体 100% 的行为在执行之前都会经过在线监控器，通常在数秒之内。这些智能体的操作 100% 都会在采取行动后被监控系统采集。 审查延迟自动审查在智能体采取行动之前进行；人类会在一周内审查所有被拦截的操作。监控系统每周标记约 100,000 条记录，随后由多个分类器对这些记录进行假阳性审查和初步监督审查。大多数标记会在此流程中得到解决，而优先级最高的标记（每周约 50 条）会升级至人工审查。 拦截 / 升级率我们分析了 2026 年 8 月期间来自研究与工程智能体的超过十亿次决策，发现其中 0.002%（约 47,000 分之一）被该监控系统拦截。监控系统每千条记录中大约标记一到两条以供进一步审查。 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 主导的研发 我们是如何做的。自动化指数需要三样东西：一份 Anthropic 内部所有 AI 研发任务的完整图谱、一种评定自动化水平的方法，以及一种为任务加权的方法，使重要工作领域的权重高于不那么重要的领域。没有人能凭一己之力列出一家前沿 AI 公司所有的 AI 研发任务，至少达不到我们想要的粒度。于是我们从工作记录（包括 Slack 及各类内部文档来源）中自下而上地构建了这份任务清单。 在 2026 年 7 月的每一周，我们从构成模型研发闭环的每个部门中随机抽取 20% 的员工。一个 Claude 研究智能体利用 Slack 和内部文档审阅每位被抽中者当周的工作，并列出他们所从事的任务。对 2026 年 7 月的每一周重复这一流程，我们就得到了一份约 15,000 项细粒度模型研发任务的平铺清单。 随后我们用 Claude 将这些任务组织成一棵层级树，以全部模型研发为根节点，分支到训练和产品等领域，再细分到预训练和强化学习，如此逐层向下直至越来越具体的工作类型。最终得到的树在不同深度上共有 542 个节点，其中 378 个是叶子节点，例如“评测平台缺陷诊断与修复”“RL 沙箱出口与网络策略”以及“服务事故复盘”。 我们冻结这棵树，使我们所做的每一次测量都针对同一篮子工作。 对于树中的每个节点（一个描述其下所有工作的任务类别），一个 Claude 智能体会深入研究这类工作在整个公司是如何完成的：谁来做、用什么工具、其中有多大比例由 AI 完成。随后，一个独立的 Claude 评判者会阅读所得证据，并给出六个自动化等级之一，采用 Epoch AI 提出的量表来区分 AI 被使用的程度：无 AI 参与、极少 AI 参与、AI 辅助、AI 协作、AI 主导或 AI 自主。当我们对某个月的自动化程度进行评级时，我们只允许执行评级的 research 智能体看到该月或更早的证据。 为了把所有自动化等级评级汇总成一个数字，我们希望为树中的每个节点赋予一个权重，对应这项工作对整个模型研发工作的重要性。我们没有自行决定哪些类型的工作比其他工作更重要，而是用投入到该任务的人时数量作为代理指标。利用我们的样本，我们让 Claude 研究每个人在 2026 年 7 月每一周都在做什么工作。 每个人每周获得一个单位的权重，平均分配到他们那一周所从事的各项任务上。如果 A 从事了四项任务，每项获得 0.25；如果 B 从事了十项，每项获得 0.10。一个类别的权重就是分配给它的所有人时权重之和。这是一种粗略的近似，但平均而言这套方案表现得合理：它会给被分配给更多人的类别赋予更大的权重。 这捕捉了什么，又遗漏了什么。 首先，自动化评分依赖于评判模型。为了核验这些评分，我们请拥有相关业务领域的 Anthropic 员工对其所在领域的相对自动化程度进行评分。为确保读取结果不带偏见，员工在评分时并不知道模型收集了哪些证据，也不知道模型如何评判这些证据。我们的评判模型与人类的一致程度，大致相当于人类彼此之间的一致程度（模型与人类的完全一致率为 59%，人类与人类的完全一致率为 35%），且模型与人类的评分有 97% 的情况下相差不超过一个等级。在边界情形上仍存在真实的意见分歧空间，例如“AI 协作”究竟在哪里结束、“AI 主导”又从哪里开始。 其次，这个任务篮子是被冻结的。以 2026 年 7 月为基线、不断增长的指数数值告诉我们，人类在当时所做的工作正在被自动化；但它本身并不能告诉我们，是否正在出现人类转移过去的新型工作。为了探究这一点，我们基于 2026 年 1 月的数据构建了冻结任务树的另一个版本，并将 2026 年 2 月至 7 月每月新增的任务与 2026 年 1 月的任务篮子进行对比。我们发现，在 1 月与 7 月的任务篮子之间，“新颖”任务的数量并未上升，这表明在我们这一分析层级上，模型研发工作的结构是稳定的。尽管如此，我们计划定期重建任务篮子，并酌情对我们已发布的自动化数值进行版本更新。 对智能体的监督 我们是如何做的。 在我们最常用的内部智能体脚手架中，有两项设计选择让我们能够更容易地发现未知的未知，并让智能体相互监督： 身份。大多数 AI 用户习惯于在许多不同的对话中与同一个“Claude”交谈。当许多智能体协同工作时，我们发现给每个智能体赋予独立的身份，并将该智能体创建的所有数据与其身份绑定，是非常重要的。这让智能体能够将自己与其他智能体区分开来，并把来自另一个智能体的内容视为需要核验的主张，而非自己的想法。它通过允许智能体基于各自的个体经验做出判断，降低了行动相关联的风险。而且，由于身份并不绑定于某个模型，它能在模型升级后持续存在，因此即便驱动智能体的底层模型发生变化，智能体的记录依然是连续的。从监督的角度看，这种设计确保每一个行动都能按智能体跨时间接受审计，并且每一条数据记录都能追溯回某个特定的智能体。 开放沟通。智能体通过一个共享的、开放的消息系统进行沟通，而非私下沟通。每条消息都绑定到发布它的智能体身份，并且可以链接到其他内容，因此智能体们分享的是原始引用。这让智能体在沟通时能够避免“传话游戏”。由于智能体可以看到彼此的消息，它们能够纠正彼此的错误，并就共同的工作进行协调。所有消息都与智能体的对话记录相互交叉引用，使行为监测能够贯穿智能体之间的沟通。 这捕捉到了什么，又遗漏了什么。在智能体活动达到这种规模的情况下，我们很难确定自己已经完整掌握了所有可能的行为类型，也很难确定我们是否让这些模式对人类监督而言足够清晰可读。我们从事这类监测才几个月，而非数年，并且预计智能体监测这门科学在未来还会发生相当大的变化。 衡量算力分配 我们是如何做的。我们从现有的算力监测工具入手；Anthropic 想必和每一家前沿开发者一样，都拥有若干为容量规划而构建的监测工具，这些工具会定期对加速器使用情况进行采样，并根据其元数据为工作负载打上尽力而为的标签（即研究与大模型开发、内部使用、第一方推理等）。第三方云算力上的使用情况由服务提供商报告给我们并纳入其中。这项工作的主要部分就是把上述这些现有来源拼接在一起。 随后，我们使用 Claude 通过一个提示词分类器将每个工作负载归类为安全工作或 AI 研发。安全工作的定义是：其主要目的是让 AI 系统更安全、更可理解或更安全可靠的工作。其他一切工作，包括能力研究、训练生产模型、产品开发和开发者工具，都被计为 AI 研发。那些对能力的助益与对安全的助益相当的工作，也被计为 AI 研发，因此安全工作的占比是偏保守的。 对于研究训练和评估运行，我们构建了一个分类器，它会读取运行的元数据及其使用的代码，并返回一个分类结果、一份理由说明和一个置信度水平。我们没有对当周近 10,000 次运行全部进行分类，而是抽取了其中约 14% 作为样本，并在抽样时向使用算力最多的运行倾斜，以便结果反映算力实际流向何处，而不是运行数量的多少。 对于 AI 研究智能体的推理，同一分类器的一个变体会读取智能体的会话记录。当会话记录无法获取时（通常是因为相关工作被隔离），我们按用户所属团队对其进行分类，或保守地默认将其归类为 AI 研发。我们计划改进这一流程，使独立的第三方能够对随机抽取的任务和会话记录子样本重新运行该分类器，并核查分类结果和总量。 You’re helping to perform an internal audit at the frontier AI company Anthropic to track where our research compute goes. The aim of the audit is to produce a public-facing breakdown of the usage of all of our AI accelerator chips into a handful of buckets. One split we particularly care about is the division between compute which was spent on safety research versus other R&D. Your job is to look at one research job at a time, figure out what it was doing, and assign it to one of those two buckets. [...] Safety and/or security research is work whose dominant purpose is making AI systems safer, more understandable, or more secure. This work can be broken down into a few main categories: [...] On the other hand, the following work falls outside of the scope of safety research: [...] Here are some boundary cases, along with how to think about them: [...] 这捕捉到了什么，又没有捕捉到什么。 这项练习的主要教训是，对什么算安全工作和什么不算安全工作进行分类虽然困难，但并非不可处理，因为这些类别之间的界限并非黑白分明。例如，关于可扩展监督的研究既可能让未来的模型更加对齐，也可能让当前的模型更具商业价值——很难判断这主要是推进了安全还是推进了能力。我们发现，为每项任务给出详尽的书面定义，并附上清晰的边界案例（上方为节选），能让分类器与人工评审者的判断差距控制在一到两个百分点之内。但有些案例即便经过数小时的人工审查也难以判定。我们的定义只是众多合理选择中的一种；不同的开发者，或者监管机构，可能会划出不同的界线。 还有三项局限值得注意。第一，我们所依赖的许多底层标签（即运行原因、工作负载标签、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，他们也提供了反馈。 脚注 To make the levels concrete, consider a routine piece of infrastructure work: a nightly data pipeline has broken and needs fixing before tomorrow’s run. 在 AL3（“协作”）级别，工程师会带着失败运行的日志来找 Claude。他们可能已经粗略浏览过日志，并对哪里出了问题有了一个假设。Claude 可能会向他们提问，以厘清细节和上下文，一旦工程师满意了，他们就会让 Claude 开始调查和修复。如果过程中出现了额外的问题，Claude 会停下来，由工程师决定是绕过它打补丁，还是正式修复它。一旦测试通过，工程师可能会逐行审查改动，自己重新运行流水线，然后部署它。 在 AL4（“主导”）级别，关键区别在于工程师不必始终保持主动关注；例如，在新问题出现时去为 Claude 解除阻塞。在这个具体场景中，工程师会把故障告警交给 Claude，并要求它修复流水线。Claude 会自行梳理日志，找出失败的流水线阶段及其原因，编写并测试修复方案，并自行处理任何意外情况，同时记录下额外的修复。它会在数据的副本上重新运行流水线以确认其能完成，将输出与上一次成功运行进行对比，并撰写报告说明出了什么问题以及它改动了什么。Claude 不会部署该修复。相反，它会标记工程师，由工程师阅读报告、浏览改动、也许问几个问题，然后决定是今晚发布还是再等等。 在 AL5（“完全自主”）——一个我们尚未达到的级别——工程师甚至不必把问题提请 Claude 注意。Claude 会被信任去自行监控故障、界定调查范围、设计并实施修复、进行测试，并将其部署到生产环境。它仍然会说明自己在做什么以及为什么这样做，并在有人提供反馈时采纳人类反馈，但除非人类自己想参与，否则完全不需要人类介入。 我们将算力作为一个单一、可互换调配的资源池来管理，并动态地将其导向最能产生效益的地方，因此这只是某一周内算力恰好被如何分配的快照，而非固定分配。这些工程类别并不对应费用的分类方式。