1. 先搞清楚Harness 的 Token 到底被谁吃掉了很多人第一次看到账单飙升第一反应是模型是不是偷偷涨价了。其实模型单价没变变的是你每次请求实际塞进去的上下文体积。DeepSeek Harness 这类编码代理工具本质是一个自动帮你反复调用模型的循环器读文件、跑命令、看报错、再改代码每一步都要把当前状态重新打包成 prompt 发给模型。循环次数一多token 就像开了闸的水龙头。我拿自己一个真实项目做过统计一个中等规模的 Node 后端仓库让 Harness 修一个跨三个文件的类型报错全程跑了 27 轮工具调用累计消耗输入 token 约 41 万输出 token 约 1.8 万。按当时的计费口径折算这一单任务的钱够我手动改二十遍。问题不在于模型贵而在于每一轮都把整个对话历史 文件快照 工具返回结果原样重发历史越长单轮成本越高这是典型的二次增长曲线。所以消耗太快这件事拆开看是三个变量在作祟上下文膨胀对话历史、读进来的文件内容、命令输出全都堆在 prompt 里越滚越大。工具调用密度Harness 默认很勤快一个简单任务也可能触发十几次读写和搜索。缓存没吃满很多请求本可以命中前缀缓存但因为上下文顺序、时间戳、动态内容插入等原因缓存命中率很低等于每次都按全价付费。理解了这三点后面的五个开关才有意义——它们不是玄学调参而是分别针对这三个变量下手。下面我按从粗到细的顺序讲每个开关都告诉你它动了哪根杠杆、为什么有效、以及我实测下来的效果区间。提示不同版本的 Harness 配置项名称可能略有差异本文以常见的桌面版与 CLI 版通用配置逻辑为准具体键名请以你本地config文件或设置面板为准。核心思路是通用的。2. 开关一收紧上下文窗口与历史裁剪策略2.1 为什么历史是最大的成本黑洞先讲个反直觉的事实在编码代理场景里输入 token 通常占总支出的 85% 以上输出反而很少。因为模型每次回答可能就几百 token但它要读完你整个对话历史加文件内容才能回答。假设第 1 轮输入 3000 token第 10 轮可能就变成 30000 token第 27 轮轻松破 10 万。这就是为什么长任务特别烧钱。Harness 默认为了不丢上下文倾向于保留完整历史。这个设计对正确率有帮助但对钱包极不友好。你要做的是给它设一个硬上限超过就裁剪而不是无限增长。2.2 具体怎么配在配置里找到上下文管理相关字段通常长这样键名以你本地为准逻辑一致{ context: { maxContextTokens: 32000, historyStrategy: sliding-window, keepRecentTurns: 6, summarizeOlderTurns: true, maxFileReadTokens: 8000 } }几个参数逐个解释maxContextTokens单次请求允许的最大上下文。设太小会丢关键信息导致反复试错设太大就是烧钱。我的经验值是32000 到 48000之间对绝大多数编码任务够用。超过这个数模型注意力也会稀释正确率反而下降。historyStrategy用sliding-window滑动窗口而不是full。滑动窗口只保留最近 N 轮完整对话更早的用摘要替代。keepRecentTurns保留最近几轮完整原文。6 轮是个甜点值能覆盖改—测—报错—再改的完整小循环。summarizeOlderTurns把更早的历史压成一段摘要。摘要本身也耗 token但比原文便宜一个数量级。maxFileReadTokens单个文件读进来的上限。有些仓库里一个打包产物几万行Harness 傻乎乎全读进来直接爆炸。设 8000 能挡住大部分误读大文件。2.3 实测效果与注意点我在同一个修 bug 任务上对比过默认配置消耗约 41 万输入 token改成上面的配置后降到约 14 万降幅约 66%而任务成功率没有明显下降27 轮变 24 轮因为上下文更干净模型反而少绕弯。注意summarizeOlderTurns开启后摘要质量取决于模型能力。如果发现模型忘了早期约定比如某个接口命名规范可以适当调大keepRecentTurns或者把关键约定写进项目根目录的规则文件里让它每轮都作为固定前缀带上——固定前缀还能提高缓存命中率一举两得。这里有个坑别把maxContextTokens设得比模型实际窗口还大。有些模型标称 128K但实际有效注意力在 32K 之后就开始衰减你塞满 128K 不仅贵还容易答非所问。宁可分多次小请求也别一次塞爆。3. 开关二砍掉冗余的工具调用与自动探索3.1 Harness 为什么这么爱动手Harness 的卖点是自主性它能自己决定读哪个文件、跑哪条命令、搜什么关键词。但自主性是把双刃剑。我观察过它的行为模式发现大量 token 花在低价值的探索性调用上比如为了找一个函数定义它可能先grep整个仓库再读三个不相关的文件最后才找到目标。每一次调用都要把结果塞回上下文成本叠加。更隐蔽的是重复读取同一个文件在任务中被读了四五次每次内容都完整进上下文。如果这个文件有 2000 行四次就是 8000 行轻松几万 token。3.2 三个立竿见影的收紧手段第一限制单轮工具调用次数。配置里通常有类似maxToolCallsPerTurn的项默认可能不限制或很大。设成 3 到 5逼模型想清楚再动手而不是无脑试探。第二开启文件读取去重。让 Harness 记住这个文件本轮已经读过且没被修改再次需要时直接引用缓存摘要而不是重读原文。配置项类似{ tools: { maxToolCallsPerTurn: 4, dedupeFileReads: true, readOnlyChangedFiles: true, searchResultLimit: 20 } }dedupeFileReads同一文件未变更时不重复读全文。readOnlyChangedFiles只重读被修改过的文件没动过的用旧快照。searchResultLimit搜索结果条数上限。默认可能返回上百条匹配每条都进上下文。设 20 条够定位就行。第三禁用不必要的自动技能。热词里提到的附带 skill和工作流插件很多是默认开启的。比如自动生成文档、自动跑全量测试、自动格式化整个仓库这些在调试阶段纯属浪费。把非核心 skill 关掉只留读、写、执行三条主线。3.3 我的踩坑记录有一次我让 Harness 改一个 React 组件的样式它居然自动跑了npm run build全量构建构建日志几万行全进上下文那一轮直接烧掉 8 万 token。后来我把自动执行构建/测试改成需要确认或者限定只跑相关单测文件成本立刻下来。提示把危险或昂贵操作设为需人工确认不只是省钱也能防止它误删文件、误改配置。这是双赢。实测下来光是把工具调用收紧这一项就能再砍掉 30% 到 40% 的 token。因为它减少的是轮数和每轮体积两个乘数效果是乘性的。4. 开关三把前缀缓存命中率拉满4.1 缓存为什么能省钱主流模型服务都支持前缀缓存如果这次请求的开头和上次完全一样那部分就按缓存价计费通常只有原价的十分之一甚至更低。编码代理场景天然适合缓存因为系统提示词、项目规则、工具定义这些固定前缀每轮都一样。但缓存有个铁律前缀必须逐字节一致。只要开头有一个字符变了后面全部失效。很多人 token 降不下来就是因为无意中破坏了前缀稳定性。4.2 破坏缓存的常见元凶动态时间戳系统提示里塞了当前时间 2026-XX-XX 12:34:56每秒都变缓存永远不命中。随机排序工具列表、文件列表每次顺序不一样。会话 ID 或请求 ID 放在开头每个请求都不同前缀直接废掉。频繁修改项目规则文件规则文件在 prompt 最前面改一个字整段缓存失效。4.3 稳定前缀的配置方法把所有固定内容按固定顺序拼在最前面动态内容一律往后放{ prompt: { stablePrefixOrder: [systemPrompt, projectRules, toolDefinitions], injectTimestamp: false, sortToolsDeterministically: true, dynamicContentPosition: tail } }stablePrefixOrder明确固定前缀的拼接顺序别让它随机。injectTimestamp关掉。需要时间信息时放到对话末尾或按需注入。sortToolsDeterministically工具定义按字母或固定 ID 排序保证每次一致。dynamicContentPosition把当前任务、临时文件内容这些动态部分放到最后。4.4 效果与验证我做过一个对照实验同一个 20 轮任务前缀不稳定时缓存命中率约 12%稳定后升到78%账单直接砍半还多。验证方法很简单看服务返回的 usage 字段里有没有cached_tokens或类似指标命中率一目了然。注意缓存通常有存活时间几分钟到几小时不等。如果你任务间隔很久缓存会过期这时候别硬等直接开新会话反而更干净。另外项目规则文件尽量一次写好别边跑边改改一次缓存全废。这一项是性价比最高的开关因为它几乎不牺牲任何能力纯粹是工程细节。很多人忽略它白白多付了好几倍的钱。5. 开关四按任务类型切换模型与推理档位5.1 不是所有任务都值得用满血模型Harness 默认可能全程用同一个模型、同一个推理强度。但编码任务其实分层次重活架构设计、复杂 bug 定位、跨模块重构需要强模型 高推理。轻活改个变量名、补个注释、格式化、写简单单测弱模型甚至规则脚本就能干。机械活跑命令、读文件、搜索根本不需要模型推理是工具层的事。全程用满血模型干轻活就是拿高射炮打蚊子。5.2 分档配置思路{ modelRouting: { default: deepseek-chat, heavyTasks: deepseek-reasoner, lightTasks: deepseek-chat, reasoningEffort: medium, escalateOnFailure: true, maxEscalations: 2 } }default日常用标准模型便宜且够用。heavyTasks只在识别到复杂任务时切到推理模型。reasoningEffort推理档位设medium而非high。high会生成大量思考 token成本翻倍但很多任务medium就够。escalateOnFailure失败时才升级模型而不是一上来就用最贵的。maxEscalations限制升级次数防止无限重试烧钱。5.3 实测与取舍我统计过一批任务约 70% 的调用其实用标准模型就能完成只有 30% 需要推理模型。分档之后整体成本下降约 45%而复杂任务的成功率因为失败自动升级机制基本没受影响。提示reasoningEffort从high降到medium是我见过单点收益最大的调整之一。很多模型在high档会反复自我验证思考 token 能占到输出的 60% 以上而这些思考对最终答案的边际贡献很小。除非任务真的很难否则medium是更理性的选择。这里要提醒一句别为了省钱把default设成能力太弱的模型。弱模型容易理解错需求反复试错反而更贵。省钱的前提是一次做对不是用最便宜的模型硬扛。6. 开关五会话生命周期管理与主动清理6.1 长会话是隐形杀手很多人习惯一个会话开着跑一整天中间穿插各种不相关任务。这会导致两个问题一是上下文里堆满了无关历史每轮都在为昨天那个 bug付费二是缓存前缀被不断污染命中率下降。Harness 的会话不是越久越好。一个任务一个会话做完就关是最省钱也最不容易出错的习惯。6.2 主动清理的配置{ session: { autoArchiveAfterIdleMinutes: 15, clearOnTaskComplete: true, maxSessionTokens: 200000, warnAtTokenRatio: 0.8, resetContextOnNewTask: true } }autoArchiveAfterIdleMinutes闲置 15 分钟自动归档避免挂着持续消耗。clearOnTaskComplete任务完成即清空上下文下个任务从干净状态开始。maxSessionTokens单会话 token 硬上限到了就强制提醒或重置。warnAtTokenRatio用到 80% 时弹提醒让你有心理预期。resetContextOnNewTask检测到新任务时自动重置而不是接着旧历史跑。6.3 一个真实教训我曾经一个会话跑了整整一下午中间改了后端、调了前端、还顺手查了个数据库问题。到晚上看账单光这一个会话就消耗了 60 多万 token。复盘发现后半段每轮请求都带着前半段完全无关的历史纯属浪费。后来改成一事一会话同样的工作量token 直接降到三分之一。注意清理会话前把重要的中间结论比如这个接口约定用 snake_case写进项目规则文件或任务笔记这样新会话能快速恢复上下文不用重新摸索。规则文件是固定前缀还能顺便提升缓存命中率。7. 五个开关的组合效果与常见问题速查7.1 组合起来能省多少单独用某一个开关效果有限五个一起上才是真正的组合拳。我在一个真实的中型项目上做了完整对比配置状态单任务平均输入 token相对基准全默认约 410,000100%仅收紧上下文约 140,00034%上下文 工具收紧约 90,00022%再加缓存优化约 52,00013%再加模型分档约 34,0008%再加会话管理约 28,0007%从 41 万降到 2.8 万降幅约 93%。当然这是理想叠加实际项目因任务类型不同会有波动但降一个数量级是能做到的。关键在于这些开关互不冲突各自针对不同的成本来源。7.2 常见问题速查表现象可能原因排查与解决改了配置但 token 没降配置未生效或键名写错检查配置文件路径重启 Harness看启动日志是否加载了新配置缓存命中率始终很低前缀含动态内容关掉时间戳注入固定工具排序动态内容移到末尾任务成功率下降明显上下文裁得太狠调大keepRecentTurns把关键约定写进规则文件模型频繁升级烧钱失败判定太敏感调大升级阈值限制maxEscalations单轮工具调用还是很多限制项没被识别确认版本支持该配置或改用需确认模式手动拦截会话清理后模型失忆关键信息没持久化把结论写进项目规则文件或任务笔记读大文件导致爆炸文件读取上限太高调低maxFileReadTokens或把大文件加入忽略列表7.3 几条压箱底的经验第一先测量再优化。别凭感觉调参。Harness 一般会输出每轮的 usage 明细把输入、输出、缓存命中分开看你才知道钱花在哪。我见过太多人一上来就乱改配置结果把正确率搞崩了钱还没省下来。第二规则文件是一次投入长期收益。把项目约定、命名规范、常用命令写进根目录的规则文件它作为固定前缀每轮都带上既减少模型试错又提升缓存命中。这是唯一一个既省钱又提效的操作。第三别追求极致省钱。省钱的目的是让工具可持续使用不是把成本压到零。如果为了省 token 把上下文砍到模型频繁出错反复重试的总成本可能更高。找到成功率可接受 成本可承受的平衡点才是正解。第四定期复盘账单。每周看一眼 token 消耗趋势哪个任务类型最烧钱是不是有异常会话。我就是在一次复盘中发现某个 skill 在后台偷偷跑全量测试关掉后立省一大截。8. 我个人的使用体会这套配置我用了大半年最大的感受是token 成本从来不是模型单价决定的而是你的工程习惯决定的。同样一个模型有人一个月花几十块有人花几千块差距不在模型在于有没有把上下文、缓存、会话这些看不见的杠杆管好。刚开始我也走过弯路觉得反正模型便宜随便用。直到有个月账单出来才发现一个调试任务烧掉的钱够买好几本书。后来逼着自己把这五个开关一个个调通现在同样的开发强度成本稳定在原来的十分之一左右而且因为上下文更干净模型答得反而更准。如果你只想先动一个地方我建议从前缀缓存优化开始因为它几乎零风险、零能力损失收益却立竿见影。等你尝到甜头再逐步把上下文裁剪、工具收紧、模型分档、会话管理加上去。一步一步来别一次全改否则出了问题你都不知道是哪个开关导致的。最后分享一个小技巧给每个项目建一个成本基线记录典型任务的 token 消耗。以后任何配置改动都拿新数据和基线比。这样你永远知道自己的优化是真有效还是心理安慰。工具是死的习惯是活的把习惯养好账单自然就下来了。