https://.com/-Heo/oh-my-）

为什么需要 OMC？ Code 自己不够用吗？

称得上是好的问题。这款Code自身确实具备很强的能力，然而当你切实以它去从事重大任务的时候，会遭遇几个能令人抓狂不已、让人烦躁到极点的问题：

痛点一：单线程执行的时候效率低下。Code从本质上来说是一个Agent，一次仅仅能够专注于做一件事情。要是你的项目存在有几十个文件需要修改、有上百个测试需要运行，它只可以一个一个地去处理，效率实在是让人觉得无奈。

痛点二：欠缺整体的视野空间，它仅仅关注当下眼前的那几行代码内容，很不容易同时去考量架构、安全、性能以及可维护性这般多个维度情况，修改完成一个 Bug 之后，极有可能在其他的角落引发引爆三个全新的 Bug 问题。

痛点之三为中途放弃，AI编程之中，最令人崩溃的并非是写得不好，而是写到一半就停了，速率限制触发、上下文溢出以及意外中断等情况发生后，你必须手动重新启动，犹如在玩一款永远存不成档的游戏。

痛点之四为，成本并非清晰明了codejock software，每一回皆是运用价格最为高昂的模型去运行全部任务，就连简单的文件查找操作也要使用 Opus，钱包仿佛在不断滴血，心疼不已。

OMC 是为解决这些问题才产生的，它并非是在 Code 之上增添几个华而不实的功能，而是对整个工作流进行了重新设计。

核心亮点在于，有五个能让处于特定圈子里的人，大声喊出「卧槽」的功能，其中一个是，Team模式，它可模拟真实的开发团队。

这是 OMC 最推荐的编排方式，也是目前最核心的功能。

设想一个真切的软件开发进程，先是产品经理撰写需求，接着架构师开展设计方案，随后开发者进行代码实现，再之后测试工程师予以验证，一旦发现问题便打回要求修复。OMC的Team模式将该进程移至AI领域当中：

团队规划转变为团队需求文档，团队需求文档进而过渡到团队执行阶段，团队执行之后进入团队验证环节，团队验证后要是有问题就进行团队修复，如此循环一直到通过。

你只需要一句话就能启动：

也就是说这句话所表达的意思是，开启 Team 模式，派遣 3 个身为执行者的 Agent 去将所有错误修复，它能够自动对任务进行拆解，分配给不同的 Agent，使其并行执行，之后汇总结果，并且验证修复。

更为厉害的是，自v4.4.0起始，OMC居然还支持跨模型去协作，要知道并非一个AI的事，而是能同时对三个不同的AI的CLI工具进行调度，这三个AI分别为Codex（）、（） ，是不是很令人惊叹呢？

让每一个 AI 去做其最为擅长之事：Codex 进行架构审查，做 UI 设计（它具备 100 万 token 的上下文窗口，能够一次性将整个项目完整查看），实施综合决策。这恰似在一个技术团队当中，架构师、设计师以及全栈工程师各尽其责。

2.Ralph 模式——不达目的誓不罢休的「永动机」

要是你曾有过使用AI编程工具的经历，那么大概率遭遇过这般绝望的情况：让AI对一个模块进行重构，然而它在改了一半之后就向你表示「我已然竭尽全力了」，最终留下了一堆处于半成品状态的东西。

Ralph 模式就是为了解决这个痛点。它的逻辑很简单：

先是执行，接着进行验证，然而出现失败的情况，然后开展修复，之后再次进行验证，如此反复codejock software，一直到通过才停止。

这可不是那种轻而易举的重试行为，它能够自行剖析失败缘由所在，进行具有针对性的修复操作，之后再次予以验证，整个流程处于循环封闭状态，并不需要你亲自参与其中进行人工干预，你能够使它通宵开展一项繁杂程度较高的数据库迁移任务，等到第二天早晨起床查看结局便可以了。

3.智能模型路由——帮你省钱

OMC 内部设置了一整套模型路由策略，它会依据任务的复杂程度，自动挑选出恰当的模型，用来做决策：

依据官方给出的数据，这套策略能够节省百分之三十到百分之五十的Token成本，简单的任务采用便宜且快速的模型，只有在碰到真正需要深度思考的问题时，才会动用“大杀器”.就如同公司里面不会让首席执行官去打印文件那样。

4.技能学习系统——AI 版的「经验笔记」

这是 OMC 最被低估的功能之一。

倘若你正处于调试一个出现了代理崩溃情况的问题之中，历经两个小时的反复折腾以后最终寻觅到了解决办法（即在 .py:42 的位置添加一个 try/） . 而后 OMC 会自动将这个经验提取出来，进而保存成为一个「技能文件」：

