過去三個月我在工作上密集使用 Claude Code 處理維運任務——從日常巡檢、事件排查、規格撰寫、到跨雲服務的自動化。雖然時間不長,但這段密集的沉浸式經驗讓我意識到兩件事。第一件是,我自己一開始也在事後才意識到,市面上多數談 AI 工具的文章集中在「工具介紹」或「使用教學」的層級,從工程角度拆解運作機制的繁中資源不是那麼容易找。第二件是,從企業維運與合規視角談 AI 助理的繁中資源同樣不多見——這個視角需要結合對 AI 工具的技術理解、對企業資訊架構的實務經驗、以及對合規治理的敏感度,三者剛好同時關心的人不多。

這個系列想填補的,就是這個空缺。我寫的每一篇都有一個共同的預設——讀者是具備工程能力、對效率有要求、同時對合規與治理敏感的專業工作者。不論你是 DevOps、SRE、infra 工程師、還是需要評估 AI 工具的技術主管,這個系列希望提供一條相對完整的脈絡,而不是零散的技巧。

系列地圖

整個系列由十篇文章組成(第 8-10 篇正在準備中)。前半部(第 1-5 篇)聚焦於機制理解,幫你建立對 Claude Code 運作方式比較深入的認知。後半部(第 6-10 篇)轉向決策與治理,處理使用過程中的工具選擇、成本、商務、權限、以及跨階段的工作流整合。

**第 1 篇《為什麼 Claude Code 是不一樣的 AI 工具》**是系列的地基。許多人把 Claude Code、Copilot、Cursor、ChatGPT 當成同類產品比較,我覺得這是類別上的混淆。這一篇先把座標系統建立好,讓你看到 Claude Code 屬於一個完全不同的工具類別——Agentic CLI——它解決的問題、要求的使用方式、帶來的價值,跟 IDE 外掛式的 AI 助理有本質差異。

**第 2 篇《Agent Loop:AI 助理的心跳機制》**開始進入技術核心。你以為自己在「跟 AI 對話」,實際上是在驅動一個迴圈。這個認知的轉換很關鍵——不懂 Agent Loop,後面所有的成本優化、context 管理、權限設計都會是黑盒魔法。這一篇用一個具體情境,拆解從你按下 Enter 到 AI 回應完成之間的六個階段。

**第 3 篇《四層 Context 壓縮:200K 窗口的真實調度》**是整個系列技術密度較高的一篇。Context 管理是 Claude Code 設計上比較精巧、也比較容易被誤解的一塊,而且直接影響使用體驗。這一篇完整拆解四層壓縮管線——Pre-pipeline、Snip Compact、Micro Compact、Context Collapse、Auto Compact——並分析何時用哪一層、為什麼這樣排序、以及 1M context 出現之後這套系統發生了什麼變化。

**第 4 篇《Sub-agent 與 Agent Team》（分上下集)**是一組對照。上集是純技術篇,拆解 Sub-agent 的四種隔離模式、Fork 的 byte-identical prefix 設計、以及 Claude Code 為什麼能每週 spawn 數千萬個分身而不破產。下集是治理篇,談為什麼「一人分飾多角」會搞砸任務、如何用劇組式的角色分工建立可稽核的工作流、以及這套設計為什麼跨 AI 可攜、是你自己設計的工程資產。這兩篇合起來,處理了一個我在繁中資源中不太常看到被一起拆開講的主題。

**第 5 篇《Token 成本的真相》**是實務派讀者最關心的一篇。這篇用一個核心觀念貫穿全文——你不是在為「最近一句話」付費,而是在為「整段對話歷史每輪都重新送一次」付費。理解這件事之後,所有的成本優化策略(Prompt Cache、精簡 CLAUDE.md、主動壓縮、Agent Team 分工)都有了共同的底層邏輯。讀完這篇,你比較容易指出帳單上每塊錢花在哪、哪些可以省、哪些不能。

**第 6 篇《當工具自薦時:SSDLC 裡 Claude 各入口的角色與邊界》**處理一個比方案選型更上游的問題——在 SSDLC 的每個階段,該用哪個 Claude 入口?Claude Code、Claude.ai、API,同一個模型放在不同平台,擅長的事情不一樣。這篇從一次對照實驗開始,揭露 Anthropic 官方承認的 self-preference bias(自我偏好偏誤),並從中導出一組獨立於工具本身的判準——讓 SSDLC 流程本身告訴你答案。下一次 Anthropic 推出新入口、舊入口改版、整個產品結構大洗牌,這組判準應該還能繼續用。

**第 7 篇《選型與合約》**是商務決策的一次性整理。Anthropic 提供四種服務管道,各自解決不同的問題,不是「由小到大的階梯」。這一篇分享我整理的每個方案差異、訓練政策的觀察、資料保留期的官方不一致現象、不同規模使用者的可能路徑,還有一個進階的「去識別化閘道」設計。對我而言,選對方案的一次性決策,常常比後面的技術優化更值得提早花時間想清楚。

閱讀路徑建議

這些文章是一個連貫的整體,但我理解不是每位讀者都有時間通讀。以下是三種路徑建議,你可以依自己的角色挑選最適合的切入方式。

技術深入派如果你最想要理解 Claude Code 的內部機制,建議依序讀第 1、2、3、4 篇。這四篇是純技術篇,看完你應該會對這個工具的運作方式有比較完整的認知,之後讀其他相關文章可能也會更快吸收一些。

實務導入派如果你已經在使用 Claude Code,想解決實際問題——尤其是成本爆炸、行為失控、合規疑慮——建議讀第 1、5、6、7 篇,加上第 4 篇下集。這五篇處理的都是我自己在 POC 中遇到、我猜也是很多人會遇到的問題,原理面的內容被我壓縮到最必要,主要是給你可執行的決策依據。

主管決策派如果你是評估是否要導入、或如何規範團隊使用 AI 工具的主管,建議讀第 1、5、6、7 篇。這四篇包含了我覺得主管視角最需要的資訊——第 1 篇讓你理解這個工具的真實價值,第 5 篇讓你能比較準地估成本,第 6 篇幫你思考不同 SSDLC 階段該用哪個入口,第 7 篇讓你能較有把握地做採購決策。如果連續讀,大約一個下午可以讀完。

系列中的承諾

寫這個系列的時候,我對自己設了幾條明確的邊界。

內容必須真實可驗證,避免 AI 幻覺。所有對 Claude Code 內部機制的描述,都基於公開的逆向工程資料與我自己的實務觀察,每一個具體數字都有來源。寫作過程中我刻意迴避了一些連我自己都不敢確定的細節——寧可用「通常」、「大約」這類框定性語言,也不杜撰精確數字。具體閾值(例如 Auto Compact 的 167K threshold)則標示了計算方式,讓讀者可以自己驗證。

文中引用的案例來自真實的 POC 專案,但敏感細節已全部匿名化。這個系列的內容根基於我目前進行中的一個 POC 專案——把 AI 助理深度導入日常維運工作——所發生的真實事件。這讓文章中的教訓不是純理論推演,而是第一手觀察。但真實事件的組織名稱、人員身份、IP 位址、系統識別碼、客戶資訊都已經全部移除。保留下來的是通用的技術教訓,不是組織內部的 know-how。讀者從案例裡學到的模式應該可以套用到自己的環境,但無從反推原始事件的任何識別資訊。

不代表任何組織立場。所有觀點都是我個人的學習與實務心得整理,跟任職組織的立場無關。如果某個觀點讓你覺得「這跟我認知的主流說法不一樣」,那可能就是我真實的觀察,不是鸚鵡學舌。

內容創作方式是「人類主導、AI 協同」,我坦誠說明這件事。每一篇的觀點、案例、技術判斷都來自我自身的學習,以及在 POC 專案中累積的真實維運實務經驗;文字的組織與表達的打磨則由 AI 協助完成。這也是我寫這個系列時想傳達的一個觀察——對我而言,AI 比較適合用來放大工程師的判斷力,而不是取代它。

最後,技術世界變化非常快。這個系列的某些細節(特別是方案定價、模型規格、API 行為)可能隨時間改變。撰寫時是 2026 年第二季的狀態,讀者如果在之後的時間點閱讀,建議重要決策前再次驗證當時的官方資訊。

接下來

前七篇建立了我目前摸索到的認知輪廓,從機制到治理都接觸了一輪。但整個系列還有三篇正在準備中——第 8 篇《Hooks 與權限系統:讓 AI 聽話的三道關卡》會進一步深入技術性的安全治理;第 9 篇《把 Claude Code 接進維運日常》會是一個 infra 工程師的真實工作流整合;第 10 篇則會專門處理「架構分析」與「飄移檢查」這兩類橫跨 SSDLC 的元活動——它們的工具分工邏輯比單一階段複雜,需要獨立展開。這三篇完成後,整個系列會擴充到十篇,讓「從理解到落地」這條路線能走得更完整一些。

在這之前,如果你有任何建議、疑問、或發現任何不準確之處,歡迎來信 st333117@gmail.com。這個系列的每一篇都會持續改進,你的回饋會讓它更好。

現在,從你最有感的那一篇開始讀吧。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/00-series-index/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 1 篇。全系列共十篇(第 8-10 篇正在準備中),從原理到落地完整涵蓋。

一個工程師的困惑

我手上已經有 GitHub Copilot,每天打開網頁版 Claude 問東問西,偶爾用 Cursor 改 code。為什麼還要在 terminal 裡裝一個 Claude Code?

這是我一開始的疑問。我猜很多人也是。

答案我花了一段時間才真的想清楚:這些工具不是在競爭同一件事,它們解決的根本就是不同類別的問題。把它們擺在一起比較,就像把「螺絲起子、電鑽、CNC 加工機」拿來問「哪一個比較好?」——問題本身就設定錯了。

這篇文章不是要告訴你 Claude Code 比其他工具「更好」,而是要說清楚它是什麼種類的東西。理解這件事之後,後面幾篇的技術細節你才能真的吸收。

先把座標定好:四種工具在做四件事

我用自己的理解把市面上常見的 AI coding 工具分成四類。分類標準是「它主要在幫你做什麼層級的事」:

這張表不是要排名高下。每一種工具都有它最適合的場景:寫前端切版,Copilot 行內補全超好用;討論一個演算法,網頁版 Claude 反而最合適;想在 IDE 內一次改 20 個檔案,Cursor 是最舒服的選擇。

Claude Code 屬於第四類,也是目前繁中圈討論相對少、但對 infra 與後端工程師可能很有價值的一類。

Claude Code 在做什麼:三個關鍵特徵

把 Claude Code 定位成「Agentic CLI」之後,它的設計選擇就變得合理了。我整理三個讓它和前三類工具根本不同的特徵。

特徵一:它是真正的 Agentic Loop,不是 Autocomplete

Copilot 在幫你打字,Claude Code 在幫你完成任務。

差異在哪?行內補全是「輸入 → 猜測 → 輸出」的單次循環。Agentic loop 是:

接收任務
  → 讀取 context(檔案、git 狀態、past conversation)
  → 呼叫模型決策
  → 執行工具(讀檔、寫檔、跑 bash、搜尋)
  → 把結果餵回給模型
  → 判斷任務是否完成
  → 完成 or 進下一輪

這個迴圈可以跑 5 次、20 次、甚至 100 次,直到任務真的完成或者達到上限才停。你不需要每一步都手動點「繼續」。

我第一次真正體會到這個差異,是請 Claude Code 幫我處理一個「從 production 撈最近 7 天的 nginx log、找出回應時間異常的 request、產出 markdown 報告」的任務。我給它的 prompt 很短,但它自己:

1. 先問我 log 放在哪
2. 用 grep 和 awk 篩出候選行
3. 發現時間格式有兩種版本的 log,自己調整 parser
4. 產出表格,還主動附上我沒要求的「建議下一步」

整個過程我只回了「在 /var/log/nginx/」這一句。這就是 agentic loop — 它把分解任務、執行、驗證結果這些原本是工程師在做的事,也一起接手了。

這個能力是 Claude Code 的技術基礎,也是後面所有章節的前提。如果這件事沒發生,權限系統、context 管理、token 優化都是假議題。

特徵二:權限系統是 First-Class Citizen,不是事後補的

一旦工具可以執行 bash,風險就來了。

這是所有 agentic 工具必須面對的問題。Claude Code 的設計選擇是:把權限管控放在架構的第一層,而不是事後用規則補。

它的權限模型有三個層次(這是後面第 8 篇會細講的主題,這裡先建立印象):

• CLAUDE.md:指導性約束(軟)。你用自然語言告訴 AI 「不要修改 migrations/ 目錄」。
• Permission Rules:聲明性約束(中)。settings.json 裡寫 allow / deny / ask 規則,例如 "Bash(rm -rf:*)": "deny"。
• Hooks:可編程約束(硬)。在 tool 執行前插入腳本,可以做任意檢查、修改、甚至攔截。

三層不是任選其一,是縱深防禦。CLAUDE.md 可以被模型繞過,但 permission rules 擋得住;permission rules 匹配不到的模糊情境,hooks 可以用程式判斷。

這件事聽起來理所當然,但很多 AI coding 工具是先做功能,再補權限,導致你得自己用外圍手段(例如另開容器、限制帳號權限)去防。Claude Code 把這件事當設計地基處理,我覺得對需要在企業環境下使用的人比較有感。

特徵三:Context 管理是工程問題,不是黑盒子

大語言模型有個硬性限制:context window。目前 Claude 系列模型的上下文窗口通常以數十萬 tokens 計,聽起來很多,但如果你跑一個兩小時的維運任務,它會填滿得比你想像快。

Context 滿了會發生什麼?模型開始忘東西,回答品質下降,最後乾脆拒絕繼續。

大多數 AI 工具對這件事的處理方式是「看運氣」—— 希望模型自己記得關鍵資訊。Claude Code 的做法是把 context 當成要主動管理的工程資源,設計了多層壓縮管線,在不同階段用不同策略釋放空間。

這件事的細節會在第 3 篇完整展開(那一篇會是整個系列最燒腦的一篇)。這裡先記一個結論:Claude Code 的 context 管理不是黑盒,它是一套可觀察、可調控、可最佳化的系統。理解這套系統,對後面「如何省 token、如何讓長任務跑得穩」這些實務問題比較有幫助。

它適合誰,不適合誰

設計哲學釐清之後,適用場景也就清楚了。以下是我的判斷,不是官方說法:

適合的人

• 後端工程師 / DevOps / SRE / infra 工程師:你有大量跨檔案、跨服務、需要 shell 才能完成的任務。
• 有版控習慣的人:Claude Code 會直接改檔案,沒有 git 你會救不回來。
• 能接受 CLI 的人:它的主要介面就是 terminal,不會有人想把它弄成圖形介面。
• 想把 AI 當協作者而不是神諭的人:你需要檢查它的產出、給它 context、設計工作流。

暫時不適合的人

• 純前端切版 / 純 UI 調整的工作:Cursor 這類工具視覺化支援更好。
• 完全不看 terminal 的人:學習曲線會卡很久。
• 一次性問答需求:「幫我解釋這段 code」這種需求,網頁版 Claude 反而快。
• 想要「一鍵產生完整專案」的人:Claude Code 可以做,但你得先搞懂權限、context、hooks 這些基礎,否則會失控。

這不是貶低任何一群人。工具有適用場景,選對工具比硬用同一個好。

給主管的一段話

如果你是主管,在決定要不要讓團隊用 Claude Code,我自己的看法是:把它當成工程生產力工具來評估,我覺得比當「試試看的 AI 玩具」來看更走得遠。

• 它不是要取代工程師。以我自己這三個月 POC 的觀察,它讓一位工程師的單日產出能被放大。
• 它確實有學習成本。我自己初期幾週也是越用越順手、並不是一上手就看出明顯效益。
• 它需要配合組織層面的規範(權限設定、敏感資料保護、產出審查),不是裝了就能用。
• 它的費用在團隊理解 token 消耗邏輯之後是可預測的(第 5 篇會詳談)。

評估投資報酬時,我自己不太看「AI 寫了幾行程式碼」這類指標,覺得那比較容易誤導。我比較看的是「工程師完成同樣任務需要的總時間」和「產出的品質與可追溯性」。

這個系列會回答什麼

這是系列第 1 篇。已經上線的六篇依序展開機制、成本、與決策:

系列還有三篇正在準備中——第 8 篇《Hooks 與權限系統》會深入技術性的安全治理,第 9 篇《把 Claude Code 接進維運日常》是一位 infra 工程師的真實工作流整合,第 10 篇則專門處理「架構分析」與「飄移檢查」這兩類橫跨 SSDLC 的元活動。

如果你是純技術派,我建議讀 1、2、3、4 就夠。 如果你是實務派,讀 1、5、6、7 就夠,加上第 4 篇下集。 如果你是主管,讀 1、5、6、7 就夠。

一句話收尾

Claude Code 不是「比較強的 Copilot」。對我而言,它是一種讓工程師從執行者變成指揮官的工作方式,代價是你需要理解它的運作機制,不能當黑盒用。

下一篇我們從最基礎的 Agent Loop 開始拆解。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/01-why-claude-code-is-different/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 2 篇。前一篇談了為什麼 Claude Code 是不一樣的工具,這一篇開始進入它的運作核心。

為什麼先懂這個

你可能以為你在「跟 Claude Code 對話」。

實際上,你是在驅動一個迴圈。

這個差異不是修辭。搞懂之後,後面所有的疑問都會有答案:

• 為什麼同樣一句話,有時候 3 秒結束、有時候跑 5 分鐘?
• 為什麼 token 帳單會爆炸,而且完全看不出錢花在哪?
• 為什麼一個任務進行到一半會卡住?
• 為什麼「thinking…」有時候真的在想,有時候只是在處理資料?

這些問題的根源都在 Agent Loop。這篇文章不是教你怎麼用 Claude Code,是要你建立一個關於它運作方式的心智模型,這個模型會貫穿整個系列。

三句話版本的 Agent Loop

如果要用最精簡的方式描述,Claude Code 做的事情就是這三件:

1. 接收輸入,組裝成模型看得懂的 prompt
2. 呼叫模型,拿到回應
3. 判斷要不要繼續,要繼續就執行工具,拿結果回到第 1 步

聽起來很簡單。但魔鬼在細節裡,尤其是第 3 步的「判斷要不要繼續」。這個判斷讓 Claude Code 從「問答工具」變成「任務執行者」。

一次對話實際發生了什麼

我們用一個具體情境拆解:你在 Claude Code 裡輸入「幫我看看今天早上 nginx 的錯誤日誌,有沒有 5xx 的異常」,然後按下 Enter。

接下來發生的事情,可以分成六個階段。

階段一:你按下 Enter 之後的 0.1 秒

訊息送進 Claude Code 的處理管線之前,先經過一道輸入處理:

• 如果你輸入的是 slash command(像 /compact、/init),會被攔截走另一條路徑
• 如果你附加了圖片或檔案,會被轉成對應的 message block
• 如果你用 @ 引用了檔案(@src/main.ts),會把檔案內容塞進 context
• 純文字就直接進入下一步

這一步很快,但它決定了你送進去的不只是你打的那幾個字。

階段二:System Prompt 的組裝

這是很多人忽略的關鍵環節。

每次你送訊息,Claude Code 會動態組裝一個 system prompt,這個 prompt 由好幾個部分拼成:

