★ FEATURED ARTICLE 1. 推理强度到底是个什么东西先把概念说清楚。推理强度Reasoning Effort是近两年大模型 API 里出现的一个控制参数最早由 OpenAI 在 o 系列模型上引入后来各家推理模型基本都跟进了类似的设计。它的作用非常直白告诉模型在给出最终答案之前愿意花多少内部思考的预算。你可以把它理解成考试时的草稿纸用量。同样是解一道题有人心算三秒就写答案有人要在草稿纸上推演半页。两种方式都能交卷但正确率、耗时、草稿纸消耗完全不同。推理强度就是那个允不允许你多用草稿纸的开关。目前主流的档位大致是这样划分的档位典型标识内部思考量适用场景最低minimal / none几乎不思考直接输出格式转换、简单抽取低low少量推理链分类、改写、简单问答中medium中等推理链常规问答、代码补全高high完整推理链复杂数学、多步逻辑极高xHigh / extra high超长推理链可能反复自我验证竞赛级难题、复杂 Agent 规划标题里问的有 xHigh为什么要选 Low本质上是在问既然模型提供了最强的思考档位为什么还有大量生产环境主动把它调到最低这个问题在 Agent 开发和 Prompt 工程圈里被反复讨论因为答案直接关系到你的账单、延迟和稳定性。我先把结论摆出来推理强度不是越高越好它是一个需要按任务类型精算的成本项。选 Low 不是偷懒而是经过权衡后的工程决策。下面我把这个决策背后的逻辑一层层拆开。2. 为什么高推理强度反而是个陷阱2.1 推理强度和准确率不是线性关系很多人有个直觉思考得越多答案越准。这个直觉在简单任务上完全错误。我拿实际测试的数据说话。在一个文本分类任务上把用户反馈分成物流质量客服三类我用同一个模型跑了不同推理强度的对比推理强度准确率平均延迟平均输出 tokenLow94.2%0.8s45Medium94.5%2.1s320High94.1%5.6s1180xHigh93.8%11.3s2400看清楚了吗准确率几乎没变甚至 xHigh 还略微下降了。但延迟涨了 14 倍token 消耗涨了 50 倍。这就是典型的过度思考——模型在简单任务上强行展开推理链反而容易在中间步骤引入噪声最后把自己绕进去。注意推理链越长中间任何一步的偏差都会被后续步骤放大。这在学术上叫误差累积在工程上就是你多花的钱买来了更多出错的机会。2.2 成本结构决定了 Low 的性价比推理模型的计费有个特点思考过程的 token 也要算钱。这跟传统模型不一样传统模型你只为输入和输出付费推理模型的内心戏是实打实消耗 token 的。假设你在做一个日调用量 100 万次的 Agent 服务平均每次任务用 Low输入 500 token 输出 50 token 550 token用 xHigh输入 500 token 思考 2000 token 输出 50 token 2550 token按主流推理模型的价格粗算xHigh 的单次成本是 Low 的 4 到 5 倍。100 万次调用下来这个差距就是真金白银的几万块。而如果你的任务本身是从订单里抽取收货地址这种确定性工作xHigh 带来的那 0.3% 准确率提升根本不值这个价。2.3 延迟是用户体验的隐形杀手在 Agent 场景里延迟的影响比单次问答大得多。一个 Agent 完成任务往往要调用模型 5 到 20 次规划、执行、观察、再规划。如果每次调用都开 xHigh单次 10 秒20 次就是 200 秒。用户等三分钟才拿到结果这个产品基本就废了。我踩过这个坑。早期做一个数据分析 Agent为了保证质量全程开 High结果一个中等复杂度的分析任务要跑 4 分钟。后来把规划阶段降到 Medium、执行阶段降到 Low总耗时压到 40 秒用户满意度直接翻倍而任务成功率只掉了 2 个百分点。3. 什么任务该用什么档位一张决策表说了这么多核心问题是怎么判断一个任务该用哪个档位。我总结了一套判断标准按任务是否需要多步推理和错误代价两个维度来分。3.1 按任务类型选档位任务类型推荐档位理由文本分类、情感分析Low / minimal模式识别不需要推理链信息抽取NER、结构化Low确定性映射思考反而添乱文本改写、翻译Low / Medium语言任务中等强度够用简单问答、FAQLow答案在知识里不在推理里代码补全、单函数生成Medium需要一定上下文推理多步数学题High推理链是刚需复杂 Agent 规划High / xHigh需要权衡多个方案竞赛级难题、科研推理xHigh唯一值得开满的场景这张表的关键洞察是大部分生产环境的任务其实落在 Low 到 Medium 区间。真正需要 xHigh 的场景在真实业务里占比可能不到 5%。3.2 一个反直觉的发现Agent 的不同阶段该用不同档位这是我在做 Agent 开发时最重要的一个经验。一个 Agent 的完整生命周期通常包含几个阶段每个阶段对推理强度的需求完全不同意图识别阶段判断用户想干什么。这是分类任务用 Low 甚至 minimal。任务规划阶段把大目标拆成子步骤。这是真正的推理任务用 High。工具调用参数生成把子步骤转成具体的函数调用。这是结构化输出用 Low。结果观察与判断判断工具返回是否满足预期。中等复杂度用 Medium。最终答案组织把结果整理成自然语言。这是生成任务用 Low。如果你全程用一个档位要么在简单阶段浪费钱要么在关键阶段思考不足。动态切换档位才是 Agent 开发的正确姿势。我实测下来这种分阶段策略能把总成本压到全程 High 的 30%而任务成功率基本持平。3.3 怎么判断这个任务到底难不难有个简单的自测方法你自己做这个任务需要打草稿吗。如果答案是看一眼就知道用 Low。如果答案是要想一下但不用写下来用 Medium。如果答案是得在纸上列几步用 High。如果答案是得反复推演、验证、回头检查才考虑 xHigh。这个方法听起来土但出奇地准。因为模型的推理强度和人类解决同类问题所需的思考量是高度相关的。4. 实操怎么在代码里动态控制推理强度光说理论没用得能落地。下面我给出几种主流框架下的实现方式。4.1 直接调 API 时的参数设置以 OpenAI 风格的接口为例推理强度通常通过reasoning_effort参数控制from openai import OpenAI client OpenAI() def call_model(prompt, task_type): # 根据任务类型映射推理强度 effort_map { classify: low, extract: low, rewrite: low, qa: medium, code: medium, math: high, plan: high, research: high, } effort effort_map.get(task_type, medium) response client.chat.completions.create( modelyour-reasoning-model, messages[{role: user, content: prompt}], reasoning_efforteffort, ) return response.choices[0].message.content关键点在于effort_map这个映射表。你要根据自己的业务把每个具体的调用点归类到某个任务类型然后统一管理档位。这样调整的时候只改一处不用满代码找参数。4.2 在 Agent 框架里做分阶段控制如果你用的是 LangChain、LlamaIndex 这类框架或者自研的 Agent 编排层思路是把推理强度作为节点的一个属性class AgentNode: def __init__(self, name, prompt_template, effortmedium): self.name name self.prompt_template prompt_template self.effort effort # 定义各阶段节点 nodes [ AgentNode(intent, INTENT_PROMPT, effortlow), AgentNode(planner, PLAN_PROMPT, efforthigh), AgentNode(tool_call, TOOL_PROMPT, effortlow), AgentNode(observe, OBSERVE_PROMPT, effortmedium), AgentNode(respond, RESPOND_PROMPT, effortlow), ]这样每个节点自带档位配置编排引擎执行到哪个节点就用哪个档位。我强烈建议把档位配置和 Prompt 模板放在一起管理因为它们本来就是配套的——换 Prompt 往往意味着换任务类型档位也该跟着变。4.3 用 Prompt 本身来暗示推理强度有些模型或部署环境不支持显式的reasoning_effort参数这时候可以用 Prompt 来间接控制。核心技巧是在系统提示里加入对思考深度的指令想要 Low 效果直接给出答案不要解释推理过程。想要 Medium 效果简要说明你的判断依据然后给出答案。想要 High 效果逐步分析列出你的推理步骤最后给出结论。提示Prompt 控制不如参数控制精确而且会占用额外的 token。能用参数就用参数Prompt 控制只作为兜底方案。4.4 一个容易被忽略的细节输出格式约束推理强度高的时候模型倾向于输出大段解释。如果你要的是结构化数据JSON、表格高推理强度反而会让输出格式不稳定。这时候除了降档位还要在 Prompt 里强约束输出格式EXTRACT_PROMPT 从下面的文本中抽取收货信息只输出 JSON不要任何解释。 文本{text} 输出格式 {{name: , phone: , address: }} 配合 Low 档位这种抽取任务的稳定性能到 99% 以上。我试过用 High 档位做同样的事模型会贴心地加上分析过程导致 JSON 解析失败率飙升。5. 常见问题与排查技巧实录5.1 降档位后准确率掉了怎么办这是最常见的顾虑。我的排查顺序是这样的先确认是不是 Prompt 的问题。很多时候准确率下降不是档位不够而是 Prompt 本身有歧义。把 Prompt 改清楚Low 档位也能达到 High 的效果。检查任务是否真的需要推理。如果任务本质是模式匹配降档位不该掉准确率。如果掉了说明你的 Prompt 把简单任务描述复杂了。做 A/B 测试定位临界点。从 Low 开始逐步升档找到准确率不再提升的那个点。那个点就是你的最优档位。考虑混合策略。对准确率敏感的关键调用用 Medium其余用 Low。5.2 为什么我开了 xHigh 反而变慢了除了延迟本身还有一个隐蔽原因高推理强度会触发更多的重试和自我验证。模型在思考过程中可能反复推翻自己的结论导致输出 token 暴涨。如果你的服务有超时限制xHigh 很容易触发超时重试实际耗时比预期更长。排查方法看日志里的completion_tokens和reasoning_tokens。如果 reasoning_tokens 占比超过 70%说明模型在过度思考该降档了。5.3 不同模型的档位不能直接套用这是个坑。A 模型的 Low 可能相当于 B 模型的 Medium。因为各家对推理强度的实现和训练方式不同档位的实际含义有差异。我的做法是换模型时重新做一遍档位标定。用一组固定的测试用例跑一遍所有档位记录准确率和延迟重新画那张决策表。这个过程大概花半天但能避免上线后才发现档位不对。5.4 常见问题速查表现象可能原因解决方向降档后准确率明显下降任务确实需要推理升到 Medium 或优化 Prompt高推理强度延迟过高过度思考降档 限制输出长度输出格式不稳定推理链干扰结构化输出降档 强约束格式成本超预算全程高档位分阶段动态切换换模型后效果变差档位语义不一致重新标定档位思考 token 占比过高任务太简单直接降到 Low5.5 一个独家避坑技巧给推理强度加监控上线后一定要监控两个指标每次调用的 reasoning_tokens 占比和各档位的任务成功率。如果发现某个 Low 档位的任务成功率异常低说明这个任务被错误分类了需要重新归类。如果发现某个 High 档位的 reasoning_tokens 占比超过 80%说明这个任务其实不需要那么高的档位。我见过太多团队上线后就不管档位了结果半年后发现成本翻了三倍原因就是某个新加的功能默认用了 High。监控能让你在成本失控前发现问题。6. 我的实际配置经验最后分享一套我在生产环境用的默认配置你可以直接抄作业再按需调整。对于纯文本处理类任务分类、抽取、改写、翻译默认 Low只有在准确率不达标时才升 Medium。这类任务占了调用量的 60% 以上是省钱的主力。对于对话和问答类任务默认 Medium。因为用户的问题复杂度不可控Medium 是个稳妥的中间值。如果检测到问题很短很简单比如少于 20 个字自动降到 Low。对于Agent 编排严格按阶段分档意图识别 Low、规划 High、工具调用 Low、观察 Medium、回复 Low。这套配置我用了大半年成本和延迟都控制得很好。对于代码相关任务默认 Medium。简单的补全和解释用 Low涉及多文件重构或复杂算法才升 High。对于数学和逻辑推理这是唯一值得开 High 甚至 xHigh 的场景。但即便如此我也会先试 Medium只有在测试集上准确率不达标时才升档。注意这套配置的前提是你的 Prompt 质量过关。Prompt 写得烂再高的推理强度也救不回来。我见过太多人把准确率问题归咎于档位不够实际上是 Prompt 没说清楚要什么。推理强度这个参数本质上是在思考质量和思考成本之间做权衡。xHigh 不是不能用而是要用在刀刃上。大部分时候一个清晰的 Prompt 配一个 Low 档位比一个模糊的 Prompt 配 xHigh 效果好得多还便宜得多。这个道理我在踩了无数次坑之后才真正想明白。
阅读完成 · 觉得有帮助？
 high, but should be low. Please check target）)
