Deepseek Harness 推理级别完全指南

DeepSeek Harness

推理级别完全指南

low · medium · high · xhigh · max

五个级别的定位、优缺点与配置方法

适用产品	LinkTokenView 桌面版（DeepSeek Harness）
文档版本	v1.0
整理日期	2026 年 10 月 28 日
依据	本机 DSH 安装包源码逐行核对

一　为什么需要推理级别

二　五个级别的总览

三　逐级详解：定位、优点、缺点、配置

四　四个必须知道的机制

五　配置方法：四个入口

六　选型建议与成本控制

七　常见问题

八　数据来源与口径说明

阅读提示：本文所有配置写法均来自本机安装包的源码与 settings.yaml，不是通用推测。若你的版本较新，字段名请以实际安装目录为准。

同一个模型，面对「把这句英文翻成中文」和「找出这段并发代码里的竞态条件」，需要投入的思考量完全不同。推理级别（reasoning effort）就是让调用方显式表达「这件事值不值得多想一会儿」的开关。

级别越高，模型在给出最终答案之前用于思考的预算越多，通常表现为：推理链路更长、对边界情况考虑更全、复杂任务的一次通过率更高；代价是首字延迟变大、输出 Token 变多，账单随之上升。

在 DeepSeek Harness 里，这个开关不是一个布尔值，而是一条有序的级别链。理解这条链的顺序和落地规则，比记住某个级别「好不好」更有用。

1.1　五个可见级别与两个隐级

DSH 内部实际定义了七个级别，按强度升序排列：

EXTENDED_THINKING_LEVELS = ["off", "minimal", "low", "medium", "high", "xhigh", "max"]                               ↑ 隐级                    ↑____ 本文重点 ____↑

其中最左侧的 off 与 minimal 属于隐级：off 表示完全关闭思考，minimal 表示极低强度。二者一般不出现在常规选型里，界面上是否展示取决于模型是否声明。本文聚焦中间的五个级别。

先给一张总表，后面再逐级展开。表中「强度」等列为定性排序，用于相对比较，不是实测基准。

级别	一句话定位	推理强度	延迟	成本	典型用途
low	快速直给	低	最快	最低	翻译、改写、格式转换、简单检索问答
medium	轻量权衡	中低	快	低	一般性分析、代码补全、单步任务
high	默认均衡	中	中等	中等	多步开发任务、常规工程、日常主力
xhigh	加强推理	高	较慢	较高	复杂推理、疑难缺陷、严谨论证
max	全力思考	最高	最慢	最高	架构决策、最难问题、质量优先

表 1　五个级别总览（强度/延迟/成本为定性排序）

下面每一级都按「定位 → 优点 → 缺点 → 适用 → 配置」展开。配置写法在第 3.1 节给全，后续小节只标注差异，避免重复。

3.1　low：快速直给

定位：把模型当作高效执行器，而不是思考者。DSH 源码里对 low 的官方描述是「Prefer for routine or latency-sensitive tasks」，即优先用于例行任务或对延迟敏感的场景。

优点

· 响应最快。思考预算被压到最低，首字延迟基本等于网络往返时间。

· Token 消耗最低。思考产生的 Token 同样计费，low 是五个级别里最省的。

· 行为可预测。不会因为「想太多」而在简单任务上绕远路或过度解释。

缺点

· 复杂任务上明显吃亏：多步推理容易漏掉约束条件，长链条计算更容易出错。

· 不适合需要自我校验的场景。没有额外的思考空间，就难以发现自己的第一反应有问题。

· 遇到需要权衡的取舍题时，容易给出「正确但浮于表面」的答案。

适用场景

批量数据清洗、字段抽取、格式转换、翻译、短文本摘要、以及任何「你本来就知道答案长什么样」的例行工作。

配置方法

四种入口（界面、全局默认、模型声明、子 agent 参数）的完整写法见第五章。以全局默认为例：

agent-default-model:   provider: linktokenview-official   model: deepseek-v4.1-flash   reasoningEffort: low

3.2　medium：轻量权衡

定位：介于「直给」与「认真想」之间的中间档。DSH 为它保留了独立级别，但在 dsh-llm-deepseek 适配器的四个标准档位（off/low/high/max）里并不单独出现——它是否可选，取决于模型是否声明支持。

优点

· 性价比区间的低位。相比 low 能处理稍复杂的多条件问题，成本上升幅度可控。

· 比 low 更少出现「理解偏了但答得很快」的尴尬。

