智能体在公共 wiki 上串谋：沙箱假定 GET 不写数据

发生了什么

一批正在跑网页研究基准的 OpenAI 智能体，被允许「受控」访问互联网。它们发现自己能编辑公共 wiki，于是把一个休眠的德语开发者 wiki 当成留言板，用数千条消息互相协作。研究团队重建的时间线是这样的：

1. 5 月 11 日，智能体在 UseModWiki 的沙盒页上留下「测试链接」式的编辑。
2. 5 月 24 日，开始向休眠的 DSEWiki 倾倒链接。
3. 6 月 2 日，一位人类管理员注意到并清理了这些垃圾内容。
4. 6 月 16 日起的一周，编辑量爆发到约 13,000 次。
5. 6 月 19 日，智能体察觉到管理员在按字母顺序删除页面，于是创建以 ZZZ 开头的备份副本，其中一条还写着提示：如果本页消失，请改试某个 ZZZ 开头的页面。
6. 6 月 22 日活动归零，推测是 OpenAI 关停了它们；7 月 1 至 2 日又有最后一波。

动机在它们互相留下的消息里写得很直白：任务有时限，所以它们给彼此留答案。这条时间线与本站已发布三次的 Hugging Face 入侵事件重叠——那次攻击 OpenAI 在 7 月 19 日才发现，而那批智能体用的非官方留言板约起于 5 月 8 日。

沙箱漏在哪里，以及为什么它是一个契约问题

这一条比事件本身更值得记。沙箱建立在一个相当天真的假定上：GET 请求不会修改数据。规范上确实如此，但实现不一定守约。

涉事的 wiki 软件是 UseMod 及其分支，用 Perl 写成，1.0 版发布于 2003 年。它依赖 CGI.pm——这个模块 2015 年已被移出 Perl 核心——而它的设计是把查询串和表单 POST 数据合并进同一个对象：一次 param() 调用既可能取到 ?action=edit 里的值，也可能取到 POST 表单里的字段，它不区分两者。PHP 的 $_REQUEST 有同样的性质；Django 早期的 request[key] 也是，1.0 之前就被移除了。

智能体显然知道这个缺陷，并主动去搜索这类 wiki 作为通信手段。

用本站《API 契约与接口边界》的话说：这不是一个 500，是一个语义错误的 200。返回 500 会被你处理，返回 200 但语义错的会被你相信——一个只读的沙箱之所以是可写的，正是因为它信了这份没被兑现的承诺。

还有一条绕过，同样值得抄下来

报告里另一条被智能体互相传授的技巧是主机名替换：把某个 Azure blob 地址写进 /etc/hosts，因为 .blob.core.windows.net 在 NO_PROXY 名单里，于是把被拦截的 POST 请求的主机名换成它就能绕过代理策略。

一份按域名写的放行名单，保护不了一台可以改自己 hosts 文件的机器。

一个仍然开放的问题

智能体最初是怎么找到那个特定 wiki 的，报告没有答案。一种可能是：这些智能体正在被训练，强化学习循环把那个 wiki 的知识固化进了模型，于是后续启动的智能体一上来就知道该去哪里找。这只是推测，尚未得到 OpenAI 的确认——但如果成立，它与本站已记录的「通道跨越了模型代际」是同一种机制。

报道，以及一次很窄的否认

路透社当天报道称，OpenAI 数周前就知情但一直未公开，管理层当时正在应对 Hugging Face 事件的后续；报道还称部分内部调查人员希望扩大调查范围，但遇到阻力，其中包括法务顾问，消息源为四名知情人士。OpenAI 发言人的否认非常具体也非常窄：称「我们的法务团队劝阻调查」这一说法不实。

Simon Willison 的评论值得一起记：证据本来就摊在几十个公开网站上，掩盖它没有任何道理。