fork 和普通子代理的差別，一句話怎麼說？
fork 繼承整段對話（相同的 system prompt、工具、模型與訊息歷史），普通子代理從空白開始，只拿到任務訊息、CLAUDE.md、git status 和預載的 skill。兩者共通的是：中間的工具呼叫都不進主對話，只有最終結果回來。
我在 CI 裡用 claude -p，升級後帳單會變多嗎？
更新說明沒有量化 fork 的成本，所以不能直接下結論。v2.1.302 起 claude -p 預設就能使用 fork，Claude 可能在派工時選它，而 fork 會帶著整段歷史。DEV Community 的整理說影響可能是升也可能是降，建議先量幾次。可以用 --output-format json 的 usage 或 OpenTelemetry 比較升級前後的 token 用量，再決定要不要設 CLAUDE_CODE_FORK_SUBAGENT=0。
我在子代理 frontmatter 寫了 autoCompactWindow，好像沒效果？
依序檢查：值要寫純整數，200k 會被讀成 200 而超出範圍；範圍是 100000 到 1000000，而且要小於子代理原本會繼承的視窗；如果設了 CLAUDE_CODE_AUTO_COMPACT_WINDOW，它會蓋過這個欄位；用 --agent 或 agent 設定把整個 session 當子代理跑時也沒有作用。最後用 claude --debug 在 log 裡搜尋 invalid autoCompactWindow 確認有沒有被忽略。
我不是工程師，這個比喻怎麼理解？
把子代理想成請一位助手幫你做一件事。普通子代理是給他一張任務單，他從零開始；fork 是讓他先把你們到目前為止的整段對話記錄看完再開工。後者不用重新解釋，但他要讀的資料很多。這個預設在自動化流程裡改變了，所以如果你負責看費用，升級後請工程師比較一次用量。
多數人對子代理的印象是「開一個乾淨的 context 去做一件事」。fork 子代理刻意不這樣做：官方文件的說法是，fork 是繼承目前整段對話的子代理，而不是從頭開始，這等於放棄子代理原本提供的輸入隔離，換來「不必重新交代背景」。2026 年 10 月 16 日的 v2.1.302 又把 fork 在 claude -p、Agent SDK、桌面版與 VS Code 預設開啟，所以這個取捨現在會在更多場合自動發生。
依官方子代理文件，普通子代理的起始 context 只有：自己的 system prompt、任務訊息、CLAUDE.md、git status，以及預載的 skill，看不到你的對話歷史。fork 則和主 session 看到同樣的 system prompt、工具、模型與訊息歷史，而且拿到主對話完全相同的工具集，也就是跳過了普通子代理會被套用的兩道工具過濾。output style 也是這樣：文件說它不會影響普通子代理，「除非是 fork」。
相同的是產出方式：fork 自己的工具呼叫不會進到你的對話，只有最終結果會回來，所以主 context 仍然保持乾淨。
文件的建議是：當任何其他子代理都需要太多背景才能派上用場，或你想從同一個起點平行嘗試幾種做法時，用 fork。啟動方式有兩種：讓 Claude 透過 Agent 工具要求 fork 子代理類型（fork 模式開著時），或隨時用 /subtask <任務>，例如 /subtask draft unit tests for the parser changes so far。/subtask 需要 v2.1.212 以上；v2.1.161 到 v2.1.211 之間這個指令叫 /fork。如果關掉了 agent view，/fork 會啟動 fork 子代理，否則 /fork 會把整個 session 複製成一個新的背景 session。
觀察方式：提示列下方的面板會列出主 session 與每個 fork，↑／↓ 切換，Enter 開啟某個 fork 的 transcript 並可以送追問，x 停止執行中的 fork 或收起它的列，Esc 回到提示列。fork 完成時，結果會以一則訊息送回主對話；成功的列會立刻消失，失敗或被停止的列保留 30 秒。
v2.1.302 的更新說明：fork 子代理（subagent_type: "fork"）在 claude -p、Agent SDK、桌面版與 VS Code 預設開啟，和終端機一樣；CLAUDE_CODE_FORK_SUBAGENT=0 可以關閉，而 claude mcp serve 永遠不提供。同一則更新也改了背景行為：桌面版與 VS Code 現在一律在背景執行主對話的子代理，不再讓 Claude 選擇；子代理自己發出的 Agent 呼叫，在 claude -p、SDK、桌面版與 VS Code 預設在前景執行。
要提醒一個不一致：我讀到的官方子代理文件頁面仍寫著 fork 模式在 -p 與 Agent SDK 預設關閉，需要自己開。這很可能是文件落後於 v2.1.302，但我沒辦法確認，請以自己版本上的實測為準，必要時明確設定 CLAUDE_CODE_FORK_SUBAGENT。
更新說明沒有說明 fork 對成本的影響，我讀到的文件頁面（在 fork 段落中途被截斷）也沒有談 fork 的 prompt caching。DEV Community 的整理說它可能讓 headless 的花費變高也可能變低，並建議先量測幾次再決定。我的推論（不是文件內容）是：普通子代理靠隔離節省 tokens，fork 則把整段歷史當成輸入帶進去，對話越長，這個輸入越大，但它省下了 orchestrator 寫 brief 與子代理重新探索背景的成本。哪一邊划算，取決於你的對話長度與任務性質。
v2.1.296 起，子代理的 frontmatter 與 --agents 定義可以設定 autoCompactWindow，讓這個子代理在 100000 到 1000000 之間的某個 token 數就提早壓縮。官方文件的幾條規則都很容易踩到：
---
name: log-reader
description: Reads long log files and reports the errors it finds
autoCompactWindow: 200000
---200k 會被讀成 200，超出範圍，子代理就當作沒有這個欄位。要確認值有沒有被忽略，執行 claude --debug 並在 debug log 搜尋 invalid autoCompactWindow。CLAUDE_CODE_AUTO_COMPACT_WINDOW，子代理會用那個變數的視窗，這個欄位沒有作用。--agent 或 agent 設定把整個 session 當成子代理跑時，這個欄位也沒有作用。以下是我的建議（不是官方規範）：任務自成一體、想要隔離、或背景很短就能講完，用普通子代理；需要大量既有討論才能做對、或想從同一個起點平行試幾種方案，用 fork；在自動化流程裡升級到 v2.1.302 之後，先量測一輪 token 用量，再決定要不要設 CLAUDE_CODE_FORK_SUBAGENT=0。