10 篇博文 含有标签「reasoning-models」

我上季度合作的一个团队在周二发布了推理层升级，周三就开始收到支持工单。用户反映助手感觉“坏了”、“冻结了”或“卡住了”。值班工程师查看了延迟仪表盘，没发现任何异常。p99 首字延迟（first-token latency）为 612 毫秒——远低于团队花了一个季度建立的 800 毫秒 SLO。仪表盘是一片绿色。电话却响个不停。

问题的根源在于 14 个月前做出的一个埋点决策，当时生产环境中还没有推理模型。标记为 “first token” 的指标测量的是供应商发出的第一个数据块（chunk）的时间戳。升级后，第一个 chunk 变成了推理 token——这对用户不可见，也从未渲染，但在 SLO 中却被计为“首个”。模型在流式传输第一个用户可见字符之前，会先发出 4 到 7 秒的内部思考过程。每个图表依然是绿色的。每个用户却在黑暗中等待。

这不是一个关于指标好坏的故事。指标对于它最初设计的模型来说是正确的。这是一个关于当你的埋点边界不再是用户的感知边界时会发生什么的故事——以及在不知不觉中发布这种偏差是多么容易且危险。

第一个注意到你推理模型回退的人，几乎永远不会是工程团队的成员。而是财务分析师，在周二下午联系你的经理，因为上个月的 Anthropic 账单比前一个月高了 2.4 倍，而且“我们并没有发布任何会导致这种结果的东西”。你打开仪表板，查看请求量——平稳。p99 延迟——平稳。每个响应的输出标记——平稳。错误率——平稳。你六个月前配置的每一个面板都显示系统运行健康。财务人员看的是另一个数字，而且他们是对的。

他们看的数字是推理标记（reasoning tokens），而大多数可观测性栈是在这个领域出现之前构建的。

价格页面上最便宜的那一行很少是发票上最便宜的一行。团队选择主力模型（Workhorse model）——Sonnet、Haiku、Flash、GPT-mini——是因为每 token 的计算方式很友好。上线功能后，看着成本控制面板报告了一个季度的单位经济效益（unit-economics）好消息。然后长尾效应跟了上来：主力模型处理不了一部分请求，开始重试，接着是部分回答，最后升级到人工审核，每个功能的损益表（P&L）不再像每次调用的仪表盘那样好看了。

这里的套利在于，针对这些困难请求，团队永远不会作为默认选项的推理模型（Reasoning model）——Opus、o3，这类缓慢昂贵的模型——通常在第一次尝试时就能给出答案。一次 0.50 美元的推理调用总成本，胜过五次 0.05 美元的主力模型调用加上升级队列，以及周一调试失败的工程师成本。采购问题（哪个模型每 token 最便宜？）和架构问题（哪个模型解决每个请求最便宜？）是不同的问题，将两者混为一谈的团队正在支付这两者之间的差价。

推理模型会输出思维链（chain-of-thought）轨迹，因为这是它的计算方式。产品团队在 UI 中渲染该轨迹，是因为隐藏它感觉像是丢掉了用户付费购买的 token。这是两个不同的决定，而产品端几乎没有人意识到他们做了第二个决定。于是，轨迹变成了面板，面板变成了功能，功能有了文档页面。六个月后，有人在季度回顾中问，为什么支持队列里全是用户在反驳推理过程，而不是针对答案本身。

推理轨迹本质上是调试输出。它的存在是为了让工程师了解模型为什么选择某个工具、在日期上含糊其辞，或者在段落中间悄悄切换了角色。在没有经过设计审查的情况下将其推给终端用户，等同于在生产环境中留下 console.log 调用并称之为“透明度”。它看起来像个功能，渲染成本几乎为零，但它会以团队构建的任何仪表盘都无法显示的方式悄悄削弱信任。

当你的财务团队第一次问，为什么单个用户在回答一个价值 0.1 美分的问题时产生了两美分的账单，那个电话讨论的不会是模型，而是发票上那行十二个月前还不存在的项目：推理 Token (reasoning tokens)。在账单上它们看起来像输出 Token，在大多数服务商那里也按输出 Token 的费率计费，而且它们没有天然的上限。一个在非推理模型上只需产生 400 个 Token 回复的查询，可能会悄无声息地消耗 8,000 个内部思考 Token 才能得出答案——唯一注意到这一点的人是核对支出的人。

在 API 时代的大部分时间里，“使用的 Token 数”是一个诚实的数字。你输入提示词，得到响应，账单是两者的清晰函数。推理模型打破了这种直觉。模型现在在发出调用者将阅读的答案之前，会生成一个隐藏的、可计费的、仅内部可见的思维链，而该链的大小取决于模型自身对问题难度的评估。用户可见的输出可能只有一句话，而账单可能长达十页。

强化思维在处理新颖的推理任务时表现出色。但在工具边界（即你的智能体必须选择调用哪个函数、何时调用以及传递哪些参数的时刻），同样的思维预算往往会适得其反。模型会权衡三个等效的工具，而快速模型原本只需要一个 token 就能消除歧义。它在原本不存在歧义的地方制造出听起来合理的歧义。它消耗了一千个推理 token 来反复质疑那个显而易见的 search 调用，结果最后还是调用了 search。你为一个不需要推理的决策支付了推理税。

