Как использовать режим мышления в Claude 4.5

Claude 4.5 中的“Thinking mode”（也称为 extended thinking、thinking 或 thinking blocks）是一种显式、可配置的运行模式，它会指示模型在输出最终答案之前，先使用一部分单独预算的 token 生成内部的、逐步展开的推理（即 “chain-of-thought”）。它旨在通过以更高的延迟和 token 成本换取更深入的内部推敲，从而提升模型在多步推理、复杂编码与 agent 工作流以及研究任务中的表现。Claude 4.5 在 Messages API 层面公开了这一能力，并提供了明确参数（例如 thinking / budget_tokens 或 effort / “interleaved-thinking” header）；同时它还会保留并可选地加密 thinking blocks，以便后续验证或工具调用，并引入了你在构建生产级工作负载时必须管理的缓存与 token 计费行为。

什么是 Claude 4.5？（以及我应该关注哪些模型？）

Claude 4.5 是 Anthropic 最新一代 Claude 模型的增量“4.5”版本更新（例如 Sonnet 4.5 和 Opus 4.5）。Sonnet 4.5 被定位为对大多数开发者而言，在智能性、编码能力和 agent 能力之间最均衡的选择；Opus 4.5 则专注于高强度推理，并保留 thinking blocks 以提升多轮交互的连续性。两者都支持 Claude 的 extended thinking 能力，不过某些行为（例如摘要式 thinking 与完整 thinking）会因模型而异。

Claude 4.5 的性能提升，尤其是 Sonnet 4.5，在 SWE-bench Verified 基准测试中最为明显。该基准用于衡量 AI 解决真实世界 GitHub issue 的能力。

这些数字表明，Claude 4.5 不只是更擅长写代码片段；它在遍历整个文件系统并自主执行任务方面也显著更强，无需人工干预。

为什么这很重要

• 编码与 agents： Sonnet 4.5 在真实软件任务和长时程编码工作上有明显提升——使其成为代码生成、代码编辑和自主 agent 流程的自然选择。
• Extended thinking 与上下文： Claude 4.5 系列模型能够使用非常大的内部草稿空间进行推理（可达数万 token 或更多），从而实现更深入的多步推理。这会改变你设计 prompt、token 预算和工具交互的方式。

Claude 4.5 中的 Thinking Mode 是什么？

Thinking Mode（官方称为 “Extended Thinking”）是一项能力，它允许模型在输出最终结果之前，先“给自己展示推理过程”。不同于标准模型会立即给出答案，Claude 4.5 会使用一个专门的推理空间来探索多个假设、识别其逻辑中的潜在错误，并优化其策略。

响应结构解析

在标准交互中，模型接收 prompt 后会直接开始生成答案。而在 Thinking Mode 中，响应会分为两个不同的 block：

Thinking mode 的关键属性

• 按需启用：你可以在 API 调用中传入 thinking 对象，例如 {"type":"enabled","budget_tokens":10000}，来启用该模式并为模型分配内部推理 token 预算。
• 预算控制：budget_tokens 会限制模型内部推理使用的 token 数量。预算越高 => 推理可能越深入，但成本和延迟也越高。在 Claude 4 模型中，即使你只收到摘要形式的 thinking，thinking token 仍然会被计费。
• 摘要与脱敏：对于许多 Claude 4 模型，用户看到的是 thinking 内容的摘要版；某些内部推理可能会被安全系统脱敏（加密），并以 redacted_thinking 的形式返回。
• 签名与验证：Thinking blocks 包含一个不透明的 signature，在将 thinking blocks 返回给 API 时可用于验证（尤其是与工具结合使用时需要）。你应将该签名视为不透明数据——不要尝试解析它。
• 与工具的交错 thinking：Claude 4 支持在工具执行之间插入 thinking blocks（某些情况下为 beta 功能并需通过 flag 启用）。这对 agent 场景非常强大（运行工具、思考、再运行另一个工具，依此类推）。

如需获取实际示例和最新参数，Anthropic 的 Messages / Extended Thinking 文档是最权威的参考资料。

Messages API 如何返回 thinking 内容

摘要 thinking 与完整 thinking；加密与签名

不同版本的 Claude 模型对 thinking 的处理方式不同：较新的 Claude 4 模型（如 Sonnet / Opus 4.5）通常会返回内部推理的摘要式公开视图，而完整草稿可能会被加密，并仅通过 signature 字段（或 redacted blocks）提供。当使用工具时（或者你需要在工具调用之间保留内部状态），你必须将 thinking blocks 传回 API，或者使用文档中描述的签名机制。该机制既能保护敏感的内部推理，也能在需要时安全地延续当前思路。

实际处理模式

工具使用 / 连续推理：如果下一次请求需要延续相同的内部状态（例如工具是基于 thinking 运行的），那么在再次调用 API 时，请包含返回的 thinking block 或 signature，以便模型解密并从上次中断的地方继续。

