智能体循环中的推理模型溢价：何时“思考”值得，何时不值得

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

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

为什么推理模型在智能体场景下的成本要高得多

推理模型实现了研究人员所说的“推理时计算扩展”（test-time compute scaling）：在生成最终答案之前，模型会生成一段很长的内部思维链 —— 即思考 token（thinking tokens）—— 然后再据此行动。这些 token 是真实的 API 费用，也是真实的 GPU 周期。模型不仅仅是在和你交谈；它在回答之前还在“大声地”梳理问题。

在标准的单轮设置中，这种开销在每次查询中是固定的。但在智能体循环中，开销会以两种方式复合。

首先，智能体循环涉及多次连续的 LLM 调用，每一次都会继承前一次的对话历史。一个运行 10 次迭代的 Reflexion 风格循环消耗的 token 可能是单次线性传递的 50 倍。当每一次传递都包含推理前导时，实际的成本乘数要比单次调用的 token 计数所显示的要高得多。

其次，智能体任务往往运行在更长的输入上。工具输出被追加到上下文中，检索到的文档被注入其中。每一次后续调用都会因为输入变大而变得更加昂贵 —— 而且推理模型在更长、更复杂的输入上会产生比例更高的思考 token。

关于动态推理对基础设施影响的研究发现，与单轮推理相比，运行在 8B 模型上的智能体每次查询所需的 GPU 能量要高出 62 到 136 倍。在每一步都使用推理模型扩展到生产规模，这已经不再是定价问题，而是一个基础设施架构问题。

推理模型在哪些方面能真正发挥作用

推理模型能够提供可衡量的、持久改进的案例通常具有共同的结构：任务要求模型同时处理多个约束条件，做出影响后续步骤的决策，并在早期假设被证明错误时能够从容地恢复。

多步规划与任务分解。 当任务需要将复杂目标分解为相互依赖的子任务时 —— 例如预订具有签证要求的行程、撰写并安排跨五个服务的数据库迁移 —— 推理模型的表现显著优于标准模型。研究表明，在规划智能体中加入思维链推理，比没有显式推理的同一模型成功率提高了 4 个百分点以上；而一个 8B 的推理增强模型在网络导航任务上的表现甚至达到了非推理 70B 模型的水平。在长周期规划方面，推理是比单纯扩大模型规模更好的投资。

软件工程与代码生成。 SWE-bench 排行榜被启用了推理的系统所占据。在经验证的基准测试中，高推理配置的得分在 80 分中高段，而标准模型则明显处于较低的平台期。对于涉及调试陌生代码库、实现带有边界条件的算法解决方案，或在多个文件中产生架构一致的更改等任务，准确性差距是持续且巨大的。

科学与形式推理。 医学鉴别诊断、具有司法管辖区细微差别的法律分析、具有条件约束的财务建模 —— 这些任务类型从推理中受益，因为给出确信但错误的答案代价很高，而通往正确结果的路径需要同时考虑许多事实。推理模型在做出最终答案之前愿意修正自己的中间步骤，这正是减少这些领域中“确信的错误”的机制。

在廉价流程中的高风险单次决策。 即使整体工作流很简单，通常也会有一两个决策点，如果出错，代价将是昂贵的或不可逆的。一个主要使用快速模型进行路由的客户支持流程，可能仍会专门针对确定是否退款或升级到法律审查的步骤，将其路由到推理模型。

推理模型不划算的场景

过度使用推理模型的失效模式是：为那些本不需要深思熟虑的任务支付了高昂的“思考”成本。

反应式动作执行。 一旦计划形成，当前步骤是“使用此查询调用搜索 API”或“将此字符串写入该文件”，推理标记（reasoning tokens）就毫无用处了。该动作是确定性的。快速模型能以与推理模型相当的可靠性生成正确的函数调用，而成本仅为后者的一小部分。这是智能体系统中常见的预算泄露：在流水线的每个节点都放置了推理模型，而实际上只有一两个节点需要它。

短时界、低歧义的查询。 事实检索、类别明确的分类任务、从结构化文档中提取信息——标准模型在处理这些任务时，其表现几乎与推理模型持平。关于“计划与行动”（plan-and-act）框架的研究明确指出：在简单的导航任务中，为标准模型增加一倍的轨迹数据仅能将准确率提高 0.61%，而推理增强带来的收益同样微乎其微。这些任务存在性能天花板，而推理并不能抬高这个上限。

延迟敏感型应用。 语音 AI 流水线的目标是首音输出（time-to-first-audio）低于 300 ms。交互式 UI 流程期望在 1 秒内做出响应。推理模型通常会为每次调用增加数秒的延迟——对复杂输入的深入思考可能需要 10 到 30 秒。如果你的应用对延迟的 SLA（服务等级协议）要求比推理模型的中值响应时间还要紧凑，那么无论准确率如何，该模型层级对于这项工作来说都是错误的。

早期迭代与原型开发。 推理模型会掩盖提示词工程（prompt engineering）的债务。它会补偿那些描述不充分的指令和模糊的工具模式（tool schemas），而快速模型则会通过失败将这些问题暴露出来。如果团队仅使用推理模型进行原型开发，随后发现切换到标准模型层级时一切都无法运行，那么他们并没有构建出一个产品；他们只是构建了一个需要昂贵基础设施才能运作的演示（demo）。

复合风险：当智能体陷入自我循环时

最危险的推理模型使用场景并非单次任务，而是可以递归或自我修正的智能体循环。一个 Reflexion 风格的智能体运行自我批评循环，每次尝试都会多次调用推理模型。如果智能体配置错误，或者任务定义不清晰，它可能会陷入无限循环：每个周期都在消耗推理标记，每个周期都让上下文窗口变得更长，从而使下一次调用更加昂贵。

针对这种行为的研究建模发现，Reflexion 循环在早期周期中以增加 51% 延迟的代价换取了 4% 的准确率提升，但若要在循环后期获得同等幅度的提升，则需要支付 31 倍的成本。迭代推理的收益递减曲线非常陡峭。通常存在一个循环次数上限，超过该上限后，额外的推理标记只是在为“合理化”买单，而不是在解决问题。

两种实用的缓解措施：为每个智能体循环设置明确的迭代上限；并在每次自我批评周期前增加一个检查点，询问当前轨迹是否仍有足够的未确定性，以证明进行另一次推理尝试是合理的。如果信心已经很高，则终止并交付。

将任务路由至推理模型的决策框架

实际的解决方案是采用一种路由架构，根据可衡量的信号而非猜测，将查询发送到合适的模型层级。目标不是完美地分类每一个查询，而是确保正确率足够高，让合适的层级处理那些在经济上有重大影响的情况。

在以下情况下路由至推理模型：

• 任务需要五个以上相互依赖的步骤才能完成
• 工具输出具有歧义，在执行下一步操作前需要解释
• 任务涉及不可逆的操作，错误决策的成本极高（如发送电子邮件、修改记录、触发外部系统）
• 此前在同类任务中使用快速模型的尝试显示失败率 > 10%
• 该领域涉及形式推理、代码或多约束规划

在以下情况下路由至快速模型：

• 任务正在执行已形成计划中的某个具体步骤
• 在现有上下文下，动作是确定性的
• 延迟要求严于 2 秒
• 查询属于分类、提取或简单的信息检索
• 任务是交互式的、面向用户的，且具有紧密的反馈循环

在投入使用前进行测量。 针对你实际的生产环境分布进行推理模型的影子测试（shadow-test），而不是仅依赖基准测试。基准测试中的性能差距是真实的，但基准测试是为难度而设计的。你的生产流量可能具有不同的分布——平均任务复杂度低于 SWE-bench，但对延迟的敏感度更高。

作为可调参数的思考预算

一个未被充分利用的杠杆：大多数推理模型 API 允许你显式配置思考预算。最小值通常为 1,024 个标记；实际上限取决于模型，但通常在数万个。

从最小预算开始，针对准确率至关重要的任务类型逐步增加预算，这为你提供了一个“成本-准确率”调节拨盘，而非二选一。一个中等复杂度的规划任务可能需要 4,000 个推理标记就能达到目标准确率——而不是 32,000 个。成本差异是巨大的；但在你实际的任务分布中，准确率的差异往往很小。

实际的工作流程：在多种思考预算下对你的任务类型进行基准测试。绘制准确率与成本的关系图。找到每类任务的曲线“拐点”（knee of the curve）。在生产环境中使用该预算，而不是默认的最大值。

这对架构意味着什么

对架构的启示是：推理模型的使用应当是局部化的，而非默认的。在构建你的 Agent 架构时，应将模型层级视为每个节点上的路由决策，而不是系统的全局属性。分解复杂调研任务的规划节点可能需要推理模型。而根据该计划获取相关文档的检索节点，可能就不需要。从检索内容中生成最终报告的综合节点可能再次需要推理能力，但其预算应低于初始规划步骤。

这比为所有环节设置单一模型需要更多的工程工作。但在生产规模下，当 Agent 循环每天运行数十万次时，统一使用推理模型与进行适当路由之间的成本差异，往往决定了一个产品是具有可行性，还是无法在其目标价位实现盈利。

推理模型溢价是真实存在的，推理模型税也是如此。了解你流水线中的每一步适用于哪一种，并非锦上添花 —— 这正是能够规模化的系统与陷入停滞的系统之间的本质区别。