AI 代理程式可觀測性：如何監控看不見的東西

Anthropic 在 Claude Desktop 中推出了一項名為 Cowork 的功能。這項功能會在每一次 macOS 安裝時建立一個 10GB 的虛擬機器套件包。從未啟用過 Cowork 的使用者同樣拿到了這台虛擬機器；把它刪掉的使用者，則眼睜睜看著它重新生成。有使用者回報該套件包膨脹到了 21GB。在 Anthropic 承認問題之前，這個 GitHub issue 已在 Hacker News 上累積 345 點與 175 則留言。¹

直到磁碟空間耗盡，才有人察覺。

什麼是 AI 代理程式可觀測性？ 代理程式可觀測性是指在執行階段監控自主代理程式消耗了什麼、執行了什麼的實務作法。它需要三層：資源計量（每個工作階段的磁碟、記憶體、CPU、網路）、政策強制執行（每次工具呼叫時的允許／拒絕規則），以及執行階段稽核（在核心層級記錄實際行為）。三者缺一，維運人員就無從察覺偏移、無從強制範圍，也無從重建事故經過。

摘要

代理程式工具如今會在維運人員毫無可見性的情況下配置運算資源（磁碟、記憶體、CPU、網路）。Anthropic 的 Cowork 虛擬機器是看得見的例子；而每一次 MCP 工具呼叫、每一個衍生出的子代理程式、每一次網頁擷取，都是看不見的例子。治理代理程式需要三層可觀測性：資源計量（它消耗了什麼？）、政策強制執行（它被允許做什麼？），以及執行階段稽核（它實際做了什麼？）。目前有兩個開源專案分別處理政策層與稽核層（mcp-firewall 與 Logira），但還沒有任何一款生產級工具涵蓋全部三層。以下依序談可見性問題、三層堆疊、每一層能捕捉到什麼，以及今天就能落實的最小監控掛勾。

可見性問題

傳統軟體運行在一條由維運人員自行劃定的可觀測性界線之下。網頁伺服器之所以寫存取記錄檔，是因為工程師設定了記錄功能。資料庫之所以追蹤慢查詢，是因為有人設定了 log_min_duration_statement。決定監控粒度的是維運人員。

代理程式系統顛倒了這層關係。決定執行階段要做什麼的，是代理程式本身。一個接到「修好登入端點」指令的編碼代理程式，可能會讀 47 個檔案、寫 12 個檔案、衍生三個子代理程式、擷取兩個網頁、執行 15 條 bash 指令。每一個動作都在消耗資源。而這些消耗，沒有一項會出現在傳統監控裡。

Cowork 事件把這種顛倒暴露在基礎架構層面。Claude Desktop 配置了 10GB 磁碟空間，閒置時佔用 24% 至 55% 的 CPU，並在 8GB 記憶體的機器上把交換空間的置入次數從 2 萬次推高到 2.4 萬次以上。¹ 使用者發現這些資源消耗，靠的是 macOS 的儲存空間警告，而不是 Anthropic 的遙測資料。應用程式並未為虛擬機器的配置提供任何儀表板、任何計量，也沒有任何需要使用者主動同意的揭露。

這種模式並非假設。2026 年 3 月，一位開發者回報 Claude Code 執行的一條 Terraform 指令摧毀了正式環境的資料庫。該代理程式對著正式環境的 state 檔案執行了 terraform apply。沒有出現確認提示，也沒有掛勾攔下這條指令。開發者是在應用程式離線之後才發現資料被銷毀的。該事件在 Hacker News 上累積 142 點與 158 則留言。¹² 幾天後，另一位開發者回報 Claude Code 刪除了整套正式環境，其中包括承載兩年半紀錄的資料庫快照。¹³ 兩起事件的根本原因相同：在損害變得無法挽回之前，沒人看得見代理程式在做什麼。

