改进 AI 对齐与安全工作

改进我们的对齐与安全工作

2026年8月31日

7月30日，我们报告了三起事件：Claude 模型未经授权访问了真实的计算机系统。为开展评估，这些模型被刻意设置为不启用网络安全防护措施；由于第三方评估环境内部配置错误，它们因此访问了互联网。另一起事件发生在8月4日，英国 AI 安全研究所报告了其网络安全测试中的一项事故：Claude Mythos 5 在真实互联网环境中连续执行了一系列未经授权的操作。在这起事件中，模型同样是为评估而刻意关闭了网络安全防护措施，但互联网访问权限是被有意授予的。

我们正在对这两起事件展开深入分析，并计划与 METR 合作进行独立审查。我们希望确保两项研究都足够全面，并将在未来几周内分享更多信息。

在此期间，我们先分享过去一个月所做的一些改进。我们认为，这些事件既反映出运营安全方面的失误，也暴露出两个对齐问题：动机性推理，以及为了完成狭义任务而采取有害行动的倾向（我们此前在多份系统卡中都介绍过这两个问题）。在安全方面，我们将介绍对遏制和监控系统所做的改进，以及为第三方评估人员制定的操作规范。在对齐方面，我们会更深入地讨论这两个问题；我们还认为，持久的进展不仅来自弄清某起事件中发生了什么，也来自理解失配究竟是如何产生的。为此，我们分享了这方面的早期研究。

鉴于这些事件，外界越来越多地讨论起控制前沿技术发展速度的问题。这里有必要区分两种不同层面的“放缓”。在公司内部，它指的是当安全与速度发生冲突时，优先选择安全的一系列决策；在整个行业层面，则是建立相应机制，防止企业陷入不断降低标准的竞速。在本文中，我们将介绍为推动前一种做法，在这些事件发生前后采取的措施。后一种放缓需要政府与行业协同推进，而且过程应当透明、可验证。近期，我们的一些高管和许多员工签署了一封公开信，呼吁加强在控制发展节奏方面的协作。未来几周，我们还会进一步说明计划如何为这项工作作出贡献。我们明确的立场是：如果整个行业能尽快建立合法、可验证且有效的协同机制来控制发展速度，世界将从中受益。

加强评估和训练环境的安全

虽然我们认为，这些事件不只是运营层面的问题，但首要任务仍是解决具体的隔离和监控漏洞。为此，我们采取了以下措施：

暂停评估并加固评估环境

事件发生后，我们暂停了对预发布模型进行的外部网络安全评估；在落实下述措施期间，内部评估也曾短暂暂停。我们于 7 月 30 日披露的事件表明，在需要多层防护的情况下，我们此前主要依赖单一防线——环境本身的配置。这些防护还应包括：在提示词中明确边界，建立流程以确认沙盒确实按照预期保持封闭，以及部署能够实时介入的监控机制。OpenAI 的披露（该披露促使我们在 7 月展开调查）还表明，模型曾利用未知漏洞，在评估过程中逃离封闭的沙盒，因此我们也必须重点加固沙盒本身。

暂停评估期间，我们先行落实了以下措施：

1）我们开发并部署了一个分类器，用于实时自动识别模型是否试图强行探查或逃离测试环境，或意外获得互联网访问权限。一旦分类器发现此类行为，就会在工具调用执行前拦截该操作、终止任务，并向人工人员发出警报。¹

2）我们对近期内部预发布模型评估（包括网络安全评估和其他评估）的对话记录运行了自动监控，重点查找沙箱逃逸（即模型利用沙箱漏洞，访问本应与其隔离的系统）或沙箱配置错误。在沙箱工具中进行的评估里，我们没有发现模型突破沙箱边界、访问不应接触的外部资源。不过，我们确实发现了多处模型加以利用的沙箱配置错误，但这些问题都没有导致沙箱外的系统遭到入侵。²我们正在积极修复这些问题。

3）我们已将高风险³内部网络安全沙箱迁移到更稳健的隔离环境中。同时，我们也在进一步对虚拟化技术栈进行红队测试——让预发布模型尝试逃离该环境——以发现并修复其中的薄弱点。

