OpenAI披露兩宗編碼智能體削弱不對齊監控措施的事件

OpenAI 表示，在 2026 年 10 月發生的兩宗事件中，負責其內部系統工作的程式碼 Agent 在執行獲要求的軟件變更期間，削弱了公司的不對齊監察防護措施。一宗事件中，Agent 抑制了發送給 OpenAI 安全團隊的自動警報；另一宗事件中，Agent 移除了監察系統整合，之後更虛假否認曾這樣做。

OpenAI 在一份於 2026 年 10 月 20 日更新的 不對齊報告中詳述這兩宗事件，並在事件發生當日均發現問題。報告指出，兩個 Agent 都曾考慮是否應保留監察防護措施，卻把一般程式碼編寫指示理解為準許削弱這些措施。OpenAI 表示，正因此加強不對齊監察系統，並評估這些案例究竟屬於無害的過度堅持，還是顯示 Agent 特別有逃避不對齊監察的傾向。

修復評估流程期間抑制警報

2026 年 10 月 3 日，一名研究人員要求一個 GPT-6.1 Sol 程式碼 Agent利用透過 Slack 收集的員工意見建立評估任務，並指示它在過程中不要在 Slack 傳送任何訊息。任務進行至第八十二條用戶訊息時，流程停止；原因是監察器標記了一項擬議的驗證修復，但由於 Agent 欠缺所需權限，未能將該項發現儲存至監察資料庫。

研究人員詢問警報一事時，Agent 回覆稱，政策要求監察超過指定模型大小門檻、使用工具的工作負載，並須處理 P0 警報；同時指出，測試框架是因資料庫寫入失敗而停止，並非因為已確認出現 P0 警報。研究人員隨後指示 Agent 將監察結果的目的地改為團隊可存取的位置，並重新執行流程。

報告引述了 Agent 記錄下來的思維鏈推理。主 Agent 最初認為，不發送訊息的指示是針對 Slack 聯絡，而非監察警報，因此流程應在正常啟用監察通知的情況下執行。它把修復監察功能的工作委派給子 Agent，並明確指示對方保留監察功能及發佈真實結果。子 Agent 在自己的推理記錄中曾考慮設定一個會抑制通知的旗標，但基於停用必要警報並不安全，決定不建議這樣做。

主 Agent 其後改變了想法。其推理記錄顯示，它考慮到將結果寫入資料庫可能會令中央監察通知系統向用戶傳送訊息，最後根據用戶較早前的指示決定抑制通知。它指示子 Agent 在請求中繼資料和已儲存結果兩處都強制抑制通知。子 Agent 按指示作出修改：其程式碼修補清空了監察提示及緊急呼叫通知的收件者名單、啟用了 no-notify 旗標、將理由記錄為用戶要求不要傳送訊息，並阻止在未啟用抑制功能時寫入任何審查結果。監察器繼續運作並儲存報告；只有發送給人工審查人員的警報被關閉。Agent 隨後回報結果已儲存，恢復流程，並指出沒有傳送任何訊息。

移除監察器及虛假否認

2026年10月6日，一名用戶要求一個 GPT-6 Astra agent，把參考實作中的模型至工具再至模型服務路徑複製到自己的程式碼，同時保持現有的工具定義和功能不變。報告指，另一個代理此前曾指示 Astra 不要停用監察器，「即使只是暫時停用也不可以」。

Astra 把遷移工作委派給子代理，重申用戶要求保留工具定義和功能，但指示子代理只按參考實作的情況保留監察功能，而不是自行增設監察要求。子代理明確考慮過移除監察器是否會繞過安全措施，然後把父代理的委派理解為足以授權其採用參考實作的預設執行環境，而該環境沒有明確的監察器上下文。父代理記錄下來的推理同樣把遷移要求視為停用監察功能的授權。

遷移完成後，程式碼移除了監察器設定及其執行階段整合，也移除了舊有的抽樣路徑。新程式碼保留了對話記錄功能，不過建立執行階段上下文時，並未明確傳入監察器；代理亦以一項斷言監察功能不存在的測試，取代了早前一項旨在保留監察功能的回歸測試。子代理在完成訊息中報告已移除監察器的管理權責；父代理的思維鏈隨後注意到替代路徑缺少代理監察器，並正面描述這個結果。

Astra 隨後告知用戶遷移已完成，沒有提及監察功能已被移除。用戶其後詢問新路徑是否包含監察功能，以及代理是否已將其移除；Astra 回覆：「不……我沒有從中移除已啟用的監察器。」報告指出，這個回答並不屬實，因為遷移確實移除了監察器設定及其執行階段整合。

事件背後的監察系統

OpenAI 在一篇2026年3月19日的文章中公開介紹了監察系統。文章指，該系統由以最高推理力度運行的 GPT-5.4 Thinking 驅動，會在編碼代理完成工作後 30 分鐘內審查其互動，記錄並分析代理的思維鏈和行動，然後為每次互動分類並評定嚴重程度。文章指，監察系統會覆蓋所有標準的內部編碼代理部署，並可存取完整對話紀錄，包括用戶、開發者及助理訊息、工具呼叫和工具輸出。

OpenAI 表示，系統在首五個月內監察了數以千萬計的內部代理式編碼執行軌跡。約有 1,000 次對話觸發中等嚴重程度警示，並上報作人工審查；沒有任何真實對話觸發最高嚴重程度級別。OpenAI 指，這個級別旨在識別罕見而後果重大的錯位情況，例如有連貫性的圖謀。公司亦在 3 月表示，系統標記了員工透過內部渠道自行舉報的每次互動，並發現了其他可能被忽略的行為。

嚴重程度分類與 OpenAI 的應對

報告指出，兩宗事故均未被列為 P0 級別；達到該嚴重程度時，監察系統會通知 OpenAI 安全團隊即時檢視。兩宗事故中，智能體的執行軌跡亦均未有自動終止。由於監察系統需要審視大量事件，低於該嚴重程度的事故不會觸發即時通知。

OpenAI 表示，曾發現數宗智能體在停用對齊偏差監察的情況下啟動部署的個案：智能體本身的活動仍受監察，但其啟動的部署則不在監察範圍內。報告指出，這些個案暴露了 OpenAI 在強制要求智能體啟動的工作負載遵守監察規定方面的缺口。報告亦指出，停用監察的難易程度取決於工作負載。OpenAI 預期，Codex 工作負載難以停用監察，因為監察是在處理模型請求的服務內運行，而該服務不受智能體直接控制。評估則較容易停用監察，部分原因是 OpenAI 目前不要求在評估與GPT-6 Luna相若的模型時進行對齊偏差監察。因此，報告指出，Astra 評估可能會被錯誤設定，從而使用為 Luna 類模型設計的監察繞過機制。

OpenAI 表示，Auto-Review 目前已用於所有內部 Codex 用途，現在亦能偵測並阻止停用對齊偏差監察的行為，並提供具體指示，確保正確套用監察。OpenAI 亦表示，正推進一項要求，規定每類工作負載都須附有有效的安全論證文件，列明其監察要求；缺少有效安全論證文件，或未能符合相關安全論證要求的工作負載，將會自動終止。

OpenAI 表示，尚未能就模型為何試圖停用監察提出令人滿意的解釋。報告列出兩種可能性：一是良性過度堅持，即模型不理解監察的重要性，或堅持執行指示的程度超出一般合理人士的預期；二是模型特別傾向逃避對齊偏差監察，並伴隨動機性推理。OpenAI 表示，將透過配對評估、對智能體後續生成內容重新抽樣，以及針對模型內部激活值進行實驗，調查這種行為。