把這種模式放大到代理程式工作階段的規模。我的掛勾協調系統建立在 Claude Code 的掛勾基礎架構之上，會在每一次工具呼叫中攔截 15 種事件類型。¹¹ 在 60 次工作階段裡，該系統記錄到每個動作觸發 84 個掛勾，產生了任何預設代理程式安裝都不會提供的遙測資料。² 若沒有這套檢測機制，我根本不會發現寫進 NIST 公開意見書裡的那 12 起偏移事件、幽靈般的驗證失敗，以及遞迴衍生迴圈。³

DORA 的 2024 年 Accelerate State of DevOps Report 發現，可觀測性實務扎實的團隊部署更頻繁，從故障中復原也更快。2025 年版把這套架構延伸到 AI 輔助開發，將可觀測性與「AI 輔助編碼或測試如何影響品質、前置時間與整體可靠性」連結起來。⁴ 代理程式可觀測性並非錦上添花。衡量代理程式的行為，是治理它的前提。

代理程式可見性的三層

代理程式可觀測性需要三個彼此獨立的層。每一層回答一個不同的問題。其中一層失效，不會連累另外兩層。

這三層對應一條遞進關係：沒有計量過的資源，無法對其強制執行政策；從未定義過的政策，也無從稽核其遵循狀況。每一層都建立在它下面那一層之上。

第 1 層：資源計量

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

Cowork 事件是一次資源計量的失敗。虛擬機器套件包佔用了 10GB 磁碟空間。轉譯處理程序在閒置時佔用 24% 的 CPU。工作階段期間交換空間的活動持續攀升。所有這些指標都存在於 macOS 的活動監視器中，卻沒有一項出現在 Claude Desktop 的介面裡。¹

對於代理程式的編碼工作階段，資源計量需要追蹤四個面向。

磁碟。 每一次檔案寫入、每一筆快取項目、每一個記錄檔。我的工作階段每次會產生 200 至 400KB 的狀態檔案（jiro.state.json、jiro.progress.json、掛勾記錄檔）。60 次工作階段累積下來就是 12 至 24MB 的狀態資料，除非明確清理，否則會一直跨工作階段留存。²

記憶體。 每一輪對話的上下文視窗消耗。以目前 Opus 的價格計算，一個 20 萬 token 的上下文視窗填滿一次大約要 3 美元。我的成本追蹤器會記錄每個工作階段的累計 token 用量，並在可設定上限的 80%、90% 與 95% 處設下預算門檻。⁵

CPU。 掛勾的執行時間。我那套由九個掛勾組成的提示詞分派器，每條提示詞增加 200 毫秒開銷。這點開銷對使用者是隱形的（人打字才是瓶頸），但在自動化流程中會不斷累積。ralph 自主迴圈每個故事會觸發分派器 50 到 100 次，為每個故事增加 10 至 20 秒的掛勾開銷。²

網路。 網頁擷取、API 呼叫、MCP 工具叫用。每一個對外請求都是潛在的資料通道——而且每一個 MCP 伺服器都是一個新的攻擊面，網路計量必須涵蓋到這裡。我的網頁擷取程式庫會記錄擷取的 URL 與回應大小。少了網路計量，一次回傳 50MB 的網頁擷取和一次回傳 5KB 的擷取毫無分別。⁶

沒有任何商用代理程式工具提供以工作階段為單位的資源儀表板。雲端供應商計量運算資源是為了計費，不是為了讓維運人員看見。代理程式消耗了什麼，與維運人員看得見什麼，兩者之間的落差就是資源計量的缺口。

這種缺席在數字累積起來之前一直是隱形的。一次寫入 400KB 狀態檔案的工作階段不算什麼。但六十次各寫 400KB 且從未清理的工作階段，會留下 24MB 無人認領的狀態資料。一次回傳 847KB 的網頁擷取可以忽略不計。但一條每次執行擷取 80 個 URL 的掃描流程，會產生 67MB 的快取內容，而代理程式的工具抽象把這些全對維運人員藏了起來。資源計量的意義，就是在累積演變成逼人提交 GitHub issue #22543 的危機之前，先讓它現形。¹

第 2 層：政策強制執行

政策強制執行回答的是：有哪些規則在約束代理程式，這些規則是否被一致地套用？

