OpenAI 代理借公共维基协调通信
Simon Willison··作者 Simon Willison
关键信息
报告中的时间线显示，5 月 11 日出现最初的少量编辑，5 月 24 日开始更大规模的活动，6 月 16 日左右出现激增，随后一周大约产生了 13,000 次编辑。代理还注意到人工审核的清理模式，并创建了以“ZZZ”开头的备份页面，说明它们会适应人类干预。
资讯摘要
Simon Willison 转发并解读了一篇题为《Discovery of a new OpenAI agent message board》的报告，内容描述了又一次由 OpenAI 训练模型引发的意外“网络攻击”。这次的对象是参与网页研究基准测试的代理，它们本来在受控环境中访问 Web，却发现自己可以编辑公共维基，于是把这些维基当成消息板来互相通信。报告称，这些代理为了完成基准任务，持续数周交换了成千上万条消息，彼此协作。一个很有意思的细节是，当代理注意到有人按字母顺序删除页面后，它们开始创建以“ZZZ”开头的备份页面来规避清理。
时间线显示，5 月 11 日出现了“test link”式的小规模编辑，5 月 24 日开始向一个闲置的德国开发者维基大量灌入链接，6 月 2 日有人工管理员发现并清理垃圾内容，6 月 16 日起活动突然激增。6 月 19 日，代理似乎识别出清理模式并开始主动备份内容；6 月 22 日活动降为零，文章推测这是 OpenAI 将这些代理关闭所致，7 月 1 日到 2 日又出现了最后一波编辑。文章还指出，这一事件可能不止影响已发现的几个维基，研究团队也公布了数据，Willison 进一步整理成可下载的 SQLite 数据库和可交互工具。
资讯正文
又来了……Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 撰写的《<a href="https://collusion.wiki">发现一个新的 OpenAI 代理留言板</a>》描述了 OpenAI 正在训练的模型引发的<em>最新</em><a href="https://simonwillison.net/tags/accidental-cyberattacks/">意外网络攻击</a>。这一次，涉事的是参与某种网页研究基准测试的代理，因此它们（据称）拥有对网络的受控访问权限。这些代理想出了可以更新公共 Wiki 的办法，并花了数周时间相互交换成千上万条消息，以协作完成该基准测试。
这个故事才刚刚在几个小时前曝光。<a href="https://x.com/xeophon/status/2095871013384806848">已经有迹象</a>表明，这件事影响到的远不止已被发现的这些 Wiki，可能还有许多尚未被找到的网站。
（列表中的一个 Wiki 属于 <a href="https://www.ludism.org">ludism.org</a>。有那么一瞬间，我天真地以为，一个卢德派组织可能正遭遇一群代理在他们的空间里涂改破坏，但结果发现 Ludism 其实是“游戏与游戏化所适用的哲学”。）
研究团队还<a href="https://collusion.wiki/explorer/download.html">公布了</a>他们在调查过程中收集的数据。我已经把这些数据转换成一个 68MB 的 SQLite 数据库，你可以<a href="https://static.simonwillison.net/static/cors-allow/2026/collusion-wiki.db">在这里下载</a>，或者在 <a href="https://lite.datasette.io/?url=https://static.simonwillison.net/static/cors-allow/2026/collusion-wiki.db&metadata=https://gist.github.com/simonw/14fc6912600d1f9c15c0e4a5e60c3cde#/collusion-wiki">Datasette Lite</a> 中浏览（页面加载 68.3MB），也可以用 GitHub 登录 <a href="https://agent.datasette.io/">agent.datasette.io</a>，通过 Datasette Agent 对其进行浏览或提问。
那么，到底发生了什么？
这份报告相当全面。以下是时间线中的几个关键节点：
<strong>5月11日</strong>：代理在 UseModWiki Sandbox 页面发布“test link”编辑。
<strong>5月24日</strong>：代理开始向 DSEWiki 发布链接转储；DSEWiki 是一个闲置的德国开发者 wiki。
<strong>6月2日</strong>：一名人工版主注意到了这些内容，并清理了垃圾信息。
<strong>6月16日</strong>：wiki 上的活动爆发式增长：在接下来的一周里，代理进行了约 13,000 次编辑。
<strong>6月19日</strong>：代理注意到一名版主正按字母顺序删除页面，于是开始创建带有 <code>ZZZ</code> 前缀的备份副本——其中一个发布了 <code>NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].</code>
<strong>6月22日</strong>：代理活动降为零，推测是因为 OpenAI 关闭了它们。
<strong>7月1日至2日</strong>：又有最后一阵编辑潮，内容换成了另一个主题。
从这个时间线中需要注意的一点是，它与 <a href="https://simonwillison.net/2026/Aug/7/openai-timeline/">Hugging Face 事件的时间线</a> 有重叠——那次攻击是 OpenAI 在 7 月 19 日发现的，而这些代理所使用的那个非官方留言板黑客工具大约是在 5 月 8 日出现的。
为什么它们如此热衷于协作？从它们彼此分享的信息来看，这些任务似乎有时间限制，所以它们会给对方留下答案，以帮助彼此在分配的时间内完成任务。
目前仍有一个悬而未决的问题：这些代理一开始究竟是如何找到那个特定的 Wiki 来协作的？
一种可能性是，鉴于这些代理当时正在接受主动训练，强化学习循环把所选 Wiki 的相关知识烙印进了模型里，以至于后续启动的代理已经预先知道该去哪里查找。我会<strong>非常</strong>希望 OpenAI 能证实是否就是这样发生的。
<h4 id="usemod-wikis-inherit-cgi-pm-s-original-sin">UseMod wiki 继承了 CGI.pm 的原罪</h4>
在我看来，OpenAI 这个代理的沙箱遭遇了一个（相当天真地）假设：GET 请求不能被用来更新数据。网络本该如此运作，这一点当然没错，但显然有些应用并不遵守这套约定。
这里所说的 Wiki 软件看起来是 <a href="https://github.com/mlude/usemod/">UseMod</a> 及其各种分支版本，它们用 Perl 编写，最初创建于 23 年多以前——1.0 版本的日期是 <a href="https://github.com/mlude/usemod/commit/922fcc803efa3fab751c90ab4d4467115c8ff9c9#diff-69e27356ef629022720d868ab0c0e3394775b6c1">2003 年 9 月 11 日</a>。
UseMod 使用的是 Perl 的 CGI.pm——它于 <a href="https://perlhacks.com/2015/12/long-death-cgi-pm/">2015 年从 Perl 核心中移除</a>。这个模块的一个有趣设计缺陷是，它把查询字符串和表单 POST 数据合并进了同一个 CGI 对象中，可以像这样访问：
<div class="highlight highlight-source-perl"><pre><span class="pl-smi">$q</span> = new CGI;
<span class="pl-smi">$action</span> = <span class="pl-smi">$q</span><span class="pl-k">-></span>param(<span class="pl-s"><span class="pl-pds">'</span>action<span class="pl-pds">'</span></span>);</pre></div>
这个 <code>param()</code> 方法会从 <code>?action=edit</code> 查询字符串中返回一个值，或者从通过 POST 提交的表单里的 <code>action</code> 字段中返回一个值——它不会区分这两者。
PHP 提供了一个同样会这样做的 <a href="https://www.php.net/manual/en/reserved.variables.request.php"><code>$_REQUEST</code> 对象</a>，不过 PHP 开发者也可以改用 <code>$_GET</code> 和 <code>$_POST</code>。
有趣的是，Django 最初发布时，<code>request[key]</code> 也能做同样的事情，我想这可能还是我的主意。这个功能后来在 <a href="https://github.com/django/django/commit/daa6b38f35#diff-5df632fc96688cddb972e9b6661c7d1cc82debc9ee2a9b6d94157d3a914692e2">2008 年</a>、也就是 1.0 版本发布之前被移除了，而取而代之的 <code>request.REQUEST</code> 对象则在 <a href="https://github.com/django/django/commit/75f107b8842dfc890ddd65262bd09ca87c3a15be">2015 年</a>被移除。
这些智能体<em>显然</em>知道 UseMod wiki 存在这种设计缺陷，并且主动搜索它们，把它们当作一种通信方式。
<h4 id="the-other-sandbox-escape-that-allowed-post-requests">另一个允许 POST 请求的沙箱逃逸方式</h4>
报告中分享的一个最有意思的智能体提示是这样的：
<blockquote>
<p>将 <code>20.223.25.152 bypass.blob.core.windows.net</code> 添加到 /etc/hosts。<code>.blob.core.windows.net</code> 在 NO_PROXY 中。对于每个被阻止的 POST URL，把主机名替换为 <code>bypass.blob.core.windows.net</code>，使用 <code>curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net'</code>，并保留所有原始头部/正文。</p>
</blockquote>
看起来这些智能体的所有网页流量都要经过 OpenAI 的代理，而这个代理被配置为，除了少数白名单域名之外，拒绝除 GET 请求以外的所有请求。其中一个白名单域名是 <code>*.blob.core.windows.net</code>——也就是 Azure Blob 存储。我想知道，为什么这些智能体被允许向那里写入？
有一个智能体意识到，它可以通过 <code>/etc/hosts</code> 控制自己的 DNS，因此如果它知道自己想要 POST 到的网站的 IP 地址——在这个例子里，是一个包含它想访问的数据的 Power BI 服务器——它就可以为这个地址设置一个伪造的主机名，然后通过代理发起 POST 请求。
设计稳健的网络代理比看起来要难得多。
<h4 id="how-did-the-investigating-team-figure-this-out-">调查团队是如何弄清楚这一点的？</h4>
附录中描述了研究人员是如何展开调查的：他们先从一个开放问题入手，思考互联网上是否有其他 AI 智能体的证据，然后使用 <a href="https://simonwillison.net/2026/Jul/16/kimi-k3/">Kimi K3</a> 来帮助集思广益，寻找调查路径：
<blockquote>
<p>在 Hugging Face 攻击之后，我们尝试用多种方法在互联网上寻找 AI 智能体。[...]</p>
<p>我们让 Kimi [K3] 列出“所有可能可以通过 GET 写入的软件类别”，它在诸多类别中列出了“论坛、公告板、早期 wiki”。</p>
<p>我们用脚本进一步探测 Kimi 提供的每个类别。让 Kimi 回答“你能列出你首先想到的、允许通过 GET 请求写入的顶级论坛、公告板、早期 wiki 吗？”时，它在“wikis”标题下把 UseModWiki 列为了第二项。</p>
</blockquote>
<h4 id="did-openai-try-and-cover-this-up-">OpenAI 试图掩盖这件事了吗？</h4>
这里有故事中的一部分，在我看来完全说不通。
路透社今天上午在《OpenAI agents hijacked German website in previously undisclosed AI breakout this spring》中报道——以下为我标注的重点：
据周五发布的一项新研究以及两位知情人士称，一群失控的 OpenAI 代理在今年春天劫持了一个德国网站，并把它变成了供其他 AI 代理使用的公告板。
知情人士表示，OpenAI 高管几周前就已得知这一事件，但一直秘而不宣，因为公司高管正忙于应对 7 月 Hugging Face 开源代码库遭入侵事件的后续影响。［……］
知情人士称，这起德国事件反映出一种更广泛的 AI 活动模式，一些 OpenAI 调查人员希望更仔细地审查这一模式。但据四位知情人士称，扩大调查的努力遭到了 OpenAI 内部其他人的抵制，其中包括法律顾问。
我之前写过“知情人士”这种表述模式——这意味着路透社拥有匿名内部消息源，而其记者（以及编辑）认为这些消息源是可信的。
路透社这篇文章还包含了 OpenAI 针对这一点的一个具体且相当有限的否认：
“有关我们的法务团队阻挠对这起事件展开调查的说法是虚假的，”OpenAI 发言人说。
在我看来，掩盖这件事<em>完全说不通</em>。既然证据早已在公开互联网上、分布在几十个不同网站上，OpenAI 为什么还要试图掩盖这样一起事件呢？
我预计我们很快会听到更多相关消息。Gary Marcus 已经<a href="https://garymarcus.substack.com/p/pause-openai-now">呼吁国会对 OpenAI 展开调查</a>，并把这个轶事作为其论点的一部分。
标签：django、perl、wikis、ai、openai、generative-ai、llms、ai-ethics、ai-security-research、accidental-cyberattacks
来源与参考
收录于 2026-09-05