qwen-code 模型推理能力清单为 Qwen Hybrid-Thinking 模型实现准确的 Thinking/Effort 控制【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读qwen-code 在接入阿里云 Coding Plan 与 Token Plan 模型时面临一个关键工程问题不同 Qwen 模型的思考控制方式并不一致——qwen3.8-max支持离散的推理努力级别reasoning effort而qwen3.7-plus、qwen3.6-flash等 Hybrid-Thinking 模型只支持开启/关闭思考、使用整数思考预算。本文基于 model-reasoning-capabilities.md 设计方案结合仓库中真实的能力注册表、ACP 配置生成与 WebShell 渲染实现说明 qwen-code 如何用一份精确模型 ID 能力元数据的清单避免向不支持努力级别的 API 发送虚构的控制参数并确保旧版客户端与旧版 daemon 的兼容行为。一、背景为何需要能力清单而非统一的 Effort 控件qwen-code 的推理控制遵循一套统一的努力级别阶梯low/medium/high/xhigh/max见 packages/core/src/core/reasoning-effort.ts。但不同提供商的 Chat Completions API 使用不同的线上字段reasoning_effort、enable_thinking、thinking_budget等且不同模型支持的取值子集差异巨大。如果对某个模型注册了它根本不支持的努力级别控件上就会出现一个选中了但实际不会发送的假选项。因此本设计的核心目标Goal是为常见的阿里云 Coding Plan 与 Token Plan 模型暴露准确的推理控制不虚构其 Chat Completions API 不支持的 effort 级别。这份设计文档同时是 gpt-5-reasoning-effort.md 的配套扩展——GPT 部分复用共享 core 定义中的能力模块而本清单是 Qwen 系模型的权威来源二者保持一致。二、研究结论Qwen 家族的两种推理控制模型设计文档的调研阶段Research区分了阿里云对 Qwen 模型的两种官方文档化行为qwen3.8-max原生支持离散的推理努力级别low、medium、xhigh可通过reasoning_effort字段直接控制qwen3.6-plus、qwen3.6-flash、qwen3.7-plus、qwen3.7-max、qwen3.5-plus属于 Hybrid-Thinking 模型可以启用/禁用思考但思考强度使用整数思考预算thinking budget而非离散的 Chat Completions effort 级别。据此设计文档给出了已注册的能力表本文完整继承并附源码佐证精确模型 IDThinkingEffort 控制qwen3.8-maxOptionallow、medium、xhighqwen3.7-maxOptionalNoneqwen3.7-plusOptionalNoneqwen3.6-plusOptionalNoneqwen3.6-flashOptionalNoneqwen3.5-plusOptionalNone这一结论在仓库的实际注册表中得到完整印证。例如 packages/core/src/providers/presets/alibaba-token-plan.ts 中{ id: qwen3.8-max, capabilities: { reasoning: { thinking: true, efforts: [low, medium, xhigh], defaultEffort: xhigh, canDisable: false, disableField: reasoning_effort, }, }, contextWindowSize: 1000000, enableThinking: true, thinkingMandatory: true, modalities: { image: true, video: true }, }, { id: qwen3.7-plus, capabilities: { reasoning: { thinking: true, toggleOnly: true, disableField: enable_thinking, }, }, contextWindowSize: 1000000, enableThinking: true, },注意两个细节qwen3.8-max还声明了canDisable: false与thinkingMandatory: true思考不可关闭只能选择努力级别而 Hybrid 模型则通过toggleOnly: true标记只开关、无级别。同样的注册也存在于 packages/core/src/providers/presets/alibaba-coding-plan.ts覆盖qwen3.5-plus、qwen3.6-plus、qwen3.7-plus等 Coding Plan 模型。三、能力类型从分档推理到纯开关推理的统一建模设计文档的核心思想是模型清单区分分档推理tiered reasoning与纯开关推理toggle-only reasoning并且继续按精确模型 ID 精确匹配。这一区分直接体现在类型定义 packages/core/src/models/types.ts 中export type ModelReasoningCapabilities ( | { toggleOnly: true } // 纯开关无 effort 列表 | { toggleOnly?: false; efforts: readonly ReasoningEffort[]; // 分档支持的努力级别 defaultEffort?: ReasoningEffort; } ) { thinking: true; canDisable?: false; // 思考是否可关闭 disableField: enable_thinking | reasoning_effort | thinking; };toggleOnly: true的模型没有efforts列表控件层面不出现任何 effort 档位分档模型必须声明efforts从统一阶梯中取子集与可选的defaultEffortdisableField声明关闭思考时实际发送的线上字段canDisable: false表示该模型思考强制开启。对应的解析函数parseModelReasoningCapabilities位于 packages/core/src/core/reasoning-effort.ts它会对来自设置文件的输入做防御性校验thinking必须为true、disableField必须属于三种合法取值之一、toggleOnly/canDisable类型必须合法、efforts必须是统一阶梯内不重复的子集、defaultEffort必须包含在efforts内。任何一项不满足都返回undefined——让非法能力保持模型原有的行为而不是扭曲线上请求。四、ACP 配置选项两种模型产出同构的none/default语义设计文档规定Toggle-only 模型与分档模型产出相同的 ACP 配置选项但只有两个值none和default。选择none关闭本次 live 会话的思考选择default清除会话覆盖让既有的模型或 provider 默认值生效。这一逻辑由 packages/cli/src/acp-integration/model-configuration.ts 的buildModelReasoningConfigOption实现。它把能力换算成 ACP 的SessionConfigOption选项 ID 统一为reasoning_effort类型select类别thought_level若模型可关闭思考则提供noneThinking off描述为 Disable thinking for this session对 toggle-only 模型只再提供一个defaultThinking on描述为 Use the model or provider thinking default——即只有两档开关对分档模型则提供default加每个支持的努力级别low/medium/xhigh等显示名来自REASONING_EFFORT_NAMES能力元数据写入_meta[qwenCode/reasoning]其中toggleOnly: true、canDisable、thinkingMandatory等字段供 daemon 与 WebShell 消费。选择值的落盘与恢复逻辑也在这个模块applyReasoningSelection中none对应generation.reasoning falsedefault对应清除effort字段或回退到默认推理配置而resolvePersistedReasoningConfigState负责把持久化的选择解析回{ enabled, effort, thinkingMandatory }状态。CLI 侧还有一份独立的MODEL_CONFIGURATIONS清单model-configuration.ts同样把qwen3.5-plus到qwen3.7-max标为toggleOnly把qwen3.8-max标为[low,medium,xhigh]且默认xhigh与 provider 预设保持一致。五、WebShell 映射空 effort 列表 仅显示 Thinking 开关设计文档对 WebShell 的要求是daemon 在 ACP 元数据中标记 toggle-only 选项WebShell 将其映射为空 effort 列表只渲染 Thinking 开关并在模型芯片上显示Thinking或Thinking Off。既有的分档控件保留其 effort 行与标签。映射实现在 packages/web-shell/client/daemon/session/mappers.ts 的mapReasoningControls中从 ACP 配置选项中读取reasoning_effort选项解析出none/default/effort 值列表并检查_meta[qwenCode/reasoning]。当toggleOnly true时返回{ enabled: currentValue ! none, effort: default, efforts: [], // 空 effort 列表界面不渲染档位 ...(canEnable false ? { canEnable: false } : {}), ...(thinkingMandatory ? { canDisable: false } : {}), }于是前端拿到efforts: []后只会渲染开/关开关而qwen3.8-max这类分档模型则拿到efforts: [low,medium,xhigh]继续渲染 effort 下拉行。同时canDisable: false/canEnable: false会禁用相应的关闭/开启动作防止对强制思考模型发起无效的关闭请求。对应的前端行为测试可在 packages/web-shell/client/App.test.tsx 与 packages/web-shell/client/daemon/session/mappers.test.ts 中查阅。六、请求管线enable_thinking与reasoning_effort的线上分歧能力声明最终要落到线上请求。Qwen 系 Hybrid 模型与分档模型在 DashScope 兼容端点上的字段分歧由 packages/core/src/core/openaiContentGenerator/provider/dashscope.ts 处理Hybrid 模型读取enable_thinking开/关与thinking_budget整数思考预算见该文件第 49–95 行对enable_thinking | reasoning_effort | thinking_budget三字段的采样选择逻辑qwen3.8-max家族读取分档的reasoning_effort代码注释明确说明该家族不接受reasoning_effort与thinking_budget同时出现并且该家族的开关折叠为开/关后reasoning_effort优先于旧行为第 559–586 行附近第 642–686 行实现了跨层冲突消解例如显式enable_thinking: false会被转换为该家族规范的关闭形态reasoning_effort: none同时丢弃冲突的thinking_budget字段。这套冲突消解机制确保了控件上看到的值与线上真正发送的字段一致——这正是设计文档 Goal 中不虚构 API 不支持的 effort 级别的底层保证。对请求层行为如applyReasoningSelection的覆盖合并、clearReasoningRequestOverrides对 Qwen 专属字段的清理都有对应测试覆盖在 packages/core/src/core/reasoning-effort.test.ts。七、延迟注册的模型不携带能力上下文的 Provider 路径不做宽泛匹配设计文档明确列出了不注册的模型范围避免在能力上下文不完整时显示选中值无法正确发送的控件DeepSeek、GLM、Kimi、Grok其推理参数或默认值在直连端点与阿里云端点之间不一致而当前清单只按模型 ID 为键。在 provider 路径携带相应能力上下文之前注册它们可能显示一个值根本发不出去的控件Qwen 别名、带日期的变体、coder 模型、以及预设默认值不同于模型默认值的模型它们需要独立的能力或解析后配置语义而非放宽匹配规则。这一保守策略同样体现在类型与解析的防御性上getModelConfigurationmodel-configuration.ts只有在解析出显式能力、GPT 能力表命中、或模型 ID 精确命中MODEL_CONFIGURATIONS时才返回能力其余情况一律返回undefined交由通用行为兜底。八、兼容性旧客户端与旧 daemon 的安全降级设计文档的 Compatibility 章节规定了向后兼容行为这在 ACP 生态中尤为重要旧版 ACP 客户端可以继续把该选项当作普通 select 处理——none/default/effort 值本身就是合法的 select 选项不需要新协议知识旧版 daemon 不会宣传 toggle-only 元数据因此当前版本的 WebShell 在能力未显式声明时会保持控件隐藏不会凭空出现一个残缺的推理开关。换句话说这是一个能力显式声明才展示、旧栈自动降级的渐进式演进设计。配套的 GPT 扩展gpt-5-reasoning-effort.md遵循同一套共享能力模块与 ACP 元数据约定保证 GPT 系模型与 Qwen 系模型在 CLI、WebShell、请求管线上行为一致。九、如何在当前仓库验证这套设计若想亲自验证或扩展这份能力清单可在仓库中按以下路径追踪完整调用链能力声明源头packages/core/src/providers/presets/alibaba-token-plan.ts 与 packages/core/src/providers/presets/alibaba-coding-plan.ts 中的ModelSpec.capabilities.reasoning类型与解析packages/core/src/models/types.ts 与 packages/core/src/core/reasoning-effort.tsACP 配置生成与选择落盘packages/cli/src/acp-integration/model-configuration.tsbuildModelReasoningConfigOption、applyReasoningSelection、resolvePersistedReasoningConfigStateWebShell 控件映射packages/web-shell/client/daemon/session/mappers.ts线上字段分歧消解packages/core/src/core/openaiContentGenerator/provider/dashscope.ts测试佐证packages/core/src/core/reasoning-effort.test.ts含clampReasoningEffort的钳制用例与toggleOnly畸形输入的拒绝用例、packages/web-shell/client/daemon/session/mappers.test.ts。十、小结模型推理能力清单是 qwen-code 在统一推理控件体验与差异化 provider 能力之间取得平衡的关键设计以精确模型 ID 为键用toggleOnly/efforts/canDisable/disableField四类元数据描述能力统一生成 ACP 的none/default选择语义再由 daemon 元数据驱动 WebShell 渲染为仅开关或开关档位两种形态最终在 DashScope 兼容端点上把控件选择翻译为正确的enable_thinking或reasoning_effort字段。对于无法确认能力的模型设计选择宁可延迟注册、隐藏控件也绝不在请求中发送无效参数——这套宁缺毋滥的能力声明哲学正是推理控制准确性的根本保障。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
