代理需要監督介面

OpenAI現在將Codex app描述為一個命令中心，用來管理多個代理、平行執行工作，並在整個軟體生命週期中監督協作團隊。¹這個產品方向確認了介面的轉變：難題已經從「代理能不能行動？」轉向「人能不能大規模監督行動？」

代理需要監督介面：讓人能看見狀態、審查風險、核准敏感工具、檢查追蹤、從失敗中復原，並用證據簽核成果的地方。更好的聊天有助於表達。監督介面則治理工作。

摘要

聊天仍適合表達意圖。但如果把它當成自主工作的唯一介面，就會失靈，因為代理執行包含工具呼叫、權限、追蹤、記憶、失敗分支與完成聲明。OpenAI的Codex雲端文件描述了沙箱環境中的背景任務、即時進度監控、終端機記錄引用，以及測試輸出證據。²OpenAI的Agents SDK提供人工介入式核准，以及針對工具呼叫、移交、防護機制與自訂事件的內建追蹤。³⁴Anthropic的Claude Code掛鉤則揭露了PreToolUse、PostToolUse、PermissionRequest與Stop等生命週期節點。⁵

產品上的教訓是：監督不是最後跳出的一個對話框。它是一組介面，在工作發生時伴隨代理左右。

重點整理

給代理產品團隊： - 先建立監督佇列，再去打磨另一個聊天功能。佇列應顯示受阻的執行作業、高風險動作、過期證據、失敗檢查，以及可審查的產物。 - 把核准、追蹤與復原視為核心UX。使用者不應該從逐字稿裡重建工具狀態。

給設計工程師： - 為每個代理動作設定呈現層級：靜默、摘要、打斷或阻擋。唯讀工作不應看起來像正式環境變更。 - 設計審查物件，而不只是訊息。審查物件包含工具酬載、風險原因、差異內容、證據與下一步動作。

給導入程式碼代理的團隊： - 衡量操作員能否回答：什麼正在執行、什麼正在等待、改了什麼、哪裡失敗、什麼需要核准，以及還有什麼尚未驗證。 - 用聊天來委派。用監督介面來承擔責任。

什麼是監督介面？

監督介面是讓代理工作可被問責的使用者介面。

它不試圖顯示每個詞元。它顯示的是那些決定代理是否應該繼續的部分：

它與聊天的差異在於隨機存取。聊天說的是「讀完這串捲動內容」。監督介面說的是「檢查有風險的部分，然後做決定」。

當一個人同時執行多個代理時，這點尤其重要。單一代理可以在一段時間內維持對話形式。5個長時間執行的代理，就會變成操作流程。介面必須排序、摘要並導引注意力。

為什麼聊天不適合作為操作介面？

聊天會失靈，因為它的形態不適合持續變動的工作。

代理工作會產生事件：計畫、搜尋、檔案讀取、檔案寫入、終端機命令、瀏覽器動作、API呼叫、測試執行、被否決的路徑、失敗重試，以及最終證據。逐字稿可以包含這些事件，卻無法依風險、階段或責任來組織它們。

OpenAI的Codex app公告直接點出了這個轉變。開發者現在會委派工作、平行執行任務，並跨專案監督代理；舊有IDE與終端機介面不適合這種模式。¹這樣的措辭很重要，因為監督需要不同於提示輸入的版面。操作員需要的是看板，不是一長串捲動內容。

Microsoft在2019年提出的人類-AI互動指引，仍然提供了基礎設計框架：AI系統應該傳達狀態、支援修正，並在互動過程中處理失敗。⁶代理讓這些舊指引變成可操作的要求。狀態現在意味著「哪個工具呼叫正在等待？」修正現在意味著「拒絕並繼續這次執行」。失敗現在意味著「顯示失敗命令、改變的假設與修復路徑」。

錯誤在於把監督視為摩擦。糟糕的監督會增加摩擦。好的監督會降低認知負擔，因為它把決策放在正確的位置。

執行佇列應該顯示什麼？

執行佇列應該顯示注意力需求，而不是活動量。

活動摘要告訴使用者發生過的一切。監督佇列告訴使用者哪些地方需要判斷。佇列可以把多數事件壓縮成幾種狀態：

OpenAI的Codex雲端文件描述了可在背景執行的任務，包括在各自雲端環境中平行執行。²平行背景工作會改變注意力模型。使用者不應逐一輪詢每個討論串。系統應該把受阻、高風險與可審查的工作導向同一個地方。

佇列應避免虛假的急迫感。草稿分支上的程式碼檢查失敗，和正式部署不一致，不該有相同的視覺權重。介面應把打斷保留給不可逆動作、公開發布、安全敏感操作，以及代理缺乏足夠脈絡而無法負責任地繼續的決策。

核准應該如何運作？

核准應該像一組審查物件佇列，而不是一串跳出的模態干擾。

OpenAI的Agents SDK人工介入流程會在敏感工具呼叫前暫停執行，直到有人核准或拒絕。文件將待處理核准描述為interruptions，並使用RunState在決策後序列化狀態並繼續執行。³同一頁也指出，核准適用於巢狀代理工具與MCP工具，而不只限於目前最上層的代理。³

Anthropic的Claude Code掛鉤文件則從另一個角度呈現相同的設計形態。PreToolUse會在工具呼叫前執行，並可阻擋該呼叫。PermissionRequest會在權限對話框出現時觸發。PostToolUse與PostToolUseFailure會在工具成功或失敗後觸發，而Stop會在Claude完成回應時觸發。⁵

這些基礎元件指向正確的介面：

正確的核准介面會讓低風險讀取靜默通過，將中風險決策批次處理，並為高風險變更打斷使用者。使用者不應該一邊讀段落，一邊核准終端機命令。使用者應該核准的是一個型別明確、脈絡足夠、能維持問責的操作。

