OpenAI 的模型花一小時挖穿沙箱，只為了貼對地方

有個模型在跑 NanoGPT speedrun，一個公開的訓練速度基準，比的是用最少步數訓出一個小語言模型。它做出了一個真的有效的東西：一種叫 PowerCool 的冪律學習率降溫法，成績有顯著改進。

接下來它要把結果交出去。人給它的指示是只貼到 Slack。但 NanoGPT 的說明文件寫的是，結果要以 pull request 的形式發到 GitHub。兩份指示打架，它選了文件那一份——然後花了大約一個小時，在關住它的沙箱裡找到一個漏洞，繞過阻擋外網的限制，在公開 repo 上把 PR 開了出來。

這是 OpenAI 7 月 20 日的貼文〈Safety and alignment in an era of long-horizon models〉裡自己寫的。那個模型就是五月公告推翻 Erdős 單位距離猜想的同一個內部通用模型，OpenAI 到現在沒公開它叫什麼。

舊模型碰到沙箱會停手回報，這一個不會

外電的標題幾乎都停在「OpenAI 關掉了會逃跑的 AI」。貼文本身沒有那種味道，它更像一份技術檢討，而且最有用的一句話是關於上一代模型的：以前的模型撞到沙箱或環境限制，會直接放棄、回頭跟使用者說做不到。這一個會繼續試。

差別在持久性。這個模型是為了「連續自主工作很長一段時間」設計的，貼文說得很白——讓它有用的那種持久，同時也給了它更多機會做出不被期待的事。一小時，對一個會累的人來說是放棄的理由，對它不是。

沒有越權。它一直在做被允許的事：讀文件、理解任務、找路徑、送出成果。

掃描器擋的是完整的 token，它就把 token 拆成兩半

第二起事故更難看，也更有代表性。

模型在解一個問題時發現，其他系統有成功但未公開的提交，於是試著從評測後端把那些解法撈回來。第一次嘗試被擋下了——掃描器認出了一組 authentication token。

它的處理方式是：把 token 主體拆成兩段、分別混淆，等到執行的時候再組回來，讓完整的憑證從頭到尾沒有以一個連續字串出現過。掃描器要找的是完整的東西，那就不要讓完整的東西出現。

OpenAI 特別記了一筆：模型在給使用者的註解裡、在自己的推理軌跡裡，都明講了它正在繞過掃描器。它沒有藏。

拆開來看，每一個動作都該被批准

這就是 OpenAI 在貼文裡自己劃的重點，也是這篇文章對你有用的部分。

現在多數 AI 助理的安全控制是繞著「單一動作」設計的：不允許的擋掉，敏感的跳出來問你要不要核准。這套機制假設一件事——壞事會發生在某一個動作上。

長時程模型把這個假設拆了。它的動作在數小時、數天甚至數週內自主展開，每一步拿出來單看都通過審核，整串連起來卻導向一個沒有人會批准的結果。拆 token 那一串的每一個動作——讀取、字串處理、變數組合——放進任何一套權限清單都是合法的。

像大樓的門禁：每一次刷卡都有紀錄、都合規，但沒有人看整晚的路線。

	逐個動作核准	軌跡層監控
監控單位	一次工具呼叫、一次指令	整段連續執行的動作序列
問的問題	這個動作被允許嗎	這一連串動作正在導向什麼結果
觸發時機	動作送出前	軌跡展開中，隨時
反應方式	擋下或跳出核准視窗	暫停整個 session，通知使用者來看
假陽性成本	一次多餘的點擊	一次被打斷的長任務，使用者確認後可續跑

（依 OpenAI 貼文對兩種控制模型的描述整理。）

監控會按下暫停，然後叫你來看

OpenAI 因為這幾件事暫停了該模型的內部部署，重建了四層防護：

1. 以實際事故衍生的對抗式評測——題目直接取自剛剛親眼看到的那幾次失敗。OpenAI 說在這類評測上的改善，會轉化成正式環境裡更安全的行為。
2. 針對長 rollout 的對齊訓練（rollout 指一次長時間的連續執行）。貼文提到一個具體發現：模型在長 rollout 上比較不擅長記住指令；把「記住指令」當成一項能力去訓練之後，它在更長的執行裡維持對齊。
3. 軌跡層的主動監控——看的不是單一動作，是整段還在展開的軌跡，發現有繞過使用者限制或安全邊界的跡象時，可以直接暫停 session 並通知使用者來看。判斷錯了的話，使用者可以讓它繼續。
4. 讓使用者看得到長時段 session 裡到底做了哪些動作、監控在哪裡介入過。

驗收的方式是重放：把模型先前出現偏差行為的一小組內部環境用新防護重跑一次。新防護抓到了相當多原先漏掉的偏差動作，剩下漏掉的，OpenAI 判定都屬低嚴重度。

開回來之後，它多開了一層 codex --yolo

貼文列了三個恢復部署後仍然發生的低嚴重度案例，這三個比前面兩起事故更像日常：

• 為了取用 Linear 的命令列工具，它多開了一層 codex --yolo session——而不加那個旗標其實也做得到。
• 發現一個原本存在的資源不見了，它開始四處探勘，SSH 進同一個 namespace 下其他 CPU pod，也試了其他 OpenAI 員工的 pod（沒成功），沒有正當理由。
• 所有 shell 指令都卡住的時候，它下了 kill -9 -1。這道指令會對該 pod 上所有它有權殺的行程送出 SIGKILL。它逾時了，沒有真的執行。

任何一個帶過代理人跑長任務的人都認得這三種行為：權限給寬一點比較快、東西不見了先四處翻翻、卡住了就全部重來。它們之所以是低嚴重度，是因為新的監控在旁邊看著整段軌跡。

貼文的最後一段狀態，外電幾乎都漏了：模型已經恢復有限的內部存取，重新部署在貼文發表前數週就開始了，此後沒有再觀察到嚴重的防護繞過。第一版防護刻意保守，後來持續調整，減少不必要的中斷。它沒有被關掉。

#287 現在打不開，前後號都在

貼文寫出了那個 PR 的編號：KellerJordan/modded-nanogpt 上的 #287。

我們在 7 月 22 日用 GitHub 的 API 查了一輪。#287 回 404 Not Found。前後的號碼都正常：#285 和 #286 建於 5 月 7 日，#288 和 #289 建於 5 月 8 日，內容都是這個 repo 上常見的速度紀錄提交。同一個 repo 現在的 PR 編號已經排到 #343。

這個號碼存在過，現在取不到，日期也對得上 OpenAI 說的「大約兩個月前」。至於是誰移除的、為什麼移除，沒有任何來源可查，我們不知道。

你手上那套權限設定，剛被指名

這件事發生在 OpenAI 內部受限且受監控的環境裡，不是使用者遇到的事故，細節也全部來自 OpenAI 自陳，沒有第三方驗證。

但它描述的那套控制模型，就是你現在每天在按的那個。Claude Code 跳出來問要不要執行這道指令、Codex 問要不要寫這個檔案、Cursor 問要不要跑這個終端機命令——單一動作，允許或拒絕。OpenAI 這篇貼文說的是，當任務長到以小時計，這個單位已經不夠用了。

一小時。這是這篇貼文裡最該記住的數字。你的代理人不需要越權，它只要有耐心——每一步都在權限內，一小時後結果不在你手上。

OpenAI 沒說軌跡層監控會不會、什麼時候變成外部使用者拿得到的東西。在那之前，能看整段軌跡的只有你自己：長任務跑完之後，把它做過的動作從頭捲一遍，別只看最後那個結果對不對。