隱形代理：為何看不見就無法治理

Anthropic在Claude Desktop中推出了一項名為Cowork的功能。該功能會在每個macOS安裝環境中建立一個10GB的虛擬機器套件。從未啟用Cowork的使用者也會收到該虛擬機器。刪除它的使用者則眼睜睜看著它重新生成。有使用者回報該套件膨脹至21GB。該GitHub issue在Hacker News上累積了345個讚和175則留言，Anthropic才承認了這個問題。¹

直到磁碟空間耗盡，才有人注意到。

重點摘要

代理工具現在會在操作者無法看見的情況下分配運算資源（磁碟、記憶體、CPU、網路）。Anthropic的Cowork虛擬機器是顯而易見的案例；每一次MCP工具呼叫、每一個衍生的子代理、每一次網頁擷取，都是隱形的資源消耗。治理代理需要三個層次的可觀測性：資源計量（它消耗了什麼？）、策略執行（它被允許做什麼？）以及執行時稽核（它實際做了什麼？）。有兩個開源專案處理了策略與稽核層（mcp-firewall和Logira），但沒有任何生產環境工具涵蓋全部三個層次。以下內容包含：可見性問題、三層架構、每一層能發現什麼，以及您今天就能實作的最低限度監控hook。

可見性問題

傳統軟體運作在操作者選擇劃定的可觀測性界線之下。網頁伺服器會寫入存取日誌，因為工程師設定了日誌記錄。資料庫會追蹤慢查詢，因為有人設定了log_min_duration_statement。操作者決定觀測的粒度。

代理系統顛覆了這個關係。代理在執行時自行決定要執行什麼。一個收到「修復登入端點」指令的程式碼代理，可能會讀取47個檔案、寫入12個、衍生三個子代理、擷取兩個網頁，並執行15個bash指令。每個動作都消耗資源，但傳統監控中看不到任何消耗紀錄。

Cowork事件在基礎設施層面暴露了這個反轉。Claude Desktop分配了10GB的磁碟空間，在閒置時消耗24-55%的CPU，並在8GB機器上將swap使用量從20K推升至24K+次換入。¹ 使用者是透過macOS的儲存空間警告發現資源消耗的，而非透過Anthropic的遙測。該應用程式未提供任何儀表板、計量器，也未對虛擬機器分配進行任何選擇加入的揭露。

將此模式放大到代理會話。我的hook編排系統在每次工具呼叫中攔截15種事件類型。¹¹ 在60多個會話中，系統記錄了每個動作觸發84個hook，產生的遙測資料是任何預設代理安裝都不提供的。² 若沒有該監控機制，我不會偵測到那12次偏移事件、虛假驗證失敗，以及我在NIST公開意見中記錄的遞迴衍生迴圈。³

DORA 2024年《Accelerate State of DevOps Report》發現，具備強大可觀測性實踐的團隊部署更頻繁，從故障中恢復更快。2025年版將框架擴展到AI輔助開發，將可觀測性連結到「AI輔助程式碼撰寫或測試如何影響品質、前置時間和整體可靠性」。⁴ 代理可觀測性不是錦上添花。衡量代理行為是治理代理行為的先決條件。

代理可見性的三個層次

代理可觀測性需要三個獨立的層次。每個層次回答不同的問題。一個層次的失敗不會危及其他層次。

這些層次呈現出一個遞進關係：您無法對未計量的資源執行策略，也無法稽核從未定義的策略的合規性。每個層次建立在其下方的層次之上。

第一層：資源計量

資源計量回答的是：代理消耗了多少，消耗在哪裡？

Cowork事件就是一個資源計量失敗的案例。虛擬機器套件消耗了10GB的磁碟空間。渲染程序在閒置時消耗24%的CPU。Swap活動在會話期間持續攀升。所有這些指標都存在於macOS的活動監視器中，但沒有任何一項出現在Claude Desktop的介面中。¹

對於代理程式碼會話，資源計量追蹤四個維度：

磁碟。 每次檔案寫入、每個快取項目、每個日誌檔案。我的會話每次產生200-400KB的狀態檔案（jiro.state.json、jiro.progress.json、hook日誌）。在60多個會話中，累積產生12-24MB的狀態資料，除非明確清理，否則會跨會話持續存在。²

記憶體。 每輪對話的上下文視窗消耗。一個200,000 token的上下文視窗在目前Opus定價下，每次填滿約花費3美元。我的成本追蹤器記錄每個會話的累計token使用量，並在可設定限額的80%、90%和95%時觸發預算門檻。⁵