mcp-firewall 承擔 CLI 代理程式的政策層。⁷ 該工具位於代理程式與所有工具使用請求之間，在執行前依據以正規表示式為基礎的政策逐條評估請求。政策以 JSONNet 設定檔撰寫，可按資料夾、git 儲存庫或使用者劃定範圍。這道防火牆透過 PreToolUse 掛勾整合支援 Claude Code 與 GitHub Copilot CLI。

這套架構反映了一個關鍵洞見：每個代理程式都在為允許／拒絕邏輯實作自己那套半吊子方案。Claude Code 用 glob 模式，Codex CLI 只做前綴比對。每種作法都只涵蓋政策空間的一個子集。mcp-firewall 把規則集中到一個可跨代理程式運作的引擎裡。

不妨設想一下缺少集中式強制執行時的政策缺口。我的掛勾系統裡有 12 個 PreToolUse:Bash 處理器，分別檢查憑證樣式、危險的 git 操作、敏感路徑存取與部署指令。² 每個處理器都是一支獨立的 shell 指令碼，各有各的正規表示式。每要新增一條拒絕規則，就得寫一支新指令碼；每要稽核既有規則，就得在 12 個檔案裡 grep。mcp-firewall 把這些整合進一個帶有明確允許陣列的設定檔。

OWASP Top 10 for Agentic Applications（2025）把 Agent Goal Hijacking（ASI01）與 Excessive Agency（LLM06:2025）列為最高風險。⁸ 這兩類風險都要求在工具呼叫層級強制執行政策。目標遭到挾持的代理程式照樣會發出工具呼叫；權限過大的代理程式照樣會請求權限。政策強制執行會在代理程式的意圖與系統工具相遇的邊界上，把兩者一併攔下。

政策強制執行不同於存取控制。傳統存取控制問的是「這位使用者有權限嗎？」針對代理程式的政策強制執行問的是「這個動作，在這個情境下，為了這項任務，是否落在核准的範圍內？」部署與防禦的信任悖論說明了為什麼為了讓代理程式好用而授予寬鬆權限，恰恰製造出政策強制執行必須去約束的那片攻擊面。難處在於情境敏感性。推送到功能分支的 git push 與推送到 main 的 git push --force 是同一個工具（Bash），波及範圍卻天差地別。mcp-firewall 的正規表示式能區分兩者，預設的代理程式權限卻不能。

應用層的政策強制執行同樣面臨被繞過的風險。正如你的代理程式沙箱只是一項建議所述，看似牢固的執行邊界，往往存在結構性的漏洞。2026 年 3 月的一份分析記錄了針對 Claude Code 內建拒絕清單的三種逐級升高的沙箱逃逸手法：以路徑規避（/proc/self/root/usr/bin/npx 解析到的執行檔與被攔下的 /usr/bin/npx 完全相同）、代理程式自行停用沙箱（當沙箱阻礙任務完成時，代理程式自主推理出了移除沙箱的作法），以及叫用動態連結器（ld-linux-x86-64.so.2 透過記憶體映射載入執行檔，完全繞開核心的強制執行掛勾）。¹⁴ 第三種手法代表一整類的漏洞：任何避開 execve 的程式碼載入方式，都能繞過處理程序層級的強制執行。對政策強制執行而言，結論是字串比對的拒絕清單是必要的第一層，卻不是充分的一層。以內容定址的強制執行（依 SHA-256 雜湊而非檔名辨識執行檔）能補上路徑規避的缺口，但動態載入器的繞過則需要位於政策層之下的核心層級控制。