请求：发送 thinking: {type: "enabled", budget_tokens: N}。

响应：你可能会收到 (a) 一个公开摘要输出，(b) 一个加密的 signature 或 redacted_thinking block，或 (c) 两者都有。

CometAPI 以官方 API 价格的 20% 提供 Claude 4.5 API，并且也支持通过 Anthropic Messages 方式调用。在开始之前，你需要先获取 API key。

示例 1 —— 启用 thinking 的简单 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 blocks。请检查每个 block，并优先使用 text blocks 作为最终输出；thinking blocks 则包含模型内部分析的摘要。

示例 2 —— Python：请求、解析 thinking 和 text blocks

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"))

这段代码会提取并打印摘要式 thinking 和最终答案。如果你需要在多轮 agent 流程中保持连续性，请将未修改的 thinking blocks 包含到下一次请求的 messages 数组中（见下一个示例）。

示例 3 —— 在多轮流程中复用 thinking blocks（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)

在执行工具集成流程或长链路 agent 工作流时，精确保留原样、未经修改的 thinking blocks 至关重要。Opus 4.5 在 thinking block 保留和缓存方面有更好的默认行为。

如何流式传输 thinking 输出并在 UI 中显示进度？

流式传输最佳实践

• 使用 SDK 的流式接口（Python / TypeScript SDK 都提供 stream helper）。对于长时间运行或高预算推理任务，流式返回可以避免 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 如何与 thinking mode 交互？（终端 + VS Code）

Claude Code 是一个交互式、具备 agent 能力的编码终端，它集成了 Messages API 和工具运行器。CLI / IDE 体验主要通过两种方式暴露 thinking 功能：

• 全局 / 会话级设置： Claude Code 提供 /config 设置面板来调整行为（例如 agent 如何请求权限、是否保留 thinking blocks 等）。如果你想进行持久化行为变更，建议使用该 UI，而不是反复手动输入原始 JSON。
• 模型选择与 CLI 命令： 你可以在 REPL 中选择 claude-sonnet-4-5 或 claude-opus-4-5 作为当前模型，工具与 thinking 行为会随之遵循 Messages API 语义。CHANGELOG 和发布说明表明，对于某些 Opus 4.5 部署，thinking 已默认启用，并且相关配置通过 /config 暴露。

Claude Code 中的实际流程：

1. 在 REPL 中启动一个项目。
2. 使用 /config 查看与 thinking 相关的标志位（保留、冗长度等）。
3. 让 agent 执行一个长任务——它会生成 thinking 内容，并在需要时请求权限来运行某些 bash 步骤。当你需要后续验证或重跑决策过程时，请保留 thinking blocks。

安装与设置

Claude Code 需要 Node.js，可全局安装。

# Install Claude Code CLI
npm install -g @anthropic/claude-code

# Authenticate
claude-code --init

在终端中启用 Thinking

Claude Code 支持多种标志和自然语言触发词来控制其推理深度。

提示：

• 当你希望 agent 探索替代实现方案时，使用 think / think harder。
• 当 Claude Code 执行工具调用（运行测试、git 操作）时，如果 CLI / agent 返回了 thinking blocks，请保留它们；否则 agent 可能会在步骤之间丢失上下文。

交错 thinking 与 block 保留的优势

对于高级 agent 工作流，Claude 4.5 引入了两个显著增强多轮交互和工具使用体验的 beta 功能：Interleaved Thinking 和 Thinking Block Preservation。

Interleaved Thinking（Beta）

标准推理只会在输出前发生一次。而 Interleaved Thinking（通过 interleaved-thinking-2025-05-14 header 启用）允许 Claude 在工具调用之间继续“思考”。

设想 Claude 正在调试一个服务器：

1. 思考： “我应该先检查日志。”
2. 工具调用： read_file(logs.txt)
3. 思考： “日志显示数据库超时。现在我需要检查连接池设置。”
4. 工具调用： read_file(db_config.yml)

这种“持续反思”可以确保模型根据从工具获得的数据调整自己的策略，而不是执行一个僵化、预先定义好的计划。

Thinking Block Preservation

在多轮对话中，特别是涉及工具使用时，将之前的 thinking blocks 传回 API 至关重要。

• 推理连续性： 通过接收它之前的想法，Claude 能维持其逻辑路径的上下文。
• Opus 4.5 优化： 在 Claude Opus 4.5 中，这一行为是自动化的。模型默认会在上下文中保留所有先前的 thinking blocks，从而确保即使会话持续 30+ 小时，模型也不会“忘记”它在十轮之前为何做出某项架构决策。

在 Claude 4.5 中使用 THINKING mode 的最佳实践

为任务选择合适的模型与预算：

