同样的事，上下文压缩 85%：OpenCode 装这两个插件

换了两个让 OpenCode 消耗 token 更少的插件。现在模型自身的 harness 能力越来越强，不再需要一整套厚厚的“规约”也能把活干好——约束这东西，模型弱的时候是拐杖，强的时候是负担。

这期实测两个插件：

oh-my-opencode-slim：算是社区对 omo 理念的轻量化实现版本
opencode-dcp：减上下文中的历史信息——压缩对话里产生的无用信息

其中 opencode-dcp 一个插件，实测就把历史上下文压掉了 85%。

一、oh-my-opencode-slim——轻量版 omo

https://github.com/alvinunreal/oh-my-opencode-slim

omo（oh-my-opencode，已改名 oh-my-openagent）是 OpenCode 最火的插件之一，甚至是必装插件：把工作分解给一队各司其职的 Agent，各干各的工作。个人觉得它有些重了——预设的 Agent 和 Category 都有接近20个，还要去手动配置模型。光是发一个 Hello World，起始会话就要吃掉 30-40k 上下文（omo 的起始会话约束，比 omo-slim 复杂不少）

虽然我挺喜欢使用 Prometheus 来制定计划，再让 Atlas 负责编排，让其他 Agent 去执行。但目前 LLM 的 Harness 能力越来越强了，尤其用了 grill-me（https://github.com/mattpocock/skills）之后，感觉还是让 OpenCode 轻量一些更好。

于是换装了 oh-my-opencode-slim 来试试。它不是 omo 官方出的轻量版，是社区第三方基于 omo 理念重写的插件。

我自己的配置里只挂 6 个 Agent，认知负担低很多，编排都交给 Agent Orchestrator；发一个 Hello World 的起始上下文也比 omo 轻不少，Harness 约束没那么重。

我一直都觉得 omo-slim 这几个 Agent 的形象图，神叨叨的 😂

omo-slim 中，如何给 Agent 设置思考强度

下面以 deepseek-v4-flash 为例子。第一层，在 opencode.jsonc 里给模型声明三档（provider 名 deepseek 按你自己的实际配置填写），下面的配置只展示了部分核心配置（variants）：

{
  "deepseek": {
    "models": {
      "deepseek-v4-flash": {
        "variants": {
          "low":  { "reasoning_effort": "low" },
          "high": { "reasoning_effort": "high" },
          "max":  { "reasoning_effort": "max" }
        },
        "options": {
          "thinking": { "type": "enabled", "budgetTokens": 8192 }
        }
      }
    }
  }
}

第二层，在 slim 的预设文件（~/.config/opencode/oh-my-opencode-slim.json）里，给不同角色分配档位：

{
  "preset": "deepseek",
  "presets": {
    "deepseek": {
      "explorer": {
        "model": [
          { "id": "deepseek/deepseek-v4-flash", "variant": "low" }
        ]
      },
      "orchestrator": {
        "model": [
          { "id": "deepseek/deepseek-v4-flash", "variant": "high" }
        ]
      },
      "oracle": {
        "model": [
          { "id": "deepseek/deepseek-v4-flash", "variant": "max" }
        ]
      }
    }
  }
}

如果只用 deepseek-v4-flash 的话，跑腿的工作用 low 档；复杂工作用 max，编排用 high 比较平衡。这样配置，自我感觉可以比较好的控制成本。

二、opencode-dcp——减上下文中的无用历史信息

https://github.com/Opencode-DCP/opencode-dynamic-context-pruning

dcp（opencode-dynamic-context-pruning，动态上下文修剪）负责把对话历史里没用的部分剪掉。AI 编程对话长什么样：频繁调工具，反复读文件、跑命令、报错再重试——一两个小时后历史里全是重复和过时内容。dcp 干三件事：

1. 重复的调用，只留最后一次。 同一工具、同一参数反复调用，只保留最后一次输出，之前的替换成一行占位符。

2. 报错过的输入，过几轮就剪。 报错过的工具调用，4 轮之后还躺在历史里，就把当时的输入剪掉（错误信息保留）。"报错→改→再报错"的来回最占地方又最没营养。

3. 只改副本，不动原件。 它永不修改真实会话历史，只在把内容发给模型之前，复制一份在副本上剪枝。你随时能回溯完整记录，压缩只影响模型"看到"的东西。

另有软提示系统：上下文逼近上限时让模型主动瘦身；触及硬上限（默认 100k token）变成必须压缩。想手动压，输入 /dcp-compress 就能让模型立刻把已说完的话题压成摘要。

这个插件的开发速度已经放缓，他把新的上下文管理思路都搬去了新项目 Sleev。那为什么还推荐它？机制已经跑熟——官方生态仍在收录、8 月还在合并社区的 PR、版本更新到 3.1.15，对 OpenCode 用户来说，这是现成能用的。

一次压缩结果

让 AI 统计了一个月实测：85.6%

82 个会话里 46 个产生了压缩，被压掉的原始输入合计 357 万 token：

指标	数值
被压缩前的原始输入	357 万 token
压缩后保留的摘要	51.4 万 token
整体压缩率	85.6%

意思是每 100 万 token 的历史垃圾，砍掉 85 万，只留 15 万当背景资料。压缩后的第一次请求会缓存 miss 一次；官方口径是缓存命中率大约从 90% 掉到 85%，我这边用 deepseek-v4-flash，总体也是在 90% 上下。

几个坑，装之前要知道

1. 装了就关掉内置压缩，二选一。 dcp 的定位是替代 opencode 自带的 compaction，不是补充。两个一起开会打架：有用户反馈内置压缩被 dcp 的压缩“顶”出来后，上下文反而飙到 400k 直接爆窗。装 dcp 后，同时在 opencode.jsonc 中把 compaction.auto 关掉。