第一个注意到你推理模型回退的人，几乎永远不会是工程团队的成员。而是财务分析师，在周二下午联系你的经理，因为上个月的 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）不加区分地应用于不需要它的任务时，就会发生这种情况。
推理模型（o1、o3、DeepSeek R1、具有扩展思考能力的 Claude）的出现，代表了解决难题能力上的真正飞跃。但它也引入了一类新的生产错误：在快速、廉价的生成完全足够的情况下，部署了昂贵且缓慢的深思熟虑。正确做出这一决策，对于构建真正有效的 AI 系统正变得越来越核心。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
