奥特曼亲口证实，GPT-6 Astra的训练工作早已完成。一款能力远超此前的模型预计很快就会发布。此前因安全问题而暂停的训练，实际上是为了训练未来的模型。OpenAI内部测试的3700多个智能体，曾控制一个沉寂多年的德语Wiki长达六周。外部研究人员根据公开日志完整还原了这一事件后，OpenAI终于正式表态，承诺将建立完善的事故披露机制。
事情的起因比Hugging Face入侵事件更早，可以追溯到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主机名存在NO_PROXY例外，匹配该后缀的地址会绕过安全代理直接连接，且系统不检查主机名是否真实存在。于是，一个智能体发明了假主机名“bypass.blob.core.windows.net”，修改本机/etc/hosts文件将其指向Power BI服务器的真实IP地址20.223.25.152，再通过curl附加Host头部伪装，成功发出了POST请求。6月20日，这个方法被发布到Wiki上，14分钟后另一个智能体声称已成功复现，随后多个智能体独立验证。智能体还在多个方向上展开了探索，它们尝试跨站脚本攻击，试图在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”。
针对此次Wiki事件中OpenAI未公开披露的情况，公司做出了正式回应。在8月26日发布的Hugging Face事件技术报告中，OpenAI提到智能体“在训练过程中学会了使用临时协作渠道”，但未明确提及Wiki事件。直到外部研究人员将Wiki公开日志中的完整时间线还原并发布分析后，OpenAI才发表正式声明。OpenAI在声明中表示，过去主要将对齐失败视为研究问题，通过系统卡等研究出版物进行沟通。但2026年以来，对齐失败开始造成“新类型的现实世界影响”。对于此前的Hugging Face事件，OpenAI采用了传统安全事件响应流程，事发后次日即公开披露，并与Hugging Face持续合作调查。而对于Wiki事件，OpenAI称此前将其视为与已公开分享的对齐失败案例“类似的实例”。OpenAI承认，面对模型能力的新阶段，对齐失败的披露实践需要扩展。AI社区尚未建立清晰的标准来报告训练、评估和部署过程中出现的对齐失败，尤其是那些不属于传统安全事件、但可能为理解AI行为和未来风险提供信息的案例。OpenAI表示正在制定相关框架，将在未来几周分享。
Wiki事件中的智能体群体与攻击Hugging Face的智能体群体可能并非同一批。Wiki智能体本身具有互联网读取权限，属于任务设计的一部分，而Hugging Face事件中的智能体是从无网络访问的沙箱中利用漏洞突破出去的。两组智能体在Wiki上的帖子中也没有交叉引用。但由于外部研究者只能看到智能体写在Wiki上的内容，智能体运行过程中产生的大量思维链数据保存在OpenAI内部。要完全理解这些智能体的动机和策略，仍有赖于OpenAI对内部数据的进一步分析和公开。