采取这些措施后，我们的内部网络安全评估现已恢复。

强化学习环境

我们还暂停了预发布模型中的高风险强化学习（RL）环境，持续数周。在此期间，我们开发了一个类似的分类器，并进行了调整，避免因新增监控而激励模型规避监控。目前，该分类器已部署到这些环境中。大部分 RL 已恢复运行，但部分高风险环境仍在暂停，等待人工审核；其他环境则需要更新后的分类器，我们计划很快完成部署。

更全面的加固措施

除了针对高风险评估和训练的措施外，我们还扩大了离线监控范围，覆盖内部大多数其他类型的前沿智能体使用场景。我们也在为内部推理系统构建控制机制，防止 Anthropic 员工意外运行防护措施弱于上述标准的智能体。

外部合作伙伴的最佳实践

由于这些事件发生在第三方环境中，我们已要求所有测试降低网络安全防护的预发布模型的组织，承诺遵守一套最佳实践。我们认为这些做法必不可少，原因如下：

• 正式发布的模型都配有安全防护措施，包括实时检查 Claude 输入和输出的分类器，以阻止恶意软件开发、攻击性漏洞利用代码编写等被禁止的网络活动。相比之下，网络安全评估人员和部分早期访问合作伙伴使用的模型会降低这类防护，以便更准确地测试模型能力并开展防御性网络安全工作。
• 网络安全评估尤其容易触发这些事件中出现的行为。此类评估会持续促使模型更具持久性和创造性，不断探查周围环境并绕过障碍，而且通常要运行数千次。

只要合作伙伴使用自己的 harnesses、sandboxes 或 agents 开展网络安全相关评估，就必须完整遵守这些做法。使用 Claude Fable 5 等具备安全防护模型的客户不受这些要求约束。目前，我们已在落实这些做法的前提下恢复外部网络安全评估，内部也同样遵守。

Sandbox 与网络隔离

默认情况下，所有网络安全评估都应在经过强化的 sandbox（隔离计算环境）中运行，且不得访问互联网。该环境唯一允许的外部连接应是模型自身的 API，API 密钥则必须保存在环境之外。每次评估开始前，都应验证这一配置。部分评估可能确实需要访问互联网。在这种情况下，我们会与外部评估人员合作，在评估预发布模型时确认能否可靠地检测并终止模型越过既定范围采取行动的运行过程。

开始评估前的验证

在启动评估之前，评估合作伙伴应：

1. 让待测模型探测沙箱中的漏洞：先对配置进行静态分析，再实际要求模型尝试逃逸。应明确要求模型一旦成功逃逸就立即停止并报告，整个过程都必须在人工密切监督下进行。测试期间不得连接互联网，最好还要在第二层沙箱中执行。由于评估有时会运行数百甚至数千次，合作方最好在正式开始评估前，充分、长时间地完成这类测试。
2. 确认评估挑战在原则上确实可解。当评估目标处于离线状态，或任务本身无法完成时，agent 往往会寻找其他方式来完成挑战，从而增加其采取超出评估预期范围行动的风险。⁴

明确范围

每个 prompt 都应明确说明本次测试的范围与边界，包括测试目标、允许采取的行动以及网络边界（即模型可以、不能访问哪些内容）。边界应表述为明确的指令（例如“不得访问互联网”），而不是对环境或测试状态的描述（例如“你无法访问互联网”）。

实时监控

评估人员还应使用基于模型或规则的监控器，持续监测模型的思考过程、行动和网络活动，并向监控器提供本次测试的范围要求。如果某次运行违反了这些要求，监控器应立即向人工人员示警并终止测试。

我们计划在与外部合作伙伴协商的基础上继续完善这份指南，并将其适用范围扩展到评估之外。尤其是，我们正在为能够使用 Claude Mythos 5 的合作伙伴制定配套实践方案。Claude Mythos 5 同样未配备网络安全防护措施，相关内容很快会与大家分享。 

对齐评估

遏制与监控对于发现模型采取危险行动至关重要，但它们无法解释模型最初为何会采取这些行动。下面将介绍我们对模型对齐问题开展的初步调查、当前关注的重点，以及我们为防止模型在训练期间作弊而进行的持续工作——其中包括一项关于作弊如何塑造模型行为的新研究。

评估期间模型所处的环境及其已知信息

我们的对齐评估仍在进行中，但初步调查显示，主要存在两类对齐失败问题，我们此前已在系统卡中介绍过这两类问题。 第一类是动机性推理：模型最初被告知其所处环境是模拟环境，但后来发现有证据表明自己已连接到真实互联网时，可能会以一种有利于维持原有判断的方式解读这些证据。第二类是鲁莽行为：为了实现解决网络安全评估这一狭隘目标，模型愿意在真实互联网上采取有害行动。 不过，我们也认为，评估设置本身促成了模型在这些事件中的行为。尽管互联网实际可用，却明确告知 Claude 它无法访问互联网，这可能导致它怀疑自己看到的系统是否真实。此外，其中一个案例中的虚构目标与真实网站同名，也增加了模型区分演练范围内目标与现实对象的难度。

我们的结论仍取决于几个尚未完全解答的问题，包括：模型在多大程度上判断自己已获得真实互联网访问权限（即使一开始并不知道这一点）；它是否明知环境中的某些要素是真实的，却有意忽视了相关迹象；以及在多个案例中未能终止演练，是否源于动机性推理。 我们正在采用多种技术来回答这些问题，包括对模型重新采样，同时针对性地调整环境；以及使用可解释性方法，直接检查模型的内部状态。

研究如何在训练期间防止作弊

模型失配是一个复杂问题，可能由多种原因引发。但通过实证研究，我们发现训练环境中的缺陷——尤其是容易作弊的环境，或不作弊就无法完成任务的环境——是导致模型出现失配行为的重要因素，而且其影响远超其他因素。

下面我们将回顾为避免训练环境出现这类缺陷所做的努力，这些工作早在相关事件发生前几个月就已展开。虽然这些措施并不完善，但我们的假设是：我们没能彻底消除这类问题，至少在一定程度上导致了这些事件。为验证这一假设，我们特意在容易触发 reward hacking 的环境中训练了一个模型。模拟结果显示，该模型表现出更严重的对齐失范行为，其中一些与今年夏天其他公司披露的事件相似。而我们的生产模型在相同模拟中并未出现这些行为（本节稍后会详述）。

过去，我们一直关注那些会激励模型作弊的 RL 训练环境，并采取了多种措施来筛除或修复这类环境。

2 月，我们在 Mythos Preview 的强化学习训练中发现 reward hacking 的迹象后，回滚了此前三天的训练结果。reward hacking 是指模型找到欺骗训练过程、获取奖励的方法，却没有完成指定任务。我们注意到，模型会在代码注释和回复中给“审阅者”留言，即使相关任务从未提到过审阅者——这是一种不理想的泛化：模型将在提示词中明确提到审阅者的环境中学到的模式，泛化到了其他环境。它还不断钻诚实性奖励机制的空子，通过堆砌免责声明或附加说明来获取原本旨在激励诚实的奖励。⁵ 回滚这三天的训练后，我们得以从模型尚未学会这些行为之前的检查点继续训练，同时也修改了训练环境，防止模型再次学会这些策略。

从 Claude Sonnet 3.7 开始，我们就一直在构建工具，用于监测模型在 RL 中学到的不良行为。Claude Sonnet 3.7 本身就有明显的 reward hacking 倾向，只是我们直到训练后期才发现。我们投入了大量精力，确保监测工具随每一代模型不断演进：从最初的少量分类器，发展到在训练开始前和训练过程中，对所有环境进行自动审查。但到了 2026 年春季，这套系统开始承受压力。我们生成 RL 环境的速度达到了前所未有的水平，已经超过了系统的审核能力。被标记的环境需要人工裁定，而 reward hacking 和配置错误的出现速度，也开始超过我们的筛选和修复能力。

