1. 先搞清楚 Token 到底被谁吃掉了1.1 一个真实账单引发的排查上个月帮朋友看一个 DeepSeek Harness 的 Agent 项目他跟我吐槽说一天烧掉了几百万 Token账单出来的时候手都在抖。我让他把 Harness 的日志导出来按会话维度拆了一遍结果发现真正干活的推理调用只占了不到三成剩下七成全是无效开销——重复的上下文注入、每轮都重新读一遍的文件、被反复塞进 prompt 的历史消息、还有那些明明可以命中缓存却每次都当新请求发出去的调用。这个现象在 Agent 开发里太常见了。Harness 这类框架的设计初衷是让 Agent 能自主规划、调用工具、读写文件、多轮迭代但它的默认配置是能力优先而不是成本优先。也就是说开箱即用的状态下Harness 会尽可能把上下文塞满、把推理强度拉高、把每一步都当成独立请求发出去保证 Agent 聪明代价就是 Token 哗哗地流。所以Token 消耗太快这件事本质上不是 Harness 有 bug而是你没打开那几个控制成本的开关。这篇就把我实测有效的 5 个官方开关拆开讲每个开关解决什么问题、怎么配、配完能省多少我都会给出具体的数字和踩坑记录。1.2 先建立 Token 消耗的账本意识在动手调开关之前你得先知道 Token 花在哪了。我一般会按下面这个维度给一个 Agent 会话做成本画像消耗类型典型占比是否可优化优化手段系统提示词注入15%-25%可优化精简 prompt、按需注入历史消息累积20%-40%高度可优化上下文裁剪、摘要压缩工具调用返回10%-20%可优化结果截断、结构化返回文件/知识读取10%-30%高度可优化缓存、增量读取实际推理输出15%-30%部分可优化降低推理强度这张表是我拆了十几个项目后总结的经验值不同项目差异很大但规律是一致的真正用于思考的 Token 往往不到三分之一大部分都花在喂上下文上。你打开 Harness 的调试日志按会话统计一下 input_tokens 和 output_tokens 的比例如果 input 是 output 的 5 倍以上那基本可以确定是上下文管理出了问题。提示Harness 的日志里通常会区分 prompt_tokens 和 completion_tokens前者是输入后者是输出。输入远大于输出是 Agent 类应用的常态但比例超过 8:1 就说明上下文冗余严重了。2. 开关一推理强度分级别让简单任务跑满血2.1 推理强度到底影响什么DeepSeek 系列模型支持推理强度reasoning effort的调节这个参数直接决定了模型在给出答案前想多久。强度越高模型内部的思维链越长消耗的 Token 越多。很多人图省事全局设成最高强度结果一个帮我列个目录的任务也跑出了几千 Token 的思考过程。Harness 里这个开关通常叫reasoning_effort或者thinking_budget取值一般是 low / medium / high 三档部分版本支持自定义 token 预算。我的经验是low适合格式化输出、简单分类、字段提取、模板填充这类任务不需要深度推理medium适合常规问答、代码补全、单步工具调用high只留给多步规划、复杂调试、需要权衡取舍的决策类任务2.2 按任务类型动态切换的实操全局设一个值是最偷懒也最浪费的做法。我一般会在 Harness 的 Agent 配置里做任务路由根据任务类型动态指定推理强度。下面是一个配置示例YAML 风格具体字段名以你用的 Harness 版本为准agent: default_reasoning_effort: medium task_routing: - match: extract|parse|format|list reasoning_effort: low - match: debug|plan|analyze|refactor reasoning_effort: high - match: .* reasoning_effort: medium这个路由规则的意思是命中提取、解析、格式化、列举类关键词的任务走 low命中调试、规划、分析、重构类关键词的走 high其余走 medium。实测下来光这一项就能把整体 Token 消耗压掉 25%-35%因为大部分日常任务其实都是 low 档就能搞定的。2.3 一个反直觉的发现我一开始担心降强度会让 Agent 变笨实测下来发现对于工具调用类任务low 和 high 的成功率差异不到 5%但 Token 消耗差了 3 倍。原因是工具调用本身是确定性的模型只需要判断调哪个工具、传什么参数不需要长篇大论地推理。真正需要 high 的是那种信息不全、需要自己权衡的开放式任务。所以我的建议是先把默认强度降到 medium观察一周如果 Agent 表现没有明显退化再针对具体任务类型往下调。不要一上来就全局 high那是纯烧钱。3. 开关二缓存命中率拉满别让重复内容反复计费3.1 缓存命中率为什么是省钱核心DeepSeek 的 API 对缓存命中的输入 Token 有大幅折扣这个折扣力度相当可观。所谓缓存命中就是你的请求前缀和之前某个请求的前缀完全一致服务端可以直接复用之前的计算结果只对新增部分计费。Agent 场景下系统提示词、工具定义、固定的知识库片段这些内容每一轮都会重复发送。如果缓存命中率高这部分几乎不花钱如果命中率低每一轮都按全价计费差距能到 5-10 倍。Harness 里控制缓存的关键是保持请求前缀的稳定性。我见过太多项目每次请求都把时间戳、随机 ID、动态排序的工具列表塞在 prompt 最前面导致前缀每次都变缓存永远命中不了。3.2 让前缀稳定的三个硬规则规则一固定内容放前面动态内容放后面。系统提示词、工具 schema、静态知识库这些不变的内容必须放在 prompt 最前面且顺序固定。用户输入、当前时间、会话状态这些动态内容放最后。规则二工具列表顺序要稳定。很多 Harness 版本会按字典序或注册顺序输出工具定义如果你在运行时动态增删工具前缀就变了。我的做法是把工具集固定下来需要禁用某个工具时用参数控制而不是从列表里删掉。规则三避免在系统提示里塞时间戳。这个坑我踩过系统提示里写了当前时间{now}结果每次请求前缀都不一样缓存命中率直接归零。正确做法是把时间信息放到用户消息里或者干脆不注入。3.3 缓存命中率的监控方法Harness 的响应里一般会返回prompt_cache_hit_tokens和prompt_cache_miss_tokens两个字段。我习惯在日志里把这两个值记下来算一个命中率命中率 cache_hit_tokens / (cache_hit_tokens cache_miss_tokens)健康的值应该在 60% 以上优化得好的项目能到 85%。如果低于 40%基本可以确定是前缀不稳定导致的。我帮朋友排查的那个项目命中率只有 12%调整前缀顺序后一周内涨到了 78%账单直接砍掉一半多。注意缓存有有效期通常是几十分钟到几小时不等。如果你的 Agent 调用间隔很长缓存会失效这时候命中率低是正常的不用过度优化。4. 开关三上下文裁剪与摘要压缩砍掉历史包袱4.1 历史消息是最大的隐形开销Agent 多轮对话时每一轮都会把之前所有消息重新发一遍。第 10 轮的时候你发的是前 9 轮的全部内容加上第 10 轮的新内容。这是 O(n²) 的增长轮次一多Token 消耗是指数级往上窜的。Harness 默认通常会保留完整历史因为这样 Agent记性最好。但实际项目里很多历史消息对当前任务毫无价值——三轮前的一次失败尝试、已经完成的子任务、被否决的方案这些留着纯属浪费。4.2 滑动窗口 摘要的两级裁剪我的做法是两级裁剪第一级滑动窗口。只保留最近 N 轮完整消息N 一般设 5-8。更早的消息要么丢弃要么压缩。第二级摘要压缩。对窗口外的历史用一个低强度的模型调用生成摘要把摘要作为一条系统消息注入。摘要的 Token 消耗远小于原始历史。配置大概长这样context_management: window_size: 6 summarization: enabled: true trigger_threshold: 10 summary_model: deepseek-chat summary_reasoning_effort: low max_summary_tokens: 500意思是保留最近 6 轮完整消息当总轮次超过 10 时触发摘要用低强度模型生成不超过 500 Token 的摘要。实测下来一个 30 轮的会话Token 消耗能从 40 万降到 12 万左右。4.3 工具返回结果的截断策略工具调用返回的内容经常是 Token 大户。比如读一个文件返回几千行、查数据库返回一大坨 JSON这些全塞进上下文下一轮又要重新发一遍。我的策略是工具返回只保留关键字段长内容截断并标注。比如文件读取只返回前 200 行加一句文件共 X 行已截断数据库查询只返回命中的记录数和前几条样例。Agent 如果需要更多可以再发起一次精确读取。这个策略有个前提你的工具实现要支持分页读取或按范围读取否则截断了 Agent 也拿不到完整内容。我在工具定义里一般会加offset和limit参数让 Agent 自己控制读取范围。5. 开关四工具调用去重与批量化减少往返次数5.1 每一次工具调用都是一次完整请求Agent 调用工具的模式是模型输出工具调用请求 → 框架执行工具 → 把结果塞回上下文 → 模型继续。每一次往返都是一次完整的 API 请求都要重新发送全部上下文。所以减少往返次数 直接减少 Token 消耗。我见过一个项目Agent 要读 10 个文件它一个一个读每次读一个就发一次请求10 次往返下来上下文被重复发送了 10 遍。如果改成一次性批量读取往返次数降到 1-2 次Token 消耗能省 70%。5.2 批量化与并行化的实现Harness 一般支持并行工具调用parallel tool calls也就是模型一次输出多个工具调用请求框架并行执行后一起返回。开启这个功能的关键是在工具定义里明确标注哪些工具可以并行在系统提示里引导模型能批量就批量框架层面支持并行执行和结果合并配置示例tool_execution: parallel_enabled: true max_parallel_calls: 5 batch_similar_calls: true dedup_window: 3dedup_window是我自己加的一个去重窗口意思是最近 3 轮内如果调用了相同的工具和参数直接返回缓存结果不再实际执行也不再发请求。这个对那种Agent 反复读同一个文件的场景特别有效。5.3 工具粒度的设计经验工具设计得太细会导致调用次数暴增设计得太粗又会让单次返回内容过大。我的经验是按业务动作而不是技术操作来设计工具。比如不要设计read_line、read_range、read_file三个工具而是设计一个read_file带 offset/limit 参数。这样 Agent 一次调用就能拿到需要的内容不用来回试探。6. 开关五输出长度限制与提前终止管住话痨模型6.1 输出 Token 比输入贵很多人只盯着输入 Token忽略了输出 Token。实际上输出 Token 的单价通常比输入高好几倍而且输出是模型一个字一个字生成的没法缓存。一个话痨的 Agent输出 Token 能占到总消耗的 40%。Harness 里控制输出的开关主要是max_tokens和停止条件。默认的 max_tokens 往往设得很大比如 4096 或 8192模型会倾向于把话说满。实际很多任务只需要几百 Token 的输出。6.2 按任务类型设置输出上限我的做法是按任务类型设不同的 max_tokens任务类型建议 max_tokens理由分类/判断50-100只需要输出标签或布尔值字段提取200-500结构化输出长度可控代码生成1000-2000复杂代码需要空间长文写作2000-4000内容本身就需要长度工具调用200-500只需要输出调用参数这个表是我根据实际项目调的你可以根据自己的任务特点微调。关键是不要全局用一个值那必然要么浪费要么不够。6.3 提前终止的触发条件除了 max_tokens还可以设置停止序列stop sequences。比如工具调用场景模型输出完 JSON 参数后就应该停止不需要再输出解释性文字。设置合适的 stop sequence 能让模型在完成任务后立即停止避免多余的总结陈词。我常用的 stop sequences 包括\n\nObservation:、/tool_call、\n\nHuman:这类标记。具体用什么取决于你的 prompt 格式。提示stop sequence 设置不当会导致模型输出被意外截断。建议先在测试环境验证确认不会误伤正常输出再上生产。7. 五个开关的组合效果与调优顺序7.1 组合效果实测数据我把这五个开关在一个中等规模的 Agent 项目上逐个打开记录每步的 Token 消耗变化。项目背景是代码助手类 Agent日均 2000 次会话平均每会话 8 轮。优化阶段日均 Token 消耗相对基线缓存命中率基线默认配置100%-12% 推理强度分级72%-28%12% 缓存前缀优化45%-55%78% 上下文裁剪32%-68%80% 工具批量化24%-76%82% 输出限制18%-82%82%最终 Token 消耗降到基线的 18%也就是省了 82%。这个数字看起来夸张但拆开看每一步都是合理的推理强度省的是想太多的钱缓存省的是重复发送的钱上下文裁剪省的是历史包袱的钱工具批量化省的是往返次数的钱输出限制省的是话痨的钱。五笔钱加起来就是这个效果。7.2 推荐的调优顺序这五个开关不要一起上否则出了问题你都不知道是哪个导致的。我的推荐顺序是先开缓存前缀优化改动最小收益最大风险最低。只要把 prompt 结构调一下不用改业务逻辑。再开推理强度分级需要梳理任务类型但逻辑清晰容易验证。然后开上下文裁剪这个改动会影响 Agent 的记忆需要仔细测试确认不会丢失关键信息。接着开工具批量化需要改工具实现和框架配置工作量稍大。最后开输出限制最简单但收益也相对小放最后。每开一个开关观察至少 3-5 天的数据确认 Agent 表现没有退化再开下一个。我见过有人一次性全开结果 Agent 变傻了回头排查花了两天。7.3 什么情况下不要过度优化省钱是好事但别省过头。有几种情况我建议保守一点任务本身就需要深度推理比如复杂的代码重构、多步规划这时候降强度会显著影响质量省下的钱不够弥补返工成本。缓存命中率已经很高如果已经在 85% 以上再优化空间有限不如把精力放在别的地方。会话轮次很少如果平均只有 2-3 轮上下文裁剪的收益很小反而增加了复杂度。输出质量是核心竞争力面向用户的直接输出别为了省钱把 max_tokens 卡得太死用户体验下降得不偿失。8. 常见问题与排查技巧实录8.1 缓存命中率上不去的排查清单缓存命中率低是最常见也最影响成本的问题。我整理了一个排查清单按顺序检查排查项检查方法常见问题系统提示是否含动态内容对比两次请求的 prompt 前缀时间戳、随机 ID、会话 ID工具列表顺序是否稳定打印工具 schema 的哈希动态增删工具、字典序不稳定知识库片段是否固定检查 RAG 注入的内容每次检索结果不同、排序不稳定消息格式是否一致对比 JSON 序列化结果字段顺序、空格、换行差异请求间隔是否过长看两次请求的时间差超过缓存有效期我遇到过一个特别隐蔽的坑Harness 在序列化工具定义时JSON 字段顺序不固定导致每次请求的前缀字节级不一致缓存永远命中不了。后来在序列化时强制排序字段才解决。这种问题不看字节级对比根本发现不了。8.2 Agent 变笨了怎么办开了优化开关后如果 Agent 表现退化按这个顺序回滚先回滚输出限制max_tokens 太小会导致输出被截断这个最容易发现也最容易恢复。再回滚上下文裁剪如果 Agent 开始忘记之前的信息多半是裁剪太激进把 window_size 调大。然后回滚推理强度如果 Agent 的判断开始出错把关键任务的强度调回 high。最后回滚工具批量化如果工具调用开始出错检查并行执行是否有竞态问题。我的经验是上下文裁剪是最容易导致 Agent 变笨的开关因为它直接改变了 Agent 能看到的信息。调这个开关时一定要做 A/B 测试对比优化前后的任务成功率。8.3 几个容易被忽略的细节细节一摘要本身也消耗 Token。摘要压缩不是免费的生成摘要要调用模型摘要本身也要占上下文。如果历史消息本来就不长摘要反而可能增加消耗。我的经验是只有当被压缩的历史超过 2000 Token 时摘要才划算。细节二并行工具调用有并发上限。不是并行数越高越好服务端和框架都有并发限制超过限制会排队甚至报错。max_parallel_calls 一般设 3-5 比较稳妥。细节三缓存是按前缀匹配的不是按内容匹配的。同样的内容如果出现在不同位置缓存不会命中。所以保持结构稳定比保持内容稳定更重要。细节四不同模型的缓存策略不一样。有些模型缓存粒度细有些粗。切换模型时缓存命中率会重置这是正常的过一段时间会恢复。8.4 监控与告警的搭建优化不是一次性的需要持续监控。我一般会搭三个告警单会话 Token 超阈值告警某个会话消耗超过历史 P95 的 2 倍时触发排查是否有异常循环。缓存命中率跌破阈值告警命中率低于 50% 持续 1 小时触发排查前缀是否被破坏。日均消耗环比告警日消耗环比增长超过 30% 触发排查是否有新功能引入了额外开销。这三个告警搭起来后基本能在成本失控前发现问题。我朋友那个项目就是因为没监控等发现的时候已经烧了一周了。9. 一些关于 Harness 与 Agent 配合的个人体会9.1 Harness 和 Agent 的分工要清晰很多人把 Harness 和 Agent 混为一谈其实两者职责不同。Agent 是决策者负责想清楚要做什么Harness 是执行者负责把决策落地成实际的模型调用和工具执行。成本优化的开关大部分在 Harness 层但优化的策略要结合 Agent 的任务特点来定。比如推理强度这个开关Harness 提供的是能调的能力但什么时候调低这个决策要基于你对 Agent 任务的理解。所以做成本优化的人不能只懂 Harness 配置还要懂 Agent 在干什么。9.2 离线与内网环境的注意事项有些项目跑在内网或离线环境这时候缓存策略要重新考虑。内网环境如果用的是自部署模型缓存机制可能和公有云不一样需要看具体部署方案的文档。另外内网环境的模型版本可能较旧某些优化参数不一定支持配置前先确认版本兼容性。9.3 关于 Token 失效与登录问题的提醒Agent 项目里经常遇到 Token 失效、登录态过期这类问题这类问题本身不直接消耗推理 Token但会导致重试间接增加消耗。我的做法是在 Harness 层做统一的凭证管理凭证快过期时提前刷新避免请求发出去才失败重试。重试逻辑也要设上限别让失败请求无限重试把账单刷爆。9.4 最后分享一个压箱底的技巧如果你的 Agent 有大量读文件类的操作可以在 Harness 层做一个文件内容指纹缓存对文件内容算哈希哈希没变就直接返回缓存的内容不重新读取也不重新注入上下文。这个技巧对那种Agent 反复读同一批文件的场景特别有效我有个项目靠这一招把文件读取相关的 Token 消耗砍掉了 90%。具体实现是在工具层加一层缓存key 是文件路径加内容哈希value 是读取结果。Agent 请求读文件时先查缓存命中就直接返回。注意缓存要有失效机制文件修改后哈希变了自然就失效了。这个技巧的关键在于Agent 不知道缓存的存在它以为自己每次都在读文件实际上大部分请求都被缓存拦截了。对 Agent 的行为没有任何影响但成本降得实实在在。