再下次你一旦碰到相似的问题，只要输入之中含有“proxy”或者“”等这样的关键词，OMC便会自动将这个技能注入到上下文里。这就如同你调试过的每一个坑，它都帮自己记住了。

这些技能文件存在两级管理方式，项目级（.omc//），能够随着代码仓库版本进行控制，实现团队共享，用户级（~/.omc//），在所有项目中均会生效。学习一回，便可终身受益。

5.魔法关键词——说话就能干活

OMC 令最易使人上瘾之处有可能是在其具备的自然语言接口，你无需去记任何命令，仅需直接讲人话便可。

甚至哪怕你说出「fast」这个词，它便能够知晓需要去激活并行模式，你若说出「don't stop」，它就会明白要进入持久化模式，每个意图均映射至正确的执行策略。

上手有多简单？三步搞定

如果你已经有 Code 环境，安装 OMC 只需要三步：

第一步：安装

在 Code中运行：

或者用 npm 全局安装：

第二步：初始化

第三步：开干

事情就是如此这般，并不需要那种繁杂的配置文件，并不需要去学习全新的 DSL，并不需要去研读好几百页的文档。安装完毕后就能够投入使用，这极有可能是最为具有杀手级特性的产品设计，也就是所谓的零学习曲线。

32 个专业 Agent 都在干什么？

OMC 的 32 个 Agent 按职能分成三大阵营：

其中几个特别值得一提：

在实际的运用情形场景里，于什么时刻运用OMC 会是最为畅快的呢？存在场景一，即从一端起始直达另一端结束的功能进行相应的研制与开发。

讲一句：构建一个任务应用程序，操作维护控制台会不由自主地完成从需求澄清到架构设计，再到代码实现，接着到测试生成，最后到文档编写这么一个完整流程。你只需在最后对产出物做一下检查。

场景二：大规模代码重构

面对项目代码量增大的情况，打算从 REST 迁移至？采用 模式：将所有 API 予以运用。它能够自动实施文件拆分，并行开展修改操作，运行测试，并且自动进行提交。

场景三：PR 审查（三模型交叉验证）

将此PR交由Codex审查后端架构，交由另一处审查UI组件，最终由其综合两方意见给出结论。三双各异的眼睛审视同一个PR，相较于任何单一模型而言更为可靠。

场景四：通宵跑任务

数据库迁移这一耗时任务，交给 Ralph 模式，大规模测试这一费时任务，交给 Ralph 模式，批量重构这一耗力任务，交给 Ralph 模式。它会自动处理速率限制，限定时若被检测出则暂停，后重置便自动恢复，全程无需人工进行看护。第二天早上抵达后，结果已在你桌上呈现了。

背后的趋势：编排层才是 AI 工具的未来

OMC 最有意思的其实不是技术本身，而是它代表的方向。

它的官网之上写有一句话，那句话是：「A , not a tool.」（是武器，并非工具）此句话听闻起来略微带有些中二之感，然而仔细去思索一番，它的确点明了一个关键之区别，这个区别是，工具乃是你拿过来用以使用的，武器则是能够改变战场格局的。

站在一个更为宏观的角度去瞧，整个那人工智能编程的生态环境正处于经历一场范式转移的进程之中：

第一层，是模型层，GPT - 4等，这些属于大模型本身，其地位等同于「大脑」。

第二层是工具层，Code等的这些存在属于AI编程工具，其作用等同于「双手」。

第三层是编排层，当中的OMC、CLI - 属于多Agent编排系统，这具备着「指挥中枢」的作用。

以往众人竞争侧重点处于第二层，即究竟是谁的代码编写得优良，以及谁所具备的上下文更为冗长。然而当下，数量日益增多的创新正于第三层涌现。编排层并不关注模型究竟究竟才智几何，它所关注的是，如何促使多个模型协同运作，达成一加一大于二的效果。

OMC 的官网上还有另一句值得品味的话：

你提供的内容似乎不完整且混乱，不太能明确确切需求，请补充完整清晰的句子以便我准确改写。

（今天的软件服务于人类。明天的用户将是 Agent。）

这番话语，开始的时候，出自香港大学的 CLI - 项目，然而，它对于 OMC 的愿景，同样是适用的。在 AI Agent 变得越发具备能力之际，真正关键的，或许并非教导人类如何运用 AI，反而是教导 AI 怎样富有效率地管理 AI。

适合谁？不适合谁？

写在最后

回顾一下 OMC 给我们带来的几个关键信号：

要是你身为一名开发者，并且已然在使用Code，那么OMC值得你耗费两分钟去安装一下尝试一番。要是你尚未使用过Code，那么OMC或许便是那个能让你下定决心投身其中的缘由。

毕竟，有谁会不想去拥有一支 AI 开发军团呢，（本文首发钛媒体 APP，作者是硅谷，编辑为焦燕）。

如有侵权请联系删除！