一個 /loop 每兩分鐘跑一次 pytest 的任務，在 10 分鐘裡會燒掉 5 個 API call——其中 4 個完全沒拿到有用資訊。 每次 Claude 醒來、載入 context、發 prompt、收 response，然後看到「測試還在跑，下次再來」，就這樣重複四次。token 照算、時間照花、noise 照寫進 transcript。

Claude Code v2.1.98 新增的 Monitor Tool，把這個模式整個翻過來。

想像一下你家的煙霧偵測器。它不是每 30 秒跳出來問你「廚房起火了嗎？」，而是靜靜地掛在天花板上，真的有煙才會叫。Monitor Tool 就是給 Claude 裝煙霧偵測器：背景跑一個程序，每一行 stdout 都是一個事件，事件真的來了才會叫醒 Claude。沒事件的時候，Claude 在做別的事，不花 token 也不佔 context。

這個差異在帳單上很具體。以前你要求「幫我盯著 server.log，出現 5xx 就通知」，只能用 /loop 或 watch，每次輪詢都要付出一次 Claude 的 thinking round。現在的寫法是：

1
> Tail server.log in the background and tell me the moment a 5xx shows up

Claude 會開一個背景 process，stdout 透過 Monitor Tool 接回 conversation。grep 5xx server.log 沒命中之前，Claude 甚至不知道有這個 session 在執行。命中的瞬間，那一行 log 才直接推到 transcript，Claude 看到、讀懂、開始修 bug。

這個工具到底怎麼運作

Monitor Tool 不是魔法。它做的事情其實是一個架構上的反轉——從 pull 變成 push。

以前的模式是 polling：Claude 每隔 N 分鐘主動問「有事嗎？」。問題是你不知道「N」要設多少。設太短，成本爆炸；設太長，反應太慢。煙霧偵測器不做這件事，因為它不是每 30 秒去聞一次廚房——它接一個感光元件，煙進來，它響。

Monitor Tool 的 push 模式長這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
Claude 主對話
    │
    │  spawn 一個背景 process
    ▼
背景程序（一直跑著）
    │
    │  stdout 每產生一行 = 一個事件
    ▼
Monitor 事件流（非阻塞）
    │
    │  真的有事件才推回
    ▼
Claude 主對話（讀到事件、立刻反應）

背景 process 跑它的，stdout 每產生一行就變成一個通知事件。這個事件直接以一個新的 transcript message 出現在對話裡，Claude 讀到、反應、可能派 Edit 工具去改 code 或派別的工具去處理。沒有事件的時間，Claude 去做別的事——你可以繼續問它其他問題、要它寫別的 function、改別的檔案。

這個設計的聰明之處在於它不佔用「回合」。Bash sleep 30 會 hold 住一整個 turn，10 分鐘內你沒辦法叫 Claude 做別的事。Monitor 是非同步的——它在後台流事件，前台對話繼續跑。

三個能立刻動手做的情境

情境一：Dev server 崩了自動叫修

你開了 Next.js 或 Vite dev server，一邊寫 code 一邊怕 build 壞掉。以前你要自己盯終端機，發現錯誤、複製貼到 Claude、等它修。現在：

1
> Monitor the dev server output and fix any build error the moment it appears

Claude 接上 monitor，dev server 的 stdout 一有 error 出現，那一行就變成 transcript message。Claude 讀錯誤訊息、去找對應檔案、改 code、存檔。vite 本身會 hot reload，build 就好了。整段過程你沒手動做任何事。

情境二：Test runner 跑到哪，我修到哪

pytest 或 vitest 跑 500 個測試要 8 分鐘。以前你要等它全跑完，看報告、修失敗的測試。現在：

1
> Run the test suite with monitor, and start fixing failures as they appear

每個失敗的 test case 在它 fail 的那一秒就變成事件推給 Claude。測試還在繼續跑，Claude 已經開始改 test #23 的 fixture 和 test #47 的 mock。整體時間從「測試時間 + 修 bug 時間」變成「max(測試時間, 修 bug 時間)」。並行，不是串行。

情境三：CI 通了自動 merge

1
> /autofix-pr then monitor the checks until everything is green

PR push 上去，Claude 在背後 tail CI checks。綠燈就 merge，紅燈就開始修。你不用每 5 分鐘去 GitHub 看一次——它在看。

跟 /loop 的差別在哪

/loop 不是被 Monitor 取代——它們解決不同問題。

/loop 解決的是重複性主動動作：每 5 分鐘跑一次 git status 看 team 有沒有 push、每天早上跑一次 Last30Days 摘要、每週五下午跑一次 sprint review。這些都是你要 Claude 去做事，而不是等事情發生。

Monitor 解決的是事件驅動反應：server 崩了、test 失敗、alert 觸發、檔案被修改。這些是等外部訊號，訊號沒來就不該做事。

v2.1.98 之後這兩個工具開始互相認識。新的 /loop 會 self-pace：你不給 interval，它會看任務性質自己決定下次什麼時候跑——或者直接去拿 Monitor Tool 跳過輪詢。例如：

