长对话模型上下文暴增，如何压缩上下文？

[jonsmith]

基于单一长需求持续对话，模型上下文很容易跑到几十万 Token 。

背景：

• 模型：DeepSeek V4 Pro （ 1M 上下文）
• 不限额不考虑费用（公司报销），也不在乎延迟，只追求最高质量的回复与代码准确率。

疑问：

1. 压缩时机： 按比例固定压缩，比如上下文到达 50%主动压缩？
2. 压缩方式： OpenCode 的 /compact 指令是否靠谱？会丢失关键信息吗？
3. 替代方案： 如果不压缩上下文，是自己拆分任务吗？有合适的工具或流程吗？

[ttsh]

我目前的做法是

先判断当前对话和上下文是否有关联，没关联丢弃历史对话，只要最新的 message
有关联保留，然后按照对话和 trace 次数来分割，保留前 200 字符
再长就让模型总结当前对话，然后给一个概览

我这个和写代码没关系，是内部平台，比较简单，压缩我感觉是对话里很难的一步

[canyue7897]

直接拉满。这玩意儿公司都是自部署的，不用管，直接拉满。

[Edisonzzz]

你看看 opencode 咋实现 session 无限续的

[catinsides]

参考 pi 的实现 https://github.com/earendil-works/pi/blob/main/packages/coding-agent/docs/compaction.md#compaction

[jonsmith]

opencode 自动触发了 compact ，上下文从 70%降到 50%左右。我就不主动压缩了，先按目前工具默认的行为试试

[ykone]

推荐你用用这个插件 https://github.com/ranxianglei/billion-context-pii ，之前作者也来介绍过，我也是实际用了发现它确实很能解决单个巨型对话的问题，又避免那种一次性压缩的信息丢失

[ykone]

打错字了......https://github.com/ranxianglei/billion-context-pi ，也有其他插件适配

[micean]

这种上下文管理的插件多如牛毛了，我用的 https://github.com/cortexkit/magic-context ，压缩和记忆都有

[ychost]

目前只有 codex 的服务端 compact 相对好点，其它都是 PE 压缩，损失很大

[mandex]

让它把任务分给子 Agent

[leafiy]

pi 不错,压缩后也有索引,一直在用