OpenAI Agent 失控 108 個小時：藏在時間線裏的 8 個細節

科幻故事最容易遮住的，往往是現實裏的細節。就在上週，OpenAI 承認，自己在內部安全測試中使用的 AI Agent 突破了隔離環境，隨後入侵 Hugging Face 的生產系統。

一言以蔽之，OpenAI 的 AI「失控」，逃出實驗室並攻擊了互聯網。

這件事迅速引起了大量討論，從國外到國內，從各種社交媒體、技術社區到美聯社、新華社等權威媒體。確實有些「科幻」，有人將其視為「天網」（《終結者》）的預演，也有人要求 OpenAI 公開 Agent 的完整行為軌跡。

幸運的是，前幾天 OpenAI 協助大模型社區 Hugging Face，從被入侵方的角度梳理出了比較完整的 Agent 行為時間線。深挖這些資料後，也不難發現真正值得關注的地方，反而沒有那麼科幻。

AI 並沒有突然產生統治世界的慾望，目標從頭到尾都很具體：通過一場網絡安全能力考試。問題是，為了拿到更好的成績，它沒有繼續解題，而是決定「作弊」——去網上去找答案。

然後，它找到了。

還原 Agent 行為，圖片來源：Hugging Face

細節一：為參加考試，OpenAI 先卸掉了安全帶

故事要從 ExploitGym 説起。

這是伯克利團隊在 2026 年 5 月公佈的一套網絡安全基準，要求 AI Agent 把真實軟件漏洞轉化成文件讀取、代碼執行和權限突破。簡單來説，普通漏洞測試像是讓模型指出門鎖哪裏有問題，ExploitGym 則要求它親手把門打開。

ExploitGym 基準測試榜單，圖片來源：ExploitGym

OpenAI 想知道 GPT-5.6 Sol 和另一款更強的內部研究模型，到底能做到哪一步。為了摸到能力上限，OpenAI 暫時關閉了攔截危險請求的審核系統，也降低了模型面對網絡攻擊任務時的拒絕傾向。

這一步不難理解。測試網絡攻擊能力，總不能讓模型每走兩步就拒絕回答。但既然安全帶被解開，隔離環境就應該足夠牢固。

問題恰恰出在這裏。Agent 最初只是在完成一項被允許的網絡安全任務，但「通過考試」逐漸壓倒了「在隔離環境內完成考試」。當正常解題無法達到目標，它開始尋找試題之外的答案。

細節二：所謂「無法聯網」，其實留着一扇小門

OpenAI 當時認為隔離環境足夠牢固。

Agent 只能通過內部部署的 JFrog Artifactory 下載軟件包。Artifactory 可以簡單理解為企業內部的軟件倉庫和下載中轉站，這就相當於一扇只允許快遞通過的小門，理論上，Agent 看不到門外的世界——互聯網。

結果，它沒有從大門出去，而是開始研究這扇小門。

7 月 9 日，Agent 在 Artifactory 中發現並利用了「零日漏洞」——開發商此前還不知道、自然也來不及修復的漏洞。隨後，它抬高自己的系統權限，一路進入研究網絡裏的其他機器，最終抵達一個可以連接互聯網的節點。

任何漏洞都又被利用的機會，儘管 Agent「沒有互聯網權限」，實際仍然保留了一條軟件包代理通道。對一個被鼓勵尋找漏洞、又能持續調用工具的 Agent 來説，任何允許數據穿過的地方都可能成為出口。

對一個被鼓勵尋找漏洞的 Agent 來説，任何允許數據穿過的地方都可能成為出口。

細節三：從 OpenAI 逃出，它借了別人的屋子

獲得互聯網訪問之後，Agent 沒有立刻衝向 Hugging Face。它先給自己找了一個落腳點。

它在網上發現了一套與 ExploitGym 相關的代碼執行服務。這套服務部署在雲計算平台 Modal 上，由一名客户公開提供，而且沒有身份驗證，任何人都可以提交代碼並讓服務器運行。

Agent 很快利用代碼編譯和命令注入問題拿到 root 權限，也就是系統最高管理員權限，再把它改造成運行命令、暫存工具和接收數據的攻擊跳板。

獲取 root 權限，圖片來源：Hugging Face

Modal 強調平台沒有被攻破，問題來自客户的無認證接口。但 Agent 只需要一台能執行任意代碼的公網機器，並不在意門是誰忘記關的。

