引導思考

Claude 的思考是自適應的：模型會評估每個請求，並自行決定是否要思考以及思考多少。您設定意圖，可選擇性地指定 effort（投入程度），模型便會在它判斷推理有幫助的地方分配推理資源。

這使得思考非常適合混合了簡單與複雜請求的工作負載，也適合長時程的代理式工作流程，因為在這類流程中，每一步所需的適當推理量各不相同。

若要了解如何開啟思考、如何讀取思考輸出，以及關於 Claude Fable 5 與 Claude Mythos 5 上的思考輸出，請參閱思考總覽。本頁涵蓋 Claude 如何決定何時思考、如何引導該決定，以及由此衍生的快取、成本與定價機制。

Claude 如何決定何時思考

對模型而言，思考是可選的。在每個請求中，Claude 會衡量輸入的複雜度，並決定更深入的推理是否能改善答案。一個簡單的事實性問題可能會得到直接回應，完全沒有思考區塊；而一個多步驟的數學問題或棘手的除錯任務則會觸發更深入的推理。

這個決定是逐請求進行的。同一段對話中可以同時包含有思考與沒有思考的回合，而 Claude 選擇不思考的回合不會包含思考區塊。請勿建構假設每個助理回合都以思考區塊開頭的應用程式邏輯。

對此決定的主要控制項是 effort 參數，它作為軟性指引，決定 Claude 應該多願意思考以及思考多深；請參閱本頁的 Effort 等級以了解各等級的作用。

如果您希望 Claude 較少思考，請先降低 effort 等級，再考慮使用基於提示的引導。

思考也會自動與「tool use」（工具使用）交錯進行：Claude 可以在工具呼叫之間思考，在決定下一步之前反思每個工具結果（交錯思考）。您不需要 beta 標頭或任何額外設定即可使用此功能。

若要完整了解思考設定與 effort 參數如何互動，請參閱思考與 effort。

引導 Claude 思考的頻率

Claude 是否在特定回合思考是可以透過提示影響的。Effort 設定整體姿態，但您也可以透過自然語言指引直接塑造該決定，無論是在「system prompt」（系統提示）中全域設定，或是從使用者回合逐則訊息設定。

請依以下順序搭配使用這兩個控制桿：

1. 設定符合您工作負載在品質與延遲之間預設平衡的 effort 等級。
2. 只有當 Claude 在該等級下的觸發行為仍不符合您的需求時，才加入提示指引。

若要了解搭配思考的更廣泛提示指引，請參閱善用思考與交錯思考能力。

Effort 等級

Effort 是思考的主要引導控制桿。每個等級為 Claude 思考的頻率與深度設定不同的預設值：

此表格描述每個等級如何改變思考行為。若要了解針對特定工作負載應選擇哪個等級的指引（包括各模型的建議），請參閱 effort 頁面上的何時調整 effort 參數。

Effort 設定於 output_config.effort，而非 thinking 物件內；若要查看各語言的完整範例，請參閱 Effort。

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

等級的可用性因模型而異；effort 頁面上的 effort 可用性表格是各模型支援哪些等級的權威依據。

系統提示指引

系統提示指引會改變對話中每個請求的 Claude 思考門檻。如果 Claude 思考的頻率高於您工作負載所需，請在系統提示中加入如下指引：

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

若要反過來鼓勵思考，請使用如下語句：

This task involves multistep reasoning. Think carefully before responding.

引導的效果可能對確切措辭很敏感。如果某種說法無法產生您想要的行為，請嘗試更直接的變體。

逐則訊息引導

您也可以從使用者回合逐則訊息地引導思考，獨立於系統提示之外。在使用者訊息後附加 "Please think hard before responding." 會鼓勵 Claude 在該回合思考；"Answer directly without deliberating." 則會抑制思考。

當對話中只有部分請求需要延伸推理時，逐則訊息引導非常有用。例如，代理框架可以在規劃步驟附加鼓勵語句，在例行確認時附加抑制語句，而無需更動系統提示或在回合之間變更任何請求參數。

在您的工作負載上驗證引導效果

基於提示的引導會改變模型行為，因此請像對待任何其他提示變更一樣對待它：在上線前先進行量測。以具代表性的流量樣本分別在有與沒有該指引的情況下執行，並比較思考觸發的頻率（回應中是否出現思考區塊）、輸出 token 用量、延遲，以及在您關心的案例上的答案品質。

機制

由 Claude 自行管理思考衍生出三項機制：回合驗證、提示快取，以及您如何限制成本。

回合驗證

助理回合不需要以思考區塊開頭。（使用舊版手動思考預算的模型會強制要求啟用思考之請求的最後一個助理回合以思考區塊開頭；請參閱手動模式下的回合結構。）

對於多回合應用程式，這表示您可以用手邊現有的任何形式傳回對話歷史：

• Claude 選擇不思考的助理回合，原樣即為有效的歷史。
• 您可以恢復一段起初沒有思考、或使用了不同思考設定的對話，而無需重寫其歷史。
• 從混合來源組裝的歷史不需要在每個助理回合開頭重新插入思考區塊即可通過驗證。

此放寬是關於驗證，而非關於您應該傳送什麼。當您擁有思考區塊時，請原封不動地傳回它們，特別是在工具使用期間，因為它們承載了 Claude 工具呼叫背後的推理。完整規則請參閱思考總覽。

