> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/claude_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/claude_guide/di-san-bu-fen-jin-jie-pian/08_agent/8.4_extended_thinking.md).

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

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

> 注：Anthropic 在这一能力上的 API 形态仍在持续演进。写作本章时，公开文档同时出现过 **extended thinking**、**interleaved thinking**、**adaptive thinking** 等表述。工程上应以官方当前文档为准；本章重点解释设计原则、成本结构和使用边界，而不是绑定某一个短期版本字段。
>
> **2026 年 6 月更新**：API 对不同模型的 thinking 支持已明确分化：
>
> * **Claude Sonnet 5**：Sonnet 5 默认启用 Adaptive Thinking；可用 `thinking={"type": "disabled"}` 关闭。手动 Extended Thinking 会返回 400，非默认 `temperature` / `top_p` / `top_k` 同样不接受。
> * **Claude Fable 5**：Adaptive Thinking 常开且不可关闭；不支持手动 Extended Thinking（`thinking={type: "enabled", budget_tokens: N}` 会返回 400 错误），思考深度用 `output_config={"effort": ...}` 控制；2026-07-01 已恢复全球访问。
> * **Claude Opus 4.8 / 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（Opus 5 / Sonnet 5 / Opus 4.8 / Opus 4.7 / Opus 4.6；Sonnet 4.6 仅作为迁移兼容性参考）
# 注：Opus 5 上 thinking 默认即为 adaptive，下面显式写出等价于默认值
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=8192,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # low / medium / high；Opus 5、Opus 4.8/4.7 还可用 xhigh / max
    messages=[{"role": "user", "content": "设计一个高并发秒杀系统的架构"}]
)
```

工程上有两个判断原则：

* Opus 5 与 Sonnet 5 默认开启 Adaptive Thinking，不接受手动 `budget_tokens`。Opus 4.8、Opus 4.7 和 Opus 4.6 优先使用 `thinking={"type": "adaptive"}` 配合 `output_config={"effort": ...}` 控制思考深度；其中 Opus 4.8 / 4.7 不支持手动 `budget_tokens`，且**不写 `thinking` 字段就不思考**（Opus 5 相反）。
* 在 Opus 5 上关闭思考要额外注意：`thinking={"type": "disabled"}` 只在 `effort` 为 `high` 及以下时接受，与 `xhigh` / `max` 同时使用返回 400，且按请求逐次校验。
* 仅为迁移兼容，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 通常应按 **输出侧成本** 来理解，因为它们本质上属于模型生成过程的一部分，而不是读取输入的成本。另外注意：思考 Token 同时计入请求的 `max_tokens` 输出上限——上限设得过小会截断思考过程；在高 effort 档位下应把 `max_tokens` 设大（官方建议从 64k 起步按需调优）。

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

```
总成本 = 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-8",
    max_tokens=2000,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},
    messages=[...]
)
```

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

* **简单任务**：`effort: "low"`，模型可能跳过思考，响应更快。
* **中等复杂任务**：`effort: "medium"`，适度思考。
* **复杂推理任务**：`effort: "high"`（默认），深度推理。
* **极端复杂任务/Agentic 编码**：`effort: "xhigh"` 或 `"max"`（Opus 5、Opus 4.8 / 4.7 可用），在工具使用密集的场景下提供更充分的推理。官方默认档位仍是 `high`；使用 `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)