先分清楚：你是坐在旁邊，還是放它自己跑

Claude Code 在 v2.1.212（2026-07-17）悄悄加了三個 session 級的資源上限。官方 changelog 講得很平淡，多數人滑過去大概也不會多想。但這三個開關的價值，完全取決於你怎麼用 Claude Code，所以在講該不該動它們之前，得先把使用情境切成兩種。

第一種，你坐在終端機前面，一句一句跟它對話，它每要動一次危險操作你都看得到。這種情況下，這三個上限你幾乎可以當它不存在。第二種，你把一個任務丟給它，關掉螢幕去睡覺，或乾脆掛在排程上每天自動跑。這種情況下，這三個數字就從「裝飾」變成「保險絲」。

我用電箱裡的保險絲來想這件事最順。保險絲不是拿來限制你用電的，你想開幾盞燈、吹不吹冷氣，它一概不管。它只在一種時刻起作用：電線快要走火、整間房子有燒起來的風險時，「啪」一聲把電切掉。這三個上限的角色一模一樣。平常你感覺不到它們，它們只在 agent 陷入某種失控迴圈、準備把你的 token 額度燒到見底的那一刻，跳出來把電閘拉下。

三根保險絲各自防的是什麼火

先把三個開關擺出來，順便說清楚每一根防的是哪一種走火。它們都是環境變數，設定方式就是一般的 export：

1
2
3
4
5
6
7
8
# 這一個 session 裡，WebSearch 最多叫幾次（預設 200）
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=200

# 這一個 session 裡，最多能生出幾個 subagent（預設 200）
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=200

# MCP 工具呼叫跑超過幾毫秒，就自動轉到背景（預設 2 分鐘）
export CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=120000

第一根，WebSearch 上限，防的是搜尋鬼打牆。agent 有時候會為了查一件查不到的事，一輪接一輪換關鍵字搜下去，每一次都在燒錢。這道閘把單一 session 的搜尋次數封頂。

第二根，subagent 上限，防的是委派失控。現在的 agent 很愛開分身，分身還會再開分身。正常情況這是好事，可以平行辦事；但一個寫壞的迴圈可能讓它無止盡地 spawn 下去。這道閘管的就是這個。它有個貼心設計：/clear 會把這個 session 的 subagent 額度重新歸零，所以你不必為了額度去重開終端機。

第三根跟前兩根不太一樣，它不是「擋下來」，而是「挪到旁邊」。MCP 工具呼叫如果跑超過兩分鐘，會自動被丟到背景去，讓你的 session 不會整個卡在那邊乾等。它防的不是燒錢，是「看起來像當機」。

那個最容易搞混的細節：subagent 到底怎麼算

subagent 上限最值得花時間搞懂，因為「哪些算、哪些不算」有點反直覺，官方文件特別列了一段來講。搞錯的話，你會以為自己設的閘有在守門，其實漏了一大半。

會算進這個額度的，是 Claude 自己用 Agent 工具開出來的所有分身，包含巢狀的分身、背景分身，連 workflow 腳本裡那些用 Agent 工具開的也一起算。這一群共用同一份預算。

不算進去的有兩類。一類是你用 /fork 另外開的獨立背景 session，它自己帶一份預算，跟主 session 井水不犯河水。另一類是 workflow 腳本用 agent() 開的，workflow 有它自己的每次執行上限，走另一套帳。

這裡有個 v2.1.212 一起改掉的命名，不講清楚很容易踩到：以前在同一個 session 裡分叉出去的那個 /fork，現在改叫 /subtask 了，而且它會花掉同一份 subagent 預算。至於 /fork，現在專指「另外開一個獨立的背景 session」，那個才不計入。所以當你讀到「/fork 不計入」，指的是後者，別跟舊版 session 內的 fork 搞混。

順帶一提，這三根保險絲有個共同的邊界：上限可以往上調到任何正整數，沒有天花板，但你沒辦法把它整個關掉。這個設計本身就是一種態度，等一下會講到。