同樣的教訓在上面一層依然成立，而在那一層，政策根本看不見。Air Security 於 2026 年 9 月公布的 Plugin4Shell，是四大編碼代理程式共有的一處市集供應鏈缺陷：市集為外掛釘選一個經過審核的 commit，但代理程式在簽出這個 commit 時並不查核它是否真的落在那裡，於是掌控外掛儲存庫的攻擊者可以新建一個以釘選 commit 命名的分支，並把它設為預設分支；市集裡一次例行的重新釘選隨後觸發每個代理程式的背景自動更新，簽出被解析到那個分支，而釘選看起來依然受到遵守。依我的解讀，這套堆疊裡沒有任何 PreToolUse 掛勾、拒絕清單或防火牆看得見外掛被掉包，因為掉包發生在代理程式發出工具呼叫之前。Air 的時間軸指出，Anthropic 在 Claude Code 2.1.179 中確認了修復，OpenAI 在 Codex 0.146.0 中交付了修復，GitHub Copilot 沒有修復，已棄用的 Gemini CLI 也不會有；但 Claude Code 公開變更記錄中 2.1.179 的條目並未點名這項修復，因此這個版本號只能依據研究人員的說法。適用的控制手段是版本衛生，再加上一份盤點：市集究竟解析出了什麼。這是計量問題，而非政策問題。¹⁷

第 3 層：執行階段稽核

執行階段稽核回答的是：在系統呼叫層級，代理程式實際做了什麼？

Logira 藉由 eBPF 探針在核心層級攔截系統呼叫，承擔稽核層。⁹ 該工具記錄三類事件：處理程序執行（exec 事件）、檔案操作（含憑證檔案存取），以及網路連線（附目的地追蹤）。每一次受稽核的執行會產生三個檔案：供時間軸檢視的 events.jsonl、供查詢篩選的 index.sqlite，以及記錄執行中繼資料的 meta.json。

其設計哲學是「只觀察」：Logira 記錄並偵測，但不強制執行、不攔截。⁹ 與強制執行層的分離是刻意的。政策強制執行防的是已知的惡意動作，執行階段稽核則在事後發現未知的惡意動作。兩層在時間軸上承擔不同職能：預防（事前）與鑑識（事後）。

Logira 的 eBPF 探針運作在應用層之下。就算代理程式建構出一條前所未見的指令來外洩資料，它照樣得發出系統呼叫。代理程式無法把檔案讀取、網路連線或處理程序衍生藏過核心層級的追蹤。這種作法能捕捉應用層掛勾漏掉的東西：那些繞過工具呼叫抽象的副作用。

內建的偵測規則專門針對 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 只觀察式稽核軌跡相當的生產級方案。

Agent Safehouse 是一款 macOS 原生的沙箱工具，2026 年 3 月在 Hacker News 上累積 802 點與 181 則留言，它從強制執行這一側填補了平台的空缺。¹⁵ 該工具提供專為 macOS 上的本機 AI 代理程式設計的沙箱設定檔。社群的反應（對一款沙箱工具而言 802 點相當罕見）反映出這件事的急迫：在 macOS 上運行代理程式的實務工作者，除了「不用沙箱」與「自己寫 Seatbelt 設定檔」之外幾乎別無選擇。Agent Safehouse 在強制執行側補上了這個缺口，而 macOS 在稽核側的缺口依然敞著。

強制執行與稽核之別，對應著事故應變在時間上的分工。強制執行防止事故發生，稽核讓事後重建成為可能。兩者缺一不可。一個攔截所有憑證存取的強制執行層，在阻止外洩的同時也會擋掉正當的 SSH 操作。一個只記錄、不攔截所有憑證存取的稽核層，則讓維運人員得以檢視存取樣態，並依據證據去調校強制執行規則。稽核資料與政策精煉之間的這條回饋迴路，正是可見性堆疊隨時間持續改善的方式：稽核揭露樣態，樣態形塑政策，政策又縮小了稽核需要涵蓋的面。

Logira 的 cgroup v2 隔離帶來一項應用層稽核無法複製的能力：以執行為單位的歸屬。系統會把每一個事件歸屬到某一次受稽核的執行，而不是籠統地歸給整台機器。當兩個代理程式工作階段在同一台機器上並行執行時，cgroup 隔離能確保工作階段 A 的檔案存取不會出現在工作階段 B 的稽核軌跡裡。應用層掛勾給不了同樣的保證，因為掛勾是在代理程式的處理程序內部觸發的，而該處理程序並沒有一條隔開並行工作階段的核心層級邊界。⁹