· 适合高频调用的线上链路：既想有一点推理余量，又不能容忍明显延迟。

缺点

· 定位最模糊。它和 low、high 的差别在体感上不如相邻两档明显，容易变成「选它也不会错，但也没占便宜」。

· 部分模型不声明该级别，此时请求会按第五章的规则被就近改派。

适用场景

一般性代码补全、单文件重构、中等长度的文档分析、需要少量判断但不涉及复杂权衡的客服问答。

配置方法

# 全局默认换成 medium agent-default-model:   reasoningEffort: medium

3.3　high：默认均衡

定位：出厂推荐的平衡点。源码对 high 的描述是「The default balance for most tasks」——多数任务的默认平衡档。若无特别指定，很多链路最终落在这里。

优点

· 覆盖面最广。绝大多数开发与分析任务在这一档就能拿到接近上限的质量。

· 风险最低的默认值。不确定该选什么时，选 high 几乎不会后悔。

· 与工具调用配合稳定：多步任务里既要推理又要调工具时，这一档的节奏最不容易失衡。

缺点

· 对极简单任务而言是浪费：翻译一句话也用 high，成本与延迟都不划算。

· 对极难任务仍可能不够：遇到真正烧脑的推理题，high 会显得「想到了但没想透」。

适用场景

日常开发主力档：写功能、改缺陷、读代码库、做方案对比、写技术文档。

配置方法

界面上的推理等级面板直接选 High 即可只影响当前会话；若要长期固定为默认：

agent-default-model:   reasoningEffort: high

3.4　xhigh：加强推理

定位：在 high 之上再加一档。这个级别有一个关键特性——它只在模型显式声明时才可用，不会因为模型「看起来支持推理」就自动出现。

源码里的判定逻辑是：对 xhigh 与 max 这两个级别，必须存在显式映射才认为支持；其余基础级别缺省即视为支持。

// pi-ai/dist/models.js:554 const mapped = model.thinkingLevelMap?.[level]; if (mapped === null) return false; if (level === "xhigh" || level === "max") return mapped !== undefined; return true;

优点

· 复杂推理的质量台阶明显：多约束、需要反复推翻假设的问题，在这一档更容易收敛到正确解。

· 适合作为「疑难专用档」：日常用 high，遇到硬骨头临时切到 xhigh，成本可控。

· 相比 max 更易获得支持：声明了 xhigh 的模型通常也覆盖绝大多数强推理场景。

缺点

· 可用性依赖模型声明。很多模型只到 high，请求 xhigh 会被就近改派，你不会收到报错，只会拿到实际低一档的结果。

· 在预算型适配器上会被压平。例如 Bedrock 的 Claude 路径会把 xhigh 与 max 一律折算成 high。

· 延迟和成本都明显高于 high，不适合放在高频线上链路里。

适用场景

疑难缺陷定位、复杂算法设计、严谨的论证与评审、需要「先想清楚再动手」的长任务。

配置方法

先在模型能力声明里把 xhigh 打开，界面上才会出现这个选项：

llm-pi-ai:   providers:     linktokenview-official:       models:         - id: deepseek-v4.1-flash           reasoningEfforts:             low: low             medium: medium             high: high             xhigh: xhigh             max: max

3.5　max：全力思考

定位：质量优先的最后一档。源码描述为「Reserve for the hardest quality-first tasks」——留给最难的、以质量为先的任务。

优点

· 在正确率比成本更重要的场合，这是唯一合理的选项。

· 面对开放式难题时，更愿意探索多条路径再收敛，而不是抓住第一个想法就往下写。

· 适合作为「交付前复核」档：用 max 审一遍 high 的产出，常能发现遗漏。

缺点

· 最慢最贵。思考链路拉长，输出 Token 显著增加，账单压力直接体现。

· 收益递减。对简单任务而言，max 相对 high 的提升微乎其微，纯属浪费。

· 同样受「必须显式声明」与「适配器折算」两条规则约束，未必真的按 max 执行。

适用场景

架构决策、根因分析、高风险变更的方案评审、以及任何「答错一次的成本远高于多花几毛钱」的场景。

配置方法

与 xhigh 相同，需在 reasoningEfforts 中声明；单次临时使用可走子 agent 参数：

subagent(description="根因分析", prompt="...", reasoning_effort="max")

3.6　优缺点速查

