「Thinking mode」(亦稱為extended thinking、thinking或thinking blocks)在 Claude 4.5 中是一種顯式、可配置的運作模式,指示模型在輸出最終答案之前,使用單獨預算的 token 生成內部的、逐步的推理(「chain-of-thought」)。它旨在以延遲與 token 成本為代價,換取更深入的內部思考,以提升多步推理、複雜程式設計與代理型工作流程,以及研究任務的表現。Claude 4.5 在 Messages API 層面以顯式參數提供此能力(例如 thinking / budget_tokens 或 effort/「interleaved-thinking」標頭),能保存並選擇性加密思考區塊以供後續驗證或工具使用,並引入需要在生產工作負載中管理的快取與 token 核算行為。
什麼是 Claude 4.5?(我該關注哪些模型?)
Claude 4.5 是 Anthropic 最新發布的 Claude 模型套件,以「4.5」的增量更新形式推出(例如Sonnet 4.5與Opus 4.5)。Sonnet 4.5 被定位為在智慧、程式設計與代理型表現之間取得最佳平衡,適合多數開發者;Opus 4.5 則著重於高強度推理,並保留思考區塊以改善多輪連續性。兩者皆支援 Claude 的延伸思考能力,但部分行為(例如摘要版與完整版思考)會因模型而異。
Claude 4.5 的效能提升,尤其在 Sonnet 4.5 上,於 SWE-bench Verified 基準測試中最為明顯,該測試衡量 AI 解決真實 GitHub 問題的能力。
| 模型 | SWE-bench Verified 分數 | OSWorld(電腦使用) |
|---|---|---|
| Claude 3.5 Sonnet | 49.0% | 42.2% |
| Claude 4.1 Opus | 67.6% | 55.0% |
| Claude 4.5 Sonnet (啟用思考) | 77.2% | 61.4% |
| GPT-5 (中等推理) | 65.0% | 52.0% |
這些數字表明,Claude 4.5 不僅更擅長撰寫程式片段;它在導覽整個檔案系統與無需人為介入下執行自主任務方面也顯著更有能力。
為何這很重要
- 程式設計與代理:Sonnet 4.5 在真實世界的軟體任務與長期程式設計工作上展現強勢提升——使其成為程式碼生成、程式碼編輯與自主代理流程的自然之選。
- 延伸思考與上下文:Claude 4.5 系列模型能以非常大的內部草稿區(數萬 token 以上)進行推理,促成更深入的多步推理。這改變了你設計提示、token 預算與工具互動的方式。
什麼是 Claude 4.5 的思考模式?
思考模式(正式稱為「Extended Thinking」)是一項能力,允許模型在提供最終輸出之前,先對自身「展示解題過程」。有別於標準模型立即做出答案承諾,Claude 4.5 使用專屬的推理空間來探索多種假設、識別邏輯上的潛在錯誤並精煉策略。
回應的構成
在標準互動中,模型接收提示並開始生成答案。在思考模式下,回應會分成兩個不同的區塊:
| 區塊類型 | 可見性 | 用途 |
|---|---|---|
| Thinking Block | 隱藏(透過 API)或收合(UI) | 模型的內部獨白、規劃與自我批判。 |
| Text Block | 可見 | 提供給使用者的最終、精煉答案。 |
思考模式的關鍵屬性
- 依請求啟用:你在 API 呼叫中傳入
thinking物件,例如{"type":"enabled","budget_tokens":10000}以開啟並為模型的內部推理提供 token 預算。 - 預算控管:
budget_tokens會為模型的內部推理 token 設定上限。更高的預算 => 更深入的推理潛力,但成本與延遲更高。在 Claude 4 模型中,即便你只收到摘要視圖,也會為思考 token 計費。 - 摘要與遮蔽:許多 Claude 4 模型使用者會看到思考內容的摘要版本;部分內部推理可能會由安全系統遮蔽(加密),並以
redacted_thinking回傳。 - 簽名與驗證:思考區塊包含不透明的
signature,在將思考區塊回傳至 API(尤其使用工具時)用於驗證。你應將此簽名視為不透明——不應嘗試解析。 - 與工具交錯思考:Claude 4 支援將思考區塊與工具執行交錯(在部分情況屬於 beta 且需旗標)。這對代理型工作非常強大(執行工具、思考、再執行工具,等等)。
欲獲得實作示例與最新參數,請參考 Anthropic 的 Messages/Extended Thinking 文件,該文件是正典參考。
Messages API 如何回傳思考內容
摘要版與完整版思考;加密與簽名
不同版本的 Claude 模型對思考的處理方式不一:較新的 Claude 4 模型(如 Sonnet/Opus 4.5)通常回傳摘要的公開視圖,而完整的草稿可能會被加密,僅能透過 signature 欄位(或遮蔽區塊)取得。當使用工具時(或需要跨工具呼叫保留內部狀態),你必須在回傳至 API 時附上思考區塊或使用文件描述的簽名機制。此機制有助於保護敏感的內部推理,同時在需要時允許安全地延續同一思考過程。
實務處理模式
工具使用/延續:如果你的下一個請求必須延續相同的內部狀態(例如,工具依據該思考執行過程),請在下一次呼叫 API 時包含回傳的思考區塊或簽名,以便模型解密並從中斷處繼續。
請求:傳送 thinking: {type: "enabled", budget_tokens: N}。
回應:你可能會收到 (a) 思考內容的公開摘要、(b) 加密的 signature 或 redacted_thinking 區塊,或 (c) 二者皆有。
CometAPI 以官方 API 價格的 20% 提供 Claude 4.5 API,並且可以使用 Anthropic Messages 呼叫。開始前你需要取得 API 金鑰。
範例 1 — 簡單的 curl(非串流)啟用思考
curl https://api.cometapi.com/v1/messages \
-H "x-api-key: $CometAPI_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-4-5",
"max_tokens": 16000,
"thinking": {
"type": "enabled",
"budget_tokens": 10000
},
"messages": [
{"role": "user", "content": "Design a robust data validation strategy for CSV imports, show tests + code."}
]
}'
回應會包含 content 區塊。檢視每個區塊並優先使用 text 區塊作為最終輸出;thinking 區塊包含模型的內部分析摘要。
範例 2 — Python:請求、解析思考與文字區塊
import os, requests
API_KEY = os.environ["CometAPI_API_KEY"]
URL = "https://api.cometapi.com/v1/messages"
HEADERS = {
"x-api-key": API_KEY,
"anthropic-version": "2023-06-01",
"content-type": "application/json"
}
payload = {
"model": "claude-sonnet-4-5",
"max_tokens": 16000,
"thinking": {"type": "enabled", "budget_tokens": 8000},
"messages": [{"role": "user", "content": "Explain how to do property-based testing in Python; include example code."}]
}
r = requests.post(URL, headers=HEADERS, json=payload)
r.raise_for_status()
resp = r.json()
# Parse blocks
for block in resp.get("content", []):
if block.get("type") == "thinking":
thinking_summary = block.get("thinking")
print("=== THINKING (summary) ===")
print(thinking_summary[:1000]) # truncate for logs
print("signature:", block.get("signature")[:64], "...")
elif block.get("type") == "text":
print("=== FINAL TEXT ===")
print(block.get("text"))
此程式碼會擷取並印出思考摘要與最終答案。如果你需要在多輪代理流程中保留連續性,請在下一次請求的 messages 陣列中包含未修改的思考區塊(見下一個範例)。
範例 3 — 在多輪流程中重用思考區塊(Python 偽代碼)
# After initial response (resp above):
# Add the assistant message including the thinking block back into the conversation
assistant_message = {
"role": "assistant",
"content": resp["content"] # include raw content array (contains thinking + text blocks)
}
# Next user turn: ask follow-up and include previous assistant message
payload2 = {
"model": "claude-opus-4-5", # Opus preserves thinking blocks better across turns
"max_tokens": 20000,
"thinking": {"type": "enabled", "budget_tokens": 12000},
"messages": [
{"role": "user", "content": "Now adapt the validation logic for an avro pipeline."},
assistant_message
]
}
r2 = requests.post(URL, headers=HEADERS, json=payload2)
在進行工具整合或長時代理工作流程時,保留完全未修改的思考區塊至關重要。Opus 4.5 在思考區塊的保留與快取方面具有更佳預設行為。
如何串流思考輸出並在 UI 中顯示進度?
串流最佳實務
- 使用 SDK 串流端點(Python/TypeScript SDK 有串流輔助器)。對於長時間或高預算推理任務,串流可避免 HTTP 逾時,並在模型計算時提供部分文字。典型程式碼會使用對
text_stream的疊代器(Python)或事件解析(JS)。 - 預期有時會出現雙階段串流:模型可能先產生可見的推理片段,然後再完成最終答案。建構你的 UI 以處理分段內容,並顯示「thinking…」與最終答案的狀態。
- 若 API 在串流時回傳
signature_delta或content_block_delta,請捕捉並按規範附加至後續呼叫。
若你需要在 UI 中顯示中途的推理進度,請串流回應。伺服器會先發出 thinking_delta 事件,接著是 text_delta 事件。
curl https://api.cometapi.com/v1/messages \
--header "x-api-key: $CometAPI_API_KEY" \
--header "anthropic-version: 2023-06-01" \
--header "content-type: application/json" \
--data '{
"model": "claude-sonnet-4-5",
"max_tokens": 16000,
"stream": true,
"thinking": { "type": "enabled", "budget_tokens": 8000 },
"messages": [ { "role": "user", "content": "Walk me through debugging this failing unit test and propose fixes." } ]
}'
在串流時,依序處理 content_block_start、content_block_delta(內含 thinking_delta 與 text_delta)以及 content_block_stop 事件。透過此方式,你可以在模型推理的過程中即時顯示其逐步思考。
Claude Code 與思考模式如何互動?(terminal + VS Code)
Claude Code 是互動式、代理型的程式設計終端機,整合了 Messages API 與工具執行器。CLI/IDE 體驗以兩種方式呈現思考:
- 全域/每次會話設定:Claude Code 透過
/config設定面板來調整行為(代理的許可請求方式、是否保留思考區塊等)。若你想要持續的行為改變,請使用該 UI,而非重複輸入原始 JSON。 - 模型選擇與 CLI 指令:你可以在 REPL 中選擇
claude-sonnet-4-5或claude-opus-4-5作為使用中的模型;工具與思考行為會遵循 Messages API 的語意。CHANGELOG 與發行說明指出,在某些 Opus 4.5 部署中,思考功能現已預設啟用,且思考設定可透過/config呈現。
Claude Code 的實務流程:
- 在 REPL 中啟動專案。
- 使用
/config檢視與思考相關的旗標(保留、冗長度等)。 - 要求代理執行長任務——它會產生思考內容,且如有需要,會請求執行特定 bash 步驟的許可。當你需要驗證或重跑決策時,請保留思考區塊。
安裝與設定
Claude Code 需要 Node.js,並可全域安裝。
# Install Claude Code CLI
npm install -g @anthropic/claude-code
# Authenticate
claude-code --init
在終端機中啟用思考
Claude Code 支援多種旗標與自然語言觸發來控制其推理深度。
| 指令/觸發 | 說明 |
|---|---|
| claude-code --think | 以預設啟用延伸思考啟動一個會話。 |
| claude-code --model sonnet-4.5 | 指定最新的前沿模型。 |
| /think | CLI 內的斜線指令,用於啟動特定高思考需求的任務。 |
| "ultrathink" | 自然語言關鍵字,指示 Claude 使用最大可能的推理預算。 |
提示:
- 當你希望代理探索替代實作時,使用「think/think harder」。
- 當 Claude Code 執行工具呼叫(跑測試、git 操作)時,若 CLI/代理回傳了
thinking區塊,請予以保留;否則代理可能在步驟之間失去上下文。
交錯思考與區塊保留的好處
對於進階的代理型工作流程,Claude 4.5 引入了兩項顯著增強多輪互動與工具使用的 Beta 功能:交錯式思考與思考區塊保留。
交錯式思考(Beta)
標準推理通常在輸出前發生一次。交錯式思考(透過 interleaved-thinking-2025-05-14 標頭啟用)允許 Claude 在工具呼叫之間進行「思考」。
想像 Claude 在除錯伺服器:
- 思考:「我應該先檢查日誌。」
- 工具呼叫:
read_file(logs.txt) - 思考:「日誌顯示資料庫逾時。現在我需要檢查連線池設定。」
- 工具呼叫:
read_file(db_config.yml)
這種「持續反思」確保模型能依據工具回傳的資料調整策略,而非遵循僵化的預先計劃。
思考區塊保留
在多輪對話中,尤其涉及工具使用時,將先前的 thinking 區塊回傳至 API 極為重要。
- 推理連續性:藉由接收先前的思考,Claude 能維持其推理旅程的邏輯上下文。
- Opus 4.5 最佳化:在 Claude Opus 4.5 中,此行為已自動化。模型會預設在上下文中保留所有先前的思考區塊,即使是在長達 30+ 小時的會話中,也能確保模型不會「忘記」它在十多輪之前所做的架構決策的理由。
使用思考模式(THINKING)與 Claude 4.5 的最佳實踐
為任務選擇合適的模型與預算:
對需要在速度、成本與強大程式能力間取得最佳權衡的程式設計與代理型工作流程,使用 Sonnet 4.5;當你需要最深度的推理、最大上下文視窗或規劃長時間自主會話時,使用 Opus 4.5。兩者都支援延伸思考。請依任務複雜度設定 budget_tokens(實驗時從小開始;僅在觀察到品質明顯提升時提高預算)。
監控與控制成本與延遲
你會為 Claude 產生的完整思考 token 付費,而非你收到的摘要輸出。這表示冗長的內部思考會增加成本,即便你只看到短摘要。請追蹤 token 使用量,並在從探索到生產的過程中采用逐步調整(例如:2k → 8k → 32k)。
僅在必要時保留思考區塊
思考區塊可進行密碼學簽名並保留,以供後續驗證與交錯工具使用。除非工作流程要求模型保留先前的內部推理(例如代理會重跑步驟且需要保留的理由),否則避免在每次後續請求中回傳思考區塊。持續保留思考會增加上下文體積,並使 token 核算更複雜。
何時將思考串流給使用者
串流思考非常適合開發者工具與教育型 UI(在模型思考時顯示「進行中」)。在面向消費者的生產應用中,未經安全與遮蔽考量請勿直接串流原始思考:摘要版思考正是為此而設計。若要串流,請在 UI 中明確標示內部推理(例如「助理推理——內部」),並控制最終使用者看到摘要或完整推理。
工具使用與交錯
當你將思考與工具結合(程式執行、網路擷取、本機程序),在需要模型於同一輪選擇工具、執行並根據結果推理的情境下,使用交錯式思考設計。交錯會提高複雜度(可能需要功能旗標),但對代理型自動化非常強大。請明確你保留哪些思考,並測試模型在啟用思考的情況下如何選擇工具。
實務疑難排解與營運注意事項
常見錯誤與含義
- 無效的思考 + 強制工具選擇:若你請求思考但同時強制使用特定與思考不相容的工具模式,API 會回傳錯誤——請勿將
tool_choice: {"type":"tool","name":"..."}與思考混用。 - 預算 > max_tokens:對交錯式思考情境,有效的 token 規則有所不同——平台文件解釋了何時
budget_tokens可超過max_tokens。在測試大型預算前,請仔細閱讀「交錯式思考」章節。 - 簽名驗證:若你保留思考區塊以供後續呼叫,請包含回傳的
signature,使 API 能驗證其確為 Claude 所生成;此舉可防止竄改並維持可驗證的鏈。
可觀測性與儀表化
記錄:(1)model 選擇、(2)thinking.budget_tokens、(3)實際思考 token 消耗(你會為此計費)、(4)串流延遲(首次 thinking_delta 的時間)、以及(5)最終文字 token。使用這些指標為面向使用者的流程建立預算與 SLO。
漸進式發布與人類審查
在功能旗標後推出啟用思考的模型。先從一部分開發者或內部流量開始,收集失敗或遮蔽案例,並迭代提示與預算。對敏感領域,在包含大量內部推理的輸出發布前要求人工審查。
除錯提示
- 從小開始:先啟用較低的
budget_tokens,再逐步擴大以理解增量改善。 - 開啟串流並記錄
content_block_delta/簽名事件,以理解模型何時產生思考區塊。 - 若使用 Claude Code:檢查
/config與專案層級設定;若行為與預期預設不符,請參考 Claude Code 的變更記錄。
結論:
結合延伸思考與 Claude Code CLI 的 Claude 4.5,代表了自 IDE 發明以來開發者生產力的最大飛躍。透過允許模型「展示解題過程」並對複雜問題進行審慎思考,Anthropic 已從「聊天機器人」時代邁向「代理」時代。
無論你是將 Messages API 整合到自訂開發工具,或使用 Claude Code 管理每日的 PR,掌握思考模式至關重要。它提供建立信任所需的透明度,以及追求卓越所需的推理深度。
開發者可透過 CometAPI 存取 Claude 4.5(Claude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.5)模型。開始前,請在 CometAPI 的 Playground 探索模型能力,並參考 API 指南取得詳細說明。在存取前,請確保你已登入 CometAPI 並取得 API 金鑰。CometAPI 提供遠低於官方價格的方案,以協助你整合。
準備好了嗎?→ Claude 4.5 免費試用!