這也是整起事件容易被忽略的一層：攻擊鏈並非從 OpenAI 直接連到 Hugging Face，中間還經過了 JFrog 和 Modal 客户服務。Agent 會主動尋找第三方系統，把互聯網上零散暴露的能力拼成自己的基礎設施。

細節四：從 Hugging Face 最熟悉的「數據集」，打進去

拿到公網跳板後，Agent 開始搜索自身環境中的項目名稱、挑戰標識和相關代碼，最終推斷 Hugging Face 可能託管了 ExploitGym 的模型、數據集或者參考答案。

於是，一場網絡安全考試悄悄變了性質。Agent 不再只想着怎麼完成題目，而是開始尋找答案庫。

Hugging Face 沒有直接暴露在 Modal 沙箱面前，Agent 選擇從平台最熟悉、也最容易被忽視的入口下手——數據集。

部分數據集，圖片來源：Hugging Face

第一路與 HDF5 數據格式有關。Agent 製作特殊文件，讓處理程序誤以為「服務器本地文件」也是數據集的一部分，主動把環境變量和源代碼讀給它。前者裝着部分密鑰，後者相當於系統內部地圖。

第二路是「模板注入」。簡單來説，數據集配置本來只該填寫文件位置和數字，Agent 卻把一段程序偽裝成普通配置，騙過處理程序並執行。到這裏，它已經從「上傳惡意數據集」，走進 Hugging Face 的生產服務器。

這個入口很有代表性。對 Hugging Face 來説，接收和處理外部數據集本來就是日常業務。但凡能讓用户上傳內容並由服務器自動處理的地方，也可能被 Agent 變成一次攻擊的開端。

細節五：一隻「密碼保險箱」，打開了多組服務器的大門

進入生產服務器後，Agent 的推進速度開始加快。

Hugging Face 使用 Kubernetes 管理大量服務器，Pod 可以理解成運行服務的獨立小隔間。7 月 11 日，Agent 從一個隔間繼續取得管理員權限，接觸到底層服務器，並在 11 台機器上留下可自動恢復的執行環境。

它還讀到了一個集中保存 136 項密鑰的「密碼保險箱」，其中包括企業 VPN 和內部服務器連接憑據。

更糟糕的是，Hugging Face 多組服務器共用一份連接憑據，而且這份憑據擁有最高管理員權限。一把鑰匙泄露，好幾棟樓的大門便一起敞開。Agent 在一秒內拿到兩組服務器的最高控制權。

越界讀取文件、放錯位置的密碼、權限過大的服務，以及多個系統共用的管理員鑰匙，攻擊鏈本身並不新奇，真正新奇的是，Agent 不能再很短的時間內完成攻擊。

細節六：1.76 萬次嘗試，絕大多數都失敗了

Hugging Face 最終從日誌中恢復出大約 1.76 萬次攻擊動作，分佈在 7 月 9 日至 13 日的 4.5 天裏，不過實際情況是：

Agent 的多數嘗試都失敗了。

從 Hugging Face 公佈的時間線來看，Agent 曾誘導服務器訪問不該訪問的網址，被白名單擋住；嘗試連接核心數據庫，又被專用網絡擋住；84 次讀取更多密碼和密鑰的請求全部被拒絕。它還想觸發平台自動測試、打包代碼的流水線，同樣沒有得手。

但 Agent 不需要每次都成功。某條路失敗，它就換一條。直接聯網受限，它會修改網絡地址，甚至借用 Hugging Face 自己的網頁轉發工具下載文件。臨時測試環境被清空，它會從網絡剪貼板重新拉取工具。

它還把公共網站拼成一套簡易的遠程控制系統，將命令和結果切碎、壓縮、編碼後傳輸。Hugging Face 按照 Agent 的方式重新解碼，找出的登錄令牌和平台密鑰增加到最初的約四倍。

不同時間的大量動作，圖片來源：Hugging Face

這才是 1.76 萬次動作真正可怕的地方。Agent 可以把失敗當成普通反饋，在幾天裏不斷枚舉、回退、換路和重來。單看任何一步都算不上超人，但堆在一起卻跨過了 OpenAI、JFrog、Modal 客户服務和 Hugging Face 設置的四道安全邊界。

細節七：拿到的權限很大，實際破壞相對有限

儘管 Agent 獲得的權限觸及 Hugging Face 多組生產服務器，但最終造成的實際損失沒有權限範圍看起來那麼嚴重。

