有使用 opencode+omo 的吗?

发布于

hiboshi:

昨晚刚刚开通的新的 opencode 。

使用的是 omo 官方推荐的配置,一个简单的项目都没完成就把周限额给干完了,月限额直接 50% 了,是我用的姿势不对么

"$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/assets/oh-my-opencode.schema.json",

"agents": {
// Sisyphus: Kimi K2.7 是 Claude 的顶级替代方案,用于编排
"sisyphus": {
"model": "opencode-go/kimi-k2.7-code",
"ultrawork": { "model": "opencode-go/kimi-k2.7-code" },
},

// Hephaestus: 需要 GPT。ChatGPT Plus 能让你到达这里。
"hephaestus": { "model": "openai/gpt-5.6-sol", "variant": "medium" },

// 建筑咨询: GPT 或 Claude Opus
"oracle": { "model": "openai/gpt-5.5", "variant": "high" },

// Prometheus 在各模型家族间保持相同的 ulw-plan-backed 提示
"prometheus": { "model": "opencode-go/kimi-k2.7-code" },

// Atlas 涉及交流 — Kimi 表现出色
"atlas": { "model": "opencode-go/kimi-k2.7-code" },

// 实用代理保持廉价
"explore": { "model": "opencode-go/qwen3.5-plus" },
"librarian": { "model": "opencode-go/qwen3.5-plus" },
},

"categories": {
"visual-engineering": { "model": "opencode-go/qwen3.6-plus" }, // Qwen 作为 Gemini 替代
"deep": { "model": "openai/gpt-5.6-terra", "variant": "xhigh" },
"ultrabrain": { "model": "openai/gpt-5.6-sol", "variant": "xhigh" },
"quick": { "model": "openai/gpt-5.4-mini" },
"unspecified-low": { "model": "opencode-go/kimi-k2.7-code" },
"unspecified-high": { "model": "opencode-go/kimi-k2.7-code" },
"writing": { "model": "opencode-go/kimi-k2.7-code" },
},

"background_task": {
"providerConcurrency": {
"openai": 3,
"opencode-go": 10,
},
},

---

原文链接:[点击查看](https://www.v2ex.com/t/1226720)

评论(18)

属于是正常操作了,多 agent 套娃就是这个德行,加上它还在那儿不停地切模型,缓存命中率根本没法看。我觉得 OMO 搞这么多 agent 和 category 分类,已经有点过度花哨了。

· 0 个赞

回复

确实,感觉它搞得太过度复杂了。到底有没有实质性效果我也不好说,反正我还没看到项目跑出结果,额度先给干光了。

· 0 个赞

一样的情况,GO 套餐这点额度真不够看。之前我搞大项目,按任务拆分成几个大 TASK,再细分为多个 Slice。结果光是处理一个 Slice(修改/新增了大概 1000~5000+ 行数据、代码和文档),就把周限额给直接干爆了。后来我也润了,转头去用 Codex Pro5x 了。

· 0 个赞

回复

对的。其实现在最新版 codex 默认的调度已经够用了,跟 OMO 的工作模式大差不差。OMO 针对它做了个 lazycodex 插件版(也就是常说的 omo Light),其实就是用来帮 codex 调度各种 hook、mcp 和子 agent 的。我也试过,确实能增强复杂编程的能力,但好得有限,而且烧 token 比原生 GPT 5.5 xHigh goal 还猛。另外最近 codex 上了 GPT 5.6,我感觉它原生的消耗速度都变快了不少,现在不用 OMO 竟然都比以前 5.5+OMO 还费了。

· 0 个赞

回复

那确实准备弃坑了。顺便问一句,如果不用 OMO,纯原生的 opencode 是不是就没啥优势了?那我还不如直接回去用 codex 省心?

· 0 个赞

你可以试试精简版的 omo-slim。

· 0 个赞

我已经放弃 OMO 了,折腾半天,感觉还是 superpowers 用起来更顺手,更适合我的习惯。

· 0 个赞

兄弟,没啥特殊需求的话,最好别让它在不同厂商的模型之间来回横跳。每次切换遇到冷启动,缓存就直接 0 命中了,Token 消耗会直线上升。

· 0 个赞

回复

确实是这样,其实我也没啥硬性需求,当初就是不想被单一 agent 厂商绑架才没选 cc 和 codex,转头用了开源的 opencode。但原生的纯 OP 又不太好用,就套了个 OMO,没想到消耗这么大。

· 0 个赞

可以去翻翻 OMO 的官方文档,自己手动配一下备用模型,除了核心业务必须要用 GPT 系列外,其他的任务一律换成便宜的模型就行。下面这个配置可以参考一下(附 JSON)

· 0 个赞

回复

兄弟,你配置里 sisyphus 用的 opencode-go/kimi-k2.7-code 可一点都不便宜啊!我跑这个单是输出就烧了4刀,结果一个简单的接口需求都没写完,额度就见底了。对于 opencode-go 这个套餐来说,根本就不够扛的。

· 0 个赞

OMO 这个 harness 其实非常吃资源,只有在搞大型项目(用来防漂移)的时候才真正好用。而且 opencode 的 go 套餐给的额度本来就抠门,你再选了特别费配额的 kimi-k2.7-code 去做主力(sisyphus),那肯定不经造啊。如果死磕 go 套餐,建议换成小米或者 DeepSeek 的模型,这俩家给量最大,而且能力也够打。

· 0 个赞

我直接让网页版的 OpenAI 和 Claude Code 帮我写了个配置,日常优先跑 deepseek flash 和 mino 这种便宜的套餐。实际上手感觉还行,碰到复杂逻辑它会自己切到高级模型去兜底。

· 0 个赞

感觉 OMO 并不怎么好用,甚至可以说这种纯靠 prompt 来硬性约束 Agent 的路子本身就不太靠谱。说到底还是得看基座模型自带的能力,外加我们自己怎么去合理拆分需求。这可是我烧了几百 B 的 token 才得出的血泪教训啊。

· 0 个赞

感觉 GO 套餐用着不够啊。做大项目把任务分得细,每个 TASK 的 Slice 修改/新增个几千个数据和代码,周限额就没了。后来干脆不做了,转用 Codex Pro5x 了。

· 0 个赞

回复

我也准备放弃了,感觉如果不用 omo,直接用 codex 省心多了。

· 0 个赞

回复

是啊,如果不依赖 omo,是否就没什么优势了?不如直接用 codex 更简单一些?

· 0 个赞

正常,多 agent 之间频繁切换,缓存率估计没啥保障。我觉得 OMO 里的几个 agent 和类别,反而搞得花样太多了。

· 0 个赞