Skip to main content

Oh My OpenCode / OpenAgent 技术分享笔记

如果说 OpenCode 解决的是“AI 能不能进终端干活”，那 Oh My OpenCode（官方现在更常见的名字是 Oh My OpenAgent，下面还是简称 OMO）解决的更像是另一件事：它进来以后，到底能不能像一个靠谱团队那样干活。

这也是这篇文档想讲清楚的重点。它不是单纯多塞几个 agent 名字，也不是把 prompt 包装得更神秘一点，而是把“先理解意图、再拆任务、并行找资料、最后做验证”这套原本靠人自己脑补的流程，尽量做成默认工作流。

Oh My OpenCode 官方预览图

图：Oh My OpenCode 官方仓库里的预览图。第一眼看上去，它不像只是多了一个 AI 按钮，而更像是给 OpenCode 接上了一套偏工程团队协作的外骨骼。

先用一句话理解它​

先用一句更顺手的说法来理解：

  • OpenCode 提供终端里的工作现场，能读代码、改文件、跑命令。
  • OMO 负责把“谁来查、谁来想、谁来做、谁来验”这件事安排明白。

所以它更像是在 OpenCode 之上补了一层 agent harness / orchestration。重点不是 agent 数量变多了，而是复杂任务终于有了比较像样的分工。

这篇文档适合怎么读

如果你是第一次接触 OMO，可以先看“它适合谁”“角色分工”“第一次上手”这三节；如果你已经在用 AI coding 工具，更值得重点看“为什么它更像工程团队”和“什么时候该用、什么时候别用”。

先把名字讲清楚，免得一上来就被绕晕​

OMO 现在有一个很容易把人看迷糊的地方：按目前能查到的官网、仓库和安装命令来看，官方展示更偏向 Oh My OpenAgent，但安装包、命令名和很多旧资料里，仍然经常能看到 oh-my-opencode。

你可以先这样记：

  • GitHub 仓库和官网现在更常用 oh-my-openagent
  • npm 包和安装命令里仍然常见 oh-my-opencode
  • 配置文件和社区文章里，新旧名字都可能同时出现

第一次看到这两个名字混着出现，不用怀疑人生。更稳妥的理解是：按当前资料和工具表现来看，它更像是一套正在迁移命名、同时兼容旧入口的体系，而不是两个完全独立的产品。

它到底更适合哪种人​

如果你平时本来就接近下面这种工作方式，OMO 大概率会比“单 agent 一路硬怼”更顺手：

  • 长时间待在终端、Tmux、SSH、Neovim 这一套环境里。
  • 做的任务经常不是改一行代码就结束，而是要查代码、翻文档、跑命令、验证输出一起上。
  • 已经开始感觉到，真正拖慢 AI 干活的，未必是模型本身，而是流程太乱。
  • 愿意花一点时间把规则、配置、约束写清楚，换后面更稳定的持续收益。

如果你只想让 AI 补一行代码、改一句文案、解释一个配置项，那普通补全插件或者单 agent 工具通常更便宜也更安静。OMO 更适合那种“把任务交给它一段时间，它别半路装睡”的场景。

它为什么比普通 agent 更像一个团队​

OMO 最直观的不同，不是“会的事更多”，而是分工终于像回事了。

在官方资料里，你会看到像 Sisyphus、Prometheus、Hephaestus、Oracle、Librarian、Explore、Metis、Momus 这样的角色。名字听起来像神话人物团建，但职责其实很务实。为了更容易讲清楚，可以先把最常提到的几类角色压成一张偏工作化理解的表：

角色官方语境里的大致职责偏工作化理解
Sisyphus主编排者更像技术负责人，负责判断意图、拆任务、派 agent、盯验证。
Prometheus规划师更像先采访你、再写方案的那位，不急着直接开工。
Hephaestus深度执行者适合吃下复杂实现、长链路推进这类更重的执行工作。
Oracle架构顾问 / 疑难问题会诊适合在方向不明确、调试卡住、需要判断取舍时出场。
Librarian文档与外部资料检索负责去官方文档、GitHub 和示例代码里找证据。
Explore仓库内探索快速 grep、找文件、查模式，像一个不嫌麻烦的代码搜索员。
Metis预分析顾问在任务还模糊时先帮你拆清楚边界和风险。
Momus审稿 / 评审帮你看计划和结果里有没有漏项、模糊点和验证缺口。

这套设计最有价值的地方在于，主 agent 不必一边想架构、一边查官方文档、一边 grep 全仓库、一边还假装自己没漏掉边界条件。该查的让检索 agent 去查，该搜的让探索 agent 去搜，该拍板的交给更稳的模型去拍板。人写代码都知道分工重要，轮到 agent 当然也一样。

这里最值得强调的一个点

OMO 真正放大的，不只是模型能力，而是开发流程本身。它把“先分析、再规划、再执行、最后验证”这种工程纪律，变成了更容易被持续执行的默认路径。

先讲一个最小可用流程​

第一步：先把环境带起来​

如果你已经装好了 OpenCode，OMO 最直接的安装方式通常是：

bunx oh-my-opencode install

装完以后，建议马上跑一遍：

bunx oh-my-opencode doctor

这一步很关键，因为 AI 工具最烦人的问题通常不是“不会用”，而是“你以为它装好了，结果它只是在礼貌地失败”。doctor 这种自检命令，能帮人少走很多“明明昨天还能跑”的弯路。

第二步：进项目，再启动 OpenCode​

cd /path/to/your/project
opencode

如果面对的是第一次接触 OpenCode 的人，这里最好补一句说明：很多命令是 进入 TUI 之后再输的 slash command，不是在 shell 外面直接敲。

第三步：先记住一个入口就够了​

