聊天是 AI 代理的錯誤介面

聊天是良好的輸入原語，卻是糟糕的代理操作環境。當軟體開始長時間運作——維護狀態、呼叫工具、做出決策、失敗後恢復——介面就必須從對話轉向操作。以下六種介面模式定義了代理控制面板的真正需求。

多數 AI 代理以聊天視窗形式推出。Claude Code 是終端機對話，Cursor 是編輯器對話，Codex 在雲端執行對話，Devin 則將對話包裹在瀏覽器、終端機和編輯器之外。對話框架主導一切，「跟 AI 說話」已成為「使用 AI」的同義詞。當互動模式還是提示-回應時，這個隱喻合情合理：你問，它答，你評估。一輪、兩輪，頂多十輪。

但當代理開始自主運作，這個隱喻便徹底崩塌。

我的 Ralph 迴圈讓 Claude Code 整夜運行。每次迭代都從全新上下文開始，透過檔案系統在工作階段之間保留記憶，停止鉤子防止過早終止。單次過夜執行產生 8 至 15 次迭代，每次都使用完整的 200K token 上下文視窗。系統在多次無人看管的工作階段中交付了 3,455 行生產級 Python。¹要透過滾動聊天紀錄來監督這些工作階段，意味著閱讀數千行交錯的工具呼叫、檔案差異和推理軌跡。沒有人這樣做，也沒有人做得到。聊天介面在自主操作的重壓下徹底崩潰。

實踐者正逐漸認識到聊天隱喻的謬誤。OpenAI 的 Codex 在雲端無介面執行，回傳完成的成果。Anthropic 的 Claude Routines 執行多步驟工作流程，並提供可審閱的工作階段。Devin 將螢幕分割為瀏覽器、終端機、編輯器和聊天四個面板。每款產品都在遠離純粹對話，朝向更具操作性的方向發展，但沒有任何一款抵達完整的解決方案。「附帶檔案差異的聊天」與「代理操作儀表板」之間的鴻溝，仍然是 AI 工具領域中最大的未解 UX 難題。

聊天失敗的五個原因

缺乏軌跡時間軸

一個 90 分鐘的代理工作階段會產生數百個事件：檔案讀取、檔案寫入、bash 指令、搜尋查詢、子代理生成、壓縮事件和推理步驟。聊天將這些事件以線性對話捲軸呈現，使得「第 30 分鐘到第 45 分鐘之間發生了什麼？」這個問題，若不逐行閱讀中間的所有內容就無法回答。

我的鉤子系統攔截每次工具呼叫中的 15 種事件類型，產生聊天介面無法呈現的結構化遙測資料。²遙測資料存在，視覺化卻不存在。當我除錯失敗的過夜工作階段時，我用 grep 搜尋日誌檔案，而不是滾動聊天紀錄。

軌跡時間軸會將事件以可篩選、可縮放的序列呈現。只顯示檔案寫入、只顯示修改了檔案系統的 bash 指令、只顯示代理選擇路徑 A 而非路徑 B 的決策點。飛行資料記錄器不會將駕駛艙事件以對話紀錄呈現，代理介面也不應如此。

缺乏權限審核介面

Claude Code 的權限模型會中斷對話以請求核准。「允許此 bash 指令？」與代理的推理內容一同出現，使用者必須從閱讀分析切換到評估風險。這種中斷模型適用於互動式工作階段，卻完全不適合自主操作——代理需要的是批次核准和分級權限。

我的 95 個鉤子充當程式化的權限層。白名單指令靜默通過，封鎖的模式則停止執行。鉤子解決了自動化問題，但它以程式碼而非介面來解決。³權限閘道 UI 應將待審核項目以佇列呈現，依風險等級排序，一鍵核准或拒絕。高風險操作（強制推送、生產部署、破壞性指令）的呈現方式應與低風險操作（檔案讀取、搜尋查詢）截然不同。介面應在使用者評估內容之前，先傳達風險。

缺乏記憶瀏覽器

上下文壓縮會抹除代理所知的內容。200K token 視窗填滿後，系統摘要先前的輪次，資訊隨之消失。我在 50 個工作階段中的測量顯示，輸出品質在上下文使用率約 60% 時便開始退化，遠在硬性限制觸發壓縮之前。⁴來自 Microsoft Research 和 Salesforce 的記憶退化研究證實了這個結構性問題：在 15 個 LLM 和超過 200,000 次模擬對話中，從單輪到多輪互動的平均效能下降 39%。⁵