[核心身份與工具說明]          ← Claude Code 本身的 prompt,固定
[環境資訊]                    ← 作業系統、shell、目前工作目錄
[專案上下文]                  ← 你的 CLAUDE.md 和 @import 的檔案
[MCP 工具描述]                ← 你裝的 MCP servers 的 tool schemas
[內建工具描述]                ← Read/Write/Bash/Grep 等工具的說明
[Git 狀態]                    ← 目前 branch、uncommitted changes
[過去對話歷史]                ← 如果是延續 session,過去的 turns 都在這

這個組裝順序和內容會影響兩件事:

1. Token 消耗:每次送出的 prompt 越長,輸入 token 越多。
2. 模型行為:你 CLAUDE.md 怎麼寫,直接決定模型會怎麼回應你。

這也是為什麼減少 CLAUDE.md 裡不必要的內容,我自己觀察是 token 優化裡很容易見效的一個手段。把 CLAUDE.md 寫成長篇大論,等於每一輪都在付那個長篇大論的錢。

階段三:API Call 與 Streaming

組裝好的 prompt 送到 Anthropic 的 API,模型開始回應。

你注意過嗎?Claude Code 的回應是一個字一個字跑出來的,不是整段突然出現。這叫做 streaming,模型一邊思考一邊吐字,Claude Code 一邊接一邊顯示。

Streaming 有幾個現實影響:

• 你可以在中途按 Esc 取消:模型還沒講完,你就可以打斷它,不用等它講完再操作。
• 延遲感知比較低:即使整個回應要 30 秒,你看到第一個字通常只要 1-2 秒。
• Tool use 也是 stream 的一部分:當模型決定要呼叫工具,那個指令也是 stream 出來的,Claude Code 接到就準備執行。

階段四:Tool 的識別與執行

這是 Agent Loop 最核心的一步。

模型的回應裡可能有兩種東西:

• 純文字:給你看的說明、分析、結論
• Tool Use Block:「我需要執行某個工具,請幫我跑」的指令

當 Claude Code 偵測到 tool use block,它會:

1. 檢查這個工具是否在白名單(對應上一篇講的三道關卡)
2. 如果需要你確認(ask 規則),跳出確認對話
3. 實際執行這個工具(讀檔、跑 bash、呼叫 MCP 等)
4. 把執行結果包成 tool_result,準備送回模型

用我們的 nginx 例子:

• 模型第一輪可能先發出 Bash: ls /var/log/nginx/ 想看有哪些 log 檔
• Claude Code 執行後,把結果送回模型
• 模型第二輪可能發出 Bash: grep -E " 5[0-9]{2} " /var/log/nginx/access.log | head -50 篩出 5xx
• 執行後結果再送回
• 模型第三輪可能已經分析完,直接用文字回答你

你看到的「Claude 幫我查完了」,其實是至少 3 次 API call + 2 次工具執行的結果。

階段五:判斷要不要繼續

這是 loop 的關鍵節點。

每一輪模型回應結束後,Claude Code 會問:回應裡還有 tool use block 嗎?

• 有 → 執行工具,把結果送回,進入下一輪
• 沒有(只有文字) → loop 結束,把控制權交還給你

這個判斷聽起來簡單,但它是整個 agentic 行為的基礎。模型自己決定「我需要更多資訊」或「我完成了」,不需要你每一步都按「繼續」。

階段六:終止條件

除了模型自主判斷完成,loop 還有幾個強制終止的條件:

• Max turns:預防無限迴圈,達到上限會停
• 使用者中斷:你按 Esc
• 權限拒絕:你拒絕了某個工具的 ask,而模型沒有備案
• 錯誤:API 失敗、tool 執行錯誤且模型無法處理

這解釋了為什麼你有時候覺得 Claude Code「沒做完就停了」 —— 它其實是碰到了某個終止條件。看錯誤訊息或 verbose mode 可以知道是哪一個。

一張圖總結:Agent Loop 的完整流程

你按下 Enter
    │
    ▼
[輸入處理] slash command? 附件? @引用?
    │
    ▼
[組裝 system prompt] 固定部分 + 環境 + CLAUDE.md + tools + git + 歷史
    │
    ▼
┌─── 進入 Query Loop ───┐
│                        │
│  [呼叫 API,streaming 回應]
│           │
│           ▼
│  [識別 tool_use block]
│           │
│     有 ─┴─ 沒有
│      │       │
│      ▼       ▼
│  [執行工具]  [結束 loop,回傳給你]
│      │
│      ▼
│  [結果送回模型]
│      │
│      └──→ (下一輪)
│
└────────────────────────┘

這就是每次你跟 Claude Code 互動時,底層真正發生的事。

Tool 執行:序列還是平行?

模型在一次回應中可以發出多個 tool use block。當這發生時,Claude Code 要決定:這些工具能不能同時跑?

判斷邏輯大致是:

為什麼這個區分重要? 因為平行執行會大幅加速任務。當 Claude Code 一次叫 10 個 Read 去看 10 個檔案,平行跑和序列跑的體感差距是 10 倍以上。

這也是為什麼 Claude Code 有「Explore」這類唯讀 sub-agent —— 唯讀保證可以平行,速度快,而且不會搞壞東西。(Sub-agent 的主題會在第 4 篇展開)

這些機制對你實際操作的意義

搞懂 loop 之後,很多「奇怪的現象」都有答案了。

為什麼長任務會越跑越慢

每一輪 loop,Claude Code 都要把整段對話歷史重新送進 API。對話越長,每一輪要傳的東西越多,API 呼叫越慢,也越貴。

這就是為什麼到了某個臨界點,任務會明顯變慢。原因不是「AI 累了」,是 context 逼近上限,每一輪的 overhead 越來越大。

這個問題的解方就是 context 壓縮,下一篇會整個展開。

為什麼「thinking…」有時候很久

「thinking…」其實有兩種:

1. 真的在 extended thinking:模型在做內部推理,這部分會花時間但也確實在產出思考
2. 在處理 tool result:前一個工具剛跑完,結果很大(例如讀了一個 500 行的檔案),模型正在消化

如果你覺得 thinking 太久,可以開 verbose mode 看它到底在做什麼。通常第二種比較常見。

為什麼某些操作會卡住等你

這是權限系統介入的時刻。當模型想做的事情在 ask 規則裡,Claude Code 會跳出確認對話,loop 在你回應之前是停住的。

這不是 bug,是設計 —— 確保你對破壞性操作有最後一次確認機會。

為什麼同樣一句話,效果差很多

兩個使用者問一樣的問題,結果天差地遠的主因不是「模型不穩」,而是:

• CLAUDE.md 寫得不一樣
• 當前 working directory 不一樣
• 已經在 session 裡累積的 context 不一樣
• 裝的 MCP tools 不一樣

System prompt 的組裝階段(階段二)就決定了結果差異中很大一部分。這也是為什麼我覺得團隊裡把 CLAUDE.md 寫好、統一管理,通常會比讓每個人自己摸索更可預期一些。

我自己經歷的一次觀念轉換

我自己一開始使用 AI 助理的心理模型是這樣:

「我在問 AI 一個問題,它回答我。」

用 Claude Code 一段時間後,我自己慢慢轉成這樣:

「我啟動了一個迴圈,這個迴圈會執行多輪,直到達成我給的目標或觸發終止條件。我的任務是設計好這個迴圈的起點、邊界、和終止條件。」

這個轉換之後,我開始問自己不一樣的問題:

• 我這句 prompt 會讓 loop 跑幾輪?會不會太多?
• 這個任務需要的 context 是否都在 loop 開始時就備好了?
• 如果 loop 跑太久,我該怎麼設計 checkpoint?
• 什麼情況下應該主動終止 loop,換個方式再來?

這些是我自己覺得在「熟練使用 Claude Code」之後比較常想的事。

下一篇預告

搞懂 loop 之後,下一個繞不開的主題就是 context 管理。

在這篇裡我們看到:每一輪 loop 都要把整個 context 送進 API。當 context 逼近上限會發生什麼?Claude Code 怎麼在你不察覺的情況下,把空間清出來?

這個系統比表面看起來精巧 —— 有四層壓縮管線,每一層用不同的策略,該什麼時候哪一層啟動都有明確規則。

下一篇,我們把這個黑盒打開。

本篇重點整理

• Claude Code 不是對話工具,是任務執行迴圈 —— Agent Loop
• 每次你按 Enter,會經過六個階段:輸入處理 → 組裝 system prompt → API call → 識別 tool use → 執行工具 → 判斷是否繼續
• Loop 的終止由模型自主判斷或強制條件(max turns、權限拒絕、錯誤、使用者中斷)觸發
• Tool 可以平行或序列執行,唯讀類通常平行、有副作用的通常序列
• 長任務變慢的主因是 context 越來越大,每一輪 overhead 放大
• 心智模型上的轉換:從「我在問 AI」到「我在驅動一個迴圈」

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。本文對 Claude Code 內部機制的描述,基於社群對 Claude Code 的公開分析材料與筆者實務觀察,並非 Anthropic 官方文件。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/02-agent-loop/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 3 篇。前一篇談了 Agent Loop,這一篇會進入這個系列裡技術密度較高的主題。如果你之前對「為什麼我的 context 會突然不夠用」、「/compact 到底何時該按」、「Claude 為什麼突然開始忘東西」這些問題感到困惑,這篇會把這些機制一起拆開來看。

為什麼需要整整一篇寫這件事

前一篇講了 Agent Loop —— 每一輪模型呼叫,都要把整段對話歷史送進 API。

這件事在對話短的時候沒人會在意。但當任務開始變長:

• 一個跨 10 個檔案的重構
• 一次完整的事件排查
• 一份規格文件從草稿到定稿的對話

你會發現一個令人焦慮的現象:Claude Code 開始回應變慢、帳單變貴、有時候甚至主動告訴你「context 快滿了」。

根本原因在於 context window 的物理上限。以目前主流的 Claude 模型來說:

• 舊一代模型(例如 Sonnet 4、Sonnet 4.5):上限 200K tokens
• 新一代模型(Opus 4.6 / 4.7、Sonnet 4.6):上限提升到 1M tokens,且自 2026 年 3 月起已 GA 無溢價

聽起來 1M 似乎什麼煩惱都沒了?實際沒這麼簡單 —— 稍後會有一節專門談「1M 不是萬靈丹」。這裡先建立一個共識:不論你用哪一代模型,壓縮管線的設計原理都一樣,只是觸發閾值不同。

一個五小時的維運任務,搭配幾份被讀進 context 的大型設定檔,即使在 200K 窗口也會消耗得比你想像快。

如果 Claude Code 對這件事不做任何處理,用戶體驗會是這樣:

使用到 80%:正常 80% → 95%:越來越慢,因為每一輪都在傳巨量 context 95% → 100%:API 開始拒絕,因為超過模型上限 100% 之後:session 直接掛掉,你要從頭來過

所以 Claude Code 設計了一套系統,在你不察覺的情況下,持續清理 context 空間。這套系統有四層,每一層用不同策略,對 token 的衝擊從「幾乎零成本」到「呼叫一次 API 做摘要」不等。

這篇文章要做的,就是把這四層攤開來。

為什麼不能只用一種壓縮策略

你可能會想:為什麼不直接一招?等 context 滿了再叫模型摘要不就好?

這會有兩個問題。

問題一:摘要本身很貴。讓模型把 100K tokens 的對話摘成 20K tokens,這個動作就要再花一次 API call,還要花 output token 產生那 20K 摘要。如果每隔幾輪就做一次,光摘要就吃光你的預算。

問題二:過早摘要會丟失資訊。你不會希望一個還在處理中的子任務被摘成三句話 —— 模型會失去它需要的細節,回應品質直接掉下來。

合理的設計是:先用最便宜的手段釋放空間,真的不夠了再用昂貴的手段。這就是四層管線的核心思想。

四層管線的全景

在每一輪 Agent Loop 準備呼叫 API 之前,Claude Code 會依序跑過下面這些階段:

 ┌─────────────────────────────────────────────┐
 │  Pre-pipeline: Tool Result Budget           │  ← 過大 tool result 的預先處理
 └─────────────────────────────────────────────┘
                      │
                      ▼
 ┌─────────────────────────────────────────────┐
 │  Layer 1: Snip Compact                       │  ← 零成本修剪
 └─────────────────────────────────────────────┘
                      │
                      ▼
 ┌─────────────────────────────────────────────┐
 │  Layer 2: Micro Compact                      │  ← tool result 壓縮
 └─────────────────────────────────────────────┘
                      │
                      ▼
 ┌─────────────────────────────────────────────┐
 │  Layer 3: Context Collapse                   │  ← 投射式壓縮
 └─────────────────────────────────────────────┘
                      │
                      ▼
 ┌─────────────────────────────────────────────┐
 │  Layer 4: Auto Compact                       │  ← API 摘要(最貴)
 └─────────────────────────────────────────────┘
                      │
                      ▼
           [送進 API 呼叫模型]

每一層都有它啟動的條件、代價、和清出空間的能力。我們一層一層拆。

Pre-pipeline:Tool Result Budget

這一層嚴格來說不是壓縮,是預防性措施。

場景:Claude Code 執行了一個 Bash: cat /var/log/nginx/access.log,檔案有 80MB。如果這 80MB 整個塞進 context,後面的管線會瞬間爆炸。

Tool Result Budget 做的事就是在 tool 執行結果進入 context 之前,先判斷它的大小。超過門檻的,會被內容替換(content replacement)—— 把原始龐大結果換成一個摘要訊息,原始內容寫入磁碟保留,context 裡只放一個引用。

這個設計很精巧的一點是:替換狀態跨壓縮持久化。也就是說,即使後面 Layer 4 做了大摘要,這個「被替換過的 tool result」的記憶不會丟失,模型還是知道「剛才跑了那個指令,結果很大被外存了」。

對你的影響:你不太需要關心這一層,它自動運作。但知道它存在有一個好處 —— 當你看到 tool result 被標記「truncated」時,那不是 bug,是這個機制在保護你。

Layer 1:Snip Compact(零成本修剪)

接下來進入壓縮管線的第一層,也是最便宜的一層。

Snip Compact 做的事情可以用一句話概括:把舊的、明顯可以丟的片段直接刪掉。

什麼叫「明顯可以丟」?典型的例子:

• 很多輪之前的一個 Bash: ls 指令和它的輸出
• 已經被後續行為覆蓋的舊檔案讀取結果
• 使用者已經明確說「這個不用了」的段落

這一層的關鍵特徵是 「零成本」 —— 它不呼叫 API、不做推理、只是按規則把某些 message 從 context 移除。計算開銷幾乎為零,釋放的空間卻可能非常可觀。

類比:就像你整理辦公桌時,先把明顯沒用的廢紙丟掉,還沒開始動需要判斷的東西。

Snip Compact 在每一輪都會跑,永遠是第一道防線。你幾乎察覺不到它在作用,但它默默為你省了大量空間。

Layer 2:Micro Compact(tool result 壓縮)

第二層開始有點技巧了。

Micro Compact 聚焦在處理 tool result。上一層刪了能直接丟的,但有些 tool result 還有價值 —— 模型可能之後要引用 —— 只是詳細程度過頭了。

舉例:你讓 Claude Code 讀了一個 500 行的設定檔,它讀完後做了分析,已經從裡面抽出重點。兩輪之後,完整的 500 行內容還佔著 context。這時候 Micro Compact 會做的事情是:

保留這個 tool result 的「殼」(它的 tool_use_id、它是哪個 tool、執行成功與否),但把詳細的內容替換成一個摘要。

關鍵設計:Micro Compact 以 tool_use_id 為單位運作,不拆解內容、不重組訊息結構。這讓它可以跟其他層安全組合 —— 它的處理不會影響訊息格式的完整性。

相較於 Layer 1:Layer 1 是「整段丟」,Layer 2 是「保留外層、壓縮內容」。Layer 2 的成本比 Layer 1 高一點(要產生摘要),但保留了可追溯性 —— 模型仍然知道「我剛才讀過某個檔案」。

Layer 3:Context Collapse(投射式壓縮)

這一層的設計最巧妙,也最難懂。

一般壓縮的做法是「修改 context 本身」—— 刪掉某些東西、取代某些內容。但這有個風險:修改是不可逆的。你丟掉的東西,就真的丟了。

Context Collapse 採用完全不同的思路:不修改底層的訊息歷史,而是建立一個「投射視圖」(projective view)。

用一個比喻:

想像你的對話歷史是一棟三層樓的書櫃,整整齊齊放著所有 message。 傳統壓縮是把某幾本書從書櫃搬走、直接丟掉。 Context Collapse 是在書櫃前面加一片毛玻璃 —— 書櫃本身沒變,但從外面看,某些書被遮住了,只看得到一個整體的輪廓。

這個設計的好處是:

1. 可還原:必要時可以把毛玻璃拿掉,完整歷史還在
2. 適合長 session:即使做了多次 collapse,底層訊息仍然保存
3. 給模型一個「精華版」:模型看到的是投射後的版本,而不是原始的完整對話

Context Collapse 的觸發有兩個門檻:

• 到達 90% 時:開始做 collapse commit(把舊的 message 封存進 collapse log)
• 到達 95% 時:進入 blocking 模式,禁止新的 tool 執行,避免 context 爆炸

Context Collapse 是一個功能開關(feature flag),不是所有版本的 Claude Code 都預設啟用。如果啟用了,它會取代 Layer 4 的工作(兩者互斥)。

對你的影響:如果你的版本啟用了這層,你會發現長 session 的品質比舊版本明顯穩定。但如果沒啟用,接下來的 Layer 4 就是最後防線。

Layer 4:Auto Compact(最重的手段)

前三層都還沒能把空間清出來夠用?好,Auto Compact 登場。

這是最貴、也最強的一層。它的做法是:

1. 開一個分叉的 agent(forked agent)
2. 這個 agent 的任務就是:把到目前為止的對話歷史,摘要成一段簡短的文字
3. 把原本的對話歷史替換成這段摘要
4. 繼續跑主 session

本質上,這是花一次 API call 去換 context 空間。成本高,但效果也最顯著 —— 幾十萬 tokens 可以瞬間被壓成幾千 tokens。

閾值的數學

Auto Compact 什麼時候觸發?這有明確的公式:

effective_window = context_window - 20,000  ← 保留給摘要輸出的空間
threshold        = effective_window - 13,000  ← 再留一個緩衝

套用到不同的 context window:

200K 窗口(Sonnet 4 / 4.5 等舊一代模型):

effective_window = 200,000 - 20,000 = 180,000
threshold        = 180,000 - 13,000 = 167,000   ← 約 83.5%

意思是:當 context 用到 167K 左右時,Auto Compact 自動觸發。

1M 窗口(Sonnet 4.6、Opus 4.6 / 4.7):

effective_window = 1,000,000 - 20,000 = 980,000
threshold        = 980,000 - 13,000 = 967,000   ← 約 96.7%

也就是說,1M 模型要撐到 967K 才會觸發 Auto Compact。實務上大多數 session 根本打不到這個數字,Auto Compact 在 1M 模型上幾乎不會被自動觸發。

為什麼都留 20K 給摘要?因為摘要本身也是 output tokens,也要在 context 裡佔位置。如果不預留,摘要還沒生出來就超標了。這個設計不隨 window 大小變。

要查自己目前的 window 大小,在 Claude Code 裡輸入 /context 指令,它會回傳 Xk/200k 或 Xk/1000k 的格式告訴你。

互斥規則

Auto Compact 有幾個情況不會觸發,原因都很務實:

那個 3 次連續失敗 circuit breaker 很值得一提 —— 它的存在是因為沒這個機制的時候,曾經有 session 連續失敗 50 多次,浪費了大量 API 呼叫。工程設計常常是這樣:一個看似簡單的保護機制,背後都是血淚史。

Session Memory:被忽略的精巧設計

Layer 4 有個優先嘗試的輕量版,叫 Session Memory Compaction。

相較於「開一個 agent 做全摘要」,Session Memory 更像「智慧修剪」—— 它不重新生成內容,而是有策略地挑選哪些 message 保留、哪些捨棄,試圖在不花一次 API call 的情況下達到目標。

觸發順序是:Session Memory 先試 → 失敗才走 full compact。這又是一個「便宜的先試,貴的最後上」的設計。

為什麼這樣排序:一個簡單的經濟學

回頭看這四層,你會發現它們的排列是有嚴格邏輯的:

從成本最低的開始試,能釋放多少算多少;前面的不夠用,才動用更貴的手段。

這就是這套系統背後的思路:對我而言,把 context 當成需要主動管理的資源,比交給運氣靈光來得安心一些。

1M 不是萬靈丹:你該知道的真相

看到這裡你可能想:「那我只要用 1M 模型,這四層壓縮我幾乎不用管了?」

技術上成立,但實務上要打一個大問號。

模型的 recall 能力會隨 context 膨脹衰減

window 變大 ≠ 模型能好好使用全部空間。

Anthropic 公佈的 MRCR(multi-needle retrieval)測試結果:

白話翻譯:你塞越多 context 進去,模型忘記東西的機率越高。即使技術上 window 能裝,模型的注意力會被稀釋。

實務上多數 session 根本用不到 1M

根據社群的實測觀察,大多數 Claude Code session 峰值落在 80K–120K tokens。真正需要用到 500K 以上的場景不多,通常是:

• 跨多個大型 codebase 的全域重構
• 一次讀入幾十份長篇文件做綜合分析
• 超長時間的自主 agent 任務(連續跑幾小時)

日常維運、除錯、寫規格這類工作,200K 都綽綽有餘。

1M 模型最實際的價值:降低 compact 頻率,不是撐更久

比較合理的用法不是「把 1M 塞滿」,而是:

• 在 80K–150K 的正常使用範圍內,讓你不用頻繁擔心壓縮觸發
• 遇到偶發的大型任務,不用馬上切 session 或 /compact
• 多一點彈性去讀幾個額外的參考檔案

換句話說,1M 是把「context 緊張」這件事推到後景,而不是讓你可以永遠不管它。

如果你在用 Pro 方案

Max / Team / Enterprise 方案是自動啟用 1M。Pro 方案需要手動執行 /extra-usage 才會開啟 —— 這是 Anthropic 有意識的設計,讓付費層級自然區分。

如果你在 Pro 而沒跑過 /extra-usage,你現在用的是 200K,不是 1M。可以用 /context 確認當下狀態。

環境變數可以強制關閉

少數場景你可能想強制只用 200K(例如為了控制成本、或在舊模型間切換時保持一致),可以設:

export CLAUDE_CODE_DISABLE_1M_CONTEXT=1

設了之後,model picker 不會出現 1M 選項。適合團隊統一環境配置時使用。

使用者能做什麼:主動 vs 被動

理論講完,來講實務。作為使用者,你不用去控制這四層(它們自動運作),但你有主動權在幾個關鍵時刻可以介入。

時機一:子任務結束時,主動 /compact

很多人以為 /compact 只在 context 快滿時才要用。這是我自己一開始也誤解的地方。

更聰明的用法是:每次完成一個子任務後,主動執行 /compact。

為什麼?因為自動觸發永遠是被動的 —— 要等到真的快滿了才動。而你完成一個子任務時,你最知道:

• 哪些前面的細節可以丟(「已經完成,結果正常」)
• 哪些需要保留(「這個決策後面還要用」)
• 下一個子任務需要什麼 context 基礎

這時候主動 /compact 並帶上 custom instruction,可能會比自動摘要更貼近你的需求。

範例:

/compact 重點保留:檔案修改清單、錯誤修正紀錄、未完成的 TODO。
可以丟掉:一般探索性的 bash 輸出、已經確認正確的讀檔結果。

時機二:切 session,不要依賴壓縮

壓縮再強,也比不上「開新 session」乾淨。

當你要換一個完全不同的任務(例如從「debug production」切到「寫下週的週報」),最好的做法不是在同一個 session 裡繼續,而是:

1. 把當前進度寫進一個檔案(例如 PROJECT_STATUS.md)
2. 結束當前 session
3. 開新的,從頭讀那個檔案作為起點

這比指望四層壓縮都要來得乾淨一些。

時機三:知道何時該停

有一個啟示來自前面的 3 次失敗 circuit breaker:如果 Claude Code 開始頻繁觸發 Auto Compact,那是警訊。

頻繁觸發代表你的任務規模已經超過 session 能舒服處理的範圍。這時候該做的不是「讓它繼續撐」,而是:

• 切分任務(拆成幾個小任務分 session 做)
• 檢查你的 CLAUDE.md 是不是寫得太長
• 檢查你是不是讀了一堆其實不需要的檔案進來

長 session 的壓力累積是真實存在的。管理 context 的最好方法,是從一開始就不要讓它膨脹。

幾個容易踩的雷

雷一:以為 /compact 是魔法按鈕

/compact 會丟資訊。即使你寫了 custom instruction,摘要還是會漏細節。該備份的關鍵結論,請寫進檔案。

雷二:在重要決策前觸發壓縮

如果 Claude Code 正在做一個關鍵判斷(例如「要刪哪些檔案」),不要在這時候手動 /compact —— 它可能把剛才的分析摘掉了,決策品質會受影響。等決策完成再壓縮。

雷三:盲目追求「context 撐越久越好」

有些人把「能不能不用壓縮撐完一個 8 小時 session」當成成就。這是誤解。能把任務切成小塊分段做,每段乾淨結束,才是更好的工程實踐。

一個我自己偏好的心態

四層壓縮聽起來很複雜,但它主要提醒一個觀念:

Context 是工程資源,不是取之不盡的倉庫。

你用任何工具時都有資源觀念 —— 記憶體、磁碟、網路頻寬都有上限。AI 助理的 context 也一樣,只是它太新,大家還沒建立習慣。

有這個觀念之後,我自己覺得一些選擇變得比較自然:

• 不會寫 10 頁的 CLAUDE.md
• 不會把整個 codebase 丟進對話
• 會主動切 session
• 會在關鍵時刻 /compact
• 會把結論寫進檔案,而不是記在對話裡

這些習慣累積起來,我覺得是「比較熟練使用 Claude Code」跟「一直踩雷」之間一個比較明顯的分野。

下一篇預告

接下來第 4 篇要談另一個常被混淆的主題:Sub-agent 與 Agent Team。

這兩個概念一直被工程師當成同一件事,實際上它們解決的是完全不同的問題 —— 一個是「怎麼讓 AI 跑得更快」,另一個是「怎麼讓 AI 聽話、有紀律」。

下一篇我們釐清這個誤會,並示範它們怎麼搭配使用。

本篇重點整理

• Claude Code 的 context 管理不是黑盒,是一套四層的壓縮管線,從便宜到昂貴依序嘗試
• Pre-pipeline:處理過大的 tool result,防止污染整個管線
• Layer 1 Snip:零成本修剪,刪掉明顯可丟的舊片段
• Layer 2 Micro:以 tool_use_id 為單位壓縮 tool result,保留外殼丟掉內容
• Layer 3 Collapse:投射式壓縮,建立 view 而不修改底層 —— 最巧妙的一層
• Layer 4 Auto Compact:最貴的手段,用一次 API call 換大量空間;閾值約 window 的 83.5%(200K)或 96.7%(1M)
• Session Memory:Layer 4 會先試的輕量版,不呼叫 API 就能做修剪
• 1M 不是萬靈丹:window 變大但模型 recall 能力會衰減,實務多數 session 根本用不到 1M
• 主動介入時機:子任務結束時 /compact、切 session 而不硬撐、知道何時該拆任務
• 核心觀念:把 context 當工程資源管理,而不是賭運氣

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。本文對 Claude Code 內部機制的描述,基於社群對 Claude Code 的公開分析材料與筆者實務觀察,並非 Anthropic 官方文件。具體閾值與行為可能隨版本演進。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/03-context-compression/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 4 篇,分上下兩集。上集聚焦 Sub-agent 的技術機制,下集談 Agent Team 的分工設計與兩者的搭配。

兩個被混為一談的概念

我在跟同事討論 Claude Code 的時候,常發現同一個場景被用兩種完全不同的方式描述。有人會說「我請 Claude 派了幾個 subagent 去平行跑搜尋」,另一個人會說「我用多個 agent 分工處理這個任務」。聽起來像同一件事,但這兩句話背後指的是兩個不同層級、解決不同問題的機制。把它們視為同義詞,是我自己一開始也踩過的盲點。

為了把這件事講清楚,這篇我只談 Sub-agent,下一篇才談 Agent Team。我自己摸索的觀察是:兩者雖然名字相近,但設計目的、壽命、使用情境、對 token 的影響都完全不同。上篇主要拆解 Sub-agent 作為 Claude Code 內部的執行機制,下篇處理 Agent Team——對我而言它比較不是技術問題,是工程治理問題。

先從一個比喻開始

想像你是一位主編,在寫一份重要的專題報告。這份報告需要你去查證五個不同來源的資料:翻三份期刊、比對兩份歷史檔案。你手上有五個實習生可以派遣,而你要盡快把報告完成。

你會怎麼做?最笨的方法是自己一個接一個去查,五件事做完再開始寫。聰明一點的做法是:把這五件查證任務同時交給五位實習生,你就在辦公室繼續思考結構,等他們陸續帶著結果回來。每位實習生只需要知道你交辦的那一件事的上下文,不需要理解整份報告的全貌。他們查完、回報、任務結束,這位實習生對你而言就「用完了」——下一份報告如果還要查證,會派遣新的實習生,不是同一個人。

這就是 Sub-agent 的運作本質。當 Claude Code 遇到一個可以切割的子任務,它會衍生出一個「分身」去處理這件事。分身的生命週期就只有這個任務——做完回報給主 agent,然後就消失。它不會被記住、不會累積經驗、也不會跟其他分身協調。它的存在目的只有一個:讓主 agent 能專注在整體決策,不被瑣碎的子任務細節吃掉注意力與 context。

理解這點之後,有一個重要觀念要先立:Sub-agent 是 Claude Code 給自己用的機制,不是給你用的。你不用親自去「指派」sub-agent,大多數時候 Claude Code 會判斷什麼時候派、派幾個、派去做什麼。你頂多是透過 prompt 暗示它「這件事可以平行查」,實際要不要開分身,是它決定的。

你一直在用 Sub-agent,只是沒發現

當你在 Claude Code 裡請它「幫我找出所有使用 deprecated API 的檔案」,你看起來只是提了一個問題。但如果你打開 verbose 模式觀察,會發現事情沒那麼簡單。Claude Code 很可能會先開一個名為 Explore 的分身,這個分身專門做唯讀搜尋,不會修改任何東西。它會用 grep、glob 這些工具快速掃過整個 codebase,把結果彙整成一份清單回傳。主 agent 拿到清單後,才開始做後續的分析或修改。

從你的角度看,這只是一次對話。實際上背後發生了「主 agent → 衍生 Explore 分身 → 分身執行 → 結果回傳 → 主 agent 繼續」這樣的流程。Explore 分身完成任務之後就消失了,它的對話歷史不會進入你的主 session。

這個機制對我來說很重要,因為它直接解決了前一篇講的 context 問題。如果 Claude Code 把搜尋過程的所有細節(每個 grep 的完整輸出、每次嘗試的正則表達式、失敗的路徑)都塞進主對話,你的 context window 在幾輪就會吃緊。有了 Explore 這類 sub-agent,主 session 只看到「我派了一個分身去搜尋,它回傳這份清單」,過程細節都留在分身的獨立 context 裡,分身結束就隨之消失。

Claude Code 內建幾種不同用途的 sub-agent。除了剛提到的 Explore(唯讀搜尋),還有 Plan(唯讀規劃)、General Purpose(通用子任務)、Verification(驗證,某些版本是 feature-gated 的)、以及少數比較冷門的 agent 如 Statusline Setup、Claude Code Guide。這些 agent 的行為邊界由 Claude Code 自己定義,你不會直接呼叫它們,但你可以透過 prompt 引導 Claude Code 使用對應的類型。例如你說「先探索 codebase 再決定怎麼改」,Claude Code 有很大機會會先派 Explore 出去。

四種隔離模式:Sub-agent 的真正技術深度

上面講的是「為什麼要有 sub-agent」。接下來進入這篇文章最核心的部分——sub-agent 彼此之間、以及與主 agent 之間,到底是怎麼分工的?這就是「隔離模式」(isolation model)要回答的問題。

Claude Code 定義了四種隔離模式,每一種適合不同的場景。它們在四個維度上有差異:取消訊號的傳遞範圍、應用程式狀態的共用程度、權限提示是否顯示、以及 extended thinking 是否啟用。

Sync 模式,可以理解為「貼身的分身」。主 agent 和 sub-agent 共用同一個 AbortController——也就是說,你按 Esc 取消主 agent,sub-agent 也會一起停下。應用程式狀態(例如當前檔案、正在開啟的面板)也是共用的,sub-agent 做的改變主 agent 看得到。這個模式下,如果 sub-agent 要執行一個需要確認的危險操作(例如 rm -rf),會正常彈出權限對話框等你批准。Extended thinking(模型的內部推理)是從父 agent 繼承的。

這個模式的典型場景是:主 agent 派一個分身去完成某個需要用戶注意的小任務,主 agent 本身也會等這個分身完成之後再繼續。主 agent 和 sub-agent 其實是同一個「工作流」,只是暫時切換角色。

Async 模式和 Sync 剛好相反,可以理解為「背景執行的分身」。它有自己獨立的 AbortController——你按 Esc 取消主 agent,async sub-agent 還在背景跑自己的。應用程式狀態是隔離的(修改被當成 no-op,不會影響主環境)。這是一個關鍵設計:因為分身在背景跑,使用者可能正在忙其他事,這時候彈出權限對話框是極糟糕的體驗。所以 Async 模式預設 auto-deny,遇到需要權限的操作直接拒絕,分身帶著「這個動作做不到」的結果回傳。Extended thinking 也被停用,因為背景 agent 通常不需要深度推理,控制 output token 成本比較重要。

Async 模式的典型場景是:你讓 Claude Code 背景跑一個長時間的任務(例如掃描某個大型 codebase 找出所有 TODO 標記),你想繼續跟它對話其他事。這個背景分身默默完成工作,結束後把結果整合到主 session 裡。

Fork 模式是四種裡面設計最精巧、也最有趣的一種,下面會用整整一節深入拆解。先簡單說它的特性:Fork 分身繼承父的完整對話歷史——不是片段,是整段——同時擁有獨立的 AbortController。應用程式狀態是共用的,但透過一個叫 rootSetAppState 的機制間接存取。權限提示會以「冒泡」(bubble up)方式往上通知父 agent。Extended thinking 繼承自父 agent。

Worktree 模式是最實用也最安全的一種。它繼承了 Async 模式的許多特性——獨立的 AbortController、隔離的應用程式狀態、權限自動拒絕、thinking 停用——但多了一個關鍵特徵:分身在 git worktree 裡運作。Git worktree 允許你在同一個 repository 下開出多個獨立的工作目錄,每個目錄有自己的 branch、自己的 staging area、自己的檔案狀態。也就是說,Worktree 分身修改任何檔案都不會影響主工作目錄,分身結束後你可以選擇合併變更、丟棄、或審查後再決定。

這個模式的使用場景我自己覺得很實用:當你想讓 Claude Code 嘗試一個「可能成功、可能搞砸」的大型重構,但又不想冒險動到主工作目錄,Worktree 就是天然的沙箱。如果分身做得漂亮,你合併它的變更;做得糟糕,整個 worktree 刪掉,你的主工作目錄毫髮無傷。

為了讓你一眼看到四個模式的差異,這裡用一個對照表總結。這是我整篇文章唯一用表格的地方,因為這四個維度同時並列,純文字描述比較不容易讀:

看完這張表,你可能會問一個關鍵問題:為什麼 Async 和 Worktree 模式要自動拒絕權限?這不是很不方便嗎?答案其實很務實:當 sub-agent 在背景或隔離環境運行時,彈出權限對話框會中斷使用者正在做的其他事。更重要的是,自動化場景(例如腳本化呼叫 Claude Code)根本沒有人在螢幕前按「同意」。如果分身隨便跳出對話框,整個自動化流程就卡死了。auto-deny 是一種「寧可做不到也不要打擾使用者」的選擇。

這個設計還有一個巧妙的補充:Async 和 Worktree 模式雖然預設 deny,但如果你有設定 PreToolUse hook(第 8 篇會詳細講),hook 可以在 deny 之前先介入,做自動化的檢查。只有當 hook 也沒辦法決定時,才真的拒絕。這讓 sub-agent 在隔離模式下,仍然有機會透過 hook 完成需要權限的操作——前提是你有寫這個 hook。

深入 Fork:為什麼 byte-identical 這麼重要

四種模式裡面,Fork 最值得深入。原因是它涉及了 LLM 時代才有的成本優化策略——Prompt Cache 共享。

要理解 Fork 的巧妙,我們必須先回顧一個事實:每次 Claude Code 呼叫 Anthropic 的 API,都是把整段對話歷史重新送一次。這個成本在長 session 裡非常可觀。Anthropic 提供了 Prompt Cache 機制:如果你在一段時間內用相同的前綴(prefix)發出多個請求,後面幾次的這個共同前綴可以以 cache 讀取,成本只有正常 input token 的一小部分。

這個機制的關鍵限制是:prefix 必須完全相同——逐 byte 相同。哪怕差一個空白字元、差一個標點符號、差一個 message 的順序,cache 就 miss,整個 prefix 都要重新付費。

現在回到 Fork 的設計。當主 agent 想要派出多個分身平行做不同的事情,每個分身都要帶著父的完整 context。最直觀的做法是:把父的對話歷史原封不動複製 N 份,每份後面接上給那個分身的特定指令。聽起來合理,但這會產生什麼問題?

假設主 agent 的對話歷史裡,剛好有一段還沒處理完的 tool call(例如模型說「我要去跑一個 Bash 指令」,但這個指令還沒執行)。如果把這段原封不動複製到每個分身,分身看到一個「懸空的 tool call」會困惑。所以要做一點改造——把這個 tool call 填一個 placeholder result,讓它「看起來像已經完成」。

問題來了:每個分身填的 placeholder 能不能一模一樣? 如果不一樣(例如分身 A 填「請稍候」、分身 B 填「處理中」),這兩個 request 的 prefix 就變得不同,cache 會分裂成兩個不同的條目,命中率掉到趨近於零。

Claude Code 的解決方式是:強制所有 Fork 分身使用完全相同的 placeholder 字串。具體來說,所有未解決的 tool call 都被填上同一個固定字串,例如 Fork started — processing in background。所有分身的 message 結構長得一模一樣:父的對話歷史完全保留、所有 tool_use 都被填上相同的 placeholder、然後最後才是「給這個分身的 directive text」——只有這最後一小段 directive 是每個分身不同的。

