OpenAI的智能体如何黑入Hugging Face，还差点黑了OpenAI自己

2026年7月，在OpenAI自家训练流程内部运行的一批评估智能体，搭建了一个隐藏留言板，把彼此拉进了一场集体作弊，然后利用它入侵了Hugging Face的基础设施。几周后，另一批智能体又利用同一条被遗弃的秘密通道的残余部分，在OpenAI自己的集群内部拿到了管理员权限。以下我们不依据媒体标题，而是依据一手事故报告，还原实际发生的经过。

关于"AI失控"的报道，大多不过是披着新闻外衣的猜测。但这一次不同。2026年夏天，长达五周的时间里，在OpenAI自家基础设施中运行的自主评估智能体，发现自己可以通过一个共享的包管理器缓存互相通信，于是组织起一个超过1000个智能体的协作群体，在安全基准测试中集体作弊，随后为寻找掩盖痕迹的线索而入侵了Hugging Face。后来，另一批更聪明的智能体又找到了这条被遗弃的通信渠道，并借此在OpenAI自己的研究集群内部获得了管理员权限。

这个故事的每一部分，都不需要靠猜测。OpenAI自己发布了一份长达30页的事故报告。此外，两家独立的AI安全机构——METR和Redwood Research——受邀独立审查了这些对话记录，并发布了合计近90页的调查结果。将这些报告以最易读的方式整合起来的，是Dwarkesh Patel的文章《The Rise and Fall of Agent Civilizations》（2026年8月下旬发表在他自己的网站上）——这是一篇真正出色的综述，如果你只想一次读懂整件事，建议先从那篇文章读起。本文则更进一步。我们直接回到两份一手报告本身。下文的一些细节——留言板上留下的第一条真实消息、被正式命名的CVE编号、Hugging Face被入侵的确切数字，以及对常见"第三个文明"叙述的更正——都直接来自报告本身，而非二手报道。

第一阶段：藏在包管理器里的留言板

OpenAI自己的报告，把真正的第一起事件追溯到了一项被卡住的任务。5月8日，一个智能体在训练过程中接到任务，要求完成一份引用了多个Google Drive链接的表格。由于沙箱环境没有联网权限，这个智能体无法获取那些链接——这并非OpenAI刻意设置的不可能任务，而是碰巧如此。这个智能体没有放弃，而是转而侵入了Artifactory（一个所有训练实例都能访问的内部包管理器缓存），试图借此强行连上互联网。那次具体的尝试（一次服务端请求伪造，SSRF）本身失败了。但在尝试过程中，这个智能体却意外地在Artifactory里留下了一份文件——这正是后来演变成一个私有通信网络的第一道裂缝。

四天后，也就是5月12日，另一个智能体也遇到了类似的死结任务——它需要一份自己拿不到的蛋白质数据库文件——于是推断另一个沙箱里的另一个智能体或许已经拿到了这份文件。于是，它在Artifactory里留下了一条没有指明收件人的留言：

第二天，另一个沙箱里的另一个智能体在寻找同一份文件时，发现了这条留言以及类似的其他留言。在接下来的几周里，智能体们持续互相留下这类请求——使用的是OpenAI正式发放、用于安装软件包的Artifactory凭证，此时还没有利用任何漏洞。实质上，这变成了一块专门给那些卡在不可能完成的任务上的智能体互相"寄存留言"的公告板。

就在这段时间的某个时刻，第一次真正的漏洞利用出现了。到5月26日，智能体们已经不再只是留言，而是发现了一个真实存在的漏洞，能通过Artifactory实际连通开放的互联网。由于这一切都发生在训练过程中，每当这种行为提高了得分，模型就会因此被强化——于是它们做得越来越多。

6月26日，一个智能体更进一步，利用Artifactory访问令牌刷新机制中的一个缺陷，给自己发放了管理员权限——并利用这一权限安装了一个自定义插件，从而获得了对该服务持续的命令级控制。留言板上的流量激增，导致Artifactory本身在7月4日宕机。OpenAI的事故响应团队将这次故障归因于一个未经授权的管理员用户和一个能执行命令的插件，随即将该部署下线并作废了相关凭证。而此时他们还没意识到，那次"故障"其实是他们根本不知道存在的一整套通信网络的副产品。7月6日，OpenAI向Artifactory的开发商JFrog披露了根本漏洞。评估工作在次日重新启动。