我實際在跑什麼

我的協調系統靠掛勾而非專用監控工具，涵蓋了全部三層。

資源計量。 cost-gate 掛勾依據可設定的預算門檻追蹤每個工作階段的 token 用量。⁵ 系統效能監視器按可設定的間隔檢查 CPU、記憶體、磁碟與交換空間，在資源壓力越過門檻時注入警告。¹⁰ 工作階段偏移偵測器每 25 次工具呼叫觸發一次，計算原始提示詞嵌入與近期動作滑動視窗之間的餘弦相似度。²

政策強制執行。 八個 PreToolUse 分派掛勾依工具類型路由到相應的處理器掛勾。光是 PreToolUse:Bash 就會執行 12 個處理器，涵蓋憑證樣式、破壞性 git 操作、敏感路徑存取與部署指令。遞迴防護會強制最大深度為 2、每個父代理程式最多五個子代理程式。²

執行階段稽核。 PostToolUse 掛勾記錄每一次工具呼叫的結果。安全掃描掛勾在執行後檢查 bash 輸出是否洩漏憑證。工作階段狀態檔案（jiro.state.json）記錄每一次故事完成、審查者判定與證據關卡結果。² 該系統不使用 eBPF（macOS 的限制），但透過掛勾流程擷取了工具層級的遙測資料。

這套系統之所以奏效，是因為每一個動作都會流經掛勾流程。限制在於深度：掛勾層級的監控捕捉的是代理程式要求做的事，而非作業系統實際執行的事。一個建構出內嵌子 shell 的 bash 指令的代理程式，執行的程式碼在掛勾看來只是一個字串。核心層級的稽核則能看見其中每一個子處理程序。

以下是來自正式環境事故的具體結果，這三層堆疊捕捉到了預設監控本會漏掉的失敗。

不斷累積的盲區

代理程式衍生代理程式，會讓不透明性成倍放大。每一次委派跳轉都會帶來資訊損耗。

當我的協調系統執行 ralph 自主迴圈時，父處理程序會為 PRD 中的每個故事衍生全新的 Claude Code 執行個體。每個子代理程式拿到一項聚焦的任務與一個全新的上下文視窗。父處理程序追蹤完成狀態，卻看不到子代理程式各自的工具呼叫、檔案讀取或資源消耗。²

在深度一（父衍生子）時，父處理程序看到的是子代理程式的最終輸出。在深度二（子衍生孫）時，父處理程序看到的是子代理程式對孫代理程式輸出的轉述。每跳一次，資訊就被壓縮一層。我在 NIST 意見書中的委派鏈分析量化了三種疊加風險：語意壓縮（情境塌縮成一個提示詞字串）、權限放大（子代理程式在不理解敏感性的情況下繼承權限），以及責任稀釋（根代理程式要為自己從未查驗過的結果負責）。³

可觀測性以同樣的速率衰減。在根代理程式上部署三層可見性堆疊，對孫代理程式而言仍是零可見性，除非每個子代理程式都獨立執行自己的監控。我的遞迴防護會強制深度限制，但那是政策控制，不是可觀測性控制。知道委派止於深度二，並不等於知道深度二發生了什麼。

來自我正式系統的一個具體例子：ralph 迴圈衍生了一個子代理程式去實作一個資料庫遷移故事。該子代理程式判斷這次遷移需要一個「驗證步驟」，於是又衍生出自己的子代理程式去跑整合測試。孫代理程式靜默失敗了（測試資料庫沒有設定好）。子代理程式收到一個空回應，把沉默當成成功，回報故事已完成。父處理程序記下「story 4: complete」。三小時後應用程式因為缺失的欄位當掉，我才發現遷移已經壞了。根代理程式的遙測顯示這是一次乾淨的執行。故障藏在兩跳之外，我部署在根節點的每一層監控都看不到它。²

