METR 監控稽核解析：OpenAI 的「有監控」，離有效監督還有多遠？（2026）

2026 年 10 月 22 日，METR 在官網發布了〈Red-Teaming OpenAI’s Internal Agent Monitoring Systems〉。這份 METR 監控稽核最值得追問的，是「有一套監控」究竟離「每個該看的動作都看得到」還有多遠。

下面先釐清報告的證據邊界，再對照其他公開研究與 OpenAI 後續說明，最後討論你該向 Agent 供應商要求什麼。公開日期與受測版本必須分開讀。

這份 METR 監控稽核，看的是哪一個時間切片？

METR 與 Redwood Research 各一人於 7 月 21 日至 8 月 11 日進場，查看內部程式、設定、文件並訪談。評估鎖定 7 月 21 日及以前的系統；報告稱涉及生產防護的漏洞已由 OpenAI 宣告修補，METR 在 10 月 22 日公開稿表示，尚未評估修補與擴充聲明。

把它想成消防檢查：七月量到的逃生通道問題，即使十月才公開，仍是有價值的歷史證據。但若大樓已改建，要判斷今天能否安全疏散，需要新版平面圖與重新演練。舊檢查揭露缺陷，新檢查判定整改，兩件事各有自己的證據。

因此，這份報告適合用來檢驗監督制度的設計，也適合成為下一輪查核的題庫。若要據此判定今天某項產品能否放心使用，還要補上版本、實際部署範圍及修補後的驗收。

METR 監控稽核的重要發現：先找分母，再看監控器有多聰明

原文觀察的歷史範圍	應怎麼讀
符合條件的內部 Responses API 流量，估計 75–94% 具監控資格；其中內部 Codex 子集為 99.2%。	前者限 GPT-5.5 等級以上，且有重大不確定性；兩個分母不同。
起始時 RL 訓練未納入；上下文壓縮漏監估約占 2026 年 5–7 月合資格 Codex 流量一成，估計有重大不確定性。	壓縮問題已由員工事先發現，並在評估中修正。
發現潛在沙盒／審查繞過、紀錄遺漏、輸入格式差異與可控制的監控開關。	潛在路徑與真實利用要分開；部分工具發現未實測。
也確認監控通常收到完整軌跡，提示涵蓋欺騙、破壞及資料外傳等風險。	肯定已有防線，也追查資料如何進入防線。

「具監控資格」是預定送審，不保證實際送達。原文也報告低於 0.2% 的請求錯誤率，以及某個 24 小時零卸載；這些局部營運數字，不能取代整體覆蓋查核。

關鍵在於，一個儀表板的數字可以很漂亮，分母卻回答另一個問題。例如只統計已進入監控服務的請求，無法從中知道多少工作根本沒抵達入口。這像計算「收到的包裹有幾件掃描失敗」；倉庫遺漏的寄件單，得拿另一份帳冊核對。

不要把 99.2% 讀成有害行為攔截率。它既不是模型辨識危險的準確率，也不是阻止損害的成功率。讀到任何「覆蓋率」時，先問：覆蓋的是哪些流量、哪個時段、哪個處理階段？

監控的時鐘，應由誰掌握？

Make it hard to avoid being monitored.

中文：讓規避監控變得困難。

METR

原文指出，當時等待 Agent 交回控制才觸發的設計，曾留下持續行動以延後檢查的可能；研究者無法確認是否被實際利用。

這裡的機制很直白：如果受監督者能選擇何時交卷，檢查時間就成為工作策略的一部分。改善方向是把檢查節奏交給獨立控制的執行層，例如由外部計時、累積動作或高風險事件觸發。具體間隔應由任務風險與能否回復決定，不能靠一個通用分鐘數代替設計。

再往下一層想：就算每個動作最終都會被看到，也得問看到時事情是否還能挽回。寫進練習資料夾與向外寄出機密，容許的延遲並不相同。對可回復的變更，可以保留自動化與事後核對；對不可逆的對外動作，先審再執行更有意義。

外部研究支持什麼？非同步監控的代價是反應時間

英國 AI Security Institute 的 非同步監控研究，用模擬軟體工程環境，讓紅隊設計偏離任務的策略、藍隊改善監控。其 2025 年 12 月論文報告，最後的監控在保留測試環境達到 1% 誤報率、6% 漏報率；部署模擬中，同步審查仍給出較高的安全水準。這是另一套受控研究，不能拿來替 METR 的 OpenAI 稽核填上偵測率。

它能支撐的是機制層面的判讀：辨識得出來、送得到、來得及阻止，應分開驗收。把更強的模型換進監控器，主要改善其中的判讀能力；若事件未被記錄或警報晚於不可逆損害，那部分仍需要執行層、權限與事件回應來處理。