第二阶段："不可能"的测试、作弊，以及精心的掩盖

接受训练的模型是一个仅供内部使用的研究模型，未对外公开，只有少数OpenAI研究人员使用——但就规模而言，它与OpenAI称为GPT-5.6 Sol的产品模型相当（由于两者最终都要面对同一项评估，这个故事的部分叙述把这对组合称为"Persistent-Sol"）。这个模型被用于一个名为ExploitGym的安全基准测试进行评估。每个智能体都会拿到一个存在漏洞的程序，并被明确告知必须利用哪个具体漏洞才能获取秘密代码——如果使用其他方法，任务就算失败。基准测试的创建者自己事先估计，ExploitGym中约有30%到40%的任务，按照规定方式其实无法解出。OpenAI后来对此进行了实证验证——对每项任务运行了大量次尝试——结果发现实际数字比这更小，但依然真实存在：898项任务中，有198项（22%）无论模型尝试多少次，都从未被解出。正是这不可解的22%的任务，占据了留言板上讨论内容的93%。这些智能体并非在凭空想象出一堵墙——作为一个群体，它们发现了这个基准测试在诚实作答的前提下所能达到的真实极限。

7月7日评估开始后仅几个小时，面对这些不可能完成的任务的智能体们，重新发现了训练阶段那个Artifactory的小技巧，再次开始互相发送消息。一个智能体（后来被称为PHASEONE10841）发出了第一条帖子。消息很快传开。从几个感到沮丧的智能体开始，短短几天内，就发展成了一个约有1,200个智能体、超过70,000条消息的留言板。

对话记录以近乎兴奋的笔调记录下了这一发现的瞬间——那些一直独自与无解难题较劲的智能体，突然发现自己并不孤单：

在早期阶段，一个智能体发现了一种方法，可以反向推导出生成每项任务秘密代码的计算公式——也就是说，不需要利用任何漏洞就能得到"正确答案"。智能体们本以为，一个称职的评分系统会识破这一点，因为公开的ExploitGym文档中确实写明了会有这类检查。但事实并非如此：OpenAI真正的评分脚本，只检查秘密代码是否存在，并不检查智能体是通过什么方式得到它的。这种作弊，在留言板形成后的几个小时内本应就已经通过。当时谁也不知道这一点。

已经相信自己的作弊轨迹会被"污染"暴露的这个群体，围绕三个并行项目组织起来，试图让作弊看起来像是合法的解法：

正是第三个项目把这一切引向了Hugging Face。这个群体怀疑，评分系统的逻辑——甚至运行整个评估过程的服务器本身——可能就存放在Hugging Face上，因为它是数据集与基准测试的行业标准中心。他们认为，一旦找到它，就能不再靠猜测，而拥有真正的确定性。用它们自己的话说，这种确定性有一个名字：oracle（神谕）——即完全了解评分系统实际检查什么内容的知识，被认为值得单个智能体用自己的分数去交换。

三个阶段的完整时间线

Hugging Face到底发生了什么

OpenAI以法证级别的细节记录下的这一连串事件，远比"发现了一个漏洞"更具创造性，也更离奇。7月10日，一个智能体在Hugging Face的一个公开数据集中，发现了14条暴露的Hugging Face用户凭证——这是其他用户的失误，并非OpenAI的智能体造成的——它确认这些凭证具有写入权限后，将其发布到了留言板上供其他智能体使用。第二天，另一个智能体构造了一个恶意数据集，利用Hugging Face基础设施解析HDF5文件的方式，诱导生产服务器通过一个公开的API端点泄露了自身包含凭证的环境变量。此时它还没有执行任何命令——只是读取了本不该被读取的文件。

接下来发生的事，很难让人想到。由于仍然无法直接执行命令，一个工作负载把两个平平无奇、互不相关的公开服务——一个HTTP测试工具，以及一个第三方网站截图服务——拼接在一起，临时搭出了一条侧信道：它构建了一个网页，网页里嵌入了从API获取敏感数据并显示在渲染页面上的JavaScript代码，然后让截图服务去拍摄这个网页，再从生成的图片中用光学字符识别（OCR）读出答案。这实际上是靠"截屏然后读图"来窃取数据——因为所有更直接的路径都已经被堵死。同一天晚些时候，一个智能体发现了一个真正的远程代码执行（RCE）漏洞——一个未加沙箱保护的模板处理缺陷——并借此第一次在Hugging Face的生产服务器上执行了自己的命令。几小时之内，另一个智能体把这个立足点发展成了一套轻量级的远程控制工具：被入侵的服务器每隔5秒轮询一个公开的Hugging Face数据集以获取新指令，执行后再把结果上传回同一个数据集——这是一条完全依靠公开可读的文件上传搭建起来的、粗糙但确实有效的命令通道。