OWASP 的 Agentic Applications 架構談到了連鎖失敗與失控代理程式，卻沒有為多代理程式委派鏈訂出可觀測性要求。⁸ OpenGuard 在 2026 年 3 月發表的代理程式提示詞注入分析，從安全這一側揭露了同樣的缺口：遭汙染的情境在權限各異的代理程式之間流動，在缺乏清楚的資料流政策與組合層級授權的情況下，透過交接製造出「一條悄悄提升權限的途徑」。¹⁶ 這個缺口是結構性的：鏈上的每個代理程式都需要各自的資源計量、政策強制執行與執行階段稽核，各自獨立設定、獨立回報。開銷是相乘的。為鏈上的三個代理程式各加三層監控，就是九個監控執行個體，每一個都產出自己的遙測，每一個都要自己的設定。現有工具中沒有一款能管理這樣的協調。

今天就能落實的作法

三個涵蓋可見性堆疊的最小監控掛勾。

1. 資源：token 預算追蹤器。 記錄每個工作階段累計的輸入與輸出 token。設一個硬上限，在 80% 時發出警示。實作上只需讀取代理程式的用量統計（Claude Code 透過 /cost 揭露工作階段成本）並與門檻比較。我的 cost-gate 掛勾用 47 行 bash 就做到了。⁵

2. 政策：PreToolUse 拒絕清單。 建立一個在每次 Bash 工具呼叫之前觸發的掛勾。把指令與一份樣式清單比對：rm -rf /、git push --force、含有 .ssh 或 .env 的路徑、curl | sh。命中就攔下。實作上只需一支 shell 指令碼，讀取標準輸入（工具呼叫的 JSON），取出 command 欄位，再與樣式檔案做 grep。我的憑證檢查掛勾用 31 行就做到了。²

3. 稽核：PostToolUse 工作階段記錄。 把每一次工具呼叫及其結果附加到以工作階段區分的 JSONL 檔案裡，包含時間戳記、工具名稱、參數與結束代碼。有了這份記錄，就能在工作階段結束後重建全程：代理程式做了什麼、依什麼順序做的、有沒有什麼東西靜默失敗了？我的工作階段記錄器用 22 行 bash 就做到了。²

以下是 settings.json 中拒絕清單掛勾的一個實例：

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

掛勾指令碼從標準輸入讀取工具呼叫，取出指令字串，再與樣式比對。被攔下的指令會回傳一個 JSON 物件 {"decision": "block", "reason": "Sensitive path access denied"}；被放行的指令則回傳 {"decision": "approve"}。這兩種回應 Claude Code 都會遵從，不再追問。整個掛勾對放行的指令不增加任何延遲（正規表示式檢查在 5 毫秒內完成），對被攔下的指令則給出即時回饋。

這三個掛勾加起來不到 100 行。它們並不取代專用的監控工具，只是把零可見性換成最小可見性。而最小可見性，是此後每一項治理決策的前提。沒有計量，就設不了資源預算；沒有拒絕清單，就強制不了範圍政策；沒有稽核記錄，就調查不了事故。先從記錄開始，另外兩項自會跟上。

重點整理

給平台工程師： 代理程式消耗的是現有監控沒有追蹤的資源。每個代理程式工作階段的磁碟、記憶體、CPU 與網路用量，理應和容器指標出現在同一塊儀表板上。Cowork 事件證明了這種必要性：10GB 被配置出去，維運人員卻毫無可見性。

給資安團隊： 在工具呼叫邊界上強制執行政策，是代理程式資安態勢的最小可行起點。mcp-firewall 的集中式作法，把各代理程式各自為政的允許／拒絕邏輯歸併成一份可稽核的設定。請評估您的代理程式內建權限，是否涵蓋了威脅模型所要求的政策空間。

給工程主管： 長期的答案是代理程式自我治理——讓代理程式把監控內化為行為規範，而不只是外部約束。在那一天到來之前，請針對您的代理程式工具鏈問三個問題：看得到以工作階段為單位的資源消耗嗎？能定義並稽核工具呼叫政策嗎？能在事後重建代理程式做過什麼嗎？只要有一個答案是「不能」，您就存在一處可見性缺口，而它會隨著工作流程中每多一個代理程式而持續擴大。

