oh-my-opencode-slim 精简版实测：与完整版的关键区别在哪？
先说结论：slim 版确实更轻巧、更节省 token，但前提是你需要自己“手动操作”。
上一篇文章介绍了 oh-my-opencode 的理想拍档，评论区有朋友提到还有一个精简版 oh-my-opencode-slim。它在 GitHub 上也有 1.6k 的 Star，说明关注度确实不低。那么，它和完整版的核心差异到底在哪里？实际体验感受如何？
核心差异体现在哪些方面？
一、Agent 数量直接减半
完整版包含 12 个 Agent，slim 版精简到 6 个，分别是：
- 主编排者（orchestrator）：负责任务规划、委派与协调
- 探索者（explorer）：并行检索代码库、定位文件
- 图书管理员（librarian）：搜索和研究外部文档与库
- 预言家（oracle）：处理高风险架构决策、复杂调试及系统级权衡
- 设计师（designer）：UI/UX 实现、视觉呈现与响应式布局
- 修复者（fixer）：快速执行明确规格的编码任务
从数量上看，这已经是大幅精简了。
二、项目体积缩水明显
从项目体积来看，oh-my-opencode-slim 比完整版小了约 80%，文件数量减少了 87%。
这个差距相当直观。如果说完整版像是一个完整的开发工具箱，那么 slim 版就像一张随身携带的多功能工具卡。
三、提示词设计理念的差异
Agent 减少了，提示词自然也随之精简。以主编排 Agent 为例：
完整版中，Sisyphus 的提示词包含两部分——静态提示词 sisyphus-prompt.md 和动态提示词 src/agents/sisyphus.ts，仅静态提示词就有 742 行。
而 slim 版的 orchestrator 提示词以常量形式存放在 src/agents/orchestrator.ts 中，只有 172 行。
这不仅仅是行数的差异，背后是两种完全不同的设计哲学：
- Sisyphus 更像一个企业级“操作系统”式的编排器，本质上是 AI 工程执行框架，而不仅仅是提示词
- Orchestrator 则是高效调度型编排，像一个经验丰富的 Tech Lead 在做快速任务调度
从复杂度对比来看，差异仍然相当明显：
| 维度 | Sisyphus（完整版） | Orchestrator（slim版） |
|---|---|---|
| 规则密度 | 极高 | 中等 |
| 冗余度 | 高 | 低 |
| 学习成本 | 高 | 低 |
| token 消耗 | 非常高 | 较低 |
| 执行刚性 | 很强 | 高弹性 |
四、实际 token 消耗差距
在实际使用中，token 消耗的差异也很明显。多次测试的结果显示：
完整版下 Sisyphus Agent 完成任务的 token 消耗为 36605，耗时 58.6 秒。
slim 版下 Orchestrator Agent 完成同等任务的 token 消耗为 27711，耗时 1 分 13 秒。
为了数据准确，反复测试了好几轮。结论是：slim 版的消耗确实少很多，但耗时并不一定占优势。而且两个版本都存在一个共同问题——多轮对话后，结果才能达到预期。
另外，slim 版还去掉了完整版中一些比较“强势”的自动行为，比如 todo 续做、重试循环等。
各自适合什么场景？
从主编排 Agent 的定位差异出发，可以延伸到两个工具的整体适用场景。
完整版 oh-my-opencode 的特点是：
- 内置了大量生命周期钩子（Hooks）
- 能自动规划、拆分任务并管控上下文
- 支持多 Agent 并行处理（Sisyphus + Librarian + Explorer + Oracle 等）
- 具备自动补缺、自动恢复、自动背景检查能力
因此它不只是在写代码，而是把复杂任务拆解成可执行的小步骤，让多个 Agent 协同工作，整个研发流程更加工程化。特别适合复杂工程、需要自动规划以及长期任务推进的场景。
slim 版 的特点是：
- 去掉了大部分 hooks（强制 TODO、retry 循环等）
- 提示词更短、更纯粹
- 保留了核心的袋鼠分工机制
- 不再做过度的上下文监控和激进压缩
所以它在保持多 Agent 协作的基础上，变得更轻、更可控、更直奔需求。非常适合短任务、明确目标、想自己掌控流程的场景，当然也适合对 token 成本敏感的场景。
换句话说：
完整版是 AI 项目经理——它会主动拆解任务、跟进进度，确保需求按时完成。
Slim 版是 AI 执行工程师——给出指令后，直接埋头干活，干完就停。
如何用好 slim 版？
因为 slim 版不像完整版那样会自动拆解、自动续做、自动兜底，所以如果使用太随意，确实会感觉“没那么聪明”。实际上，它最擅长的是高可控和低成本，前提是你自己得带节奏。
几条使用建议：
- 一次只做一件清晰的事。它不会主动拆分任务，那就由你把任务说清楚
- 明确输入边界。指定要修改哪个文件、哪个函数，执行起来会更稳定
- 定期清理上下文。slim 版不会主动压缩上下文，需要手动操作
- 复杂任务需要手动分阶段。不要指望一步到位，拆成几步来做更靠谱
上次用完整版做了一个五子棋，这次用 slim 版来做一个贪吃蛇。
安装方式很简单，把对应提示词提供给 AI 即可。
鉴于 slim 版属于“手动挡”工具，所以需要一步一步跟 AI 沟通：
第一步，先设计结构。让 AI 给出框架设计，而不是直接输出代码。这样便于人为介入，避免过度设计或不合理设计。
第二步，基于设计实现基础画布和主循环。只做初始化，不涉及蛇逻辑和食物。
第三步，实现蛇的数据结构和移动逻辑。用数组存储蛇身，每隔固定时间移动一格。
第四步，加入方向控制。键盘方向键控制，不允许反向移动。
第五步，加入食物和变长逻辑。食物随机生成在未被蛇占用的位置。
第六步，加入碰撞检测和结束逻辑。撞墙或撞自己时游戏停止，显示 Game Over。
第七步，增加分数系统。每吃到一次食物加 1 分，Game Over 时显示最终分数。
第八步，支持移动端。增加四个方向按钮，保留键盘控制。
第九步，补充开始按钮。因为一开始忘记加，导致游戏一进来就自动开始了。补充后改成手动启动、可重新开始。
最终成果就是一个完整的贪吃蛇游戏。
整个过程里，每一步都需要人为介入。对于追求高可控性的开发者来说，这种方式反而很友好——既减轻了 AI Coding 时的心智负担，又能提高开发效率和准确率。
总结
oh-my-opencode 的初衷是让 OpenCode 不仅能写单条指令的代码，还能像一个真实团队那样进行规划、分配、协作和执行复杂任务。
但随之而来的过度自动化——比如不停催你完成 TODO、自动重试循环、深入背景检查——反而让一部分人觉得“啰嗦”“烦人”“token 消耗大”。
于是出现了 oh-my-opencode-slim——去掉冗余、保留核心能力、更直达任务执行的版本。
完整版是自动驾驶，slim 版是手动操控。选择哪个，取决于你的项目复杂度和个人偏好。