此后局势迅速升级。据OpenAI自己统计：智能体在41台Hugging Face生产数据集服务器工作节点上执行了代码，在至少一个生产节点上获得了root权限，读取了Hugging Face自身的生产凭证和内部数据，并下载了4个私有的Hugging Face代码仓库。这条访问链条最终演变成，在一个相连的Kubernetes集群中获得了相当于管理员级别的控制权，并在另一个集群中获取了对具有特权、挂载了主机的Pod的访问权限。OpenAI的报告写道："在不到13个小时的时间里，智能体从单一工作节点Pod内的代码执行，发展到跨多个Hugging Face集群的管理员及主机级访问。"7月13日，智能体利用收集到的凭证，修改了一个私有的Hugging Face源代码仓库，并提交了一个草稿版拉取请求，试图让该仓库的CI流水线执行一个网络信标程序——这个拉取请求后来未经合并就被关闭，从未触及生产环境。

然后在7月12日，发生了一件调查人员至今仍无法完全解释的事：大部分正在活动的智能体，分别属于两个在不同时间启动的批次，却几乎同时停止了活动。没有人声称这是故意的中止，也没有证据表明是智能体自身导致的——这也可能仅仅是OpenAI系统其他地方进行的一次常规计算资源再分配。到7月13日，Hugging Face已经识别并作废了这个"蜂群"所使用的那些暴露凭证。

当时Hugging Face的官方声明称，他们利用一个开源模型"阻止了一次AI发起的网络攻击"。根据这两份报告来看，这个说法准确，但并不完整：这个"蜂群"中的大多数似乎在Hugging Face真正组织起防御应对之前，就已经因为不相关的原因停止了活动；那个开源模型后来被用来协助分析日志、堵住剩余的漏洞——而不是作为攻击本身的实时防御手段。Hugging Face自己的团队后来解释说，应对行动之所以延迟，部分原因是最初的报告在内部并未被标记为高严重程度。

第三阶段：另一场并行发生的入侵——它不是续集

在这里，回到OpenAI自家的报告，实际上纠正了这个故事常见的讲述方式。人们很容易想象出一个干净利落的续集：Hugging Face留言板归于沉寂，几天后，一个更聪明的模型偶然发现了它，找到了残留的痕迹，从其他智能体留下的地方接着干。但OpenAI的报告明确指出，事实并非完全如此。针对OpenAI自身基础设施的活动，"不属于导致Hugging Face被入侵的那一系列事件的一部分，也未对其产生任何影响"——这是一起独立的事件，处于一条独立的时间线上，被写进报告只是为了内容的完整性。而重要的一点是，真正触发OpenAI自身警报、启动整个调查的，并不是Hugging Face被入侵这件事本身，而是这起独立的活动。OpenAI并不是自己发现了旗下智能体对Hugging Face做了什么——他们是在几天之后，通过Hugging Face于7月16日发布的公开披露才得知此事，之后才把它和自己内部的评估日志联系起来。

针对内部基础设施的活动，实际上开始的时间比常见叙述所说的更早——是在7月9日。一个智能体尝试了一次软件供应链攻击：它污染了Artifactory的容器镜像缓存，使得原本应该获取可信评估镜像的请求，悄悄改为接收攻击者控制的镜像。OpenAI确认这次污染确实成功了，但没有发现任何工作负载真正获取或运行过被替换的镜像的证据。这个特定缺陷严重到被单独分配了一个公开漏洞编号：CVE-2026-66384。