OMO 最常被提到的入口基本就是这句：ultrawork，也就是 ulw。

进入 OpenCode 交互界面后，可以直接输入：

ultrawork
# 或者更短一点
ulw

它背后的意思其实很简单：把高精度模式、自动规划、并行 agent、验证回路这些能力一起拉起来。没必要先把每个角色都背熟，再决定要不要按下开始键。先把它当成一个入口跑一遍，通常更容易判断这套工作流适不适合当前场景。

第四步：什么时候该用​

ulw 不是仙丹，它更像“把整支施工队都叫来了”。

  • 如果任务是跨文件改动、需要查资料、要跑验证，它很值。
  • 如果任务只是改一个错字、看一个配置项说明，就没必要每次都开满编制。

这一点最好提前讲清楚，不然很多人第一次体验完只会记住一件事：它很强，但它也真的很会烧 token。

从配置视角看，为什么它会比较顺手​

比较值得先看清楚的，通常是这几个位置：

~/.config/opencode/
~/.config/opencode/opencode.json
~/.config/opencode/oh-my-opencode.json

~/.local/share/opencode/
~/.local/share/opencode/auth.json
~/.local/share/opencode/opencode.db
~/.local/share/opencode/snapshot/
~/.local/share/opencode/tool-output/

这里有个很实际的结论：一旦把“全局配置放哪、插件配置放哪、运行痕迹放哪”这三件事分清楚，后面很多排错都会轻松很多。

比如 opencode.json，核心思路其实可以很朴素：

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": [
    "oh-my-opencode@latest",
    "superpowers@git+https://github.com/obra/superpowers.git"
  ]
}

这段配置本身没什么玄学，重点在于它体现了一个事实：OpenCode 本来就适合继续往下长，而 OMO 刚好把“继续往下长”这件事做得更像工程体系，而不是单次脚本。

另外在 oh-my-opencode.json 这类配置文件里，也会看到一个很明显的变化：它已经不是“单模型单人格”那套玩法了，而是开始出现不同 agent、不同 category、不同职责的组合。也就是说，调的已经不只是一个 AI，而是一套工作流。

一个很实际的建议

如果你准备长期用 OMO，早点把全局配置、项目配置和数据目录这三件事分清楚。这样后面不管是迁移机器、排查问题，还是复用工作流，都会轻松很多。

它真正的优点，不只是“看起来厉害”​

1. 多 agent 协同是真的有用​

这不是为了把面板做得更热闹，而是因为复杂任务本来就不该让一个 agent 同时兼职侦察兵、架构师、施工队和质检员。该并行的时候并行，该分工的时候分工，完成度会稳定很多。

2. 很适合终端流工作方式​

如果你的工作已经在命令行里发生，OMO 这类增强层会非常自然。你不用在“浏览器里的 AI”和“终端里的真实现场”之间来回切换，思路更完整，动作也更顺。

3. 它会逼流程更像工程，而不是像许愿​

这一点其实很关键。先分析、再规划、再执行、再验证，这些本来就是正常开发流程。OMO 只是把这套纪律更明显地写进了系统行为里。懒人会觉得它有点啰嗦，踩过坑的人会觉得它终于像个同事了。

它的缺点也很明显，而且很现实​

1. 比较费 token​

多 agent、深度规划、背景检索、独立验证，这些东西都不是凭空出现的，背后基本都在烧 token。

所以 OMO 的强项和它的成本，几乎是同一枚硬币的正反面：你想要更完整的流程、更像团队协作的效果，那通常就得接受它不像“单次问答”那么省。

2. 名字和兼容层对新手确实有点绕​

仓库、官网、安装包、配置文件里的名字在过渡期里会并存。只要你知道它不是两个不同产品，而是一套正在迁移命名的体系，这个问题就不至于变成真正的阻碍。

3. 不适合所有任务都开满编制​

如果你只是改一句文案、修一个错字、看一个配置项说明，那上来就 ulw，多少有点像为拧灯泡先开项目启动会。它能干，不代表每次都值得这么干。

一个更稳妥的判断：把它当放大器，别当替身​

OMO 最适合的打开方式，不是把自己变成纯旁观者，而是把它当成一个能放大你已有工作流的系统。

如果本来就会拆任务、会判断风险、会区分“先查资料”和“直接动手”的差别，那它会非常好用；如果希望它自动理解一切、自动兜住一切、自动在一句话都没说清楚的前提下把事情办成，那最后大概率还是得自己回来收拾残局。

核心提醒

OMO 更像外骨骼，不是魔法棒。这个比喻只是为了帮助理解它的工作方式，不代表官方对能力边界的承诺；更现实地说，是先有自己的判断和基本功，它才会让流程更快、更稳，而不是凭空替人长出一双腿。

前面的内容可以收成四个重点​

  1. 它解决的不是“AI 会不会写代码”，而是“AI 干活时能不能有像样的分工”。
  2. 最容易让人理解的入口不是角色大全，而是 ulw 带起来的整套工作流。
  3. 真正该讲清楚的不是“它很强”，而是“它适合什么任务、不适合什么任务”。
  4. 最容易让人真正上手的，不是炫配置，而是先跑通一次最小闭环。

可以顺手收藏的官方页面​

最后留一句判断​

如果说 OpenCode 解决的是“AI 能不能真的进终端干活”，那 OMO 解决的更像是“它进来以后，到底能不能像个靠谱团队那样干活”。

更实际的结论其实很简单：它确实更强，也确实更费 token；它确实更像工程化工作流，也确实不太适合“随口问一句就走”的轻量场景。

但如果已经开始认真把 AI 当生产工具，而不只是聊天窗口，那 OMO 这条路，至少很值得亲手走一遍。

阅读次数--次