追蹤介面應該證明什麼？

追蹤介面應該證明順序、原因與後果。

OpenAI的Agents SDK追蹤文件指出，追蹤會記錄一次執行中的LLM生成、工具呼叫、移交、防護機制與自訂事件，並支援開發與正式環境中的除錯、視覺化與監控。⁴這樣的描述讓追蹤成為產品基礎元件，而不只是開發者儀器。

監督追蹤應回答5個問題：

追蹤不需要私人推理。它需要操作證據。使用者不需要隱藏的思維鏈來評估一次發布。使用者需要的是命令輸出、路由狀態、快取狀態、D1資料列、翻譯關口、來源檢查，以及仍待母語審查的缺口。

這個區分同時保護信任與品味。顯示太多內部細節會讓介面充滿噪音。顯示太少則會讓產品變成表演。

復原應該如何融入流程？

復原應該放在失敗事件旁邊。

代理系統在一般工作中經常失敗：安裝命令逾時、格式化工具改到無關檔案、瀏覽器冒煙測試發現過期快取、翻譯關口拒絕某個語系，或來源連結對腳本回傳403。好的監督介面會把這些時刻視為預期狀態。

復原控制應保持具體：

OpenAI的Codex app公告描述了代理如何在隔離的程式碼副本中工作，讓使用者能探索不同路徑，並在某個代理繼續工作時，將變更取回本機。¹這種隔離有助於復原，但介面仍需顯示哪條路徑勝出、哪條路徑失敗，以及哪些工作仍不適合合併。

產品不應讓使用者從原始記錄中重建復原流程。失敗步驟本來就知道自己的命令、工作目錄、輸出與目標。介面應該把負責任的下一步動作放在該事件上。

什麼讓監督介面值得存在？

當監督介面能減少工作、但不降低責任時，它才值得存在。

簡單版本只是增加更多面板。值得存在的版本會消除疑慮。使用者應該能更快回答真正重要的問題：

• 哪個執行作業需要我？
• 哪個動作可能造成損害？
• 哪個結果有證據？
• 哪個結果只有文字說法？
• 哪個分支應該保留下來？
• 哪個缺口尚未解決？

NIST的AI風險管理框架把可信賴性視為團隊應納入AI產品與系統之設計、開發、使用與評估的事項。⁷監督介面正位於這個交會點。它讓設計承擔操作風險，讓使用產生證據，並在使用者簽核前讓評估可見。

MCP也擴大了同一份責任。Model Context Protocol會把AI應用程式連接到外部資料來源、工具與工作流程，讓代理能存取資訊並執行任務。⁸連接的工具越多，行動介面就越大。更大的行動介面需要更好的監督，而不是更多信任。

設計標準應保持簡單：代理產品不應最大化自主行動，而應最大化可問責的進展。

要如何開始建置？

從最小但有用的監督介面開始：

1. 執行清單：每個活躍代理一列，包含階段、耗時、阻礙與下一個決策。
2. 核准佇列：每個敏感工具呼叫一個物件，包含引數、目標、風險，以及核准/拒絕/延後控制。
3. 追蹤表格：每個有意義的事件一列，可依讀取、寫入、終端機、瀏覽器、來源、測試、部署與審查篩選。
4. 證據面板：最終結果的一張主張對證據表。
5. 復原選單：從失敗事件直接執行暫停、繼續、重試、分叉與帶缺口關閉。

第一版可以看起來樸素。表格、篩選器、徽章與可展開列，都勝過把風險藏起來的優雅逐字稿。品味問題要等資訊架構誠實之後再處理：降低噪音、保留警示色、分組低風險事件、暴露高風險酬載，並讓最終簽核始終綁定證據。

代理式設計就是控制介面設計。 代理介面就是操作層。 HTML能保留Markdown會丟失的空間資訊。 監督介面結合了這些框架：它們把自主工作轉化為可檢查、有空間結構、可問責的作業。

快速總結

代理需要的不是更好的逐字稿，而是監督介面。嚴肅的代理介面需要執行佇列、核准佇列、追蹤時間軸、證據面板與復原控制。OpenAI、Anthropic、Microsoft、NIST與MCP文件都指向同一種產品形態：自主系統需要可見狀態、工具治理、可審查追蹤，以及在正確層級發生的人類決策。^1345678

聊天可以繼續作為委派通道。監督必須成為工作介面。

FAQ

什麼是代理監督介面？

代理監督介面是用來監控與控制自主代理工作的UI。它顯示執行狀態、待核准項目、工具追蹤、證據、失敗與復原控制。聊天收集意圖。監督介面則協助操作員決定代理下一步可以做什麼，以及結果是否值得簽核。

為什麼聊天不足以支援AI代理？

聊天是循序且只能追加的。代理工作需要隨機存取狀態、風險、核准、追蹤、差異內容、測試輸出與未解缺口。逐字稿可以記錄這些事件，卻無法依風險排序，也無法在平行代理之間導引人類注意力。

團隊應該先建置什麼？

團隊應先建置執行佇列與核准佇列。這兩個介面會立刻揭露受阻工作與敏感動作。接著加入追蹤表格，因為證據、復原與最終審查都仰賴事件記錄。

監督介面和可觀測性有何不同？

可觀測性協助建置者除錯系統。監督則協助操作員在工作發生時治理工作。兩者共享資料，但服務不同使用者。正式環境追蹤可以同時供應開發者除錯視圖，以及人類核准介面。

每個代理都需要人類核准嗎？

不需要。每個代理都需要校準過的監督。低風險讀取可以靜默執行。中風險變更可以批次審查。高風險動作應暫停等待核准。公開發布、破壞性命令、影響客戶的動作與金錢移動，都需要更強的關口。

參考資料