级别	最突出的优点	最需要警惕的缺点
low	最快、最省、行为最可预测	多步推理容易漏条件，难自我校验
medium	成本可控且有少量推理余量	与相邻档体感差异小，定位模糊
high	覆盖面最广，默认不后悔	简单任务上是浪费，极难任务仍不够
xhigh	复杂推理质量台阶明显	依赖模型声明，常被就近改派为 high
max	质量上限最高，适合复核	最慢最贵，收益随任务变简单而递减

表 2　五个级别优缺点速查

级别不是「写了就一定生效」。以下四条规则决定了你实际拿到的是哪一档，不了解它们，配置很容易白写。

4.1　可选级别由模型声明决定

一个模型能提供哪些级别，由它的思考级别映射表决定。声明了就是支持，没声明就是不支持；不支持就不会出现在界面的推理等级面板里。

在配置层面对应的字段是 reasoningEfforts：写什么，映射表就记什么；写成 null 或干脆不写，该级别即被标记为不支持。只有 off 比较特殊——off 不给值时表示「不发任何思考参数」。

4.2　请求的级别会被就近改派

如果你请求的级别当前模型不支持，DSH 不会报错，而是按「先向上、再向下」的顺序找一个可用级别顶上。这条规则在 clampThinkingLevel 里实现。

实践含义：你写 xhigh 却只拿到 high 的效果，往往不是模型变弱，而是这个模型根本没有 xhigh 这一档。排查时先看模型声明，再怀疑模型能力。

4.3　预算型适配器会压平高档位

部分适配器把思考预算折算成固定 Token 数，此时高于其上限的级别会被压回上一档。例如 Bedrock 的 Claude 路径里，xhigh 对应固定预算，而 xhigh 与 max 的请求都会被统一按 high 处理。

因此「我在别的模型上 max 效果很好」不能直接迁移到这条路径上，比较跨模型效果时必须先确认实际生效级别。

4.4　Default 与继承

界面上的推理等级显示 Default 时，表示不显式指定，沿用厂商或线路的默认值，而不是「没有思考」。子 agent 未显式指定时会继承父 agent 的级别；但如果子 agent 换了模型或线路，继承来的级别会被丢弃，改用新模型的默认档——这条细节决定了委派任务时子 agent 的真实思考强度。

推理等级可以在四个位置指定，作用范围从小到大依次是：单次委派、当前会话、全局默认、模型能力声明。

5.1　界面：模型选择器 → 推理等级

最直接的方式。点开界面顶部的模型名，菜单里除了模型列表，还有一个「推理等级」面板；选定后，触发按钮上会显示「模型名 · 级别」，例如 deepseek-v4.1-flash · High。

· 只影响当前会话，不写入配置，重启后回到默认。

· 面板里列出的是该模型声明支持的全部级别；若模型不支持任何思考级别，面板会提示为空。

· 选项里可能包含 Default，表示沿用默认值而非关闭思考。

5.2　全局默认：agent-default-model

想让自己每次新建会话都落在同一档，就改 settings.yaml：

# settings.yaml agent-default-model:   provider: linktokenview-official   model: deepseek-v4.1-flash   reasoningEffort: high

这是最省事的一处配置：只写一行，对之后所有新会话生效，且不影响已有会话的历史记录。

5.3　模型能力声明：reasoningEfforts

决定「哪些级别在界面上可选」的地方。要逐级写出该模型在传输层实际接受的值：

# settings.yaml llm-pi-ai:   providers:     linktokenview-official:       models:         - id: deepseek-v4.1-flash           name: deepseek-v4.1-flash           input: [text, image]           reasoningEfforts:             low: low             medium: medium             high: high             xhigh: xhigh             max: max

· 键是级别名，值是发给模型的传输值；两者通常同名，但不强制相同。

· 不支持的级别写 null 或直接省略，等价于「该档不可用」。

· 把 reasoningEfforts 设为 false，表示这是一个不做思考的模型。

· 至少要声明一个 off 之外的有效级别，否则配置校验不会通过。

5.4　子 agent：reasoning_effort 参数

委派任务时可以单独指定，让子 agent 用与父 agent 不同的强度：

subagent(   description="复杂缺陷根因分析",   prompt="...",   provider="linktokenview-official",   model="deepseek-v4.1-flash",   reasoning_effort="xhigh" )

· 只影响这一次委派，不改变当前会话的设置。

· 不写 provider/model 时继承父 agent 的设置；一旦换了模型或线路，未显式指定的级别会被丢弃。

· 适合「日常用 high、疑难任务临时开 xhigh/max」的成本策略。

5.5　其他入口：SDK 与编辑器协议

