别再为冗余 Token 白白烧钱了。OpenCode 生态系统官方收录的开源插件，让 AI 只看到它真正需要的东西。
用 OpenCode 做 AI 辅助开发一段时间后，你大概率会遇到同一个问题：Token 消耗怎么这么快？
每次让 AI 改个代码，它会反复读取同一个文件、反复执行相同的命令、反复生成相似的输出。这些冗余内容堆在对话上下文中越积越多，不仅推高 API 费用，还会让模型响应变慢、输出质量下降。
好消息是，这个问题已经有了官方认可的优雅解决方案——DCP（Dynamic Context Pruning，动态上下文修剪插件）。它是 OpenCode 官方生态系统页面收录的第三方社区插件（GitHub: Tarquinen/opencode-dynamic-context-pruning，NPM 包名 @tarquinen/opencode-dcp，当前最新版本 3.1.9）。根据官方收录页面的介绍和社区实测数据，DCP 可将 Token 消耗降低 50%，文件密集型场景甚至可达 65%，而且几乎不需要手动干预。
今天这篇文章，就带你彻底搞清楚 DCP 的工作原理、安装配置方法、以及它在不同计费模式下的真实收益。
Token 到底被谁"吃掉"了？
在深入 DCP 之前，先搞清楚一个问题：Token 都花在哪了？
以 AI 编程工具的一次典型交互为例，Token 消耗构成如下：
- Input Tokens
（占总消耗 70%-90%）：系统指令、对话历史、项目文件内容、工具调用输出 - Output Tokens
（占总消耗 10%-30%）：AI 返回的代码、解释、日志
其中最大的黑洞是对话上下文膨胀——每次工具调用的输入和输出都被保留在上下文中，随着对话轮次增加快速膨胀。
举个例子：你让 AI 读取了一个 3000 行的文件，然后改了其中 5 行。下一次对话，这 3000 行仍然躺在上下文里。如果你连续做了 10 次类似操作，上下文里就堆了几万行早已过时的文件内容。
这就是 DCP 要解决的问题。
DCP 是什么？
DCP 的全称是 Dynamic Context Pruning（动态上下文修剪），是一个被 OpenCode 官方生态系统页面收录的开源插件。
核心特点：
- 官方生态认可
：收录在 OpenCode 官方生态系统页面，采用标准的 Hook 机制（message.removed / message.part.removed），与 OpenCode 核心功能不冲突 - 只修剪发送给 LLM 的内容
：不修改原始对话历史，只在发送请求前替换修剪内容为占位符 - 自动运行
：安装后无需手动触发，每次请求前自动清理上下文 - 灵活可配
：支持多级配置文件（全局、自定义目录、项目级），项目级配置优先级最高
DCP 三种清理策略对比：一图看懂谁在帮你省钱
DCP 内置了三种核心优化策略，分别解决不同场景的冗余问题。下面这张表让你一目了然：
|
|
|
|
|
|
|
|---|---|---|---|---|---|
| 自动去重 |
|
|
|
零 |
|
| 覆盖写入检测 |
|
|
|
零 |
|
| 错误清理 |
|
|
|
零 |
|
进阶能力（需 LLM 调用）：
此外，DCP 还提供了一个 Compress 工具，允许 AI 在完成任务后将对话块压缩为高保真技术摘要。你可以把它理解为 OpenCode 内置 compaction 的智能升级版：不是等上下文满了再机械压缩全部内容，而是让 AI 自主判断何时压缩、压缩哪些内容。这个能力需要 LLM 调用，有额外开销，但收益是更精准的上下文管理。
三选一 + 进阶的决策逻辑：
- 你的模型支持 Compress 工具调用，且会话较长 → 启用 Compress 让 AI 自主管理
- 想要零额外开销的自动优化 → 默认的自动去重 + 覆盖写入检测 + 错误清理
- 追求极致简单、装完即忘 → 保持 DCP 默认配置
DCP 对 Prompt 缓存的影响
这是一个容易被忽略的重要细节。
LLM 服务商（如 Anthropic、OpenAI）通过 Prompt Cache 为重复上下文提供折扣——缓存命中的部分按基础输入价格的 10% 计费，相当于 90% 折扣。
DCP 修剪上下文后会改变消息内容，可能导致缓存失效：
-
未启用 DCP 时，缓存命中率约 85% -
启用 DCP 后，缓存命中率约 80%（下降约 5 个百分点）
你需要做的权衡：
- Token 节省收益：50%-65% 的 Token 减少量
- 缓存损失：约 5% 的缓存命中率下降
在实际长会话场景中，Token 节省收益远大于缓存命中率的轻微下降。但你还需要考虑自己的计费模式：
- GitHub Copilot 用户请注意
：Copilot 已于 2026 年 6 月 1 日起从按请求计费全面转向按 Token 计费，用量根据输入、输出及缓存 Token 的实际消耗计算。这意味着 DCP 现在对 Copilot 用户同样有效。个人 Pro 用户每月含 10 美元 AI Credits，Pro+ 含 39 美元，超额可额外购买。如果用 Copilot 做重度长会话开发，DCP 可以帮助控制在月度额度内。 - Cerebras Code 用户
：该服务对输入和输出统一按每百万 Token 2 美元收费，且不提供缓存折扣。使用 DCP 修剪上下文几乎没有缓存损失顾虑，收益更大。 - 按 Token 计费的 API 用户
（Anthropic、OpenAI 等）：Token 节省收益通常远大于缓存命中率的轻微下降，建议启用。
DCP 安装与配置（5 分钟搞定）
第一步：安装
在终端中执行：
opencode plugin @tarquinen/opencode-dcp@latest --global
这是标准的 OpenCode NPM 插件安装命令，会将插件添加到全局 OpenCode 配置中。
第二步：重启 OpenCode
重启后，DCP 会自动开始优化你的会话，无需额外配置。
第三步：验证是否生效
运行一个任务，检查日志中是否出现类似输出：
[DCP] Reduced context: 18,240 → 6,120 tokens
如果看到 Token 削减信息，说明 DCP 正在工作。没有日志 = 没有生效，需要检查安装是否正确。
第四步（可选）：个性化配置
DCP 首次运行后会在 ~/.config/opencode/dcp.jsonc 自动生成配置文件，你可以按需调整：
{
"enabled": true,
"debug": false,
"pruneNotification": "minimal",
"commands": {
"enabled": true
}
}
配置建议：
- 日常开发：保持默认即可，默认自动策略已覆盖最常见的冗余场景
- 使用小上下文窗口的模型（如 GitHub Copilot 模型或本地模型）：建议降低 compress.minContextLimit 和 compress.maxContextLimit 以匹配可用上下文大小
- 长会话重度开发：可启用 Compress 工具，让 AI 在完成任务后自动压缩已关闭的对话块
- 重要提醒：如果同时安装了 DCP 和 ACP（Agentic Context Pruning），两个插件都做上下文修剪，双重处理会进一步破坏缓存命中率，建议只选其一
总结
Token 优化不是"抠门"，而是让你的 AI 工具只关注真正重要的信息。DCP 作为 OpenCode 官方生态系统收录的开源插件，用三种零 LLM 成本的自动策略 + 可选的 AI 驱动压缩，让你在不改变开发习惯的前提下，将 Token 消耗降低 50% 以上。
三步行动指南：
1. 打开终端，执行 opencode plugin @tarquinen/opencode-dcp@latest --global
2. 重启 OpenCode，用 /dcp stats 查看实时 Token 统计
3. 正常开发，DCP 在后台自动优化一切
真实预期管理：
- 日常编程场景预期节省 50%
- 文件密集型场景可达 65%（极限情况）
- 如果你使用的是按请求计费的服务（如已转为按 Token 计费前的旧版 Copilot），DCP 收益为零
省下来的 Token，就是赚回来的开发效率。
写在最后
DCP 本质上是用工程化手段解决上下文膨胀问题，让 AI 只看到真正该看的东西。
你在用 OpenCode 吗？遇到过 Token 消耗的困扰吗？评论区聊聊。