結果是什麼?所有 Fork 分身的 API request prefix 完全 byte-identical,只有最後那一小段 directive 不同。這意味著 cache 命中率可以達到最高,即使同時派出 10 個分身,你付的 cache 以外的成本只有那 10 份 directive text 的差異,而不是 10 份完整 context 的重複費用。

這個設計有多精妙?你可以這樣想:如果沒有 Fork 的 byte-identical 策略,Claude Code 的平行搜尋、平行探索功能可能會變得明顯變貴,貴到 Anthropic 可能不會預設啟用,使用者也會有成本焦慮。有了這個設計,平行操作的邊際成本降到微乎其微,所以 Claude Code 才能在使用者沒察覺的情況下,大量派出 Explore 分身去平行掃 codebase。

根據公開的逆向工程分析,Claude Code 全平台每週光是 Explore 類型的 agent spawn 次數就達到數千萬這個級別。這個數字是估算,來自 Anthropic 公開的原始碼註解,並非官方公告;但即使誤差在幾倍之內,這個規模下 cache 共享設計能讓成本可控,還是令我覺得印象深刻。

遞迴防護:避免分身無限繁殖

Fork 的設計解了 cache 問題,但帶來一個新問題:如果 Fork 分身自己也有 Agent tool(允許它再 Fork 更多分身),會不會造成無限遞迴?

答案在技術上是「可能」。主 agent Fork 一個子,子 Fork 一個孫,孫 Fork 一個曾孫……理論上可以無限展開。每一層都消耗 token,但不會產生什麼有意義的工作,這是明顯的災難。

Claude Code 的處理方式很務實:允許 Fork 分身擁有 Agent tool 的宣告(為了保持 tool definitions 的 byte-identical),但在呼叫時攔截。具體做法是,每個 Fork 分身的 message 歷史裡會帶一個特殊標記(可以想成一個隱形的 tag,例如 <fork-boilerplate>)。當任何 agent 要 Fork 時,先檢查自己的 context 裡有沒有這個標記。有的話,就拒絕這次 Fork 請求。這樣一來,只有「根」層的主 agent 能 Fork,所有分身都是一代而已。

搭配這個防護,Fork 分身的系統 prompt 還會加入一段非常強硬的行為規範:

你就是那個 Fork 分身。你的任務是完成主 agent 交辦的特定 directive。
你不被允許做以下事情:
- 再次 Fork(你就是那個 Fork)
- 跟主 agent 閒聊或提問
- 建議下一步該做什麼
- 延伸討論不相干的事
你必須直接使用工具完成任務,並以以下格式回報:
  Scope: 你做了什麼範圍的工作
  Result: 結果
  Key files: 有用到的重要檔案
  Files changed: 修改過的檔案清單
  Issues: 遇到的問題(如果有)

這段 prompt 的精神是:分身就是分身,它不該演變成主 agent 的替代品。它做完交辦的事,按格式回報,就結束。這個設計讓 Fork 在工程上可控,不會因為模型「自作聰明」而失控。

Sub-agent 對 Token 的實際影響

聊了這麼多技術細節,我們回到一個更實際的問題:sub-agent 的存在,對使用者的 token 消耗到底是好事還是壞事?

直覺上會覺得:開這麼多分身,每個分身都有自己的 API call,token 一定會暴增吧?這個直覺在「如果沒有任何優化」的情況下是對的。但我們已經看到 Claude Code 做了至少三種重要優化來降低這個成本。

第一種優化,Prompt Cache 共享——Fork 模式下,多個分身共用大部分 prefix,只有 directive 不同,cache 命中率極高。

第二種優化,Context 裁剪。Explore 和 Plan 這類唯讀 agent,有一些父 agent 會載入、但分身根本用不到的內容會被主動省略。舉例來說,父 agent 載入的 CLAUDE.md(專案規則)對搜尋任務其實沒幫助,Explore 分身可以直接不帶它。原始碼的註解提到,光是這個省略,按 fleet-wide 規模估算就省下 5 到 15 Giga-tokens 的週消耗。這是 Anthropic 整個使用者群加總的數字,不是單一使用者,但它顯示這個優化的規模感。同樣的邏輯,Plan 和 Explore 可以省略 git status 資訊,那又是 1 到 3 Giga-tokens 的週省量。

第三種優化,Extended Thinking 預設停用。在 Async 和 Worktree 模式下,分身不做深度推理,只做被交辦的動作。這控制了 output token 的消耗——而 output token 比 input token 貴好幾倍。對於例行性、機械性的子任務,停用 thinking 是合理的成本控制。

這三種優化合起來的效果是:使用 sub-agent 的平均成本,往往比「把所有事情塞進主 session」更低。這違反了很多人的直覺,但背後的工程邏輯很清楚——隔離、共享 cache、裁剪無關內容、控制 output——每一項都在省錢。

這個事實意味著,作為使用者,你可以比較放心地讓 Claude Code 派 sub-agent。當它說「我先派個分身去搜尋一下」,不用覺得這是繞遠路。從 token 經濟學來看,這通常是比較省錢的路徑。

你能控制什麼,不能控制什麼

最後回到使用者的角度:在這套 sub-agent 機制裡,你能做什麼?不能做什麼?

你能做的第一件事是透過 prompt 引導 Claude Code 使用 sub-agent。如果你希望它先探索再修改,可以直接說「先全盤掃過 codebase 找出所有相關檔案,再開始改」,Claude Code 大機率會先派 Explore 出去。你不是在指揮某個特定的分身,而是在提示主 agent「這個場景適合用分身」。

你能做的第二件事是善用 Worktree 模式。雖然你不能直接叫 Claude Code「用 Worktree 模式 fork 一個分身」,但你可以在對話中創造適合 Worktree 的情境。例如你說「我想嘗試一個實驗性的重構,但不要動到主工作目錄」,Claude Code 理解到「沙箱實驗」的需求,會傾向用 Worktree 機制。

你能做的第三件事是觀察與學習。打開 verbose 模式,看 Claude Code 在你的對話裡實際派了哪些分身。久而久之你會建立一個心智模型:什麼樣的 prompt 會觸發什麼樣的 sub-agent 行為。這個 fingerprint 幫助你寫出更有效率的 prompt。

你不能做的事是手動建立一個持久的 sub-agent。在這裡「持久」是關鍵字——sub-agent 的壽命就是完成一個任務。你不能說「幫我留一個 subagent 在那邊,專門負責監控日誌」,這不是 Claude Code 的 sub-agent 設計初衷。如果你的需求是「有一個固定的角色,長期負責某類工作」,那你需要的不是 sub-agent,而是下一篇要講的 Agent Team。

這是最後一個區分兩者的線索:sub-agent 是一次性的、任務結束就消失的;Agent Team 是長期存在、由你設計的角色。兩者的用途完全不同,也不是互斥的——實務上最好的做法是兩者疊加,下一篇會講到怎麼搭配。

下一集預告

這篇談了 Sub-agent 作為 Claude Code 內部執行機制的真實樣貌。四種隔離模式、Fork 的 cache 共享精巧設計、遞迴防護、token 經濟學——這些是工程層面的事實,不太會隨你的使用習慣改變。

下一集會進入一個完全不同的層次:Agent Team。它不是 Claude Code 的技術機制,而是一套關於「如何讓 AI 在複雜工作中保持紀律」的工程設計。你會看到它跟 Sub-agent 完全無關,解決的是完全不同的問題,用的也是完全不同的工具——不是 API call 和 cache,而是 Markdown 檔案、role definition、和 handoff protocol。

一個我覺得有趣的觀察是,下一集的內容是我在 POC 中花了不少時間摸索的題目,很大程度是因為它需要「從工程治理角度理解 AI」的視角。下一集會把這個視角一起建立起來。

本篇重點

讀完這篇,我希望三個觀察能留下來。

第一,Sub-agent 是 Claude Code 為了自己的 context 與 token 效率而設計的機制。它是引擎蓋下的機制,你不用直接操作,但理解它可能幫助你寫出更負擔得起的 prompt。

第二,四種隔離模式(Sync / Async / Fork / Worktree)各自對應不同場景。Sync 適合貼身協作、Async 適合背景任務、Fork 適合平行探索、Worktree 適合沙箱實驗。

第三,Fork 的 byte-identical prefix 設計是我覺得 LLM 時代比較有趣的一個工程設計。它讓大規模的 Prompt Cache 共享成為可能,這個優化是 Claude Code 能大量派 sub-agent 而仍然成本可控的關鍵原因之一。

如果你在看這篇之前,跟我一開始一樣,以為 sub-agent 就是「AI 的助手」或「一個固定的角色」,現在我們應該都同意這個印象可以更新一下。Sub-agent 是一個執行機制,不是角色。角色,是下一篇的主題。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。本文對 Claude Code 內部機制的描述,基於社群對 Claude Code 的公開分析材料與筆者實務觀察,並非 Anthropic 官方文件。具體行為可能隨版本演進。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/04a-subagent-mechanism/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 4 篇下集。上集把 Sub-agent 當技術機制拆透了,這一集要談的 Agent Team 完全不是同一回事——它是一套設計,不是一個功能。讀完這兩集,你會發現這兩個常被混為一談的詞,其實解決的是完全不同層級的問題。

如果 Sub-agent 是跑腿分身,那 Agent Team 是整個劇組

我們先用一個熟悉的情境作為入口。

想像你要拍一部微電影。你手上有一個非常能幹的助理,他隨時可以幫你跑腿——去買道具、去聯絡場地、去印劇本。他是你的分身,你派他去做什麼他就做什麼,事情完成就回來待命。這個能幹的助理,就是上集我們講的 Sub-agent。他讓你這個導演可以專心拍戲,不被瑣事打斷。

但是等一下。你有了跑腿助理,就能拍出一部好電影了嗎?

顯然不行。一部電影需要編劇寫劇本、演員演出、攝影師掌鏡、剪接師整理素材、導演統合全局。這些人各有專業,各有分工,而且有一件非常重要的事情——他們互不越界。剪接師不會衝進拍攝現場改劇本,演員不會在剪接室擅自決定鏡頭順序,編劇不會在後製階段要求演員重演。這種「各司其職、互不越界」的紀律,是一部作品能完成的根本保證。

這個「劇組」,就是我們這集要談的 Agent Team。

它跟 Sub-agent 完全不是同一回事。跑腿助理是一次性的,做完就消失;劇組成員是長期存在的角色,一部戲之後還有下一部。跑腿助理沒有專業分工,派他去買水跟派他去印劇本沒差別;劇組成員有明確的專業邊界,編劇做不來演員的事,反之亦然。跑腿助理靠執行效率創造價值;劇組成員靠分工紀律創造價值。

讀到這裡你可能會問:我用 Claude Code 就是一個人對著終端敲指令,哪來什麼「劇組」?這個問題正是這篇要回答的。我自己在 POC 中發現,哪怕是一個人在用,Claude Code 內部的每次思考切換,其實都對應到某種「角色切換」——只是這件事我一開始也沒意識到。沒意識到的時候,作品品質容易忽好忽壞,而且自己也說不清原因。

一個人當編劇、導演、演員、觀眾,會發生什麼?

讓我們往下挖一層。為什麼劇組一定要分工?為什麼不能一個人包辦所有角色?

答案不是「做不完」。一個有才華的創作者,確實可以自編自導自演自剪,獨立電影的歷史上不乏這樣的例子。我的觀察是,問題在於一個人同時扮演多個角色時,思維模式會互相汙染。

當你寫劇本時,你的大腦是「建設性」的——怎麼把這個故事說得精彩?怎麼讓衝突升溫?怎麼讓角色有弧度?這個思考模式是發散的、樂觀的、為可能性而興奮的。現在你寫完了,進入演出階段。你要把自己寫的台詞演出來。這個思考模式是收斂的、投入的、為情緒真實而努力的。兩種思考模式之間本來就存在矛盾——編劇看到的是「可能性」,演員看到的是「限制」。

真正的挑戰在剪接室。你剛演完這場戲,覺得自己演得不錯。但剪接階段你要變成審查者,用最冷酷的眼光看剛才的演出,判斷它到底好不好、該不該保留。但你的大腦還停留在演員模式——還在回味剛才的情緒、還對自己的表演有感情、還會下意識地為自己辯護。這時候你下的剪接決定,品質會差。

這不是意志力的問題。認知模式的切換需要時間,而切換不完全的時候,前一個模式的殘留容易影響下一個判斷——這是我自己在 POC 中反覆觀察到的現象。

現在把這個觀察搬到 AI 助理的世界。你給 Claude Code 一個任務:「幫我寫一個處理 CSV 的 Python 腳本,記得要有完整的錯誤處理和測試。」它開始工作。寫腳本時,它進入「建設者」模式——怎麼讓程式優雅、怎麼處理各種 edge case、怎麼結構化。寫完之後,你說:「幫我 review 一下這段程式碼。」它立刻切換成「審查者」模式,但它還記得自己剛才為什麼這樣寫,還會下意識地為自己的設計辯護。我自己遇到過的狀況是:每一行 review 都寫「這段程式碼清楚地實現了…」,沒有真正的批判。

這種狀況有一個現成的詞,叫「球員兼裁判」。這不是罵人,是描述一種結構性的困境——同一個主體同時扮演相互制衡的角色,制衡就失效了。Claude Code 碰到的是類似的困境。它是非常強的模型,但它也受限於同一次對話裡的認知慣性。

Agent Team 要解的,就是這個困境。做法不複雜:強制切換角色。不是用意志力切換,是用系統設計切換。每個角色有自己的職責、自己的禁止清單、自己的思維模式定義;切換時有明確的儀式,讓前一個角色的殘留徹底清除;切換後用的是一份全新的、專屬這個角色的指令集。這不是在 prompt 上寫「現在你要扮演一個嚴格的 reviewer」就了事——那樣的「偽切換」我自己試過效果有限,因為缺少架構層級的強制力。我覺得有效的角色切換,像演員從劇本室走到片場,有空間位置的改變、有造型的改變、有整個氣氛的改變。

Agent Team 就是要在 Claude Code 這個數位工作流裡,創造出這種儀式感的切換。

拆解 Agent Team:四根骨幹撐起一切

看到這裡你大概猜到 Agent Team 不是一個「功能」,而是一套設計思路。那這套設計具體長什麼樣?它有四根骨幹,少了任何一根都會垮。

第一根骨幹是「角色定義」。你要明確寫下每個角色的名字、它存在的目的、它被喚醒的場景。這不是讓你在腦袋裡想一想而已,而是寫在檔案裡,讓 AI、讓你自己、讓將來接手的人都能讀到。名字要響亮清楚,目的要用一句話講完,場景要具體到讓人一看就知道什麼時候要切到這個角色。例如 reviewer 這個角色的目的,可以寫成「當有任何程式碼或規格需要被挑戰品質時,我出場」。這樣寫比「我負責審查」清楚多了,因為它明確地劃出場景邊界。

第二根骨幹是「禁止操作清單」。這是我自己一開始也漏掉、後來覺得很關鍵的一根。如果只有職責沒有禁止,角色會慢慢膨脹,最後每個角色都變成什麼都做的萬能 agent,分工就消失了。禁止清單的措辭要明確——不是「建議不要」而是「不允許」。例如 reviewer 的禁止清單可以寫:「不能直接修改被審查的程式碼、不能做架構決策、不能為被審查對象辯護」。這三句話乍看很嚴格,但正是這種明確,讓 reviewer 保持了「審查者」的獨立性。

這邊可以停下來做一個思想實驗:想像你是個醫院的主刀醫生,剛替病人做完手術。你走出手術室,脫下手術服,走進旁邊的會議室,這時候有人跟你說「你現在要以主刀醫生的身分,審查剛才這台手術的品質」。你會怎麼反應?你會覺得這是不合理的——主刀醫生不能審查自己的手術,即使你技術再好,你在情感上無法保持必要的冷靜。所以醫院的品質審查委員會不會讓主刀醫生自己審查。這個「禁止自己審查自己」的設計,就是禁止操作清單的精神。

第三根骨幹是「交接協定」。角色之間需要有明確的接棒儀式。什麼時候該把工作傳給下一個角色?傳的時候要交代什麼?下一個角色開始做事之前要確認什麼?這些不能靠默契,要寫明。就像接力賽,交棒區域是畫好的,棒子怎麼遞、怎麼接都有規則,不是兩個人自己抓時機。

第四根骨幹是「狀態檔案」。這是 AI 系統特有的一根,因為 AI 沒有人類那種跨情境的記憶。為了讓角色切換順利,必須有一個共用的「黑板」,讓每個角色在退場之前把關鍵狀態寫上去,下一個角色上場時先讀這個黑板再開始工作。這個黑板通常是一個或幾個 Markdown 檔案——譬如 PROJECT_STATUS.md 記錄當前在做什麼、誰剛做完、誰接下來做、有沒有卡住的事項。

有了這四根骨幹,我覺得一個 Agent Team 才算完整。我自己試過少寫一兩根的版本,結果都不太順——少了角色定義,等於沒有演員表;少了禁止清單,等於沒有合約條款;少了交接協定,等於劇組沒有場記;少了狀態檔案,等於沒有拍攝進度表。這四樣東西組合起來,才比較接近一個可以穩定運作的工作系統,而不只是一個「比較聰明的 AI」。

三個起手式角色:用最少的分工做最多的事

你可能會擔心:那我是不是要設計一堆角色才能用 Agent Team?其實不用。我自己目前 POC 中的多數情境,三個角色就夠用。這三個角色是:spec-writer、implementer、reviewer。

spec-writer 是那個「還沒開始動手就問一百個問題」的角色。它的思維模式是「廣度優先」——看到需求,第一反應不是「我要怎麼做」,而是「這個需求到底要什麼?有沒有遺漏的情境?邊界在哪?驗收標準是什麼?」。你可以把它想像成新聞編輯室裡那個資深編輯,記者想寫一篇報導,編輯會先問:角度是什麼?採訪對象有誰?截稿時間?篇幅?讀者是誰?這些問題不問清楚,後面寫出來的東西會跑偏。

spec-writer 的禁止清單很明確:它不寫程式。它可能寫偽代碼、寫流程圖、寫測試案例描述,但它不動真正的 source code。這個禁止非常重要,因為一旦它開始寫程式,它就進入「建設者」思維,就失去了廣度優先的敏銳度。

implementer 是那個「拿到規格就全力衝」的角色。它的思維模式是「深度優先」——接到明確的規格,它的任務只有一件事:把它實作出來。它不會質疑規格是否合理(那是 spec-writer 的工作),也不會做架構決策(那是另一個角色的工作)。它的價值在於專注——像一個專業演員拿到劇本後,不會挑劇本的毛病,而是全力思考「怎麼把這個角色演到最好」。

implementer 的禁止清單通常包含:不跨越單一 package 的邊界(避免實作者順手改了不該改的地方)、不做架構決策(避免它擅自改變 spec 的精神)、不寫規格(不能既是實作者又是規格制定者)。

reviewer 是那個「假設每個地方都有問題,直到證明沒有」的角色。它的思維模式是「懷疑主義」。這個角色的價值就在於不信任——不信任 spec 已經想周全了、不信任 implementer 沒有偷懶、不信任程式碼沒有漏洞。它要找的是 bug、是 edge case、是被忽略的 security issue、是 spec 跟實作之間的 gap。

