DSH的上下文工程没做针对工具的渐进式披露，针对工具的输出日志只做了简单的裁剪/外置，大家有无更好的替换方案？

[bjvgukv25842-cmyk]

如题所示，在这几天个人体验下来，DSH目前底层的上下文工程做的非常简单。
实际使用下来个人感觉它的压缩机制只设定了一个合理的阈值，没有做像Claude code那样的分级压缩，它的生命周期还不够完整，特别是针对于压缩后的重新水合、重注入机制，十分不完善，对话几轮之后上下文窗口全被工具的输出日志还有一些垃圾信息冗余。特别是针对于工具的披露方式，几乎都是完整Schema全量加载进上下文窗口，单次对话固定占据10到20k tokens的上下文窗口。针对工具的输出日志，DAH团队做了裁剪和外置，但是目前机制不够完善，基本都是静态触发，且他们似乎针对工具的输出日志的裁剪做了四层机制
Layer 1：采集期裁剪 + 外置（每会话都生效）
Layer 2：通用 spill policy（dsh-spill-policy，maxInlineBytes）存在但默认未启用，任意超预算纯文本工具结果 → 全文存盘 + 头尾预览 + 取回提示
Layer 3：工具结果裁剪器（dsh-compaction-tool-result-pruner） 已装载但被动
Layer 4：压缩（dsh-compaction-basic）已装载但从未触发

结果是我1M 窗口下 Layer 3/4 基本是摆设；真正每轮在控制上下文增长的只有 Layer 1 的各工具采集上限，所以历史里单次不大的工具结果会原样累积——因此我建议目前的解决方式「长会话及时开新篇」

[hardness1020]

你把四层列出来这点挺有用的。不过问题可能不在层数，在触发条件全挂在压力比例上：1M 窗口配 0.8，Layer 3/4 永远等不到那一刻。Claude Code 那套是分级的，budget → snip → micro → auto，前几层每轮都跑，跟窗口剩多少无关，只有最后的语义摘要才看压力。所以可以先在 thresholdRatio 之外加一个绝对回放上限，别让裁剪时机跟窗口大小绑定。工具的渐进式披露是另一件事，全量 Schema 那 10 到 20k 得靠延迟加载解决，跟压缩不是同一层。

另外重注入那块有个坑：替换工具结果的 stub 字符串每次必须一模一样，带时间戳或路径的话前缀一变，后面的 cache 全没了。

这块我用 Python 拆成了教程，GitHub 上 500+ 星：https://github.com/hardness1020/awesome-agent-architecture/tree/main/sections/08-context-management

[bjvgukv25842-cmyk]

「问题不在层数，在触发条件」——这个定位我完全认同，而且我这边有取证数据可以背书：我解压了本机 12 个会话的 append-only 日志逐一核对，真实 spill 事件 0、真实裁剪事件（surfaceOp: replace）0、compaction 事件 0。裁剪器配置齐全（8192/4096/1024）但从没上岗——机制都在编制里，扳机挂错了地方，和你说的「1M 配 0.8 永远等不到」是同一件事，相关讨论可以看看#1090，我也在里面分享了我的看法。

顺带一个取证陷阱分享：日志里 grep 到 tool result middle pruned、stored at 这类字符串不等于触发过——那可能只是模型在对话中引用了 README 文本。必须核对事件是否带 surfaceOp: {op: 'replace'}，我差点被一个会话里 6 处这种假阳性误导。

几个点回应一下：

1. 绝对回放上限：赞同，但杠杆在 preset 默认值

在 thresholdRatio 之外加绝对上限、让裁剪时机与窗口大小解耦，方向完全对。但 DSH 现在就有一个现成的反面教材：spill-policy（maxInlineBytes）能力早已存在，可默认不注册，等于没上线。所以只加库层字段是「给了可能性」，库层保守 + 自带 preset 积极默认启用才这道防线的真正开关——否则绝大多数交互式用户永远享受不到。

2. 「前几层每轮都跑」——分级本质是按成本分层，不是按容量分层

budget → snip → micro 这几级之所以敢每轮跑，是因为它们便宜且确定；只有语义摘要这种昂贵操作才配得上「压力」这种全局判断。如果 DSH 要跟进，我觉得有两个工程细节值得提前想好：

• 增量游标要 crash-safe：作为事件写入 append-only 日志、重启续扫，而不是内存态；
• 同一 pre-step 内多次改写批处理为一次表层提交：每次 surface 改写都让 KV 前缀缓存从第一个变更 token 起失效，分多次提交等于多次重付 prefill。这也是「每轮小裁」相对「达标后一次性大裁」的隐藏收益——越早裁，被击穿的前缀越短。

3. stub 字符串一致性这个坑，DSH 恰好有正反两面教材

正面：pruner 的 omission marker 是固定字符串（无时间戳）；工具定义排序强制确定性（字典序 + toolOrder），保证工具数组逐字节稳定——团队是有 cache 意识的。反面风险恰恰藏在增量重扫里：如果游标失效回退全量重扫、且替换不幂等，同一结果被反复改写就会反复击穿缓存。所以「第二遍扫描必须零输出」的幂等性不是可选项，是缓存经济学的一部分。

4. 渐进式披露确实是另一层，但它有独立的账单

实测：44 个工具全量 Schema 共 39,294 字符 ≈ 11.2k token/请求，且每轮都带（top3：workflow 4,067 / bash 3,290 / describe_image 1,956）。更能说明问题的是延迟左端：纯文本「你好」、零工具调用、prompt 压力才 ~20k token 时，首 token 就要 12s。静态底座是恒定成本每轮重付，和工具输出治理是两条独立的成本曲线，得各治各的——延迟治理不能全指望压缩侧修好。

谢了老兄，教程链接收了，正好去补一下前几级触发成本的设计细节。在机制改好之前，「长会话及时开新篇」恐怕还是唯一有效的手动阀门——但一个需要用户手动续命的系统，恰恰说明了自动分级的缺位。

[lloydzhou]

deepseek官方api只支持前缀缓存

如果做了所谓的什么渐进，工具结果剪裁等，会严重拉低缓存命中率
而在长任务情况下，缓存已经在整体开销占据比较大比重的情况下，这里因为优化context带来的缓存失效反而会增加整体开销。