先说个让我肉疼的经历。某个周六我原本只是想在命令行里用 DeepSeek Harness 把小项目里一个模块重构一下顺手把几个 TODO 清掉结果到晚上随手点开 API 账单后台一看当天的 token 消耗比我平时跑一整天的量还高出一大截。一开始我还以为是任务复杂后来把用量明细导出按会话拆开才发现问题根本不在于“聊了多少轮”而在于每一轮请求的输入都比我想象中大得多。DeepSeek Harness 这种终端 Agent 工具跟平时在网页上问两句完全不同它每走一步都会把系统提示词、skill 定义、工具返回内容、历史对话、甚至你贴进上下文的大段文件全部重新发给模型一次。也就是说你每说一句话模型都要把之前所有内容重新“读”一遍。这个设计保证了连续性代价就是 token 像开了闸一样往外流。这篇内容就是把 Harness 里官方提供的 5 个省钱开关逐个拆开讲每个开关控制什么、怎么配、为什么能省钱、省钱的代价是什么。适合正在用 Harness 写代码、写综述、接入了 DeepSeek API 后感觉账单涨得乎的人。看完你至少能把同样任务的 token 消耗压掉一半而且不会明显牺牲生成质量。1. Token 计费的三个“漏斗”先搞清楚钱到底漏在哪不先弄清楚计费口径就去乱调开关很容易调到自认为省了、实际反而更贵。我在 Harness 场景下把 token 消耗拆成了三个漏斗所有开关本质都是在堵这三个口子。1.1 输入 Token 才是大头上下文堆积的放大器很多人有个直觉误区觉得聊天嘛主要花钱在“模型生成的那段回复”上。实际上对于 Agent 类工具输入 token 才是绝对的消耗主力。你每次发给 API 的 payload 大概长这样系统提示词Harness 自带的规则、角色设定、工具使用规范通常就有几千 tokenskill / 插件描述你装了多少个 skill它就会把对应描述和调用方式都塞进去对话历史从第一句到现在所有消息完整重发工具返回结果上一个工具跑出来的输出、代码片段、报错堆栈上下文文件你主动添加或者 agent 读取的源码、文档、日志。一次请求带 2 万到 5 万 token 的输入是家常便饭。而且问题在于这不是一次性花费——会话里每走一步同样的输入基本都要重发一遍。十步下来输入 token 就是 20 万起步。打个比方这就像你让一个助手干活每交代一句新任务都要把之前整本说明书从头朗读一遍。次数多了朗读本身比干活还累。很多 Harness 新手以为“装更多插件、挂更多 skill 能让 agent 更聪明”其实每个额外挂载的说明都是实打实的输入 token。想知道自己当前一个普通请求到底发了多少 token可以在 Harness 的 verbose 日志里看请求体大小或者直接用用量明细按会话维度拆。1.2 输出 Token 的隐藏成本reasoning 与冗长生成第二个漏斗在输出侧。许多模型包括 DeepSeek 系列在 agent 模式下会先产生一段“思考/规划”内容然后再给出最终回复。这段预热的输出一样计费而且在 Harness 里每个子步骤都可能产生一次完整的“计划 行动 观察”输出。我实测过同一个重构任务开启 verbose 推理输出和不开启相比输出 token 能差出 2 到 3 倍。如果你选的模型本身带 reasoning 能力且没有关闭开关那你每次让它改个小 bug它都要先写一大段分析再动手。分析本身不是没用但很多日常任务根本不需要那种强度的“内心戏”。还有就是 agent 生成的回复往往自带 Markdown 表格、步骤罗列、甚至把没改动的代码整段重贴一遍。这些都算钱。后面要讲的输出上限开关就是专门堵这个漏斗的。1.3 缓存命中与未命中的价格差省钱的第一杠杆第三个漏斗比较隐蔽也是省钱空间最大的地方——提示词缓存。DeepSeek API 的计费规则里命中缓存的输入 token 价格远低于未命中的价格具体倍数以官方计价页为准但确实是非常可观的折扣。Harness 这种工具的请求天然有大量重复前缀系统提示词、skill 描述、前几轮对话这些内容每次请求都一样。如果缓存逻辑生效这部分反复计费的输入就能以近乎“骨折价”结算。但如果请求前缀不稳定——比如每轮对话都往中间插了一段新内容或者系统提示词频繁变动缓存就一直打不中。这等于明明买了打折券却因为不按要求排队每次都按原价结账。所以下面五个开关里我会把缓存相关放在中间重点讲因为它不需要你牺牲任何质量纯粹靠请求组织方式的优化就能省钱。2. 第一个开关上下文压缩阈值别让历史对话无限膨胀2.1 压缩阈值设多少合适一个可复用的估算公式Harness 默认会在大模型上下文窗口接近上限时触发自动压缩auto compact把历史对话浓缩成摘要腾出空间。但默认阈值不一定适合你的使用习惯尤其是你同时在跑长对话和高强度代码任务的场景。这个开关的核心参数有两个auto_compact是否启用自动压缩。compact_threshold上下文使用率达到多少时触发压缩通常是一个 0 到 1 的比例。我自己常用的估算思路是这样的假设模型上下文窗口是 64K token那么触发压缩的阈值建议设置在 48K 附近也就是窗口的 75% 左右。之所以不设到 95%是因为压缩动作本身需要模型进行一次生成生成又要占用一部分输出 token。如果窗口已经满到 95% 才动手压缩完剩的空间不够模型继续干活它就会再触发一次压缩白白多花一轮输出。给你一个可以直接抄的配置[context] auto_compact true compact_threshold 0.75 compact_strategy summarizecompact_strategy有两个选项summarize把旧对话总结成摘要和drop直接丢弃最早的对话。前者保留语义但压缩动作本身要消耗一轮输出 token后者更省 token但模型会彻底忘记被丢弃的内容。2.2 压缩的副作用与“压缩-膨胀”循环这里有个我必须提醒你的坑压缩不是免费的而且它有个副作用叫“压缩-膨胀”循环。现象是这样的——你把压缩阈值调得很低比如窗口刚到 50% 就压缩。模型聊不了几句历史攒到阈值触发压缩。压缩完成后历史变成摘要上下文缩了回去模型接着聊。但会话内容本来就没积累多少很快又到 50%又触发压缩。每压缩一次都要花一次完整的输出。结果就是历史没省多少压缩的 output token 倒是一轮接一轮。我一开始就是为了“省输入 token”把阈值压到 0.5结果账单不降反升日志里全是 compact 记录。后来把阈值调回 0.75这个问题就消失了。不同任务建议这样调重代码任务改 bug、重构、实现功能阈值调高到 0.8 左右。因为代码细节丢失一次后面 agent 可能反复读文件找上下文反而更贵重问答任务写综述、文档梳理阈值可以低到 0.6。这类任务对精确细节要求没那么高摘要足够维持连续性长文档喂进来的会话建议干脆开新会话别指望压缩能救你。后面讲会话归档时会展开。3. 第二个开关单轮输出上限锁死增量生成3.1 为什么要锁输出agent 模式下的三步开销很多人第一次看到max_output_tokens这个参数时以为它只是限制“答案长度”没啥好调的。但在 Harness 里输出 token 包含的东西远不止最终回复。一个标准的 agent 执行路径是这样的模型读上下文生成一段内部规划reasoning / thinking模型决定调用哪个工具生成工具调用参数tool call工具返回结果后模型再生成一段面向用户的总结。这三步每一步都算输出 token。你让 agent 执行一个需要 5 次工具调用的任务输出 token 可能积累 4 到 5 次。如果完全不设上限模型可能在某个没必要的环节放飞自我——尤其是那种“为了验证一个想法先把完整方案写出来再动手”的拖延式生成。设置输出上限的好处有两个第一单次生成失控时能被及时截断避免几百 token 就能说清楚的事情变成几千 token 的论文第二强制模型更早进入工具调用环节而不是反复在思考里打转。3.2 按任务类型分配输出预算我目前的配置是这样[generation] max_output_tokens 4096然后根据任务类型手动调整任务类型输出上限原因快速问答、读代码解释1024 - 2048几句话能说清的事不需要长文改 bug、小范围修改4096需要贴改动代码但不用太多发挥从零实现模块、大重构8192 以上输出不够会被截断代码残缺反而引发重试这里最核心的经验是输出上限设得太低不会“省钱”只会“省事不成反花钱”。因为模型输出被截断后下一步大概率会重新生成、重新读上下文甚至因代码不完整而反复修修补补。我踩过的配置是给改 bug 任务设了 1024 上限结果模型一次只能改半个函数逼得它分三轮才把事干完总消耗反而比直接给 4096 还高。如果你不确定某个任务该给多少先用默认值跑一次观察日志里出现truncated或max_tokens reached的次数。如果频繁出现说明上限设太低适当地加。另外如果你的模型和 Harness 版本支持关闭 reasoning 输出我建议在日常任务里关掉或者调低。保留思考过程对复杂调试很有价值但对于“把这段 YAML 转成 JSON”这种纯执行任务那大段“内心戏”纯属浪费。4. 第三个开关提示词缓存把重复发送的文本变成折后价4.1 缓存命中率对账单的影响有多大前面说过Harness 请求的输入大部分是重复的——系统提示词、skill 描述、前几轮对话。如果 API 侧的缓存机制能命中这些重复输入会按更便宜的价格计费。也就是说在请求内容不变的前提下你什么都不用牺牲费用直接打折。对应 Harness 的开关大致是这样的逻辑[api] cache_prompt true打开这个开关后Harness 会尽量把请求组织成“前缀稳定、增量追加”的结构让模型 API 有机会命中缓存。前提是你别在对话中段反复插入大量新内容并且系统提示词和 skill 列表不要频繁改动。怎么判断命中率看 Harness 的日志或者用量面板里有没有 cache hit / cache miss 的统计项。我见过最夸张的情况是一个会话跑了很久缓存命中率长期在 20% 以下大量重复的输入按原价计费。后来只是调整了请求组织方式命中率上到 70% 左右同量级任务的费用肉眼可见地降下来了。4.2 为什么你的请求总是打不中缓存缓存命中有个前提请求前缀要能和之前的请求对齐。最常见的三个打不中原因你可以对照排查。第一会话里频繁插入动态内容。比如每次请求都在历史最前面塞一个当前时间、一个随机字符串、或者一段实时变化的日志。这些内容会破坏前缀连续性导致整条前缀重新计费。解决方法是把易变的、无关的内容尽量放在固定内容之后让它成为“后缀”而不是“前缀”。第二系统提示词经常改动。今天加个规则明天换个格式每次改动都相当于把前缀推倒重来。我现在的做法是系统提示词和 skill 描述一旦确定就尽量在会话中途保持稳定真想调整时开新会话。第三对话历史被压缩后内容变了。压缩把旧对话从原文替换成摘要这个动作本身会改变前缀导致重新缓存。所以前面说的“压缩阈值设太高会增加输入 token”和“设太低会频繁失效缓存输出浪费”之间得找平衡。我的体感是 0.7 到 0.75 这个区间对缓存最友好。顺带提醒一句并不是所有 API 都允许你通过开关显式“强制缓存”DeepSeek 这边更多是自动侧策略。Harness 这个开关的真实作用是帮你组织请求尽量别自己破坏缓存条件。所以别把它理解成“一键打骨折”理解成“别给自己添乱”更准确。5. 第四个开关会话归档与历史裁剪不用开新会话也能止损5.1 长会话的账单陷阱Harness 这类工具最大的体验优势是“一个会话从头跟到尾agent 记得所有事”。但这也是最大的账单陷阱。一个会话聊了 200 轮之后哪怕你当前问题只是“把上面第 15 步的变量名改一下”模型也要先把这 200 轮的完整历史读一遍才能回答。历史里那些早已完成的任务描述、中间过程、甚至打错字的对话全都在按输入 token 计费。我见过一个真实的极端案例有人用 Harness 写综述一个会话用了整整两天期间挂了一堆外部文档片段和中间结果。到第二天晚上他随便问一句“刚才提到的那篇论文作者是谁”单次请求的输入 token 已经到了六位数。花六位数 token 的成本去查一个一句话能回答的问题。5.2 裁剪策略按轮数、按 token 数、按空闲时间Harness 里控制这个问题的开关叫会话归档和历史窗口核心参数大致这样[session] auto_archive true archive_idle_minutes 30 history_window 20含义分别是auto_archive启用自动归档会话空闲超过一定时间后自动保存并关闭当前上下文archive_idle_minutes空闲多久算“该归档了”。开发场景我习惯 30 分钟如果你经常中途去开会查资料可以放宽到 60history_window当前有效历史的最大轮数。超过之后更早的轮次要么被摘要化要么被移出当前上下文。这里有一个实践建议一个任务完成了无论你多舍不得当前上下文都立刻开新会话。新会话只有系统提示词和当前任务描述跟一个 200 轮老会话相比输入 token 能差出一个数量级。很多“越用越贵”的诡异情况其实就是因为你让一个会话活得太久了。我自己的节奏是一次功能开发一个会话一次综述阅读一个会话每次执行完大批量操作后把结果文件保存好然后用一句话向新会话描述“已完成什么、接下来要什么”。这个习惯帮我把每月的总 token 消耗压掉至少三成。如果你确认某个老会话还有用但又不想让它继续拖着巨额历史可以把关键决策内容手动复制到新会话然后主动归档老会话。Harness 的归档能力正常支持这种操作等真需要追溯时再回去翻归档记录而不是让它一直占着上下文。6. 第五个开关请求限流与失败重试抑制最容易被忽视的漏钱口6.1 鉴权失败和重试的隐性消耗这个开关讨论的人最少但它引发的账单异常往往最迷惑人。Harness 这种工具内置了重试机制请求失败自动重试。重试本来是好事但在某些情况下会变成“漏钱口”。比如你长时间没用token 失效了或者登录态过期此时 Harness 反复弹 “token exchange failed”、“sign-in could not be completed”这类错误。有些版本在鉴权失败时会反复走完整流程每次都重新读取上下文、重新构造请求等到终于恢复时之前那些失败重试也不是完全无痕的——尤其是有几步请求已经打到计费侧但业务侧报错的情况那部分 token 照扣不误。更典型的是 429 限流。你短时间发太多请求API 开始限流Harness 默认会自动重试。如果退避策略不好它可能以几乎相同的间隔连续打 5、6 次。每一次重试都是一次完整计费请求而且因为限流大概率又失败失败后再重试形成“请求风暴”。一条经验是错误处理完了之后再让 agent 继续而不是在错误状态下反复触发重试。Harness 这边对应的参数大致是[request] max_retries 2 retry_backoff_factor 2.0 request_limit_per_minute 20含义分别是最多重试 2 次退避系数 2.0第一次等 1 秒第二次等 2 秒呈指数增长本地每分钟最多发起 20 次请求。这样即使 API 端限流本地也不会像无头苍蝇一样猛撞。6.2 遇到登录态失效先重启会话别硬刚这里有个非常实用的经验当你看到token exchange failed、your access token could not be refreshed这类提示时不要反复点重试也不要马上让 agent 继续干活。正确的处理顺序是先停下手里的任务退出当前会话或注销当前登录态重新登录确认状态恢复把当前任务的上下文描述精简后复制到新会话继续执行。为什么不建议原地重试因为登录态失效的恢复通常是一个一次性动作重试机制针对的是“网络抖动”“瞬时超时”这类问题而不是“你的凭据已经彻底失效”。对着一个已经失效的凭据反复重试每次请求都会走一遍完整流程消耗的输入 token 可一分不少。顺便说一下重试参数的调整有代价max_retries设得太低在真正网络抖动时会频繁失败任务中断重跑成本反而高设得太高遇到故障时会重复报错很久。2 次是我觉得比较平衡的数字。重试退避系数一定要大于 1否则失败请求会像机关枪一样连发既触发限流又烧 token。7. 五个开关组合出的省钱配方表以及我实测的账单变化7.1 两组经过验证的推荐配置不同任务类型的省钱侧重点不一样。我自己日常会准备两套配置按任务切换写代码 / 重重构场景[context] auto_compact true compact_threshold 0.8 compact_strategy drop [generation] max_output_tokens 8192 [api] cache_prompt true [session] auto_archive true archive_idle_minutes 30 history_window 15 [request] max_retries 2 retry_backoff_factor 2.0 request_limit_per_minute 20写综述 / 重阅读场景[context] auto_compact true compact_threshold 0.6 compact_strategy summarize [generation] max_output_tokens 2048 [api] cache_prompt true [session] auto_archive true archive_idle_minutes 60 history_window 30 [request] max_retries 2 retry_backoff_factor 2.0 request_limit_per_minute 20注意代码场景我把压缩策略设为drop因为代码任务里旧轮次的细节丢失也没太大关系关键是从文件里获取的当前代码状态还在综述场景反而用summarize因为阅读笔记的上下文连贯性很重要宁多花一点压缩输出钱也要保住语义脉络。7.2 一次真实的优化前后对比某周我用旧配置跑了约 280 万 token 的总消耗大部分集中在一个长期会话和大量未命中缓存的重复请求上。调完上面这套配置后同一类任务总消耗降到约 90 万 token而且因为缓存命中率上来了账单金额降得比 token 量更明显。当然这是个人实测数据跟具体任务复杂度和模型版本有关不能当作普适结论。但有一点我可以确定调配置之前先导出一份用量明细按会话维度看看哪些会话消耗最高然后针对性优化那个会话的行为习惯是否该归档、是否该压缩、输出是否冗长比盲目照搬任何人的配置参数都有效。7.3 开关之外的三个大坑skill 冗余、文件整读、多开并发最后再提三个开关管不住的坑因为它们属于使用习惯层面。第一个是 skill 和插件装了太多。每个 skill 的描述都会进请求前缀装多了就相当于给每次请求都加上一笔固定“过路费”。我见过有人一口气装了十几个 skill实际常用的就两三个。建议定期审视只保留当前任务链路的 skill其余禁用。第二个是一次性把超大文件整段塞进上下文。Harness 支持让 agent 读文件但读之前最好先head或者grep一下只喂需要的那一段。把整个 2 万行日志文件糊进去光那一次请求的输入 token 就够你少说几百句话了。第三个是多开窗口并行跑同一套上下文。Harness 如果你同时开了好几个会话每个会话都是独立的 token 消耗四条并行会话的账单合计往往远超你的心理预期。我做综述那阵子习惯开三个窗口同时查资料后来发现很多轮次是重复劳动不但费钱还容易产生混乱。我自己现在养成了一个固定习惯每周导出一次 token 用量按会话排序看看本周有哪些会话异常膨胀。发现异常后先看这个会话是不是该归档了再看是不是请求缓存命中率下滑最后才怀疑模型本身。这套“体检”流程很朴素但它帮我规避了九成以上的“不明原因账单飙升”。