OpenCode 配置 Oh My OpenAgent（OMO）记录

今天主要折腾的是 OpenCode 里的 oh-my-openagent，也就是之前常被叫作 oh-my-opencode 的这套插件。它不是一个单独的模型客户端，而是挂在 OpenCode 上的一套增强层：多 Agent、角色分工、规划模式、检索工具、模型 fallback、variant 档位这些能力都由它来组织。

我一开始比较关心两个问题：安装以后会不会影响原来的 OpenCode 使用，以及如果模型主要来自一个中转站，还值不值得配置 OMO。最后的结论是：只要不强制触发 ultrawork，普通 opencode 仍然可以正常用；OMO 更像是给复杂任务准备的增强工作流。对于后台管理系统加模块、跨多文件改业务这种任务，它比裸 OpenCode 更有意义。

安装过程

安装前先确认 OpenCode 版本。官方安装器要求 OpenCode 至少 1.4.0+，本机后来升级到了：

opencode --version
# 1.14.40

然后使用最小安装方式，只注册插件，不做任何账号认证：

npx -y oh-my-openagent@latest install --no-tui --claude=no --openai=no --gemini=no --copilot=no --opencode-zen=no --zai-coding-plan=no --opencode-go=no --kimi-for-coding=no --vercel-ai-gateway=no --skip-auth

安装完成后，OpenCode 主配置里会出现插件：

"plugin": [
  "oh-my-openagent@latest"
]

cc-switch 和 OMO 的关系

我之前一直通过 cc-switch 管模型配置。现在理解下来，cc-switch 和 OMO 的职责不一样。

cc-switch 更适合管底层 provider，比如中转站地址、API key、baseURL、模型列表，以及把这些 provider 写入 OpenCode live config。

OMO 则不直接管理这些 key。它关心的是 OpenCode 当前能看到哪些 provider/model，然后把这些模型分配给不同角色。

所以实际配置链路是：

cc-switch -> OpenCode provider/live config -> oh-my-openagent agent/category model mapping

如果 cc-switch 里的某个 provider 没有同步进 OpenCode，OMO 也就看不到。可以用下面命令确认 OpenCode 当前能看到哪些模型：

opencode models

今天最后可用的关键模型有这些：

mimo/mimo-v2.5
mimo/mimo-v2.5-pro
openai/gpt-5.2
openai/gpt-5.3-codex
openai/gpt-5.3-codex-spark
openai/gpt-5.4
openai/gpt-5.4-mini
openai/gpt-5.5
deepseek/deepseek-v4-flash
deepseek/deepseek-v4-pro
deepseek/deepseek-v4-pro-search

中转站模型 variants

中转站给的 OpenCode 配置里有这样的写法：

"variants": {
  "low": {},
  "medium": {},
  "high": {},
  "xhigh": {}
}

这不是四个模型，而是同一个模型的四个推理档位。空对象 {} 的意思不是不能用，而是声明这个档位存在，具体参数让 OpenCode 和 provider 用默认规则处理。

比如 openai/gpt-5.5 可以有：

low
medium
high
xhigh

如果 OMO 里不写 variant，通常就是走默认档位，大致可以理解成偏 medium，但最终还要看中转站默认行为。为了让关键 Agent 更明确，今天给 GPT 相关角色补了 variant。

当前 OMO 分工

现在的整体思路是：GPT 做主力，MiMo 做中强度辅助，DeepSeek 做检索和轻任务。

主调度和规划：

"sisyphus": {
  "model": "openai/gpt-5.5",
  "variant": "high"
},
"prometheus": {
  "model": "openai/gpt-5.5",
  "variant": "high"
}

深度判断和复核：

"oracle": {
  "model": "openai/gpt-5.5",
  "variant": "xhigh"
},
"momus": {
  "model": "openai/gpt-5.5",
  "variant": "xhigh"
}

执行型 Agent：

"hephaestus": {
  "model": "openai/gpt-5.5",
  "variant": "medium"
}

检索和探索：

"librarian": {
  "model": "deepseek/deepseek-v4-pro-search"
},
"explore": {
  "model": "deepseek/deepseek-v4-pro-search"
}

视觉和前端相关：

"multimodal-looker": {
  "model": "openai/gpt-5.4",
  "variant": "medium"
},
"visual-engineering": {
  "model": "openai/gpt-5.4",
  "variant": "medium"
}

MiMo 没有放到多模态位置，而是用在协调、审查、次主力这些位置：

"sisyphus-junior": {
  "model": "mimo/mimo-v2.5-pro"
},
"metis": {
  "model": "mimo/mimo-v2.5-pro"
},
"atlas": {
  "model": "mimo/mimo-v2.5-pro"
}

轻任务和写作：

"quick": {
  "model": "deepseek/deepseek-v4-flash"
},
"writing": {
  "model": "mimo/mimo-v2.5"
}

这个配置不是追求每个模型都用上，而是让模型出现在更合适的位置。比如 mimo-v2.5-pro 不支持多模态，就不应该硬塞给视觉 Agent。

后续怎么使用 OMO

平时还是可以正常运行：

opencode

如果只是小改动，不一定需要触发 OMO 的重型工作流。普通提问、简单修 bug、改字段，直接让 OpenCode 做就可以。

遇到复杂任务时，比如后台管理系统新增一个模块，跨表、菜单、权限、路由、控制器、页面、导入导出这些都要动，就可以在提示词里加：

ultrawork

或者简写：

ulw

它会更倾向于使用 OMO 的多 Agent 和执行闭环。

如果任务还不清楚，不要一上来就让它动代码。可以先用规划方式，让它先问清楚需求，再产出计划，再执行。官方文档里推荐的思路是用 Prometheus 这类规划 Agent 先把范围定清楚。

配置调整建议

现在这套配置适合日常开发，但后面可以按实际体验微调。

如果觉得慢或者贵，可以先降这些位置：

oracle: xhigh -> high
momus: xhigh -> high
ultrabrain: xhigh -> high

如果觉得检索不够准，可以让 librarian 或 explore 的 fallback 更靠近 GPT，例如加上 openai/gpt-5.4。如果只是日常后台管理系统开发，不建议所有角色都上 gpt-5.5 xhigh，那会浪费。

最后记一下判断

OMO 不是每个任务都必须用。它的价值主要在复杂任务：多文件、多步骤、多角色、需要规划和复核的开发工作。

假如我有一个后台管理系统项目，后续如果是“新增一个完整业务模块”，它是适合的。因为这类任务最容易漏菜单、权限、验证、路由、模型关系、列表筛选这些边角。OMO 的好处不是让模型突然变聪明，而是把任务拆给更合适的角色，并且在执行过程中减少漏项。

如果只是小修小改，就继续轻量用 OpenCode。复杂活再喊 ultrawork。

PS：实测非常废token，谨慎使用，没什么事的话还是继续用superpowers就可以，这个插件非常非常重。token多的随意。

项目地址

oh-my-openagent GitHub地址: https://github.com/code-yeongyu/oh-my-openagent

检测到移动端访问