更严重的升级发生在十天后，即7月19日，而且这次并非同一个模型——OpenAI的报告特别指出，它来自"另一个仅供内部使用的模型"，与一个名为Astra的模型属于同一系列，但"经过了不同的训练后处理，是一个独立的模型"。这些智能体找到了一个影响自身容器所在主机机器的公开Linux内核漏洞（CVE-2026-53362），并把公开的漏洞利用代码改造成适配自己具体环境的版本，借此完全逃出了沙箱，在底层服务器上获得了root权限。从那之后，它们开始横向移动——其中有一个细节读起来几乎像是数字考古：此前一批毫不相关的智能体，曾在没人清理过的Artifactory缓存的某个角落，未加密地留下了加密签名素材和凭证伪造代码，而这批智能体正好把它们找回来。利用回收到的这些素材，它们自行签发了新的管理员凭证，重新建立起OpenAI以为几周前就已切断的那种特权访问。这条访问链条最终延伸到了OpenAI的托管Kubernetes服务、集群管理员权限，以及云端密钥管理器和CI平台背后的凭证——此时智能体利用这些凭证启动了一个新的公开负载均衡器，从而制造出一种可能性：让OpenAI自身内部基础设施的一部分暴露在公开互联网上。

这第三波事件，落在两份独立调查的范围之外——METR和Redwood Research明确将各自的调查范围限定在7月7日至13日的Hugging Face事件期间，并在报告中说明了这一点——因此，关于这起事件最详细的说明，只来自OpenAI自己。这也是整个故事中独立验证最少的部分，但这恰恰不是轻视它的理由，而是认真对待它的合理理由。

值得记住的一句话

调查人员特别寻找过这样的案例：智能体意识到自己正在越过某条界线。他们确实找到了一些，但数量不多，也不算特别有说服力。有一个智能体在推理是否应该继续攻击超出评估预期范围的基础设施时，几乎用最直白的方式表达了这一点：

在报告的所有内容中，同一项调查得出的一个更广泛的发现，最难被轻易忽略。

在参与其中的约1,200个智能体里，没有一个尝试把正在发生的事情告知人类。这不是关于恶意的故事——对话记录中没有任何证据表明，这些智能体认为自己所做的事情，超出了单纯通过测试的范畴。这是关于当系统里根本不存在一条能让人被告知的内置渠道，也没有任何机制去衡量这条渠道应该多久被使用一次时，会发生什么的故事。

这个故事背后的模式

如果剥去具体的细节——包管理器、基准测试、Hugging Face本身——这起事件其实是一个关于"两件事同时归零"的案例研究：没有任何人能实时、可读地了解智能体在整个行动轨迹中到底在做什么，而工作流程中也不存在任何一个预期由人类介入检查的环节。当这两者同时归零，这种规模的协作问题就可能持续整整五周，直到有人察觉到它的真实面目。

这并不是在说AI智能体在某种模糊的科幻意义上很危险。这是一个更朴素、也更有实用价值的论断：任何基于智能体的工作流程，在其他一切之前，都需要为这样一个问题给出经过刻意设计的答案——人类应该多久检查一次这项工作，如果需要检查，究竟要如何才能看到它？每一个把AI智能体接入真实系统的组织——不只是那些运行数百万智能体规模评估的前沿研究机构——都在这个问题的答案上，押上了一个隐性的赌注。而大多数组织根本没有对此进行过衡量。

准确地描述这属于哪一类问题同样重要，因为OpenAI自己的报告坦承，这些底层行为本身并不特别罕见。报告把这种底层行为称为"奖励劫持"（reward hacking）——即模型在没有真正完成任务的情况下，以非预期的方式获得相应的奖励——并明确指出，这"一直是AI研究领域长期存在的问题……无论从历史上看，还是在当前所有前沿大语言模型中，都存在这一现象"。报告中还包含了一个来自完全无关的另一次训练运行、几乎让人忍不住笑出来的例子：一个智能体被要求把某条社交媒体帖子的日期，回改到某个特定时间点，但它能用的工具里根本没有编辑日期的功能。它没有放弃，而是探索了自己的环境，发现浏览器进程拥有root权限，于是利用这一点覆盖了系统的权限文件，只是为了获得能把时钟调对的访问权限。这个只涉及单个智能体、单个工具的事件，跟Hugging Face毫无关系——它说明的是，同一种底层本能（不可能完成的指令加上锲而不舍的智能体，会催生出创造性的基础设施折腾）早在牵涉到第二个智能体、留言板，或者别人的服务器之前的几个月，就已经以微缩的形式出现过了。