前兩篇量了兩個數字：第 22 篇一分錢的預算花到 0.1175 美元才停，第 23 篇一句 20 字的問題組成 82,574 個詞元的請求。還有一個數字我一直沒量：每一圈裡，模型開口之前先想了多久。在 Claude Opus 5.5 上，這一段關不掉，而且預設一個字都不給你看。

先講結論：第六層到這裡收尾。一個代理的花費是三個數字相乘：繞幾圈、每圈送多少、每圈想多久。 前兩個前面已經算過，這一篇補第三個，思考預算（thinking budget），再講代理在錢以外會怎麼壞、什麼時候不該用代理，拿第 4 篇的評估集量一次這一層換到了什麼，最後看一個代理的天花板在哪。

前兩筆帳，前面已經算過

每圈重送、越送越長是第 11 篇和第 21 篇的帳，快取的價格在第 4 篇、試算在第 11 篇，只更正一個比例：那時候 Claude Opus 5 的快取命中是輸入價的 0.1 倍，Opus 5.5 是 0.05 倍（定價表，2026-10-08 查）。預算煞車只停得在兩輪之間，第 22 篇實測過。新的只有一個：Claude 的 API 有一個還在 beta 的任務預算（task budget）。max_tokens 是模型不知道的硬上限，任務預算則把詞元總額告訴模型，由伺服器替它倒數，讓它自己配速收尾。它只是建議，硬線還是你自己設。另外它目前只能直接走 Messages API，Claude Code 不支援（2026-10-08 查）。

思考預算：從一個數字，變成一個等級

模型開口之前先想的那一段，叫推理詞元（reasoning tokens）。以前控制它的方法是直接給一個數字，budget_tokens，這就是「思考預算」的原意。手動模式的文件還留著這個寫法，主要給 Claude 4.5 以前的模型用（4.6 還能用，但已棄用）。Claude 4.7 之後，包括 Opus 5.5，送出去回你的是 400。

現在 Opus 5.5 的思考關不掉，唯一的旋鈕是努力程度（effort）：low、medium、high、xhigh、max 五級，Opus 5.5 預設 medium。它管的不只是想多深，官方把它定位成整體詞元花費的開關。

看不見的中間過程，第 21 篇和第 23 篇都講過。思考是更深的一層：Opus 5.5 的思考區塊預設是 omitted，回來的 thinking 欄位是空字串，但思考照樣發生、照樣照輸出價計費。想看，要自己打開摘要：

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},  # 預設看不到，要自己開
    output_config={"effort": "low"},  # low | medium | high | xhigh | max
    messages=messages,
)
print(response.usage.output_tokens)  # 思考的詞元也算在這裡
print(response.usage.output_tokens_details.thinking_tokens)  # 其中有多少是思考

打開也只是摘要，能稽核的只有 usage。後面那次評估集的 20 次呼叫，effort 都是 medium：回「新功能」這種題目，有 9 次思考詞元是 0，review 那題則想了 478 和 901 個。所以「關不掉」的意思是你不能叫它別想，想不想、想多少是它自己決定的。我的習慣是每一輪都記下 usage，thinking_tokens 突然很高的那一輪，就是它想很久的那一輪。

多想一點，什麼時候划算

回答時多花運算，叫測試時運算（test-time compute）。第 22 篇的反思是多繞一圈，effort 是同一圈想得更深。

Snell et al.（arXiv, 2024）發現多想有沒有用很看題目難度，照每一題的難度分配運算（他們叫 compute-optimal），比每題都固定抽 N 個答案挑最好的（best-of-N），運算效率高出 4 倍以上。在算力相同的比較下，而且是小模型本來就有一定成功率的題目，多給它推理時間，甚至贏過大 14 倍的模型。

翻成工程做法：effort 照路徑設，不要全域一個值。 判斷使用者回的是「好」還是「不好」，用 low。要改三個檔案的重構，給 high 以上。全域一個值，簡單的請求就在替難的請求付錢。

同一個想法往外推，是連模型都照路徑換。FrugalGPT（Chen, Zaharia, Zou, 2023）叫它 LLM 串接（cascade）：先問便宜的模型，評分器判斷不夠可靠才往上問貴的，摘要報告的是表現追平當時最好的單一模型（GPT-4），成本最多省 98%。2026 年也有產品做這一層，例如 TypeSafe AI 的 Jev（廠商說法，我沒量過）。但快取跟著模型走，換模型就是另一份前綴，所以我會先在同一個模型上把 effort 調低，量過不夠再加小模型。

