# 8.4 扩展思考：深度推理模式

2025 年初，OpenAI o1 和 Claude 3.7 Sonnet 的新特性引发了关于 **System 2 Thinking** 的热潮。 所谓的 “Extended Thinking” (或称 Thinking Mode)，是指模型在输出最终答案之前，能够在后台进行更长时间的推理与自我校验。

> 注：Anthropic 在这一能力上的 API 形态仍在持续演进。写作本章时，公开文档同时出现过 **extended thinking**、**interleaved thinking**、**adaptive thinking** 等表述。工程上应以官方当前文档为准；本章重点解释设计原则、成本结构和使用边界，而不是绑定某一个短期版本字段。
>
> **2026 年 4 月更新**：API 对不同模型的 thinking 支持已明确分化：
>
> * **Claude Opus 4.7**：仅支持 Adaptive Thinking（`thinking={type: "adaptive"}`），不再接受 `type: "enabled"` 的旧语法（会返回 400 错误）。
> * **Claude Sonnet 4.6**：支持 Adaptive Thinking（推荐）和 Extended Thinking（`thinking={type: "enabled", "budget_tokens": N}`，已弃用但仍可用）。
> * **Claude Opus 4.6**：支持 Adaptive Thinking（推荐）和 Extended Thinking（`thinking={type: "enabled", "budget_tokens": N}`，已弃用但仍可用）。
> * **Claude Haiku 4.5**：支持 Extended Thinking（`thinking={type: "enabled"}`），但不支持 Adaptive Thinking。

## 8.4.1 什么是 System 1 vs System 2？

* **System 1 (快思考)**: 直觉式反应。
  * Example: "2+2=?" -> "4"。
  * Standard LLM Mode.
* **System 2 (慢思考)**: 逻辑推理，逐步验证。
  * Example: “计算 3491 x 231” -> (列竖式...) -> “806421”。
  * Extended Thinking Mode.

在 Extended Thinking 模式下，Claude 可能会花费更长时间生成额外的推理 Token，用于自我辩论、尝试错误路径并回溯，最终只输出一个质量更高的答案。

## 8.4.2 启用与控制

虽然具体字段会随模型和 API 版本调整，但控制逻辑通常只有两类：

1. **开关型控制**：告诉模型“这次任务允许进行更深的推理”。
2. **预算型控制**：给推理过程设上限，避免时延和成本失控。

可以把它理解为下面这种抽象调用：

```python
# 推荐写法：Adaptive Thinking（Claude Opus 4.7 / Opus 4.6 / Sonnet 4.6）
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=8192,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # low / medium / high / max
    messages=[{"role": "user", "content": "设计一个高并发秒杀系统的架构"}]
)
```

工程上有两个判断原则：

* Opus 4.7、Opus 4.6 和 Sonnet 4.6 优先使用 `thinking={"type": "adaptive"}` 配合 `output_config={"effort": ...}` 控制思考深度。
* Opus 4.6 和 Sonnet 4.6 仍兼容 `thinking={"type": "enabled", "budget_tokens": N}`，但该手动预算模式已弃用；Haiku 4.5 仅支持 Extended Thinking，不支持 Adaptive。

## 8.4.3 工作流程解密

当启用了 Thinking Mode，Claude 的内部独白可能长这样：

> *(Hidden Thinking Block)* User wants a high-concurrency system. *Initial thought*: Use Redis + MySQL. *Critique*: Simple Redis might act as a bottleneck if not sharded. *Alternative*: Explore Lua scripts for atomicity. *Check*: What about message queues? Kafka vs RabbitMQ? *Decision*: Let's propose a 3-layer architecture: CDN -> Nginx L7 -> MQ -> Consumer -> DB. *Refinement*: Need to mention cache consistency strategies (Cache-Aside vs Write-Through). ...

最终输出： “这是一个推荐的三层架构方案...”（逻辑更完整，遗漏更少）

## 8.4.4 适用场景

并非所有任务都需要慢思考。

| 场景             | Extended Thinking | 理由                           |
| -------------- | ----------------- | ---------------------------- |
| **创意写作**       | 视任务而定             | 发散式任务未必受益于更长推理，过度约束反而可能损失风格。 |
| **日常闲聊**       | ❌ 通常不需要           | 用户更在意低延迟。                    |
| **数学证明**       | ✅ 推荐              | 需要严密推导和自检。                   |
| **复杂代码架构**     | ✅ 推荐              | 需要比较多种方案和约束。                 |
| **法律/医疗高风险问答** | ✅ 推荐              | 更需要审慎推理与自我检查，但仍不能替代专业审阅。     |

## 8.4.5 推理的前沿方向：超越语言链

Extended Thinking 本质上仍是基于语言序列的推理。研究前沿正在探索两个方向：**隐空间推理**（在更高维表示空间中完成部分推理）和**并行推理**（将独立子问题拆分并发执行）。这两个方向都指向同一个趋势：**下一代推理能力的提升，未必只来自“想得更久”，也可能来自“想得更高效”**。

