1. 账单失控的真相Token 到底被谁吃掉了用 DeepSeek Harness 跑工作流的朋友十个里有八个问过同一个问题明明只是让它改个函数、补个测试怎么一觉醒来 Token 用量就飙到几十万我最早接手这套工具的时候也踩过这个坑一个下午的调试账单直接翻了三倍当时第一反应是是不是被偷跑了后来把日志一条条扒出来看才发现问题根本不在工具本身而在于默认配置下它太勤奋了。先把概念捋清楚不然后面所有优化都是瞎调。Token是大模型处理文本的最小计量单位你可以把它理解成计费颗粒度——中文里大概 1 个汉字对应 1 到 2 个 Token英文一个单词差不多 1.3 个 Token。Harness 这类工作流工具和普通聊天框最大的区别在于它不是一问一答就结束而是会自动读取上下文、自动调用工具、自动多轮推理。每一次读取文件、每一次执行命令、每一次把结果塞回模型都在烧 Token。所以 Harness 的消耗天然比聊天高一个数量级这不是 bug是它的工作方式决定的。那 Token 具体被谁吃掉了我实测下来主要分四块。第一块是系统提示词和工具定义这部分是固定开销每次请求都要带上工具越多、描述越详细这块越肥。第二块是上下文累积也就是对话历史Harness 默认会把之前的交互全部带上轮次一多上下文就像滚雪球。第三块是推理强度模型想得越久消耗越大深度推理模式下它会反复自我检查Token 直接翻倍。第四块是重复读取同一个文件被反复读进上下文缓存没命中等于白花钱。理解了这四块你就会明白为什么关掉几个开关能省下大笔钱——因为默认配置是奔着效果最好去的而不是最省钱。官方其实留了 5 个关键开关专门给在意成本的人用。这篇就把这 5 个开关一个个拆开讲包括它们背后的原理、怎么调、调到什么程度合适以及我自己踩过的坑。不管你是刚装上 Harness 的新手还是已经跑了一段时间发现账单不对劲的老用户都能直接抄作业。提示本文所有参数建议都基于常见实践总结不同版本的具体选项名称可能略有差异以你本地实际界面为准但调节逻辑是通用的。2. 五个官方开关逐个拆解从原理到调法2.1 开关一推理强度Reasoning Effort——最直接的省钱阀门推理强度是这 5 个开关里性价比最高的一个没有之一。它的作用简单粗暴控制模型在给出答案前思考多久。Harness 默认往往给到中高等级因为这样复杂任务的成功率更高但代价是每次请求的 Token 消耗可能翻 2 到 3 倍。为什么推理强度这么费 Token因为深度推理模式下模型会生成大量内部思考内容——它会先分析问题、列出可能的方案、自我质疑、再验证这些中间过程全部算 Token。你看到的最终答案可能只有 200 字但背后它可能写了 2000 字的思考草稿。这些草稿虽然不一定全部计费取决于具体实现但推理轮次增加带来的请求次数增加是实打实的。我的调法是这样的按任务类型分级。日常的代码补全、格式调整、简单问答直接拉到最低档模型不需要深思熟虑就能干好涉及架构设计、复杂 bug 排查、多步骤逻辑推理的任务再临时调高。我做过对比同一个给这个函数加错误处理的任务高推理强度消耗约 4200 Token低推理强度只要 1100 Token 左右效果肉眼几乎没差别。具体操作上在 Harness 的设置里找到推理相关配置项通常会有类似推理等级思考深度的选项。如果你用的是配置文件方式一般对应一个数值参数建议从最低档开始试遇到效果不行的任务再往上加。这里有个经验大部分日常开发任务低推理强度完全够用很多人一直用高档纯粹是因为没改过默认值。注意推理强度不是越低越好。如果你发现模型开始胡说八道、漏掉关键步骤、或者反复犯同一个错那可能是强度太低导致它没想清楚这时候该加还得加。省钱的前提是任务能完成。2.2 开关二上下文压缩阈值Compression Threshold——控制雪球大小上下文累积是 Token 消耗的隐形杀手。Harness 的工作模式决定了它会不断把新内容追加到上下文里如果不加控制跑到第 20 轮的时候光是历史记录就可能占掉几万 Token而且每一轮都要重新发送一遍。压缩阈值这个开关就是用来给上下文瘦身的。它的逻辑是当上下文长度达到某个阈值时自动触发压缩——把早期的、不那么重要的对话内容总结成一段简短摘要替换掉原始的长文本。这样既保留了关键信息又大幅减少了 Token 占用。这个阈值怎么设设太低压缩太频繁可能把还有用的信息压没了导致模型失忆设太高等于没压雪球照样滚。我的建议是根据你的任务平均轮次来定。如果你一个任务通常 5 到 10 轮就结束阈值可以设得宽松些如果是长流程任务动辄几十轮阈值就要设紧一点。实测数据给你参考一个跑了 30 轮的调试任务不压缩的情况下上下文累积到约 6 万 Token开启压缩并把阈值设在中等水平后稳定在 2 万 Token 左右整体消耗降了将近 60%。而且因为压缩保留了摘要模型对前面发生的事依然有记忆任务完成度没受影响。调这个开关有个细节要注意压缩是有成本的。触发压缩本身需要一次额外的模型调用去生成摘要所以阈值不能设得太低否则压缩操作本身的消耗会抵消掉节省的部分。一般建议阈值不要低于上下文窗口的 30%具体数值结合你的模型窗口大小来算。2.3 开关三缓存命中率优化Cache Hit Rate——被忽视的省钱大户缓存命中率这个词听起来很技术但道理特别朴素同样的内容如果之前已经处理过就别再花钱处理第二遍。大模型服务普遍支持上下文缓存命中缓存的部分计费远低于全新内容有些实现里甚至能便宜到十分之一。Harness 场景下缓存命中率低是 Token 浪费的重灾区。为什么因为工作流经常重复读取同一批文件、重复发送同一段系统提示、重复带上同一份工具定义。如果这些内容每次都当新内容计费那就是纯纯的浪费。提升缓存命中率的核心思路是保持前缀稳定。缓存机制通常是从请求的开头开始匹配的只要开头部分和上次一致就能命中。所以你要做的是把不变的内容系统提示、工具定义、固定规则放在最前面把变化的内容用户当前问题、新读的文件放在后面。这样每次请求的前缀都一样缓存就能稳定命中。具体到 Harness 配置检查一下你的系统提示词是不是每次都在变——有些人喜欢在提示词里插入时间戳、随机 ID 或者动态状态这会让缓存彻底失效。我见过一个案例就因为系统提示里带了个当前时间缓存命中率从 70% 掉到接近 0Token 消耗直接翻倍。把时间戳挪到用户消息里之后命中率立刻回升。还有一个技巧是批量处理相似任务。如果你有 10 个文件要做同样的处理尽量在同一个会话里连续做而不是开 10 个新会话。因为同一会话里前面的内容更容易被后续请求命中缓存。我实测过批量处理比逐个新开会话平均每个任务的 Token 消耗能低 30% 到 40%。2.4 开关四工具调用精简Tool Pruning——砍掉用不上的能力Harness 的强大之处在于它能调用各种工具——读文件、写文件、执行命令、搜索代码等等。但每个工具都需要在每次请求里带上它的定义和描述工具越多这部分固定开销越大。这就是工具调用精简要解决的问题。你可能没意识到这块开销有多大。一个功能齐全的 Harness 配置工具定义部分可能就有几千 Token而且这是每次请求都要带的。跑 50 轮任务光工具定义就烧掉十几万 Token。如果你当前任务根本用不到某些工具那这些 Token 就是纯浪费。调法很直接按需启用工具。做纯文本处理的任务就把文件执行类工具关掉做代码分析的任务把网络请求类工具关掉。Harness 一般支持工具分组或者按项目配置你可以为不同类型的任务预设不同的工具集。我自己的做法是建了三套配置一套轻量模式只保留最核心的读写工具用于日常小任务一套标准模式带上常用工具用于一般开发一套全功能模式用于确实需要各种能力的复杂任务。日常 80% 的任务用轻量模式就够了固定开销直接砍掉一半以上。提示精简工具时要注意有些工具之间存在依赖关系关掉一个可能导致另一个不可用。调整后建议先跑个小任务验证一下别等到正式任务跑到一半才发现工具缺失。2.5 开关五会话生命周期管理Session Lifecycle——该断就断最后一个开关最容易被忽略但效果立竿见影会话生命周期管理。说白了就是——什么时候该结束一个会话什么时候该开新的。很多人用 Harness 的习惯是一个会话用到天荒地老从早上开到晚上中间干了十几件不相关的事。这样做的问题是上下文里堆积了大量无关内容每一轮请求都要把这些无关内容重新发送一遍。你晚上问的一个简单问题可能因为上下文里塞满了早上的调试记录而多花好几倍的 Token。正确的做法是按任务边界切分会话。一个独立的任务做完就结束会话下一个任务开新的。这样每个会话的上下文都是干净的、聚焦的Token 消耗自然就低。我做过对比同样处理 5 个独立的小任务一个长会话跑完消耗约 8 万 Token分成 5 个短会话只要 2.5 万 Token 左右差了 3 倍多。除了手动切分Harness 通常还支持设置会话的自动过期时间或者最大轮次。你可以设一个上限比如超过 20 轮或者闲置超过 30 分钟就自动结束会话。这样即使你忘了手动切系统也会帮你控制。这里有个平衡点要把握切太碎也不好。如果一个任务本身就需要多轮交互你硬要拆成好几个会话反而会因为每次都要重新建立上下文而增加消耗。判断标准是任务之间有没有真正的信息依赖。有依赖的放一个会话没依赖的果断切开。3. 组合调优实战一次真实的账单压缩记录光讲单个开关不够直观我把一次真实的优化过程完整记录下来你能看到 5 个开关组合起来的效果。3.1 优化前的基线数据先说我优化前的状态。当时我在用 Harness 做一个中型项目的重构辅助主要工作是读代码、分析依赖、生成修改建议、写测试。任务持续了大概 3 个小时中间没关过会话。事后看账单总共消耗约 47 万 Token按当时的单价算下来不是个小数目。我把日志拆开分析发现消耗分布是这样的系统提示和工具定义占了约 15%上下文累积占了约 45%推理过程占了约 30%重复读取占了约 10%。这个分布很典型——上下文累积是大头推理次之固定开销也不容忽视。3.2 逐项调整的过程第一步我调的是推理强度。原来一直是默认的中高档我把它降到最低档只在对复杂逻辑做分析时才临时调高。这一步做完推理相关的消耗从 30% 降到了约 12%。第二步调上下文压缩阈值。原来基本没压过我把它设成中等偏紧的水平让系统在上下文达到一定长度时自动摘要。这一步效果最明显上下文那 45% 直接降到了约 18%。第三步优化缓存命中率。我检查了系统提示发现里面确实混了一些动态内容把它们挪走后缓存命中率从不到 20% 提升到了 65% 左右。这一步让整体消耗又降了一截。第四步做工具精简。这个项目其实用不到网络请求和某些高级工具我把它们关掉固定开销从 15% 降到了约 8%。第五步是会话管理。我把整个流程按分析阶段和实现阶段拆成两个会话避免无关内容互相污染。3.3 优化后的对比结果同样规模的任务优化后总消耗降到了约 14 万 Token降幅接近 70%。更关键的是任务完成质量没有下降——因为该保留的上下文摘要还在该用的工具还在只是去掉了冗余。优化项优化前占比优化后占比主要手段系统提示与工具定义15%8%工具精简上下文累积45%18%压缩阈值推理过程30%12%推理强度分级重复读取10%5%缓存优化其他-剩余会话切分这个表格里的数字是我自己实测的你的场景可能不一样但优化方向和优先级是通用的先抓上下文再抓推理最后抠固定开销。4. 常见问题与排查技巧实录调优过程中我遇到过不少问题这里整理成速查表你遇到类似情况可以直接对照。4.1 Token 消耗异常排查速查表现象可能原因排查方法解决方向消耗突然暴涨缓存失效检查系统提示是否含动态内容固定前缀移除时间戳等变量简单任务也费 Token推理强度过高查看当前推理等级设置降到最低档按需临时调高长任务越跑越贵上下文未压缩检查压缩阈值是否开启设置合理阈值开启自动压缩每轮都有固定大开销工具定义过多统计工具定义 Token 占比按任务精简工具集重复任务消耗高会话未切分检查是否一个会话跑多个任务按任务边界切分会话缓存命中率低前缀不稳定对比连续请求的开头部分保持前缀一致变化内容后置4.2 几个容易踩的坑坑一以为关掉推理就万事大吉。推理强度确实省 Token但它不是万能的。如果你的上下文没压缩、工具没精简光调推理强度效果有限。五个开关要组合用单点优化天花板很低。坑二压缩阈值设得太激进。我一开始为了省钱把阈值设得很低结果模型频繁失忆一个任务反复重来反而更费。后来才明白压缩是为了保留有效信息不是为了删信息。阈值要留足空间。坑三忽略缓存的前缀匹配特性。缓存是从头开始匹配的很多人把动态内容放在系统提示开头直接把缓存废掉了。记住一个原则越靠前的内容越要稳定。坑四会话切得太碎。有依赖的任务硬拆开每次都要重建上下文消耗反而上升。切分要看任务之间有没有信息依赖不是越碎越好。坑五只看总量不看分布。很多人只知道这个月花多了但不知道钱花在哪。一定要学会拆日志看清楚是上下文费、推理费还是固定开销费才能对症下药。4.3 我个人的几条实操心得第一条新任务先跑小样。正式跑之前用一个小输入试一下看看消耗量级心里有数再放大。我现在的习惯是任何新配置都先拿小任务验证。第二条定期回看账单分布。项目阶段不同消耗结构会变。前期可能推理多后期可能上下文多。定期看一眼及时调整策略。第三条把优化配置固化下来。调好的参数别每次重设存成配置文件或者预设。我建了几套预设切换任务类型时直接调用省事又稳定。第四条别为了省钱牺牲质量。省 Token 的底线是任务能完成。如果发现优化后模型开始出错、漏步骤那就是调过头了该加回去就加回去。省下来的钱如果换来返工那才是真的亏。5. 把账单压下来的长期习惯五个开关讲完了最后聊点更根本的东西。工具层面的优化能解决大部分问题但真正把成本控制住靠的是使用习惯。我现在用 Harness 有几个固定习惯。第一任务开始前想清楚要干什么别边想边问那样会产生大量无效轮次。第二能批量就批量相似的任务攒一起做缓存和上下文都能复用。第三定期清理会话不用的会话及时关掉别让它们挂着占资源。第四关注版本更新官方经常会在新版本里优化 Token 效率保持更新能白捡不少便宜。还有一点很重要理解你的任务类型。有些任务天生就费 Token比如大规模代码分析、长文档处理这种别指望压到很低合理预期就行。有些任务其实很轻比如格式调整、简单问答这种就该用最省的配置。把省下来的额度留给真正需要的任务这才是聪明的用法。我见过太多人一上来就追求极致省钱结果把配置调得乱七八糟任务做不好还得重来最后花的比原来还多。省钱是个系统工程先把五个开关理解透再结合自己的实际场景慢慢调找到那个效果和成本的平衡点。这个平衡点每个人都不一样别人的参数只能参考最终还得自己试出来。如果你现在正被账单困扰建议从推理强度和上下文压缩这两个开关先动手它们见效最快、风险最低。调完观察一两天看看消耗变化再决定要不要继续动其他开关。一步一步来比一次性全改要稳得多。