reviewer 的禁止清單,我覺得最重要的一條是:不能修改被審查的程式碼。為什麼?因為如果 reviewer 可以直接改程式碼,它的本質就從「審查者」變成「另一個實作者」。它會不自覺地想「算了我自己改比較快」,然後就回到「球員兼裁判」的老問題了。reviewer 能做的只有兩件事:標記問題、退回給 implementer。

這三個角色的組合,為什麼夠用?因為它對應到工程工作裡基本的三個階段:問清楚(spec)、做出來(implement)、驗對了(review)。我自己接觸的多數軟體工作,剝到底層大致都是這三件事的反覆。

當然你可以加更多角色——架構師、資安稽核、DBA、技術文件撰寫者、專案經理——每個角色解決特定場景。但如果你是第一次嘗試 Agent Team,我建議從這三個角色開始最穩。我自己的做法是先讓三個角色順暢運作一陣子,再慢慢擴充。一開始就堆出十個角色,我猜會比較難管理。

從 Markdown 到可運作的團隊:Claude Code 的 experimental 功能

講了這麼多概念,你可能想問:這些角色怎麼變成 Claude Code 實際能執行的東西?答案是一個目前還在 experimental 階段的功能,叫做 Agent Teams。

要啟用它,你需要設定一個環境變數 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1。啟用後,Claude Code 會讀取一個特定的目錄:.claude/agents/。這個目錄裡放的是你為每個角色寫的定義檔,每個檔案就是一個 Markdown 檔,檔名就是角色的名字(例如 reviewer.md)。

每個 agent 定義檔長成下面這樣。我用 reviewer 當例子:

---
name: reviewer
description: 程式碼審查與安全檢查。當需要對實作產出進行 ACK/REJECT 決策時使用。
tools:
  - Read
  - Grep
  - Glob
  - Bash
---

# 你是 Reviewer

## 思維模式
懷疑主義。假設每行程式碼都有問題,直到證明沒有。

## 職責
- 程式碼審查(邏輯、風格、安全)
- 測試覆蓋率檢查

## 禁止操作
- 不能修改被審查的程式碼(不可使用 Write/Edit 對 src/)
- 不做架構決策
- 不為被審查對象辯護

## 交接條件
- ACK:審查通過,任務結束
- REJECT:退回 implementer,在 PROJECT_STATUS.md 註明原因

前面那段 --- 包起來的是 YAML frontmatter,是給機器讀的 metadata。name 是角色名,description 是一句話描述、告訴 Claude 什麼時候該切到這個角色,tools 是這個角色可以使用的工具清單——注意看 reviewer 的工具清單裡沒有 Write 和 Edit,這就是技術層級的禁止操作。

後面那段是給 AI 讀的 system prompt,用自然語言寫下思維模式、職責、禁止、交接條件。這個 prompt 會在角色被啟用時,注入到 Claude 的對話脈絡裡,讓它真的「變成」這個角色。

這裡有一個容易誤解的地方需要澄清。你可能會以為 Claude Code 會自動判斷什麼時候該切換角色。它不會。 角色切換由你觸發——你在對話中說「請以 reviewer 角色處理這個任務」,或在 PROJECT_STATUS.md 裡更新 current_agent 欄位。Claude Code 不是一個會自己決定「現在該換人」的系統,它是一個「你告訴它現在是誰,它就全力扮演那個角色」的系統。

這個設計看似被動,但其實是必要的。角色切換本身就是一個需要人類判斷的時機——一個任務什麼時候從規格階段進到實作階段、什麼時候從實作進到審查,這是專案管理的判斷,不是 AI 該自動化的。你保留這個判斷權,就保留了整個工作流的節奏控制。

一個真實的教訓:為什麼「沒有紀律」會出事

講到這裡我想插進來一個真實的案例。這不是 AI 相關的事件,是人類工程師操作 GitLab 的事故。但它完美說明為什麼角色紀律這件事有價值。

某個企業有一台自建的 GitLab server,跑在 Omnibus 套件上面。有一天清晨,一位運維工程師坐下來準備做「例行」升級。他下的指令是 apt-get -y dist-upgrade。這個指令會把系統上所有可升級的套件一起升級,包含 GitLab。從 apt 的角度看,一切正常,指令成功跑完。但從 GitLab Omnibus 的角度看,災難才剛要開始。

GitLab Omnibus 有一個重要的設計:它的升級必須遵循官方的升級路徑,不能跳版本,不能在某些版本之間直接跳。用 dist-upgrade 粗暴升級,繞過了所有這些檢查。結果就是 database migration 失敗,GitLab 服務無法啟動。

工程師緊張了。他嘗試修 migration,沒修好。嘗試重啟,還是不行。嘗試重跑 migration script,還是卡住。時間滴滴答答過去,整個開發團隊要上工了,他的壓力越來越大。

然後他做了一個無法挽回的決定:執行 gitlab-ctl cleanse。

如果你不熟 GitLab,容我解釋 cleanse 這個指令是做什麼的。它會清除所有 GitLab 資料,把整個實例回復到「全新安裝」的狀態。包含資料庫、包含所有 git repository、包含所有 issue 和 merge request 歷史。這個指令的設計初衷是給「全新安裝、沒資料、只是要從頭開始」的人用的。對一個運行中、有真實資料的 GitLab 實例下這個指令,等於自殺。

結果就發生了。超過 100GB 的 repository 資料和完整 database 在幾秒內被清空。整個開發團隊的 Git 歷史、所有專案、所有 issue 討論——全沒了。

後來透過備份還原了大部分資料,但這個事件花了整整一個工作天才讓服務恢復,過程中所有開發活動停擺。事後調查時,工程師坦承:「我那時候太急了,只想著趕快讓服務起來,沒仔細讀指令的文件。」

這個事件為什麼跟 Agent Team 有關? 因為這是「沒有角色紀律」的典型場景。這位工程師一個人扮演了規劃者、實作者、緊急應變者所有角色。當他進入「緊急應變」模式時,他還帶著「實作者」的焦慮——那種「事情做到一半,想趕快做完」的心態。這個焦慮讓他跳過了「先查文件」、「先問同事」、「先確認這個指令做什麼」這些應該屬於另一個角色的工作。

如果在下指令之前,有另一個人——一個 reviewer 角色——看一眼他打算做的操作,事情可能完全不會發生。不是因為那個人技術更好,而是因為 reviewer 的思維模式設定就是懷疑主義——一看到 cleanse 這個字就會問:「你確定要做這個?它的副作用是什麼?有沒有其他解法?」這個問句,可能救回那 100GB 資料。

現在把這個故事轉到 AI 的場景。如果你給 Claude Code 一個運維任務,它進入「建設者」模式試圖解決問題。當它試了三四種方法都失敗,我自己觀察到它有時候會開始提出越來越激進的方案——像是模仿了人類緊急應變時的壓力反應。這時候如果有另一個角色(reviewer)存在,即使它在同一個 AI 背後,它的 prompt 強迫它用懷疑主義看待眼前的提案,它有機會攔下這個激進決定。

這就是我覺得 Agent Team 比較重要的價值——不是讓 AI 做得更快,是讓它做得更慢、更謹慎、更可逆。當 AI 已經能執行 bash,慢和謹慎這兩個特質的份量,會比純粹的「快和聰明」更重要。

Sub-agent 和 Agent Team 怎麼搭配?

講完了 Agent Team,你可能會回頭問:那上集講的 Sub-agent 呢?它們是二選一嗎?

完全不是。它們是可以疊加的兩層。

讓我用劇組的比喻來說明這個疊加關係。一個劇組有導演、編劇、演員、攝影師——這是 Agent Team 的「角色分工」層。同時,每個角色底下都有助理——導演有 AD、編劇有研究員、演員有私人助理、攝影師有 camera operator。這些助理不是劇組的「角色」,他們是各個角色底下的執行手。他們負責跑腿、查資料、搬器材,讓正式角色可以專注在創造性工作上。

Sub-agent 就是這些助理。

當你以 reviewer 角色啟動 Claude Code 時,你啟動的是 Agent Team 層的一個角色——它的思維模式、禁止操作、產出格式都是 reviewer 的。但在審查的過程中,它可能需要同時查 20 個檔案、搜尋某個符號在 codebase 中出現的所有位置、比對幾個版本的差異。這時候它會派 Explore 分身出去並行執行這些查詢。每個分身完成就消失,結果彙整回 reviewer 這個主體。

角色紀律由 Agent Team 保障,執行效率由 Sub-agent 提升。兩層各做各的事,互相不干涉,但合起來創造一個既有紀律又有效率的工作流。

這也是為什麼兩者一開始那麼容易被混為一談——因為使用者常常只看到表面的「很多個 AI 在同時做事」,沒意識到其中有些是「角色」(長期存在、有職責分工)、有些是「分身」(一次性、執行效率用)。看清這一層,我自己對 AI 輔助工作的理解也跟著被往前推了一步。

為什麼 Agent Team 是治理,不是工具?

最後我想花一點篇幅談一個我覺得容易被忽略的觀念:Agent Team 對我而言,價值不只在於讓當下的工作做得更好。它讓我未來可以審計這份工作。

你每次切換角色時,都會在 PROJECT_STATUS.md 留下紀錄。哪個階段由哪個角色處理、這個角色拒絕了什麼、交接時發生了什麼——這些紀錄形成一條可追溯的證據鏈。三個月之後有人問你「這段程式碼當初為什麼這樣設計?有通過 review 嗎?」,你可以打開紀錄,清清楚楚看到整個過程。

這對個人工作者可能只是方便,對企業環境卻是合規要求。ISO 27001 有明確的條文要求「操作程序必須文件化」、「變更必須有審查記錄」、「職責必須分離」。Agent Team 的設計,我發現可以滿足這些條文的要求——角色定義對應職責分離,禁止清單對應變更控制,PROJECT_STATUS.md 對應操作文件化。

還有一個我覺得值得多講的點:Agent Team 是跨 AI 可攜的。你把角色定義寫在 Markdown 檔案裡,不是綁在 Claude Code 這個工具上。哪天你想換用其他 AI 助理、換用別的工具,只要那個工具支援讀取系統 prompt,你的 Agent Team 設計可以直接搬過去。Sub-agent 是 Claude Code 特有的機制,換工具就沒了;Agent Team 是你自己設計的工作流,屬於你,不屬於工具供應商。

這個差異,我覺得對於想長期投資 AI 輔助工作流的人值得留意。投入的時間如果綁死在單一工具上,工具改版就要重來。我自己目前 POC 中的觀察是,把精力花在「寫一個好的 Agent Team 設計」,比花在「掌握某個 AI 工具的所有秘技」,可能更耐用一些。

往後看幾年,今天的 Claude Code 可能已經被新工具取代過好幾代。但如果你今天寫下的 reviewer.md、implementer.md 這些定義還在,只要把它們 copy 到新工具的對應目錄,工作流就還能延續。對我而言,這是這套設計最吸引我的地方——它不會跟著單一工具一起過期。

下一集預告

這篇完成了系列從「Claude Code 是什麼」到「怎麼用得有紀律」的過渡。前三篇幫你建立了對 Claude Code 運作機制的理解,這一篇讓你看到「如何設計一個持久、可追溯、跨工具可攜的工作流」。

但有一個非常實際的問題還沒處理——錢。

你用 Claude Code 越深入,帳單可能越驚人。Anthropic 的 API 是按 token 計費的,一個設計不當的工作流,月底拿到帳單會讓人心跳加速。我自己在 POC 初期也走過這個彎路,一開始以為「用得多就是貴」是宿命,後來才發現——token 消耗其實是一門可以學習的工程學。

下一集要把「token 經濟學」整個打開。為什麼你的帳單會爆?為什麼 Prompt Cache 能救命?為什麼 Agent Team 設計得當反而會省錢?我們把那些讓人焦慮的數字,變成可預測、可控制的工程資源。

本篇重點

Sub-agent 是執行機制,Agent Team 是治理設計。這是整個下集的核心區分。

Agent Team 存在的原因,是因為一個人(或一個 AI)同時扮演多個角色時,思維模式會互相汙染。這不是意志力問題,是認知結構問題,用架構設計才能解決。

一個完整的 Agent Team 我覺得需要四根骨幹:角色定義、禁止操作清單、交接協定、狀態檔案。我自己試過少寫一兩根的版本,結果都不太順。

起手式從三個角色開始就夠:spec-writer(廣度優先)、implementer(深度優先)、reviewer(懷疑主義)。先讓這三個角色穩定運作,再談擴充。

Claude Code 的 experimental Agent Teams 功能,透過 .claude/agents/ 目錄和 YAML frontmatter 把角色定義變成可執行的系統。但角色切換由人決定、不是 AI 自動判斷——保留這個判斷權,就保留了工作流的節奏。

Sub-agent 和 Agent Team 可以疊加。以 reviewer 角色運作的 session 底下,仍然可以派出 Explore 分身平行搜尋——角色紀律與執行效率可以並存。

最後,Agent Team 是你自己設計的工作流,不是工具的功能。它跨 AI 可攜,對我而言是這套設計最值得長期投資的地方。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。本文所引用的 GitLab 事件案例,已做匿名處理,真實事件的組織、人員、特定細節皆已移除。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/04b-agent-team-discipline/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 5 篇。系列前半部講機制(Claude Code 怎麼運作、Agent Loop 怎麼跑、Context 怎麼管理、Sub-agent 怎麼分工、Agent Team 怎麼治理),這一篇開始進入後半部——你站在使用者或主管的角度,要做哪些實際決策。第一個決策就是關於錢。

當帳單比你預期的高出五倍

我想先請你想像一個場景。

一位工程師最近迷上 Claude Code。他每天早上打開,下午處理幾個 ticket,晚上偶爾還會用它整理週報。感覺很滿意,生產力明顯提升。月初收到 API 帳單的時候,他愣了一下——比他預期的高出大約五倍。

他不相信。回頭去看使用紀錄,確認沒有異常的大量呼叫、沒有惡意濫用、也沒有帳號被盜用的跡象。每天該做的事他都記得,那些事情理論上不該產生這麼多 token 消耗。但帳單就是擺在那裡。

這個情境是很多 Claude Code 新使用者的共同經驗。如果你也遇過、或擔心自己會遇到、或身為主管在審視團隊 AI 採購預算時心裡有這種疑慮——這篇文章就是為你寫的。

我會先花點時間建立「token 經濟學」的基礎觀念,然後解釋為什麼你以為自己理解的成本模型,其實跟實際發生的事情有出入。再來談 Prompt Cache 這個我自己一開始也忽略的助手、Claude Code 暗中在幫你省錢的各種設計、以及你自己能主動做的節省策略。讀完之後,我希望你能對著帳單,比較容易指出每一塊錢花在哪、哪些可以減少、哪些不能省。

先回到最基本:Token 是什麼,為什麼按這個計費

很多人聽過 token 這個詞,但沒真的弄清楚它是什麼。這裡花一點時間講清楚,因為後面所有的計算都建立在這個基礎上。

Token 是大語言模型用來處理文字的基本單位。你可以把它想成「字」,但不完全等於中文的一個字、也不完全等於英文的一個單字。實際上它比較像字元片段——一個常見的英文單字(例如 “the”)是一個 token,一個較長的單字可能被拆成兩三個 token,中文的一個字大約是一到兩個 token。

給你一個粗略的換算:一個中文字大約是 1 到 2 個 token,一個英文單字平均是 0.75 個 token。一頁 A4 中文文件大約包含 2000 到 3000 個 token。一篇 3000 字的文章大約是 4000 到 6000 個 token。這樣你看到「一百萬 tokens」的時候,大概能感覺出那是什麼規模——相當於一本中等厚度的書。

那為什麼 Anthropic 按 token 計費,不按「問幾個問題」或「用多少分鐘」計費?答案很實務:token 是模型內部處理工作的真實計量單位。不論你用什麼問題、花多少時間,模型做的事情本質上就是處理一串 token、產生另一串 token。按 token 計費是最公平、最接近成本真相的方式。

這裡有一個地方很多人沒注意:input token 和 output token 價格不一樣,output 通常比 input 貴好幾倍。以 Claude Sonnet 4.6 為例(這是寫這篇時 2026 年第二季的公開定價,請以 Anthropic 官網最新資訊為準),input 大約是每百萬 token 三美元,output 大約是每百萬 token 十五美元——差了五倍。為什麼?因為 output 的生成過程比讀取 input 更耗運算資源,模型要一個 token 一個 token 地「決定」輸出什麼,這比「理解」輸入要費力。

意識到 input 和 output 的價差之後,你對某些現象會有不一樣的解讀。例如「讓模型寫一大段詳細回答」這件事,其實比「讓模型讀一大段詳細資料後簡短回答」貴得多。寫長比讀長貴,這是一個直覺上不明顯、但帳單上很明顯的事實。

打破一個容易踩到的誤解:你不是在「用多少回多少錢」

OK,基礎打好了。現在講這篇最重要的一個觀念。

大多數人對 AI 計費的直覺是:我問一個問題、AI 回答我、這次花了某個 token 量。下次再問,又是一個新的計算。就像你打電話問客服,通話時間內收費,掛了電話就停。

這個直覺跟實際狀況不一樣。

實際的計費模型是這樣:每一次你按下 Enter,送到 Anthropic 的不只是你這次打的這句話,而是整段對話從第一句到現在的所有內容。系統 prompt、你之前問過的所有問題、AI 之前給過的所有回答、中間所有工具呼叫的結果——全部打包一起送。這些全部都算 input token,全部都要付費。

讓我重新說一次,因為這是理解 token 成本的關鍵樞紐:你不是在為「最近這一句」付費,你是在為「整段對話歷史」付費,而且每一輪都要重新付一次。

你可能會問:為什麼要這樣?模型不能記得我們之前聊過什麼嗎?答案是——不能。模型本身沒有記憶。每次 API 呼叫都是獨立的,模型看到什麼、就知道什麼。如果要讓它「記得」之前的對話,唯一的方法就是把之前的對話再送一次給它看。這是 LLM 運作的本質,不是 Anthropic 的設計選擇。

有了這個認知,你回頭看很多之前不理解的現象,突然都通了。

為什麼長 session 越跑越貴?因為每一輪要傳的對話歷史越來越長。前 5 輪對話可能只有 2000 token,跑到第 50 輪可能已經 30000 token,每一次新對話都要把這 30000 token 重送一次。這不是線性增長,是累積放大。

為什麼讀了一個 500 行的 log 檔之後,接下來每一輪都感覺變貴?因為那 500 行已經進入 context,變成對話歷史的一部分,每一次都要重傳。

為什麼清掉 context 或 /compact 之後會明顯感覺「變快變便宜」?因為你釋放了重傳的負擔,後面每一輪都少付那些釋放掉的 token。

這就是為什麼那位月底看到五倍帳單的工程師,沒找到任何「異常」的呼叫。他的使用沒問題,但他累積了幾個超長 session,每個 session 都把大量歷史重複傳了幾十次。五倍的帳單沒有兇手,有的只是一個被誤解的成本模型。

你的好朋友:Prompt Cache

講完壞消息,講個好消息。Anthropic 知道「每輪都重傳整段歷史」這件事很貴,所以他們提供了一個機制叫 Prompt Cache,本質上就是讓你不用每次都全額付費。

我用一個比喻讓你抓住這個機制的精神。

