推理模型工程

路由决策：什么请求才值得 reasoning

背景与原理

reasoning model 用 test-time compute 换准确率：把更多 token 花在隐藏的思考上。Snell 等人 2024 的 Scaling LLM Test-Time Compute Optimally（arXiv 2408.03314）给出关键工程结论——最优策略取决于任务难度：简单题上加推理几乎无收益，难题上 test-time compute 才可能比单纯放大模型参数更划算。所以路由的判据不是「重要不重要」，而是三条同时满足才升档：(1) 答案可验证（数学/代码/逻辑有客观对错）；(2) 需要多步规划且步数无法预先压成 workflow；(3) 错误成本高于多花的钱和延迟。反过来，检索问答、格式化、分类、改写、抽取——这些一步到位的任务路由到 reasoning 纯属烧钱，还常因「过度思考」掉准确率。

实战示例

把路由写成代码层的前置分类，而不是「全量上 o3」：

def route(task):
    # cheap 分类器（标准模型/规则）先判难度档
    if task.kind in ("lookup", "format", "classify"):
        return ("claude-haiku-4-5", None)            # 不开 thinking
    if task.kind in ("math", "plan", "debug") and task.verifiable:
        return ("o3", "medium")                     # 升档 + 中预算
    return ("claude-sonnet-4-6", None)

一个被低估的事实：同一个 reasoning 模型族里，小号开高推理常常打不过大号开低推理，但便宜得多——所以路由表里要同时调「模型大小」和「推理档位」两个维度，不是只调一个。

思维预算：更长不等于更准

背景与原理

两家给了不同的控制面。OpenAI 用 reasoning_effort（low / medium / high）；Anthropic extended thinking 历史上用 budget_tokens（必须 < max_tokens），但在 Opus 4.6 / Sonnet 4.6 上 budget_tokens 已弃用，改成 adaptive thinking——深度交给 effort 自适应，模型自己决定想多久。关键反直觉来自两篇实证：Underthinking of o1-like LLMs（arXiv 2501.18585）发现模型会在思路间频繁跳转、不深挖；而过度思考的反面同样存在——思维链越长，平均准确率反而可能下降，模型陷入重复与自我推翻。换句话说，预算不是越大越好，每个任务类型有自己的甜区，要靠 eval 找，不能拍脑袋给满。

实战示例

# OpenAI o-series：effort 是主旋钮（Responses API）
resp = client.responses.create(
    model="o3", reasoning={"effort": "medium"}, input=task)

# Anthropic extended thinking（3.7 ~ 4.x < 4.6）：显式 budget_tokens
resp = client.messages.create(
    model="claude-sonnet-4-5", max_tokens=8000,
    thinking={"type":"enabled", "budget_tokens": 4000},  # 必须 < max_tokens
    messages=msgs)

# 4.6+：budget_tokens 弃用，改 adaptive thinking — 深度交给 effort
thinking={"type":"enabled"}   # 模型自适应，配合 effort 旋钮

工程做法：按任务档位设三级预算（low/medium/high 或 ~1k/4k/16k token），用一组带 ground truth 的题扫一遍，画「预算 vs 准确率」曲线，取拐点而非顶点。多数任务会在中档触顶，高档只增成本不增分。

Agentic loop 里的推理：interleaved thinking 与协议坑

背景与原理

标准 reasoning 是「想完再答」。但 agent 需要「想一下→调工具→看结果→再想→再调」——这就是 interleaved thinking（Anthropic 用 beta header interleaved-thinking-2025-05-14 开启）：模型可以在每次 tool 调用前后插入思考，根据 tool_result 调整下一步。OpenAI o3/o4-mini 则把工具调用原生训进 CoT，让模型在思考中决定何时用工具。这里有个极易踩的协议坑：多轮之间，你必须把上一轮 assistant 返回的 thinking block（连同它的 signature）原样回传。很多 harness 为了省 token 把 thinking 当「废话」strip 掉——结果要么报错，要么割裂了模型的推理链，agent 行为骤然变差。interleaved 模式下思考 token 还会累计跨多个 block，预算语义和单轮不同。

实战示例

msgs = [{"role":"user", "content": task}]
while True:
    r = client.beta.messages.create(
        model="claude-sonnet-4-5", max_tokens=8000,
        betas=["interleaved-thinking-2025-05-14"],
        thinking={"type":"enabled", "budget_tokens":4000},
        tools=schemas, messages=msgs)
    msgs.append({"role":"assistant", "content": r.content})  # ← 原样存 thinking+tool_use
    if r.stop_reason != "tool_use": break
    msgs.append({"role":"user", "content": run_tools(r.content)})
    # 关键：不要在这里删 r.content 里的 thinking block

另一个工程要点：reasoning 在 agent 里最值钱的地方是规划与纠错——开局让它想清楚整体计划、tool 失败后让它想为什么失败。中间纯粹的机械 tool 调用不必每步高推理，按需调档。

Prompt 反模式与 trace 的诚实用法

背景与原理

reasoning model 自带内部思考，外部再让它「think step by step」是冗余甚至有害的——OpenAI 官方指南明确：这类模型偏好简洁直接的 prompt，硬加 CoF 引导和大量 few-shot 反而可能拉低表现（Simon Willison 2025 年那篇 prompting 建议总结得很清楚）。所以从 GPT-4 时代搬来的「让我们一步步思考 + 5 个示例」模板要拆掉。第二个陷阱关于 reasoning trace 的可信度：思维链读起来条理分明，但它不是模型决策的忠实记录——可解释性研究反复显示模型会事后合理化（backward rationalization）。所以别 parse CoT 文本去做下游硬决策，也别因为「思路看着对」就信结论。要信，就用可验证的最终输出（跑测试、对数值、查引用），而不是信过程叙述。

实战示例

# BAD：把 GPT-4 的 CoT 模板原样套给 o3 / extended thinking
"Let's think step by step. Here are 6 examples... Now reason carefully:"
# → 冗余引导 + 大量 few-shot，常拉低 reasoning model 表现

# GOOD：简洁直给，把约束讲清楚，让模型自己想
"修复这个并发 bug。约束：不改公共 API，保持向后兼容。"
# 需要 markdown 时（OpenAI o 系列）在 developer message 首行：
"Formatting re-enabled"

eval 上的反直觉守则：不要假设更长的思考 = 更可信。给 reasoning 输出做评估时，盯客观正确率，别被冗长缜密的 trace 唬住——「想得满满当当却答错」在难题上很常见，本质是用一个不完美的验证器去筛不完美的推理链，错误被「洗」得更自信而已。