上个月我把 DeepSeek Harness 正式接进日常开发流程用来改代码、写脚本、跑长任务和补文档。工具本身确实好用但月底一看 API 账单我愣了好几秒——不是模型跑得慢是 token 烧得太快了。我翻了一下使用记录发现大多数消耗根本不是干活干掉的而是被使用习惯和默认配置悄悄吃掉的。DeepSeek Harness 这类 AI 编程助手本质上每次请求都要把整个对话上下文重新发给模型上下文越长每一轮的花费就越高。再加上 reasoner 模型的思考链动辄输出上万 token、MCP 工具返回的大段 JSON 全量塞进窗口一个月下来真金白银就这么没了。好在 Harness 本身提供了好几个官方开关不用改一行代码只要把配置调对就能把消耗明显压下来。这篇文章我就把自己实测有效的 5 个官方开关逐一拆开讲每个都会说明原理、配置方法和适合什么场景。你照着操作大概率能把账单压下一个档次。1. 先搞清楚 Token 都烧在哪里Harness 的隐性消耗点1.1 每一轮请求都在重发完整历史这是最大的隐性消耗很多刚上手 DeepSeek Harness 的人会以为一场对话只有最开始把历史发一次后面的请求只发新增的那句话。实际上完全不是这样。大语言模型是无状态的它不记得之前聊过什么所以 Harness 每发一次请求都必须把当前窗口里的全部内容——包括最初的系统提示、你之前发过的所有指令、模型生成过的所有回复、工具返回的所有结果——重新发给 API 一次。这听起来好像没什么但算一笔账就明白了。假设你跑了一个长任务上下文累积到 50k token你继续让模型改一个小函数这一条请求就消耗 50k token。如果你修改过程中反复让模型调整发了 20 条请求那就是 50k×20 1M token 的消耗。注意这 1M token里绝大多数是重复发送的旧内容模型真正新生成的部分可能只有几千 token。所以长会话是 token 消耗的头号杀手。不是模型在乱花钱是带着全部家当反复出门这个机制本身决定的。1.2 思考链和超长回答reasoner 模型的隐藏账单DeepSeek Harness 默认可以接入 deepseek-reasoner 这类推理模型。reasoner 在给出最终答案之前会先输出一大段内部思考过程用来拆解问题、规划步骤。这个过程对复杂任务很有用但它产生的 token 数量相当可观。我实际观察过一个中等复杂度的代码重构问题思考链可能输出 5000 到 15000 token而最终答案本身往往只有两三千 token。这意味着什么你花的钱里可能有七成是模型在自言自语。如果禁用思考链或者限制思考长度这部分消耗能立刻降下来但代价是复杂问题的处理质量会下降。1.3 工具调用结果MCP 和 skill 的返回内容全量进上下文第三个隐藏消耗点是工具调用。Harness 接了 MCP 服务器之后模型可以调用各种外部工具读文件、搜索代码、查文档、执行命令。每次工具调用后工具返回的原始输出会原封不动地进入上下文成为历史的一部分并且在后续所有请求中反复重发。比如你让它列出某个目录下的所有文件工具返回了一份 2000 token 的目录和元数据列表。这个列表本身不贵问题是它进入上下文后接下来你发的每一条请求都要带着它。如果一场对话里发生了 30 次工具调用每次返回平均 1500 token那就是 45k token 的内容长期挂在上下文里不断被重复计费。总结一下token 烧得快核心就是三件事——上下文无限膨胀、思考链输出过长、工具返回结果全量堆积。下面 5 个开关就是针对这三件事逐个下手的。2. 开关一给上下文装上自动截断阀别让历史对话无限膨胀2.1 先弄明白上下文压缩的原理Harness 的官方命令/compact就是用来做上下文压缩的。执行之后Harness 会把当前对话的核心内容和关键结论总结成一段精炼摘要替换掉原来的完整历史然后继续对话。压缩之后的上下文可能从 60k token 降到 5k token后面每一轮请求的消耗都会成倍下降。但手动压缩需要你自己判断时机而且容易忘。更省心的做法是利用 Harness 的自动压缩能力。在基于 Claude Code 的 Harness 版本中你可以在设置文件里配置自动压缩阈值当上下文达到某个长度时Harness 会在下一轮请求前自动执行压缩不需要你干预。2.2 配置方法与推荐阈值有两种方式开启第一种是直接在对话中输入/compact手动触发。我建议每个长任务里最多每 20 轮交互就主动压缩一次。不要等到上下文已经堆到七八成再动手因为压缩本身也是要消耗 token 的把 80k 压成 8k 的代价比把 40k 压成 5k 高得多。第二种是在 Harness 的配置文件中设置自动压缩。以 settings.json 为例你可以在 env 区域添加类似这样的参数{ env: { COMPACTION_THRESHOLD: 30000 } }不同版本的 Harness 对这个参数的支持程度不太一样如果你的版本没有这个环境变量就退回到手动/compact效果也是一样的。我把阈值设在 30000 token 左右也就是上下文接近 3 万 token 时自动压缩。这样既不会因为过早压缩丢失太多细节也不会让上下文膨胀到失控。2.3 压缩前必须做的一件事关键信息落盘这里有个特别重要的经验压缩会丢掉细节。模型总结摘要时只会保留它认为重要的内容你之前随口提到的一个路径、一个临时决定很可能就被它略过了。压缩后模型突然失忆你再让它改某段代码它可能完全不知道你在说什么返工成本反而更高。我的解决办法是重要信息不要只留在对话里要落到项目文件里。Harness 本身支持引用 CLAUDE.md 这类项目说明文件你可以在任务一开始就把关键约束、文件路径、目标写进去或者用/todo维护一个带检查项的待办文件。这样即便对话被压缩模型也能通过读取文件找回关键信息。这算是我用过压缩功能后总结出的最实用的一条经验。3. 开关二限制思考 Token 和最大输出防止模型想太多、说太多3.1 MAX_THINKING_TOKENS给 reasoner 的思考链上锁DeepSeek Harness 在接入推理模型时支持通过环境变量MAX_THINKING_TOKENS限制思考链的长度。这个变量的作用就是给模型的内心独白设一个字数上限思考到上限就强制收敛直接开始输出答案。配置方法是把环境变量写进 Harness 的 settings.json{ env: { MAX_THINKING_TOKENS: 4096, MAX_OUTPUT_TOKENS: 2048 } }MAX_OUTPUT_TOKENS控制的是模型最终回答的长度上限。像帮我把这个函数改短这类小需求回答根本不需要很长给它 2048 token 完全够用。但如果你不加限制有些模型会滔滔不绝地解释设计思路、贴完整代码、再给你写个测试用例几千 token 就这么花掉了。3.2 不同任务场景的参数推荐我按场景整理了一个参数参考表你直接抄作业就行任务类型MAX_THINKING_TOKENSMAX_OUTPUT_TOKENS说明简单问答、补文档、格式化代码0 或 10241024不需要复杂推理尽量压掉思考链日常代码生成、修 bug20482048平衡质量与消耗代码重构、跨文件改动40964096需要一定推理深度架构设计、疑难问题排查81928192放开限制但要做好上下文压缩配合这里要提醒一下MAX_THINKING_TOKENS 不是越低越好。我试过把它设成 0 去跑一个跨模块的重构结果模型给出的方案明显变浅甚至漏掉了几个重要的边界条件。省下的 token 又因为返工补了回去。建议日常任务开 2048 左右遇到确实复杂的任务再临时调高。3.3 顺带提一句不要用低输出限制反复截断有一种做法是故意把 MAX_OUTPUT_TOKENS 设得很低期望模型说重点。这在某些场景确实有效但有个副作用如果模型答案被截断Harness 有时会继续补完而补完的过程又是一次完整的 API 请求等于花了两份钱才拿到一个完整答案。所以输出限制别低于 1024否则省下来的还不够补完请求花的。4. 开关三模型路由与按需切换简单任务别用大炮打蚊子4.1 deepseek-chat 和 deepseek-reasoner 的消耗差异DeepSeek 的 API 提供多个模型Harness 里最常用的是两种deepseek-chat和deepseek-reasoner。前者是通用对话模型速度快、价格低、没有长思考链后者是推理增强模型擅长复杂逻辑但思考链长、消耗大。我在同一个任务上对比过让两个模型各自写一个带复杂条件判断的数据处理函数。deepseek-chat 用了约 8000 tokendeepseek-reasoner 用了约 18000 token多出来的几乎全是思考链。而最终代码质量差距并不大deepseek-chat 的版本稍微改一下也能用。所以结论很直接简单任务用便宜模型复杂任务才切推理模型。4.2 在 Harness 里配置模型路由Harness 支持通过/model命令在会话中直接切换模型。你也可以在配置里设置环境变量让 Harness 默认使用某个模型{ env: { ANTHROPIC_MODEL: deepseek-chat } }注意ANTHROPIC_MODEL这个名字是 Harness 为了兼容 Claude Code 的工作方式而保留的实际映射到 DeepSeek 的模型名需要看你用的 Harness 版本的配置文件。建议在安装 Harness 后先查看 README 里的模型映射部分确认正确的配置键。我的实操习惯是写脚本、改配置、整理文档这类任务直接锁定 deepseek-chat只有做架构设计、排查复杂 bug、编写核心算法时才切到 deepseek-reasoner。配合/compact压缩历史切换模型后上下文也不会太占开销。4.3 还有一个容易被忽略的小模型出口Claude Code 生态里有个概念叫快速编辑模型专门用来处理简单的文件编辑、标题生成这类琐碎动作不求聪明只求便宜快速。部分 DeepSeek Harness 版本也支持把这种内部动作路由到更小的模型上。你可以看看自己的 Harness 配置文件里有没有类似fast_model或small_model的字段有的话就填上 deepseek-chat。这一项看着不起眼但它在一次会话中会被触发很多次累计节省相当可观。5. 开关四把缓存命中率提上来省掉重复计算的费用5.1 DeepSeek 官方上下文缓存的计费逻辑DeepSeek API 提供了上下文缓存机制。当你的请求前缀和之前请求的前缀一致时API 会直接复用之前计算的缓存结果而这部分 token 的费用远低于重新计算的价格。简单理解就是模型不是每次重新读一遍你的历史而是直接调之前算好的结果。问题在于缓存按前缀精确匹配工作。只要前缀有任何变化后面的缓存就全部失效。这个机制放在 Harness 里就意味着系统提示词、对话开头的内容越稳定缓存命中率越高。5.2 提高缓存命中率的三个实操技巧第一个技巧把动态内容尽量放到对话的后面。比如你项目中有一个很长的规范文档需要模型始终参考那就把它放在 system prompt 或会话的前几轮里并且中途不要改动它。动态的东西比如临时的文件路径、反复变化的需求描述让它出现在对话后段。第二个技巧避免频繁清空和重启会话。有些人喜欢每隔一会儿就新建一个会话觉得这样上下文干净。但新会话意味着前缀完全变了缓存全部失效等于之前反复重发的那几十万 token 全都白烧了。长任务尽量在一个会话里完成配合压缩而不是重开会话。第三个技巧观察 Harness 的请求日志。打开调试日志能直接看到每条请求的缓存命中情况。如果发现命中率长期很低多半是系统提示或首轮消息不稳定检查是不是有哪个插件或 skill 每次启动都往会话开头插入时间戳、随机文本之类的内容。# 以 Harness 的 verbose 模式启动观察缓存相关日志 deepseek-harness --verbose这个方法我在调优缓存时帮了大忙日志里能直接看到某条请求是cache hit还是cache miss省得全靠猜。6. 开关五精简工具生态堵住 MCP 和 skill 的隐形消耗6.1 不用的 MCP 服务器关掉比留着划算MCP 服务器能大幅扩展 Harness 的能力但每个接入的 MCP 服务器都意味着模型在每次决策时要多考虑一些可用工具工具列表的描述也会占据上下文空间。更要命的是一旦模型决定调用某个工具工具的输入输出都会进入上下文并持续计费。我见过不少人的 Harness 配置里挂着五六个 MCP数据库、浏览器、搜索引擎、文件同步一个不缺。可日常开发真正用到的可能就一两个。没在用的 MCP 服务器建议直接整体移除。需要的时候再用命令行临时启动长期关着。Harness 的 MCP 配置一般在.mcp.json或类似文件里把不需要的 server 条目注释掉即可{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem] } } }这里的思路是少一个工具就少一条工具描述占位少一次调用就少一份输出进上下文。6.2 限制工具输出长度别让大海报塞满窗口有些工具输出天然很长比如搜索代码库会返回一堆文件路径和摘要读取日志会返回大段文本。Harness 有环境变量MAX_MCP_OUTPUT_TOKENS专门用来限制工具结果进入上下文的长度。{ env: { MAX_MCP_OUTPUT_TOKENS: 2000 } }设了之后工具返回超长内容会被截断模型看到的信息少了但日常场景够用。我建议从 2000 起调不够再往上加。这个开关对控制上下文增长速度立竿见影尤其是你经常让模型搜索代码、查日志的时候。6.3 skill 文件也要瘦身DeepSeek Harness 支持通过 skill 方式给模型注入特定领域的操作指南。很多人的 skill 文件写得跟百科全书似的洋洋洒洒几千几百行。这些内容在会话中会被加载进上下文成为每次请求都要重发的前缀一部分。如果你确实需要某个 skill把它的说明压缩到最精简保留操作步骤和关键参数删掉背景介绍和重复示例。一个 3000 token 的 skill 文件压缩成 800 token对单次任务来说只是省了一点点但长期跑下来差别非常明显。7. 实测账本配置前后的对比数据与几个易踩的坑7.1 我的一组对比数据我把上面 5 个开关全部配置好之后拿一个真实的周任务做了对比。任务是基于现有代码库新增一个数据导出功能涉及修改 3 个文件、新增 1 个脚本、补充文档。配置前和配置后各跑了完整一遍指标配置前配置后会话平均上下文长度52k token9k token总 API 请求次数126 次118 次总 token 消耗约 4.8M约 1.1M任务完成质量良好良好注意请求次数没有明显下降但总 token 消耗降了接近四分之三。原因就是每一轮请求都变轻了上下文不再背着几十 k 的历史重发。这个数据不一定适用所有任务但趋势是确定的调整配置的收益主要在每轮请求的份量而不是请求次数。7.2 配置过程中容易踩的三个坑第一个坑是压缩太激进导致返工。有个任务我把自动压缩阈值设到了 10k结果模型频繁忘记早期需求我不得不反复解释返工的 token 比省下来的还多。阈值还是建议 30k 左右起步跑一段时间观察一下再调。第二个坑是同时压思考链和接复杂任务。有一次我忘了调高 MAX_THINKING_TOKENS把 4096 的配置拿去跑一个架构设计任务模型给出的方案明显单薄最后只能重开会话再跑一次。限制参数要跟着任务性质走不能一套配置走天下。第三个坑是缓存命中率的假象。有时候日志显示命中率很高但消耗并没有降多少原因是命中的是廉价的前缀部分而中间大量动态内容每次都在重新计算。遇到这种情况最有效的做法是把动态对话和静态参考文档分离让静态部分永远待在前缀里。7.3 顺带说一句Token 失效和登录报错别和用量优化混为一谈最近总看到有人在讨论 token 失效、登录失败这类报错。这类问题本质上是身份认证或网络会话过期和token 用量完全是两码事。用量优化解决的是花得多认证报错解决的是登不上。如果你的 Harness 环境里频繁出现登录失败、token 失效那通常是 API Key 配置或网络环境的问题需要单独排查。不过有一点是相通的失败之后的自动重试也会产生 API 请求报错越多没用的小额消耗就越多。把认证配置一次调对本身也算一种变相的省钱方式。8. 最后分享一点我的实际配置模板如果你不想一个一个抠我把自己当前在用的配置模板贴出来你可以直接套用然后按自己的任务类型微调{ env: { ANTHROPIC_MODEL: deepseek-chat, COMPACTION_THRESHOLD: 30000, MAX_THINKING_TOKENS: 4096, MAX_OUTPUT_TOKENS: 2048, MAX_MCP_OUTPUT_TOKENS: 2000 } }这套配置的核心理念是默认用便宜模型干活上下文到 30k 就压缩思考链和输出长度都上锁工具返回内容不让超长堆积。需要跑复杂任务的时候我临时把模型切到 deepseek-reasoner把 MAX_THINKING_TOKENS 调到 8192任务结束再切回来。个人实测下来这个模板应对常见的代码开发、脚本编写、文档整理都够用而且账单稳定在一个让我不心疼的水平。如果你也是 DeepSeek Harness 的重度用户建议从这个模板起步跑两周之后看数据再根据自己的使用习惯做精细调节。省钱这件事最怕的就是不看数据、不管配置只换着模型硬跑——那才是真的又费钱又费力。