錢以外，單一代理會怎麼壞

自己走偏。 第 6 篇的雪球效應（Zhang et al., 2023）說模型會對早期的錯誤過度承諾，因此犯下原本不會犯的錯。在代理迴圈裡，那一步錯的判斷寫進 messages，每一圈都重送，後面每一個決定都站在它上面，中間沒有人問一句「方向對嗎」。

繞圈。 錯誤一直回來，它一招換過一招試不停（第 22 篇）。每一圈都開了不同的工具單，從外面看像在做事。

說做完了，其實沒有。 end_turn 只代表模型認為做完了。terminal-bench（Merrill, Shaw, Carlini et al., 2026）用測試腳本檢查容器的最終狀態，前沿代理在上面仍然不到 65%。

這三種壞法，迴圈裡都缺一個不是模型自己的檢查。所以我的代理至少帶一個外部驗證，測試、檔案在不在、一個 schema 都好，完成的定義不交給模型自己講。現成能用的有三種：

• 測試：pytest、npm test，或像 terminal-bench 那樣，最後跑一支檢查最終狀態的腳本。
• schema：API 的結構化輸出在 output_config.format 放一份 JSON Schema，官方說是用受限解碼保證回應符合（拒答和 max_tokens 截斷例外）。工具的輸入用第 16 篇的 strict: true。
• Claude Code 的 Stop hook：模型要收尾之前先跑你的指令，指令以結束碼 2 退出，它就停不下來，stderr 那段話會當成理由交給它。

Stop hook 我掛上去跑了一次。.claude/settings.json：

{
  "hooks": {
    "Stop": [
      { "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/check-done.sh" } ] }
    ]
  }
}

.claude/check-done.sh（要先裝 jq）：

#!/bin/bash
input=$(cat)
# 已經被擋過一次、正在補做，就放行，避免永遠停不下來
[ "$(jq -r '.stop_hook_active' <<<"$input")" = "true" ] && exit 0
cd "$(jq -r '.cwd' <<<"$input")"
if [ ! -s changelog.md ]; then
  echo "changelog.md 不存在或是空的，還沒做完。" >&2
  exit 2
fi

我只請它把三則 commit「整理成一份 changelog」，沒說要存檔。它把內容貼在對話裡就要收尾，被擋下來後回我「我剛才只把 changelog 回在對話裡，沒有存成檔案，所以專案的完成檢查擋了下來」，接著把 changelog.md 寫出來。3 圈，0.11 美元（2026-10-08，跑了兩次結果相同）。兩個要注意的地方：stop_hook_active 那一行讓它只擋一次，補做之後就不再檢查，官方文件也提醒別擋一個永遠不會成立的條件。拿掉那行的話，Claude Code 連續被擋 8 次會強制結束。還有，這支檢查只看檔案在不在，分類對不對它不管，外部驗證寫多細，完成的定義就有多細。

什麼時候別用代理

第 21 篇引過 Anthropic〈Building effective agents〉的分界：工作流程（workflow）的路徑是程式寫死的，代理是模型自己決定下一步。 同一篇建議先找最簡單的解法，需要才加複雜度，有時候就是不做代理系統，因為代理系統通常拿延遲和成本換任務表現，要先想清楚划不划算。

我自己的判斷順序是三問：

1. 一次呼叫做得完嗎？ 分類、摘要、改寫，做得完就停。
2. 步驟事先寫得出來嗎？ 寫得出來就是工作流程，每一步可以單獨測。
3. 都不行，才讓模型決定下一步，帶著煞車和外部驗證。

延遲也是判準。像語音介面，使用者講完就在等，代理多繞一圈就是一段沒人說話的空白，這種場景多半停在第 2 問。

重跑評估集：第六層

第 4 篇的規矩是每加一層就用同樣的 10 題重跑。第四、五層我沒有重跑，所以上一次公開的分數停在第 5 篇的 6／10（第三層：附上團隊筆記，不准用工具，Claude Opus 5）。