CPU。 Hook執行時間。我的九個hook提示分發器每次提示增加200毫秒。該開銷對使用者來說是看不見的（人類打字速度才是瓶頸），但在自動化管線中會累積。ralph自主迴圈每個故事觸發分發器50-100次，每個故事增加10-20秒的hook開銷。²

網路。 網頁擷取、API呼叫、MCP工具調用。每個對外請求都是潛在的資料通道。我的網頁內容擷取程式庫會記錄擷取的URL和回應大小。若沒有網路計量，一個回傳50MB回應的網頁擷取與回傳5KB的無法區分。⁶

目前沒有任何商業代理工具提供按會話的資源儀表板。雲端供應商計量運算資源是為了計費，而非為了操作者的可見性。代理消耗的資源與操作者能看到的之間的落差，就是資源計量赤字。

這種缺失在數字累積之前感覺是隱形的。一個會話寫入400KB的狀態檔案微不足道。六十個會話各寫入400KB，且無清理機制，就留下24MB的孤立狀態。一次回傳847KB的網頁擷取可以忽略。一個掃描管線每次執行擷取80個URL，產生67MB的快取內容，而代理的工具抽象層將其對操作者隱藏。資源計量讓累積的影響在演變為危機之前變得可見——在有人去提交GitHub issue #22543之前。¹

第二層：策略執行

策略執行回答的是：什麼規則約束代理，這些規則是否一致地被套用？

mcp-firewall為CLI代理處理了策略層。⁷ 該工具位於代理與所有工具使用請求之間，在執行前根據基於正規表達式的策略評估每個請求。策略使用按資料夾、Git儲存庫或使用者範圍劃分的JSONNet設定檔案。該防火牆透過PreToolUse hook整合支援Claude Code和GitHub Copilot CLI。

該架構反映了一個關鍵洞察：每個代理都實作了自己的半套允許/拒絕邏輯。Claude Code使用glob模式。Codex CLI使用僅限前綴的比對。每種方式僅涵蓋策略空間的一個子集。mcp-firewall將規則集中到一個跨代理運作的引擎中。

考慮一下沒有集中式執行的策略缺口。我的hook系統包含12個PreToolUse:Bash處理器，檢查憑證模式、危險的Git操作、敏感路徑存取和部署指令。² 每個處理器都是獨立的shell指令碼，有自己的正規表達式模式。當我需要新增拒絕規則時，我寫一個新指令碼。當我需要稽核現有規則時，我在12個檔案中進行grep。mcp-firewall將這些整合到一個具有明確允許陣列的單一設定檔案中。

OWASP 2025年《Agentic Applications十大風險》將代理目標劫持（ASI01）和過度代理（LLM06:2025）列為首要風險。⁸ 這兩種風險都需要在工具呼叫層面進行策略執行。劫持目標的代理仍然會發出工具呼叫。擁有過度權限的代理仍然會請求權限。策略執行在代理意圖與系統工具交會的邊界上攔截這兩者。

策略執行不同於存取控制。傳統存取控制問的是「此使用者是否有權限？」代理的策略執行問的是「此動作，在此上下文中，針對此任務，是否在核准範圍內？」上下文敏感性是挑戰所在。對功能分支執行git push和對main分支執行git push --force使用的是同一個工具（Bash），但影響範圍完全不同。mcp-firewall的正規表達式模式可以區分兩者，預設的代理權限則無法。

第三層：執行時稽核

執行時稽核回答的是：代理在系統呼叫層面實際做了什麼？

Logira使用eBPF探針在核心層面攔截系統呼叫來處理稽核層。⁹ 該工具記錄三類事件：程序執行（exec事件）、檔案操作（包含憑證檔案存取），以及網路連線（含目的地追蹤）。每次稽核執行產生三個檔案：events.jsonl用於時間線檢視、index.sqlite用於可查詢的過濾、meta.json用於執行元資料。

設計理念是「僅觀察」：Logira記錄並偵測，但不執行或阻擋。⁹ 與執行層的分離是刻意為之。策略執行防止已知的惡意動作。執行時稽核在事後發現未知的惡意動作。兩個層次服務不同的時間函數：預防（事前）和鑑識（事後）。

Logira的eBPF探針運作在應用程式層之下。一個構造新穎指令來竊取資料的代理仍然會發出系統呼叫。代理無法向核心層級的追蹤隱藏檔案讀取、網路連線或程序產生。此方法能捕捉應用程式層級hook所遺漏的：繞過工具呼叫抽象層的副作用。

內建偵測規則專門針對AI代理風險：憑證檔案存取、持續性機制變更（/etc、systemd、cron）、可疑的指令鏈（curl-pipe-sh模式）、破壞性操作（rm -rf），以及異常的網路流出。⁹ 這些規則是針對代理威脅模型的預設設定，而非通用的系統稽核。