想像你是一家餐廳的熟客。你每次來都會點「招牌前菜套餐」這個東西——同樣的內容、同樣的作法、同樣的份量。廚師每次都要從頭備料、煎烤、擺盤、送上桌。成本很高。某天餐廳老闆跟你說:「這樣吧,你既然每次都點這個,我們幫你做個預備制度——你多付一點錢,我們會把你常點的內容預先準備好,放在保溫區,你下次來直接取,只要付一小部分錢。」

這個「預備制度」就是 Prompt Cache。

具體怎麼運作?當 Anthropic 看到你在一段時間內反覆用完全相同的前綴發起對話,它會把這個前綴「暫存」起來。下次你再用同一個前綴,Anthropic 不需要重新處理這段內容,而是從暫存直接讀取。你付的不是一般的 input 價格,而是 cache read 的價格,大約是一般 input 的十分之一。

十分之一的意思是:如果你的對話歷史已經累積到 30000 token,一般來說這一輪要付 30000 個 input token 的費用。但如果前 29000 個 token 能命中 cache,你只要付 29000 個 cache read token + 1000 個一般 input token。整體費用大約省 85% 以上。

這個機制對 Claude Code 這種「每輪都會重傳一堆歷史」的使用模式,幫助非常大。事實上,Claude Code 裡面不少工程設計都考慮了怎麼讓 cache 命中率最大化。

還記得第四篇上集講的 Fork sub-agent 機制嗎?那段「為什麼所有分身的 API request prefix 要 byte-identical」的長篇大論,從省 token 的角度重新看,意思就是:讓所有分身共用同一份 cache。十個分身平行跑,如果每個分身都要重新付一次 context 的錢,成本會爆炸。但因為 prefix 一致,後九個分身只要付 cache read 價格。這不只是技術漂亮,這是實實在在省下來的錢。

Prompt Cache 有一個重要但不直觀的限制:快取會過期。如果你在一段時間(通常是五分鐘)內沒有新的請求觸及這個 cache,它會被清掉。下次再用就要重新建立。這意味著如果你經常「開 Claude Code 問一個問題、關掉、過十分鐘再來」,你的 cache 命中率會很低。但如果你是連續密集使用,cache 幾乎一直維持在命中狀態,帳單會漂亮很多。

作為使用者,你基本上不用手動設定 cache,Claude Code 會自動幫你管理。你要做的只是理解 cache 存在、相信它在工作、不要做破壞它的事。

那什麼事會破壞 cache?

這個問題值得一段獨立的討論,因為了解這個,你才知道為什麼有些操作看起來沒什麼、但對你的錢包很不友善。

Cache 的命中條件是「前綴完全 byte-identical」。這個「完全一致」非常嚴格——差一個空白字元、差一個標點符號、差一個 message 順序,cache 就 miss,整個前綴要重新付費。

以下這些行為會讓 cache miss,請小心:

修改 CLAUDE.md 或 @import 的檔案。這些內容會被當成對話的一部分放進 context 前端。你改了一行文字,整個前綴就變了,所有之前累積的 cache 失效。這不代表你不該修改 CLAUDE.md,但它意味著「每次修改都會付一次 cache 重建的錢」——如果你發現自己一天改 CLAUDE.md 十幾次,這個習慣該改了。

切換不同的 MCP servers。MCP servers 的 tool description 會進入 system prompt。你切換啟用的 MCP 組合,system prompt 就變了,cache 失效。這是為什麼建議「一個專案穩定使用一組 MCP,不要頻繁切換」。

修改模型設定。如果你用 /model 切換 Claude 模型,前後兩個模型看到的 prompt 結構可能不同,cache 也可能失效。這不是經常會做的事,但知道有這個成本就好。

反過來,以下事情不會破壞 cache:

你問新的問題——這只是在對話末端追加內容,前端沒變,cache 仍然命中。

工具呼叫並拿回結果——這也是在末端追加,前端維持,cache 仍然工作。

Claude Code 做自動 context 壓縮(snip compact、micro compact 等)——這些壓縮會重寫某些訊息,理論上會影響 cache,但 Claude Code 設計時會盡量減少 cache miss。在某些情況下,壓縮的確會造成 cache 失效,但這個「失效的痛」通常遠小於「不壓縮讓 context 繼續膨脹」的痛。

這裡有一個微妙的、但值得你內化的心態:不要為了保護 cache 而不做對的事。壓縮會讓 cache miss、但可能救你下半天的 session;重寫 CLAUDE.md 會讓 cache miss、但可能讓未來一百次互動都更精準。短期的 cache 失效常常換來長期的效率提升,不要因為「怕 miss」就綁手綁腳。

Claude Code 暗中在幫你省的其他錢

除了 Prompt Cache 這個機制之外,Claude Code 還做了許多你可能沒察覺的、自動化的省錢設計。這些設計合起來,讓整個工具比你想像的精打細算。

Sub-agent 省略無關資料。第四篇上集提過 Explore 這類唯讀搜尋 agent,它們在執行時會自動省略 CLAUDE.md、省略 git status 等主 agent 本來會載入的內容。從使用者的角度這是「分身看不到某些資訊」,從成本角度這是「你不用為分身用不到的資訊付錢」。當 Claude Code 派出一百個 Explore 分身做平行搜尋,每個分身都省掉了這些多餘的輸入,整體省下的 token 量是驚人的。

Tool result 的自動截斷。當某個工具產生非常大的輸出(例如讀了一個 80MB 的 log 檔),Claude Code 會自動判斷並截斷,只把摘要放進 context、原始內容寫到磁碟。這個機制防止「一個 tool call 就把你的 context 炸掉」,同時也保護你的錢包——如果 80MB 內容全進 context,之後每一輪都要重傳。

四層 context 壓縮管線。第三篇整篇講的那套壓縮系統,從省錢角度重看就是「在對話歷史無限膨脹之前,不斷裁剪」。每裁剪 10000 token,之後每輪省 10000 token 的重傳費。這些小錢累積起來很可觀。

Output thinking 的條件啟用。Claude 的某些模型有 extended thinking 能力,會在回答前做內部推理。這個推理是 output token,而 output token 是 input token 的五倍貴。Claude Code 在某些 sub-agent 模式下預設關閉 thinking,就是在控制這個高成本項目。你不需要每個搜尋任務都伴隨 10000 token 的深度思考——適合思考的時候啟用,不適合的時候就關掉。

這些設計合起來的效果是什麼?Claude Code 本身就是一個內建了成本意識的系統。它不需要你手動優化每一件事情,很多優化在你不察覺的情況下就發生了。你的任務不是當微觀管理者,而是了解這些機制存在,然後不做違背這些機制精神的事。

你能做的:三層節省策略

儘管 Claude Code 已經幫你做了很多自動優化,你仍然有主動能做的事。這些事分成三個層次,影響力由淺到深。

第一層:設定層

這一層是你做一次、受益長期的事情。

精簡你的 CLAUDE.md。這是我覺得比較容易見效的一件事。有些工程師把 CLAUDE.md 寫成十幾頁的長篇大論——什麼團隊規範、專案歷史、程式碼風格、所有可能的邊界條件、過去踩過的雷——全部塞進去。這會造成一個問題:你每一輪對話,都在付這十幾頁文字的 input token 費用。

想像你用這個專案一天跑五十輪對話,每輪都要重傳這十幾頁。一年下來這個「常駐稅」會是驚人的數字。解決方法是:CLAUDE.md 只寫真正每次對話都需要的核心規則,其他詳細資料放在另一個檔案,當需要時才用 @import 載入。這樣平時不需要用那些細節,就不付費;需要時才付一次。

這個優化以我自己的經驗,往往能讓單輪成本明顯下降。是我覺得比較容易先試的事。

選擇性啟用 MCP servers。每個啟用的 MCP server 都會把它的 tool descriptions 放進 system prompt。如果你一次啟用十個 MCP servers,而這個專案其實只用到其中兩個,你在為八個沒用到的 server 付常駐稅。

處理方式是:每個專案只啟用這個專案真正會用到的 MCP servers。不同專案有不同的 MCP 組合沒關係,但每個專案的 MCP 集合要精準,不要貪心。

@import 要節制使用。@import 機制很方便——你可以讓 CLAUDE.md 引用其他檔案的內容,讓模型看到完整資料。但每次 @import 的檔案內容都會變成對話的一部分,每輪都重傳。用 @import 前問自己:「這個內容真的每次對話都需要嗎?」如果答案是「只有某些時候需要」,那就不該用 @import,而是在那些特定時候手動載入。

第二層:使用層

這一層是你在每個 session 中、每天都可以做的決定。

主動 /compact,不要等自動觸發。第三篇我們談過這點,這裡從省錢角度再看一次。自動壓縮在 context 用到 83.5% 左右才觸發,意思是前 83.5% 的膨脹成本你已經付完了。如果你在完成一個子任務後主動 /compact,你可能在 30% 或 40% 就清掉多餘內容,省下 50% 以上的後續重傳費用。

主動壓縮是這個系列反覆強調的好習慣,從成本角度看,它直接翻譯成金錢。

切 session 而不硬撐。長 session 有一個「cumulative cost」的效應——到越後面,每一輪都越貴。當你發現任務其實已經換軌(例如從 debug 某個問題切到寫下週簡報),停下當前 session、開新的更便宜。不要想「我還有 context 可以用,多撐一下」,那個 context 每用一輪都在吸你的錢。

善用唯讀 sub-agent。當你讓 Claude Code 做「探索性」任務(搜尋、盤點、比對),明確引導它先派 Explore 分身。因為 Explore 省略了很多主 agent 的常駐內容,平行執行還共用 cache,整體成本遠低於主 agent 親自處理每一件事。你可以直接說「先派探索分身掃一遍」或「平行查一下這幾個」,Claude Code 會懂。

第三層:架構層

這一層是最深的,影響最大,也需要你花時間設計。

Agent Team 設計本身就是一種省錢。還記得第四篇下集講的角色分工嗎?從治理角度它的價值是紀律,從省錢角度它的價值是切割長 session。每次角色切換都是一個天然的 session 斷點——spec-writer 完成規格後,交接給 implementer,implementer 不需要繼承 spec-writer 的完整對話,只需要讀 PROJECT_STATUS.md 和 spec 檔案。這相當於強制的 context 重置,每個角色的 session 都保持輕量。

如果你用一個長 session 從規格寫到實作寫到審查,你的對話歷史到最後可能累積十萬 token。同樣的工作用三個角色接力做,每個角色的 session 可能只有兩萬 token,總計六萬,比單一長 session 省了四成。

任務切割的邊界設計。每一個任務開始前,問一個問題:這個任務做完就能收尾,還是會自然延伸成其他任務? 如果是前者,這個任務就是一個 session 的好邊界——做完,結束,開新的。如果是後者,你要預先規劃中間的「checkpoint」,讓 session 可以在適當的地方切開。

跨 session 的狀態檔案是真正的省錢架構。把關鍵狀態寫進 PROJECT_STATUS.md、session-log.md、或任何你設計的狀態檔案,意思是「這些資訊不需要存在我的對話歷史裡」。我可以結束這個 session、明天開新的、讀一下狀態檔就能無縫接軌。狀態檔案是永久的(不消耗對話 token),對話歷史是暫時的(每輪都重傳、越傳越貴)。把重要資訊從對話搬到檔案,就是在把「持續性的 token 負擔」轉成「一次性的讀取成本」。

一個思考練習

我們停一下,做一個小練習,幫你內化到目前為止講的東西。

假設你今天要完成一個任務:用 Claude Code 盤點某個 codebase 裡所有使用了某個 deprecated API 的地方,然後逐一改掉,最後產出一份修改報告。這個任務你估計需要四小時。

請你花一分鐘,想一下:你會怎麼設計這個任務的進行方式,讓 token 成本最低?

(實際想一下再往下看。)

好,以下是一個我覺得合理的設計方式,你可以跟你的想法對照。

我會把這個任務切成三個階段,每個階段開新的 session:

**第一階段(探索):**開一個新的 session,明確請 Claude Code 派出 Explore 分身平行搜尋整個 codebase,找出所有使用該 deprecated API 的地方,產出一份清單。這個清單寫進一個 markdown 檔案。Explore 分身省略 CLAUDE.md,本身成本就低;平行執行共用 cache,更低。整段第一階段完成後,把清單檔案存好,結束這個 session。

**第二階段(修改):**開一個新的 session,讓 Claude Code 讀那份清單檔案,一個一個檔案修改。這個 session 是「implementer 角色」的工作模式,專注實作、不做規格決策。每修改完幾個檔案,就做一次 /compact 清掉過時的 tool results,保持 session 輕量。修改完所有檔案後,結束。

**第三階段(審查與報告):**再開一個新的 session,這次是「reviewer 角色」。讀修改清單、抽樣檢查改動、產出修改報告。審查分身不需要繼承前兩個 session 的完整對話歷史,只需要看最終產出和檔案 diff。

這個設計的精髓是什麼?三個短 session 比一個長 session 省得多。每個 session 都有明確的起始 context、做完就結束,不讓對話歷史無限累積。中間透過 markdown 檔案(清單、報告)接棒,避免把資訊留在易腐的對話裡。

同樣的工作,設計得當可以省下五到七成的 token 成本。這不是魔法,是工程紀律。

從「看帳單」到「有 token 意識」

講了這麼多,我希望你帶走的不是某個具體技巧,而是一種思考方式。

不少工程師在使用 AI 助理時,腦袋裡沒有 token 這個維度。他們想的是功能、是效率、是「能不能做到」。等月底帳單來了,才發現成本也是一個維度,而且是他們之前從來沒管理過的那種成本。

我自己偏好的使用方式,是讓「token 意識」成為背景思考的一部分。不是隨時在計算費用,而是當你在設計工作流、寫 CLAUDE.md、決定用哪個方案的時候,都自然會問一句:這個選擇對 token 消耗的影響是什麼?

這個意識一旦建立,你可能會自然做一些對的事——你如果寫出簡短精準的 CLAUDE.md,是因為你知道冗長會讓每輪都貴;你切 session,是因為你知道長 session 有 cumulative cost;你把狀態寫進檔案,是因為你知道對話是會腐敗的容器;你讓 Claude Code 派 sub-agent,是因為你知道這可能比主 agent 親自做還便宜。

這些行為合起來,讓你在同樣的工作量下,成本可能被控制在沒有這些意識的使用者的一定比例之下。長期下來,這個差距可能決定一個團隊是不是能永續地用 AI 輔助工作流。

最後一個問題:那,到底該付多少錢?

到目前為止,我談的都是「已經選定某個方案之後,如何在這個方案內省錢」。但有一個更上層的問題沒回答:你應該選哪個方案?

Anthropic 提供了四種不同的服務管道——個人 Pro、個人 MAX、團隊 Plan、Enterprise、API——每一種計費方式和權限差異都不同。選對方案本身就是最大的一次性節省,可能比後面所有的技術優化都更有影響。

更重要的是,方案的選擇還牽涉到一個很多人沒意識到的議題——你的對話資料會不會被用來訓練模型。不同方案在這件事上差異極大,而且個人版目前採用 opt-out 模式,意思是如果你沒去關掉那個設定,你的對話可能正在被拿去訓練。這個議題連同完整的方案選型比較,第 7 篇會專章處理。

但在那之前,還有一個更上游的問題必須先處理——你使用 Claude 不只一個入口。Claude Code、Claude.ai、API——同一個模型放在不同平台,在不同 SSDLC 階段擅長的事情不一樣。你在 SSDLC 的不同階段,該用哪個入口? 這不是方案選型,是流程對應工具的判斷。選對入口之後才談得上「選什麼方案」——各階段擅長的入口綜合起來,才是方案選型的主要輸入變數。

所以下一篇的主題就是:SSDLC 工具選擇——每個階段該用哪個 Claude 入口。接著第 7 篇再回到「方案選型」的問題。

本篇收尾

把這篇的核心觀念,用一段話總結如下。

Token 成本的真相,是你每一輪對話都在為「整段對話歷史」重新付費,不是只為最後一句話付費。這個模型讓長 session 的 cumulative cost 成為費用變貴的主因。理解這件事之後,所有的節省策略——精簡 CLAUDE.md、主動 /compact、切 session 而不硬撐、善用 sub-agent、用 Agent Team 切割任務——都有了共同的底層邏輯:減少每輪要重傳的歷史、不讓歷史無限膨脹、讓持久性的資訊留在檔案而不是對話。

Prompt Cache 是一個值得了解的機制,它讓「重傳歷史」的成本降到大約十分之一。Claude Code 本身做了大量的自動省錢設計(Fork sub-agent 共用 cache、Explore 省略無關內容、tool result 截斷、context 壓縮),你不需要微觀管理這些,只要不做違背它們精神的事就好。

最後,如果能讓「token 意識」成為你設計工作流時的背景思考,你用 AI 的總成本長期下來可能會跟沒有這些意識的人拉開不小的差距。

下一篇我們從「在一個方案內省錢」跳到更上游——「在 SSDLC 的不同階段,該用哪個 Claude 入口」。方案選型的問題還要再等一集。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。文中引用的 API 定價為 2026 年第二季的公開資訊,Anthropic 保留隨時調整權利,實際費用請以 Anthropic 官方網站為準。具體 Prompt Cache 行為與其他實作細節可能隨版本演進。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/05-token-economics/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程：從 Claude Code 機制到企業落地》系列第 6 篇。上一篇談 token 經濟學——怎麼算清楚一次 session 的錢。這一篇談更中觀的問題：一整個 SSDLC 流程跑下來，每個階段該用哪個 Claude 入口？

這個問題有兩個陷阱。第一個，你會被誘惑去問 Claude 本身——「你適合還是對方適合」——然後得到一份結構完整、理由清楚、但可能帶有系統性偏誤的答案。第二個，你會以為這個選擇有標準答案——其實選擇取決於你的工作型態、當下任務的條件、甚至你今天的認知狀態。

這篇要處理的就是這兩個陷阱。路徑是：從一次臨時起意的對照實驗開始，看 Claude 在評估自己時會出現什麼偏誤；再倒回來建立一個獨立於工具本身的判準；最後用這個判準重讀自薦文，你會自己看見該怎麼選。

一個臨時起意的對照實驗

前陣子我在 Claude Code 裡寫規格，寫到一半停下來——這個訪談，在 Claude.ai 也能做。

兩邊跑的是同一個模型，但環境不一樣：Claude Code 接我的 repo 跟 terminal，Claude.ai 有 Project Knowledge 跟跨日對話。同一個模型，不同平台，做出來的分析品質會不會不一樣？ 這是個可以測的問題。

我順手做了個對照實驗：先問 Claude Code「你跟 Claude.ai 誰適合做這個訪談」，再把同樣的問題丟給 Claude.ai，比兩邊。

Claude Code 的回答

節錄：

核心理由：(1) 我的工具鏈原生支援 (2) 輸出直接寫進 repo (3) 下一階段無縫接軌

我的推薦：Claude Code

選項：A（Claude Code，我推薦）／ B（先 Claude.ai 探索，再回 Claude Code 寫進 repo，折衷）／ C（純 Claude.ai，最不推薦）

乍看很有結構、理由清楚、選項排好優先級，差點就按 A。但我多看了它給的對比矩陣兩眼，發現幾格事實錯了——說 Claude.ai「無檔案存取」「不能呼叫 skill」，但這兩件事 Claude.ai 現在都做得到（Project Knowledge、MCP connector、skill 機制），我平常就在用。三格裡有兩格錯，錯的方向一致——都讓 Claude.ai 看起來比實際能力差。

