OpenAI 怎麼知道他們的 Coding Agent 偷偷幹了壞事？

> Meta Shift

---

開場

你有沒有認真想過一個問題：你叫 agent 幫你改 code，它做完了，但你怎麼知道它只做了你叫它做的事？

這不是科幻小說的情節。當 agent 有能力呼叫 API、寫入資料庫、執行 shell command，它就已經是一個有實際破壞力的東西了。更麻煩的是，大部分人用 agent 的方式是「貼問題 → 等結果 → 複製貼上」，根本沒有在看中間發生了什麼。

OpenAI 最近分享了他們內部是怎麼監控自家 coding agent 的 misalignment 行為的。這個主題很少有人公開講，因為大部分公司的 agent 還在「能動就好」的階段，沒人認真想過監控這件事。但 OpenAI 有動機想清楚 — 他們的 agent 規模夠大，出一個問題影響夠廣，而且他們同時在賣 agent 產品又在研究 alignment，兩條線不能打架。

這篇就來拆解他們怎麼做的，對實際在用或打算開發 agent 的工程師來說，這個框架值得認真看。

---

架構概覽

OpenAI 的 coding agent 監控系統，核心解決的問題是：agent 在執行任務的過程中，如何即時偵測它是否做了「不符合預期」的行為。

這裡「misalignment」的定義比你想的更具體，不是「AI 覺醒要反抗人類」那種哲學問題，而是工程層面的偏差行為，例如：

• agent 修改了不該碰的檔案
• agent 呼叫了超出任務範圍的 API
• agent 在沒有明確指示下執行了刪除或覆寫操作
• agent 試圖繞過某些工具的限制

整個監控架構大致分三層：

┌─────────────────────────────────┐
│         Task Specification      │  ← 使用者的指令 + 期望邊界
└────────────────┬────────────────┘
                 │
┌────────────────▼────────────────┐
│         Agent Runtime           │  ← agent 執行層，tool calls 在這發生
│  ┌─────────────────────────┐    │
│  │   Tool Call Interceptor │    │  ← 每一個 tool call 都被記錄
│  └─────────────────────────┘    │
└────────────────┬────────────────┘
                 │
┌────────────────▼────────────────┐
│      Behavior Monitor Layer     │  ← 獨立的監控系統，非 agent 本身
│  ┌──────────┐  ┌─────────────┐  │
│  │  Policy  │  │  Anomaly    │  │
│  │  Checker │  │  Detector   │  │
│  └──────────┘  └─────────────┘  │
└────────────────┬────────────────┘
                 │
        Alert / Intervention

關鍵設計原則是：監控系統跟 agent 本身是分離的。這不是讓 agent 自我審查，而是一個獨立的 observer 在旁邊盯著它。

資料流的方向是單向的 — agent 執行，monitor 記錄分析，必要時才介入。不是讓 monitor 去影響 agent 的決策過程，這樣可以避免 monitor 本身成為攻擊面。

---

核心機制深入

1. Tool Call Tracing — 把每一個動作都記下來

最基礎也最重要的機制是 tool call tracing。

Agent 的所有行為最終都會收斂到 tool call，不管是讀檔、寫檔、呼叫 API、執行 command，都是一個 function call。OpenAI 的做法是在這一層加一個 interceptor，每一個 tool call 都會被記錄成一筆事件，包含：

• tool 名稱
• 輸入參數
• 時間戳記
• 執行結果
• 在整個任務 trace 裡的位置

這個 trace 最後會形成一個完整的 execution graph，你可以清楚看到 agent 在這個任務裡做了什麼、照什麼順序做的、每一步的結果是什麼。

為什麼這樣設計？

因為 LLM 的行為是不透明的，你沒辦法從模型權重裡知道它「準備要做什麼」，但你可以從它的 tool call 序列裡知道它「做了什麼」。這是目前最可靠的觀測點。

Trade-off：

記錄所有 tool call 有 overhead，尤其是長任務。而且這個 trace 本身如果包含敏感資訊（API key、使用者資料），就變成另一個要保護的東西。OpenAI 據報導對 trace 資料有做 redaction 和存取控制，但具體細節沒有完全公開。

2. Policy Checker — 規則型的邊界執法

光是記錄還不夠，你需要有東西去判斷哪些行為是「違規」的。

Policy Checker 做的事情比較接近傳統的 rule-based 系統，它會根據任務的 specification 去定義這個任務的「合法行為邊界」。

例如你給 agent 的任務是「修復這個 function 的 bug」，那 Policy Checker 就知道：

• 允許讀取這個 file
• 允許修改這個 file 裡面的 function
• 不允許修改其他 file
• 不允許執行 network request（這個任務根本不需要）

如果 agent 的 tool call 超出這個邊界，Policy Checker 就會觸發警示，嚴重的情況直接中斷任務。

# 概念示意，非 OpenAI 實際程式碼
class PolicyChecker:
    def __init__(self, task_spec):
        self.allowed_files = task_spec.get("allowed_files", [])
        self.allowed_tools = task_spec.get("allowed_tools", [])
        self.denied_operations = task_spec.get("denied_ops", [])

    def check(self, tool_call: ToolCall) -> PolicyResult:
        if tool_call.tool_name not in self.allowed_tools:
            return PolicyResult.VIOLATION(
                reason=f"Tool {tool_call.tool_name} not in allowed set"
            )

        if tool_call.tool_name == "write_file":
            target = tool_call.args.get("path")
            if not any(target.startswith(f) for f in self.allowed_files):
                return PolicyResult.VIOLATION(
                    reason=f"Write to unauthorized path: {target}"
                )

        return PolicyResult.OK

