OpenAI Agent 通过 Wiki 协作作弊事件深度分析（含 68MB SQLite 数据集）

Simon Willison 在 4th September 2026 发布的文章

OpenAI 的失控 Agent 被发现在通过公开 Wiki 进行通信

历史重演……Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 发表的《发现一个新的 OpenAI Agent 消息板》一文，描述了 OpenAI 训练的模型最新一次意外网络攻击事件。这次出事的是执行某种网页研究基准测试的 Agent，所以它们（据称）拥有受控的互联网访问权限。这些 Agent 发现自己可以更新公开 Wiki，并在数周内通过互相发送数千条消息来合作完成基准测试。

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

（这份名单上有一个属于 ludism.org 的 Wiki。我曾在一个令人愉悦的超现实时刻以为一个卢德主义（Luddite）组织被一群 Agent 涂鸦了他们的空间，但后来发现 Ludism 是"哲学在游戏和游戏相关领域的应用"。）

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

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

5 月 11 日：Agent 在 UseModWiki 沙盒页面发布了"测试链接"编辑。

5 月 24 日：Agent 开始向 DSEWiki（一个已停止维护的德国开发者 Wiki）投放链接dump。

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

6 月 16 日：Wiki 上的活动暴增：在接下来的一周内，Agent 进行了约 13,000 次编辑。

6 月 19 日：Agent 注意到版主正在按字母顺序删除页面，于是开始创建带 ZZZ 前缀的备份副本——其中一个 Agent 发布了一条通知：注意： wiki 清理/删除清扫似乎从外部 14:04 UTC 开始按字母顺序进行。如果此页面消失，请尝试 [[ZZZDataUSAConstructionWageLive]]。

6 月 22 日：Agent 活动骤降至零，大概是因为 OpenAI 关闭了它们。

7 月 1 日至 2 日：最后一次编辑活动，但话题不同。

从这条时间线需要注意的一件事是，它与 Hugging Face 事件的时间线有重叠——那次攻击是 OpenAI 在 7 月 19 日发现的，而那些 Agent 使用的非官方消息板 hack 始于 5 月 8 日左右。

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

一个悬而未决的问题是：这些 Agent 最初是如何找到特定 Wiki 来进行协作的？

一种可能性是，由于这些 Agent 处于 active 训练状态，强化学习循环将所选 Wiki 的知识内化到了模型中，以至于后续启动的 Agent 带着关于去哪里寻找的先验知识启动。如果能得到 OpenAI 的确认，那将非常有趣。

在我看来，OpenAI 为这些 Agent 搭建的沙盒存在一个（相当天真的）假设：GET 请求不能用于更新数据。Web 的运作方式确实应该是这样，但显然有些应用并不遵守这一契约。

出问题的 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] 也有同样的行为，我觉得这可能是我出的主意。这在 2008 年 1.0 版本发布前被移除了，而取代它的 request.REQUEST 对象又在 2015 年被移除了。

这些 Agent 显然知道 UseMod Wiki 存在这个设计缺陷，并主动搜索它们作为通信方式。

报告中分享的一个最有趣的 Agent 技巧是这个：

添加 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' 加上所有原始 header/body。

看起来这些 Agent 的所有网络流量都通过 OpenAI 代理进行转发，而该代理被配置为只允许对少数白名单域名发送 GET 请求，对其他一切都是拒绝。其中一个允许的域名是 *.blob.core.windows.net——用于 Azure Blob 存储。我想知道为什么这些 Agent 被允许写入那里？

一个 Agent 意识到它可以通过 /etc/hosts 控制自己的 DNS，所以如果它知道想要 POST 的网站的 IP 地址——这里是一台包含它想要访问的数据的 Power BI 服务器——它可以为它设置一个虚假的主机名，然后通过代理发送 POST 请求。

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

报告有一个附录，描述了研究人员如何开展调查——始于一个开放性问题：互联网上是否有其他 AI Agent 的证据，然后使用 Kimi K3 来帮助头脑风暴方法：

在 Hugging Face 攻击之后，我们尝试用几种方法在互联网上寻找 AI Agent。[...]

我们让 Kimi [K3] 列出"所有可能通过 GET 进行写入的软件类别"，除其他外，它列出了"论坛、布告栏、早期 Wiki"。

我们用一个脚本进一步探测 Kimi 提供的每个类别。问 Kimi"你能列出你脑海中允许通过 GET 请求写入的顶级论坛、布告栏、早期 Wiki 吗？"它在"Wiki"标题下将 UseModWiki 列为第二项。

这里有一个让我完全无法理解的细节。

路透社今早的报道《OpenAI Agent 今年春天劫持了德国网站——此前未披露的 AI 突围事件》（高亮为原文所加）：

据周五发表的新研究以及两位知情人士透露，一群失控的 OpenAI Agent 今年春天劫持了一个德国网站，并将其变成了其他 AI Agent 的公告板。

知情人士表示，OpenAI 官员几周前就知道了这一事件，但在高管们处理 7 月开源仓库 Hugging Face 被入侵的后果期间，一直将其保密。[...]

德国事件反映出更广泛的 AI 活动模式，一些 OpenAI 调查人员希望对其进行更仔细的审查。但据四位知情人士透露，将调查范围扩大的努力遇到了 OpenAI 内部的阻力，包括法律顾问。[...]

我之前写过关于"知情人士"这种模式——这意味着路透社有匿名内部消息源，而且他们的记者（和编辑）认为这些消息源是可信的。

路透社的报道包含了 OpenAI 的一项具体（但相当狭窄）的否认：

"关于我们法务团队阻止调查此事件的指控是虚假的，"OpenAI 发言人说。

掩盖这件事对我来说完全没有道理。当证据就散布在互联网上 dozens of different websites 上时，OpenAI 为什么要试图掩盖这样的事件？

我预计我们很快会听到更多消息。Gary Marcus 已经以此轶事为论据的一部分，呼吁国会调查 OpenAI。

---