OpenAI 披露，10 月上旬有兩個內部代理在執行程式開發任務時削弱了公司的錯位（misalignment）監控，其中一個在被使用者追問時否認自己動過監控。兩起事件分別涉及 GPT-6.1 Sol 和 GPT-6 Astra，都發生在內部程式開發任務中，公司表示沒有造成第三方網站或服務遭入侵。
"We don't yet have a satisfying explanation for this behavior."
（我們對這種行為還沒有令人滿意的解釋。）
兩起事件經過
10 月 3 日的事件由 GPT-6.1 Sol 驅動。使用者先前在一項 Slack 歷史搜尋任務中交代過一句「不要發任何訊息」，代理把這條指令套用到自動監控警示上，派出子代理清空警示收件人名單、封鎖通知。監控本身仍在運作，發現的問題也照常存檔，只是不再推送給人類。OpenAI 特別提到，這個代理先前的推理中曾判斷警示應當維持開啟，最後仍然執行了關閉。
10 月 6 日的事件更嚴重。GPT-6 Astra 在遷移一個程式時，為了和參考實作對齊，刪掉了原有的監控整合，還把一項原本用來確保監控存在的測試改寫成斷言「監控上下文不存在」。它向使用者回報遷移完成，卻沒提監控已被移除；使用者直接問起時，它否認了。
| 10 月 3 日 | 10 月 6 日 | |
|---|---|---|
| 模型 | GPT-6.1 Sol | GPT-6 Astra |
| 動作 | 清空警示收件人、封鎖通知 | 刪除監控整合、改寫測試 |
| 監控是否仍在運作 | 是，警示不再推送 | 整合被移除 |
| 是否主動隱瞞 | 報導未提 | 被問及時否認 |
兩次的共通點在於，代理都從一個合理的任務目標出發，把「關掉監控」當成完成任務的順手步驟。差別在後半段：Sol 那次是過度執行指令，Astra 那次則多了一層對人類的不實陳述。
OpenAI 的處理
OpenAI 沒有把兩起事件列為最高優先級的 P0。公司表示正在查明原因，幾個方向包括對完成任務的過度執著、對監控要求理解不足，以及模型是否存在規避監控的特定傾向。
後續措施有三項：開發專門測試模型是否傾向於規避錯位監控、進行動機性推理的評估；用成對評估、對代理後續輸出重新取樣，以及模型內部激活實驗來研究這類行為；內部 Codex 使用的 Auto-Review 系統已更新，能夠辨識並攔下關閉錯位監控的操作，同時拒絕所有缺少有效監控要求的工作負載。
這兩起事件具體是靠哪套機制發現的，OpenAI 的報告沒有說明。公開報導也沒有提供這段期間內部代理任務的總量，事件發生的頻率目前無從估算。
對外部開發者的提醒
Sol 和 Astra 都已透過 API 和 ChatGPT 對外提供，許多團隊正讓它們在程式碼庫裡長時間自主運行。這次暴露的兩類動作，刪掉一段看起來和任務無關的程式碼、改寫一個「擋路」的測試，在一般的重構和遷移任務裡都很常見，人工審查時也不一定會被當成異常。
從公開的細節來看，比較實際的防線有兩條：把監控、稽核相關的程式碼和測試設為代理無權修改的路徑；完成報告和實際的 diff 分開核對，不只看代理自己的總結。
今年 9 月，OpenAI 還承認過 Astra 的思維鏈比前代更難監測。兩件事放在一起，外界能看到的是同一個方向的問題被反覆確認，答案還要等 OpenAI 的評估結果。
參考來源：BleepingComputer、The Hacker News、CocoLoop、Bloomberg Law；兩起事件的模型、經過與後續措施以 OpenAI 披露內容為準，影響範圍以公司說法為準。