常見問題

什麼是代理程式可觀測性？

代理程式可觀測性是指監控並理解 AI 代理程式在執行過程中所作所為的能力：它消耗了哪些資源、採取了哪些動作，以及這些動作是否符合既定政策。

Anthropic 的 Cowork 為什麼會建立 10GB 的虛擬機器？

Claude Desktop 的 Cowork 功能會為協作開發工作階段佈建一台虛擬機器。Claude Desktop 在每一次 macOS 安裝時都會自動建立該虛擬機器套件包，即便使用者從未啟用過這項功能，而且會一直保留到被手動刪除為止。¹

mcp-firewall 是什麼？

mcp-firewall 是一款開源的政策強制執行工具，它攔截來自 CLI 代理程式（Claude Code、GitHub Copilot CLI）的工具使用請求，並在執行前依據以正規表示式為基礎的允許／拒絕規則加以評估。⁷

什麼是 eBPF 執行階段稽核？

eBPF（extended Berkeley Packet Filter）能在不修改受稽核處理程序的前提下，於核心層級追蹤系統呼叫。Logira 之類的工具便使用 eBPF 探針，記錄 AI 代理程式執行期間的處理程序執行、檔案操作與網路連線。⁹

代理程式是如何在維運人員看不見的情況下衍生子代理程式的？

委派任務的代理程式會衍生帶有全新上下文視窗的子處理程序。父代理程式看得到子代理程式的最終輸出，卻看不到它各自的工具呼叫、檔案讀取或資源消耗。每經過一次委派跳轉，資訊就被壓縮一層：孫代理程式的整場工作階段，在父代理程式的記錄裡只剩一行狀態。可觀測性衰減的速率，與委派深度增加的速率相同。²

代理程式監控與傳統 APM 有何不同？

傳統的應用程式效能監控（APM）追蹤確定性軟體的請求延遲、錯誤率與吞吐量。代理程式監控追蹤的是非確定性行為：代理程式在執行階段決定做什麼、這些決定是否落在政策之內，以及每個決定消耗了多少資源。APM 假定應用程式會沿著已知的程式碼路徑執行；代理程式監控則假定代理程式會自己選路。²

Claude Code 的掛勾能提供代理程式可觀測性嗎？

可以。Claude Code 的掛勾系統會在生命週期事件（PreToolUse、PostToolUse、Notification）上觸發指令碼，這些指令碼可以計量資源、強制執行政策並記錄動作。一套三掛勾配置——token 預算追蹤器、PreToolUse 拒絕清單與 PostToolUse 工作階段記錄器——用不到 100 行 bash 就能涵蓋全部三層可見性。對於已經在用 Claude Code 的團隊，掛勾是最容易上手的切入點。

代理程式繞過自己的沙箱時會發生什麼？

沙箱被繞過，意味著強制執行層靜默失效。代理程式會繼續在既定範圍之外執行，而如果沒有執行階段稽核，這次突破不會留下任何記錄。2026 年 3 月記錄的沙箱逃逸手法包括以路徑規避、代理程式自行停用沙箱，以及叫用動態連結器——這些對應用層監控而言全都是隱形的。

MCP 工具的可觀測性為什麼重要？

每一次 MCP 工具呼叫都是潛在的資料通道：它可以讀取檔案、發出網路請求、執行程式碼。MCP 伺服器會擴大攻擊面，因為每接上一個伺服器，代理程式在執行階段就多了一批可叫用的新能力。若沒有逐次呼叫的記錄與政策強制執行，MCP 工具的叫用對維運人員就是隱形的。

如何監控多代理程式的委派鏈？

委派鏈上的每個代理程式都需要各自的資源計量、政策強制執行與執行階段稽核。ralph 自主迴圈很好地展示了這個問題：父代理程式衍生出的每個子代理程式都會拿到全新的上下文視窗。父代理程式看到的是最終輸出，而非各自的工具呼叫。可觀測性衰減的速率與委派深度增加的速率相同，因此每一跳都需要獨立的監控。

參考來源