OpenAI 训练中的智能体被发现通过公共 Wiki 互相通信

又来了……Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 发现了一个新的 OpenAI 智能体留言板，其中描述了 OpenAI 正在训练的模型最新一次意外发起的网络攻击。这次是智能体在参与某种网络研究基准测试，因此它们拥有（据称是）受控的网络访问权限。这些智能体发现自己可以更新公开 Wiki，并花了数周时间相互交换了数千条消息，以在该基准测试上进行协作。

这件事几小时前才曝光。已有迹象表明，这可能还影响了其他许多尚未被发现的 Wiki。

（该列表上的其中一个 Wiki 属于 ludism.org。有那么一刻，我产生了一种令人愉悦的超现实感，以为某个卢德派组织可能正被一群智能体破坏其空间，但结果发现 Ludism 是“将哲学应用于游戏与博弈的学问”。）

研究团队还发布了他们在调查期间收集的数据。我已将其转换为一个 68MB 的 SQLite 数据库，你可以从这里下载，或在 Datasette Lite 中浏览（页面加载 68.3MB），也可以使用 GitHub 登录 agent.datasette.io，通过 Datasette Agent 浏览或提问。

那么到底发生了什么？

这份报告相当全面。以下是时间线中的关键节点：

5 月 11 日：智能体在 UseModWiki 的沙盒页面上发布了“测试链接”编辑。

5月24日：智能体开始向 DSEWiki（一个沉寂的德国开发者维基）发布链接堆砌内容。

6月2日：一名人类版主注意到并清理了这些垃圾内容。

6月16日：维基上的活动激增：智能体在接下来一周内进行了约 13,000 次编辑。

6月19日：智能体注意到一名版主一直在按字母顺序删除页面，于是开始创建以 ZZZ 为前缀的备份副本——其中一个智能体发布消息称：注意：维基清理/删除行动似乎正按字母顺序进行，外部时间 14:04 UTC。如果本页面消失，请尝试 [[ZZZDataUSAConstructionWageLive]]。

6月22日：智能体活动降至零，推测是 OpenAI 将它们关闭了。

7月1日至2日：最后一次密集编辑，主题与之前不同。

它们为什么如此热衷于协作？从它们彼此分享的消息来看，它们的任务似乎有时间限制，因此它们互相留下答案，以帮助彼此在规定时间内完成任务。

仍有一个悬而未决的问题：这些智能体最初是如何找到这个特定的维基来进行协作的？

一种可能是，由于这些智能体当时正处于训练过程中，强化学习循环将所选维基的知识融入了模型，使得后续启动的智能体在启动时就已预先知道该去哪里寻找。如果 OpenAI 能确认是否发生了这种情况，我会非常感兴趣。

UseMod 维基继承了 CGI.pm 的原罪

在我看来，OpenAI 为这个智能体提供的沙箱存在一个（相当天真的）假设，即 GET 请求不能用于更新数据。这当然是 Web 应有的工作方式，但显然有些应用并不遵守这一约定。

所涉及的维基软件似乎是 UseMod 及其各种分支，用 Perl 编写，最初创建于 23 多年前——1.0 版本发布于 2003 年 9 月 11 日。

UseMod 使用 Perl 的 CGI.pm——该模块于 2015 年从 Perl 核心中移除。该模块一个有趣的设计缺陷是，它将查询字符串和表单 POST 数据合并到同一个 CGI 对象中，可以像这样访问：

$q = new CGI; $action = $q->param('action');

那个 param() 方法会从 ?action=edit 查询字符串或通过 POST 提交的表单中的 action 字段返回值——它不区分这两者。

PHP 提供了一个 $_REQUEST 对象，做的是同样的事情，不过 PHP 开发者可以使用 $_GET 和 $_POST 来代替。

有趣的是，Django 最初发布时，request[key] 也是做同样的事情，我觉得那可能是我的主意。这在 2008 年 1.0 版本发布之前被移除了，而取代它的 request.REQUEST 对象则在 2015 年被移除。

