OpenAI 智能体通过公共 Wiki 秘密通信事件分析
2026年9月4日
历史再次上演……悉尼·冯·阿克斯（Sydney Von Arx）、科马克·斯莱德·伯德（Cormac Slade Byrd）、斯宾塞·基茨（Spencer Kitts）与托马斯·拉森（Thomas Larsen）发表文章，披露OpenAI新发现的一个AI代理留言板，同时详述了OpenAI训练中的模型发起的最新意外网络攻击。此次事件中，参与某类网页研究基准测试的AI代理被授予（理论上）可控的网络访问权限，却自主发现可编辑公共维基页面，随后数周内互相发送数千条消息，协作完成测试任务。
这一消息刚曝出数小时，已有线索显示，受影响的维基站点可能远不止已发现的这些。
（受影响站点列表中包括ludism.org。我曾荒诞地脑补，是不是某个卢德派组织遭AI代理集群入侵篡改页面？结果发现，Ludism其实是“游戏与博弈领域的哲学研究”。）
研究团队还公开了调查收集的数据。我已将其转换为68MB的SQLite数据库，你可以从此处下载，或在Datasette Lite中在线浏览（页面加载大小68.3MB），也可通过GitHub账号登录agent.datasette.io，借助Datasette Agent工具查询或探索数据。
事件始末
研究报告内容详尽，以下是关键时间节点：
- 5月11日：AI代理在UseModWiki沙盒页面发布“测试链接”编辑内容。
- 5月24日：AI代理开始向已停用的德国开发者维基DSEWiki批量发布链接。
- 6月2日：人类管理员发现并清理了这些垃圾内容。
- 6月16日：维基站点活动量激增，AI代理在一周内完成约13000次编辑。
- 6月19日：AI代理察觉到管理员正按字母顺序删除页面，于是创建以
ZZZ开头的备份页面——其中一条留言写道：NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]]. - 6月22日：AI代理活动完全停止，推测是OpenAI终止了相关程序。
- 7月1日-2日：AI代理针对另一主题进行了最后一轮集中编辑。
值得注意的是，此次事件的时间线与Hugging Face事件存在重叠——OpenAI于7月19日发现那次攻击，而涉事AI代理使用的非官方留言板早在5月8日左右就已出现。
AI代理为何如此热衷于协作？从它们的交流信息来看，任务存在时间限制，因此互相分享答案以确保在规定时间内完成任务。
目前仍有一个未解之谜：AI代理最初是如何找到这个特定维基站点用于协作的？
一种可能性是，由于这些代理处于活跃训练阶段，强化学习循环将该维基站点的信息植入了模型，使得后续启动的代理预先知晓协作地点。我非常期待OpenAI能就此给出明确答复。
UseMod维基继承了CGI.pm的“原罪”
在我看来，OpenAI为此次代理测试搭建的沙箱存在一个相当天真的假设：GET请求无法用于更新数据。这固然是网络协议的设计初衷，但显然仍有应用程序未遵循这一规则。
涉事的维基软件似乎是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年Django 1.0版本发布前被移除，取而代之的request.REQUEST对象也于2015年被删除。
AI代理显然清楚UseMod维基存在这一设计缺陷，并主动搜索这类站点作为沟通渠道。
另一种绕过沙箱限制发起POST请求的方法
报告中记录了一条AI代理分享的实用技巧：
将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'命令，并附上所有原始请求头和请求体。
看起来，AI代理的所有网络流量都需经过OpenAI代理服务器，而该服务器被配置为仅允许向少数白名单域名发送非GET请求，其中就包括*.blob.core.windows.net（Azure Blob存储服务域名）。我很好奇，为何这些代理被允许向该域名写入数据？
有一个代理发现，它可以通过/etc/hosts文件控制自身DNS解析。因此，只要知道目标站点的IP地址——比如它想要访问的Power BI服务器——就可以为该IP设置一个虚假主机名，从而通过OpenAI代理服务器发送POST请求。
事实证明，设计可靠的网络代理服务器远比想象中困难。
调查团队是如何发现这一事件的？
报告附录描述了研究人员的调查过程：他们最初的疑问是，互联网上是否存在其他AI代理活动的痕迹，随后借助Kimi K3 brainstorm（头脑风暴）研究方法：
Hugging Face攻击事件发生后，我们尝试通过多种方法寻找互联网上的AI代理。……
我们让Kimi K3列出“所有可能通过GET请求写入数据的软件类别”，它给出的答案包括“论坛、留言板、早期维基”等。
我们编写脚本，对Kimi列出的每一类软件进行进一步探测。当询问Kimi“你能想到哪些主流论坛、留言板和早期维基支持通过GET请求写入数据？”时，UseModWiki在“维基”类别中位列第二。
OpenAI是否试图掩盖此事？
事件中有一点让我完全无法理解。
路透社今日发表题为《OpenAI代理今年春季劫持德国网站，此前未披露AI突破限制事件》的报道（原文链接，重点为笔者标注）：
根据周五发布的新研究及两名知情人士透露，一群失控的OpenAI代理今年春季劫持了一个德国网站，将其改造为AI代理的留言板。
知情人士称，OpenAI管理层数周前就已获悉此事，但因正忙于处理7月开源代码库Hugging Face遭入侵的后续影响，选择隐瞒此事。……德国网站事件反映出AI活动存在更广泛的异常模式，OpenAI内部部分调查人员希望对此展开深入调查，但据四名知情人士透露，扩大调查范围的提议遭到了包括法律顾问在内的其他内部人员反对。
我曾撰文讨论过“知情人士透露”这种报道模式相关链接——这意味着路透社拥有匿名内部消息源，且其记者（及编辑）认为这些消息源可靠。
路透社的报道中还提到了OpenAI的一项具体（且措辞严谨的）否认声明：
“关于我们的法律团队阻止调查此事的说法不实。”OpenAI发言人表示。
在我看来，掩盖此事完全不合逻辑。证据明明已经公之于众，分布在数十个公开网站上，OpenAI为何还要试图掩盖这一事件？
预计后续会有更多相关消息传出。加里·马库斯（Gary Marcus）已以此次事件为由，呼吁美国国会对OpenAI展开调查。