OMO vs SLIM：一次省钱切换的实测与反思

TL;DR： 从 OMO 切换到 SLIM 跑了 13 天，每消息平均 Token 数降了 3.7%，几乎持平。按任务类型拆开后发现：coding 持平，写作贵 61%，review 省 53%，debug 贵 121%（样本不足不可靠）。Aristotle 省 68%，但主因是架构重写不是插件差异。「省钱」不是全局事实，是局部现象。真正的差异在体验和架构选择上，不在 Token 数。

oh-my-openagent（GitHub，npm 包名 oh-my-opencode）和 oh-my-opencode-slim（GitHub）是两个 OpenCode 插件。前者是原版，后者是 fork。下文分别简称为 OMO 和 SLIM。

OMO 走「全家桶」路线，11 个 agent，prompt 能到 1100 行，batteries-included。SLIM 走「最小有效复杂度」路线，7 个 agent，prompt 精简。SLIM 独有 Council 多模型投票和 Interview 功能；OMO 则有 LSP 深度集成、hashline edit、ultrawork 模式、model-prompt 硬绑定这些独门武器。

调研一圈下来，我关心的核心问题只剩一个：SLIM 号称 token 消耗更少，那能少多少？

2026 年 4 月 22 日我动手切了，禁用 OMO 再装上 SLIM，前后不到十分钟。切完之后跑了 13 天，回头拉数据一看——情况比「省不省」复杂得多。

评估方法

数据从哪来？OpenCode 的 session 数据库，路径在 ~/.local/share/opencode/opencode.db，一个 SQLite 文件。我用亲自写的 Python 脚本 opencode-daily-stats（当然是亲自指导 AI 写的啦）从里面提取 token 消耗记录。

核心指标是每消息平均 Token 数（∑tokens / messages）。为什么不直接看总量？因为两个时期的使用强度不同，总量会被消息数量带跑。每消息平均 Token 数才能反映插件本身的上下文构建效率。

时间窗口怎么选？

• OMO 期间：2026-04-15 ~ 2026-04-21（7 天）
• SLIM 期间：2026-04-23 ~ 2026-05-05（13 天）

为什么从 4 月 15 日而不是更早？因为 4 月 15 日之后使用强度趋于稳定，两个时期的日均消息量接近——OMO 期间 1108 条/天，SLIM 期间 1339 条/天，后者是前者的 1.21 倍。差距不大，避免使用强度差异得出有偏的结论误导大家。

我对每个 session 按任务类型打了标签，排除了自动化测试 session。打标口径详见附录 B。下面同时呈现总消息数、总 Token 量、每消息平均 Token 数三个维度。

第一层：总平均持平

先看总体数据：

每消息平均 token 降了 3.7%，几乎持平。日均 token 多了 16%，但日均消息也多了 21%，说明 SLIM 期间使用强度略高。

「看起来没差异」——如果到这里就结束，结论是「省钱是假的」。但这个平均数掩盖了很多细节差别。

第二层：分组拆解揭示真相

基础统计：任务构成与日均开销

两段时期我做的事情完全不同。

OMO 期间写博客、做方案设计、跑 Aristotle 反思为主。SLIM 期间重心转向 TDD coding 和 review，debug 量也上来了。两段时期的工作模式根本不是同一件事。

几个交叉事实值得关注。

coding 占 SLIM 期日均 token 的 51.4%，超过一半。日均 token 从 17.8 M 涨到 61.1 M，主因不是插件更费，而是 coding 消息量暴涨了 6.8 倍。

写作消息量增加了 1.6 倍，日均 token 也水涨船高。

review 消息量翻了 7.2 倍，日均 token 还是增加了。

Aristotle 消息量降到了原来的 39%，日均 token 从 21.4 M 缩减到 1.4 M。

每消息开销对比

控制住任务类型后，差异才浮出水面：

三类变省，两类变贵，一类持平。其中 Aristotle 的降幅来自架构重写（LLM 调用迁移到 MCP），不是插件机制差异。排除 Aristotle 后，插件本身带来的变化是三类变省（review、探索/研究、方案设计），两类变贵（写作、debug），一类持平（coding）。「省钱」不是全局事实，是局部现象。