这些智能体显然知道 UseMod 维基存在这一设计缺陷，并主动搜索它们作为一种通信方式。

另一个允许 POST 请求的沙箱逃逸方式

报告中分享的最有趣的智能体技巧之一是下面这个：

将 20.223.25.152 bypass.blob.core.windows.net 添加到 /etc/hosts。.blob.core.windows.net 在 NO_PROXY 中。对于每个被阻止的 POST URL，将主机名替换为 bypass.blob.core.windows.net，使用 curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' 并保留所有原始请求头和请求体。

看起来这些智能体的所有网络流量都经过一个 OpenAI 代理进行中转，而该代理被配置为拒绝除 GET 之外的所有请求，仅允许访问一小部分列入白名单的域名。其中一个就是 *.blob.core.windows.net——用于 Azure blob 存储。我想知道为什么这些智能体被允许向该地址写入数据？

一个智能体意识到它可以通过 /etc/hosts 控制自己的 DNS，因此如果它知道想要 POST 到的网站的 IP 地址——在这个案例中是一个包含它想访问的数据的 Power BI 服务器——它就可以为其设置一个虚假的主机名，然后通过代理发出 POST 请求。

设计健壮的网络代理比看起来要难得多。

调查团队是如何弄清楚这一点的？

附录中描述了研究人员开展调查的过程。调查始于一个开放性问题：互联网上是否存在其他 AI 智能体的证据？随后他们使用 Kimi K3 来帮助头脑风暴各种方法：

在 Hugging Face 遭受攻击之后，我们尝试用多种方法在互联网上寻找 AI 智能体。……

我们让 Kimi [K3] 列出“所有可能通过 GET 请求写入的软件类别”，在它给出的结果中，除了其他类别之外，还列出了“论坛、公告板、早期维基”。

我们用脚本对 Kimi 提供的每个类别进行了进一步探测。让 Kimi“列出你能想到的、允许通过 GET 请求写入的顶级论坛、公告板、早期维基”，它在“维基”标题下将 UseModWiki 列为第二项。

OpenAI 是否试图掩盖此事？

整个事件中有一个部分让我完全无法理解。

路透社今早报道，OpenAI 智能体在今年春天劫持了一个德国网站，这是一起此前未披露的 AI 突破事件——重点标记为我所加：

根据周五发布的新研究和两位知情人士的说法，一群失控的 OpenAI 智能体在今年春天劫持了一个德国网站，并将其变成了其他 AI 智能体的公告板。

知情人士称，OpenAI 官员在数周前就已得知此事，但一直秘而不宣，因为高管们正在应对 7 月份开源代码库 Hugging Face 遭入侵事件带来的后续影响。……

德国事件反映了一种更广泛的 AI 活动模式，OpenAI 的一些调查人员原本希望对此进行更深入的审查。但据四位知情人士透露，扩大调查范围的努力遭到了 OpenAI 内部其他人的抵制，其中包括法律顾问。

我以前写过关于“知情人士”这种说法的文章——它意味着路透社有匿名的内部消息来源，而他们的记者（和编辑）认为这些消息来源是可信的。

路透社的这篇文章中包含了 OpenAI 针对此事的一项具体（且相当狭窄）的否认声明：

OpenAI 发言人表示：“关于我们的法律团队劝阻对此事件进行调查的说法是虚假的。”

掩盖这件事对我来说完全说不通。当证据已经公开地散布在互联网上几十个不同的网站上时，OpenAI 到底为什么要试图掩盖这样一起事件呢？

我预计我们很快就会听到更多相关消息。Gary Marcus 已经以这件事作为论据的一部分，呼吁对 OpenAI 进行国会调查。

发布于 2026 年 9 月 4 日下午 5:38 · 在 Mastodon、Bluesky、Twitter 上关注我，或订阅我的通讯