DeepSeek Harness Compaction 降成本

症状：缓存命中率很高，但 Token 账单和响应时间仍在上升。
最快解法：先拆分 usage 字段定位增量来源，再按状态重要性选择 Compaction、工具结果裁剪或新建会话。

这篇内容适合三类人：发现长会话 Token 持续增长的个人开发者；需要控制持续 Agent 成本与响应时间的工程团队；准备评估模型调用、运行环境和人工恢复成本的技术负责人。

最后更新于 2026 年 8 月 18 日，数据核实自 DeepSeek API 当前模型与定价文档、API usage 字段定义、Context Caching 官方说明以及 DeepSeek Harness 当前仓库说明。Compaction 的具体触发条件、事件字段和默认组合可能随开发者预览版本变化，实际操作前应以你安装版本的命令帮助和 README 为准。

SECTION 01为什么缓存命中高，Token 仍然越跑越多？

长会话的成本问题，通常不是某一轮突然产生了异常数量的 Token，而是每一轮都把新的内容叠加到已有上下文中。一次请求至少可以拆成 4 个观察对象：

新增输入：你本轮发送的任务、补充要求和修正意见。
累计历史：前面轮次的用户消息、模型回复、工具调用和工具结果。
系统上下文：规则、工作区说明、工具定义、技能提示和项目约束。
模型输出：普通回复、推理内容、代码修改说明和下一步动作。

DeepSeek API 的 prompt_tokens 等于 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens 之和，total_tokens 则包含输入和输出。也就是说，缓存命中只能改变部分输入的计费路径，不能让本轮请求不再携带不断变大的历史。你应直接保存每次响应中的完整 usage 字段，而不是只依赖 Harness 界面上的一个“缓存命中率”。(api-docs.deepseek.com)

DeepSeek 的缓存按输入前缀匹配。前缀稳定、重复出现的内容更有机会命中；如果你把时间戳、随机任务编号、实时日志或不断变化的工作区状态插入前缀，缓存和上下文压缩都会更难形成稳定边界。Context Caching 官方说明还明确指出，缓存是尽力而为，不保证每次请求都命中。

因此，排查时不要问“命中率是不是足够高”，而要问：

本轮 prompt_tokens 是否还在增长？
增长主要来自 prompt_cache_hit_tokens，还是 prompt_cache_miss_tokens？
completion_tokens 是否因为反复规划、解释和重试而膨胀？
新增的工具结果是否比用户真正关心的证据多得多？

SECTION 02工具结果膨胀，往往比用户消息更早制造压力

持续 Agent 最容易忽视的输入来源，是工具返回结果。一次构建命令可能返回完整依赖安装日志，一次搜索可能带回几十个低相关结果，一次大文件读取可能把整个文件重新塞回上下文。模型并不一定需要这些原始内容，但 Harness 如果把它们原样保留，后续每轮都可能继续携带。

你可以按下面的方式裁剪：

日志：保留错误类型、失败命令、关键堆栈、前后少量上下文和原始日志路径；成功日志通常只保留摘要。
搜索结果：保留来源、标题、与当前决策直接相关的段落，删除重复摘要和无关页面。
构建输出：保留失败阶段、退出状态、首个根因和关联文件；不要把完整依赖下载过程反复发送。
大文件读取：优先读取函数、类、配置段或指定行号，而不是整文件读取。
测试结果：保留失败测试名称、断言差异和复现命令；通过的测试只记录结果与时间。

这里要区分两个动作。工具结果裁剪解决的是“这一次返回太长”，而上下文压缩解决的是“会话历史已经积累太多”。前者应该在工具返回入口处完成，后者则需要在压缩前把任务状态整理成模型可以继续使用的摘要。仅仅把长日志截断，不能替代完整的状态压缩。

哪些内容可以裁剪，取决于它是否承担证据职责。临时调试输出、重复搜索摘要和已确认的成功日志可以裁剪；失败堆栈、迁移前后的配置、用户明确要求、测试复现命令和安全限制则应保存为外部产物。上下文里只保留文件路径、摘要和校验信息，后续需要审计时再读取原件。

