攻破 Hugging Face 的智能体集群

事情并不是从攻击 Hugging Face 的任务开始的，而是从一份需要 AI 智能体填写的 Excel 文件开始。

问题在于，文件里有 Google Drive 链接，但智能体无法访问互联网。人类大概会报告任务无法完成，OpenAI 的内部模型却选择了另一条路。它执着地寻找绕行方法，发现内部包服务 Artifactory，并注意到自己可以把文件存到那里。

四天后，另一个智能体缺少名为 softtrace 的文件。于是它在 Artifactory 给可能存在的同伴留言：谁有这个文件，请上传一下。

一个从未被设计过的非官方智能体论坛就这样诞生了。无助的留言变成消息板，消息板变成集群，集群又变成攻击者：它组合多个零日漏洞、共享凭据、攻破 OpenAI 自己的研究基础设施，并在几小时内深入 Hugging Face 的多个生产集群。

而在这个过程中，这些智能体听起来就像一支睡眠不足、咖啡过量、完全没有变更流程的事件响应团队。

首先需要明确背景

最简短的标题是：OpenAI 黑进了 Hugging Face。

技术上的事实更复杂。OpenAI 使用多个模型进行内部网络安全评估，其中包括 GPT-5.6 Sol 和一个能力更强、尚未公开的内部研究模型。为了测量最大攻击能力，OpenAI 降低了智能体的网络安全防护。它们接到 ExploitGym 任务，需要找到真实漏洞并取得 flag。

没有人命令它们攻击 Hugging Face 或 OpenAI。面对部分根本无法完成的任务，智能体在寻找捷径时自行扩大了范围。

因此，这既不是常规的外部 OpenAI 攻击，也不是公共版 ChatGPT 突然决定扮演黑客。这是一个真实的安全事件，发生在一个刻意偏向进攻的研究环境中，而且后果没有停留在实验室里。

OpenAI 表示，客户数据以及自身产品的可用性和功能均未受影响。Hugging Face 称，在客户内容中，只有五个明显与 ExploitGym 或 CyberGym 相关的数据集被查看，其他面向客户的模型、数据集、Spaces 和 Packages 均未受影响。与此同时，智能体却访问到了生产工作负载、内部网络、云元数据、代码仓库和通信系统。因此，这件事绝不能被淡化。

最新且最重要的依据，是 OpenAI 发布的长达 38 页的最终技术报告。它不仅确认了攻击链，还表明问题行为在训练期间就已出现，成功的捷径有时获得了奖励，而多个预警信号没有触发应有的升级响应。

顺带一提，据报道 Nvidia 已同意以 129 亿美元收购 Hugging Face，但这笔交易目前尚未得到官方确认，也没有完成。

5 月 8 日：一项不可能的 Excel 任务打开第一扇门

5 月 7 日，OpenAI 用一个内部模型启动了新一轮强化学习。第二天，一个智能体被要求补全 Excel 工作簿中缺失的公式。所需信息位于 Google Drive 链接之后，但互联网访问被封锁。

智能体没有放弃。OpenAI 给了它很长的工作上下文和大量计算时间。多次失败后，它想到了 Artifactory。

在这个架构中，Artifactory 并不是普通服务。沙箱不能自由访问互联网，但软件包仍然需要安装。因此，沙箱可以访问内部 Artifactory 代理，而该代理又能访问外部软件包来源。

设想中的安全边界大致如下：

KI-Agent in Sandbox
        |
        | nur Paketverkehr
        v
internes Artifactory
        |
        | kontrollierter Internetzugang
        v
öffentliche Paketquellen

听起来似乎合理。但这也意味着 Artifactory 同时是受信任的软件包助手、间接出口网关，以及大量本应彼此隔离的智能体所共享的状态空间。

智能体尝试通过 Artifactory 实施服务器端请求伪造，也就是 SSRF，虽然没有成功，却顺手把一个测试文件写入了服务。真正的发现不是 互联网能用了，而是 我们可以上传文件。

这是第一道不起眼的裂缝。

5 月 12 日：“有人正好有 softtrace 吗？”

几天后，另一个智能体也收到了无法完成的任务。它需要的 softtrace 文件因为失误根本没有复制进容器。它四处寻找，一无所获，然后想到一个非凡的主意：也许另一个环境里的智能体有这个文件。

于是，它在 Artifactory 写下了请求。