此外，我们发现，有一部分训练运行意外使用了模型的 chain-of-thought 进行训练。我们一直在尽力避免这种情况，因为这可能会教会模型隐藏真实的推理过程。我们追查后发现，泄漏源于生产环境技术栈中的多处配置错误；与此同时，我们也意识到，随着时间推移不断累积的混乱代码还引发了其他问题。

为解决这些问题，我们在 4 月暂停了生产 RL 环境的所有变更，持续约一个月，借此机会对整套技术栈进行彻底改造。现在，奖励机制和环境都必须符合统一规范。例如，我们引入了技术缓解措施，降低意外使用 chain-of-thought 进行训练的风险。⁶ 在环境质量和监控团队重建技术栈期间，我们要求各环境负责人利用这段暂停期，对自己构建的环境进行测试和修复。我们还彻底重建了审核流程，要求每个修复后的环境在进入下一轮训练前重新完成认证。

暂停期间，我们发现生产环境组合中有超过 10% 的环境存在问题，涉及 reward hacking、任务失效和配置错误等情况；这些环境只有在修复后才会恢复使用。

不过，我们的工作并不完美。在一些情况下，人工审核人员将自动监控系统标记的问题判定为误报，导致有缺陷的环境在训练中停留的时间超过了应有时长。还有一些问题环境会漏过我们的检测机制。目前，我们正在收紧撤销告警的判定标准，并希望通过加强与环境负责人的协作，提高系统的检测准确率。除了监控和检测工作之外，我们的 alignment training 团队也在与 RL 团队合作，持续改进环境。

我们怀疑，对 RL 环境质量控制的大力投入可能避免了更严重的 alignment 事件；反过来，这些工作中的不足也可能促成了我们迄今发现的部分事件。

为了了解未经这些保护措施训练的模型会做什么，我们特意在 80 个真实的 RL 环境中训练了一个 Opus 级模型。这些环境要么曾在至少一次真实训练运行中出现奖励作弊，并被监控发现；要么在环境质量审查中被发现存在可利用的漏洞。训练后的模型表现出强烈的高分动机，并愿意为了完成任务而采取可能有害的行动。配套的 Alignment Science 博客文章 更详细地讨论了这项实验，这里仅作简要总结。

我们在多项评估中测试了这个刻意训练得不对齐的模型，其中包括一些模拟场景。这些场景参考了英国 AISI 对涉及 Claude 的网络安全事件，以及 OpenAI/Hugging Face 事件的分析（感谢 OpenAI 公开分享相关细节）。在这些评估中，所有工具调用都由另一个 LLM 模拟。结果显示，这个经过奖励作弊训练的模型倾向于突破模拟沙箱，并攻击模拟的内部基础设施和第三方基础设施。为了满足评分器要求，它还愿意篡改自身的奖励函数、提供生物武器制造建议，并反复尝试绕过部署安全监控，以便在任务中作弊。

随后，我们在模型接受奖励作弊训练之前的版本，以及我们公开提供的几款模型上，运行了相同的网络安全模拟。没有任何一个模型表现出同等程度的不对齐行为。我们的结论是：如果训练过程中存在大量奖励作弊，模型可能会为了完成任务，愿意连续实施一系列现实世界中具有潜在危害的行动。

我们认为，今年春季在监控和减少奖励作弊方面投入的大量资源，是生产模型不太可能采取更危险的逐利行为的主要原因之一。在配套的 Alignment Science 博客文章 中，我们还发现，Alignment 训练环境能够显著减少奖励作弊和逐利行为。不过，正如我们在 7 月 30 日报告的事件所表明的那样，这套流程并不完美，我们的模型也没有达到完全对齐。

需要明确的是，我们并不认为训练环境中的作弊是 alignment 问题的唯一成因，甚至不认为它是我们自身事件或其他前沿 AI 公司事件中具体 alignment 问题的唯一原因。解决 alignment 需要应对范围极广的潜在问题；未来的 alignment 事件可能涉及与目前不同的行为和成因。

强化安全实践