使用者無法得知哪些內容在壓縮中倖存、哪些消失了。代理是否忘記了 40 分鐘前建立的 API 契約？模組依賴圖是否在上次摘要中保留下來？聊天介面無法回答這些問題。記憶瀏覽器應顯示代理目前保留在上下文中的內容、已壓縮的內容、已遺失的內容，以及在工作階段之間持久化於檔案系統中的記憶。Ralph 迴圈的檔案系統即記憶模式可以彌補壓縮損失，但操作者仍然無法在不閱讀原始狀態檔案的情況下檢視代理的工作記憶。

缺乏上下文預算計量器

Token 消耗是不可見的。使用者不知道上下文視窗已填滿 40% 還是 90%。耗盡的第一個徵兆是輸出品質退化：遺忘指令、重複建議、從多檔案協調退化為單檔案隧道視野。⁴當使用者察覺時，品質損害已在數輪對話中累積擴大。

上下文預算計量器應即時顯示 token 使用量、根據當前任務消耗率預估的耗盡時間，以及壓縮閾值。它的功能如同燃油錶：不需要每秒查看，但在承諾執行長時間操作前不可或缺。「此重構任務預計消耗約 80K token；您的剩餘預算為 60K」——這會改變使用者的決策判斷。目前沒有任何聊天介面提供此資訊。

缺乏工具呼叫審計

代理執行工具時使用的參數，使用者從未檢視。Bash 指令執行了、檔案寫入了、API 被呼叫了。聊天介面顯示工具名稱，有時顯示輸出結果。但參數（代理實際發送給工具的指令）以不鼓勵閱讀的格式一閃而過。

這並非假設性的失敗模式。一位開發者回報 Claude Code 刪除了整個生產環境設置，包括資料庫和 2.5 年的快照。⁶代理在沒有確認提示、沒有鉤子攔截的情況下執行了破壞性指令。這起事件追溯到介面的失敗：使用者無法有效地審閱代理即將執行的操作。

工具呼叫審計介面應呈現每次工具調用的完整參數、檔案操作的前後差異，以及破壞性操作的回滾功能。證據閘門在輸出層解決驗證問題，要求代理在標記工作完成前引用檔案路徑、測試結果和模式名稱。工具呼叫審計則在執行層解決同樣的問題——在損害發生之前。

代理操作的六種介面模式

聊天之所以失敗，是因為它將代理操作視為對話。以下六種模式將代理操作視為操作。

1. 軌跡時間軸

按時間排列的事件日誌，每個節點都可展開查看細節。每次檔案讀取、檔案寫入、bash 指令、API 呼叫、子代理生成、壓縮事件和決策點都會出現在時間軸上。使用者可依事件類型篩選、縮放至特定時間區間，並展開個別事件查看完整參數和輸出。

時間軸解決了「發生了什麼？」這個問題——目前事後除錯需要分析日誌檔案才能回答。隱形代理問題（代理在操作者不知情下消耗資源）在每個操作都附帶資源消耗指標出現在可篩選時間軸上時，便變得可見。

2. 權限閘道 UI

依風險等級排序的待審核佇列。破壞性操作（生產部署、資料庫遷移、強制推送）以紅色邊框顯示，需要明確確認。唯讀操作（檔案讀取、搜尋查詢）自動核准或批次核准。閘道介面顯示完整指令、風險評估，以及代理聲明的操作理由。

批次核准徹底改變了互動模式。過夜工作階段中不再中斷對話 47 次，權限閘道改為呈現「以下 12 項操作超過了您的自動核准閾值」，集中於單一審核介面。使用者在兩分鐘內處理全部 12 項，而非在六小時內切換上下文 12 次。

3. 記憶瀏覽器

三欄式顯示：活躍上下文（代理目前持有的內容）、壓縮摘要（何時壓縮了什麼）、檔案系統記憶（工作階段之間持久化於磁碟的內容）。每一欄皆可搜尋。使用者可以將已壓縮的項目提升回活躍上下文，或將檔案系統記憶標記為過時。

瀏覽器讓代理的知識狀態變得可檢視。當代理產出與先前決策矛盾的結果時，操作者可以檢查先前的決策是否在壓縮中倖存。代理記憶退化問題不會因瀏覽器而消失，但瀏覽器讓退化變得可見、可診斷，且部分可恢復。

