12 個 Agent、32 分鐘、3528 個錯誤：Claude Code Max Plan 的算術題

先說結論：如果你在用 Claude Code Max Plan，你對「credits」這件事的理解，需要徹底重設。

這不是誇張。以下是一個真實案例。

開發者 Wise（@trikcode）在 Claude Code Max 20x Plan 上啟動了 12 個平行 Agent，目標是修復 3,528 個 TypeScript 錯誤。結果：32 分鐘內，5 小時份量的 Opus credits 全部燒光。

這個數字讓很多人愣了一下。但如果你理解多 Agent 的運作邏輯，這個結果不但不奇怪，甚至可以說是必然的。

先算清楚這道數學題

先把 Max 20x Plan 的真實計費結構講清楚，因為很多人（包括我之前的理解）把這件事簡化錯了。

根據 Anthropic 官方文件與第三方整理（truefoundry、IntuitionLabs），Max 20x Plan（$200/月）的 usage 限制不是單一維度，而是多層複合：

• 活躍計算小時（active compute hours）週上限：不是 wall-clock time，而是「模型實際在處理 token / 執行程式碼推理的時間」，閒置瀏覽不計入
• Sonnet 與 Opus 分開計算：Max 20x 的 Sonnet 週上限約 480 小時等級，Opus 週上限大約是 40 小時
• 50 sessions/月的軟性限制：達到後可能觸發 throttling
• 5 小時滑動視窗：還有一個短時段的 rate limit，防止突發暴衝

換句話說，「5 小時 Opus credits」這個說法的準確含義，是週配額裡的 5 小時 active compute time——不是 wall-clock 的 5 小時，是 Opus 實際在計算的 5 小時。

現在加入平行度：

• 1 個 Agent active 計算 5 小時 → 消耗週配額中的 5 小時
• 12 個 Agent 同時 active → 每分鐘的 active compute 消耗是單 Agent 的 12 倍
• 12 × 32 分鐘 wall-clock ≈ 6.4 小時等效 active compute

這還沒算每個 Agent 在處理 TypeScript 錯誤時的上下文規模。3,528 個錯誤不是均勻分布——Agent 需要理解整個 codebase 結構、追蹤型別定義、跨檔案分析依賴關係。上下文越大，每個 token 的 Opus 推理成本越高，active time 累積越快。

12 個 Agent 同時做這件事，相當於把時鐘轉速調快了 12 倍。Max 20x 的 40 小時 Opus 週配額，在這種節奏下可能幾天內就用完。

這樣值得嗎？

這是真正有趣的問題。

3,528 個 TypeScript 錯誤，手動修？這件事我做過。型別錯誤不是簡單的 lint 警告，很多需要你理解業務邏輯、追蹤介面定義、確認第三方套件的型別升級。一個有經驗的工程師，保守估計每小時能處理 40 到 80 個錯誤——前提是這些錯誤不互相依賴。

如果錯誤之間存在依賴（現實中往往如此），速度更慢。

按每小時 60 個錯誤計算：3,528 ÷ 60 ≈ 59 小時的人工時間。

12 個 Agent 用了 32 分鐘和 5 小時份量的 Opus credits。Max 20x Plan 的月費是 200 美元。就算把整個月的額度都算進去，對應的人工成本根本不在同一個數量級。

在這個維度上，這個交換非常划算。

但這裡有一個重要的但書：Agent 修出來的 TypeScript 錯誤，不等於真正修好了。 修 TypeScript 最糟糕的方式，是把型別全改成 any。最快，最省事，完全不解決問題。你需要 review，需要測試，需要確認 Agent 沒有用欺騙性的方式達成「零錯誤」。

所以更準確的說法是：32 分鐘讓你從 3,528 個錯誤推進到「可以 review 的狀態」。這本身就已經是很大的價值。

這個案例說明了什麼

Credit 模型和 capability 之間有一個根本性的張力，而多 Agent 讓這個張力變得無法忽視。