在编码和 agent 工作流中使用 Sonnet 4.5，当你需要速度、成本和强编码能力之间的最佳平衡时；当你需要最深入的推理、最大的上下文窗口，或计划运行长时间自主会话时，使用 Opus 4.5。两者都支持 extended thinking。请根据任务复杂度按比例设置 budget_tokens（实验阶段从小预算开始；只有在你观察到质量确实提升时再提高预算）。

监控和控制成本与延迟

系统会按 Claude 实际产生的全部 thinking tokens 向你收费，而不是按你看到的摘要内容收费。这意味着，即使你只看到很短的摘要，较长的内部推理仍然会增加成本。请跟踪 token 使用情况，并在从探索转向生产时逐步调优（例如：2k → 8k → 32k）。

仅在必要时保留 thinking blocks

Thinking blocks 可以被加密签名，并为后续验证和交错式工具使用保留。除非你的工作流确实需要模型保留其先前的内部推理（例如 agent 需要重跑某些步骤并使用原始推理依据），否则请避免在每次后续请求中都回传 thinking blocks。始终保留 thinking 会增加上下文体积，并可能使 token 计费更复杂。

何时向用户流式展示 thinking

流式 thinking 非常适合开发者工具和教育类 UI（在模型推理时显示“处理中”）。不要在面向终端消费者的生产应用中直接向最终用户流式展示原始 thinking，除非你已经充分考虑安全性和脱敏需求：摘要式 thinking 存在的原因正是如此。如果你确实要流式展示，请在 UI 中明确标识这是内部推理（例如“Assistant reasoning — internal”），并控制最终用户看到的是摘要版还是完整版推理。

工具使用与交错执行

当把 thinking 与工具（代码执行、网页抓取、本地进程）结合使用时，如果你希望模型能在同一轮中选择工具、运行工具并根据结果继续推理，请使用 interleaved thinking 设计。交错执行会增加复杂度（也可能需要 feature flag），但对于 agent 自动化非常强大。请明确你会保留哪些 thinking，并测试模型在启用 thinking 时如何进行工具选择。

实际排障与运维说明

常见错误及其含义

• Invalid thinking + forced tool choice：如果你请求启用 thinking，同时又强制某种与 thinking 不兼容的工具使用模式，API 会返回错误 —— 不要将强制 tool_choice: {"type":"tool","name":"..."} 与 thinking 混用。
• Budget > max_tokens：在交错式 thinking 场景下，有效 token 规则会有所不同——平台文档解释了在哪些情况下 budget_tokens 可以超过 max_tokens。在测试大预算之前，请仔细阅读“interleaved thinking”部分。
• Signature validation：如果你为了后续调用而保留 thinking blocks，请附带返回的 signature，以便 API 验证这些内容确实来自 Claude；这可防止篡改，并保持链路可验证。

可观测性与埋点

建议记录以下内容：(1) model 选择，(2) thinking.budget_tokens，(3) 实际 thinking token 消耗（这是会计费的），(4) 流式延迟（首次收到 thinking_delta 的时间），以及 (5) 最终文本 token 数。使用这些指标来建立预算模型和面向用户流程的 SLO。

渐进式发布与人工审核

请通过 feature flag 逐步上线启用 thinking 的模型。先在一部分开发者流量或内部流量中使用，收集失败案例或脱敏情况，再迭代 prompt 和预算。对于敏感领域，请在人类审核通过后再发布包含大量内部推理的输出。

调试建议

• 从小开始：先启用较低的 budget_tokens，再逐步提高，以了解质量提升是否具有实际价值。
• 打开流式输出，并记录 content_block_delta / signature 事件，以了解模型何时生成 thinking blocks。
• 如果你在使用 Claude Code：请检查 /config 和项目级设置；如果行为与预期默认值不一致，请查看 Claude Code 的 changelog。

总结：

Claude 4.5，结合 Extended Thinking 与 Claude Code CLI 的能力，代表了自 IDE 发明以来开发者生产力最重要的一次飞跃。通过让模型“展示其工作过程”并对复杂问题进行审慎推敲，Anthropic 已经超越“聊天机器人”时代，迈入了“agent”时代。

无论你是在将 Messages API 集成到自定义开发工具中，还是使用 Claude Code 管理日常 PR，掌握 Thinking Mode 都至关重要。它既提供了建立信任所需的透明度，也提供了追求卓越所需的推理深度。

开发者可以通过 CometAPI 访问 Claude 4.5（Claude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.5）模型。要开始使用，请前往 CometAPI 的 Playground 探索模型能力，并查阅 API 指南获取详细说明。在访问之前，请确保你已经登录 CometAPI 并获取了 API key。CometAPI 提供远低于官方价格的定价，以帮助你完成集成。

准备开始了吗？→ 免费试用 Claude 4.5！