2026 年的 AI 编程工具生态中,单模型 CLI 已不再是终点。围绕 Claude Code 和 OpenCode 两大基座,分别涌现出 oh-my-claudecode(OMC)oh-my-openagent(OmO) 两个重量级多 Agent 编排框架。两者 GitHub star 数合计超过 9 万,代表了当前 Agentic Coding 编排层的两种核心思路:单模型深度增强 vs 多模型原生编排

本文从架构设计、核心功能、安装配置、实际使用等维度展开系统对比,并提供可直接上手的实用教程。

项目概览

维度 oh-my-claudecode (OMC) oh-my-openagent (OmO)
GitHub Stars 33.7k 57.6k
基座平台 Claude Code(Anthropic) OpenCode
主语言 TypeScript 58% / JS 40% TypeScript 93%
许可证 MIT SUL-1.0
最新版本 v4.13.7 (2026-05-09) v4.1.1 (2026-05-13)
npm 包名 oh-my-claude-sisyphus oh-my-opencode / oh-my-openagent
核心定位 Teams-first Multi-agent orchestration for Claude Code Multi-model agent harness for OpenCode
创建者 Yeachan Heo code-yeongyu

设计哲学对比

OMC:零学习曲线的 Claude 增强

OMC 的核心主张是 “Don’t learn Claude Code. Just use OMC.” 在 Claude Code 生态内部做深度增强,通过 19 个专业 Agent、智能模型路由(Haiku 处理简单任务,Opus 处理复杂推理)和魔法关键词触发机制,将多 Agent 编排的复杂性隐藏在自然语言交互之下。

设计假设:Claude 系列模型已足够强大,编排层的核心价值在于将单一模型的能力最大化——通过 Agent 专业化分工、持久化执行循环和自动验证机制来实现。

OmO:多模型原生编排

OmO 的 Ultrawork 宣言开宗明义:“human intervention during agentic work represents system failure”(人类在 Agent 工作中的干预代表系统故障)。设计理念建立在一个核心判断之上——没有任何单一 AI 供应商能在所有任务类型上保持最优,因此需要根据任务特征将工作路由到最合适的模型。

设计假设:不同模型有不同的认知特长(Claude 擅长结构化输出、GPT 擅长显式推理、Gemini 擅长视觉任务),编排层的核心价值在于跨模型协调——通过分类路由、后备链和累积学习来实现。

架构对比

OMC 的双表面架构

OMC 在两个运行表面上提供能力:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
┌─────────────────────────────────────────┐
Claude Code Session

┌──────────┐ ┌──────────┐ ┌────────┐│
/team │ │ /ralph /ccg ││
Pipeline Loop Tri-AI ││
└────┬─────┘ └────┬─────┘ └───┬────┘│

┌────▼──────────────▼────────────▼────┐│
19 Specialized Agents ││
(architect, executor, designer, ││
verifier, explorer, writer...) ││
└─────────────────────────────────────┘│
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
Terminal CLI (omc)

omc team 2:codex "..."
omc team 2:gemini "..."
omc team 1:claude "..."

┌────▼─────────────────────────────┐
tmux Worker Panes
┌───────┐ ┌───────┐ ┌────────┐
Claude Codex Gemini
CLI CLI CLI
└───────┘ └───────┘ └────────┘
└──────────────────────────────────┘
└─────────────────────────────────────────┘

Session 内通过插件系统运行 Agent 编排(team 管道、ralph 循环等);CLI 层通过 tmux 进程隔离的方式启动 Codex、Gemini 等第三方 CLI 工作节点。两个表面共享 skill 系统和状态存储。

Team 模式的执行管道:plan → prd → exec → verify → fix(循环)

OmO 的三层架构

OmO 采用规划-执行-工作三层分离的设计:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
┌─────────── Planning Layer ──────────────┐
│ │
│ Prometheus ──→ Metis ──→ Momus │
│ (规划) (缺口检测) (验证) │
│ │
Output: 50-200 行详细执行计划 │
└────────────────┬─────────────────────────┘

