同一个 high，不是一个刻度-北京尧图网络

摘要各家的 low/medium/high 推理档位名字一样刻度、默认值和计费方式却各不相同。对照官方文档理清这个旋钮真正控制什么以及什么时候调高反而更贵更差。一年前模型想多久还是个固定属性。你要么用一个会思考的模型要么不用没有中间地带。现在不一样了。Anthropic 的 API 里有effort参数OpenAI 有reasoning.effortGemini 有thinking_levelDeepSeek 和通义千问也各自支持。落到工具层面Claude Code 里一条/effort就能切换Visual Studio 的 Copilot 对话窗口上摆着三档按钮。推理深度从模型自带的能力变成了每次调用都能拧的旋钮。问题出在这些旋钮长得太像。low / medium / high名字一模一样很容易让人以为大家共用一把尺子。把各家官方文档摊开对照一遍会发现不是这么回事。名字一样控制的东西不一样先看一张对照表。所有参数名、档位、默认值都取自各家官方文档厂商参数档位默认值实际控制范围Anthropic Claudeoutput_config.effortlow / medium / high / xhigh / maxhighClaude Code 中 Opus 4.7 起为 xhigh响应中的全部token正文、工具调用、扩展思考OpenAIreasoning.effortnone / minimal / low / medium / high / xhigh取值随模型而定gpt-5.5 为 medium推理过程输出长短另由verbosity控制Google Gemini 3thinking_levelminimal / low / medium / high—思考深度2.5 系列改用thinking_budget直接给 token 数DeepSeekreasoning_effortthinking.typelow / high / maxhigh思考默认开启思考强度官方文档附带一份实际映射表通义千问enable_thinkingthinking_budget开关 1–32768 的 token 预算多数模型默认开启预算默认 4000是否思考以及思维链长度上限关键差异在第一行的最后一列。Claude 的 effort 不只管想多久它管整次响应花掉多少 token——包括工具调用的次数和正文的长度。Anthropic 官方文档的原话是较低的努力程度会让 Claude 把多个操作合并成更少的工具调用、减少工具调用的总次数、直接动手而不加前言。同一个high在 Claude 这里是整体节流阀在 OpenAI 那里只是推理节流阀——后者把输出长短交给了另一个独立的verbosity参数。Gemini 走的是第三条路。3 系列给档位名2.5 系列干脆不给直接要一个thinking_budget数字2.5 Pro 默认 8192可调范围 128–327682.5 Flash 是 0–24576。国产模型多数又是第四种形态一个 on/off 开关加一个 token 预算语义上更接近 Gemini 2.5。所以我把两边都设成 high这句话跨厂商是不成立的。Claude Code 的官方模型配置文档里有一句说得很直白effort 刻度是按模型标定的同一个档位名在不同模型下不代表相同的底层值。默认值是厂商替你做的决定这一点值得多看两眼因为默认值暴露了厂商对典型负载的假设。Anthropic API 默认 high但在 Claude Code 里Opus 4.7 及之后的默认档位是xhigh——理由是编码和 agentic 类任务确实从更深的推理里受益。OpenAI 的 gpt-5.5 默认medium。DeepSeek 的 thinking 模式默认开启、默认 high。也就是说同一个开发者、同一类编码任务在不同工具链里拿到的默认推理量能差出两档。你没动过旋钮不代表旋钮不在动。还有个容易忽略的边界Gemini 3 系列无法彻底关闭思考最低只到 minimal。而通义系的某些模型反过来——在阿里云百炼上GLM-5.3 与 kimi-k3阿里云直供版的官方文档写明该模型始终开启思考enable_thinking仅支持 true传入 false 会导致 API 请求失败。把关掉思考当降本手段在有些模型上根本不是合法选项。DeepSeek 这里还有个值得知道的细节。它的reasoning_effort名义上接受 low / high / max 三档但官方文档给了映射表medium 会映射到 highxhigh 按模型映射到 high 或 max。文档同时注明deepseek-v4-pro 的实际映射在 2026 年 8 月初有过一次调整。换句话说你传进去的档位名和模型真正执行的推理强度不一定是同一个东西。调高很多时候不划算档位拉满的直觉是多想总没错。厂商和学术两边的证据都不太支持。Anthropic 在 computer use 的最佳实践文档里给了一条相当明确的否定结论不推荐在 computer use 上使用 max effort在我们的测试中它相对 high 没有准确率收益却进一步推高了输出 token 成本。理由是 UI 任务以感知判断为主而非深度逻辑多出来的推理预算要么用不上要么变成过度思考。同一份文档里还有个更实用的发现medium 配上重试能达到和 high 相当的表现token 成本只有一半。Claude Code 官方文档对 max 的描述同样克制可能提升高难度任务的表现但存在边际收益递减且容易过度思考建议先测试再广泛采用。学术那边有一个更系统的观察。一篇分析编码 Agent 花销的论文OpenReview《How Do Coding Agents Spend Your Money?》把同一道题的多次运行按成本从低到高分成四档统计准确率相对最低成本档的变化系数最低档 0.00次低档 0.032次高档 0.025最高档 0.005。准确率在中等成本处见顶再往上反而回落。论文把它归为 inverse test-time scaling——多出来的算力没变成更好的解题而是变成了反复试错和上下文膨胀。作者还观察到一个具体行为高成本且失败的运行里重复查看、重复编辑同一文件的频次显著上升。堆推理量买到的常常不是想得更深而是绕得更远。需要给这条证据划个边界它衡量的是 Agent 整体运行的成本不完全等同于单次请求的档位设置。但它指向的方向和厂商自己的结论一致——越过某个点之后多花钱换不来准确率。真正该做的是路由不是调档既然旋钮存在正确用法就不是全局设一个值而是按任务分档。Anthropic 官方给出的分档定位是现成的档位官方定位适用low最高效显著节省 token能力有所降低简单分类、快速查询、高吞吐、子代理medium平衡有适度的 token 节省需要速度、成本、性能三者平衡的 agent 任务high高能力等同不设参数复杂推理、困难的编码问题、agent 任务xhigh编码与 agentic 任务的推荐起点反复工具调用、详细网络搜索与知识库检索max绝对最高能力无 token 上限真正前沿的难题多数负载下不划算Visual Studio 的 Copilot 在 2026 年 8 月的 18.9 版本里也上了三档官方定义是Low 给快速响应、使用更少 tokenMedium 平衡推理深度与响应速度适合日常编码任务High 做更深推理适合棘手算法、架构决策和难调的 bug。这三句定义本身就是一份任务分类表。工程上真正好用的是把档位写进配置而不是每次手调。Claude Code 提供了几种粒度/effort xhigh# 当前会话切换claude--efforthigh# 单次启动exportCLAUDE_CODE_EFFORT_LEVELmedium# 环境变量优先级最高更细的一层是 skill 和 subagent 的 frontmatter 可以单独指定 effort---name:quick-lintdescription:跑一遍 lint 并汇报结果effort:low---这解决的是一种很具体的浪费一个负责跑 lint 或格式化检查的子代理根本不需要和主代理相同的推理深度。把子代理压到 low、主代理留在 xhigh省下的钱比全局降一档多得多而且不伤主任务的质量。官方对 low 的推荐用例里子代理本来就被明写出来。还有个不太常被提到的开关ultrathink。把它写进 prompt可以让当前这一轮临时加深推理而会话的 effort 设置不变。适合一次性的难题——不必为了一个问题把整个会话的档位抬上去。要注意的是 Claude Code 只认ultrathink这一个关键词“think hard” 之类会被当成普通文本传进去。我自己目前的配置是三层全局effortLevel设成high跑 lint、格式化、依赖检查这类工具型 skill 的 frontmatter 全部压到low遇到需要跨模块重构的会话再手动/effort xhigh抬一档。这套配法没什么技巧真正的收益来自第三层因为知道抬档是要手动做的我在起一个会话前会先想清楚它属不属于智能敏感。分错的代价很直观——lint 子代理跑到 xhigh 是纯浪费重构会话停在 medium 则是要返工。旋钮的存在本身就在逼你给任务分类。几个容易踩的坑中途改档位会打断提示缓存。Anthropic 官方文档明确写了在请求之间更改 effort 值会使提示缓存失效。在长会话里频繁切档省下的输出 token 可能被反复重建缓存的输入成本吃掉。思考 token 按输出价计费藏起来的也算钱。Gemini 官方文档的说法很直接开启思考时响应价格等于输出 token 与思考 token 之和且计费基于模型生成的全部思考 token——尽管 API 只吐出摘要。Claude Code 文档同样写明即使思考内容被折叠或经过脱敏处理你仍然要为生成的所有思考 token 付费。通义的文档还补了一条例外开了思考模式但模型实际没产出思考内容时按非思考模式的价格计费。档位掉了别先用 prompt 补。Anthropic 给 Opus 4.7 的建议是如果在复杂问题上看到推理变浅提高 effort而不是试图用 prompt 补偿。反过来如果因为延迟必须压在低档位那就加一句具体指引比如这个任务涉及多步推理回答前仔细想清楚。旋钮背后是预算责任推理量从模型的能力变成了调用者的预算这是这个旋钮真正带来的变化。一年前你挑模型现在挑完模型还得挑档位。厂商把决定权交出来了同时也把责任交出来了——而那个默认值是厂商按它设想的典型负载替你选的不是按你的。明天能做的一件具体的事把你手上的 skill、subagent 和脚本按智能敏感和延迟敏感分成两堆前者默认 xhigh后者压到 low中间地带给 medium然后跑一周看账单。别凭感觉调档位——感觉会告诉你调高总没错账单不会。主要来源Anthropic《Effort》与 Claude Code《Model configuration》官方文档Effort 文档、Google《Gemini API thinking》官方文档thinking-mode、DeepSeek《思考模式》官方文档中文版、OpenAI《Reasoning》文档、通义千问《Thinking》文档、阿里云百炼 OpenAI 兼容接口文档、Microsoft《Visual Studio 18.9 release notes》。作者唐悦玮 | 从后端出发用 AI 拓展到全栈的工程师。

同一个 high，不是一个刻度

相关推荐

AI Factory揭秘：从模型平台到可治理的智能体服务生产系统

游戏开发数据驱动设计：告别硬编码，实现逻辑配置化

大数据架构深度解析：ClickHouse 向量化引擎走读：为什么它比 MySQL 快 100 倍

更多资讯

Agent Skill 如何应对第三方框架持续更新：分层解耦与版本兼容策略

贵州水土保持公报19年数据工程：PDF提取清洗与可视化

网络舆情分析系统：从数据采集到情感分析的毕设实践

前端代码审查自动化：open-code-review 规则引擎与 CI/CD 实践指南

低成本智能养虾系统：物联网技术实现自动化管理

7天AI扫盲路线图：技术人快速掌握大模型、Agent与AI应用

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？