calmnite 的博客

Appearance

OpenCode + Oh My OpenCode：一个"组装机玩家"的深度手记 ​

如果你也受够了 Claude Code 的系统提示词轰炸，又对原生 OpenCode 的"单兵作战"模式感到力不从心，这篇文章可能是你需要的。

一、为什么选 OpenCode？系统提示词少就是正义 ​

我换到 OpenCode 的起因其实挺朴素的——Claude Code 的系统提示词太多了。每次打开会话，背后塞进来一大堆 Anthropic 的"价值观灌输"和预设行为约束，你明明只是想让 AI 帮你改个函数，它却要先把"安全准则"朗读一遍。我不是说安全不重要，但那种被过度包养的感觉，对于一个想保持控制感的用户来说，真的很累。

OpenCode 在这方面清爽得多。它的系统提示词精简，留给你和模型之间的"对话空间"更大。而且它是开源的，你看得到它在干什么，不用猜背后有没有埋什么你不喜欢的后门或者偏好注入。这点对我这种对 Anthropic 天然不信任的人来说，是刚需。

但原生 OpenCode 也有明显的短板：

  • 单模型单线程：一个会话里只有一个模型在跑，复杂任务得你自己拆 prompt
  • 没记忆：换个 session，之前聊的全忘，项目上下文得重新喂
  • 容易"太监"：任务跑到一半，AI 说"我觉得这样可以了"，然后停了，留下一堆半成品
  • 没有规划模式：你让它重构一个模块，它直接动手改，不先问你"我打算这么干，行吗"

这些短板，在 Claude Code 里是被官方团队用 Subagent、Auto Memory、/plan 模式解决掉的。OpenCode 社区怎么办？答案就是 Oh My OpenCode。

二、Oh My OpenCode 是什么？不是新编辑器，是"指挥中枢" ​

我第一次听说 Oh My OpenCode（社区简称 OmO，现在官方改名叫 oh-my-openagent）的时候，还以为是又一个 AI 编辑器。其实不是——它是一个插件，给 OpenCode 装了一个多 Agent 调度系统。

作者的比喻很准：如果 OpenCode 是 Debian/Arch，那 OmO 就是开箱即用的 Ubuntu/Omarchy。

它到底补了哪些板？ ​

OpenCode 原生短板OmO 怎么补的
单模型单线程11 个专用 Agent + 多模型并行编排
任务做到一半容易"太监"TODO 未完成自动推进的 Boulder 机制
上下文膨胀后变笨70%/85% 阈值自动压缩 (Auto Compact)
没有深度代码理解LSP + AST-Grep 集成，不只是看文本
复杂任务需要手动拆 promptSisyphus 自动意图分析 + 任务分解
没规划直接动手Prometheus Planner —— 先出计划再执行
MCP 常驻吃 promptSkill-Embedded MCP —— 按需加载，用完即走
不能后台跑Background Tasks —— 关窗口也继续

那几个让我眼前一亮的 Agent ​

Sisyphus（西西弗斯）：核心执行者。名字取得好——推石头，推不完不许停。原生 OpenCode 最容易让人崩溃的场景就是：你让它改 5 个文件，改到第 3 个它说"我觉得剩下的不重要"然后提交了。Sisyphus 会维护一个 todo list，没干完就强制拦截，逼它继续。这种"防太监"机制，对长任务来说是救命的。

Prometheus：规划模式。你提需求后，它不会立刻动手，而是先分析、拆解、评估风险，输出完整计划等你确认。这很像 Claude Code 的 /plan，但 OmO 是把它做成了一个常驻 Agent 角色。

Skill-Embedded MCP：这个设计对我这种讨厌 MCP bloat 的人来说，是最大卖点。传统 MCP 一开会话就把所有 tools 注册进 prompt，导致上下文膨胀、缓存失效。OmO 的做法是触发 skill 时才临时加载对应的 MCP，任务结束就关掉。搜网页时启动 playwright，搜完就关，prompt 始终保持干净。

多模型混编 ​

OmO 的另一个激进设计是天生支持多模型混编。Claude Code 主要跑 Claude 全家桶，而 OmO 的调度逻辑是：Claude 负责规划、GPT 负责审查、Gemini 负责 UI、Kimi 负责加速。每个 Agent 自带一套硬编码的模型降级链，如果首选模型挂了或者没配，自动往下切。

比如 Sisyphus 的默认链是：Claude Opus → Anthropic → OpenCode Go/Kimi → GPT → GLM → 免费兜底。你不需要手动给每个 Agent 填 provider，只要通过 OpenCode 的 auth login 把 provider 连好，OmO 启动时会自动探测可用模型，然后按链匹配。

当然，如果你想全走 DeepSeek 省钱，也可以覆盖配置：

jsonc
// ~/.config/opencode/oh-my-opencode.jsonc
{
  "agents": {
    "sisyphus": {
      "model": "deepseek/deepseek-v4-flash",
      "fallback_models": [
        "deepseek/deepseek-v4-pro"
      ]
    }
  }
}

三、改名风波：oh-my-opencode 到底过没过时？ ​

这是我在调研阶段最大的困惑。GitHub 仓库和新文档都叫 oh-my-openagent，但 npm 上 oh-my-opencode 还在，而且下载量远超新名字（~108K vs ~4.8K）。

我当时的直觉是：老包名是不是被弃用了？装它会不会拿到过时代码？