┌────────────────▼─────────────────────────┐
│ Execution Layer │
│ │
│ Atlas (指挥官) │
- 读取计划,分配任务 │
- 不直接写代码 │
- 累积学习:conventions / gotchas │
- 验证每个子任务结果 │
└────────┬───────┬───────┬─────────────────┘
│ │ │
┌────────▼──┐ ┌──▼────┐ ┌▼──────────────┐
│Sisyphus-Jr│ │Oracle │ │visual-engineer │
│(执行) │ │(架构) │ │(前端) │
│ │ │ │ │ │
│ Category │ │ Read │ │ Gemini 3.1
Routing: │ │ Only │ │ Pro │
│ deep/quick│ │ │ │ │
/ultrabrain│ │ │ │ │
└───────────┘ └───────┘ └───────────────┘

关键设计约束:Prometheus 只能写 Markdown 计划,Atlas 不能写代码,Junior 不能委托——严格的角色隔离防止职责混淆。

架构差异的本质

维度 OMC OmO
模型策略 Claude 为主,Codex/Gemini 为辅助 多模型平等,按分类路由
Agent 命名 功能导向(executor, verifier) 神话导向(Sisyphus, Prometheus)
角色隔离 软隔离(Agent 类型区分) 硬隔离(工具级权限限制)
上下文管理 Session 内压缩 + 技能注入 累积学习 + boulder.json 持久化
多模型实现 进程级(tmux 独立 CLI) API 级(分类路由到不同模型)

核心功能特性对比

Agent 系统

OMC 提供 19 个专业 Agent,按层级变体覆盖架构、研究、设计、测试、数据科学等领域。通过智能模型路由自动选择 Haiku(轻量任务)或 Opus(复杂推理),官方声称节省 30-50% token 开销(此数据来自项目方自身,未经第三方验证)。

OmO 采用命名 Agent 体系,每个 Agent 绑定特定模型并调优:

Agent 绑定模型 职责
Sisyphus Claude Opus 4-7 / Kimi K2.6 / GLM-5.1 主编排器
Hephaestus GPT-5.5 自主深度执行
Prometheus Claude Opus 4-7 / Kimi K2.6 战略规划
Oracle 架构与调试(只读)
Atlas 执行指挥与验证

编辑系统

OMC 使用 Claude Code 原生的编辑工具。

