Cómo usar el modo de pensamiento en claude 4.5

Claude 4.5 中的“Thinking mode”（也称为 extended thinking、thinking 或 thinking blocks）是一种显式、可配置的运行模式，它会指示模型在输出最终答案之前，先使用单独预算的一定数量 token 生成内部的、逐步的推理过程（即“chain-of-thought”）。它旨在通过以更高的延迟和 token 成本换取更深入的内部审慎思考，从而提升模型在多步推理、复杂编码与代理式工作流以及研究任务中的表现。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 被定位为对大多数开发者而言，在智能性、编码能力和代理式表现之间最均衡的选择；Opus 4.5 则更侧重于高强度推理，并会保留 thinking blocks 以改善多轮连续性。这两个模型都支持 Claude 的 extended thinking 能力，不过某些行为（例如返回 summarized thinking 还是 full thinking）会因模型而异。

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

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

为什么这很重要

• 编码与代理： Sonnet 4.5 在真实世界软件任务和长周期编码工作上有显著提升——因此非常适合代码生成、代码编辑以及自主代理流程。
• Extended thinking 与上下文： Claude 4.5 系列模型能够使用非常大的内部 scratchpad（数万 token 甚至更多）进行推理，从而支持更深入的多步思考。这会改变你设计提示词、token 预算和工具交互的方式。

Claude 4.5 中的 Thinking Mode 是什么？

Thinking Mode（官方称为 “Extended Thinking”）是一种能力，使模型在给出最终输出前，能够先“向自己展示推理过程”。与标准模型收到问题后立即开始作答不同，Claude 4.5 会使用专门的推理空间来探索多个假设、识别其逻辑中的潜在错误，并优化自身策略。

响应的结构

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

Thinking mode 的关键属性

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

如需查看上手示例和最新参数，Anthropic 的 Messages / Extended Thinking 文档是权威参考。

Messages API 如何返回 thinking 内容

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

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

实际处理模式

工具使用 / 状态延续： 如果你的下一次请求需要延续相同的内部状态（例如工具是基于 thinking 结果执行的），请在再次调用 API 时包含返回的 thinking block 或 signature，这样模型就能解密并从上一次中断的位置继续。

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

响应： 你可能会收到：(a) summarized 的公开输出，(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 的摘要以及最终答案。如果你需要在多轮代理流程中保持连续性，请在下一次请求的 messages 数组中包含未经修改的 thinking blocks（见下一个示例）。

示例 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)

在进行与工具集成或长时间运行的代理式工作流时，精确保留原始、未经修改的 thinking blocks 至关重要。Opus 4.5 在 thinking block 的保留与缓存方面有更好的默认行为。

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

流式处理最佳实践

• 使用 SDK 的流式接口（Python / TypeScript SDK 都提供 stream helper）。对于运行时间长或高预算的推理任务，流式处理可以避免 HTTP 超时，并在模型思考过程中提供部分文本。典型代码模式是在 Python 中迭代 text_stream，或在 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 是一个交互式、代理式编码终端，集成了 Messages API 和工具运行器。CLI / IDE 体验会通过两种方式暴露 thinking：

• 全局 / 每会话设置： Claude Code 提供 /config 设置面板，用于调整行为（例如代理如何请求权限、是否保留 thinking blocks 等）。如果你想要持久化修改行为，应使用该界面，而不是反复手写原始 JSON。
• 模型选择与 CLI 命令： 你可以在 REPL 中选择 claude-sonnet-4-5 或 claude-opus-4-5 作为当前模型，此后工具和 thinking 的行为将遵循 Messages API 的语义。CHANGELOG 和发布说明表明，在某些 Opus 4.5 部署中，thinking 默认已启用，并且 thinking 配置已通过 /config 暴露出来。

Claude Code 中的实际流程：

1. 在 REPL 中启动一个项目。
2. 使用 /config 检查与 thinking 相关的标志（保留、详细程度等）。
3. 让代理执行一个长任务——它会产生 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 支持多种 flag 和自然语言触发词来控制其推理深度。

提示：

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

交错 Thinking 与 Block 保留的优势

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

Interleaved Thinking（Beta）

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

想象 Claude 正在调试一台服务器：

1. Think： “我应该先检查日志。”
2. Tool Call： read_file(logs.txt)
3. Think： “日志显示数据库超时。现在我需要检查连接池配置。”
4. Tool Call： 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 的最佳实践

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

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

监控并控制成本与延迟

你将按 Claude 实际生成的全部 thinking tokens 计费，而不是按你最终看到的摘要长度计费。这意味着，即使你只看到很短的 summary，长时间的内部 deliberation 仍会增加成本。请跟踪 token 使用情况，并考虑逐步调优（例如：2k → 8k → 32k），从探索阶段过渡到生产阶段。

仅在必要时保留 thinking blocks

Thinking blocks 可以带有加密签名并保留下来，以供后续验证和交错式工具使用。除非工作流确实要求模型保留其先前的内部 deliberation（例如代理要重新执行步骤并需要保留当时的推理依据），否则不要在每次后续请求中都回传 thinking blocks。始终保留 thinking 会增加上下文体积，也可能使 token 计费更复杂。

何时向用户流式展示 thinking

流式 thinking 非常适合开发者工具和教育类 UI（在模型思考时显示“正在处理”）。但不要在面向生产消费者的应用中，未经安全和脱敏评估就向终端用户流式展示原始 thinking：summarized thinking 的存在正是出于这个原因。如果要流式展示，请在 UI 中明确标注这是内部推理（例如 “Assistant reasoning — internal”），并控制最终用户看到的是摘要版还是完整推理。

工具使用与交错

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

实际故障排查与运维说明

常见错误及其含义

• Invalid thinking + forced tool choice： 如果你请求开启 thinking，同时又强制使用与 thinking 不兼容的工具调用模式，API 会返回错误——不要把强制 tool_choice: {"type":"tool","name":"..."} 和 thinking 混用。
• Budget > max_tokens： 在 interleaved 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）最终 text tokens。利用这些指标来建立用户侧流程的预算与 SLO。

渐进式发布与人工介入

将启用 thinking 的模型放在 feature flag 后面逐步发布。先从一部分开发者流量或内部流量开始，收集失败案例或 redaction 情况，再迭代提示词和预算。对于敏感领域，在发布前应要求人工审核那些包含大量内部推理的输出。

调试技巧

• 从小开始：先启用较低的 budget_tokens，再逐步增加，以观察增量收益。
• 打开流式模式并记录 content_block_delta / signature 事件，以了解模型何时生成 thinking blocks。
• 如果你在使用 Claude Code：检查 /config 和项目级设置；如果行为与预期默认值不符，请查看 Claude Code 的 changelog。

结论：

Claude 4.5，结合 Extended Thinking 和 Claude Code CLI 的能力，代表了自 IDE 发明以来开发者生产力最重大的飞跃。通过让模型能够“展示自己的工作过程”并对复杂问题进行审慎推理，Anthropic 已经从“聊天机器人”时代迈向“代理式”时代。

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

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

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