这是 2026 年智能体系统中隐形的成本中心：问题不在于推理模型本身（其擅长领域的定价是合理的），而在于在错误的环节部署了推理模型。这种反模式（anti-pattern）就潜伏在显而易见的地方，因为顶层任务看起来很难（如“回答用户的问题”），所以团队将整个循环都包裹在深思熟虑的模式中，却从未意识到 80% 的思维预算都花在了对工具选择的微观决策上，而这些决策模型凭第一直觉就已经选对了。

调出过去一周的生产环境追踪记录，查看你的延迟仪表板。你几乎肯定在总请求延迟上设置了 p50 和 p99。你可能还有令牌吞吐量（token throughput）。你甚至可能有一张每秒令牌数（tokens-per-second）图表，因为某个供应商的基准测试说服你这么做了。但你几乎肯定没有的是按模型、按路由、按租户划分的**首字时间（time to first token, TTFT）**直方图 —— 这是决定你产品感知速度的核心指标。

这绝非一个小疏忽。对于任何流式界面 —— 聊天、代码补全、智能体侧边栏、语音 —— 用户感知的速度取决于在内容出现之前，他们盯着闪烁光标的时间。一旦第一个令牌（token）出现，用户就开始进入阅读状态；随后的令牌是在与他们的阅读速度竞争，而不是与他们的耐心竞争。总延迟（Total latency）对于吞吐量规划和成本预算很重要，而 TTFT 则决定了产品是否让人感觉“有生命力”。

这两个数字之间的差距正在拉大。推理模型（Reasoning models）产生的总延迟可能与其非推理兄弟模型完全相同，但却会将 TTFT 从 400 毫秒推高到 30 秒。一个“保持延迟持平”的路由更改，可能会悄无声息地将一个反应灵敏的助手变成一个卡死的窗口。如果你没有对 TTFT 进行图表化，你就是在发布连你自己都察觉不到的 UX 退化。

大多数团队在采用推理模型时都会做同一件事：把现有的系统提示词复制过去，指向 o1 或带扩展思考的 Claude Sonnet，然后期待模型升级完成剩余工作。基准测试分数上去了，生产准确率却原地踏步——甚至下滑。问题不在模型，而在于提示词的思维模型从未改变。

推理模型的工作方式与指令跟随模型截然不同。那些能从 GPT-4o 榨取性能的策略——精心设计的系统提示词、精选的 few-shot 示例、明确的"逐步思考"指令——都是为另一种推理架构设计的。把这些策略用在推理模型上，恰恰会限制那些让这类模型具有价值的核心能力。

本文是一份实用指南，聚焦于真正重要的差异以及切实有效的调整方法。

在为你的智能体（agent）采用推理模型之前，有一个数字值得你深思：对于一个标准的快速模型，单次查询仅需 7 个 token，但在 Claude extended thinking 中则需要 255 个 token，而在配置激进的推理模型中更是高达 603 个 token。对于孤立的聊天机器人查询来说，这还是可以接受的。但在一个每项任务调用模型 12 次的智能体循环中，你支付的不只是 10 倍的溢价 —— 而是 10 倍溢价乘以 12，并且随着每一轮重新喂入不断增长的上下文窗口，成本还会进一步复现。账单带来的“惊喜”扼杀智能体项目的速度往往比准确性问题还要快。

问题不在于推理模型是否更好。在处理困难任务时，它们显然更出色。问题在于，推理模型是否更适合你的特定工作负载，是否更适合你在智能体循环中的特定位置，以及其提升的幅度是否足以抵消成本。大多数团队在这两个方向上都做出了错误的回答 —— 他们要么统一采用推理模型（在不需要它们的任务上浪费预算），要么完全避开它们（错失了在需要它们的任务上提升准确性的机会）。

有一项研究，研究人员要求一个推理模型比较两个数字：0.9 和 0.11。一个模型花了 42 秒才给出答案。数学计算只花了几毫秒。模型在剩下的 41.9 秒里都在进行糟糕的思考。它重新审视自己的答案，怀疑自己，重新考虑，最后得出了它在前三个 token 中就已经得出的正确结论。

这就是过度思考的问题，它并非个案。当你将推理侧计算（inference-time compute）不加区分地应用于不需要它的任务时，就会发生这种情况。

"https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E5%BD%93%E6%80%9D%E8%80%83%E6%A8%A1%E5%9E%8B%E7%9C%9F%E6%AD%A3%E5%8F%91%E6%8C%A5%E4%BD%9C%E7%94%A8%E6%97%B6%EF%BC%9A%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E6%8E%A8%E7%90%86%E7%AE%97%E5%8A%9B%E7%9A%84%E5%86%B3%E7%AD%96%E6%A1%86%E6%9E%B6"

推理模型（o1、o3、DeepSeek R1、具有扩展思考能力的 Claude）的出现，代表了解决难题能力上的真正飞跃。但它也引入了一类新的生产错误：在快速、廉价的生成完全足够的情况下，部署了昂贵且缓慢的深思熟虑。正确做出这一决策，对于构建真正有效的 AI 系统正变得越来越核心。