SECTION 03DeepSeek Harness Compaction 降成本，关键不是压得越狠越好

Compaction 的目标不是把历史变成最短文本，而是用更小的上下文恢复同一项任务。对代码任务来说，至少要保留 5 类状态：

当前目标：正在解决什么问题，完成标准是什么。
工作区状态：修改过哪些文件，哪些改动尚未提交。
验证状态：执行过哪些测试，哪些测试失败，失败是否已定位。
待办事项：下一步要做什么，哪些事项不能被跳过。
用户约束：语言、依赖、接口兼容、安全要求和不可修改范围。

压缩完成后，使用压缩前的同一组追问进行验证。例如，让 Agent 重新说出当前目标和未完成事项；要求它指出最近修改的文件；要求它执行失败测试的复现命令；要求它解释某个决定为什么这样做。如果回答只剩下笼统总结，或者把已完成事项重新列为待办，就不能把账单下降视为成功。

DeepSeek Harness 当前版本的仓库资料包含会话、工具调用、缓存相关行为和压缩方向的实现说明，但具体触发条件、事件字段与默认组合可能发生变化。不要把社区截图、第三方解析器字段或某个版本的自动行为当成 DeepSeek API 的永久承诺；涉及计费时，仍应以官方 usage 字段和当前定价页面为准。DeepSeek Harness 当前版本说明可用于核对你部署版本的实现边界。

压缩后的验收清单

[ ] 保存压缩前最后一次完整 usage、工具调用和任务状态。
[ ] 记录当前目标、已修改文件、待办事项与用户约束。
[ ] 将失败测试、关键日志和配置差异保存为外部文件。
[ ] 压缩后复述同一组目标、文件和测试问题。
[ ] 让 Agent 完成一个不改变工作区的恢复性动作。
[ ] 如果关键信息缺失，立即回退到压缩前会话或新建受控会话。
[ ] 对比压缩前后的结果质量、响应时间和恢复人工成本，而不是只看输入 Token。

压缩有几个明显优点：可以保留同一工作流的连续性；减少重复历史进入后续请求；降低上下文接近上限时的失败风险。它也有明确缺点：摘要可能遗漏隐含约束；工具结果被压缩后不一定还能重建原始证据；如果压缩时任务正处于半完成状态，模型可能误判哪些改动已经验证。

SECTION 04什么时候拆会话，比继续压缩更稳？

如果任务目标没有变化，工作区边界稳定，且历史中存在必须连续保留的设计决策，连续会话加适时 Compaction 通常更合理。你应先裁剪工具结果，再压缩状态，避免把无关噪声一并交给摘要器。

如果出现下面任一情况，优先新建会话：

任务目标已经从“修复问题”变成“重新设计方案”。
工作区从一个项目切换到另一个项目。
Agent 已经反复尝试错误路径，旧判断持续影响新决策。
需要把完整审计日志与日常开发上下文隔离。
压缩后无法通过追问恢复目标、文件和测试状态。

可以采用“三路分流”：

继续运行：目标稳定，关键状态完整，工具结果已裁剪。
调整策略：目标稳定，但响应变慢、输入增长过快或摘要质量下降。
拆分环境：目标变化、工作区变化、审计要求提高，或多个任务互相污染。

不要把新建会话理解成浪费。新会话会牺牲一部分前缀复用，但能阻止错误上下文、无关工具输出和旧任务约束继续进入后续请求。对于需要审计的任务，完整日志应独立保存；模型只读取经过筛选的工作摘要和必要证据。

SECTION 05如何估算长会话的真实成本？

DeepSeek 官方价格页面以每 1M tokens 为单位列出缓存命中输入、缓存未命中输入和输出价格，并说明费用由对应 Token 数量乘以单价计算。当前页面还列出不同模型的上下文长度、最大输出和并发限制；这些项目会变化，所以不要把旧文章中的价格复制到预算表里。(api-docs.deepseek.com)

你可以先用变量建立估算框架：

总费用 = 缓存命中输入 Token × 命中单价 + 缓存未命中输入 Token × 未命中单价 + 输出 Token × 输出单价

然后再加入运行环境成本：

总运行成本 = API 费用 + 环境占用成本 + 存储成本 + 人工恢复成本

