extended thinking 實戰：thinking budget 怎麼設、跟 tool use 怎麼搭

上一篇把 extended thinking 的觀念講完了：先想再答、用成本換品質、開不開由評測決定。這篇捲起袖子進實作：參數怎麼加、預算怎麼抓、跟工具一起用要注意什麼。

好消息是，開啟它只需要兩個參數；真正要花心思的，是預算的拿捏與回應的處理。

兩個參數就開得起來

做法不是每次都手寫完整的 API 請求，而是在自己封裝的 chat 函式上加兩個參數：一個開關、一個思考預算。函式簽名長這樣：

def chat(
    messages,
    system=None,
    temperature=1.0,
    stop_sequences=[],
    tools=None,
    thinking=False,
    thinking_budget=1024
):

開關打開時，把 thinking 設定塞進 API 參數，再照常呼叫即可：

if thinking:
    params["thinking"] = {
        "type": "enabled",
        "budget": thinking_budget
    }

# 呼叫時開啟思考
chat(messages, thinking=True)

這個封裝的好處，是把「開不開思考」變成呼叫端的一個布林值：平常的請求完全不受影響，只有需要深度推理的那幾條路徑才把 thinking 打開。成本控制的粒度，因此握在每一次呼叫手上。

thinking budget 怎麼抓

思考預算是 Claude 能用於推理的 token 上限，有兩條硬規則：

• 下限 1024：思考預算最少要 1024 tokens。
• max_tokens 必須大於預算：整個回應的 token 上限，要留得比思考預算更大，答案才有空間。

在這兩條規則之上，預算的拿捏就是成本與品質的平衡。我的建議是把上一篇的評測心法搬過來：從最小預算開始，跑評測，看數據決定要不要加碼。

為什麼不一開始就給大預算？因為思考 token 是實際計費的，而更多預算並不保證等比例的品質提升。評測會告訴你邊際效益在哪裡停下來：當預算加大而準確度沒有明顯進步，就是收手的時候。

搭配 tool use：回應處理要升級

chat 函式裡本來就有 tools 參數，thinking 與工具是可以同時掛上的。但要注意，這時回應的結構會更豐富：一次回應裡可能同時出現 thinking 區塊、工具呼叫區塊與文字區塊。你的程式不能再假設「回應就是一段文字」，而要逐一檢查每個區塊的型別，分別處理。

實務上常見的寫法，是用一個迴圈逐一巡訪回應的內容清單，依區塊型別分流：thinking 收進對話紀錄、工具呼叫觸發對應的工具執行、text 呈現給使用者。結構雖然變複雜，但這段分流邏輯寫一次就能在整個應用裡重用。

另外有一條跟多輪對話有關的紀律：thinking 區塊要原封不動地傳回。上一篇提過，thinking 區塊帶有 signature，用來驗證思考文字沒被修改。在工具使用的流程裡，你會把模型的回應加回訊息串、附上工具結果再送一輪，這時千萬別動 thinking 區塊的內容，改了就會破壞驗證。

redacted thinking 也要接得住

當思考內容被內部安全系統標記時，你收到的不是可讀的推理文字，而是加密的 redacted thinking 區塊。對應用程式來說，這必須是正常路徑而不是當機點：照樣把完整訊息傳回後續對話，脈絡不會遺失。

有個貼心的測試手段：送出一個特殊的觸發字串，就能強迫 Claude 回傳 redacted thinking 區塊。把它寫進你的測試，確保程式在遇到加密區塊時能優雅地處理，而不是直接掛掉。

上線前的相容性檢查

最後一關是相容性。extended thinking 與部分功能不相容，最常撞到的是預先填寫回應開頭與 temperature 調整。如果你的程式原本依賴這些技巧，開啟 thinking 前要先把它們拿掉或改寫。完整的限制清單以官方文件為準。

這一步很容易被忽略，因為錯誤往往到整合階段才浮現：單獨測 thinking 沒事、單獨測舊功能也沒事，合在一起才出問題。把相容性檢查寫進上線清單，比事後除錯便宜得多。

照這份清單走完，extended thinking 就能安全地進到你的正式環境：該想的時候讓模型想，成本與品質的平衡則始終握在你的評測數據手上。