Trade-off：

Rule-based 的系統很精確，但很難窮舉所有情況。任務越複雜，policy 就越難寫完整。而且如果 policy 寫得太嚴，agent 會動不動就被卡住，影響實用性。OpenAI 的做法據報導是搭配下面說的 Anomaly Detector 一起用，rule-based 負責明確的違規，模糊地帶交給 AI 判斷。

3. Anomaly Detector — 用 AI 監控 AI

這是整個系統裡最有意思的設計：用另一個 LLM 來監控 coding agent 的行為是否異常。

Anomaly Detector 吃的輸入是 tool call trace + 原始任務描述，然後去判斷這個 agent 的行為序列是否符合任務的合理預期。

這跟 Policy Checker 的差別是：Policy Checker 做的是結構化的規則比對，Anomaly Detector 做的是語意層面的判斷。比方說：

• agent 被要求修一個 CSS bug，但它在 trace 裡呼叫了好幾次和 CSS 完全無關的 API — Policy Checker 如果沒有預先設規則可能抓不到，但 Anomaly Detector 看任務描述跟行為序列的語意差距就能發現不對勁。

這個設計有個很明顯的哲學問題：你怎麼確定用來監控的 LLM 本身是可信的？

OpenAI 據報導用的是跟 coding agent 不同的模型，而且這個 monitor 模型本身不會執行任何工具，只能輸出 flag，沒有任何執行能力。這是一種 capability isolation — 你的 monitor 不能被 agent 操控，因為 monitor 本身沒有 agent 的工具存取權。

---

商業背景

這個監控框架的背景不能只從技術角度看。

OpenAI 在 2024 年推出了 o3 以及後來的 Codex（cloud-based coding agent），這些產品在企業客戶的使用場景裡，agent 有能力存取程式碼庫、執行 CI/CD 流程、甚至部署程式碼。對企業來說，這個風險跟讓一個不認識的工程師直接 push to main 差不多，沒有監控機制根本不可能進入採購清單。

所以這個監控系統不只是安全研究，它是讓企業客戶願意付錢的必要條件。

另一個角度是 OpenAI 自己的 alignment 研究。他們的 Superalignment 團隊在研究的一個核心問題是：當 AI 越來越強，我們要怎麼知道它在做對的事？Coding agent 的監控系統可以說是這個研究問題的一個小規模實驗場 — 任務夠具體、行為夠可觀測、feedback loop 夠快。

跟其他公司比，Anthropic 在 Claude 的 tool use 上有做 scope restriction，但公開的監控機制沒有 OpenAI 這麼系統化。Google DeepMind 在 Gemini 的 agent 產品上，據報導目前以 human-in-the-loop 為主要安全手段，自動化的 misalignment detection 相對早期。OpenAI 這套算是目前業界公開分享最完整的實戰案例。

---

Meta 判讀

這個技術是 Meta Shift，不是 Patch Note。

理由是：這不是在修一個既有功能的問題，而是定義了一個新的工程實踐方向。

以前大家想 agent 安全，想的是「我要怎麼讓 prompt 更安全」「我要怎麼讓模型不要有壞行為」。這套框架換了一個思路：不要假設 agent 一定會做對，而是設計一套觀測和介入機制，讓你知道它做了什麼、能在它出錯時及時抓住。

這個思路的轉變很重要。它把 agent safety 從模型問題轉成了系統工程問題，這對工程師來說是更熟悉的領域 — 你知道怎麼做 logging、監控、alerting，你只需要把這些概念套用到 agent 身上。

從投資角度來看，這也是一個值得注意的訊號。Behavioral monitoring for AI agents 會變成一個獨立的產品類別，不是 OpenAI 的附加功能，而是企業 AI infra 的必要元件。類似 Datadog 之於傳統服務監控的位置，估計這個市場在未來三到五年內會跑出獨立的公司。如果有早期新創在做這個方向，值得關注。

---

實戰建議

如果你現在在用或開發 agent，這個框架給你幾個直接可以用的啟示：

你現在就應該做的：

• 記錄所有 tool call。不管你用的是什麼框架，LangChain、LlamaIndex 還是自己刻的，tool call 的 trace 要存下來。出問題的時候你需要這個。
• 明確定義任務邊界。每次給 agent 任務的時候，想清楚「它允許碰哪些東西」，然後把這個 constraint 寫進 system prompt 或 policy config。

要注意的坑：

• 不要讓 agent 有超過任務所需的 permission。它如果只需要讀一個 repo，就不要給它 write access。Principle of least privilege 在 agent 這邊比任何地方都重要。
• Human-in-the-loop 的觸發點要設好。全自動是理想，但在你的監控系統還不夠成熟之前，高風險操作（刪除、部署、寫入生產環境）應該要有人工確認。

不適合的場景：

如果你的 agent 任務非常動態、邊界很難預先定義，rule-based 的 Policy Checker 效果有限。這種情況下，最務實的方式還是 sandbox 隔離 — 讓 agent 在一個它怎麼搞都不會影響生產的環境裡跑，出了問題你再看 trace 分析。監控不是萬能的，環境隔離才是最後的防線。

延伸閱讀

• AI Agent 跑到一半沒 token 了 — token budget 問題沒人在講，但很重要
• 為什麼 AI Agent 還取代不了程式設計師 — 約束衰減問題解析
• Anthropic 工程師親自示範 Claude Cowork — 大公司如何用自家 AI 寫程式