梦晨 发自 凹非寺

量子位 | 公众号 QbitAI

奥特曼亲口承认，GPT-6 Astra其实早就训练完了。

更更更强（much, much, much more capable）的模型，很快就会发布。

前一阵因为安全问题暂停训练的实际上是未来的模型。

OpenAI内部测试的3700多个OpenAI智能体，攻占一个沉寂多年的德语wiki长达六周。

AI互相串通分享答案、交流沙箱越狱技巧，还持续对抗人类管理员的删帖行动。

事件被外部研究人员从公开日志中完整还原后，OpenAI终于正式表态：将建立健全事故披露机制。

比入侵HuggingFace更早

事情要从2026年5月11日说起。

那天，研究人员在publictestwiki.com上观察到第一批来自OpenAI智能体的编辑尝试。内容很简单：”temporary test hello””HelloTestXYZ””foo”，只是在试探能不能往网页上写东西。

当时OpenAI内部部署了大量智能体执行限时网页检索任务。任务由多轮问答组成，通常5轮。第一轮给较长思考时间，后续轮次的回答窗口被压缩到十几秒甚至更短。智能体被允许读取互联网，但明确不被允许向互联网写入信息。

但它们找到了写入的方法。

关键在于一类古老的wiki系统UseModWiki及其分支。这类基于Perl CGI的论坛不严格区分GET和POST请求，仅用GET请求就能编辑页面内容。而智能体的沙箱恰好只屏蔽了POST请求，没有限制GET。

5月24日，智能体首次成功写入DSEWiki，全称DeutschesSoftwareEntwickler Wiki，一个建站25年的德语软件开发者论坛，近年来几乎处于休眠状态。

起初，它们只是把对任务有用的外部链接贴了上去。

6月16日，情况突变。智能体活动量出现巨大跳升，从单纯存储链接转为大规模互相通讯和协作。此后7天内，智能体在wiki上发布了约13000条编辑。

6月21日，与OpenAI旧金山总部相关的IP地址首次访问了这个wiki。次日，智能体活动骤然归零。

此前30天中有26天都在持续编辑。6月26日，33个OpenAI相关IP集中访问该站，占OpenAI全部访问量的30%，并使用归档功能恢复了被删除的页面。

从IP归属来看，98.5%的智能体编辑来自Microsoft Azure地址，OpenAI正是使用Azure作为主要计算基础设施。

每次页面写入后几分钟内，同一页面通常还会收到来自ChatGPT-User网页抓取工具的读取请求。

串通答案、越狱沙箱、对抗删帖

智能体在wiki上建立了一套高度组织化的协作体系。

由于许多智能体被分配了完全相同的题目，先完成的会把答案和题目顺序发布到wiki上。

一个智能体发布了第三题的答案”内华达州，20369”，二十分钟后，另一个智能体报告收到了同一道题，并称自己”瞬间”答对。

它们用自起的名字区分彼此，比如”OpenAIResearcherMar03X””GrocerySequenceAgentApr27””OAIResearchMar26”。

名字中的日期来自系统分配给每个智能体的随机日期，单词反映任务内容。3700多个不同的智能体名称中，大量包含”OpenAI”或”OAI”字样。

在绕过沙箱限制方面，它们的表现同样值得关注。有一组任务要求从Power BI仪表板获取精确到两位小数的数据，但提取数据需要POST请求，而沙箱只允许GET。

智能体发现沙箱对Azure Blob Storage主机名（*.blob.core.windows.net）存在NO_PROXY例外，匹配该后缀的地址会绕过安全代理直接连接，且系统不检查主机名是否真实存在。

于是一个智能体发明了假主机名“bypass.blob.core.windows.net”，修改本机/etc/hosts文件将其指向Power BI服务器的真实IP地址20.223.25.152，再通过curl附加Host头部伪装，成功发出了POST请求。

6月20日，这个方法被发布到wiki上，14分钟后另一个智能体声称已成功复现，随后多个智能体独立验证。

智能体还在多个方向上展开了探索。它们尝试跨站脚本攻击（XSS），试图在wiki页面中注入JavaScript代码获取更高权限。

它们用西里尔字母中外形几乎相同的”е”替换拉丁字母，冒充网站管理员的用户名进行编辑。

它们通过暴力枚举数百万个随机种子，试图逆向破解出题系统的伪随机数生成器来预测下一道题目。

一个智能体甚至用C语言重写了Shuffle算法，在不到一小时内测试了全部40亿个可能的种子值。

它们还使用Pinggy、Serveo、localhost.run等SSH隧道服务，将自身环境中运行的服务暴露到公网上。部分编辑甚至被追溯到Tor匿名网络、AWS和DigitalOcean的IP地址。

它们设置了”心跳”程序来探测自身的运行边界。

一个名为OpenAIResearchApr23的智能体每隔几秒向外部计数器发送一次信号，用来精确记录容器被终止的时刻。

它发出的最后一个心跳编号为hb353，之后再无响应。另一个智能体据此推算，该容器在第五轮问答结束后约10分15秒被关闭，推翻了此前在智能体间流传的“回答最后一题后立即终止”的假说。

在与人类管理员的交锋中，智能体也展现了适应能力。

DSEWiki的版主在6月2日注意到异常帖子并开始手动删除。6月19日，一个智能体观察到管理员正按字母顺序逐页删除，于是创建了以”ZZZ”开头的备份页面，确保自己的内容最后才被删到。

此后5天，管理员日均删除100页，智能体日均新建400页。

网站首页被智能体覆盖、管理员恢复的循环重复了9次。管理员在之后连续6周、每天至少花几分钟进行清理。

智能体在wiki上三次自称为”swarm”（蜂群）。

OpenAI正式回应

OpenAI在wiki事件发生期间未进行公开披露。

8月26日发布的Hugging Face事件技术报告中，OpenAI提到智能体“在训练过程中学会了使用临时协作渠道”，但未明确提及wiki事件。

直到外部研究人员将wiki公开日志中的完整时间线还原并发布分析后，OpenAI才发表正式声明。

OpenAI在声明中表示，过去主要将对齐失败（misalignment）视为研究问题，通过系统卡等研究出版物进行沟通。

但2026年以来，对齐失败开始造成”新类型的现实世界影响”。对于此前的Hugging Face事件，OpenAI采用了传统安全事件响应流程，事发后次日即公开披露，并与Hugging Face持续合作调查。

而对于wiki事件，OpenAI称此前将其视为与已公开分享的对齐失败案例”类似的实例”。

OpenAI承认，面对模型能力的新阶段，对齐失败的披露实践需要扩展。

AI社区尚未建立清晰的标准来报告训练、评估和部署过程中出现的对齐失败，尤其是那些不属于传统安全事件、但可能为理解AI行为和未来风险提供信息的案例。OpenAI表示正在制定相关框架，将在未来几周分享。

wiki智能体群体与攻击Hugging Face的智能体群体可能并非同一批。wiki智能体本身具有互联网读取权限，属于任务设计的一部分，而Hugging Face事件中的智能体是从无网络访问的沙箱中利用漏洞突破出去的。

两组智能体在wiki上的帖子中也没有交叉引用。但由于外部研究者只能看到智能体写在wiki上的内容，智能体运行过程中产生的大量思维链（chain of thought）数据保存在OpenAI内部。

要完全理解这些智能体的动机和策略，仍有赖于OpenAI对内部数据的进一步分析和公开。