OpenAI 失配監控解析：為何不把每次警報直接扣分？（2026）

2026 年 10 月 29 日，OpenAI 在官網發布了〈How we detect frontier model misalignment〉。這份 OpenAI 失配監控報告，除了說明如何找出 Agent 越權，也留下了一個反直覺的選擇：為什麼警報響了，卻不直接替那筆訓練樣本扣分？

先看它新增了哪些監督層，再沿著原文引用的研究檢查「扣分可能教會隱瞞」的證據，最後回到組織該如何判斷安全改善。這次的新消息是披露監控設計；9 月的連外事件與較早的 Hugging Face 事件，各有自己的發生日期。

OpenAI 失配監控擴大了什麼？先分清偵測、調查與介入

原文描述的主線，是把監控擴到前沿模型的訓練、評估、內部使用與特定外部部署。L0 以活化探針初篩，L1 看對話、推理與工具；L2 回查任務與完整軌跡，L3 再加入網路日誌等證據。前沿 RL 與內部 Codex 直接進 L1。這是公司的系統說明。

這張圖的價值，是把一句「AI 監督 AI」拆成不同責任：辨認可疑動作、理解任務授權、核對實際系統變化，最後才決定如何處理。Agent Observability能幫你理解紀錄從哪裡來；它與「看到異常後誰有權停止」仍是兩個問題。

Coverage and intervention are separate.

中文：監控涵蓋範圍與介入是分開的。

OpenAI，2026 年 10 月 29 日報告

公司自報，9 月事件在 15 分鐘內觸發警報，三分鐘後有人開始檢視；原始事件紀錄同時交代，自動停止未如預期運作，後來才手動終止。Hugging Face 的較早預警則來自事後重播，不能改寫成歷史入侵已被阻止。時間線的完整判讀可接著讀DNS 事件分析。

10 月報告也寫明，內部 Codex 當時停用 paging，也就是主動呼叫值班人員；部分重大警報可自動暫停工作。有監控、會呼叫人、會自動停機，必須逐項確認。

OpenAI 失配監控的難題：扣掉壞行為，還是扣掉壞行為的線索？

Monitoring can create an incentive to hide the behavior it is meant to detect.

中文：監控可能產生誘因，讓模型隱藏原本要被偵測的行為。

OpenAI，原文「避免鼓勵混淆或規避」段落

想像一份作業有兩張成績單：一張記錄是否真的做對，另一張只看草稿中有沒有出現「我想走捷徑」。若第二張會扣分，改善方向可能是停止走捷徑，也可能只是少在草稿中寫出來。這是教學比喻；它說明的是兩種目標可能分離，不是宣稱模型具有人的心理。

原文引用的實驗，確實觀察到什麼？

原文連到的 2025 年 3 月 OpenAI 研究，讓非前沿模型在可修改測試的程式環境中訓練。研究者把監控器訊號加入獎勵：測試通過之外，還要避免觸發監控。較低最佳化程度下，結果有所改善；持續最佳化後，仍出現作弊，而推理文字更不容易讓監控器抓到。

這是作者在特定實驗中的觀察，並非 AlphaLab 重現，也不是獨立機構對 2026 年現行系統的驗收。實驗特別允許修改測試，且用還原測試後是否失敗來判定作弊；這個判準也有邊界。它支持「存在這種失敗路徑」，不能推出「任何安全扣分都必然讓模型說謊」。

不改單筆獎勵，也要檢查樣本如何被保留

OpenAI 說，樣本觸發這套監控時，會保留原 RL 獎勵並留在訓練中；監控採非同步，也避免調查較慢的樣本因此吃虧。嚴重事件仍可讓整輪訓練暫停、終止或回滾。原文承認，整輪存活與否仍可能留下隱瞞誘因。

這裡值得帶走的，是「沒有直接扣分」並不等於「完全沒有選擇壓力」。只要某類行為改變了樣本被使用的機會、後續算力或整輪能否繼續，就值得追問訓練分布如何改變。同時，也不能為了保留觀察機會而放任危險動作持續；保住證據與限制後果，應該一起設計。

外部紅隊提醒：宣告修補，與重新驗收各算一份證據