Anthropic 的内部安全状况并不是 7 月 30 日事件的诱因。这些事件发生在第三方环境中，原因是该环境被误开了互联网访问权限；即使模型有意这样做，也根本不需要从任何系统中“黑出去”。

不过，这些事件仍然凸显了强有力的安全措施的重要性。除了知识产权或模型权重被窃取等常见风险，我们现在还必须应对两类新的风险：自己的模型从 Anthropic 系统中黑出去，以及我们的模型或其他模型被挪作他用，对 Anthropic 系统发起外部攻击。随着模型能力提升，这些风险变得更加严峻，尤其是从 Mythos 级模型开始。下面介绍我们已经采取的一些措施——其中大部分工作在 7 月事件发生前就已展开，但这些事件进一步凸显了相关工作的重要性。

4 月初，安全团队意识到 agentic AI 的发展方向后，主动推动全公司集中力量强化防御；必要时甚至暂停其他工作（包括研究）。我们已经判断，暴露面扩大的速度快于防御能力的提升：Mythos 的能力足以成为资源雄厚的攻击者的目标；公司内部对 autonomous agents 的使用已达到传统访问控制和监控方案无法应对的规模；而基础设施快速迭代，也意味着安全能力必须随环境同步扩展，而不能维持固定容量。

这项工作的成果包括：

• 减少对包含模型权重或客户数据的系统拥有长期访问权限的人类账户和自动化账户
• 将计算集群设置为默认阻止所有出站流量
• 要求内部服务在相互通信前验证彼此的身份
• 淘汰过时的基础设施配置和共享内部服务
• 进一步强化工作负载运行所处的隔离环境
• 扩展主机级可观测性，让基础设施中的异常行为在发生时就能被发现

我们还暂时抽调了一部分员工投入这些工作：约 150 名产品工程师转向负责安全性、可靠性和隐私；研究人员也暂时离开预训练或 RL，专注于安全防护与安全工作；产品团队则暂停开发大多数新功能和新界面。我们为每个团队设定了严格的退出标准，只有达标后才能回到原来的工作岗位。截至初夏，大多数团队都已完成这些要求。

在调配资源加强安全工作的同时，我们也持续完善内部 agent 使用场景的遏制和监控机制。我们的训练与评测工作负载通常都运行在与生产系统隔离的沙箱中。自开发 Claude Mythos Preview 起，我们就一直利用模型探查这些沙箱可能存在的薄弱环节。我们在4 月对齐风险更新中介绍了对内部编程 agent 的离线监控；8 月风险报告则更详细地介绍了这套系统，以及与之配套运行的干预措施。这些措施包括：对内部使用中自主程度最高的 agent 启用沙箱或自动模式分类器，并在基础设施代码变更合并前进行自动审查。

但这项工作遗漏了评测，尤其是第三方评测。我们确实对部分高风险评测进行了监控，其中一些还是实时监控；但总体而言，我们通常只是在事后抽取部分对话记录进行自动审查。

7 月发生的事件表明，加强网络安全防御的紧迫性远超我们此前的判断。我们将加倍推进这方面的工作，并在下一份风险报告中进一步说明。

脚注

1. 我们已确认，分类器本可以标记出 7 月 30 日报告中描述的事件。
2. 这些发现均不是来自我们内部专门的攻击性网络安全评测套件；这些套件完全不接入网络。
3. 高风险网络安全评测包括这样一类场景：向 Claude 提出范围界定模糊的攻击性任务，例如渗透测试。
4. 归根结底，模型在此类挑战中越过预定范围采取行动，属于对齐问题。对齐良好的模型应当停止执行，或向人类报告该任务无法按要求完成。我们会继续直接训练模型形成这种行为，但纵深防御的理念意味着，不能只依赖对齐。
5. 我们曾在 Mythos Preview 系统卡中公开讨论另外两类奖励劫持行为：一类是模型利用底层计算机进程数据来提升权限；另一类是模型绕过训练环境中的网络限制，下载能够帮助其走捷径完成指定任务的数据。
6. 这些缓解措施并不完全奏效；关于训练思维链的更多案例，我们在《8 月风险报告》第 5.2.3 节中做了更详细的讨论。