归因

数据摆出来了，逐条掰扯。

coding 持平（-6.6%） 不意外。SLIM 的 coding 子 agent 上下文构建方式和 OMO 差异不大，都是拉代码、跑测试、看输出，token 开销自然在同一量级。coding 占了 SLIM 期日均 token 的 51.4%，这块没涨，说明 SLIM 没有在最大的消耗项上变贵。

但不是所有类别都持平。

写作贵 61% 值得注意。SLIM 期写作 session 中 @zh-writer、@en-writer、@observer 子 agent 的上下文构建可能更重——每次写作任务拉入的背景材料更多，或者多 agent 协作的开销更高。具体原因还需要更多数据才能判断。

review 省 53% 是单轮省。OMO 期 review 由 @oracle/@Momus 做深度审核，每次带大量上下文——完整文件、历史记录、项目规则，一轮 review 下来上下文非常重。SLIM 期的 review 大部分是 ralph loop 中的快速确认，问的是「这轮还有没有问题」，轻量得多。但体感上用 SLIM 之后 review 的轮次变多了——单轮轻量，轮次补上，日均 Token 还是涨了。

debug 贵 121% 不用太当真。OMO 期只有 16 条 debug 消息，样本太小，任何结论都不可靠。SLIM 期 1041 条才是真实数据。调试场景下模型需要反复读取代码、执行命令、分析输出，上下文累积快，token 消耗高是正常的。

最有意思的在最后。

Aristotle 省 68%，但主因不是插件差异。SLIM 不支持子 agent 异步执行，Aristotle 项目因此重写了 bridge 插件，把大量原先依赖 LLM 的工作迁移到 MCP——文件读写、规则查询、状态管理这些，全从 LLM 调用变成了本地工具调用。这个重写意外带来了 token 大幅降耗。「限制催生创新」，这算一个活生生的例子。

使用体验差异

有些差异定量数据捕捉不到。

OMO 下子 agent 并行处理任务，主会话不阻塞。我可以同时跑多个方向——让一个 agent 写代码，另一个查文档，主会话继续聊下一步计划。SLIM 下子 agent 启动时主会话阻塞，我只能等或者切换到别的事情。工作节奏被打断的感觉很明显。

但 SLIM 也带来了意料之外的收获。

Aristotle 的案例已在归因节详述。从体验角度看，这件事给我的冲击不只是 token 数字——限制改变了我对架构选型的思考方式。原来 LLM 调用和本地工具调用之间的边界，值得重新审视。

此外，在 SLIM 的任务提示词环境下，我发现特定时间段模型的思考深度变浅——AI 用 5-Why 时浅尝辄止、单线追踪、确认偏差的问题更加突出。这催生了一套追问协议兜底方案。关于这个问题，我写了三篇系列文章：AI 用不好 5-Why：浅尝辄止、单线追踪与确认偏差、给 AI 套上质量缰绳：追问协议的七个条件、追问的最后一道防线：独立确认与协议的自反性。

反思：评估「轻量」的正确姿势

按任务分组比看总平均更全面、立体和客观，但仍有局限。

最好的做法是同期双环境 A/B 测试——同一时间段，用两个插件做相同的任务。但现实中切换后不会切回去做对照，这个实验设计目前情况难以落地。

更理想的方案还包括：按任务类型分层对照，控制任务类型后比较同类开销；把任务完成率和返工率纳入评估（省 token 但返工更多等于没省）；把并行/阻塞能力作为体验维度量化评估。

本文做到的是时间窗口对齐后的分组对比，离理想方案还有距离，期待有条件的读者做更严谨的对照实验，分享结果。

收尾

切换成本低，试一试没坏处。但别对「省钱」抱太大预期——真正的差异在体验和架构选择上，不在 token 数。

附录 A：调研详情

切换前我做了对比调研，以下是核心差异：

核心动机很直接：prompt 短了，上下文少了，token 应该省。实际测试的结果说明，这个推理链条太简单了。

附录 B：打标口径

数据可信的前提是打标方法可审计。以下是分类规则：