OpenCode上下文爆炸?DCP插件自动裁剪,Token节省40%的秘密

你有没有遇到过这种鬼情况？

好端端写着代码，OpenCode突然跟你玩起了「失忆」。它忘了你半小时前交代的需求，开始问你一样的问题。你耐着性子又解释了一遍，它居然问你第三遍。

这时你大概率会忍不住：这AI 怎么回事？

别急着骂街。这不是AI变蠢了，是它的「脑子」——也就是所谓的上下文窗口——被塞爆了。

说出来你可能不信，一个30分钟的开发会话，工具调用记录能占掉70%的上下文空间。那些鬼东西包括但不仅限于：同一个文件被反复读取十几次、上一轮已经过期的搜索结果还在那儿、调试输出堆了满满一屏幕。

这就是今天要聊的问题——上下文爆炸。而DCP这个插件，就是来解决问题的。

上下文爆炸是什么鬼？

说人话就是：OpenCode在干活的过程中，会把所有操作都记录下来。文件读取、执行命令、搜索结果、错误输出——事无巨细，全存。

每次你让AI读一个文件，它不但要把文件内容存下来，还要把读了这个动作本身、读了多少行、用了什么编码……全都记在账上。随着你开发时间变长，这些记录越来越多，多到AI开始「记不住」最初的需求。

一个典型的30分钟会话，上下文分布是这样的：

• System指令：约25K tokens（15%）
• 你说的话：约8K tokens（5%）
• AI的回复：约16K tokens（10%）
• 工具调用记录：约116K tokens（70%）

70%啊，兄弟。这意味着你开发越久，AI越健忘。

雪上加霜的是，这70%里至少有一半是垃圾——重复读取同一文件N次、早就过时的写入操作、好几个月前的报错信息还占着坑。

举个例子

你可能不信邪，让我们具体盘一盘。

一个稍微复杂的项目，少说也有几十个文件。你在调Bug的过程中，AI可能需要：

• 读取 src/user/service.ts看用户服务实现
• 读取 src/user/model.ts看数据模型
• 读取 src/auth/middleware.ts看权限中间件
• 读取 src/db/connection.ts看数据库连接
• 读取 config/app.config.ts看应用配置
• 读取 package.json看依赖版本
• ……

每个文件少说几KB，多的几十KB。读个10次，100K tokens就没了。

这还是理想情况。真实场景往往是：

• 同一个文件，因为不同的问题，被读取了3-5次
• 搜索关键词，每次搜法略有不同，结果大同小异
• 早期调试用的临时输出，现在已经完全没用了
• 那些失败的命令，它们的报错信息还占着地方

当你开发了1-2个小时，积累个16-20万tokens是常有的事。这时候AI就开始犯迷糊了——它不是不理解你的需求，是实在装不下更多了。

有什么后果？

最常见的有三种：

第一种：重复问你

AI忘了你之前说过什么，开始问同样的问题。你跟它说「把用户服务改成异步」，过了半小时它问你「用户服务在哪？」

第二种：理解力下降

AI能理解单次输入的意思，但忘了之前所有输入之间的关系。它能看懂每一处修改，但串不起来你想做的事情。

第三种：反应变慢

每次请求的token数量太大，API响应时间明显变长。你等一个回复可能要几十秒甚至更久。

不管哪种，都够你受的。

DCP是何方神圣？

DCP，全称Dynamic Context Pruning，翻译过来就是「动态上下文裁剪」。这名字听起来高大上，其实干的事情很简单：帮OpenCode打扫房间，把没用的垃圾扔掉。

目前在GitHub上有1964颗星，100个fork，20位贡献者，每周下载量23.5K，最新版本v3.1.9。算是OpenCode生态里最受欢迎的上下文管理插件了。

这插件有多火？这么说吧，凡是聊OpenCode上下文管理的帖子，下面必有人提DCP。不信的可以去Reddit上搜搜。

它是怎么干活的？

DCP有三把斧，配合使用效果更佳：

第一把：去重（Deduplication）

这是最常用的功能，也是大多数场景下节省token的主力。

系统会自动检测具有相同签名的工具调用——所谓相同签名，就是同一个工具+同样的参数。比如你连续读了一个文件3次：

读 src/utils/helper.ts读 src/utils/helper.ts  读 src/utils/helper.ts

DCP检测到这仨是同一个东西，只保留最后一次，前两次直接替换成占位符：

[src/utils/helper.ts - 2次重复读取已折叠]

省了多少？假设每次读这个文件产生3K tokens，两次就是6K。干净。

这种情况在实际开发中极其常见——同一个文件被读N次，简直是日常。去重策略就能帮你省下30-50%的token。

第二把：覆盖写清理（Supersede Writes）