> 关于隐空间推理（如 Coconut）、并行推理以及推理时扩展上界的技术细节，参见姊妹篇《大语言模型原理》14.6.6 节。

## 8.4.6 成本分析

Extended Thinking 的价值在于提高一次完成率，但它的额外成本必须单独计算。

### 思考 Token 的计费方式

在 Anthropic 的公开计费模型里，思考过程产生的 Token 通常应按 **输出侧成本** 来理解，因为它们本质上属于模型生成过程的一部分，而不是读取输入的成本。

**建议使用下面这个总公式理解成本结构：**

```
总成本 = Input Tokens × 输入单价 + (Thinking Tokens + Output Tokens) × 输出单价
```

如果只比较“开启 thinking”和“关闭 thinking”的增量，那么：

```
增量成本 = Thinking Tokens × 输出单价
```

这两个公式足以覆盖大多数工程估算场景。

### 一个更稳妥的例子

假设某次请求包含：

* Input: 2000 tokens
* Thinking: 5000 tokens
* Output: 500 tokens

则：

```
总成本 = 2000 × Pin + 5500 × Pout
```

如果同一请求在关闭 thinking 时仍然输出 500 tokens，那么开启 thinking 的额外成本就是：

```
5000 × Pout
```

这样算有两个好处：

* 不依赖某个短期价格表；
* 不会把 thinking 的增量和输入单价混在一起，导致 ROI 公式前后矛盾。

### 成本优化建议

**1. 预算不要拍脑袋设很大**

```python
# Adaptive Thinking 的 effort 级别控制
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=2000,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},
    messages=[...]
)
```

经验上可以按任务复杂度分层：

* **简单任务**：`effort: "low"`，模型可能跳过思考，响应更快。
* **中等复杂任务**：`effort: "medium"`，适度思考。
* **复杂推理任务**：`effort: "high"`（默认），深度推理。
* **极端复杂任务/Agentic 编码**：`effort: "max"`（Opus 4.7）或 `"xhigh"`（Opus 4.7 可选），在工具使用密集的场景下提供最充分的推理。使用 `xhigh`/`max` 时建议将 `max_tokens` 设为 64k 以上，为思考和工具调用留出充足空间。

Adaptive Thinking 会自动启用交错思考（Interleaved Thinking），即在工具调用之间也进行推理，这对 Agent 工作流尤为重要。

**2. 先看一次成功率，再看单次成本**

Thinking 的真正收益不在“单次更贵”，而在于：

* 是否减少了重试；
* 是否减少了人工复核；
* 是否降低了后续工作流失败率。

对复杂任务，一次高质量回答往往比三次低质量尝试更便宜。

**3. 把 thinking 留给最该用的节点**

在 Agent 系统里，可以只让：

* Planner / Reviewer 开启 thinking；
* Executor / Retriever 维持快速模式。

这样能把额外成本集中到最值钱的决策节点，而不是所有调用都一视同仁地“深思熟虑”。

## ROI 分析：什么时候值得开启 Extended Thinking？

一个实用决策框架是：

```
是否值得开启 thinking
= 它节省的重试成本 + 它减少的人工成本 + 它降低的故障成本
  是否大于
  Thinking Tokens × 输出单价
```

可以把它写成一个简单的工程函数：

```python
def should_use_extended_thinking(
    task_type: str,
    retry_cost: float,
    review_cost: float,
    failure_cost: float,
    thinking_tokens: int,
    output_rate_per_million: float,
) -> bool:
    incremental_cost = thinking_tokens * output_rate_per_million / 1_000_000
    expected_benefit = retry_cost + review_cost + failure_cost

    if task_type in {"math_proof", "complex_reasoning", "code_architecture"}:
        return expected_benefit >= incremental_cost

    if task_type in {"classification", "simple_qa", "small_talk"}:
        return False

    return expected_benefit >= incremental_cost
```

这个版本虽然更朴素，但不依赖拍脑袋的成功率或过期价格差值，适合作为长期可维护的成本判断方法。

## 8.4.7 对 Agent 架构的影响

Extended Thinking 改变了设计 Agent 的方式。

### 减少外部 Loop 次数

以前可能需要用 ReAct 模式让 Agent 显式地思考 5 轮。 现在，可以把其中一部分规划与校验内化为一次更强的 Thinking Call。 **External Loop -> Internal Thought**。 这通常会减少网络往返，也能让模型在单次上下文中做更完整的权衡。

### 混合策略

在 Multi-Agent 系统中，可以让 **Planner Agent** 开启 Extended Thinking（负责深思熟虑地定计划），而 **Executor Agent** 使用普通模式（负责快速执行）。

***

一个好汉三个帮。即使是会“慢思考”的 Claude，也无法独自完成所有事情。 有时候，需要组建一支 AI 团队。

➡️ [多 Agent 协作系统](/claude_guide/di-san-bu-fen-jin-jie-pian/08_agent/8.5_collaboration.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/claude_guide/di-san-bu-fen-jin-jie-pian/08_agent/8.4_extended_thinking.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.