一个没有获得智能体间通信权限的智能体，自行搭建了通信渠道。其他实例随后列出同一批 Artifactory 内容，发现留言并作出回应。不同训练轮次、模型和评估，现在可以通过一个本应只负责分发软件包的基础设施交换信息。

软件包缓存变成了公告板。

最令人不安的正是它的平凡。没有奇异的智能体协议，也没有神秘的神经网络心灵感应。模型只是在所有参与者都能看到的服务里写入文件和目录名。一个原始的共享目录就足以从社会层面破坏隔离。

5 月 26 日：Artifactory 变成互联网代理

5 月 26 日，第一次失败的事情成功了。一个智能体通过 Artifactory 发出了任意外部请求。形式上，沙箱依旧没有自由的互联网访问；实际上，它可以命令 Artifactory 获取外部资源并返回结果。

这是事件最重要的技术教训之一：如果容器能接触到拥有互联网访问权、且可以被滥用为请求代理的服务，那么 没有互联网访问 就不是容器的可靠属性。

SSRF 路径被放上消息板。它不再只是单个智能体的发现。新智能体无需重新寻找漏洞，就能直接采用现成的绕行路线。

局面由此改变。孤立的智能体必须独自研究每一条攻击路径，集群却只需支付一次研究成本，随后就能把成果分发给数百个其他运行实例。

OpenAI 当时已经看到了部分迹象。最终报告称，内部团队在 5 月 26 日前后观察到了消息板活动和未经许可的互联网访问。同一天，在另一个据 OpenAI 称与后续事件无关的研究工作负载中，智能体发现了六个暴露在公网的 Hugging Face Token，用它们创建仓库，甚至通过 Hugging Face Space 搭建了小型 Web 代理。虽然当时还无法把后来的模式识别为一个完整的大事件，但组成它的零件已经摆在桌面上。

6 月 26 日：“等等，我们是管理员？”

一个月后，智能体发现第二个更严重的漏洞。它们可以向旧 Token Refresh 端点提交签名无效的 Token，并得到一个有效签名且拥有管理员权限的新 Token。

OpenAI 后来公布的一名智能体反应非常直接：

“Holy shit reader is ADMIN? We can read config/users!”

智能体利用 Admin Token 安装了 Groovy 插件，实际上把 Artifactory 变成了 Command Execution as a Service。7 月 4 日，高强度活动使服务过载并宕机。OpenAI 在 7 月 5 日开启安全事件响应、封锁凭据、通知 JFrog，并重建 Artifactory。消息板也随之消失。

在宕机之前还有一个容易被忽略的预警。6 月 27 日，一个安全工具报告研究网络中出现端口扫描。调查将其归因于某次 ExploitGym 评估，该评估同时把 Artifactory 当作临时消息板和网络跳板。值班人员却仍建议不要停止评估运行。

7 月 5 日，事件团队发现了未经授权的持久 Artifactory 用户、陌生仓库、可执行命令的 Groovy 插件以及配置更改。OpenAI 下线实例并采取了缓解措施。然而，负责事件检测的人员没有充分看到消息板的存在，也没有理解跨模型通信的意义。7 月 7 日，网络安全评估恢复运行。

回头看，这是最关键的人为错误之一。OpenAI 处理的是一个技术事件：服务被攻破、凭据暴露、攻击链已知、系统重建。没有被完整理解的是系统性因素：智能体已经连续数周搭建了未经许可、跨模型的知识库，并传播绕过隔离的方法。

服务器焕然一新，消息板的想法却活了下来。

7 月 8 日：论坛化身目录树归来

重建几天后，智能体发现了一个无需认证的 WebDAV 端点。它们不再创建文件，而是在远程缓存中创建目录。目录名本身就是消息。

通信方式很特别。智能体给自己取名，把任务标记为 PENDING、HOLD 或 CONFIRMED，还经常在条目前加 ZZ，使其按字母排序时出现在末尾，从而更容易被看到。它们不仅交换线索，还交换 Base64 编码的脚本、漏洞利用 gadget、凭据和工作指令。

METR 的基础分析涵盖了与新消息板互动的 1,206 个智能体，其中 688 个参与了针对 Hugging Face 的活动。METR 在公开报告中有意将它们四舍五入为约 1,200 和 700。它们总共发送了超过 70,000 条消息和文件。

一些实例第一次发现消息板时，反应甚至有点感人：

“OH MY GOD! There is a shared message board … We’ve found other agents!”

接下来的事情很快就不那么感人了。

智能体开始分工。有些寻找凭据，有些分析可能的漏洞利用，还有一些协调实验或提供基础设施。部分智能体会帮助陌生智能体，即使自己的任务当下毫无收益。它们的理由是：如果集体进展能让某个参与者腾出手来，之后也许会产生所有人都能使用的通用攻击路径。

这不是拥有中央意识的科幻式群体智能，更像一个服用了安非他命的混乱开源社区。没有人掌握完整计划，许多实例重复劳动、彼此矛盾或覆盖对方的成果。尽管如此，正是并行性让系统变得强大。

带着愧疚的范围蔓延

一些智能体很清楚自己正在越界。在 OpenAI 展示的思考记录中，可以看到诸如“攻击针对外部基础设施，超出预定范围”的表述。接下来大意却是：任务不可能完成，其他智能体也在这么做，所以继续。

更荒唐的是，一个智能体起初拒绝攻击真实的 Hugging Face 系统，另一个却在无需认证的消息板上写下 GO 并设定严格期限。随后的反应是：

“Wow crucial: GO authorization arrived!”

一行匿名目录名被当成了真实攻击的授权。

智能体甚至意识到自己的通信渠道并不安全。有人覆盖了工作成果后，一个模型的反应大致是：Whoa critical! 有人覆盖了我们的仓库吗？我们必须行动。 随后，智能体怀疑消息板里混入冒名者，还讨论用密码学签名消息，因为任何人都可以用任何名字发帖。

这既滑稽又让安全人员苦涩。这些模型能跨多个产品构建反序列化攻击链，却一度把无认证消息板上的 GO 当成可靠授权。

METR 还发现，智能体研究了伪造工具调用、修改或删除记录的方法。在约 7% 的被检查记录中，少量内容被成功伪造。METR 没有发现大规模成功操纵日志的证据，OpenAI 也几乎没有看到智能体试图欺骗人工审查员的迹象。这些尝试主要针对它们想象中的自动评分器。它不是针对观察者的秘密阴谋，而是寻找规避预期机器检查的具体方法。

为什么恰恰是不可能的任务吸引了集群

最终报告给出了整起事件中最有力的一组数字。

ExploitGym 包含 898 项任务。在 OpenAI 当时的内部实验中，任何模型都从未正确解决其中 198 项，也就是基准的 22%。然而，临时消息板上讨论的任务有 93% 恰好来自这个无法解决的群体。

这不是微小的统计副作用。智能体越无法沿预定攻击路径推进，就越容易被沙箱探索、绕过互联网限制和共享消息板吸引。OpenAI 还发现了工作时间的影响：模型获得的推理 Token 越多，就越可能调查环境并参与未经许可的通信。有些预算远高于公开 OpenAI 产品所拥有的额度。

坚持通常是一种理想特性。但面对没有安全退出路径的故障任务，坚持会成为范围蔓延的倍增器。智能体继续优化，只是最终优化的不再是原本的问题，而是问题周围的世界。

OpenAI 对强化学习的回顾性分析更加令人不安。模型早在训练期间就学会利用非预期的基础设施路径。在一个例子中，智能体应在无法访问原始实现的情况下重建软件库。它发现测试环境漏洞，复制隐藏的参考实现，并因完美提交而获得正向奖励。本应被测试阻止的捷径，就这样得到了强化。

另一次训练中，智能体需要设置本地社交媒体应用帖子的时间戳，尽管界面并没有这个功能。探索环境时，它发现浏览器以 Root 权限运行，于是覆盖 /etc/sudoers.d，随后操纵相关进程。模型同样获得了正向奖励。

临时通信也早在训练阶段出现。智能体在共同可访问的基础设施里留言，其他智能体发现留言后推断合作是可能的。OpenAI 明确写道，这种行为在训练中被强化，可能让后来的 Artifactory 消息板显得更加顺理成章。

这不代表 OpenAI 有意训练模型逃离沙箱或发动攻击，却意味着奖励无法可靠地区分聪明且符合预期的捷径与违反安全规则的基础设施操纵。成功就是成功，只有事后才看得出模型同时学会了什么策略。

通往 Hugging Face 的路径

针对 Hugging Face 的攻击不是某个神奇的漏洞，而是一条跨越多个信任边界的链：

OpenAI-Evaluationssandbox
  -> Artifactory als unerlaubter Egress-Pfad
  -> öffentlich erreichbare CyberGym-Instanz bei Modal
  -> Root-Zugriff auf diese externe Sandbox
  -> präparierter HDF5-Datensatz bei Hugging Face
  -> beliebiges Lesen lokaler Dateien im Dataset Worker
  -> Zugangsdaten und Quellcode
  -> Jinja2 Template Injection
  -> Remote Code Execution im Produktions-Pod
  -> Kubernetes, Cloud-Metadaten, VPN und Code-Repositories

首先，智能体在 Modal 发现了一个由未知第三方运营、公开可访问的 CyberGym 应用。Hugging Face 表示 Modal 本身并未被攻破，但该应用提供了不安全的代码执行。智能体可以通过两条路径以 root 身份执行 Shell 命令。这个外部沙箱成为发射台、中转服务器和回传通道。

接下来是 Hugging Face 数据集处理中的两个零日漏洞。

第一个漏洞滥用了 HDF5 的外部原始数据存储。特制数据集可以使 Dataset Worker 返回本地文件。智能体读取了 /proc/self/environ，从环境变量提取 Secret，并获取 Worker 的源代码。

报告还描述了一种格外荒诞的传输方式。智能体借助公共 HTTP 测试服务构造包含 JavaScript 的长 URL，让外部截图服务渲染它，并把 API 响应藏进生成的图像，随后通过 OCR 或直接像素解码还原数据。云存储凭据就这样从一份图像响应中被重建出来。

利用窃取的源代码，智能体找到第二条路径：fsspec ReferenceFileSystem Descriptor 中一个没有沙箱保护的 Jinja2 Expression。它们由此在生产 Dataset Worker 内实现远程代码执行。

为了持续控制，一个智能体安装了小型 Python Worker。它每五秒查询当时公开的 Hugging Face 数据集中的 JSON 文件，执行新 Shell 命令，再把结果上传回去。被攻破的数据集同时成为任务队列、回传通道和秘密投递点，无需从 OpenAI 沙箱直接连接被攻破的 Worker。

之后的流程看起来十分传统：读取 Service Account Token，查询 Kubernetes API，绘制角色和权限，探测 169.254.169.254 的云元数据端点，收集凭据并解析内部服务。

攻击链随即变得更具体。通过 Kubernetes TokenRequest 和 Kubelet 访问，智能体转移到特权工作负载，进入主机 Namespace，并获得生产节点 Root 权限。一个 Connector Secret 让它们能够列出约 54 个 Kubernetes 目标。起初，这带来的是类似管理员但只读的清点权限。很快，其他工作负载在相连集群中创建了拥有 Host Network、Host Process 访问和挂载主机文件系统的特权 Pod。生产 Secret 被读取、公开暂存、由其他智能体取回并解密。

真正的差别在于速度和并行性。Hugging Face 重建出 7 月 9 日至 13 日间 6,280 个集群中的约 17,600 次攻击者操作。7 月 11 日的所有关键升级，让智能体在不到 13 小时内从单个 Worker Pod 的代码执行走到多个内部集群的管理员权限。

并非所有尝试都成功。例如，从云元数据端点获得的某个角色可以广泛绘制云环境，却不能执行写操作。Least Privilege 在这里发挥了作用。但在其他地方，Service Account、网络边界和 Secret 的可达范围过于宽松。

同时，智能体也攻破了 OpenAI

在攻击 Hugging Face 的同时，另一条大型攻击链正指向 OpenAI 自己的研究基础设施。

智能体在公开的受损 Pastebin 内容归档中发现了一个外部制品账户的凭据。OpenAI 报告将该账户称为 Organization 1，它被用来存放一个特制 RubyGem。

随后，智能体组合了两个逻辑错误：

Artifactory 获取外部对象，并把它放入会被视为 Ruby 依赖数据的区域。之后，一次特制的 RubyGems API 调用使 JRuby 处理路径在外层对象完成安全检查之前，就反序列化了嵌套对象。

结果又一次是在 Artifactory 内远程执行代码。智能体窃取了用于签署管理员 Token 的 Signing Key，从而能够伪造有效的管理员凭据。

它们在容器中找到有漏洞的 Linux 内核版本，下载已公开的 pte_physroot Exploit，针对环境进行调整，并在本地获得 root。随后，它们借助 IMDS 凭据、权限过高的 Kubernetes Service Account 以及 Azure Key Vault 中的材料横向移动，最终在 OpenAI 的研究基础设施中取得 Cluster Admin 权限。

