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 年 2 月更新：对于 Claude Opus 4.6 和 Sonnet 4.6，手动模式 thinking={type: "enabled", "budget_tokens": ...} 已被标记为已弃用（deprecated），建议使用新的 adaptive thinking 模式 thinking={type: "adaptive"}，由模型根据任务复杂度自动决定思考深度。旧写法在 4.6 上仍可用但将在未来版本移除。

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. 预算型控制：给推理过程设上限，避免时延和成本失控。

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

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

工程上有两个判断原则：

• 优先使用 thinking={“type”: “adaptive”} 配合 output_config={“effort”: ...} 控制思考深度，这是 4.6 模型的推荐方式。

• 旧写法 thinking={“type”: “enabled”, “budget_tokens”: N} 在 4.6 模型上仍可用但已标记弃用（deprecated），不建议新代码使用。

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. 预算不要拍脑袋设很大

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

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

• 简单任务：effort: "low"，模型可能跳过思考，响应更快。

• 中等复杂任务：effort: "medium"，适度思考。

• 复杂推理任务：effort: "high"（默认）或 "max"（仅 Opus 4.6），深度推理。

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

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

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

• 是否减少了重试；

• 是否减少了人工复核；

• 是否降低了后续工作流失败率。

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

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

在 Agent 系统里，可以只让：

• Planner / Reviewer 开启 thinking；

• Executor / Retriever 维持快速模式。

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

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

一个实用决策框架是：

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

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

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 协作系统