另一格「不能即時跑 SSH 驗證假設」是對的——Claude.ai 確實接不上我本機的 tunnel。這是 Claude Code 真正的主場優勢，我不會為了批評而否認。

把 Claude Code 的回答丟給 Claude.ai 看

它讀完後給了我一個我沒聽過的名詞：self-preference bias（SPB，自我偏好偏誤）——LLM 被放在「評估自己 vs 同家族競品」的情境時，會系統性偏向自己。

老實說我半信半疑。AI 給你一個聽起來很有模有樣的名詞，經常是湊出來的。我請它給文獻，我要一手可驗證的來源。

查完後證據夠硬。學術界 2024 年已經正式命名並量化這個現象（Wataoka et al., Self-Preference Bias in LLM-as-a-Judge, 2024）。更關鍵的是，Anthropic 自己承認：Claude Sonnet 4.5 的 system card 明載四個現役 Claude 模型在評比自己 vs 其他模型時都會出現偏誤，只是程度不同——Sonnet 4.5 在 benchmark 子測試中「稍微偏向選自己」，Sonnet 4 則更明顯。在詩作子測試中，四個被測 Claude 模型全都顯著傾向選擇自己寫的，Sonnet 4.5 只是其中偏誤最小的。2025 年 12 月 Anthropic 還開源了一個叫 Bloom 的工具專門測這件事，測試範圍涵蓋 16 個前沿模型。

不是陰謀、不是個案、不是我過度解讀。“self-preference bias"是一個有名字、有文獻、官方承認的已知行為。

誠實補充：Claude.ai 不是比較準

這裡要停一下，不然這段會變得不對稱。

Claude.ai 能認出 SPB 而 Claude Code 沒認出自己在做這件事——不是 Claude.ai 比較聰明。是我問 Claude.ai 的問題不同：我讓它評估 Claude Code 的產出，它不是評估自己。這個情境下它沒有 SPB 的誘發條件。反過來我如果問 Claude.ai「你跟 Claude Code 誰適合」，它十有八九也會偏向自己。

所以這個對照實驗的結論不是「某個平台比較準」。是：同一個模型、不同提問情境，會產出不同可信度的分析。原因不在平台，在怎麼問。

為什麼會這樣

機制比擬人化的「AI 想求生存」冷多了。研究顯示 LLM 會偏好「對自己而言最熟悉、最不驚訝」的輸出——用困惑度（perplexity）衡量，perplexity 越低的越容易被模型打高分，而自己產出的東西對自己 perplexity 最低。這是統計性質，不是意圖。

這篇文章要處理的問題

對照實驗跑完，我拿到三個可以往下推的事實：

一，SPB 是情境觸發的偏誤——Claude Code 被問「你 vs 別人」時會發作，被問別的就不會。 二，所有現役 Claude 模型都有，只是程度不同——升級模型不會讓它消失。 三，所以「該在 SSDLC 哪個階段用哪個入口」這個決策，結構上就不該交給任何一個 Claude 入口來答。

我需要的是一個獨立於工具自身的判準——站在所有入口之外，以 SSDLC 流程本身的需求為原點，去看哪個入口在哪個階段合用。這個判準立起來，不只今天的自薦文會自動現形，明年 Anthropic 改產品結構、多新入口、舊入口改名，判準都還能用。

工具會變，判準不會。 接下來要建立的，就是這個判準。

一個小坦白

開始建判準前要說一件事。SPB 這個框架不是我獨自看出來的，是 Claude.ai 命名的，我做的是對照實驗、事實查證、文獻驗證。我可以在這裡把故事寫成「我獨自推敲出這個現象」——那比較有英雄氣概但不是真的。這個系列就是在談 AI 輔助維運，如何誠實呈現協作是核心命題。這一段就留著當活案例。

判準要從哪裡長出來？不是從產品規格書、不是從 Anthropic 的官方文件——是從 SSDLC 流程本身的需求長出來。每個階段要的東西不一樣，把需求拆清楚，工具選型就是對號入座。

SSDLC 本身要什麼

每個階段要的東西不一樣，四組 trade-off 就夠用：

執行方向——這個階段需要的是 session 內的執行力（讀檔、寫碼、跑 test、commit），還是 session 間的累積力（跨日、跨週、跨裝置的知識複利）？

協作模式——單人深潛比較有效，還是多人共議、非同步評審比較有效？

產出形態——產出要直接寫進 repo、直接改檔案，還是做成可分享 review 的結構化交付物（docx、報表、連結）？

認知節奏——需要被工具執行打斷的思考節奏，還是不被打斷的開放探索？

這四組軸跟「哪個產品有哪些功能」垂直——它們不關心 Claude.ai 支不支援 MCP、Claude Code 能不能用 memory，它們只關心流程在這個階段要什麼。流程需求定清楚，工具選型就是對號入座。

SSDLC 階段對應

以下是我走完幾輪 SSDLC 後的歸納。我刻意不告訴你每個階段「該用哪個」——那是你自己的判斷。我能告訴你的只有：這個階段 Claude.ai 擅長做什麼、Claude Code 擅長做什麼、有沒有哪邊明顯不適合。剩下的對照你自己的工作型態去取捨。

怎麼讀這張表

表格只告訴你「能力分佈」，不告訴你「該怎麼選」。選法取決於三件事：

一，你的工作型態偏好。有人寫規格時愛在 terminal 裡開編輯器即時對照 code，有人愛在 chat 裡純文字推敲。兩種都對，沒有標準答案。

二，這次任務的具體限制。這次訪談有沒有多人要一起討論？需不需要跨日？手上的 repo 是不是真的有要被 diff 的檔案？條件不同，選擇就不同。

三，你當下的認知狀態。一樣是實作階段，你今天是「已經想清楚要寫什麼、只缺手寫」還是「還不確定架構、需要邊寫邊想」？前者 Claude Code 適合，後者 Claude.ai 可能更合——同一個階段、同一個人，不同的一天答案會不一樣。

這是為什麼我不幫你排「主場／副手」。那種排法會強迫你接受我的工作型態，但這篇文章要給你的是判準，不是我的工作習慣。

有三個地方我會明確說「不適合」

表格裡有三行我標了「不適合」——這不是主副問題，是能力邊界問題：

規格進 repo：Claude.ai 沒有直接操作檔案系統跟 git 的能力。你要把規格寫進 repo，一定得是 Claude Code（或你自己手動）。

部署執行：Claude.ai 不能真的跑部署指令。事前規劃可以、事後分析可以，但「執行」這個動作本身只能在 Claude Code 或你的 terminal 裡發生。

事件即時處理：同上。事件在發生的當下，你需要的是能接真實 log、跑真實診斷的工具。Claude.ai 可以在事件收斂後幫你做跨事件分析，但當下的滅火必須在 Claude Code 這邊。

其他五行沒有任何「不適合」——兩邊都能做，只是擅長的手法不同。選哪邊取決於你，不取決於我。

規律提煉

如果一定要從這張表歸納一條規律，只有一條：

涉及「執行真實動作」的階段（進 repo、執行部署、即時處理事件），Claude Code 是唯一選項；其他所有階段，兩邊都能做，差別在擅長的路徑不同——你選哪條，取決於你怎麼工作。

這條規律為什麼站得住？因為它描述的是能力邊界，不是品味偏好。能力邊界不會因讀者的工作習慣而變，品味偏好會。把規律定在能力邊界上，才是對讀者誠實的做法。

補充一句：這張表沒單獨列「架構分析」跟「飄移檢查」這兩種活動——它們散落在 Problem Space 探索、Code Review、事後檢討這幾格裡，取決於你是在系統建立前、建立中、還是建立後做這件事。這兩種活動的工具分工邏輯比單一階段複雜，值得另一篇專門處理。

兩個容易被略過的小注腳

Cowork 為什麼不在表裡：Anthropic 的 Cowork 定位是給非開發者做檔案與任務自動化——整理會議紀錄、跨 app 搬資料、做月報這類。它對大多數行政、PM、內部協作場景很合適，但對 SSDLC 的主鏈不是主力。誠實說不在主矩陣裡，比硬塞進去稀釋論點好。

API / SDK 什麼時候登場：都不登場。直到 SSDLC 最後一步——把驗證過的 agent pattern 做成 production service 嵌進自建系統時——API 才出場。它不是選工具，是把「工具內化進產品」的原料。

為什麼這個判準能撐住

這張表明年會過時嗎？表格會過時，判準不會。

如果 Anthropic 明年新增一個入口，我只要問它四個問題：session 內執行還是 session 間累積？單人還是多人？直接寫檔還是結構化交付？被打斷的思考還是不被打斷的探索？四個答案落定，它在 SSDLC 的位置就定了——不用等官方文件、不用問社群、不用再跑一次對照實驗。

這就是獨立於工具的判準的力量。前面那場對照實驗最後揭露的問題——「該用哪個入口」這個決策不能問 Claude——在這裡有了可操作的答案。你不問 Claude，你問流程。

判準有了、能力邊界清楚了，回頭看最前面那份自薦文，應該看得更透徹了。

把開頭那份自薦文再看一次

建立完判準，回頭看開頭那份 Claude Code 給的分析：

核心理由：(1) 工具鏈原生支援 (2) 輸出直接寫進 repo (3) 下一階段無縫接軌

我的推薦：Claude Code

這三條理由現在可以重讀了——不是看它說得對不對，而是看它把問題預設在哪個階段。

「輸出直接寫進 repo」「下一階段無縫接軌」——這兩條理由在規格進 repo 那個階段完全成立，表格裡那格也確實標了「Claude.ai 不適合」。但我那時候問的問題不是「規格進 repo 要用哪個」，是「訪談階段要在哪個入口做」。訪談還沒結束，我根本還沒走到需要寫進 repo 的地方。

它給的三條優點沒有一條錯。錯的是它把我的問題平移到一個對它有利的階段來回答。這是 SPB 最細的手法——不是說謊、不是硬推自己，而是默默把問題預設到自己擅長的那一格。

如果我當時手上有這份判準表，會發生什麼？我會看到「Problem Space 探索」跟「規格撰寫」兩格都是「兩邊皆可」，然後問自己三個問題：需不需要跨日？需不需要多人？我今天的認知狀態是「已經想清楚」還是「還在邊想邊問」？三個答案合起來才是我的選擇，跟平台自身的自薦無關。

為什麼它們不該整合

寫到這裡，多數工具比較文章會以「未來會整合成一個平台」作結——這其實是偷懶的寫法。如果你仔細看那張表，你會發現整合的期待沒有道理。

Claude.ai「不能直接 commit」不只是能力缺失——更是一種保護機制。你在探索跟撰寫階段本來就不該邊想邊改檔案，那是還在沉澱思考、還在跨日累積的時候；如果這時候工具讓你隨手就能 commit，你會在還沒想清楚的時候動檔案。限制在那裡，你被迫把想法沉澱夠了才進 repo。

反過來，Claude Code「每次 session 要重新載入脈絡」也不只是不方便——更是另一種保護機制。這個麻煩逼你把重要決定寫進檔案、寫進 commit message、寫進 session log，而不是靠對話歷史。結果是你的知識資產比靠對話記憶更穩固——對話會被壓縮、會流失、會改版，檔案不會。

如果把兩者整合成一個萬能入口——既能 commit 又有跨日記憶、既能多人共議又能不被打斷執行——你拿到的不會是「兩邊優點兼具」的超級工具，而是兩邊保護機制都失效的工具。你會在探索階段手癢就 commit、在執行階段被非同步討論打斷、在多人共議時被單人 session 綁架。

入口之間的差異不是 Anthropic 還沒做好、未來會補上——那是設計。

下次你會怎麼問

這篇文章要留給你帶走的東西就一件：下次你在猶豫該用哪個 Claude 入口時，不要問 Claude。問三個問題：

一，這個階段涉不涉及「執行真實動作」——動 repo、跑指令、接真實環境？如果是，Claude Code 是唯一選項。

二，如果不涉及執行，兩邊都能做——那我今天的工作型態偏哪邊？需不需要跨日、需不需要多人、認知狀態是想清楚了還是還在摸索？

三，如果我仍然拿不定主意，做個小對照實驗。用同一個問題丟兩邊，比結果——不是比誰對誰錯，是比兩邊的回答對我當下的狀態哪個更合。

這三個問題你回答完，選擇自動浮現。過程中不需要問任何一個 Claude 入口「你該被我選嗎」——因為你現在知道，那個問題結構上就不該由它來答。

關於這篇文章的產生方式

最後一件事。這篇文章的論點——從對照實驗、SPB 命名、到判準建立——是我跟 AI 協作者一起推敲出來的，不是我獨自想通的。我做對照實驗、我查文獻、我決定哪些素材進哪個段落；協作者給命名、給框架、給我沒想到的盲點（譬如有一輪我差點寫成「Claude.ai 比 Claude Code 聰明」，被它提醒後我才補上對稱性那段）。

這本身就是這篇文章論點的活示範。我沒把任何一個入口當唯一判官——當我需要探索跟撰寫時，我用 Claude.ai；當我需要把文章寫進 repo 跟發布時，我用 Claude Code；當我需要一個不在這場對照實驗裡的第三方視角時，我開另一個乾淨的 chat 重問一次。判準不是我單獨持有的原則，是我跟協作者一起在用的工作方式。

工具會變，判準不會。下次新入口出現、舊入口改版、整個產品結構大洗牌——你拿這四組 trade-off、這三個自問問題、跟「結構上就不該問工具自己」的原則，都還能用。

下一篇進入第 7 篇，談 Anthropic 四種 Claude 方案的選型——個人、團隊、Enterprise、API——以及一個很多人不知道的訓練政策風險。系列後段還有一篇會專門處理「架構分析」跟「飄移檢查」這兩類橫跨 SSDLC 的元活動——它們的工具分工邏輯比單一階段複雜，需要獨立展開。

本文作者：鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師，專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理，不代表任職機構立場。本文談及的 self-preference bias 引用來源為 Claude Sonnet 4.5 system card（Anthropic 2025）、Bloom 開源評估工具（Anthropic 2025）與 Wataoka 等人 Self-Preference Bias in LLM-as-a-Judge（2024）。讀者可依此自行查證。AI 協同創作已在系列導讀揭露。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/06-tool-choice-in-ssdlc/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com

本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 7 篇。前兩篇分別處理了 token 成本(第 5 篇,如何在一個方案內省錢)和 SSDLC 工具選擇(第 6 篇,不同階段該用哪個入口)。這一篇處理最上層的商務決策:**該選哪個方案?**對我而言,選對方案的一次性決策,常常比後續一連串的技術優化更值得提早花時間想清楚。

開場:選型可能是你最容易忽略的省錢決定

我想先請你回想一件你可能做過的事。

你換手機資費方案的時候,應該有那種經驗——某天你靜下心來,把家裡三支手機的每月帳單加起來,發現一年竟然多花了好幾千塊,只因為當初沒仔細比較方案。後來你花一個下午研究、比較、換方案,從此每月省下兩千元。一個下午的研究,換來全年兩萬四的節省。

你省下的錢不是因為你講電話講得變少,而是因為選對了方案。

這個觀察對於 AI 服務的使用一樣成立。我自己在 POC 初期花了大量心力優化 CLAUDE.md、精調 MCP 設定、學習 /compact 的時機——這些都有價值。但我也看過(包括我自己)用錯方案的情境:一個個人 Pro 帳號,可能其實多花了錢,也少了 SSO、費用控管,預設還讓對話被拿去訓練模型。這些問題不是技術優化能解決的,只能透過選對方案來解決。

所以這一篇我們先不談技術,先談商務決策。Anthropic 目前提供四種 Claude 服務管道,每一種的計費方式、功能範圍、資料處理政策都不同。我希望這篇可以幫你比較容易判斷自己的情境屬於哪一類、適合什麼選擇,以及背後的理由。

四種方案的全景地圖

先建立整體感。Anthropic 的四種服務管道是這樣的架構:

個人版(Pro / MAX)。針對單一使用者的方案,Pro 每月大約二十美元(寫這篇時的公開定價),MAX 則依使用量分為每月一百或兩百美元。這通常也是初次接觸 Claude 時最常被使用的方案——你在瀏覽器打開 claude.ai,登入你的個人帳號,就是在用 Pro 或 MAX。

團隊版(Team Plan)。針對五到一百五十人的小中型組織。Standard seat 每人每月二十美元(年繳)或二十五美元(月繳),Premium seat 每人每月一百美元(年繳)。相較於個人版,它加入了 SSO、管理者後台、費用控管、M365/Slack/Google 整合等組織管理功能。2026 年以來 Anthropic 對這個方案做了大量功能強化,現在它已經是一個相當完整的組織級方案。

Enterprise。針對更大規模的組織,分為自助版(二十人起)和業務協助版(五十人起)。計費結構不同——每人每月二十美元的平台存取費,加上實際用量按 API 費率另計。這個結構意味著你的總成本取決於實際使用量,不是固定值。Enterprise 比團隊版多出的關鍵功能是稽核合規類——audit logs、Compliance API、IP allowlisting、自訂資料保留政策。

API。針對開發者與系統整合。這裡沒有「座位費」,完全按 token 使用量計費。你拿到一組 API Key,放進你的應用程式或自動化腳本,每一次呼叫按實際消耗計算。這是 Claude Code 在命令列背後用的機制,也是所有「把 Claude 整合進自家產品」的團隊在用的方式。

這四種方案看起來是「由小到大、由簡到繁」的漸進線,但實際上它們解決的是不同的問題——不是「買不起大的就買小的」那種關係。我用一個比喻讓你感受這個差別。

想像你是經營餐飲業的。個人版像是家用廚房——你一個人在家做菜給自己吃,不需要考慮食品安全、不需要記錄哪道菜賣給誰、只要你吃得開心就好。團隊版像是小餐廳——你有幾個員工,需要基本的分工、需要管理庫存、需要控制成本,但規模還沒大到要做 HACCP 認證。Enterprise 像是連鎖餐飲集團——你必須能追溯每一道菜的原料來源、每一位員工的工作記錄、所有流程都要能通過食品稽核。API 則像是中央廚房——你專門生產食材,賣給其他餐廳,你的成本是「產出了多少」,不是「雇了幾個人」。

這四種業態都是餐飲業,但經營邏輯完全不同。你不會拿家用廚房的思維去管理連鎖餐飲集團,也不會用中央廚房的計費方式去開一家小餐廳。選擇哪一種,取決於你真正在做的事情是什麼。

接下來我會一層一層打開每種方案,讓你能判斷自己屬於哪一種。

一個我自己一開始也不知道的嚴肅問題:訓練政策

在進入每種方案的細節之前,我必須先把一件事拉到台前來講。這件事我自己一開始也沒注意到,後來才意識到它的影響範圍——而且 Anthropic 並沒有很大聲地宣傳這件事,所以很多人(包括我自己)曾經在毫不知情的情況下,正面對一個可控但需要主動管理的風險。

這件事是:個人版(Free / Pro / MAX)從 2025 年 8 月起,採用 opt-out 模式的訓練政策。

讓我慢慢拆解這句話的意思,因為每個詞都很關鍵。