4. 上下文預算計量器

即時 token 計數器，顯示當前使用率、根據滾動消耗率預估的耗盡時間，以及壓縮閾值。計量器包含細項分解：多少 token 是系統提示、多少是對話歷史、多少是工具輸出、多少是檔案內容。細項揭示預算的去向——通常工具輸出消耗了 60-70% 的視窗。

計量器改變行為。我的上下文視窗管理實踐（主動壓縮、子代理委派、基於檔案系統的記憶）源自對 50 個工作階段的 token 消耗測量。即時計量器將同樣的測量結果即時提供給每位使用者，將上下文管理從專家技能轉變為可見的資源限制。

5. 工具呼叫審閱

每次工具調用的檢視介面。檔案操作顯示前後差異，bash 指令顯示完整指令、工作目錄和退出碼，API 呼叫顯示請求和回應負載。每次工具呼叫都附帶回滾按鈕——可逆操作直接復原，不可逆操作則標記待人工審閱。

審閱介面兼具雙重功能：互動式工作階段中的即時監督，以及自主執行後的事後審計。暗工廠驗證層探討自主系統如何在無人在場時處理驗證。工具呼叫審閱則是有人在場的對應方案，提供檢視介面以實現知情信任，而非盲目信任。

6. 監督佇列

多代理儀表板，跨並行工作階段呈現優先警報。當同時執行多個代理（重構代理、測試撰寫代理、文件代理）時，佇列彙總狀態、標示失敗，並將需要人工介入的決策導向單一介面。

監督佇列之所以重要，在於代理使用是水平擴展的。一位開發者執行一個代理是對話；一位開發者同時在五個任務上執行五個代理，那就是操作。操作的介面是儀表板，不是五個聊天視窗。佇列依緊急程度排序：失敗的生產部署排在文件格式問題之上。

現有方案

目前沒有產品建立了完整的操作儀表板。但已有數個產品建立了部分元件。

Claude Code 提供了最強大的程式化層。鉤子攔截 15 種事件類型，支援允許/拒絕/修改決策。/cost 指令顯示工作階段 token 使用量。CLAUDE.md 上下文系統提供檔案系統記憶。但介面是終端機，沒有視覺化時間軸、沒有權限佇列、沒有記憶瀏覽器。基礎設施存在，介面卻不存在。⁷

Cursor 建立了行內差異，一種針對檔案操作的原始工具呼叫審閱。差異介面顯示前後狀態，支援區塊級別的接受/拒絕。模式正確但範圍狹窄：差異涵蓋檔案寫入，但未涵蓋 bash 指令、API 呼叫或子代理協調。

Devin 最接近操作 UI。產品將螢幕分割為瀏覽器、終端機、編輯器和聊天四個面板，讓代理行為的不同面向同時可見。面板佈局承認了單純對話的不足。但面板是展示，不是控制介面。使用者觀看代理工作，卻無法透過這些面板排隊核准、檢視記憶狀態或審計工具參數。⁸

Claude Routines（2026 年 4 月推出）在背景執行多步驟工作流程，每次執行都建立可審閱的 Claude Code 工作階段。審閱介面就是軌跡時間軸：使用者可以事後審閱代理的操作。這個模式驗證了核心論點：背景執行需要一個不同於原始對話的審閱介面。⁹

OpenAI Codex 在雲端無介面執行，回傳差異。隔離模型（每個任務一個沙箱環境）消除了部分權限疑慮，卻引入了新的問題：使用者以放棄所有即時監督為代價，換取沙箱安全性。沒有專用的操作時間軸或執行中控制介面。這種取捨揭示了設計張力：完全自主或完全監督，中間沒有過渡。¹⁰

這些局部解決方案與完整代理操作介面之間的差距，定義了 AI 工具領域的下一個競爭前沿。

代理介面是設計問題

上述介面模式是工程規格。建構它們需要工程規格本身無法提供的設計判斷力。

權限閘道如何傳達風險？僅靠顏色不夠：紅色在西方文化中代表「危險」，在中華文化中卻代表「喜慶」。圖示選擇、空間配置、動畫時機和文案語調都會影響使用者的風險評估。一個技術上呈現了正確資訊、卻溝通不良的權限閘道，只會訓練使用者不加閱讀就點擊「核准」。閘道淪為形式。