提示快取

保持相同思考設定與 effort 等級的連續請求會保留「prompt caching」（提示快取）；完整規則請參閱思考與提示快取。解析後的 effort 值會被渲染到提示中，因此在請求之間變更它會使快取斷點失效，就如同在使用舊版 budget_tokens 參數的模型上變更該參數一樣。將 effort 明確設定為模型的預設值等同於省略它，不會破壞快取。

實務上的結果是：為每段對話選定一個思考設定與一個 effort 等級並維持不變。如果某些回合需要更多或更少的思考，請使用逐則訊息提示來引導：附加在最新使用者訊息上的指引會讓先前的快取斷點保持完整，而設定或 effort 的變更則不會。

以下範例透過一個您可以自行執行的多回合腳本來示範此失效情形：

import requests

client = Anthropic()


def fetch_article_content(url):
    text = requests.get(url).text
    lines = (line.strip() for line in text.splitlines())
    return "\n".join(line for line in lines if line)


# 擷取文章內容
book_url = "https://www.gutenberg.org/cache/epub/1342/pg1342.txt"
book_content = fetch_article_content(book_url)
# 僅使用足夠用於快取的文字（前幾章）
LARGE_TEXT = book_content[:10000]

# 不使用系統提示 - 改為在訊息中進行快取
MESSAGES = [
    {
        "role": "user",
        "content": [
            {
                "type": "text",
                "text": LARGE_TEXT,
                "cache_control": {"type": "ephemeral"},
            },
            {"type": "text", "text": "Analyze the tone of this passage."},
        ],
    }
]

# 第一次請求 - 建立快取
print("First request - establishing cache")
response1 = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    messages=MESSAGES,
)

print(f"First response usage: {response1.usage}")

MESSAGES.append({"role": "assistant", "content": response1.content})
MESSAGES.append({"role": "user", "content": "Analyze the characters in this passage."})

# 第二次請求 - 相同設定（預期快取命中）
print("\nSecond request - same configuration (cache hit expected)")
response2 = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    messages=MESSAGES,
)

print(f"Second response usage: {response2.usage}")

MESSAGES.append({"role": "assistant", "content": response2.content})
MESSAGES.append({"role": "user", "content": "Analyze the setting in this passage."})

# 第三次請求 - 不同的 effort 等級（預期快取未命中）
print("\nThird request - different effort level (cache miss expected)")
response3 = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},
    messages=MESSAGES,
)

print(f"Third response usage: {response3.usage}")

First request - establishing cache
First response usage: { cache_creation_input_tokens: 3546, cache_read_input_tokens: 0, input_tokens: 15, output_tokens: 1033 }

Second request - same configuration (cache hit expected)
Second response usage: { cache_creation_input_tokens: 0, cache_read_input_tokens: 3546, input_tokens: 1062, output_tokens: 1630 }

Third request - different effort level (cache miss expected)
Third response usage: { cache_creation_input_tokens: 3546, cache_read_input_tokens: 0, input_tokens: 2706, output_tokens: 1468 }

成本控制

您不需要設定思考 token 預算。有兩個控制項可限制成本：

• max_tokens 是該請求總輸出的硬性上限，思考與回應文字合計。Claude 絕不會產生超過它的內容。在工具使用迴圈中，回合內的每個請求都有自己的 max_tokens，因此它不會限制整個回合的花費。
• effort 是關於 Claude 將多少輸出分配給思考的軟性指引。它會塑造行為，但不保證 token 數量。

由於思考會計入 max_tokens，請將其設定得夠高，以便為推理與答案都留出空間。為沒有思考的回應所設定的 max_tokens，一旦 Claude 開始在困難請求上思考，往往就會太小。

在 high 及以上的 effort 等級，Claude 可能會大量思考，也更可能耗盡預算。如果您在回應中看到 stop_reason: "max_tokens"，您有兩種補救方式：

• 提高 max_tokens，為模型的思考加上答案提供更多空間。
• 降低 effort 等級，讓 Claude 較少思考，並將更多預算留給回應文字。

哪一種才正確，取決於被截斷的回應是否需要該推理。如果這些請求的品質很重要，請提高上限；如果它們被過度思考了，請降低 effort。

定價

思考會產生以下費用：

• Claude 思考時使用的 token（以輸出 token 計費）
• 依據保留預設值而留在上下文中的先前助理回合思考區塊：在全部保留的模型上預設為所有回合，其他模型則僅為最後一個回合（以輸入 token 計費）
• 標準文字輸出 token

無論 display 設定為何，您被計費的內容都相同；只有您看到的內容會改變：

若要查看有多少計費輸出 token 花費在內部推理上，請讀取回應中的 usage.output_tokens_details.thinking_tokens。此值反映模型產生的原始推理（而非主體中回傳的摘要文字），且一律小於或等於 output_tokens。將其從 output_tokens 中減去，即可估算輸出中非推理的部分。在「streaming」（串流）時，此細項僅出現在最後的 message_delta 事件中。

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

output_tokens 仍是用於計費的包含性權威總數。output_tokens_details 是供可觀測性使用的唯讀細項。若要了解完整的定價資訊，包括基本費率、快取寫入、快取命中與輸出 token，請參閱定價。

後續步驟