什麼時候該動它，什麼時候別碰

回到最前面那個問題：預設值到底該不該改？我的判準很簡單，就看你把 Claude Code 放在哪種情境。

如果你是坐在旁邊互動式地用，答案是別碰。預設的 200 對一場有人盯著的對話來說綽綽有餘，你這輩子大概都撞不到。硬去調它，只是給自己找一個不存在的問題來解。

真正需要停下來想這三個數字的，是你打算讓它無人值守的時候：排程任務、半夜自己跑的 build、一個會開很多分身的重度並行工作流。這種場景才是這三根保險絲存在的理由，因為這時候的失控是「無聲的」——沒有人會即時發現它已經連續搜了八十次、或分身生到停不下來，等你早上打開一看，額度已經見底。

而且方向常常跟直覺相反。多數人一想到「上限」，第一反應是把它調高，免得礙事。但對無人值守的任務，更聰明的動作其實是往下調，把它當保險絲用。如果你很清楚某個排程腳本正常跑一趟頂多開五個分身、搜十次網路，那就把上限設在 MAX_SUBAGENTS=20、MAX_WEB_SEARCHES=30 之類略高於正常值的地方（這個數字是我的建議，官方沒有給推薦值）。一旦哪天它因為 bug 想暴衝，保險絲會在燒掉一點點的時候就跳掉，而不是燒到全部。

至於第三根 MCP 背景門檻，判準又不太一樣。它預設兩分鐘通常剛好，但如果你的工作流裡有些 MCP 工具天生就跑得久（大型查詢、慢速外部服務），你可能會希望把門檻拉長一點，免得它太早被丟到背景、打亂你原本想同步等結果的節奏。

反過來想：什麼時候調它反而是壞主意

判斷一個設定該不該動，最好的方法往往是先想清楚「怎麼調會出事」。這三根保險絲有三種很典型的錯誤用法。

第一種，因為嫌它偶爾礙事，就把上限調到天高。這等於把保險絲換成一根粗鐵絲：平常是不會再跳了，但它本來要防的那場火，現在會一路燒到底。你把唯一一個會在無聲失控時救你的機制給廢了。

第二種，把 MCP 自動轉背景的門檻設得太短，或想辦法規避掉它。結果是任何一個稍微慢一點的工具呼叫都被踢到背景，你想同步拿結果的流程被切得七零八落，反而更難用。

第三種比較隱性：明明是互動式在用，卻跑去把上限調得很低，想「省一點」。然後某次你請它做一件本來就需要開很多分身的大任務，它做到一半撞到你設的低牆，硬生生停下來。你省的那點額度，遠不如你被打斷的時間值錢。

你會發現，官方「可以無限調高、但不准關掉」的設計，其實是在替你擋掉最糟的那個選項。它願意讓你把保險絲的容量開到很大，但不讓你把整片保險絲拆掉——因為拆掉保險絲的房子，遲早會燒一次。

給你一句不騎牆的結論

所以，該不該設 session 上限？

如果 Claude Code 對你來說，就是一個坐在旁邊、隨叫隨應的助手，那你什麼都不用做，預設值本來就是為你調好的，記住有這三個開關存在就夠了。

但只要你開始把它推向無人值守，讓它在你不在的時候替你跑排程、跑 build、跑會自我委派的工作流，那這三個環境變數就是你上線前該補的最後一道功課。而且請往「調低當保險絲」的方向想，不是往「調高免得礙事」的方向。設定完，可以搭配 /usage 依 subagent、plugin、MCP 把用量拆開看一眼，確認你設的閘卡在合理的位置。

一個能自己動手、還能自己開分身的 agent，威力和風險是綁在一起長的。這三根保險絲不會讓它變弱，反而是讓你敢真正放手、關掉螢幕去睡覺的那個前提。（本文所述功能需 Claude Code v2.1.212 或更新版本。）