傳統使用 AI 工具的心態是：我一次用一個工具，慢慢做事。Credits 消耗是線性的，可預期的，你有心理準備。

多 Agent 工作流的心態完全不同：你是在部署一支小型工作隊。隊伍的規模和運作時間直接決定費用。這更接近雲端運算的計費邏輯——你需要像思考 AWS EC2 instance 時間一樣，思考 Agent 並行度和執行時長。

大多數 Claude Code 使用者還沒有建立這個心智模型。

這不是 Anthropic 的錯，也不是使用者的錯。而是一個認知過渡期的問題：工具的能力已經到了這裡，但我們思考「用 AI」的方式還停留在單點工具的時代。

Multi-Agent 正在重新定義 Claude Code 的使用方式

這個案例不是孤例。在 Anthropic 的官方文件和社群討論中，多 Agent 工作流的使用頻率正在快速上升。幾個值得關注的趨勢：

任務分解越來越精細。 與其讓一個 Agent 跑完所有事情，更有效的做法是把大任務拆成獨立子任務，並行交給多個 Agent。TypeScript 修錯這個案例就是典型：3,528 個錯誤被分配給 12 個 Agent，每個 Agent 負責一個子集。

Orchestrator 模式開始出現。 一個 Agent 負責規劃和分配任務，其餘 Agent 負責執行。這和軟體工程中的 worker pool 模式高度吻合。

Claude Code 本身的工具鏈也在往這個方向走。 官方的 /batch skill 會自動把一個大任務拆成 5–30 個獨立單位，替每個單位生成一個背景 Agent + 獨立 Git worktree，每個 Agent 各自跑測試、各自開 PR。另外 sub-agent 呼叫與 hooks 系統——這些設計都在為更複雜的多 Agent 協作鋪路。

Sub-agent vs Agent Teams 的差別也值得認識：sub-agent 是單向的（主 agent 派任務、sub-agent 回報結果），適合獨立研究和資料處理；Agent Teams 是多向協調（隊員之間可以互相溝通、共享任務清單），適合需要跨模組協作的複雜任務。12 個 agent 修 TypeScript 錯誤這個案例，比較接近前者的「split-and-merge」模式。

Anthropic 很清楚自己在做什麼：他們不只是在造一個更強的 coding 助手，而是在造一個可以組成工作隊的 Agent 基礎設施。

你現在應該怎麼做

如果你是 Claude Code 的付費使用者，尤其是 Max Plan，幾個實用的思考框架：

設定任務邊界再啟動 Agent。 不要把模糊的大任務丟給多個 Agent 同時跑。先定義清楚每個 Agent 的輸入範圍和預期輸出，否則 Agent 之間可能重複工作，credits 消耗翻倍但結果品質並沒有翻倍。

監控而不是放著跑。 32 分鐘燒光 5 小時 credits 這件事，快的程度讓人措手不及。Claude Code 有 token usage 的即時回報機制，設定一個自己能接受的上限，超過就暫停。

把 Max Plan 的 credits 當做資本，不是消耗品。 最好的使用方式是把高密度的重複性技術工作集中起來，一次性解決——就像這個案例。而不是每天用一點點，讓 credits 在低價值的任務上慢慢流失。

建立 review 流程。 Agent 生成的程式碼品質，很大程度上取決於你對輸出的驗收標準有多嚴格。批量修 TypeScript 之後，跑測試、做 code review、驗證型別推斷是否仍然正確——這些步驟不能省。

32 分鐘、12 個 Agent、3,528 個錯誤。這不只是一個有趣的 Twitter 貼文，而是一個信號：我們對 AI 工具的使用方式，正在進入一個不同的量級。

你可以繼續用 Claude Code 像用搜尋引擎一樣，一次一個問題。也可以開始認真思考，如何把它當成一支可以部署的工作隊。

這兩種用法的結果，不在同一個數量級上。