OmO 独创了 Hashline 哈希锚定编辑 系统——每行代码标记内容哈希(LINE#ID),Agent 编辑时引用这些标记,如果文件已变更则哈希不匹配、编辑被拒绝。官方基准测试显示 Grok Code Fast 1 模型的编辑成功率从 6.7% 提升到 68.3%(此数据来自 OmO 项目 README,属单一来源)。

团队模式

OMC Team 管道(v4.1.7 起为标准编排模式):

  • 分阶段执行:plan → prd → exec → verify → fix(循环)
  • 支持 Claude/Codex/Gemini CLI 混合工作节点
  • 需要启用实验性 Agent Teams 功能

OmO Team 模式(v4.0,可选启用):

  • 最多 8 个并行成员
  • tmux 实时可视化(focus + grid 窗口布局)
  • 内置团队技能:hyperplan(5 个敌对 Agent 审查计划)、security-research(3 个漏洞猎手 + 2 个 PoC 工程师)

Skill 系统

两者都支持可复用的 skill 机制:

维度 OMC OmO
存储路径 .omc/skills/ (项目) / ~/.omc/skills/ (用户) .opencode/skills/*/SKILL.md
触发方式 关键词自动注入 + 斜杠命令 关键词自动注入
内置 skill git-master, frontend-ui-ux 等 playwright, git-master, frontend-ui-ux
特色 /skillify 自动提取模式 skill 自带 MCP 服务器(按需启停)
管理命令 /skill list\|add\|remove\|edit\|search 类似

OmO 的 skill-embedded MCP 是一个差异化设计:每个 skill 可以携带自己的 MCP 服务器,按需启动、任务结束后关闭,避免常驻 MCP 占用上下文窗口。

内置 MCP 与工具链

OMC 在 v4.4.0 移除了 Codex/Gemini MCP 服务器,转向 tmux CLI 工作节点方案。内置 LSP 工具(rename、goto definition、find references、diagnostics)和 AST-Grep。

OmO 默认启用三个 MCP 服务器:

MCP 功能
Exa Web 搜索
Context7 官方文档查询
Grep.app GitHub 代码搜索

同样内置 LSP 和 AST-Grep 工具。

执行模式汇总

模式 OMC OmO
团队编排 /team(分阶段管道) Team Mode(并行成员)
持久执行 /ralph(verify/fix 循环) Ralph Loop / ulw-loop
最大并行 /ultrawork ultrawork / ulw
自主执行 /autopilot 内置于 ultrawork
三模型合成 /ccg(Claude+Codex+Gemini) 通过分类路由实现
需求澄清 /deep-interview(苏格拉底式提问) Prometheus 访谈模式
计划共识 /ralplan hyperplan(5 Agent 对抗审查)

安装与配置教程

OMC 安装

前置条件

  • Claude Code CLI(需要 Claude Max/Pro 订阅或 Anthropic API key)
  • tmux(Team 模式和限流检测必需)
  • 可选:Gemini CLI、Codex CLI(多模型编排)

方法一:插件市场(推荐)

在 Claude Code session 中依次执行:

1
2
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode

方法二:npm 全局安装

1
npm i -g oh-my-claude-sisyphus@latest

初始化设置

1
2
3
4
5
6
7
# session 内
/setup
# 或
/omc-setup

# 终端
omc setup

启用 Team 模式

编辑 ~/.claude/settings.json

1
2
3
4
5
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}

可选:多模型支持

1
2
npm install -g @google/gemini-cli    # Gemini CLI
npm install -g @openai/codex # Codex CLI

三个 Pro 计划(Claude + Gemini + ChatGPT)月费约 $60。

OmO 安装

前置条件

  • OpenCode(OmO 是 OpenCode 的插件)
  • tmux(Team Mode 和交互式终端必需)
  • 推荐订阅:ChatGPT ($20) + Kimi Code ($19) + GLM Coding ($10)

安装方式

将以下提示粘贴到 LLM Agent 中(Claude Code、AmpCode、Cursor 均可):

1
2
Install and configure oh-my-openagent by following the instructions here:
https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md

手动安装参考 docs/guide/installation.md

诊断检查

1
bunx oh-my-opencode doctor

验证插件注册、配置、模型和环境是否正常。

配置文件位置

作用域 路径
用户级 ~/.config/opencode/oh-my-openagent.jsonc
项目级 .opencode/oh-my-openagent.jsonc

支持 JSONC 格式(允许注释和尾逗号)。

分类路由配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"categories": {
"visual-engineering": {
"model": "google/gemini-3.1-pro",
"variant": "high",
"description": "Frontend, UI/UX, design"
},
"ultrabrain": {
"model": "openai/gpt-5.5",
"variant": "xhigh",
"description": "Deep logical reasoning"
},
"quick": {
"model": "openai/gpt-5.4-mini",
"description": "Trivial tasks, typo fixes"
}
}
}

实际使用场景对比

场景一:修复 TypeScript 类型错误

OMC 方式

1
2
3
4
5
# 一句话触发
/team 3:executor "fix all TypeScript errors"

# 或使用魔法关键词
ulw fix all TypeScript type errors in src/

Team 管道自动执行:分析错误 → 制定修复计划 → 并行执行 → 验证通过。

OmO 方式

1
2
3
4
5
# 触发 ultrawork
ulw fix all TypeScript errors

# Sisyphus 自动将任务分类为 quick/deep,
# 路由到对应模型并行执行

Sisyphus 按错误复杂度分类,简单类型错误路由到 GPT-5.4 Mini(快速),复杂架构级类型问题路由到 GPT-5.5 xhigh(深度推理)。

场景二:全栈功能开发

OMC 方式

1
2
3
4
5
# 先用 deep-interview 澄清需求
/deep-interview "add user authentication with OAuth2"

# 苏格拉底式提问完成后,启动 team 执行
/team 3:executor "implement the OAuth2 auth plan"

执行流程:deep-interview 暴露隐藏假设 → team plan 阶段生成执行计划 → executor Agent 并行实现 → verifier 自动验证。

OmO 方式

1
2
3
4
5
6
7
8
9
10
# 按 Tab 键进入 Prometheus 模式
# Prometheus 自动进入访谈模式

# 规划完成后
/start-work

# Atlas 接管,分配子任务给不同模型
# 前端 → Gemini 3.1 Pro (visual-engineering)
# 后端逻辑 → GPT-5.5 (ultrabrain)
# 简单配置 → GPT-5.4 Mini (quick)

场景三:代码审查与安全审计

OMC 方式

1
2
3
4
5
6
# CLI 方式,启动 Codex 和 Gemini 并行审查
omc team 2:codex "review auth module for security issues"
omc team 1:gemini "check UI components for accessibility"

# 或 session 内三模型合成
/ccg review the payment module for security vulnerabilities

OmO 方式

1
2
3
4
5
# 使用团队技能
# hyperplan: 5 个敌对 Agent 从不同角度审查
# security-research: 3 漏洞猎手 + 2 PoC 工程师

# Team Mode 下自动编排安全审计流水线

选型决策指南

选 OMC 的场景

  • 已经深度使用 Claude Code:OMC 是 Claude Code 的原生插件,零迁移成本
  • Claude 模型满足需求:如果项目主要需要的能力(代码生成、推理、测试)Claude 都能覆盖,OMC 的深度增强比多模型切换更高效
  • 追求简单上手:插件市场一键安装,魔法关键词即用,不需要配置多个 API key
  • MIT 许可证需求:OMC 采用 MIT 许可,对商业使用更友好
  • 需要 Telegram/Discord/Slack 通知:OMC 内置完整的通知系统

选 OmO 的场景

  • 需要真正的多模型编排:前端用 Gemini、逻辑用 GPT、文档用 Claude——按任务特征自动路由
  • 已经使用 OpenCode:OmO 是 OpenCode 的原生增强
  • 对编辑可靠性要求高:Hashline 哈希锚定编辑显著减少了编辑失败率
  • 需要跨模型后备链:当首选模型不可用时,自动切换到下一个可用模型
  • 需要累积学习:每个子任务的经验教训自动传递给后续任务,避免重复犯错
  • 更大的社区生态:57.6k stars,66+ 衍生项目,多语言 README

两者的共同局限

  • 复杂性税:多 Agent 编排引入额外的 token 消耗和延迟。简单任务直接使用基座工具可能更高效
  • 平台绑定:OMC 绑定 Claude Code,OmO 绑定 OpenCode。选择任一都意味着一定程度的平台锁定
  • 性能数据缺乏第三方验证:两个项目的效率提升数字(OMC 的 “30-50% token 节省”、OmO 的 “6.7%→68.3% 编辑成功率”)均为自我宣称
  • tmux 依赖:两者的高级功能(团队模式、多模型工作节点)都依赖 tmux,在纯 IDE 集成场景下存在摩擦

结论

OMC 和 OmO 代表了 Agentic Coding 编排层的两条路线。OMC 选择在 Claude 生态内做纵深——用 19 个专业 Agent 和多种执行模式榨取单一模型族的最大价值;OmO 选择横向展开——用分类路由和三层架构将不同模型的认知特长组合成一个协作系统。

两者并非互斥。技术选型的核心考量不在于哪个"更好",而在于:当前的工作流是需要单一模型的深度能力,还是需要多模型的互补组合。对于已经在 Claude Code 生态中的团队,OMC 是阻力最小的增强路径;对于追求模型多样性和自动路由的团队,OmO 提供了更完整的多模型编排方案。


参考来源