DeepSeek Harness 这次更新对平时折腾多 Agent 编排的人来说是实打实的利好——子 Agent 终于可以独立设置推理强度reasoning effort了。以前版本里你给主 Agent 配一个推理档位所有子 Agent 都会跟着继承要么全局 high 烧 token 烧时间要么全局 low 让需要深想的子任务一起变水。这次更新把配置粒度干到了子 Agent 一级终于可以根据任务类型分档施策而不是被一个全局开关绑死。这篇文章我会从更新背景、配置原理、实测参数到常见坑位完整过一遍。适合正在用 DeepSeek Harness 做多智能体任务的开发者也适合刚准备上手、对 Agent 推理配置还没摸清的朋友。整个过程基于我自己的实际升级和测试记录不是官方的发布公告复述希望能给你一个可参考的落地方案。说实话我并不是第一次在这个工具里被“全局推理强度”坑到。之前跑一个自动整理周报的流程主 Agent 负责汇总和润色子 Agent 里面挂了三个数据源采集器明明只是去调 API 拿数据、格式化一下文本结果全都按主 Agent 的 high 档去思考每个子任务都要多花十几秒。那会儿我只能在“整体质量”和“整体成本”之间二选一非常憋屈。这次更新算是把选择权还回来了。1. 更新背景与整体设计思路1.1 旧版本为什么难用全局继承的两个极端在说明这次更新之前有必要先聊聊旧版本的机制。以前的 DeepSeek Harness 把推理强度当作一个顶层配置项在 Agent 的全局配置里统一设定然后所有子 Agent 默认继承这个值。听起来很省事实际用起来却两头难受如果你把全局档位设成 high那么所有子 Agent 都会被拉到高推理档位。哪怕子 Agent 干的是“搜一下文档”“读一条日志”“把时间格式转换一下”这种根本不值得深度思考的活它也会按照 high 档去消耗 token 和时间。反过来如果你为了控制成本把全局设成 low遇到真正需要缜密推理的子任务——比如代码审查、复杂数据建模——子 Agent 的输出质量就会明显下降经常出现“思考不充分”的半吊子结果。我在测试里见过最典型的情况全局 low 时一个代码审查子 Agent 漏掉了明显的空指针风险因为它只做了浅层扫描没有展开完整的调用链分析。这种事一次两次还能接受次数多了你就知道全局一档的方案真的不适合复杂流程。更麻烦的是在一个真实的多 Agent 流程里不同类型子任务的推理需求差异非常大。主 Agent 规划路线需要全局视野high 是合理的但下游的信息抽取、格式转换、工具调用这些子任务往往 low 就够而最后的深度审校、方案生成又需要 high。全局一档的机制天然把这三者绑死怎么调都有人吃亏。这就像是团队里所有人都按同一个工作强度干活既浪费又好高骛远实际效率并不高。1.2 新版本的关键变化配置继承与覆盖并存这次更新的核心是把推理强度从“全局单档”改成了“全局默认 子 Agent 覆盖”的双层模型。简单来说顶层配置仍然保留一个默认推理强度作为兜底同时每一个子 Agent 都可以在自己的配置块里单独指定reasoning_effort字段覆盖掉全局值。这样主 Agent 负责规划时用 high信息采集类子 Agent 用 low深度分析类子 Agent 用 high互相不打架。这个设计我觉得比彻底改成“各自独立、无默认值”的方式更务实。因为在实际使用中总有一些子 Agent 你没心思去细配或者临时加进来的新子任务你希望它先用全局默认值跑起来。如果我必须给每个子 Agent 都手动填一个推理强度才能创建任务操作成本就太高了。保留默认值作为兜底既照顾了精细控制的需求也照顾了快速上手的需求算是在灵活性和易用性之间取了个平衡。注意新版本对“配置继承”的口径也做了更清晰的区分。父 Agent 的推理强度不再自动传递给子 Agent子 Agent 若没有显式设置会回落到全局默认值。换句话说如果你想保持“所有子 Agent 都跟随主 Agent”的旧行为需要在全局配置里把默认值设成和主 Agent 一致而不是继续依赖继承。这个改动会让第一次升级的人有点不习惯但长期看更合理。2. 推理强度到底在控制什么2.1 从“心算”到“打草稿”推理强度的底层逻辑推理强度reasoning effort是模型服务端的一个采样控制参数它决定大模型在生成最终答案前愿意投入多少计算资源和 token 去进行“内部思考”。档位越低模型越倾向于快速作答回答路径短、token 消耗少档位越高模型会展开更长的链式思考尝试更多中间步骤甚至对同一个问题反复推敲。你可以把它理解为做题时的“打草稿”心算适合 11但遇到复杂题目不打草稿就很容易出错可打草稿总归要费纸费时间。一个容易误会的点推理强度不等于“答案质量”。它控制的是模型在给定能力范围内的“努力程度”而不是把模型本身变强。一个中等推理强度的 deepseek-chat面对一道超纲题再努力也可能答错而一个高推理强度的模型如果任务本身很简单也只是白白多花 token并不会让结果更“正确”多少。所以合理的做法是把推理强度留给真正需要推理深度的任务简单任务用低档即可。2.2 为什么子 Agent 的推理强度值得单独配置多 Agent 场景下父 Agent 和子 Agent 的任务性质差异很大。主 Agent 通常承担任务分解、路线规划、结果仲裁这类“决策密集”工作推理强度高一点整体方案的合理性通常会有明显提升。但子 Agent 往往是被派去做具体执行的拉取一个网页、查询一条数据库记录、对一段文本做格式化摘要这些操作如果也按 high 档去跑等于给每道小题都做一遍完整推理延迟和成本都被放大。我在实际使用中最直观的感受是把信息采集类子 Agent 的推理强度从 high 降到 low 之后单次调用的响应时间几乎缩短了一半以上token 消耗也低了不少但采集到的字段、提取出的摘要质量跟以前并没有本质差别。这说明之前那部分推理开销确实有不少是浪费的。而相对的把“代码审查”这类子 Agent 保持 high它的输出建议明显更具体、更少空话这份收益才值得为推理强度买单。这就是子 Agent 独立配置推理强度的核心价值你可以按每个子任务的实际需求把预算花在刀刃上。2.3 推理强度对成本和延迟的影响面除了直接的单次调用开销推理强度还会间接影响上下文和后续流程。高推理强度会产生更长的一段内部思考内容这些内容有的会进入上下文进一步抬高后续请求的 token 基数在多 Agent 串联流程里这个影响会被逐级放大。所以给所有子 Agent 统一 high表面上只是“每次多花点钱”实际上整个任务链的延迟、上下文占用都会跟着变高。我在一次压测里做过粗略统计当流程里有 3 个子 Agent 都设成 high 时主 Agent 最后接收到的汇总上下文里有接近 40% 的内容是子 Agent 的中间思考过程而不是最终结果。这部分内容对主 Agent 的决策并不全是正向帮助有些甚至算噪音。把不需要高推理的子 Agent 降下来之后主 Agent 的上下文变得更干净后续处理的准确率反而有轻微提升。这也是我后来坚决给子 Agent 分档配置的原因。3. 配置实操给子 Agent 设置独立推理强度3.1 升级与配置前的准备在配置之前先确认你的 DeepSeek Harness 版本。这次更新只在 0.9.6 以上的版本里开放了子 Agent 级reasoning_effort字段旧版本即使写进配置文件也不会报错但会静默忽略。如果你还没升级可以通过项目仓库的 release 页面或者升级命令处理升级完记得用harness --version或者界面“关于”确认一下版本号。这个步骤看起来多余但真的能省下后面排查配置不生效的时间。升级完成之后我建议先备份一份当前配置文件。因为新版本对继承逻辑做了调整直接拿旧配置跑可能出现“子 Agent 推理强度突然变了”的错觉——其实不是突然变了是默认继承规则改了。备份之后你就有一个明确的对照基线排查起来也方便。我个人的习惯是升级前把旧配置文件复制一份存到config.backup.yaml确认新版本跑通之后再删。3.2 在配置文件中添加子 Agent 推理强度DeepSeek Harness 的 Agent 配置支持 YAML 和 JSON 两种格式我用的是 YAML。一个典型的配置块长这样version: 0.9.6 agent: default_reasoning_effort: high # 全局兜底档位 max_tokens: 8192 # 主 Agent 的最大输出 sub_agents: - name: doc-search description: 文档检索与信息抽取 model: deepseek-chat reasoning_effort: low # 覆盖全局值轻量检索用 low max_tokens: 4096 - name: deep-review description: 深度代码审查 model: deepseek-reasoner reasoning_effort: high # 复杂审查用 high max_tokens: 8192 - name: format-helper description: 文本格式整理 model: deepseek-chat # 不写 reasoning_effort将使用全局默认值 high注意几个关键点。第一reasoning_effort和max_tokens是相互配合的不是独立变量。你把推理强度设成 high却把 max_tokens 限制得很小模型思考到一半就被截断输出质量反而会更差。我在后面排障部分会再展开。第二字段名是reasoning_effort注意下划线不是连字符。某些配置文件模板里可能混用reasoning-effort和reasoning_effort新版本只认下划线版本写错了不会报错只是不生效特别坑。第三子 Agent 没有显式配置时回落全局默认值所以如果你希望某些“漏网之鱼”也用 low最好直接把全局默认值设成 low再单独把需要高推理的子 Agent 挑出来设 high这样比反过来更不易出错。如果你用的是桌面版入口通常在 Agent 配置面板里选中某个子 Agent展开“高级参数”就能看到推理强度下拉框。这里的选项一般是 low / medium / high部分模型还支持 extra-high如果你在接本地模型选项可能不太一样。界面配置跟 YAML 是同一个底层字段改完之后效果一样看个人习惯选一种方式就行不建议两边同时维护容易对不上。3.3 参数选择的经验建议什么任务配哪一档聊完配置语法来说说怎么选档。我没有标准答案但根据我的使用经验可以给一个参考矩阵。任务类型推荐推理强度原因网页抓取、文档检索、JSON 解析low信息获取为主不依赖复杂推理摘要生成、文本润色、格式转换low / mediummedium 适合需要理解上下文语义的摘要纯格式转换用 low代码生成、SQL 编写、方案设计medium / high需要多步推演medium 是性价比平衡点代码审查、Bug 定位、数据建模high需要深入分析低档位容易漏问题主 Agent 规划、任务分解、结果仲裁high决策密集尽量给足推理预算这只是一个起点别当成圣旨。不同业务场景里同一类任务的复杂程度可能差很多比如“抓取一个静态页面的标题”和“从一个动态渲染的页面里提取结构化字段”对推理的需求完全不同。我建议在刚开始配置时把任务描述里“需要几步才能拿到结果”作为判断依据步骤越少、越确定档位就越低步骤越多、越模糊档位就越高。4. 实测不同组合下的耗时、Token 与质量4.1 测试场景设计配置写好了实际效果如何还是得看数据。我搭了一个比较典型的多 Agent 工作流来测试主 Agent 负责把一份需求描述拆解成子任务并汇总结果子 Agent 有 3 个分别是网站信息采集器doc-search、代码仓库审查器deep-review和结果格式化器format-helper。为了让对比更直观我把任务固定成同一份输入分别跑了三组配置第一组所有 Agent 都设成 high模拟旧版全局 high 的行为第二组所有 Agent 都设成 low模拟旧版全局 low第三组按需配置主 Agent 和 deep-review 用 highdoc-search 和 format-helper 用 low。整个流程跑 3 次取平均值记录总耗时、总 token 消耗、以及最后产出的质量评分由我人工判断主要看有没有漏字段、结论是否合理、建议是否具体。我不建议只看单次结果的原因在于模型输出本身有一定随机性单跑的耗时和 token 波动可能达到 10% 以上。取 3 次平均值虽然不能说完全准确但足以看出各配置之间的量级差异。测试时尽量保持输入文本一致不要中途改需求否则对比就没有意义了。4.2 实测数据与观察三组数据如下配置组合总耗时总 token 消耗质量评分5分制全局 high旧行为约 46s约 31k4.7全局 low约 15s约 12k3.4按需配置high low 混合约 21s约 17k4.5从这个结果可以读出三层信息。第一全局 high 和按需配置在质量上非常接近4.7 vs 4.5说明在这个流程里那些低推理强度的子任务对整体质量贡献不大完全可以把它们的档位降下来。第二按需配置比全局 high 节省了约 45% 的耗时、约 45% 的 token 消耗这就很能说明问题了之前大量的推理预算都花在了不该花的地方。第三全局 low 虽然更快更省但质量下降明显3.4 分意味着子任务经常给出“看起来对了但细节经不起推敲”的结果比如代码审查漏掉了边界条件、摘要丢掉了关键数字这在生产环境里是不能接受的。当然这个数据是我的一个具体流程的结果换一个任务结构数据会变但规律是通用的推理强度的边际收益是递减的同一个流程里总有低价值子任务。把低价值子任务的档位降下来把高价值子任务的档位保持住是实现“质量接近、成本锐减”的关键。4.3 从实测数据看配置策略基于这些数据我自己的配置策略可以总结成三步。第一步先用全局 high 把整个流程跑通得到一份“质量上限”基线同时记录耗时和 token。第二步逐个分析子 Agent 的任务性质把明显不需要深度推理的检索、提取、格式化降到 low把决策密集的代码审查、方案设计保持 high。第三步跑一遍同样的任务对比质量评分和成本数据如果质量没有明显下降就说明可以放心保持混合配置如果某个子 Agent 的质量明显掉了就把它往上一档调再测一轮。这种“先降再回退”的策略比一上来就猜档位要稳得多。我见过不少朋友一升级就把全局默认设成 low结果主 Agent 的规划能力跟着下降然后把锅甩给更新其实就是没有理解“全局默认值”只对未显式配置的子 Agent 生效主 Agent 自己的推理强度要单独设。这个坑在第 5 部分还会提到。5. 常见问题与排查技巧5.1 配置了不生效的三种常见原因第一个原因版本不对。我在 3.1 部分已经提过低于 0.9.6 的版本不识别子 Agent 级reasoning_effort字段会静默忽略。如果你发现配置写好了但行为没有任何变化先跑一下harness --version别急着怀疑配置语法。第二个原因字段名写错。YAML 里reasoning_effort用的是下划线如果你从旧文档或者某些第三方模板里复制了reasoning-effort新版本不会报错但也不会生效这种错误最难发现建议用全文搜索检查。第三个原因是配置生效时机。修改配置文件后有些运行中的任务池不会立即重新加载配置你得重启 harness 服务或者重建 Agent 实例。命令行工具一般启动时读取桌面版则记得点“应用”或者重启应用不要只保存就当完事了。排查技巧把推理强度设成一个极端值来验证。比如某个子 Agent 你明明设了 low观察它单次调用的耗时还是特别长那就说明配置没生效而不是你“觉得”它生效了。用极端值做验证比看日志更快定位问题。5.2 推理强度与模型类型的兼容性推理强度并不是所有模型都支持的参数。DeepSeek 的 chat 系列和 reasoner 系列对推理强度的响应方式就不太一样reasoner 系列本身就偏重深度思考high 档位下模型会展开更长的推理链而 chat 系列如果设成 high更多体现在回答的详细程度和步骤完整性上。如果你用的是本地模型比如通过 Ollama 接入情况又不一样本地模型往往没有reasoning_effort这个原生参数Harness 需要做映射到采样参数上比如num_ctx加temperature的组合控制不同模型映射出来的实际效果差别挺大。我建议在接本地模型之前先确认你的模型是否支持类似的参数不要无脑照搬 API 模型的配置。另外有个容易踩的坑reasoning_effort设成 high 之后如果模型的max_tokens太低思考部分会占用大量输出 token最后真正回答用户问题的部分可能被截断。这个问题在子 Agent 上尤其隐蔽因为子 Agent 的输出还要被主 Agent 进一步消化截断后的结果可能带着残缺信息进入下一环。配置时记得给 high 档的子 Agent 留足输出预算一般建议 8192 token 起步具体根据你的任务长度调整。我在测试 deep-review 时就试过max_tokens: 4096加 high 的组合结果模型在输出“问题分析”到一半时被截断后面主 Agent 拿到一份不完整的审查报告差点漏掉一个严重缺陷。5.3 团队协作中的配置同步问题如果你和我一样是在团队项目里用 DeepSeek Harness配置文件一般会提交到 Git 仓库里统一管理。这时候要注意不同成员的本机版本如果不一样配置文件里新增的reasoning_effort字段在旧版本上会被忽略但不会报错这会导致“同一个配置不同人跑出来的效果不一样”。我建议把版本要求写进项目的 README 或者配置模板注释里并且在初始化脚本里加一个版本检查发现问题尽早暴露。还有一个我踩过的坑某些成员会通过桌面版 UI 修改配置改完之后直接提交了整个配置文件结果把 UI 自动补全的一些无关字段也一起提交了合并冲突一堆。团队协作里最好约定好配置文件只通过一种方式维护要么统一用 YAML要么统一用 UI 导出避免两边混用。这个原则看起来很简单但实际执行的时候特别容易被忽略尤其是当组里有人习惯用界面、有人习惯敲命令的时候。6. 最后分享一点我的配置习惯我在跑了一段时间混合推理强度之后最大的体会是不要追求一次配到位。DeepSeek Harness 的更新给了子 Agent 独立配置的能力但用好这个能力需要反复调整和验证。我现在的习惯是在配置文件里给每个子 Agent 加一行注释写明“这个 Agent 为什么用这个档位”这样过几个月回来看还能想起当时的判断依据不至于对着配置发呆。如果你正在搭建多 Agent 流程我建议从自己最痛的那个任务链开始先把数据采集类子 Agent 降下来再用我前面说的“先降再回退”方法逐步调优你会很快看到成本曲线往下走、而整体质量没有明显下滑。配置这东西没有一劳永逸的答案只有持续调整出来的平衡。希望这次的更新记录能给你省点时间。