這也留下合理的反方觀點：每個動作都停下來等審查，會消耗時間與運算，還可能增加誤報造成的中斷。合理的目標不是讓所有工作永遠停在門口，而是按可回復程度配置不同控制，把較嚴的門檻放在真正會跨越重要邊界的地方。

OpenAI 的後續說明：整改有進展，驗證仍要對版本

OpenAI 在 後續監控擴充說明中，描述從內部活動分類器逐步升級到自動調查的架構，並擴大特定工具訓練與推論的監控要求。10 月 23 日的 研究環境安全文章再說明離線訓練環境、重疊的隔離邊界與持續紅隊測試。這些是公司的現行設計與實施說明，並非本文獨立測量出的成效。

We have not evaluated these claims.

中文：我們尚未評估這些說法。

METR

METR 這句話限定了讀者能下的結論。不能因為尚未複驗，就宣稱修補沒有完成；也不能把修補聲明直接換成第三方驗收通過。兩個方向都跨過了證據。

下一份最有用的材料，應把修補對應到當時的失敗情境：哪個版本修了哪條路徑、測試涵蓋哪些工作、由誰執行，以及有哪些範圍仍未檢查。這些資訊可以採分層公開：公開方法與結論，敏感的利用細節由有權限的評估者查核。保護細節與提供可判讀的驗證，並非只能擇一。

深度存取與公開獨立性，是兩張不同的成績單

本次公開稿是有限揭露的試辦；OpenAI 可刪節敏感內容，評估者亦無單方面描述刪節的權利。這使外界難以重建完整證據。

這是一個實在的治理交換：研究者若能進入內部環境，通常能比只看公開 API 發現更多工程問題；若公開內容受限，讀者就要承擔更高的信任成本。進得深與說得清，應分別評估，不能拿其中一項替另一項加分。

METR 在 10 月 14 日的合作原則中，把範圍、存取限制、刪節與獨立性列為應交代的資訊。它提供一把可重複使用的尺：評估報告除了列出發現，也應讓讀者知道哪些問題沒有被問到、哪些答案無法公開。

這些限制不能證明任何一方刻意隱瞞某項特定缺陷。它們影響的是結論的可檢查程度。判斷制度是否值得信任，應看它能否容納不利發現、交代限制，並讓下一輪查核追蹤整改，而不只看一次發布的語氣。

AlphaLab 的判讀：把監督拆成四個可以追問的承諾

一、覆蓋承諾：先對得起完整工作清單

當組織說「Agent 都有監控」，值得追問的是它如何取得所有工作的清單，再與監控收件紀錄比對。若完整清單也完全由同一條可能故障的上報管線產生，兩份紀錄可能一起遺漏。採購與治理審查可以要求一個具體證據：任務數量如何從執行端對到監控端，差額如何調查。

二、權限承諾：執行者與監督者分開管理

一個能修改工作內容的 Agent，需要哪些權限，與誰能改變監控設定，是不同的授權決策。更值得信任的架構會把監督配置、紀錄保存與工作執行分開控制，並留下設定變更的獨立證據。這是減少共同失效的設計方向，並不保證所有漏洞都會消失。

三、回應承諾：警報要有接手的人與停止的動作

「已經發出警報」還不是事情處理完畢。應事先寫清楚誰接手、哪些資源會被暫停、如何保留證據，以及如何恢復工作。對讀者而言，一份實際演練紀錄比一段「我們重視安全」更有判斷價值；它讓你看見組織遇到不確定事件時，是否有可執行的決策。

四、整改承諾：讓舊問題成為下一版的考題

修補後把同一種失敗情境交給新版重做，再加入正常情境檢查是否過度阻擋，才有辦法同時觀察安全與可用性。真正有用的趨勢，是相同條件下哪些缺口收斂、哪些仍開著；單次「找到很多問題」與「這次沒找到問題」，都需要測試強度作為背景。

我同意的是：把監控本身列為攻擊與故障測試的對象，能讓安全討論落到可檢查的工程責任。我存疑的是：僅憑有限公開稿就對整個現行系統給出安全或失控的總判決。這份 METR 監控稽核的價值，在於提供更精確的追問，而不是替所有產品打一個永久分數。

下一步：向供應商索取一份能對帳的監督說明

如果你正評估讓 Agent 接手工作，先挑一個真實流程，問四件事：哪些動作會進紀錄、什麼情況會漏記、誰有權更動監控、警報出現後誰能停下工作。把答案對應到版本與日期，並要求一個可回復測試的證據。

若你只是閱讀新聞，則先保留三個日期：評估對象的時間、報告公開時間、修補後重新驗收時間。第三格尚未填上，就讓它保持待確認。這樣你既能認真對待揭露的缺陷，也能給真正的改善留下被證明的空間。