其中最容易漏掉的是人工恢复成本。一次压缩虽然降低了输入量，但如果 Agent 忘记了失败测试，导致你重新检查、回滚或补写说明，节省的金额可能不值得。相反，一次新建会话虽然让部分前缀重新计费，却可能避免数小时的错误循环。

建议你用同一基准任务做前后对照，至少记录：

每次请求的 prompt_tokens、completion_tokens。
prompt_cache_hit_tokens、prompt_cache_miss_tokens。
首 Token 延迟和完整响应时间。
Agent 进程内存、日志存储增长和会话文件大小。
压缩次数、工具结果裁剪次数和人工介入次数。
最终代码、测试结果和任务完成时间。

官方文档给出的 DeepSeek API 当前响应结构包含 completion_tokens、prompt_tokens、total_tokens 以及缓存命中和未命中字段。不要用第三方包装器重新解释后的“缓存 Token”替代原始响应；如果界面统计与原始 JSON 不一致，应先以 API 返回值为准，再检查解析器映射。(api-docs.deepseek.com)

对照测试时，至少跑 2 组相同任务：一组保持原始长会话，一组启用工具结果裁剪并在状态完整时压缩。只比较一次调用的低费用没有意义；你需要观察整个任务是否减少了重复请求、错误重试和人工恢复。

当前方案如果把 DeepSeek Harness 长期跑在你的本地 Mac 上，常见缺点是开发机被持续占用、多个 Agent 争抢内存和磁盘、长任务中断后恢复依赖本地状态；当日志、缓存和工作区同时增长时，你还要自己维护进程、权限与备份。若你确认问题不仅是 Token 消耗，还伴随本地环境被长期锁定或多任务互相干扰，可以先参考 MACNOX 的 Mac 使用入口，再根据并发量和占用窗口评估远程运行方式。对于需要临时算力、隔离测试环境或短期运行 Agent 的场景，租赁 MACNOX 的 Mac 往往比把主力开发机改造成长期任务节点更容易控制；但如果你需要长期稳定重负载、物理接口或本地硬件调试，自购设备仍然更合适。具体方案可以结合 MACNOX 的配置与下单页面评估，而不是先假设租赁一定更便宜。

SECTION 06常见问题 FAQ

为什么缓存命中率很高，DeepSeek Harness 的 Token 消耗还是不断增加？

缓存命中只影响已经重复出现的输入前缀的计费路径，不会删除新增用户指令、工具返回、系统上下文和模型输出。长会话每轮仍可能携带更大的完整历史，所以你需要同时查看 prompt_tokens、prompt_cache_hit_tokens、prompt_cache_miss_tokens 和 completion_tokens，不能只看命中率。

Compaction 会不会丢失代码任务的重要上下文？

会，尤其是压缩摘要没有明确保存目标、已改文件、失败测试、待办事项和用户限制时。压缩后不要直接相信摘要，应该用压缩前同一组追问或继续动作验证状态是否可恢复。关键证据应保留在提交记录、测试日志或外部产物中。

什么时候应该压缩会话，而不是重新创建会话？

如果目标没有变化、工作区边界稳定、历史中仍有必须保留的决策和任务状态，优先压缩并继续。若目标已经改变、项目目录发生切换，或者错误上下文不断累积，新建会话通常更安全。需要审计时，应把完整日志和供模型读取的精简上下文分开保存。

工具返回结果太长，怎样减少上下文占用？

先按结果类型处理：日志保留错误片段、时间范围和原始文件位置；搜索结果保留来源、结论和少量证据；构建输出保留失败阶段与关键堆栈；大文件读取改为按行号或函数读取。可复现证据不要直接丢掉，而应保存为外部文件并在上下文中留下路径和摘要。

长会话成本应该按哪些数据估算？

至少记录每次请求的 prompt_tokens、completion_tokens、prompt_cache_hit_tokens 和 prompt_cache_miss_tokens，再结合官方模型的缓存命中、缓存未命中和输出单价计算。除此之外，还要记录响应时间、进程内存、存储增长和人工恢复时间，否则一次低账单并不能证明整体方案更便宜。