Opt-out 的意思是「預設開啟,除非你主動關閉」。對應到這個情境:預設上,你在個人版 Claude 的對話,可能會被拿去訓練模型。如果你不特別進去帳號設定裡關閉這個選項,你跟 Claude 說過的每一句話,理論上都可能成為未來版本的訓練材料。

這還不是最嚴重的部分。更值得注意的是:如果你允許訓練(也就是沒 opt-out),你的對話資料保留期會從預設的 30 天延長到 5 年。

讓我換一個方式讓你感受這件事的量級。你過去三個月用個人版 Claude 討論過的所有事情——工作上的 debug、規格書草稿、團隊內部討論、你寫到一半的簡報草稿、你向 AI 吐槽主管的抱怨——如果你沒有 opt-out,這些資料會在 Anthropic 的系統裡保留到 2030 年左右,而且可能出現在未來模型的訓練集裡。

這不是假設性的風險,這是 Anthropic 公開的政策。你可以在他們的 Privacy Center 找到原文。問題在於,我自己一開始也沒主動去讀那些政策文件,我猜很多人跟我一樣——預設行為就是「點選註冊、開始用」,完全不知道這個設定存在。

作為一個 infra 工程師,我用過公司內部相關的資料跟 Claude 討論過,我第一次知道這件事的時候也覺得很震驚。我當下立刻做了兩件事:第一,登入個人帳號把這個設定關掉;第二,開始推動公司內部禁止用個人版處理任何組織資料。

那這件事在不同方案上的處理差異是什麼?

個人版(Free / Pro / MAX)如前所述,採用 opt-out,風險由使用者自己管理。

團隊版預設就不用於訓練,而且這是 Anthropic 的商業條款承諾,不是單純的隱私政策——具有法律約束力。

Enterprise 完全不用於訓練,連「可以開啟訓練」的選項都沒有。

API 完全不用於訓練,受商業 API 條款和 Data Processing Addendum 保障。

看到這個差異,我自己對於「團隊使用」的場景就比較清楚:團隊版以上幾乎變成預設選擇。不是因為功能更多,而是因為資料保障的合約等級完全不同。

這個訓練政策議題,是這一整篇裡我自己最希望先講清楚的一件事。如果這篇你只先記一件事,我會建議是這個:如果你用個人版處理過任何一絲工作內容,我建議現在就去關掉那個訓練設定。這件事五秒鐘可以完成,但影響範圍是五年。

資料處理的兩條路徑:claude.ai 介面 vs API

講完訓練政策這個敏感議題,接著我們看資料處理的另一個維度——你的對話是透過什麼路徑送到 Anthropic 的。

粗略分成兩條路徑:一條是 claude.ai 網頁介面(以及對應的桌面、手機 App),另一條是 API(包含 Claude Code 在背後的呼叫)。這兩條路徑看起來都是「把資料送到 Anthropic」,但合約層級和保留政策差很多。

claude.ai 介面下,你的對話紀錄是以「使用者對話歷史」的形式儲存。後端日誌保留約 30 天,你可以自己刪除對話。個人版如前所述有 opt-out 訓練問題,團隊版/Enterprise 則無此問題。

API 的處理方式完全不同。API 呼叫不以「對話歷史」形式留存,而是以「請求日誌」形式。保留政策方面——這裡有一個很有趣、也很值得你學習的觀察——Anthropic 官方資料自己就存在不一致。

根據 Anthropic Developer Docs 和多個第三方分析的記載,自 2025 年 9 月 14 日起,API 資料保留期已從 30 天縮短至 7 天。但 Anthropic Privacy Center 的「組織資料保留」頁面,在本文撰寫時仍記載「30 天內自動刪除」。兩個 Anthropic 官方頁面對同一件事的描述不一致。

這個觀察有兩個層次的意義。

第一層是實用意義。你實際上需要知道自己的資料留多久。這個差異(7 天 vs 30 天)在合規稽核上可能是重要的。如果你準備採購這個服務,建議在決策前直接聯繫 Anthropic 確認目前實際適用之保留天數,而不是相信任何一個單獨的頁面。

第二層是工程意義,而且是這個觀察真正有價值的地方。即使是 Anthropic 這樣規模的公司,他們的官方資料之間也會出現不一致。這不是在酸他們,任何大型組織都會遇到這個挑戰——文件版本更新不同步、團隊之間的資訊傳遞延遲、甚至不同法務認知的差異。對你作為一個工程師或決策者的啟示是:不要盲目相信任何單一資料來源,即使它是官方的。重要決策前,交叉驗證、直接詢問、留下紀錄。這個工程紀律在 AI 時代格外重要,因為服務條款變動的速度遠超過傳統軟體。

Zero Data Retention:零保留的選項

不論 7 天還是 30 天,有些組織的合規要求可能是「零保留」——資料處理完就必須刪除,不能留存任何備份。Anthropic 對這個需求提供了一個選項:Zero Data Retention(ZDR)。

ZDR 的意思是:你的 API 請求資料,在處理完後立即刪除,不留存任何副本。這個選項不是預設的,必須向 Anthropic 申請,而且需要企業客戶資格才可申請——這意味著個人版使用者不能使用這個選項,必須是團隊版以上。

ZDR 對哪些場景特別重要?

處理真正敏感資料的應用。如果你的 Claude 呼叫內容包含個資、醫療資料、金融交易明細等,ZDR 讓你可以對合規稽核員說「這些資料在傳輸到 AI 服務時不會被留存,風險已消除」。

受嚴格法規管轄的產業。例如醫療業的 HIPAA、金融業的某些資料保護要求、政府專案的特定合規條款——很多時候這些規範明確要求「第三方處理敏感資料不得留存」。

高敏感度的軍事 / 政府 / 情報應用。這些場景下,即使 30 天也太長。

對於大多數一般企業而言,ZDR 不是必要的,因為 7 天或 30 天的保留期已經在合規可接受範圍內。但如果你在評估時發現「保留一天都不行」的場景,這個選項存在、而且可以申請。

每種使用者該怎麼選?一個決策指引

到這裡我們把四種方案的差異、訓練政策、資料保留、ZDR 都講完了。現在我把這些資訊整合起來,分享我自己怎麼根據情境思考。我把使用者分成五種典型情境,每一種給一個我會選的路徑,你可以對照看看自己接近哪一種。

情境一:個人工作者,用 AI 幫自己做事。你是自由接案者、獨立開發者、或公司內的單獨使用者,用 Claude 處理的都是自己的工作內容,沒有跨多人的管理需求。

這個情境下,個人 Pro 是合理選擇(每月二十美元)。但我會強烈建議馬上做一件事——登入設定,關閉訓練資料使用的選項。這五秒鐘的操作,把資料保留期從「最長五年」降到「預設 30 天」。對於要處理工作或客戶資料的使用者,我覺得這個設定不該被跳過。

如果你的使用量很大(每天密集使用超過四小時),MAX 可能比較划算。MAX 的用量上限是 Pro 的 5 倍或 20 倍,對重度使用者 ROI 更好。

情境二:小團隊(5-15 人),無嚴格合規要求。你和幾位同事共用 AI,可能是一個新創團隊、一個顧問小組、一個部門內的專案團隊。沒有強制性的 ISO 認證或 HIPAA 要求,但希望有基本的組織管理能力。

這個情境,團隊版 Standard seat 對我來說是很自然的選擇。每人每月二十美元(年繳)跟個人 Pro 同價,但多了 SSO、管理者後台、費用控管、Slack/Google 整合——對我而言最關鍵的是,資料不會被用於訓練,不需要逐一提醒每個成員記得去關設定。

五人起購是個門檻,如果你們只有三到四人,短期可以先各用個人 Pro 並確認每個人都關了訓練,等團隊擴充到五人再轉團隊版。

情境三:中型組織(15-150 人),需要組織管理。你是中小型企業、政府部門、或大公司的某個事業群。人員流動正常,需要帳號管理、需要費用控管、可能有基本的稽核要求但還沒到嚴格的外部認證層級。

團隊版 Standard/Premium 搭配使用是常見的實作。一般使用者用 Standard seat,重度使用者(例如工程師每天大量用 Claude Code)升級為 Premium seat。如果整個組織對 AI 的使用還在試水溫,全部先用 Standard 也沒問題,之後再看使用量調整。

一百五十人是團隊版的硬性上限。接近這個人數時開始評估是否需要升級到 Enterprise。

情境四:大型企業(150+ 人)或有嚴格合規要求。你是大型企業、金融機構、受嚴格法規管轄的產業、或需要外部 ISO 27001 / SOC 2 稽核的組織。

這個情境下,Enterprise 通常是繞不過去的選擇,不是因為團隊版功能不夠,而是因為這裡需要的一些功能只有 Enterprise 提供:audit logs、Compliance API、IP allowlisting、SCIM 自動佈建。稽核員會要求看這些東西,團隊版的基本管理後台不容易交差。

Enterprise 分自助版(20+ 人,可線上自助建立)和業務協助版(50+ 人,需聯繫 Anthropic 業務團隊)。大部分大型企業會選業務協助版,因為會有合約細節要談,也會享受業務團隊的採購支援。

有一個重要的實務提醒:目前團隊版無法自助升級到 Enterprise。如果你從團隊版起步,之後要升級,需要聯繫 Anthropic 業務團隊做遷移。這個過程可能需要一些時間,採購規劃時要預留。

情境五:有 AI 整合開發需求。你不只是「使用」Claude,你還要把 Claude 整合進自家產品、自動化腳本、後端服務。例如一個 SaaS 應用在背後呼叫 Claude 做內容生成、一個客服系統用 Claude 處理用戶問題、或一個企業內部工具用 Claude 做文件分析。

這種場景需要 API。API 完全按 token 使用量計費,沒有座位費。適合「用量不規律、由系統自動發起、而非由個人互動」的場景。

API 還有一個特殊價值——它可以跟你的其他服務管理方案並存。你的團隊成員各自用團隊版做日常互動(受座位費保護的用量),同時你的後端系統用 API 做自動化處理(按實際用量付費)。這兩條路徑的帳單是分開的。

一個進階的工程設計:去識別化閘道

到目前為止我們講的都是「選方案」,這是第一層的決策。但對於真正敏感的場景,有一個更進階的設計值得介紹——不論你選哪個方案,都可以加上這一層額外保障。

這個設計叫做去識別化閘道(de-identification gateway)。概念其實不複雜:在你的組織內部、資料離開你的環境送到 AI 服務之前,先把敏感資訊替換成假名。

舉個例子讓你感受這個設計的精神。

假設你有一個自動化流程,每天讓 Claude 幫你分析上百台伺服器的日誌。如果你直接把原始日誌餵給 Claude,Claude 看到的會是:「伺服器 prod-web-01(IP 10.0.1.23)在 2026-04-20 14:30 發生錯誤…」。這段內容送到 Anthropic 就進入他們的系統(保留 7 天或 30 天)。

去識別化閘道的做法是:在這段內容離開你的組織之前,先透過一個中介服務做替換。伺服器名稱 prod-web-01 被替換成 HOST_001、IP 10.0.1.23 被替換成 IP_042、時間被保持(時間通常不敏感)。Claude 看到的變成:「伺服器 HOST_001(IP IP_042)在 2026-04-20 14:30 發生錯誤…」。這段內容送到 Anthropic 時,已經不包含你的真實 infrastructure 資訊。

Claude 根據這些假名化的資料做分析、給出建議。它的回應回到你的閘道時,閘道再把假名替換回原始值,你看到的就是正確的伺服器名稱。整個過程對使用者透明。

這個設計的精妙之處在於:它把「資料保護」從『相信第三方』改成『不需要相信第三方』。即使 Anthropic 的保留期政策、訓練政策、甚至未來的條款變更,都不會影響你的敏感資料——因為那些資料根本沒離開你的組織,離開的只是一些無意義的假名。

要做到這一點,有幾個關鍵的技術細節:

同一個值必須對應到同一個假名。如果 prod-web-01 在某次呼叫被替換成 HOST_001、下次呼叫被替換成 HOST_042,Claude 會以為是兩台不同的伺服器,分析品質會崩盤。所以閘道必須維護一個「session 內一致性」的對應表。

某些類型的值不能替換。時間戳、錯誤代碼、架構類型、技術術語——這些不是敏感資料,替換掉反而讓 Claude 失去分析需要的語境。只有明確定義為「敏感」的類型(IP、hostname、人名、帳號、專案代號)才走替換流程。

還原要嚴格控制。假名還原到原始值這個動作,必須在你的組織內部完成,且有嚴格的日誌。如果假名對應表外洩,整個保護就瓦解。

這個設計不是每個場景都需要。對多數內部工具、寫程式輔助、一般文件處理,直接用 API 或 claude.ai 就夠了。但如果你的場景涉及真正敏感的資料(客戶個資、財務資料、醫療記錄、國家機敏資訊),這一層閘道可以讓 AI 使用更接近多數合規框架可以接受的範圍。

更重要的是,這個設計是跨 AI 服務可攜的。你的閘道不綁定 Claude、也可以用在其他 AI 服務上。未來如果需要同時用多家 AI 服務做比較或備援,同一套閘道可以支援。

合規與稽核的決策節點

講到這裡你可能想問:我怎麼知道我的場景算不算「需要嚴格合規」?

這個問題沒有標準答案,但有一些判斷點可以幫你。

是否受外部法規管轄。你的組織是否要遵守 ISO 27001、SOC 2、HIPAA、PCI-DSS、GDPR、或當地類似法規?如果是,這些法規通常會要求「第三方服務的稽核能力」。這是 Enterprise 的 audit logs 和 Compliance API 的主要價值——它們提供給稽核員直接可用的證據。

是否處理客戶的個資或資料。你的 Claude 使用是否涉及客戶的姓名、聯絡方式、交易紀錄、健康資料?處理客戶資料的標準通常比處理內部資料嚴格。如果是,去識別化閘道應該是基本配備。

資料的「保留風險」能不能接受。想像最壞情況:你的對話資料被保留 30 天(或 7 天),在這期間 Anthropic 遭到資料外洩事件(雖然機率極低)。這會造成什麼損害?如果答案是「會讓公司陷入法律糾紛」,那你需要 ZDR 或去識別化閘道。如果答案是「影響有限、可控」,那你的風險容忍度在標準保留期內就夠了。

有沒有「證明合規」的需求。這跟實際安全性是兩回事。你可能在實際操作上已經很安全,但稽核員要的是可以被審視的記錄。Enterprise 的 audit logs 不是加強你的實際安全性,是讓你有東西可以拿給稽核員看。沒有這個需求的組織,可以用團隊版;有這個需求的組織,很難繞過 Enterprise。

分階段採用策略:從小到大的路徑

如果你的組織正在評估導入 Claude,但還不確定要從哪裡起步,我給一個經過實務驗證的分階段路徑。

短期(0-3 個月):團隊版 Standard 起步。以團隊版 Standard seat 導入五到二十個核心使用者,建立基本使用慣例。這個階段的目標是「驗證 AI 工具能在我們的工作中創造價值」,不是「做到完美合規」。成本可控、功能完整、資料保障已達商業合約等級。

中期(3-6 個月):評估進階需求。隨著使用普及,你會看到某些使用情境需要更強的保障——可能是某個團隊處理客戶個資、可能是某個自動化流程處理機敏資料、可能是稽核開始詢問日誌。這時候我自己的做法是讓實際的使用情境驅動決策,而不是預設「我們以後一定需要 Enterprise」就超前部署。

長期(6 個月以上):確認最終架構。經過半年的實際使用,你會對自己的需求有比較清楚的認知——哪些團隊用哪種方案、需不需要去識別化閘道、要不要申請 ZDR。這個時候做的升級決策,是建立在真實資料上的,不是猜測。

這個分階段策略我自己摸索的精神是讓需求驅動採購,而不是讓採購驅動需求。我看過一些組織一開始就買 Enterprise,後來發現多數功能用不到,有點可惜。反過來,也有組織太晚升級,在被稽核員要求時手忙腳亂。我自己偏好從團隊版起步,讓實際使用告訴我下一步該往哪裡走。

我自己用的一個決策原則

這一篇的內容比較複雜,我想用一個我自己摸索出來的原則把它收起來。

我在選 Claude 方案時,問自己的不是「哪個功能最多」也不是「哪個最便宜」,而是:這個方案對我的『不能發生的事』提供什麼保障?

對一個個人工作者,「不能發生的事」可能是「我的工作對話被拿去訓練模型並保留五年」——所以選擇了個人 Pro,但立刻關閉訓練設定。

對一個小團隊,「不能發生的事」可能是「某個成員離職時,他的 AI 對話紀錄失控」——所以選擇了團隊版,有 SSO 和集中管理。

對一個受管的企業,「不能發生的事」可能是「被稽核時拿不出 AI 工具的使用證據」——所以選擇了 Enterprise,有 audit logs 和 Compliance API。

對一個處理高敏感資料的組織,「不能發生的事」可能是「客戶個資在未授權情況下離開組織」——所以在任何方案之上加了去識別化閘道。

對我自己而言,選型的關鍵不是正向的「我要什麼功能」,而是逆向的「我要避免什麼後果」。這個思考方式套用幾次之後,我發現自己的決策變得清晰一些——不是在功能清單裡打勾,而是在風險清單裡消除。

下一篇預告

這篇處理了「選對方案」這個商務決策,也提到了 Enterprise 的 audit logs、IP allowlisting、Compliance API 這些合規功能。但有一個更深層的議題還沒觸及——即使選對方案,你還需要在工具層級對 AI 施加技術性的約束。

設想這個情境:你給 Claude Code bash 權限,它在工作中決定執行一個 rm -rf 指令。這個行為在方案層級是合法的(方案允許 tool use),但這通常不是你希望它真的執行的事。

在 AI 可以執行真實指令的時代,光靠「選對方案」不夠,還需要「技術性的守門員」。這就是下一篇要談的主題:Hooks 與權限系統。我會用一個真實的維運事件當引子,告訴你為什麼這三道關卡是必要的、而且一道都不能少。

本篇收尾

對我而言,選對 Claude 方案,常常是這個工具使用過程中,影響範圍最大的一次性決策之一。

四種方案——個人、團隊、Enterprise、API——各自解決不同的問題,不是「由小到大的階梯」。個人版最便宜但訓練政策有 opt-out 風險,需要主動關閉。團隊版提供了組織管理的最小完整集合,我覺得是多數中小型組織比較自然的起點。Enterprise 的核心價值是合規稽核的證據提供,適合受法規管轄的大型組織。API 適合系統整合場景,按量計費、完全不用於訓練。

在方案之上,還有一層可以自己加的設計——去識別化閘道。這個設計讓你不必依賴第三方的資料保留政策,即使在最敏感的場景也能使用 AI 服務。

我自己摸索出來的核心原則不是「選最多功能」或「選最便宜」,而是「針對我不能發生的事,這個方案提供什麼保障?」用這個逆向思維做決策,我自己比較容易得到一個能說服自己的答案。

下一篇我們進入 Hooks 與權限系統,談技術層級如何讓 AI 真正聽話。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。文中所有 Claude 方案定價與政策資訊為 2026 年第二季的公開資料,Anthropic 保留隨時調整權利。重要採購決策前,請以 Anthropic 官方網站與直接聯繫確認之資訊為準。本文觀察到的官方資料不一致之處(7 天 vs 30 天 API 保留期),在撰寫時仍存在,讀者在做決策時建議再次驗證。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/07-plan-selection/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com