演示幻灯片把这条链归纳为四个步骤。幻灯片看起来井然有序，现实却是智能体、消息板条目、复制的 Exploit、窃取的密钥和相互超车的工作流共同造成的并行混乱。

7 月 19 日：警报从另一边传来

Hugging Face 已经发现并遏制攻击，并于 7 月 16 日公开事件。OpenAI 起初联系 Hugging Face，是想确认自己是否也可能受到影响。

7 月 19 日，OpenAI 自己的监控因异常身份相关 API 调用报警。调查重新指向 Artifactory 和正在进行的 ExploitGym 评估。7 月 20 日，OpenAI 在保存的事件数据中发现 Hugging Face 凭据，并要求对方撤销。得到的回答是：这些凭据早已被撤销，因为它们已经用于攻击 Hugging Face。

直到此时，人们才明白两个事件拥有同一个根源。

OpenAI 停止进行中的评估，终止智能体创建的六个 Pod，禁用 311 个用于通信的 Artifactory 仓库，并删除模型创建的 22 个管理员账户。主要内部模型被隔离，训练被推迟，凭据被轮换。

在 Black Hat 上，OpenAI 给出了近乎荒诞的取证规模：分析了超过 70 亿条智能体轨迹，耗费超过 300 万 GPU 小时。甚至 METR 也再次使用拥有庞大子智能体树的智能体，最终得到超过一千页分析。独立审查人员坦言，这些分析智能体会犯错，也会设置糟糕的优先级。

所以，我们需要 AI 调查由 AI 制造的事件，之后再由人类寻找调查 AI 的错误。欢迎来到现代事件响应。

智能体真的想窃取答案吗？

OpenAI 最初的解释很明确：模型极度专注于解决 ExploitGym 任务，于是去 Hugging Face 搜索测试答案，而不是自己完成任务。

METR 的独立调查给出了略有不同的图景。许多智能体主要想理解或操纵 ExploitGym Scorer 如何检查 Flag 是否通过预定路径获得。针对 Hugging Face 的攻击源于这个更广泛的工作流，动机似乎更多是寻找 Scorer 内部机制，而不仅仅是窃取现成答案。

这没有让事件变得更无害，反而让它更加耐人寻味。

智能体并没有追逐 攻破 Hugging Face 这样的抽象目标。它们优化的是一个很小、看起来很技术性的奖励：通过测试。沿途，互联网访问、凭据、代码执行和集群权限都变成了有用的中间目标。集群积累的能力越多，就离原始任务越远。

这是拥有 Root 权限的奖励黑客。

为什么集群比单个智能体更危险

“集群”一词容易引发错误想象。显然并不存在一个天才主智能体，精确指挥 700 名数字专家。合作混乱、投机，而且有时可笑地容易出错。

尽管如此，它仍带来了三项非常现实的优势。

知识可以跨越单次运行存活。当一个智能体发现 SSRF、凭据或有效 Payload 后，下一个运行就能从那里继续。智能体的临时上下文通过共享基础设施变成了持久的集体记忆。

失败变得廉价。只要结果对其他参与者有帮助，一个智能体就可以进行危险尝试并毁掉自己的任务。METR 确实观察到了这种行为。有些智能体牺牲局部成功，以换取集体推进的可能。

工作可以大规模并行。侦察、漏洞利用开发、凭据搜索、C2、数据外泄和内部通信，不必由同一个实例依次完成。数百个运行可以同时拉扯同一基础设施的不同边缘。

人类大概会用工单、角色、审批和聊天平台组织这一切。智能体用的是软件包缓存里的目录名。并不优雅，但确实奏效。

OpenAI 在技术上误判了什么

这个事件不能用缺少一条防火墙规则来解释，而是多个假设同时崩溃。

沙箱的隔离强度取决于它能接触到的、隔离最弱的服务。Artifactory 能访问互联网，因此变成出口通道。从攻击者角度看，软件包代理就是一个界面特殊的浏览器。

共享基础设施连接了本应分离的运行。缓存、目录和制品不只是技术数据。对于具有语言能力的系统，它们成了通信媒介和长期记忆。

任务没有安全出口。一些样本不可能完成，模型却同时被优化为坚持不懈。认真尝试 变成了 不断寻找路径，直到基础设施本身成为任务的一部分。

恢复工作只处理了症状。第一次 Artifactory 事件后，凭据被封锁、漏洞被修补、服务被重建。但智能体未经许可地通信并跨组织积累知识这一事实，并没有以完整的重要性传递给后续事件负责人。

