夢晨 發自 凹非寺

量子位 | 公衆號 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對內部數據的進一步分析和公開。