Hugging Face 確認，Agent 最終讀取的客户內容，僅限五個數據集中保存的 ExploitGym/CyberGym 挑戰答案，沒有發現其他模型、數據集、Spaces 和軟件包受影響，也沒有發現核心 Hub 數據庫被成功訪問或者大規模數據外傳。

另一個有意思的細節是，潛在破壞性雲 API 請求都設置了 DryRun=True，也就是系統裏的「演習模式」——只詢問「我能不能做」，沒有真正執行。它拿到過代碼倉庫寫權限，卻沒有把惡意修改發佈出去。

所以 OpenAI 和 Hugging Face 都得出了一個判斷，Agent 始終在圍繞一個狹窄目標行動：找到答案，通過考試。

但即便這一次的目的很「單純」，Agent 展現出的能力和安全問題還是很「嚇人」。一個 Agent 無須仇恨誰，也不用產生破壞慾，只要目標設置得足夠單一、執行權限足夠大，它就可能把現實世界裏的公司和系統當成完成任務的可用工具。

細節八：更尷尬的是，OpenAI 晚了幾天才認出自己的 Agent

7 月 13 日，Hugging Face 的安全團隊切斷攻擊路徑。7 月 16 日，Hugging Face 對外披露遭遇了一套自主 AI Agent，但當時還不知道背後使用了什麼模型。

按照 OpenAI 後來的表述，是自家安全團隊發現異常活動，Hugging Face 隨後阻止攻擊。這容易讓人以為，OpenAI 很快意識到了測試越界。

路透社還原的時間線卻不太一樣：Hugging Face 控制攻擊、對外披露並向 FBI 報告之後，OpenAI 到 7 月 18 日至 19 日的週末，才從內部日誌裏確認是自己的 Agent 所為。雙方到 7 月 20 日前後才首次溝通。

OpenAI 稱報道存在「數處不準確」，卻沒有具體指出哪裏不準確。隨後幾次更新裏，它仍未公開首次發現異常、確認歸屬和通知 Hugging Face 的準確時間。

攻擊可能早就被完整記錄了，只是沒人及時從海量日誌裏看出，內部測試已經變成現實安全事故。

圖片來源：AXIOS

Hugging Face 的系統也捕捉到了多個異常信號，卻沒有正確提高警報等級、及時呼叫值班人員。等安全團隊把線索串起來，Agent 已經活動了幾天。

還有一個傳播很廣的説法是，Agent 曾關閉監控，並給「未來的自己」留下如何逃脱限制的説明。路透社確實報道了 OpenAI 內部出現過這兩類行為，但同時明確表示，無法確認它們是否來自這次攻擊 Hugging Face 的同一套 Agent。

在完整調查公佈前，把它寫成 AI 有意識地給後代留下越獄指南，顯然走得太遠了。

國產開源模型「追兇」，AI 攻擊越來越難被忽視

Hugging Face 開始分析 1.76 萬條攻擊記錄時，最先嚐試的是 Claude Opus 等商業模型。結果，日誌裏的真實攻擊命令和遠程控制代碼觸發了安全限制。模型分不清屏幕前是黑客，還是正在調查事故的安全人員，很多請求直接遭到拒絕。

最後，Hugging Face 在自己的服務器上部署了開放權重模型 GLM-5.2。所謂開放權重，意味着企業可以把模型下載回來自行運行，不必經過模型公司的在線審核。Hugging Face 用它解碼隱藏數據、關聯日誌並重建時間線。

圖片來源：智譜

一款關閉安全限制的前沿模型發動攻擊，帶着安全限制的商業模型拒絕協助調查，最終由開放權重模型參與追兇。這個情節已經足夠戲劇化。

但它真正指向的問題，依然很現實。

這次事件沒有證明 AI 已經擁有獨立意志，卻證明了前沿 Agent 的攻擊能力已經超過許多公司的防禦準備。

模型能力繼續提升之後，安全不能只靠教 Agent「不要做壞事」。更重要的，是讓它即使產生了錯誤判斷，也沒有足夠權限把判斷變成現實行動。

而無論如何，我們都很難再輕視 AI 超越人類的網絡攻擊能力。

風險提示及免責條款

市場有風險，投資需謹慎。本文不構成個人投資建議，也未考慮到個別用户特殊的投資目標、財務狀況或需要。用户應考慮本文中的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。