这个功能很聪明。当你读取一个文件后，意味着你已经有了这个文件的最新状态。之前对这个文件的写入操作——那些edit、write——就可以滚蛋了。

比如你之前让AI修改了某个文件，然后为了确认修改效果又读了一次。读过之后，之前的写入输入就没价值了，因为读取结果已经包含文件的最新状态。

DCP会自动清理这些过时的写入操作输入，省下空间给真正有用的东西。

第三把：错误清理（Purge Errors）

调试过程中，失败的命令会留下错误信息。这个信息对于debug很有价值，但不需要永久保留——4轮之后基本就没用了。

DCP会在4轮（可配置）之后自动清理失败工具的输入参数，但保留错误输出供你参考。这样既不耽误debug，又省空间。

AI也能主动裁剪

除了这三个自动策略，DCP还给了AI三个主动裁剪的工具。AI自己觉得上下文太满了，可以调用这些工具：

discard工具：丢指定的内容，用占位符替换。适合清理那些已经确认没用的长输出。

extract工具：把长篇大论提炼成摘要。比如一个30K的搜索结果，extract后可能就1-2K，但保留了关键信息。

compress工具（v3新增）：这是v3版本的大招。选择一段对话范围，生成技术摘要。可以理解为OpenCode内置compaction的智能升级版。

效果怎么样？

官方说能省40%，实际用下来大概在**20-40%**之间浮动。看怎么用：

• 重度使用：20-30%节省（大量工具调用，AI频繁主动裁剪）
• 中度使用：10-20%节省（频繁去重，被动裁剪）
• 轻度使用：5-10%节省（偶尔重复读取）

有个副作用得说一下：裁剪内容会导致提示词缓存命中率轻微下降。

什么叫提示词缓存？就是你每次发请求，前面相同的内容会被缓存起来，不用重新计费。缓存命中率从90%降到85%左右，影响不大。但对于按请求计费的场景（比如某些API），这个影响可以忽略。

对于长时间会话，这个交换是划算的——舍掉5%的缓存，换20-40%的token，血赚。

技术实现：裁剪是怎么发生的？

DCP的裁剪发生在每次请求发出去之前。整个过程在后台静默进行，你感知不到。

具体的流程是这样的：

1. 你发送消息2. DCP开始搞卫生：执行去重、清理过期内容3. 如果AI开启了主动裁剪模式，它可以自己决定调用裁剪工具4. 清理后的上下文被打包发送给AI5. AI正常干活，生成响应

这个过程非常快，通常在几毫秒内完成。你发完消息，稍微等一下，AI就回复了。整个过程对你完全透明。

它会乱删东西吗？

放心，DCP有点自制力。不是见什么删什么，它有保护机制。

轮次保护（Turn Protection）

工具调用后的几轮内，这个工具的输出不会被裁剪。默认值是4-6轮（复杂任务）或2-3轮（简单任务）。

为什么要有这个保护？你刚让AI读了一个文件，转身就被删了，那还玩什么。这个保护确保刚用完的东西还在。

保护名单（Protected Tools）

某些关键工具的输出，永远不会被自动策略裁剪：

• task：任务创建，删了会出大事
• write/edit：写入操作，是核心输出
• batch：批量操作，结果很重要

即使DCP饿疯了，也不会动这些东西。

自定义保护（Protected Patterns）

你可以配置正则表达式，让某些路径下的文件永远不被裁剪。比如：

protectedPatterns: ["^src critical/.*","\\.config\\.ts$"]

这样关键配置文件永远安全。

v3版本的新东西

2026年3月发布的v3版本，带来了几个新功能：

统一的compress工具

之前有三个工具（prune/distill/compress），v3把它们整合成了一个compress。这样AI调用裁剪工具的次数更少，缓存失效的问题也有所改善。

nudging机制

之前AI可能过度热衷于裁剪，v3优化了提示词，让AI只在真正需要的时候才动手。

子代理支持（实验性）

这是很多人在等的功能。用task工具创建的子代理，DCP之前是完全禁用的。v3提供了experimental.allowSubAgents配置项来尝试解决，但目前还在beta。

怎么安装？

一行代码的事。

在你的OpenCode配置文件里（一般在~/.config/opencode/opencode.json），在plugins数组加上：

{    "plugin": ["opencode-dcp"]}

或者用完整包名：

{    "plugin": ["@tarquinen/opencode-dcp"]}

完事。DCP会自动启动，默认参数足够用，你不需要任何配置。

想折腾一下？

可以在~/.config/opencode/目录下创建dcp.jsonc，配置更多参数：