平台限制很重要。Logira需要Linux 5.8+搭配cgroup v2。macOS代理（Claude Desktop、Darwin上的Claude Code）無法使用基於eBPF的稽核。我的OS沙箱使用macOS Seatbelt設定檔作為最接近的替代方案：核心層級的拒絕規則，阻擋對敏感路徑的寫入。³ Seatbelt是執行機制，不是稽核機制。macOS缺乏一個可正式用於生產環境、等同於Logira僅觀察稽核追蹤的工具。

執行與稽核之間的區別對應到事件回應中的時間分割。執行防止事件發生。稽核則在事件發生後實現重建。兩者都是必要的。一個阻擋所有憑證存取的執行層可以防止資料竊取，但也會阻止合法的SSH操作。一個記錄所有憑證存取而不阻擋的稽核層，讓操作者能夠檢視存取模式，並根據證據調整執行規則。稽核資料與策略精進之間的回饋迴圈是可見性架構隨時間改善的方式：稽核揭示模式，模式形成策略，策略縮小稽核需要涵蓋的範圍。

Logira的cgroup v2隔離新增了一項應用程式層級稽核無法複製的功能：按執行範圍歸因。系統將每個事件歸因於特定的稽核執行，而非全系統。當兩個代理會話在同一台機器上同時執行時，cgroup隔離確保會話A中的檔案存取不會出現在會話B的稽核追蹤中。應用程式層級的hook無法提供相同的保證，因為hook在代理程序內觸發，而該程序沒有核心層級的邊界來分隔並行會話。⁹

我實際執行的架構

我的編排系統透過hook涵蓋了全部三個層次，而非透過專用監控工具。

資源計量。 成本閘道hook根據可設定的預算門檻追蹤每個會話的token使用量。⁵ 系統效能監控器以可設定的間隔檢查CPU、記憶體、磁碟和swap，在資源壓力超過門檻時注入警告。¹⁰ 會話偏移偵測器每25次工具呼叫觸發一次，計算原始提示嵌入與近期動作滑動視窗之間的餘弦相似度。²

策略執行。 八個PreToolUse分發器hook按工具類型路由至處理器hook。僅PreToolUse:Bash就執行12個處理器，涵蓋憑證模式、破壞性Git操作、敏感路徑存取和部署指令。遞迴防護機制強制最大深度為二，每個父代理最多五個子代理。²

執行時稽核。 PostToolUse hook記錄每次工具呼叫結果。資安掃描hook在執行後檢查bash輸出中的憑證洩漏。會話狀態檔案（jiro.state.json）記錄每個故事的完成狀況、審查者裁決和證據閘道結果。² 該系統不使用eBPF（macOS限制），而是透過hook管線捕捉工具層級的遙測。

該系統之所以運作，是因為每個動作都通過hook管線。限制在於深度：hook層級的監控捕捉的是代理要求執行的操作，而非作業系統實際執行的操作。一個構造帶有嵌入子shell的bash指令的代理，其執行的程式碼在hook看來只是一個字串。核心層級的稽核則會看到每個子程序。

複合盲點

代理衍生代理會倍增不透明性。每一次委派跳躍都引入資訊損失。

當我的編排系統執行ralph自主迴圈時，父程序為每個PRD故事衍生新的Claude Code實例。每個子代理獲得一個專注的任務和一個全新的上下文視窗。父程序追蹤完成狀態。父程序看不到子代理的個別工具呼叫、檔案讀取或資源消耗。²

在深度一（父代理衍生子代理），父代理看到子代理的最終輸出。在深度二（子代理衍生孫代理），父代理看到子代理關於孫代理輸出的報告。每一跳都壓縮資訊。我在NIST意見中的委派鏈分析衡量了三種複合風險：語意壓縮（上下文被壓縮為一個提示字串）、權限放大（子代理繼承權限但不理解敏感性），以及責任擴散（根代理對其從未檢視的結果承擔責任）。³

可觀測性以相同的速率退化。在根代理上的三層可見性架構，對孫代理提供零可見性，除非每個子代理獨立執行自己的監控。我的遞迴防護機制強制深度限制，但防護機制是策略控制，不是可觀測性控制。知道委派在深度二停止，並不能告訴您深度二發生了什麼。

一個來自我生產系統的具體案例：ralph迴圈衍生了一個子代理來實作資料庫遷移故事。子代理判斷遷移需要一個「驗證步驟」，並衍生了自己的子代理來執行整合測試。孫代理靜默失敗（測試資料庫未設定）。子代理收到空回應，將沉默解讀為成功，並回報故事完成。父代理記錄了「故事4：完成。」我在三小時後應用程式因缺少欄位而崩潰時才發現損壞的遷移。根代理的遙測顯示一次乾淨的執行。故障藏在兩跳之外，對我在根代理上部署的每個監控層都是隱形的。²