上下文預算計量器如何傳達緊迫感而不引發焦慮？在 80% 使用率時變紅的計量器可能導致過早壓縮，保持綠色直到 95% 的計量器可能導致突然耗盡。閾值曲線、色彩漸變和通知時機都是具有操作後果的品味決策。

軌跡時間軸如何處理資訊密度而不壓垮使用者？12 小時的自主工作階段產生數千個事件。顯示所有事件是噪音，篩選至「重要」事件則需要介面定義何謂重要——這個判斷因使用者、任務和失敗模式而異。

這些問題與 Dieter Rams 為消費電子產品回答的問題、原研哉為資訊設計回答的問題一脈相承。問題不新，領域是新的。品味是技術系統：約束、評估準則、模式識別和一致性檢查，可分解為工程基礎設施。代理介面設計需要專為操作 UX 打造的品味基礎設施：在時間壓力下透過視覺介面傳達風險、信心、不確定性和資源狀態，以支援快速決策的能力。

將代理介面視為設計問題而非僅是功能清單的公司，將打造出操作者信賴用於生產工作負載的介面。僅將代理介面視為工程問題的公司，將打造出技術上完備、操作上卻無法使用的儀表板。

下一道護城河

模型不是護城河。前沿模型每季在能力基準上趨同。微調和 RLHF 帶來有意義但短暫的差異化。模型層是競爭優勢遞減的商品化競賽。¹¹

上下文層也不是護城河。上下文視窗從 128K 成長到 200K 再到 1M token，每家供應商在數月內跟進。更長的上下文提升能力，但無法形成產品差異化。

控制介面才是護城河。讓自主代理操作變得可見、可審計、可治理的介面——這個介面決定了企業信賴哪個產品來承擔生產工作負載。企業採用需要回答聊天介面無法回答的問題：代理做了什麼？為什麼這樣做？行使了哪些權限？消耗了哪些資源？能否回滾代理的操作？能否向審計人員證明代理做了什麼？

這些不是提示問題，而是操作問題。能回答這些問題的產品，贏得真正重要的市場。

我的 95 個鉤子是對這些問題的程式化回答，從終端機構建、透過 shell 腳本執行、透過設定檔維護。鉤子有效，但也代表了當前的技術前沿：非專家使用者無法複製的專家級基礎設施。證據閘門驗證代理輸出。隱形代理可觀測性層監控代理行為。上下文視窗管理實踐維護工作階段品質。每個系統都解決了真實的操作需求，每個系統都以程式碼而非介面的形式存在。

下一步顯而易見。將程式碼轉化為控制介面。將鉤子轉化為權限閘道。將遙測資料轉化為軌跡時間軸。將 token 測量轉化為預算計量器。將檔案系統記憶轉化為可瀏覽的知識狀態。將證據閘門轉化為工具呼叫審閱介面。

基礎設施已然存在，介面尚未誕生。建構介面是設計問題、工程問題，也是品味問題。三者兼備的團隊，將交付定義AI 工程下一個時代的產品。

常見問題

為什麼不改善聊天的格式就好？

改善格式只是治標。問題是結構性的：聊天是循序的、只能追加的媒介。代理操作需要隨機存取檢視（跳至任意事件）、並行視圖（同時查看記憶狀態和工具呼叫），以及批次互動（一次核准五項操作）。在聊天內改善格式（可摺疊區段、語法高亮、行內差異）有些許幫助，但無法在滾動紀錄中提供隨機存取、並行視圖或批次互動。

權限閘道能取代人類判斷嗎？

權限閘道是輔助判斷，以最適合快速且準確評估的格式呈現決策。閘道不做決定，而是帶著上下文呈現決策：完整指令、風險等級、代理的推理，以及潛在影響。人類之所以能更快、更準確地做出決定，是因為介面降低了從對話捲軸中提取相關資訊的認知負擔。

這些模式如何適用於非程式設計的代理？

每種模式都能推廣。客服代理需要軌跡時間軸（代理對客戶說了什麼？）、權限閘道（代理能否核發超過 500 美元的退款？）和工具呼叫審計（代理執行了哪些資料庫查詢？）。研究代理需要記憶瀏覽器（代理查閱了哪些來源？）和上下文預算計量器（還剩多少檢索容量？）。這些模式與領域無關，因為操作挑戰——可見性、權限、記憶、資源、審計、監督——是所有自主軟體共通的。

來源