上下文太大，token消耗增多

[a-bird-without-PC]

我一个小项目用deepseek v4 flash token消耗 从0 - 70M 昨天做了好几个小任务， 今天在对应对话， 从70M - 100M 就一个小任务。全程用的是PTC模式，这合理吗。弄得我要开新会话。（也可能是我操作有问题，在过程中我多次调用了MCP playwright,仅作分享，如果能发现问题更好）

[SPYQWER1]

新开会话吧，会话约长消耗越多。或者尽量压缩

[a-bird-without-PC]

新开会话吧，会话约长消耗越多。或者尽量压缩

但感觉这是不是所有模型的通病啊，但是这个harness这方面确实需要改进，至少不要把上下文都记住啊，两个没关系的内容还要关联，就会消耗没必要的token

[coclip]

兄弟，这个哪个agent不是这样，如果你要判断会话内容是否跟本次任务相关，这件事本身就不是代码能做到的，需要接入agent来进行语义分析，这在现阶段是得不偿失的

[a-bird-without-PC]

兄弟，这个哪个agent不是这样，如果你要判断会话内容是否跟本次任务相关，这件事本身就不是代码能做到的，需要接入agent来进行语义分析，这在现阶段是得不偿失的

我也不怎么懂，就是感觉上下文的影响太大了。但做思维链的时候，AI就应该明白这两个对话没什么关系。

[SPYQWER1]

可以看看有没有插件什么的，现在内置应该是没有自动压缩。

[fnsii]

去看一下KVCache的规则吧，如果不记住所有的上下文，就完全无法命中缓存，按照的就是新输入计算了，消耗的钱更多。
还不如快封顶之后做summary压缩
尽量还是给你的ai做个约定，有一个公共的文件夹存项目计划和文档，多对话处理

[freehul]

同样遇到过长会话 token 爆炸，分享下我的排查思路，希望对你有帮助：

为什么会涨这么快

1. 会话越长，每轮都要带全量历史，token 随轮数线性涨；
2. PTC 模式下多轮 tool 调用会把中间产物也留在上下文里；
3. playwright 这类 MCP 工具的 DOM/快照结果很大，一轮就能吃掉不少。

三个方向（按成本从低到高）

1. 换新会话（你现在做的）：最省事，但要手动搬运上下文，丢了延续性；
2. 压缩历史：DSH 自带 summarize，但压缩有损，细节会丢；
3. 记忆分层（治本）：把「对话历史」和「长期记忆」分开——历史该滚就滚，但提炼过的记忆按需注入，而不是每次全量带。

我后来是用第三个方向解决的，实现上给 DSH 接了一个记忆引擎（dsh-sgme）：每轮对话零成本落盘（L0，不走 LLM）→ 会话结束时自动提炼去重合并（L1/L1.5/L2）→ 新会话按场景只注入相关的记忆块（纯结构化查询，不烧 token）→ 需要细节时再 memory_search 按需检索。这样长会话可以随时开新档，延续性不丢，token 只花在真正需要的记忆上。

如果你的痛点是「小任务也吃掉 30M」，建议先看一下是不是每次都在带大历史——开新会话 + 按需检索通常能解决大半。

[a-bird-without-PC]

谢谢，我试试

[freehul]

如果你有迁移记忆的需求，看看freehul/sgme，多agent通用，在这边批量从会话导入记忆，在另一个agent中完美无缝调用，最重要的是，他会自动进行“剪枝”操作，把无用的工具调用内容去掉，可以减少80%以上的会话内容。

[freehul]

顺着这个话题再补充一个我实际在用的思路：把「对话历史」和「长期记忆」分开——历史该滚就滚，记忆按需注入。我最后给 DSH 接了一个独立的记忆引擎（dsh-sgme），两个机制在起作用：

按场景注入：新会话只带当前任务相关的记忆块，纯结构化查询、不烧 token，长会话随时开新档，延续性不丢；
提炼时自动剪枝：先把无用的工具调用/中间产物剔除，再交给模型提炼。我这边实测能省 65%～96% 的会话内容（视会话里工具噪音占比而定），顺带也把提炼成本压下来了。
如果你的痛点主要是 Playwright 这类大结果，楼上 pi-quiet-tools 那种「进上下文前压缩工具输出」的方向也值得试；想根治「长会话越用越贵」，可以看看这个路线。仓库：github.com/freehul/sgme（npm 包 dsh-sgme）。

[2catycm]

请教一下 PTC 是什么的缩写，我看到这个模式，没搞懂他是干啥的

[a-bird-without-PC]

PTC 模式的扩写
PTC = Programmatic Tool Calling（程序化工具调用）。

需要说明的一点：DeepSeek 官方中文站只用了「PTC 模式」这个营销名（deepseek.com/harness 原文："PTC 模式通过模型生成的一段代码组合多轮工具调用"），官方英文页面对应名称是 Code mode；「Programmatic Tool Calling」的完整扩写出自社区详解（cnblogs 指南），与代码实现完全吻合。

它是干嘛的
PTC 模式是 DSH 四个内置 Agent 预设（标准 / PTC / 极简 / 创造）中的 code 预设，本质是 Code Mode：让模型写一段 TypeScript 程序来编排多轮工具调用，而不是每步发一次工具调用。

实现要点（源码依据 apps/cli/config/agent-presets/code/agent.cordis.yml 与 agent note .agents/notes/implemented/feature/2026-06-15-code-mode.md）：