1
> /loop check CI on my PR

以前這條會變成「每 N 分鐘查一次 CI」。現在 Claude 會判斷「這是事件驅動」，直接改成 gh run watch + Monitor，完全不輪詢。

跟其他 AI 工具比一下

這個設計在 AI coding agent 圈是個新物種。對照一下幾個主要對手：

Cursor 的背景任務是用它內建的 agents window 跑的——你可以在 window 裡開一個 sub-agent 去做 long-running task。但 sub-agent 跟主對話是分開的 context，事件不會直接推到主對話——你要手動切過去看。隔離性好，反應性差。

GitHub Copilot CLI 還沒有對應功能。Copilot CLI 是 REPL-style，整個設計圍繞「你問一次，它答一次」。背景 process 監聽完全不在架構範圍內。

Windsurf Cascade 的 background mode 比較接近 Monitor，但事件通知走的是 IDE 內的 toast notification——會彈出來打斷你，而不是直接流進 agent 的思考脈絡。Claude Code 的做法更細膩：事件進 transcript，Claude 自己決定要不要處理、什麼時候處理。

這三條路線代表三種設計哲學：Cursor 把 agent 當 worker（背景跑、不干擾）、Windsurf 把事件當通知（彈給人看）、Claude Code 把事件當感官輸入（進 agent 的 context 讓它反應）。Claude 的選擇比較偏向讓 agent 持續性存在的方向，不是一次性完成任務就結束。

幾個容易踩的坑

Monitor 不會自動清理 process。如果你啟動一個 tail -f 然後結束對話，那個 process 在背景還活著。需要用 ps 確認並手動 kill。這個行為讓它特別適合放進 CLAUDE.md 的 instruction 裡，例如「每次 session end 前，列出所有 monitor process 並詢問要不要清」。

每一行 stdout 都是一個事件。如果你的背景 process 是個碎念機（例如 verbose mode 的 webpack），它會把 Claude 的 context 塞爆。在 pipe 進 monitor 前先 grep 或 awk 過濾，只留下你真的需要的那種訊號。例如不要 tail -f server.log，而是 tail -f server.log | grep -E 'ERROR|FATAL|5\d\d'。

長時間閒置的 monitor 要小心資源。一個 tail 一天的 log 不會佔太多 CPU，但如果你跑了 10 個 monitor 同時盯不同東西，記憶體和 file descriptor 會吃掉。跟 tmux 很像——方便但要管理。

對 retry 敏感的 process 要特別設計。如果你 monitor 的是會自動重啟的 service（例如 systemd unit），你會看到一堆「service stopped」「service started」事件進 transcript，Claude 可能會誤以為真的出事了。解法是在 monitor command 裡做好狀態機，或用 sentinel pattern——寫一個中繼腳本，只在「真正異常」時才 echo 出事件。

它其實是在重新定義 agent 的注意力

Monitor Tool 看起來是個小工具，但它解決的問題其實很根本：agent 的注意力怎麼分配。

傳統的 LLM agent 只有兩種狀態——正在思考和等你講話。這個模型對單次任務夠用，但對「持續性存在」的 agent 不夠用。你希望它像一個隨身助理，背景盯著幾件事、專心在手上這件事、緊急事件來了馬上切換——這需要第三種狀態：被動接收外部訊號。Monitor Tool 就是那第三種狀態。

Push vs Pull 是整個作業系統歷史裡反覆出現的對比。CPU 怎麼跟 IO 裝置溝通？最早是 polling，後來演化成 interrupt。網頁怎麼拿到 server 更新？最早是 AJAX polling，後來變成 WebSocket。Monitor 把同樣的演化帶進 AI agent——從「每 N 秒問一下」變成「真的有事才打擾你」。

學完這個可以接著學什麼？兩條路線：

往下一層——Claude Code Hooks。Monitor 是系統幫你管 background process，Hooks 則是讓你自己在 Claude 的每個 lifecycle event（UserPromptSubmit、PreToolUse、PermissionRequest）插程式碼。用 Hook 可以做出比 Monitor 更客製化的事件觸發，例如「當 Claude 要執行 rm -rf 時，先推一個警告事件」。Monitor 是消費者版，Hooks 是工程師版。

往上一層——Sub-agents。Monitor 讓一個 agent 同時盯多件事，Sub-agents 則是讓你開多個獨立的 agent 各自做事。把兩個組合起來——一個主 agent 盯著三個 monitor、每個 monitor 命中就 spawn 一個 sub-agent 去處理——你就有了一個能持續運作的小型 agent 工廠。

背後就一條線：agent 的能力邊界不是模型多強，是它能不能跟「時間」和「事件」好好相處。Monitor Tool 是其中一塊關鍵拼圖，不是最後一塊。

原文來源：Week 15 · April 6–10, 2026 - Claude Code Docs
原文來源：Monitor tool reference - Claude Code Docs
參考來源：Claude Code Monitor Tool: Stop Polling, Start Reacting - claudefa.st
參考來源：Monitor tool: real-time background process streaming - AI Codex