Hoe gebruik je de Thinking-modus in 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 能力，不过某些行为（例如返回的是摘要版 thinking 还是完整 thinking）会因模型而异。

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

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

这为什么重要

• 编码与代理： Sonnet 4.5 在真实软件任务和长程编码工作上表现出明显提升，使其成为代码生成、代码编辑和自主代理流程的自然选择。
• Extended thinking 与上下文： Claude 4.5 系列模型被设计为能够使用非常大的内部草稿区（数万 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 模型中，即使你只收到摘要版 thinking，thinking tokens 依然会计费。
• 摘要与脱敏： 对许多 Claude 4 模型而言，用户看到的是 thinking 内容的摘要版；某些内部推理内容可能会被安全系统脱敏（加密）并以 redacted_thinking 的形式返回。
• 签名与验证： Thinking blocks 会包含一个不透明的 signature，用于在你将 thinking blocks 返回给 API 时进行验证（尤其在使用工具时很重要）。你应将该签名视为不透明数据——不要尝试解析它。
• 与工具交错推理： Claude 4 支持在工具调用之间穿插 thinking blocks（某些场景下为 beta 能力或需通过特定 flag 开启）。这对代理式工作流非常强大（运行工具、思考、再运行工具等）。

如需查看实操示例和最新参数，请以 Anthropic 的 Messages / Extended Thinking 文档为准。

Messages API 如何返回 thinking 内容

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

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

实际处理模式

工具使用 / 连续调用： 如果下一次请求必须延续相同的内部状态（例如工具是基于前一次 thinking 执行的），那么你应该在再次调用 API 时，带上返回的 thinking block 或 signature，以便模型解密并从上次中断处继续。

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

Response： 你可能收到：(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 与最终答案。如果你需要在多轮代理流程中保留连续性，请在下一次请求的 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 中解析事件流。
• 有时需要预期“两阶段流”：模型可能先生成可见的 reasoning 片段，随后再输出最终答案。你的 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 已默认开启，且相关配置可通过 /config 暴露。

Claude Code 中的实际流程：

1. 在 REPL 中启动一个项目。
2. 使用 /config 查看 thinking 相关 flag（保留、详细程度等）。
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 / agent 返回了 thinking blocks，请保留它们；否则代理可能会在步骤之间丢失上下文。

交错 Thinking 与 Block Preservation 的优势

对于高级代理式工作流，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 非常关键。

• 推理连续性： 模型通过接收先前的思考内容，能够维持整个决策路径的逻辑上下文。
• 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 付费，而不是仅为你看到的摘要付费。这意味着即便你只收到很短的摘要，长时间的内部思考仍会增加成本。应持续跟踪 token 使用情况，并考虑渐进式调优（例如：2k → 8k → 32k），再从探索阶段迁移到生产阶段。

仅在必要时保留 thinking blocks

Thinking blocks 可以被加密签名并保留，以用于后续验证及交错工具调用。除非你的工作流明确需要模型保留先前内部推理（例如代理要重复运行某些步骤并依赖保留的推理依据），否则不要在每次后续请求中都回传 thinking blocks。始终保留 thinking 会增加上下文体积，也会使 token 计费管理更复杂。

何时向用户流式展示 thinking

流式展示 thinking 很适合开发者工具和教育型 UI（在模型思考时显示“处理中”）。但在面向终端消费者的生产应用中，不应在未充分考虑安全与脱敏机制的前提下直接展示原始 thinking：之所以存在摘要版 thinking，正是出于这一原因。如果要展示，应在 UI 中明确标注其为内部推理（例如“Assistant reasoning — internal”），并控制最终用户看到的是摘要版还是完整版 reasoning。

工具使用与交错推理

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

实际排障与运维说明

常见错误及含义

• Invalid thinking + forced tool choice： 如果你请求启用 thinking，同时又强制指定某些与 thinking 不兼容的 tool-use 模式，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) 最终文本 token 数。利用这些指标来构建预算模型和用户侧流程的 SLO。

渐进式发布与人工参与

应通过 feature flag 逐步推出 thinking-enabled 模型。可以先对一部分开发者流量或内部流量开放，收集失败案例或脱敏情况，再迭代提示词和预算配置。对于敏感领域，在发布前应对包含大量内部推理的输出加入人工审核环节。

调试建议

• 从小处开始：先启用较低的 budget_tokens，再逐步增加，以观察质量提升是否具有边际价值。
• 开启流式响应，并记录 content_block_delta / signature 事件，以了解模型何时产生 thinking blocks。
• 如果你在使用 Claude Code：检查 /config 和项目级设置；如果行为与预期默认值不一致，请查阅 Claude Code 的更新日志。

结论：

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！