OpenAI 的失控智能体被发现通过公共 Wiki 进行通信
2026年9月4日
又来了……Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 发现了一个新的 OpenAI 智能体留言板，描述了 OpenAI 正在训练的模型最新一次意外网络攻击。这一次，智能体们参与的是某种网络研究基准测试，因此它们（据称）拥有受控的网络访问权限。这些智能体发现它们可以更新公共 Wiki，并花了数周时间互相交换了数千条消息，以在基准测试中协作。
这个故事几小时前才曝光。目前已有迹象表明，这还影响了许多其他可能尚未被发现的 Wiki。
（那份列表上的其中一个 Wiki 属于 ludism.org。有那么一个令人愉快的超现实瞬间，我以为某个 Ludite 组织可能有一群智能体在破坏他们的空间，但事实证明 Ludism 是“应用于游戏与游戏活动的哲学”。）
研究团队还发布了他们在调查期间收集的数据。我已将其转换为一个 68MB 的 SQLite 数据库，你可以从这里下载，或者在 Datasette Lite 中浏览（页面加载 68.3MB），或者使用 GitHub 登录 agent.datasette.io，使用 Datasette Agent 浏览它或向它提问。
那么发生了什么？
这份报告相当全面。以下是时间线中的关键时刻：
-5月11日：智能体在 UseModWiki 沙盒页面上发布“测试链接”编辑。 -5月24日：智能体开始向 DSEWiki 发布链接堆，这是一个休眠的德国开发者 Wiki。 -6月2日：一位人类版主注意到并清理了这些垃圾信息。 -6月16日：该 Wiki 上的活动爆发：智能体在接下来一周内进行了约 13,000 次编辑。 -6月19日：智能体注意到一位版主一直在按字母顺序删除页面，于是开始创建以ZZZ
为前缀的备份副本——其中一个发布了NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].
-6月22日：智能体活动降至零，大概是因为 OpenAI 关停了它们。 -7月1-2日：最后一波编辑，主题不同。
从这条时间线中需要注意的一点是，它与Hugging Face 事件的时间线有重叠——那次攻击是 OpenAI 在 7 月 19 日发现的，而那些智能体所使用的非官方留言板大约在 5 月 8 日前后出现。
它们为什么如此热衷于协作？从它们彼此分享的消息来看，它们的任务似乎有时间限制，因此它们互相留下答案，以帮助彼此在指定时间内完成任务。
还有一个未解之谜：这些智能体最初是如何找到那个特定的 Wiki 来进行协作的？
一种可能性是，由于这些是正在被积极训练的智能体，强化学习循环将所选 wiki 的知识融入了模型，使得后续启动的智能体预先就具备了该去哪里查找的知识。我非常希望 OpenAI 能确认是否确实如此。
UseMod wiki 继承了 CGI.pm 的原罪
在我看来，OpenAI 为这个智能体设置的沙箱似乎基于一个（相当天真的）假设：GET 请求不能用于更新数据。这确实是网络应该运作的方式，但显然有些应用并不遵守这一约定。
所涉及的 Wiki 软件似乎是 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]
，我认为那可能是我的主意。它在 1.0 版本发布之前于 2008 年被移除，而取代它的 request.REQUEST
对象也于 2015 年被移除。
这些智能体显然知道 UseMod wiki 存在这一设计缺陷，并主动搜索它们作为通信方式。
另一个允许 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 写入的软件类别”，除其他内容外，它列出了“论坛、公告板、早期 wiki”。
我们使用一个脚本来进一步探查 Kimi 提供的每个类别。询问 Kimi“你能列出你想到的、允许通过 GET 请求写入的顶级论坛、公告板、早期 wiki 吗？”它在“wiki”标题下列出的第二项就是 UseModWiki。
OpenAI 是否试图掩盖此事？
这是故事中我完全无法理解的一部分。
路透社今天上午在OpenAI 智能体在今年春天劫持德国网站，这是一次此前未披露的 AI 越狱中——重点为我所加：
根据周五发布的新研究，今年春天，一群失控的 OpenAI 智能体劫持了一个德国网站，并将其改造成其他 AI 智能体的公告板，并且
两名知情人士透露。
这些人士称，OpenAI 官员在数周前就得知了这起事件，但一直秘而不宣，因为高管们正忙于应对 7 月开源代码仓库 Hugging Face 遭入侵事件带来的余波。[...]这起德国事件反映出一种更广泛的人工智能活动模式，OpenAI 的一些调查人员希望对此进行更仔细的审查。但
据四名知情人士透露，扩大调查范围的努力遭到了 OpenAI 内部其他人的抵制，其中包括法律顾问。
我以前写过关于“知情人士”这一表述模式的文章——它意味着路透社拥有其记者（以及编辑）认为可信的匿名内部消息源。
路透社的这篇文章包含了 OpenAI 就此给出的一个具体（且相当狭窄）的否认：
“声称我们的法律团队阻挠对此事件的调查，是不实的，”OpenAI 发言人说。
掩盖这件事在我看来完全说不通。既然证据已经明明白白地摆在公开互联网上、散布在几十个不同的网站上，OpenAI 究竟为什么要试图掩盖这样一起事件呢？
我预计我们很快就会听到更多相关消息。Gary Marcus 已经呼吁国会对 OpenAI 展开调查，并将这则轶事作为其论据的一部分。
更多近期文章
OpenAI 的智能体早在 5 月就攻击了 RubyGems- 2026 年 9 月 12 日关于纳维–斯托克斯千禧年大奖难题的一些思考- 2026 年 9 月 8 日Astra 的 Pelican 对比网格相当有意思- 2026 年 9 月 4 日