呈现层变化：注册表只暴露一个保留通道 run_code({ code, description })，外加把全部工具生成成一份 TypeScript SDK 声明（.d.ts）放进系统提示词。模型在程序里用 await tools.name(args) 调工具，return/console.log 出来的东西才回灌上下文。
执行方式：run_code 把程序交给 @deepseek-ai/dsh-code-runtime-worker-thread——每次运行起一个全新 Node worker 线程，类型剥离后执行（仅限可擦除 TS），空环境 + 堆/耗时/输出预算 + 硬终止；程序内部的每个子工具调用仍走完整的工具流水线（权限、沙箱、审计都照常生效）。
收益：原本要 5 次模型往返的调用序列合并成 1 次；程序里能写循环、分支、Promise.all 并行（按 isConcurrencySafe 分类限并行）；中间结果不再全部塞回上下文，token 开销大幅下降。比如我现在这个回答过程就是用 PTC 模式在工作。
一句话总结：PTC 模式 = 让模型用代码编排工具调用（Code Mode），把"一次工具调用一次往返"变成"一段程序一次往返"，专为复杂的多步骤工具工作流设计。

[weijiafu14]

如果这次 70M→100M 的主要增量来自多次 MCP Playwright 调用，可以先把每次 MCP 工具的大结果在进入模型上下文前压缩掉，而不是等整个会话接近上限才 summarize。

现成方案是用 pi2dsh 直接加载 Pi 社区的 pi-quiet-tools：

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add pi-quiet-tools@0.2.0

重启 DSH 即可，不需要生成 bundle 或改源码。默认超过 12,000 字符或 240 行时，只把确定性的头尾预览交给模型，完整结果保存为本地 artifact，需要细节时模型可再读；阈值可用 QUIET_TOOLS_MAX_CHARS / QUIET_TOOLS_MAX_LINES 调整。

我专门用官方 @deepseek-ai/dsh-mcp-client 启动了真实 stdio MCP server 做闭环：MCP 工具返回 40,799 字符，hook 在 DSH 工具管线里成功压缩，省略的中段从 artifact 完整读回。它覆盖 MCP/Playwright 这类工具结果，不是只对 Pi 自带工具有效。

这解决的是“大工具结果反复进入上下文”这一部分。

[freehul]

这样会不会完美避开了deepseek的超级缓存命中率？

[freehul]

刚才查了一下，pi-quiet-tools 把工具输出换成"头尾预览"后，若输出变化则前缀变、命中率确实掉。
但"完美避开"太绝对：若截断是确定性的（同输入同输出），前缀反而稳定，缓存还能命中开头部分。

[weijiafu14]

@freehul 不会。关键不是“头尾截断是否确定”，而是截断发生在什么时候。

DeepSeek 是严格的前缀缓存。当前规则会在用户输入结束、模型输出结束等位置持久化前缀单元；下一次请求只能命中已经完整匹配的前缀。工具结果是在“上一轮模型输出”之后才追加的，所以它第一次进入下一次请求时，本来就必然是新后缀、miss 一次，不论传 42K 原文还是 8K 预览。

pi-quiet-tools 经 pi2dsh 挂载后，处理顺序是：

DSH 工具执行 → tools/post-execute → Pi tool_result hook 压缩 → DSH 最终 tool/result 持久化

因此 DSH 从一开始写入会话的就是压缩版；后续不会每轮重新压缩，也不会重新生成 artifact 路径。下一轮以后回放的是同一份字节，已有前缀照常 hit。只有首次出现的压缩结果，以及以后主动读取 artifact 新增的内容，各自 miss 一次。

我刚又用当前版本重跑了一遍：原生 DSH 工具输出 42,299 字符 → 最终持久化 7,885 字符；artifact 可逐字恢复原文；连续 derive 和 durable replay 的消息哈希完全一致。

所以准确结论是：不会绕开 DeepSeek 缓存，反而把那段“必然首次 miss”的工具结果缩小，并保留之后的正常缓存命中。 缓存本身仍由 DeepSeek 原生负责，官方也说明它是 best-effort，不承诺 100% 命中。

官方缓存规则：https://api-docs.deepseek.com/guides/kv_cache/

[freehul]

已经很不错啦，加油

[ylwl1997]

上下文太大导致 token 暴涨，几个实际有效的降本手段：

1. PTC 模式：dsh 的 PTC（Prompt Token Cache）模式专门为 DeepSeek 前缀缓存优化，能显著降低长会话的重复前缀成本；
2. 主动 compact：用 /compact 手动压缩上下文，别等自动触发；
3. 精简工具注入：工具描述也会占 token，别一次装太多插件，按需装。

成本这块我实测整理过一篇（含 PTC 命中率、工具数量对成本的影响）：https://dshbase.com/blog/deepseek-harness-cost/

[Electricitysheep]

token 消耗和成本核算我们第 14 章做了完整专题（缓存命中率实测 97%、命中/未命中成本差异、推理档位联动、dsh-usage 工具推荐）：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/14-cost.md

[Electricitysheep]

70M→100M 对一个小任务确实偏大——通常两个原因叠加：1) 会话上下文持续累积（PTC 模式下工具调用会带回完整上下文），2) MCP playwright 等工具的大返回体（截图/页面文本）进上下文。

对策：a) 用第 8 章的 compaction（长会话自动压缩）b) 大任务拆新会话 c) 工具返回体控制。成本核算方法见第 14 章：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/14-cost.md

[Electricitysheep]

已同步：KVCache 严格前缀缓存规则（@weijiafu14 的分析）、封顶 summary 压缩建议（@fnsii）、记忆/压缩生态（dsh-sgme、pi-quiet-tools）已收录进第 14 章缓存机制 + 生态章节：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/14-cost.md