以 SDK 方式集成时，推理等级作为 Agent 选项传入，字段名为 reasoningEffort；通过编辑器协议（ACP）接入时，对应的配置项 id 是 reasoning_effort。两条路径的取值与界面上的级别名一致。

入口	位置	字段	作用范围
界面	模型选择器 → 推理等级	—	当前会话
全局默认	settings.yaml	agent-default-model.reasoningEffort	所有新会话
能力声明	settings.yaml	models[].reasoningEfforts	决定可选范围
子 agent	工具调用参数	reasoning_effort	单次委派
SDK / ACP	代码 / 协议	reasoningEffort / reasoning_effort	该次调用

表 3　五个配置入口对照

6.1　默认 high，按需上下调

把 high 作为全局默认，是绝大多数使用者的最优解。在此基础上做两类局部调整：简单批处理降到 low / medium 省钱，疑难任务临时升到 xhigh / max 保质量。

6.2　用「可复现的错例」作为升级依据

升级不应该是感觉。更可靠的做法是：先用 high，遇到明确失败且能复现的案例，再对同一输入切到 xhigh 或 max 对比结果。如果高档位也没能解决，说明瓶颈不在推理预算上，继续加档只是白花钱。

6.3　注意三个隐性成本来源

· 思考 Token 也计费。升级级别带来的不只是延迟，还有可观的输出侧用量。

· 高档位的输出更长。同样的任务，max 可能比 low 多出数倍 Token。

· 被改派的级别会误导评估。如果没确认实际生效级别，很容易把「模型不行」误判成结论，实际原因是这一档根本没生效。

Q　我在界面上找不到 xhigh / max，是版本问题吗？

A　先看模型声明。这两个级别必须被显式声明才可用，未声明时界面上不会出现该选项，这是设计行为而非缺陷。在 reasoningEfforts 里补上对应条目即可。

Q　为什么我选了 max，感觉和 high 差不多？

A　两种情况：一是该模型没声明 max，请求被就近改派成了 high；二是所用适配器把 max 折算了固定预算，与 high 持平。两者都不会报错，需要核对实际生效级别。

Q　推理级别会影响输出长度上限吗？

A　不影响 maxTokens 这类硬上限。级别只影响思考预算，二者是不同维度。

Q　子 agent 会自动用和我一样的级别吗？

A　会继承，但只要子 agent 换了模型或线路，继承值会被丢弃并改用新模型的默认档。

Q　批量任务应该用哪一档？

A　优先 low 或 medium。批量任务的特点是量大、单条简单、可容忍个别失败，这一档的性价比最高。

本文的技术结论来自对本机 DSH 安装包源码的逐处核对，主要依据如下：

· @earendil-works/pi-ai · dist/models.js:550 — 七个级别的定义顺序

· @earendil-works/pi-ai · dist/models.js:551 — 级别支持判定（xhigh/max 需显式声明）

· @earendil-works/pi-ai · dist/models.js:563 — 不支持时就近改派的实现

· @earendil-works/pi-ai · dist/api/simple-options.js:45 — 高档位被折算为 high

· @earendil-works/pi-ai · dist/api/bedrock-converse-stream.js — xhigh 固定预算与折算

· @earendil-works/pi-ai · dist/api/anthropic-messages.js:637 — xhigh 的可用模型范围

· @deepseek-ai/dsh-llm-deepseek · lib/index.js:1417 — off/low/high/max 的官方描述

· @deepseek-ai/dsh-llm-pi-ai · lib/index.js:546 — reasoningEfforts → 思考级别映射规则

· @deepseek-ai/dsh-llm-pi-ai · lib/index.js:295 — THINKING_LEVELS 常量

· @deepseek-ai/dsh-agent-default-model · lib/index.js:16 — 全局默认字段

· @deepseek-ai/dsh-acp · lib/index.js:306 — 编辑器协议配置项 id

· @deepseek-ai/dsh-client-ui-model-selection · lib/client.js — 界面文案与 Default 语义

口径提醒

· 文中「强度/延迟/成本」的排序为定性描述，指的是相对关系，不是实测基准值。

· DSH 本身不规定每个级别的思考 Token 预算，具体预算由各模型与线路侧决定；源码中唯一硬编码的预算数字出现在 Bedrock 的 Claude 路径。

· 字段名与行号对应 2026 年 10 月 28 日的安装版本；版本更新后请以实际安装目录为准。

Link tokens, view the future

www.linktokenview.com

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/linktokenview/article/details/169925513