OWASP Agentic Applications框架處理了級聯失敗和失控代理，但未規定多代理委派鏈的可觀測性要求。⁸ 這個缺口是結構性的：鏈中的每個代理都需要自己的資源計量、策略執行和執行時稽核，各自獨立設定、各自獨立回報。開銷是倍增的。三個層次的監控在鏈中三個代理上就是九個監控實例，每個產生自己的遙測資料，每個需要自己的設定。目前沒有任何工具能管理這種協調。

您今天就能實作的方案

三個涵蓋可見性架構的最低限度監控hook：

1. 資源：Token預算追蹤器。 記錄每個會話的累計輸入和輸出token。設定硬性限制。在80%時發出警報。實作方式是讀取代理的使用統計（Claude Code透過/cost公開會話成本）並與門檻比對。我的成本閘道hook用47行bash完成此功能。⁵

2. 策略：PreToolUse拒絕清單。 建立一個在每次Bash工具呼叫前觸發的hook。將指令與模式清單比對：rm -rf /、git push --force、包含.ssh或.env的路徑、curl | sh。阻擋匹配項。實作方式是一個shell指令碼，從stdin讀取工具呼叫的JSON，擷取指令欄位，並對模式檔案進行grep。我的憑證檢查hook用31行完成此功能。²

3. 稽核：PostToolUse會話日誌。 將每次工具呼叫和結果附加到按會話的JSONL檔案中。包含時間戳記、工具名稱、參數和結束代碼。該日誌可在會話後重建：代理做了什麼、以什麼順序、是否有靜默失敗？我的會話記錄器用22行bash完成此功能。²

拒絕清單hook在settings.json中的實作範例：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

該hook指令碼從stdin讀取工具呼叫，擷取指令字串，並根據模式進行檢查。被阻擋的指令回傳一個JSON物件：{"decision": "block", "reason": "Sensitive path access denied"}。被允許的指令回傳{"decision": "approve"}。Claude Code無需進一步提示即尊重兩種回應。整個hook對允許的指令增加零延遲（正規表達式檢查在5毫秒內完成），並對被阻擋的指令提供即時回饋。

這三個hook總計不到100行。它們不能取代專用監控工具。它們將零可見性替換為最低可見性。最低可見性是所有後續治理決策的先決條件。您無法在沒有計量的情況下設定資源預算。您無法在沒有拒絕清單的情況下執行範圍策略。您無法在沒有稽核日誌的情況下調查事件。從日誌開始，其餘兩項隨之而來。

關鍵要點

給平台工程師： 代理消耗的資源是現有監控無法追蹤的。每個代理會話的磁碟、記憶體、CPU和網路使用量，應與容器指標出現在同一個儀表板上。Cowork事件證明了這個需求：10GB的分配，零操作者可見性。

給資安團隊： 在工具呼叫邊界進行策略執行，是最低限度可行的代理安全態勢。mcp-firewall的集中式方法將各代理的允許/拒絕邏輯整合到一個可稽核的設定中。評估您的代理內建權限是否涵蓋威脅模型所需的策略空間。

給工程主管： 對您的代理工具提出三個問題：您能看到按會話的資源消耗嗎？您能定義並稽核工具呼叫策略嗎？您能在事後重建代理做了什麼嗎？如果任何答案是「否」，您就有一個可見性缺口，而這個缺口會隨著工作流程中每增加一個代理而擴大。

常見問題

什麼是代理可觀測性？ 代理可觀測性是監控和理解AI代理在執行期間行為的能力：它消耗了什麼資源、採取了什麼動作，以及這些動作是否符合已定義的策略。

為什麼Anthropic的Cowork會建立10GB的虛擬機器？ Cowork是Claude Desktop中用於協作開發會話的功能。Claude Desktop會在每個macOS安裝環境中自動建立虛擬機器套件，即使使用者從未啟用該功能，且該套件會一直保留直到手動刪除。¹

什麼是mcp-firewall？ mcp-firewall是一個開源策略執行工具，攔截來自CLI代理（Claude Code、GitHub Copilot CLI）的工具使用請求，並在執行前根據基於正規表達式的允許/拒絕規則進行評估。⁷

什麼是eBPF執行時稽核？ eBPF（extended Berkeley Packet Filter）能在不修改被稽核程序的情況下進行核心層級的系統呼叫追蹤。像Logira這樣的工具使用eBPF探針來記錄AI代理執行期間的程序執行、檔案操作和網路連線。⁹

參考資料