- jonsmith2026-08-26
基于单一长需求持续对话，模型上下文很容易跑到几十万 Token 。
背景：
- 模型：DeepSeek V4 Pro （ 1M 上下文）
- 不限额不考虑费用（公司报销），也不在乎延迟，只追求最高质量的回复与代码准确率。
疑问：
- 压缩时机： 按比例固定压缩，比如上下文到达 50%主动压缩？
- 压缩方式： OpenCode 的
/compact指令是否靠谱？会丢失关键信息吗？- 替代方案： 如果不压缩上下文，是自己拆分任务吗？有合适的工具或流程吗？
主楼 - ttsh2026-08-26
我目前的做法是
先判断当前对话和上下文是否有关联，没关联丢弃历史对话，只要最新的 message
有关联保留，然后按照对话和 trace 次数来分割，保留前 200 字符
再长就让模型总结当前对话，然后给一个概览我这个和写代码没关系，是内部平台，比较简单，压缩我感觉是对话里很难的一步
canyue78972026-08-26直接拉满。这玩意儿公司都是自部署的，不用管，直接拉满。
- Edisonzzz2026-08-26
你看看 opencode 咋实现 session 无限续的
- catinsides2026-08-26
- jonsmith2026-08-26
opencode 自动触发了 compact ，上下文从 70%降到 50%左右。我就不主动压缩了，先按目前工具默认的行为试试
- ykone2026-08-26
推荐你用用这个插件 https://github.com/ranxianglei/billion-context-pii ，之前作者也来介绍过，我也是实际用了发现它确实很能解决单个巨型对话的问题，又避免那种一次性压缩的信息丢失
- ykone2026-08-26
打错字了......https://github.com/ranxianglei/billion-context-pi ，也有其他插件适配
micean2026-08-26这种上下文管理的插件多如牛毛了，我用的 https://github.com/cortexkit/magic-context ，压缩和记忆都有
- ychost2026-08-26
目前只有 codex 的服务端 compact 相对好点，其它都是 PE 压缩，损失很大
- mandex2026-08-26
让它把任务分给子 Agent
- leafiy2026-08-26
pi 不错,压缩后也有索引,一直在用