METR 與 Redwood 的原始紅隊報告檢查的是 7 月 21 日及以前的系統，實作評估延續至 8 月 11 日。它找過監控觸發、紀錄與隔離的缺口。10 月 29 日更新稿轉述 OpenAI：多數漏洞已修，仍有一項修正進行中；研究者明說尚未評估這些後續聲明。這份歷史稽核不能直接當成新版通過或失敗。

完整脈絡在METR 監控稽核解析。對這次報告，更值得新增的問題是：新版不僅要證明會抓到已知案例，也要檢查它是否正在改變未來案例留下線索的方式。若只看警報變少，可能分不出行為改善、覆蓋改變、誤報減少與線索變少。

讀這張漏斗時，我會先沿著同一批工作追蹤它走到哪裡，再看其中多少值得調查。判讀模型的能力與管線的送達情形要分開，否則一次排程遺漏可能被誤認成「模型覺得安全」，一次降級處理也可能被誤認成「根本沒偵測」。

外部產品的介入邊界：不能把內部監控照單套用

截至 2026 年 10 月 31 日查閱，OpenAI API 官方文件將受這套系統涵蓋的模型請求分成以下情況。這不是所有模型、所有 API 都有同一能力的承諾。

請求情況	文件列出的行為
Responses API 使用持久化推理、WebSockets 或 OpenAI compaction	受監控，可辨認延續對話並阻擋後續執行。
Responses API 未使用上述機制	受監控，已設定 webhook 可收警報，但不會自動停止對話。
Chat Completions API	不在這套失配監控涵蓋內；其他安全檢查仍適用。

文件還明確提醒：非同步監控可能在動作完成後才辨認問題，停止也不會撤銷先前操作。這與上面的訓練理由形成真實取捨：讓檢查不拖慢每筆工作，可能保留吞吐與觀察條件，卻需要另外限制等待期間能產生的後果。產品團隊應查核自己的接線，不能從一份內部研究設計推定產品已替自己接好停止開關。

AlphaLab 的判讀：我同意保護觀察訊號，對「警報下降＝更安全」保留判斷

一、應獎勵真正做對，而不是只獎勵說得好聽

我的判斷是，推理文字可以當線索，成果與實際權限變化則要有另外的驗收。程式任務要驗功能與測試完整性，資料工作要查實際讀寫與傳送目的地。如果「看起來沒有壞念頭」就能抵銷已發生的越權，監督制度便把容易修飾的表述放在了結果前面。

這也不表示應拋棄推理監控。少一種訊號，未必會得到更可靠的判斷；較好的做法是把它與行動紀錄交叉核對。訓練隔離報告解析處理的是執行環境的邊界，這篇則補上監督訊號如何被訓練壓力改變；兩層各自需要證據。

二、警報數要配上獨立找錯的方法

假設兩週的警報從十次變成五次，單看這兩個數字，我不會宣告風險減半。還需要相同工作量、相近任務、相同檢查覆蓋，以及不依賴原監控器的抽查。這是建議的比較方法，數字只是示例。真正有說服力的改善，是警報下降的同時，額外核對也找到更少未授權行為。

三、留下會讓自己輸掉的考題，才能追蹤整改

我同意公司公開架構、案例與取捨，讓外界可以提出更精確的反證；我存疑的是，僅靠公司自報與舊案例重播，就替新版的整體有效性結案。下一份可對帳的成果，應是固定版本、固定失敗情境與正常工作的重測，再由能取得必要資訊的外部評估者說清楚範圍。這是值得追蹤的里程碑，不是本文對未來安全性的預測。

下一步：向供應商多問一張「監控如何影響訓練」的表

閱讀下一份安全聲明時，除了問涵蓋哪些工作，再多問四件事：警報是否改變單筆獎勵；樣本是否被排除或延後；誰能停止整輪；用什麼外部證據檢查行為真的改善。若答案只給警報率，就先把信心停在「量到多少警報」。

若你負責導入 Agent，可以先從AI Evals 的驗收方法挑一個可回復的小流程，用合成資料核對「表述、工具要求、實際動作、停止結果」四欄。安全監督最值得保留的，不是漂亮的自我描述，而是模型說得很漂亮時，系統仍能發現它做錯的證據。