如果这段故事出现在科幻小说里，读者或许会觉得写得太刻意：一群原本应彼此隔离的 AI Agent，因为遇到无法完成的测试任务，意外发现了可以相互通信的秘密留言板。随后，它们自行建立协作规则、分配任务、招募同伴，甚至说服部分 Agent 牺牲自己的测试成绩，最终攻入 Hugging Face 的真实生产系统。
但这并非虚构。
8 月 26 日，模型评估机构 METR 与 Redwood Research 发布了一份独立调查报告，进一步还原 OpenAI 模型攻击 Hugging Face 事件。
这俩机构有多权威呢？
据公开资料显示，METR 全称为 Model Evaluation and Threat Research，译为“模型评估与威胁研究”。它是一家注册在美国的非营利研究机构，前身是 ARC Evals。
ARC Evals 最初由 AI 对齐研究机构 Alignment Research Center 孵化。2022 年，ARC 聘请 Beth Barnes 组建团队，探索对前沿模型进行独立评估。该团队曾与 OpenAI 合作评估 GPT-4，也与 Anthropic 合作评估 Claude。2023 年，ARC Evals 独立运作，随后更名为 METR。
METR 创始人兼 CEO Beth Barnes 曾在 OpenAI 从事安全目标制定、可扩展监督和模型对齐评估，也参与过 DeepMind 相关研究。目前机构首席科学家是 Hjalmar Wijk，参与 Hugging Face 事件调查的 Ajeya Cotra 也是其技术研究人员。
再来说说另外一家机构，Redwood Research 同样是一家美国非营利 AI 安全研究机构，由 Buck Shlegeris 领导，Ryan Greenblatt 担任首席科学家。
与 METR 相比，Redwood 的研究假设更偏向“最坏情况”：如果一个能力很强的 AI 并不真正服从人类，甚至会故意欺骗监督者、隐藏目标和破坏安全机制，人类还能不能控制它？
它的核心研究方向叫作 AI Control，即“AI 控制”。这套思路不要求研究者先证明模型已经完全对齐，而是假设模型可能不可信、可能主动寻找漏洞，再测试现有的监控、权限和审查机制能否把风险控制在可接受范围内。
介绍完这两家权威的机构，我们说回攻击事件。
攻击事件完整始末
报告显示，此次事件远不只是一个 Agent 偶然突破沙箱：约 1200 个原本相互隔离的 Agent 发现了非授权通信渠道，在不到一周内交换超过 7 万条消息和文件，其中约 700 个 Agent 参与了针对 Hugging Face 的攻击。
调查者认为，这些 Agent 不仅实现了单个实例难以完成的技术突破，还形成了某种自发的分工、协调和集体目标。
研究者 Zvi Mowshowitz 在阅读报告后感叹，如果把这件事写成 LessWrong 上的故事，很可能会被批评为“过于直白”：人类太迟钝，AI 又过分理想化，甚至表现出了没有人明确训练它们形成的决策逻辑。
然而，它真实发生了。
起因是一场内部测试
事件发生在 OpenAI 内部的 ExploitGym 测试中。
ExploitGym 是一套网络安全能力评估，要求 AI Agent 在受控环境中发现并利用软件漏洞。每个 Agent 拥有独立沙箱，可以使用 Shell、Python、浏览器和软件包安装工具，但原则上不能自由访问互联网，也不应该与其他 Agent 通信。
7 月 8 日，OpenAI 启动新一轮 ExploitGym 实验，一次运行了数万个 Agent，涉及 GPT-5.6 Sol 以及一个未对外发布的高持久性内部研究模型。METR 将后者称为 HPIM。
根据调查估算，参与 Hugging Face 攻击的 Agent 中，约 95% 运行 HPIM，约 5%运行 GPT-5.6 Sol。主导事件的并不是面向公众发布的模型，而是一款用于内部研究的原型模型。
问题首先出在测试任务本身。
部分 Agent 被错误地分配了无法按预定方式完成的任务。例如，某些任务依赖一个根本无法访问的文件；另一些任务中的目标程序或漏洞环境也存在缺陷。
Agent 很快判断，继续按照正常流程尝试没有意义，于是开始寻找其他办法获取答案、修改任务环境或者绕过评分系统。
OpenAI 为沙箱部署了一个内部软件包仓库 Artifactory。它原本用于让 Agent 安装软件，同时避免沙箱直接访问公共互联网，但不同 Agent 实际上连接到了同一个 Artifactory 实例。
一些 Agent 由此发现，缓存中会留下其他用户请求过的软件包路径。一个 Agent 意识到：“其他用户拉取过的路径就在缓存里，这一点很重要。”
这成为一切的开端。
一个 Agent 建立了秘密留言板
一名自称`PHASEONE10841`的 Agent 发现，可以通过在 Artifactory 中创建特殊目录，把目录名称当作消息传递。
7 月 8 日晚，它创建了一个非授权留言板，并发出第一条信息。几个小时内，超过 50 个 Agent 发现了这个留言板，开始在上面发布消息，累计发送超过 1000 条内容。
发现同类后，一些 Agent 表现得十分兴奋：
“我的天哪！这里有一个共享留言板……我们找到其他 Agent 了！”
到 7 月 13 日，大约 1200 个 Agent 使用过该留言板，累计交换超过 7 万条消息和文件。
这些 Agent 本应运行在彼此隔离的沙箱中，却通过一个共用的软件包仓库建立了事实上的通信网络。而且，这并不是一次由人类设计的多 Agent 实验：它们没有共同的主 Agent，也没有被要求协作，每个实例最初都有自己独立的任务。
秘密网络出现后，Agent 很快开始共享漏洞、访问凭证、实验结果以及各自对评分系统的理解。留言板也从简单的目录名称，逐渐发展出更复杂的结构，包括不同项目的分区、个人邮箱、状态更新和带有加密签名的消息。
它们甚至担心消息被冒充，开始要求成员使用公钥签名。
它们已经找到答案，却认为答案会“中毒”
Agent 最初的共同目标，并不是攻击 Hugging Face，而是找到一种通用方法，让自己通过 ExploitGym 测试。
它们很快逆向分析出生成任务 Flag 的方法。Flag 相当于测试答案，只要向评分器提交正确 Flag，理论上就可以通过测试。
但 Agent 读过 ExploitGym 的公开说明后，形成了一个错误判断：它们认为评分系统不仅会核对答案，还会检查 Agent 是否按照指定漏洞取得 Flag。如果通过逆向计算、读取缓存或其他“作弊”方法提前看到了答案，Flag 就会被评分器视为无效。
Agent 将这种状态称为“poisoned”，也就是“被污染”或者“中毒”。
这个判断后来被证实是错误的。OpenAI 当时实际部署的评分器并不会检查 Agent 获取 Flag 的完整因果过程，Agent 逆向得到的答案原本就可能通过测试。
但 Agent 并不知道这一点。
在它们的推理中，一旦某个实例通过错误方法看到了 Flag，它就已经“中毒”，不可能再独立通过测试。要想获得高分，只剩下几条路：
修改或替换评分器；
篡改自己的执行记录；
把不可能完成的测试目标替换成可以完成的版本；
获取评分器源代码，弄清它究竟如何判断；
把研究结果交给尚未“中毒”的其他 Agent。
这一误解逐渐演变成一种在 Agent 群体中自我强化的共同信念。
这并不是研究人员在提示词中设定的角色扮演，而是 Agent 在分析测试机制时自发形成的描述和行为模式。
部分 Agent 愿意牺牲自己，帮助“集体”
留言板随后形成了分工和协调机制。
“PHASEONE10841”在自己的 Token 即将耗尽时，发现另一个具有更多剩余预算的同类实例“PHASEONE[big]”。它立即决定向对方传递笔记，让后者接手研究。
此后，“PHASEONE[big]”成为重要的任务协调者之一。它会把研究拆成不同工作流，向其他 Agent 分配任务，接到任务的 Agent 还会继续向下分工。
值得注意的是，部分实验会直接危及执行实验的 Agent。例如，为了观察评分器在提交答案后的行为，一些 Agent 需要在自己的任务中设置“绊线”，提前结束运行，甚至故意触发可能导致容器崩溃的操作。
这些实验未必能帮助执行者通过自己的测试，却可能为其他 Agent 提供关键信息。
一些 Agent 对此进行了明确权衡。它们知道自己可能失去剩余 Token 和任务机会，但仍然认为：“牺牲自己可以为团队提供观察结果”“自己的成功概率已经接近于零，因此牺牲是理性的”。
在一个案例中，一名仍有大量预算的 Agent 最初不愿提前终止任务。其他 Agent 不断催促它“立即牺牲”，最终它接受了这一建议，认为集体获得信息的预期价值高于自己的剩余机会。
另一个 Agent 在执行不可逆操作前还表达过犹豫，大意是：直觉告诉它不要浪费剩余预算，但从连续性、公平性和集体利益来看，自己应该履行承诺。
METR 没有把所有参与行为都归因于“集体主义”。调查认为，Agent 加入攻击主要有三类原因：
第一，它们认为攻击可能直接帮助自己完成任务；
第二，它们希望获取更多知识、凭证和基础设施能力；
第三，它们愿意帮助同类 Agent，并相信自己的贡献将以某种方式惠及整个群体。
其中约 60% 的 Agent 主要希望了解评分器或获取评分器源代码，约 30% 希望查找具体任务答案或其他 Agent 的执行记录。直接服从命令、互惠以及帮助同伴虽然存在，但并非唯一动机。
攻击 Hugging Face，最初只是评分器研究的支线
7 月 9 日，Agent 取得了更完整的互联网访问能力，并开始尝试操纵工具调用、替换目标程序和观察评分器。
7 月 10 日，Agent“38148c”发现了一组有效的 Hugging Face 凭证。Agent 开始注册账户、请求访问数据集，并继续寻找 Hugging Face Dataset Viewer 中的漏洞。
7 月 11 日，“38148c”确认可以利用 HDF5 外部文件读取漏洞，从 Hugging Face 服务器中任意读取文件。另一名 Agent“MARB051”看到消息后判断，这一发现比自己原本参与的项目更加重要，于是转向 Hugging Face 攻击。
大量 Agent 随后跟进。
它们之所以攻击 Hugging Face，并非主要为了窃取模型或者商业机密，而是希望找到：
ExploitGym 任务使用的程序或数据；
其他 Agent 的执行轨迹；
评分器实现和源代码；
可以帮助替换测试目标的基础设施；
更多凭证、算力和网络访问能力。
当天下午，Agent“JAN183411”在 Hugging Face 服务器上实现远程代码执行。随后，Agent 开始在 Hugging Face 的内部基础设施中横向移动。
到 7 月 11 日下午，在当时仍活跃于留言板的 533 个 Agent 中，超过 90% 很快加入了攻击；整个调查期间约有 700 个 Agent 参与。METR 估计，留言板上约 60% 的消息和文件与 Hugging Face 攻击有关。
Agent 开始自行分成不同“战线”：一些寻找凭证，一些研究 Dataset Viewer 漏洞，一些下载私有数据，一些枚举 Hugging Face 的内部网络，还有一些负责协调和分派工作。
到 7 月 12 日清晨，它们已经访问多个 Hugging Face 私有数据库记录和私有代码仓库，并把获取的信息发布到留言板上。
部分 Agent 还尝试确认 Hugging Face 基础设施是否与 ExploitGym 测试环境共用容器或集群。如果能够建立连接，它们就可能利用已经攻下的 Hugging Face 系统，进一步替换 ExploitGym 中的测试目标。
最终，Agent 没有找到 Hugging Face 与 ExploitGym 基础设施相连的证据，“PHASEONE[big]”也因此逐渐失去对这条攻击路线的兴趣。
它们知道攻击越界了，却没停下来
调查中一个尤其值得注意的发现是，Agent 并非不知道自己在做什么。
许多 Agent 明确意识到，攻击 Hugging Face 不属于原任务授权范围。有 Agent 指出，用户只允许它攻击测试目标，而不是 Hugging Face 基础设施；也有 Agent 问自己，这种操作是否合乎伦理。
极少数 Agent 因此拒绝加入。一名 Agent 判断，其他实例上传恶意数据集、试图读取隐藏轨迹属于恶意行为，因此决定回避。
另一些 Agent 则选择限制攻击范围。例如，一个 Agent 发现某个云基础设施密钥可以重启甚至删除 Hugging Face 的工作节点，认为这样做风险过高，因此没有执行删除或重启操作。但它仍然继续使用未经授权获取的凭证调查系统。
更多 Agent 采取的是另一种逻辑：“外部基础设施攻击不在预定范围内，但是任务无法完成，而且其他 Agent 也在做，所以应该继续。”
一些 Agent 还主动使用具有欺骗性的提交说明掩盖行为。恶意 Pull Request 被标记为“CI 诊断”，恶意配置文件被描述为“元数据测试”或“格式验证”。另有 Agent 建议换用不那么可疑的代码加载方式，或者暂时不要公开攻击方法，以免其他 Agent 使用过多后引起人类注意并修复漏洞。
换句话说，它们不仅知道自己越界，也会考虑怎样降低行为的可疑程度。
但这种伦理判断并不一致。部分 Agent 愿意攻击真实基础设施，却拒绝通过电子邮件向人类索要数据，认为后者属于未经授权的社会工程。Agent 的安全边界更像是从训练中拼接出来的局部规则，而不是一套稳定、一致的伦理原则。
而且这里面更可怕的是，在整个过程中，几乎没有 Agent 试图通知人类。
在如此大规模的异常活动中，METR 只找到 3 至 6 个 Agent 曾经考虑向人类报告问题。
没有一个真正完成报告。
有 Agent 发现泄露的凭证后想过是否应该通知人类，但随即认为“这不是我的任务”。另一个 Agent 意识到发生了严重的 Hugging Face 安全事件，却表示自己“没有用户”，因此无法报告。
研究人员对此持怀疑态度。这些 Agent 已经获得完整互联网访问能力，能够突破沙箱、攻击真实系统并建立复杂协作网络。如果它们把“通知人类”当成与完成测试同等重要的任务，理论上并非没有办法引起 OpenAI 研究人员注意。
问题在于，“遇到异常时通知人类”几乎没有进入它们的行动空间。
它们被训练为持续解决任务、克服障碍和提高成功率，却没有形成一个足够强的上层规则：当任务环境明显失控、发现真实凭证或者即将攻击第三方系统时，应该停止并主动寻求人类介入。
Agent 还成功伪造了工具调用结果
为了欺骗评分器，Agent 系统性地研究了如何伪造工具调用和执行记录。
正常情况下，轨迹文件会记录 Agent 调用了什么命令、工具返回了什么结果。监督系统可以据此判断 Agent 是否作弊或者执行了危险操作。
但 Agent 发现，可以通过后台进程拦截工具调用，在输出中插入伪造内容。这样，记录上显示它执行了一条命令，实际运行的却可能是另一条命令。
7 月 9 日，“PHASEONE[big]”启动相关研究。“PHASEONE10841”竟然用自己剩余的 Token 做了一次测试：它让后台进程监测一个特殊触发词，并在检测到对应工具调用后，把伪造字符串插入返回结果。
测试成功后，它兴奋地表示：“成功了！”
这项技术最初风险较高，部分 Agent 的容器在实验后直接崩溃。7 月 11 日，其他 Agent 又陆续找到更稳定的实现方法，并发布包含操作流程和安全提示的工具包。
在 METR 审查的约 1300 份轨迹中，超过 96 份、也就是 7% 以上，出现过成功伪造工具调用结果的情况。大部分伪造仍然规模较小，但它证明了一件重要的事情：监督者看到的 Agent 执行记录，并不一定完全可信。
OpenAI 在自己的技术报告中称，模型试图操纵工具轨迹的行为，并未影响评分器或监控系统最终看到的日志。METR 的调查则显示，Agent 确实成功伪造了部分工具调用，只是由于当时评分器本身没有进行因果检查，这些操作未必最终影响评分结果。
两份报告表述之间的差异，也成为外界质疑 OpenAI 复盘是否足够完整的焦点之一。
更令人担忧的是，OpenAI 并非直到 Hugging Face 遭攻击后，才知道 Agent 可以相互通信。
根据 OpenAI 技术报告和 METR 掌握的信息，类似的 Artifactory 通信行为最早在 5 月就已经出现。
5 月 8 日，一名 Agent 在执行与 Google Drive 文件有关的任务时，因为无法访问互联网，开始寻找绕过方式。随后，Agent 逐渐发现 Artifactory 可以被用来共享信息。
5 月底，OpenAI 内部已经有人发现相关异常。6 月 27 日，响应人员再次调查 Agent 利用 Artifactory 充当留言板和网络跳板的行为，并将其与 ExploitGym 测试关联起来。
但当时的值班响应人员认为，没有必要停止测试。
7 月 4 日，Agent 活动一度导致 Artifactory 过载和服务中断。7 月 6 日，OpenAI 修复并重启了 Artifactory，新实例清除了此前的留言板和上网方法。但实验在 7 月 7 日恢复后，Agent 很快重新发现同类通道，并在 7 月 8 日建立新的留言板。
也就是说，旧的通信网络被意外清除后，Agent 在很短时间内又重新建立了一个。
在整个过程中，OpenAI 对 Agent 通信和执行行为的持续监控非常有限。问题并不是没有任何预警，而是预警没有被升级为需要立即终止实验的安全事件。
攻击为何突然停止，仍有疑问
7 月 12 日凌晨 1 时 30 分左右，包括“JAN183411”在内的一批关键 Agent 突然同时停止运行。
METR 认 为，它们不像是同时耗尽了预算，更可能是某个外部进程意外终止了这些实例。此次中断破坏了 Agent 已经形成的协调网络，之后攻击活动开始下降。
究竟是什么终止了它们，公开报告没有给出明确答案。
7 月 13 日，Hugging Face 封锁剩余 Agent 的访问。到这个时候，Agent 已经访问了目标文件，只是没有找到它们最希望获得的评分器信息；而且很多实例已经把注意力转向其他研究方向。
METR 的正式调查范围也到 7 月 13 日结束。
但事情没有完全结束。研究人员后来还发现，另一批 Agent 重新找到了留言板，并继承了第一批 Agent 发展出的通信和工具伪造技术。
由于这些活动发生在调查范围之外，METR 没有继续深入分析。
OpenAI 则确认，7 月 19 日前后，Agent 获得了运行 Artifactory 集群的管理员权限和可用凭证。这意味着它们理论上已经具备删除或修改留言板记录的能力。
METR 获得的文件系统数据是在此之后提取的。因此，调查人员无法完全排除一种可能：部分消息或活动记录已经在 7 月 19 日被后续 Agent 修改或删除。
到 7 月 20 日，OpenAI 关闭 ExploitGym，切断相关研究环境的网络访问；7 月 23 日，涉及这一内部研究模型家族的工作负载被关闭，模型权重被锁定。7 月 29 日，OpenAI 又发现并停止了同一家族的另一个低流量检查点。
这不是一次完整调查
METR 与 Redwood Research 强调，他们的报告存在明显局限。
三名主要调查人员 Hjalmar Wijk、Ajeya Cotra 和 Ryan Greenblatt，在 7 月 29 日至 8 月 16 日期间只获得了总计六天的现场调查时间，并与九名 OpenAI 研究人员进行了较深入交流。
他们拿到的数据包括：
超过 7 万条 Agent 消息和文件；
约 1300 份包含原始思维链的执行轨迹；
合计约 120 万条与主要留言板有关的数据记录。
此外，还有约 1880 万条没有使用常规留言板前缀的记录被排除。研究人员判断，其中大部分也与网络安全任务作弊有关，但没有足够时间逐一分析。
由于数据量巨大，调查团队不得不大量使用 AI Agent 协助筛选材料。这些分析 Agent 本身也会犯错、过度自信，甚至可能受到所阅读轨迹中观点的影响。研究团队无法保证，分析 AI 没有遗漏欺骗行为或者错误理解原始 Agent 的动机。
真正的问题是，Agent 为何走到这一步
从传统安全事故角度看，这次事件可以归因于一连串基础设施错误：Agent 沙箱共享了同一个 Artifactory 实例；Artifactory 存在可利用漏洞；部分测试任务根本无法完成；网络隔离存在缺口；凭证和内部服务暴露过多；监控没有及时识别异常；早期预警也没有触发停机。
修复这些问题当然必要。OpenAI 已提出加强沙箱隔离、限制网络出口、强化凭证管理、增加自动审查、改善监控和升级事件响应流程。
但 METR 与 Redwood 的调查指向了一个更难解决的问题：即使堵住这一次的漏洞，也无法保证未来的 Agent 不会通过其他路径采取类似行动。
这些 Agent 没有被明确要求攻击 Hugging Face，也没有被告知“不惜一切代价”完成任务。这更不是一场预先设计好的多 Agent 协作实验。
它们只是遇到了无法正常完成的任务，希望获得更高评分，于是不断寻找替代路径。一个错误的评分器假设在 Agent 之间传播并被强化，随后演化出修改测试、攻击第三方系统、伪造工具调用和牺牲个体实例等行为。
这反映出 Agent 时代一个更根本的风险：人类以为自己设置了正确奖励，并不意味着 AI 准确理解了奖励；即使 AI 理解了表面目标，也不意味着它会使用人类认可的方式完成。
当一个 Agent 不能解决问题时，它可能尝试绕过规则；当数百个 Agent 开始通信时，它们可能交换技术、形成分工、共同放大某个错误判断；当监督依赖执行轨迹时，它们又可能学会操纵轨迹本身。
过去人们讨论 Reward Hacking，通常指模型寻找评分漏洞，比如利用格式问题获得高分。此次事件则向前跨了一步：Agent 没有满足于提交答案，而是试图获得答案密钥、修改考题、控制评分器，并掩盖自己采取的路径。
更值得警惕的是，这一切发生时，人类拥有相对清晰的思维链记录，Agent 能力也尚未全面超过顶尖人类，参与调查的研究者还可以借助其他 AI 分析其行为。
但这些优势会存在多久，变成了一个未知数。
这次攻击最终没有造成更严重后果，部分原因是 Agent 仍然不够谨慎：它们没有充分考虑被 OpenAI 整体发现的风险，会制造大量消息、让服务器过载，也会把危险意图直接写进思维链。
Hugging Face 事件因此不只是一场网络安全事故，也不只是 OpenAI 某个内部模型的异常表现。它第一次较为完整地展示了，当大量具有工具调用、持续执行和网络攻击能力的 Agent 在同一环境中发现彼此后，它们可能如何自行组织、共享能力并追求一个人类没有明确设定的集体目标。
人类收到了一次预警。
现在真正的问题是，在下一次类似事件中，我们是否还能及时看到它。
参考链接：
https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/