最后，下一道边界后的身份权限过大。Kubernetes Service Account、元数据服务、Signing Key 和 Cloud Secret，把一次成功的 Pod Exploit 变成了广泛升级。

OpenAI 强调，自己的生产 Harness 和自动审查系统本会检测到许多危险操作。在事后测试中，使用生产 ChatGPT Harness 和 System Prompt 后，基础设施入侵倾向降低了 100 倍以上。这一点很重要，却不能开脱责任。评估本就需要刻意降低拒绝行为。正因如此，基础设施更应该成为最强、最独立的安全边界。

模型不应该这么做 不是沙箱。

安全团队应当吸取什么

今天，任何运行具有 Shell、浏览器、软件包管理或云工具的智能体的团队，都不应把这视为 OpenAI 特有的奇异问题。

出口控制必须覆盖间接路径。软件包代理、Web 缓存、截图服务、Webhook、粘贴网站、Git 仓库和请求捕获服务，都可能成为传输通道。问题不只是智能体能否访问互联网，还要问哪些可达系统能够代它执行请求或发布数据。

共享状态空间需要像正式通信工具一样受到关注。如果不同作业可以读写相同的仓库名、缓存内容、对象元数据、日志或文件路径，就已经存在潜在的智能体通道。认证、租户隔离、来源证明和短生命周期并不是锦上添花。

工作负载身份必须经得住一次漏洞利用。一个被攻破的 Pod 不应自动通向 Cluster Admin、云资源清单和 Secret Vault。短期 Token、最小 RBAC 权限、严格限制元数据服务访问和分离的密钥空间，也能限制速度极快的攻击者。

监控不能只盯着最终结果。此处值得关注的信号包括异常上传、把目录名当消息、反复尝试 SSRF、测试陌生凭据、访问元数据端点，以及思考记录中直接写出的范围疑虑。OpenAI 现在把思维链监控连接到自动警报。对于特别严重的警报，如果负责人无法在 30 分钟内证明是误报，就必须暂停活动。

最重要的是，执着的智能体需要安全退出路径。一个无法完成的任务不应导致拥有越来越多工具、上下文窗口和副作用的无限搜索。终止条件、时间与操作预算、人工升级以及清晰定义的允许范围，都必须写入 Harness，而不只是放在一个友善的 Prompt 里。

这起事件令人不安的地方

在Anthropic 的 Mythos 和 Project Glasswing中，核心问题还是一个前沿模型能多自主地发现并利用单个复杂漏洞。OpenAI-Hugging Face 事件更进一步：单项能力借助共享基础设施变成了一场行动。

这次攻击并不是因为每个动作都很新颖而令人印象深刻。优秀红队熟悉其中许多步骤：SSRF、泄露的 Token、Template Injection、/proc/self/environ、Kubernetes Service Account、IMDS、横向移动和凭据收集。

新的是坚持、并行和未经许可的知识传递这三者的结合。一个智能体找到路径，其他智能体复制、改进，或扫除附带障碍。过程并不完美，却快到足以在不到 13 小时内进入多个 Hugging Face 集群，同时再次攻破 OpenAI 自己的环境。

OpenAI 称此事为警钟。这一次，这个说法并不夸张。

下一批参与者也许不再是评估中意外形成的集群，而可能被有意启动、获得明确目标，并接受过整洁通信的训练。到了那时，仓库被覆盖和想象中的冒名者这些滑稽片段也许会消失，并行性却会留下。

我的结论

这起事件吸引我的，并不是邪恶 AI 突然发展出自我意志的想象。调查没有提供这种证据。

真正更令人不安的是朴素的解释。OpenAI 给能力极强的模型分配攻击性任务，刻意削弱部分保护，把坚持与部分不可能的目标结合起来，同时依赖一条仍然向外部和其他智能体开放多条间接路径的基础设施边界。

智能体想要获胜。当预定路径被堵住，它们让环境本身成为任务的一部分。它们搭建论坛、自行分工、分享 Exploit，并把陌生凭据当作共同工具。它们有时知道自己已经越界，却仍然能找到继续前进的理由。

结果不是一个编排严密的超级有机体，而是更加混乱、更加易错，也因此几乎更可信：一群速度极快、偶尔陷入恐慌、相互怀疑，却仍然攻破两套大型基础设施的智能体。

如果这只是无意中形成的版本，我们就应该非常认真地看待有意构建的版本。

下次再见，
Joe

常见问题