這一層只改一件事：拿掉「不要使用任何工具」那句話，讓它在迴圈裡自己開工具單。模型換成了 Opus 5.5，所以第三層的條件也在同一個模型上重跑，分數和成本才比得起來（2026-10-08，Claude Code 的非互動模式 claude -p，claude-opus-5-5，effort medium，每題一個新資料夾、新工作階段，各跑 1 次，是例子不是證據）。還有一件要老實講：第 4、5 篇只記了題目重點，原文沒存，這次的提示詞是照第 4 篇的表重寫的，原文已經存下來，之後每一層照抄。

翻盤的是第 8、9 題，正好是第 4 篇標成「不能動手」的那兩題。第 8 題它自己用 shasum -a 256 算出 bd968cd1c8be，第 9 題的 changelog.md 真的建出來，三則分類都對。其餘八題兩個條件結果一樣，第三層重跑通過的組合（1、2、3、4、7、10）也跟第 5 篇在 Opus 5 上一模一樣。

帳單是我猜錯的地方。我原本以為費用會跟著圈數往上跳。結果總詞元多了 39%，費用只多 2.7%，因為多繞的那幾圈，重送的幾乎都是快取命中的前綴。每一次呼叫，就算只回「新功能」三個字，也要約 21K 詞元、約 0.088 美元，那是 harness 的前綴（這次沒載入 MCP 伺服器，所以是 21K，不是第 23 篇的 82,574）。這一次，第六層用差不多的帳單多拿了 2 分，付的是延遲和多繞的圈數。

第 5、6 題還是沒過。可以用工具的那一組，第一個對話裡它真的寫了記憶檔，內容就是「使用者負責 order-api。」但第二個對話開在另一個資料夾，Claude Code 的自動記憶以專案為單位，它回我「我的記憶目錄是空的」。所以這兩題量到的是我的測法，不是代理，這就是第 13 篇說的記憶不在 Claude 那裡。第 6 題在兩組裡錯法也一樣：SQL injection 抓到了，但照慣例附上 PEP 8 命名和空格的意見。

這麼做的代價

第一，effort 調低是拿品質換錢。 簡單的路徑省得下來，難的路徑調低了會答錯，而哪條是難的要靠量。

第二，少用代理是拿彈性換可控。 寫死的流程碰到沒想到的情況就卡住，串接時小模型也會判錯。

單一代理的天花板

這一層的代理，是把所有推理、記憶和工具執行塞進同一個實例，只走一條推理路徑。Redis 的 Talon Miller 在一篇比較單代理與多代理的文章（2026，廠商部落格，沒有附數據，我只借它的說法）裡說，代理開始挑錯工具，或明明有清楚的流程卻執行得一團亂，就是碰到單一代理的上限。對上這個系列量過的東西，天花板有五塊：

但單一代理還是預設值。同一篇也說大多數應用從這裡開始：執行路徑整條看得到、除錯單純，沒有協調開銷所以延遲低，詞元用量也好預估。它列的非拆不可只有三種：合規要求的硬性隔離、不同領域各自擴展、組織上的分工。拆開也有帳：代理之間每次往來都是一次 LLM 呼叫，它說協調開銷長得比線性快。這些都是廠商的說法，多代理到底多吃多少詞元，下一層看實測的數字。

這一篇多了什麼，又多付了什麼

多了什麼能力：把代理的花費拆成圈數、每圈脈絡、每圈思考三個數字，知道思考預算在 Opus 5.5 上變成照路徑設的 effort，認得錢以外的三種壞法，並用一個 Stop hook 把「做完了」的定義拿回自己手上，知道什麼時候別用代理，以及一個代理的天花板在哪。

多付了什麼代價：一筆看不見卻照樣計費的思考，一條要靠量測才調得準的 effort 線，以及寫死流程時失去的彈性。

下一篇

一個代理的脈絡塞不下、一個迴圈要跑太久的時候，把工作拆給好幾個代理，帳會變便宜，還是更貴？

下一篇進第七層。

延伸閱讀

• Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters（Snell et al., 2024）：測試時運算怎麼照題目難度分配。
• FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance（Chen, Zaharia, Zou, 2023）：LLM 串接，先問便宜的模型，不夠可靠才往上問。
• Building effective agents（Anthropic, 2024）：工作流程與代理的分界，以及什麼時候不該用代理。
• Hooks reference（Claude Code 官方文件）：Stop hook 的結束碼、stop_hook_active 與連續擋下的上限。
• Effort（Claude 官方文件）：五個等級與它對詞元花費的影響。
• Thinking（Claude 官方文件）：adaptive thinking 與思考區塊的顯示設定。