Claude Code 不再相信代理人會自己收手

200。

從 2.1.212 開始，Claude Code 一場對話（session）裡最多幫你搜 200 次網路，超過就不搜了。同一版還加了第二個數字：一場對話最多生成 200 個子代理。

先把最容易的誤讀擋掉——這不是配額，也不是方案調整。價格沒動，兩個上限都能用環境變數自己調高、調低，或實質關掉。

200 這個數字本身才是線索。你家的無熔絲開關不是為了限制你開幾盞燈，它的跳脫值一定遠高於日常會用到的電流，不然開個冷氣就跳，那叫故障不叫保護。200 就是那個「遠高於日常」的數字：正常一場對話，沒有人會搜 200 次網路、派 200 個分身出去。

會走到 200 的只有一種東西：跑掉的迴圈。

200 次搜尋、200 個分身，一場對話就這麼多

官方 changelog 把目的寫得很白：兩個上限分別要擋 runaway search loops 和 runaway delegation loops——失控的搜尋迴圈，跟失控的委派迴圈。

這版新加的三個閘長這樣：

新的閘	預設值	環境變數	官方寫的目的
WebSearch 呼叫（每場對話）	200 次	CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION	擋失控的搜尋迴圈
子代理生成（每場對話）	200 個	CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION	擋失控的委派迴圈
MCP 工具自動退背景	2 分鐘	CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS	讓對話保持可用

子代理的額度跟著對話走，/clear 會重置。

第三個閘的邏輯不一樣：MCP 工具呼叫跑超過兩分鐘不會被砍掉，而是自動丟到背景，讓你手邊的對話繼續能用。慢工具從此不再卡住整場。

九個版本前還在調教代理人少亂派工，這版直接上硬數字

這批更新最有意思的地方，藏在同一份 changelog 前面幾版。

2.1.203 處理「子代理亂派工」，用的是調教。changelog 上的原文是 improved subagent behavior，agents are now less likely to re-delegate their entire task to another subagent——讓代理人比較不會把整包工作再轉包出去。那是行為層的解法：把模型教乖一點。

2.1.212 換了做法。它不再談代理人「比較不會」怎樣，而是給一個數字，數到就停。

兩件事之間，changelog 沒有寫任何因果關係，我也不幫它寫。但把它們並排看，方向是清楚的：調教能降低機率，降不到零。而這是一個子代理可以再生成子代理、最深疊到 5 層的系統——那是 2.1.172 加的。機率降不到零，在 5 層自動委派裡就意味著它遲早會發生一次。

200 個分身聽起來荒謬，是因為你想的是自己手動派工。5 層巢狀的自動委派不是這樣算的。

至於 200 以後會不會變成真的配額——往下調、或綁進方案——官方沒有任何說法，我不替它推測。目前查得到的事實只有一個：npm 上的 stable 通道還停在 2.1.205，2.1.212 掛的是 latest。

plan mode 沒問就動檔案，這版才修掉

要找一個今天就更新的理由，它不在那兩個上限，在 Fixed 清單裡。

2.1.212 修掉了 plan mode 會在沒有權限提示、也沒有經過 SDK canUseTool 的情況下，自動執行會改檔案的 Bash 指令。changelog 直接舉了 touch 和 rm 當例子。

plan mode 在很多人的用法裡就是唯讀模式：先讓它規劃，我看過再動手。這條修復的意思是，在 2.1.212 之前，那個假設不是每次都成立。

同一份清單裡還有一條同性質的：建立 worktree 時會跟隨 repo 裡 committed 的 .claude/worktrees symlink，可能在 repo 外面建檔。

兩條都被官方列為 Fixed，沒有 CVE、沒有安全公告，也沒有任何被利用的紀錄，我不會把它們寫成漏洞揭露。但共通點很具體：你以為自己設好的界線，在某些路徑上沒有守住。這比 200 更值得你去看一眼手上的版本號。

/fork 換了意思，你的舊習慣要改名

最後一個會打到肌肉記憶的：/fork 變了。

現在 /fork 會把對話複製到一個新的背景 session，在 claude agents 裡有自己一列，你手邊的工作可以繼續跑。原本 /fork 那個「開一個 in-session 子代理」的行為，改名叫 /subtask。

同一版也把 Task 工具的 mode 參數標成 deprecated，現在直接忽略；子代理預設繼承父對話的權限模式。

---

三個環境變數今天就能設。嫌 200 太緊，往上調；想更保守，往下調——這是斷路器的邏輯，跳脫值本來就該由用的人決定。

還沒有答案的是：官方沒說 200 是怎麼定出來的，也沒說你真的撞到之後，對話會硬停還是先問你一句。changelog 只寫了 /clear 會重置額度。

而如果你走的是 stable 通道，這批東西——包括 plan mode 那條修復——都還沒到你手上。