推理型模型上生产：可能更聪明，但是更难控

年初那波“推理更强”的模型热潮来得很快：榜单刷屏、Demo 震撼，朋友圈的结论也很统一——“以后只要把问题喂给模型，它自己会想明白”。

我很想相信这句话。直到我们把推理型模型接进生产链路的第三天，线上报警把我从午睡里拎起来：P95 延迟翻倍、Token 成本像漏水一样持续上升，最尴尬的是——答案“看起来更像对的”，但用户依旧不满意。

这篇文章不聊宏大叙事，只写我踩过的坑：推理型模型在生产里到底难在哪、怎么控、怎么让它真的“值回票价”。

1. 生产里最真实的矛盾：更强的推理 ≠ 更好的体验

推理型模型的优势常常出现在“长链路、强约束”的任务：复杂排错、跨文档对齐、代码理解、规划执行。

但线上大部分请求不是这样。它们更像：

“帮我把这段话改得更礼貌”
“这个接口 500 了，你看日志哪里不对”
“给我一个 SQL，把某个报表做出来”

这些请求的痛点不是“推理不够”，而是：

输入信息不完整（缺少关键参数、环境、上下文）
输出不可控（格式漂移、关键信息遗漏）
成本不可预测（同一个问题，有时 200 tokens，有时 4000 tokens）

推理型模型会把“缺的信息”也纳入思考，它越认真，越可能把你的延迟和成本也认真地吃掉。

2. 我们第一次上生产时怎么翻车的

我们做的是一个面向内部研发的“排障助手”：输入是错误堆栈 + 部分日志片段 + 配置片段；输出是：

可能原因列表（带置信度）
下一步排查建议
如果需要，生成一段用于验证的脚本/命令

在旧模型阶段，我们通过“工具调用 + 结构化输出”硬把它拉进可控轨道：

先让模型把问题分类（网络/权限/依赖/配置/代码）
再根据分类决定是否去查工具（日志检索、配置对比、依赖树）
最后输出固定的 JSON 格式

推理型模型上来后，我们想着：它更聪明了，工具调用可以放松点。

结果：

它开始“热心过头”，能查的都查一遍。一个请求触发 6 次日志检索、3 次配置对比。
它开始写长篇分析，把“排障建议”写成了“推理散文”。
最要命的是：它把不确定当成可推导，反而更少问澄清问题。

最后我们得到了一条经验：推理型模型不是更听话的工程组件，它更像一个更爱思考的同事——你不把会议议程写清楚，它就会把会议开成读书会。

3. 控住推理的三个“闸门”

闸门 A：预算（Budget）必须前置

我们做的第一件事很朴素：给每个请求设预算。

最大延迟预算：例如 6 秒
最大 Token 预算：例如 1200 tokens
最大工具调用次数：例如 3 次

你会发现这听起来像“给模型戴枷锁”。但生产就是这样：

你不是在做一个聪明展示，而是在经营一个可预测的系统。

一个简单的策略是把任务分层：

L0（快速）：直接回答，最多 1 次工具
L1（标准）：允许 2~3 次工具
L2（深度）：只有当用户显式选择“深入分析”才进入

用 Mermaid 画出来大概是这样：

flowchart TD
  A[用户请求] --> B{是否需要深度推理?}
  B -- 否 --> C[L0/L1: 有预算的工具调用]
  B -- 是 --> D[L2: 深度推理 + 更高预算]
  C --> E[结构化输出]
  D --> E

闸门 B：把“澄清”当作能力，而不是失败

推理型模型很容易“硬推”出一个答案。我们强制它在满足某些条件时先澄清：

缺少环境（语言版本、OS、运行方式）
错误堆栈不完整（只有最后一行）
日志片段没有时间范围

我很讨厌那种“为了显得礼貌而问十个问题”的机器人。

所以我们用的是“最多问两个，且必须解释为什么问”。示例模板：

我需要确认 X，否则会在 Y 和 Z 两种分支里走错方向。
你只要补充：①… ②…（可复制命令）

这一步对体验帮助很大：用户会觉得它像一个靠谱的同事，而不是一个会编故事的百科全书。

闸门 C：输出契约（Contract）比推理更重要

我们把最终输出固定成“可以被系统消费”的格式，哪怕中间推理再复杂，最后也必须落回模板：

{
  "summary": "一句话结论",
  "likely_causes": [
    {"cause": "...", "confidence": 0.72, "evidence": ["log:...", "config:..."]}
  ],
  "next_steps": ["...", "..."],
  "commands": ["..."],
  "need_clarification": false,
  "questions": []
}

如果模型输出跑偏，我们宁愿把它判为失败，重新走一遍更保守的链路。

4. 让成本“看得见”的可观测性：从 Token 到 SLO

推理型模型把不可预测性放大了，所以观测必须更细。

我们最终保留下来的指标不多，但都很“能打”：

每请求输入/输出 token
工具调用次数、工具失败率
端到端延迟（P50/P95）
“澄清率”与“澄清后解决率”
回答被用户追问的比例（同一会话 2 次以上追问）

有个反直觉的点：

追问率往往比满意度更早告诉你系统坏了。

因为用户不一定会点差评，但会用脚投票：继续问、换问法、最后找人。

5. 我的结论：推理型模型适合做“可升级的选项”

我们后来把推理型模型从“默认”变成“可升级的按钮”：

默认走标准链路（预算小、结构稳）
用户点击“深入分析”才加预算
对高价值用户或高风险问题再自动升档

这听起来保守，但很适合大多数真实系统。

推理型模型最宝贵的不是它能写更长的推理，而是它能在复杂场景里把信息组织成可执行的下一步。

如果你也准备把推理型模型上生产，我的建议就一句：

先把预算、澄清、输出契约三件事做扎实，再谈“更聪明”。

琅琊苑