夜雨聆风
Claude Code 不够用?这个插件给它装上 30 个专家
公众号：AIGC 生活实验室简介：探索 AI 如何改变工作与生活作者：皮皮鲁呀鲁西西
GitHub 上有个项目，创建不到两个月，Star 冲到 7000+，迭代 171 版，40 位贡献者持续提交代码。
它叫 oh-my-claudecode。
翻了一圈文档和社区讨论，发现一个有意思的定位：官方口号不是 a tool，而是 a weapon。一个把 Claude Code 从单兵作战变成多兵团协同的开源插件，MIT 许可证，谁都能用。今天从使用教程的角度，把它拆开看看。
它到底是什么
一句话说清楚：oh-my-claudecode（下面简称 OMC）是一个 Claude Code 的多智能体编排插件，通过协调 Claude、Gemini、Codex 三个 AI 模型，把原本需要你手动切换工具的工作流变成自动化流水线。
这里面有几个关键数字值得注意：
架构上，Claude 扮演指挥家的角色，负责任务分解和结果综合。Gemini CLI Worker 利用 100 万 token 的上下文窗口处理大文件分析和 UI/UX 审查。Codex CLI Worker 专攻架构审查和安全分析。三个模型各司其职，通过 tmux 窗格协调工作。
说实话，第一次看到这个架构的时候有点意外。大多数 AI 编程工具还在卷单模型能力，OMC 直接把三家的模型拉到一起干活了。
安装：真的只要 2 行命令
OMC 的安装过程可能是我见过的开发工具里门槛最低的之一。不需要配置文件，不需要环境变量，两步搞定：
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode/plugin install oh-my-claudecode/omc-setup
跑完 /omc-setup 之后，所有 Agent、Skill、MCP 工具就自动就位了。不需要手动配置模型 API Key（用的是你已有的 Claude Code 订阅），不需要指定 Agent 路由规则（系统自动判断）。
系统要求也很简单：
如果只装 Claude Code，OMC 的核心功能照样能跑。Gemini 和 Codex 是锦上添花，不是硬性依赖。三个 Pro 计划全开的话，月成本大约 60 美元。
8 种执行模式：选对模式是关键
OMC 的核心竞争力不在于 Agent 数量多，而在于它把不同的工作场景抽象成了 8 种执行模式。每种模式背后是一套完整的 Agent 调度策略。
Autopilot 模式：全自动，从想法到代码
适合场景：需求明确、不需要中间确认的任务。
autopilot: build a todo app with React and TypeScript
系统会自动完成需求分析、架构设计、代码编写、测试验证的全流程。整个过程不需要人工干预。
Ralph 模式：持久执行，不完成不停
适合场景：大型重构、复杂 bug 修复。
ralph: refactor the entire auth module
Ralph 模式的特点是自引用循环加架构师验证。它会持续工作，遇到问题自动调整方案，直到任务通过验证才停下来。一位量化研究员在社区里的评价很直接：如果 Claude Code 在 7 天内完成人类 3 个月的工作量，OMC 的 Ralph 模式只需要 1 小时。它会一直工作直到任务完成。
Ultrawork 模式：并行到极致
适合场景：多个独立任务需要同时推进。
ulw fix all TypeScript errors across the project
Ultrawork 会把任务拆成多个子任务，分发给不同的 Agent 并行处理。官方说法是比顺序执行快 3-5 倍。
Team 模式：原生团队协作
这是 v4.1.7 之后的规范模式，直接利用 Claude Code 原生的 Agent Teams 功能。
/team 3:executor “fix all TypeScript errors”
分阶段管道：team-plan → team-prd → team-exec → team-verify → team-fix，每个阶段有明确的输入输出。需要开启实验性标志：
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
其他 4 种模式速览
Ultrapilot — 并行 autopilot，带文件所有权追踪，防止冲突
Swarm — 触发词 swarm，N 个 Agent 共享任务列表，协作执行
Pipeline — 顺序链式，Agent 之间数据传递，适合流水线任务
Planning — 触发词 plan，基于访谈的规划工作流，先收集需求再动手
选模式有个简单的判断逻辑：任务明确且独立，用 Autopilot；任务复杂且需要持续迭代，用 Ralph；多个任务并行，用 Ultrawork 或 Ultrapilot；需要团队协作，用 Team。
Magic Keywords：说人话就能驱动
OMC 的交互设计有个值得说的点：你不需要记住任何命令。
系统通过自然语言意图检测来路由请求。说 fast 就激活并行模式，说 don’t stop 就进入持久执行。这套 Magic Keywords 系统覆盖了所有核心操作：
|
|
|
|---|---|
| autopilot |
|
| ralph |
|
| ulw |
|
| team |
|
| plan |
|
| ccg |
|
| swarm |
|
/ccg 是个特别有意思的命令。它会同时启动 Codex 和 Gemini 两个 Worker，分别处理代码分析和设计审查，然后由 Claude 综合两者的结果。相当于一个命令调动三个模型的能力。
30 个 Agent 怎么分工
光说数字没感觉，拆开看看这 30 个 Agent 的分工逻辑。OMC 把它们分成了 4 个通道：
构建与分析通道：explore、analyst、planner、architect、debugger、executor、deep-executor、verifier。从探索代码库到执行任务再到验证结果，覆盖了开发的主链路。
审查通道：quality-reviewer、security-reviewer、code-reviewer。三个审查 Agent 分别从质量、安全、代码规范三个维度把关。sonim1.com 的一位博主实测后提到：OMC 的 /security-review 在 PR 前能捕获你可能遗漏的安全问题。
领域专家：document-specialist、test-engineer、build-fixer、designer、writer、qa-tester、scientist、git-master。每个 Agent 专注一个领域，比如 test-engineer 专门写测试，git-master 专门处理版本控制。
协调层：critic agent 负责计划挑战和批判性审查，防止其他 Agent 的方案有盲点。
这里面有个设计细节值得注意：OMC 的智能模型路由会根据任务复杂度自动选择模型。简单任务用 Haiku（轻量快速），复杂推理用 Opus（重量级）。这个策略据官方数据能节省 30-50% 的 token 消耗。同一位 sonim1.com 博主也确认了这一点：Agent 级别的模型路由是 OMC 的隐藏优势。
真实用户怎么说
整理了一圈社区反馈，评价两极分化挺明显的。
正面的声音很猛。有人说用 OMC 的姊妹项目 Oh My Opencode 一天内解决了 8000 个 eslint 警告（来源：Jacob Ferrari）。还有人说用 Ralph 模式一夜之间把一个 45000 行的 Tauri 应用转换成了 SaaS Web 应用（来源：James Hargis）。Medium 上的 Joe Njenga 给了个很形象的类比：It’s like oh-my-zsh for your terminal – 就像 oh-my-zsh 之于终端一样，OMC 之于 Claude Code。
但负面反馈也不少。sonim1.com 的博主直接指出了一个核心问题：OMC 提供 32 个 Agent、40 个 Skill 和 5 种执行模式，文档量巨大，很难知道什么时候该用什么。实际日常使用中，只有少数几个功能被频繁使用。
还有成本问题。Reddit 上有用户反馈 Opus 4.6 模型升级后 token 消耗暴增，多模型协作需要额外安装 Gemini CLI 和 Codex CLI，环境配置的复杂度也上来了。
坦白讲，这些反馈很真实。功能多和好用之间确实有距离。但换个角度看，OMC 的 Magic Keywords 系统就是在解决这个问题 – 你不需要知道 30 个 Agent 分别叫什么，说句话让系统自己路由就行。
从 OMC 学到的：打造个人工作流的 5 个思路
抛开 OMC 本身不谈，它的架构设计里有几个思路对任何想打造个人 AI 工作流的开发者都有参考价值。
思路 1：Agent 专业化分工
不要让一个通用 Agent 处理所有事情。OMC 把代码审查拆成了质量、安全、规范三个独立 Agent，每个 Agent 有自己的 prompt 和评判标准。这比一个 Agent 同时关注三个维度的效果好得多。你在自己的工作流里也可以这么做 – 把代码生成、测试编写、文档更新拆成不同的 Agent 或 prompt 模板。
思路 2：模型分层策略
不是所有任务都需要用最贵的模型。OMC 的做法是简单任务用 Haiku，复杂推理用 Opus，大上下文分析交给 Gemini。这个分层逻辑直接影响成本。如果你在用 API 调用，完全可以参考这个策略：格式化、简单补全用轻量模型，架构设计、复杂 debug 用重量模型。
思路 3：执行模式多样化
不同类型的任务需要不同的执行策略。写一个小功能和重构整个模块，需要的 Agent 数量、并行度、验证逻辑完全不同。OMC 用 8 种模式覆盖了这些场景。你不需要 8 种，但至少应该区分快速修复和深度重构两种模式。
思路 4：MCP 工具扩展能力边界
OMC 内置的 LSP 集成让 Agent 能获取类型信息和跳转定义，AST Grep 让 Agent 能做结构化代码搜索。这些不是 LLM 原生能力，而是通过 MCP 协议接入的外部工具。Claude Code 本身就支持 7 层可扩展性（CLAUDE.md、Commands、Hooks、Skills、Sub-agents、Plugins、MCP），OMC 只是把这些层用到了极致。
思路 5：持久化与经验学习
OMC 的 State & Memory 工具支持跨会话保持状态，从经验中提取可复用的问题解决模式。这个思路很关键 – 如果你的 AI 工作流每次都从零开始，效率永远上不去。把常见问题的解决方案、项目的架构决策、编码规范沉淀下来，让 Agent 能复用历史经验。
开源生态与跨平台价值
OMC 是 MIT 许可证，代码完全开放。GitHub 上 7086 Star、499 Fork、40 位贡献者，社区活跃度不低。
有意思的是，OMC 的架构设计已经被移植到了其他平台。姊妹项目 oh-my-codex 为 OpenAI Codex CLI 提供了相同的编排体验。V2EX 上也有开发者分享了将 OMC 核心设计移植到其他工具的经验。这种跨平台的可移植性，反过来验证了它的架构设计具有通用性。
项目主要用 TypeScript（68.5%）和 JavaScript（28.3%）编写，对前端开发者来说阅读源码的门槛不高。如果你对多 Agent 编排感兴趣，OMC 的源码本身就是一份不错的学习材料。
写在最后
说到底，oh-my-claudecode 做的事情是把多智能体编排从需要自己搭架构变成了装个插件就能用。30 个 Agent、8 种执行模式、三模型协作，这些能力对个人开发者来说确实有吸引力。
如果你已经在用 Claude Code，花 5 分钟装上试试，成本几乎为零。如果你对多 Agent 编排的架构设计感兴趣，它的开源代码值得读一读。
如果这篇文章帮到了你，点个在看👀吧，下次再见
AIGC 生活实验室
📮 投稿/合作：egretss.bai.it@gmail.com💬 交流群：回复加群✍️ 作者：皮皮鲁呀鲁西西🚀 关注我，一起探索技术的更多可能