{    "$schema": "https://raw.githubusercontent.com/Opencode-DCP/opencode-dynamic-context-pruning/master/dcp.schema.json",    "enabled": true,    "debug": false,    "pruneNotification": "detailed",    "compress": {        "mode": "range",        "maxContextLimit": 100000,        "minContextLimit": 30000,        "nudgeFrequency": 10    },    "strategies": {        "deduplication": { "enabled": true },        "supersedeWrites": { "enabled": false },        "purgeErrors": { "enabled": true, "turns": 4 }    },    "turnProtection": 4,    "protectedTools": ["task", "write", "edit"]}

参数说明：

• nudgeFrequency：AI主动裁剪的频率。默认5，意思是每5次交互AI会考虑裁剪一次。设置太高AI会过度裁剪，设置太低AI太懒。
• turnProtection：几轮内不删输出。默认4。
• deduplication：去重策略开关，默认开。
• supersedeWrites：覆盖写清理，默认关（因为可能导致某些边界情况）。
• purgeErrors：错误清理，默认开。

常用命令

DCP提供了一些命令行工具：

• /dcp stats– 查看当前会话token统计，了解消耗分布
• /dcp context– 查看上下文分布详情
• /dcp sweep 20– 手动清理最早20轮的上下文
• /dcp enable/ /dcp disable– 启用或禁用DCP

哪场景能用上？

场景一：大型重构

把30+个Vue组件从Options API改成Composition API。

如果没有DCP，这种重构是灾难级的：

• 每个组件文件要读3-5次确认
• 每个文件的相关依赖也要读
• 中间还夹杂着调试输出

30个组件文件读3次，就是90条记录压在上面，还没算依赖。

有了DCP之后：

• 重复读取自动去重，只保留最后一次
• 覆盖写清理删掉过时的写入操作
• AI每次都能专注于当前任务，不会被历史记录干扰

实测能省**39%**的token。对于大型重构，这是救命的。

场景二：调Bug

跨10个文件的状态管理Bug，调试过程会产生大量垃圾：

• 各种搜索命令，grep user, grep auth, grep permission……
• 测试输出，日志文件，错误信息
• 临时加的console.log
• 失败的curl命令

没有DCP，这些垃圾全堆着，越堆越多。

DCP会自动：

• 清理重复搜索（同一个关键词搜3次，只保留一次）
• 4轮之后清理错误输入（但保留错误输出供debug）
• 自动清理过期的临时输出

实测能省33%。而且上下文清爽了，AI更容易看清问题本质。

场景三：长会话开发

那种持续几个小时的大项目。

没有DCP，开发到后面AI已经开始说胡话了——因为实在装不下了，你说的越多，它忘得越多。

DCP可以帮你把上下文控制在合理范围内。只要不是特别极端的情况，AI能一直保持清醒。

场景四：需要注意点

子代理场景

用task工具创建的子代理里，DCP暂时用不了。子代理的上下文是独立的，DCP进不去。

如果你是那种离了子代理会死的人（说的就是某些喜欢用task拆任务的开发者），目前阶段DCP帮不了你。v3版本在尝试解决（experimental.allowSubAgents），但还在beta，别指望太多。

推理模型

如果你用的是带深度思考的模型（比如Claude Opus 4.5 Extended Thinking），这货的思考过程会占用大量tokens。

深度思考这玩意儿吧，用完了就没价值了，但DCP目前还不会自动清理。开发者表态说在做（strip_reasoning配置项），但还没正式发布。

跟其他插件怎么选？

OpenCode生态里做上下文管理的还有几个，不只有DCP：

简单说：

• 想省当前会话的token → DCP
• 想让AI记住跨会话的事情 → opencode-mem
• 想追求最大token节省 → ACP
• 两个一起用也不冲突

各有各的用法，看你需求。

为什么这么火？

分析一下原因：

解决真问题

上下文爆炸是每个OpenCode用户都会遇到的问题。不管你用谁的模型、用什么配置，只要开发时间足够长，一定会碰到。不是痒痒，是真的会疼。

开箱即用

不需要调参数，不需要学配置。装上就能用，默认参数足够好。这点很重要——技术文章看再多，不如装上就能跑。

效果明显

20-40%的token节省，看得见摸得着。不是那种「可能」「也许」的收益，是实打实的省钱。

社区活跃

维护者Tarquinen在GitHub上很活跃，issue基本都回，bug修得快。有什么问题直接提，不用怕变孤儿。

总结

DCP这插件，强烈推荐。

1964颗星不是白给的。每周23.5K下载说明广大人民群众的智慧。在OpenCode上搞中大型项目开发，这东西基本是必备的。

一行配置，完事。不需要调参数，不需要学原理。装上，然后用就完了。

一句话：它让AI记住真正重要的东西。

散会。有问题评论区见。