查完之后发现完全不是：

  • oh-my-opencode 仍在活跃更新，最新 v4.19.1
  • 两个包名是 dual-publish——每次发版同时推送到两个名字
  • 代码内容完全一致
  • 唯一"过时"的地方只是配置层面的 legacy warning（opencode.json 里写 "oh-my-opencode" 会弹提示，推荐改成 "oh-my-openagent"）

所以结论很简单：装哪个都一样，里子是完全一样的代码。改名只是面子工程，过渡了快半年还没彻底切过去。

四、性能实测：重型框架的代价 ​

OmO 被很多人称为"重型框架"，这个"重"是真实可感的。

启动开销 ​

社区反复抱怨的一个点是：OmO 启动时注入太多工具和 MCP。一个简单的 "Hello world" 请求，就能烧掉 15,000~25,000 token 的上下文窗口设置开销。这些 token 不是用来对话的，是用来"初始化武器库"的。

维护者知道这个问题，正在做 deferred tool loading（延迟加载），但截至 2026 年初这仍是真实成本。

Windows 特有问题 ​

GitHub 上有个著名的 issue #1180，说的是每次回车有 3 秒延迟。这个 issue 的状态是 Closed as not planned，意味着维护者不打算在底层修它。

最新的 v3.17.5 版本确实在集中搞性能优化：

  • 目录扫描结果缓存（减少重复 IO）
  • Skill 加载缓存优化
  • 加了性能回归测试

但那个"每次回车延迟"的 Windows 特有问题，没有明确的 changelog 说已解决。如果你装完觉得卡，大概率就是这个历史遗留问题。

我的体感 ​

我实际用下来的感觉是：长任务场景下 OmO 的收益远大于成本。如果你只是偶尔让 AI 改两行代码，那 OmO 的启动开销确实显得笨重；但如果你要处理"重构一个模块 + 写测试 + 更新文档"这种多步骤任务，Sisyphus 的防太监机制和 Prometheus 的规划模式，能帮你省去大量来回拉扯的精力。

五、和 Claude Code 的对比：组装机 vs 品牌整机 ​

很多人问：装了 OmO，OpenCode 是不是就追上 CC 了？

我的判断是：在"多 Agent 编排"这个具体维度上，OmO 让 OpenCode 从"明显落后"跳到了"功能对标、局部领先"。但 OpenCode + OmO 作为一个整体系统，和 Claude Code 的关系更像是「组装机 vs 品牌整机」。

维度OpenCode + OmOClaude Code
配置自由度极高，模型、Agent、MCP 随便组合低，主要是 Claude 全家桶
开箱成本高，需要调 omo.jsonc、模型映射、API key 矩阵低，auth 完就能用
维护稳定性社区项目，依赖维护者精力Anthropic 官方一等公民
底层集成深度插件层封装，OpenCode 有 bug 绕不过去官方深度集成
多模型混编天生支持基本不支持
系统提示词少，清爽多，厚重
透明度开源，全看得见闭源

OmO 的作者烧了 $24K 才调出最佳实践，这意味着默认配置不一定适合你，你得自己调。CC 是"开箱即用"，OmO 是"开箱后还要装一堆电池"。

但如果你是那种愿意花时间调配置、换模型、看底层逻辑的人，OpenCode + OmO 的配置上限更高、更透明、更自由。CC 的一致性更好、维护成本更低，但你也得接受它的封闭和提示词轰炸。

六、安装建议：别急着往 C 盘塞 ​

OmO 是 npm 全局包。如果你还在用默认的 npm prefix（C:\Users\<name>\AppData\Roaming\npm），它会继续往 C 盘塞东西。我的建议是先把 npm prefix 改到空间大的盘（比如 E 盘），再装：

bash
npm config set prefix "E:\tools\npm"
npm config set cache "E:\tools\npm-cache"
# 然后更新 PATH，把新的路径加进去

安装命令（两个名字都行，代码一样）：

bash
npm install -g oh-my-opencode
# 或者
npm install -g oh-my-openagent

装完之后建议先跑诊断：

bash
bunx oh-my-openagent doctor

它会检查插件配置、模型映射、有没有用 legacy 包名等，给出一个健康报告。

七、写在最后：它不是银弹，但是必装的增益 ​

我不会说 Oh My OpenCode 让 OpenCode "完美追平"了 Claude Code。底层差异（官方深度集成 vs 社区插件封装）是抹不平的，Windows 上的性能问题也确实存在。

但如果你已经在用 OpenCode + DeepSeek（或其他国产模型）这条线，OmO 几乎是一个必装的增益插件。它不会让你后悔，但你也得接受它是"补强"而不是"抹平"——就像给组装机加了一张好显卡，游戏帧数确实上去了，但机箱散热和电源兼容的问题，还是得你自己盯。

我的止损线是：如果某个版本的延迟问题严重影响写代码的心流，我就降级到不带 OmO 的原生 OpenCode，等维护者修好了再升回来。目前 v3.17.5 的缓存优化已经让体验改善了不少，这个止损线暂时还没触发。

如果你也在用 OpenCode，建议至少试一周 OmO。那种"任务终于能跑完了"的感觉，值得你去适应它的启动开销。

写于 2026 年 8 月。文中提到的版本号、issue 状态均为当时实测，后续可能有变化，建议以官方仓库为准。

Last updated: