- 写在前面
- [omo 到底是什么](#omo 到底是什么)
- [为什么说它的核心不是 Agent 数量，而是编排层](#为什么说它的核心不是 Agent 数量，而是编排层)
- [它是怎么把一个普通对话框改造成多 Agent 系统的](#它是怎么把一个普通对话框改造成多 Agent 系统的)
- [11 个 Agent 背后，其实是一套明确分层](#11 个 Agent 背后，其实是一套明确分层)
- 真正让我觉得它做得很深的是这四个机制
- [为什么 ULW 机制让它和普通 Agent 工具拉开差距](#为什么 ULW 机制让它和普通 Agent 工具拉开差距)
- 我对这个系统的总体判断
- 总结
写在前面
最新Open Code 以及他的增强插件 oh-my-openagent 相继爆火
我把 oh-my-openagent 这套东西完整捋了一遍，原本以为这只是一个运行在 OpenCode 上的增强插件，结果越往下看越发现，它的重点根本不在"多装了几个工具"或者"多配了几个 Prompt"，而是在把一个原本偏单线程的 AI 编程入口，改造成一套能自动拆任务、自动选模型、自动续跑、自动调子 Agent 的多 Agent 编排系统。
这件事表面上看很像"给 OpenCode 套了一层壳"，但实际上不是。因为它动的不是界面层，也不是简单命令层，而是整条任务执行链：从用户发出消息开始，到上下文注入、任务分类、模型路由、后台 Agent 并行执行、工具调用前后拦截、session 空闲时自动续跑，几乎每一个关键节点都被接管了。
如果只用一句话来概括 omo，我会这样说：
omo不是在 OpenCode 里塞进几个 Agent，而是在 OpenCode 上搭出了一套可持续运转的多 Agent 编排框架。
omo 到底是什么
omo 运行在 OpenCode 之上，定位是一个 plugin。但如果只停留在 plugin 这个描述上，其实会低估它。
它做的事情不是简单扩展几个按钮，而是把 OpenCode 这个原本更接近"单一 AI 对话入口"的环境，扩展成一套带有如下能力的系统：
- 多 Agent 并行协作
- 分类驱动的模型路由
- 生命周期 Hook 拦截
- Skills 与 MCP 的按需加载
- 会在空闲时自动继续干活的持久执行机制
整个插件规模已经达到 1,268 个 TypeScript 文件、约 16 万行代码，内部包括 11 个专业 Agent、46 个生命周期 Hook、26 个工具和 3 个内置 MCP。单看这些数字就知道，它关注的已经不是"功能增强"，而是"系统级调度"。
所以更准确的理解不是"它是一个有很多功能的插件"，而是：它把 OpenCode 变成了一个以 Sisyphus 为主编排器、围绕不同角色 Agent 进行协作的软件开发系统。
为什么说它的核心是编排层
很多人第一次看到这种系统，最容易被"11 个 Agent""多模型""后台并行"这些点吸引。但如果只盯着 Agent 数量，其实抓不到重点。因为单纯有很多 Agent，并不等于真的形成了协作系统。
真正关键的是下面几个问题：谁决定什么时候该用哪个 Agent，谁决定任务要不要拆分，谁决定这个任务应该用哪个模型，谁决定做完一轮之后要不要继续，谁来回收子任务结果并推进下一轮执行。omo 的核心价值，恰恰就在这里。
它不是把多个 Agent 平铺摆在那里等用户手动叫，而是通过 Sisyphus + Hook + Category + Boulder 形成一条自动编排链。这意味着它真正解决的问题，不是"如何拥有多个能力"，而是"如何把多个能力组织成一个能持续工作的系统"。
它是怎么把一个普通对话框改造成多 Agent 系统的
顺着一条用户消息往下走来带你理解OMO。
当用户发出一条请求后，系统大致会经历这样一条链路：
第一层：chat.message 阶段
消息刚提交，AI 还没正式处理之前，一批 Hook 就已经开始工作了。这里会做很多早期判断，比如检测有没有 ultrawork、search、analyze 这类关键词，判断是否需要激活更深的思考模式，识别 slash command，注入目录下的 README、AGENTS 之类的上下文信息。
这一步的本质，是在用户"刚发话"的那一刻，就给后面的模型执行准备好轨道。
第一层：messages.transform 阶段
在消息真正发给模型 API 之前，系统还会做最后一轮处理，比如注入必要上下文、验证 thinking block、清理空消息、监控 context window。这说明 omo 并不满足于"把原始消息直接丢给模型"，而是把提示构造本身也纳入了运行时控制。
第三层：进入 Sisyphus 编排器
消息经过前面的预处理之后，才进入主编排器 Sisyphus。这里最关键的动作，是 Intent Gate。
也就是说，Sisyphus 不会只按字面执行任务，而会先判断：这是研究型问题吗，这是新功能实现吗，这是 Bug 调查吗，还是快速小改动吗。不同判断会进入完全不同的执行路径。比如研究型任务会优先路由给 Librarian 和 Explore，复杂实现会走规划加并行子任务，Bug 调查会触发 Oracle 只读诊断，小任务则直接走 quick category。
第四层：并行后台 Agent 与执行分身
当任务需要拆分时，Sisyphus 会通过 task() 启动后台 Agent。这里最典型的搭配是：Explore 去扫描代码库，Librarian 去查外部文档和 GitHub 实现，Oracle 负责复杂问题的只读推理分析，Sisyphus-Junior 负责具体执行。
这里有个非常关键的限制：Sisyphus-Junior 在代码层面被限制为不能继续委托。这个设计很重要，因为它防止了无限递归拆任务。
第五层：session.idle 之后继续工作
大多数 Agent 系统走到这一步就结束了，但 omo 不是。如果 session 进入 idle，而 TODO 还没有完成，todo-continuation-enforcer 会自动注入新的提示，驱动系统继续往下跑。这就是 Boulder 机制最核心的地方。
11 个 Agent 背后，其实是一套明确分层
omo 一共拉出了 11 个 Agent，但更值得关注的不是数量，而是它们被组织成了清晰的层次。
编排层
Sisyphus：主编排器，所有用户任务的入口Hephaestus：自主深度工作者，适合长时间无人值守的端到端任务
这一层负责的是"谁统筹这件事"。
规划层
Prometheus：规划Metis：找缺口Momus：审阅计划
这一层负责的是"在动手之前，把事情想清楚"。
专家层
Oracle：只读架构顾问Librarian：查文档与外部实现Explore：快速代码库搜索Multimodal Looker：看图片、PDF、截图Atlas：计划执行与任务分发
这一层负责的是"提供不同维度的专业能力"。
执行层
Sisyphus-JuniorFrontend Engineer
这一层负责的是"真正落地改代码、做实现"。
这套结构说明一件事：omo 不是让每个 Agent 都干差不多的事，而是把不同角色的职责拆得很明确。这样主编排器才不会被迫既当分析师、又当规划师、又当执行器。
真正让我觉得它做得很深的是这四个机制
1. Hook 把自动化插进了整个生命周期
如果没有 Hook，很多系统只能靠用户主动触发命令。但 omo 把自动化能力植入到了消息、工具、session 等多个生命周期点里，这让它能在用户不额外干预的情况下维持系统秩序。
2. Category 把模型选择从 Prompt 里抽离出来
这是一个非常工程化、但又非常关键的设计。很多多模型系统的 prompt 一旦写死模型名，后面迁移 provider 会非常痛苦。omo 用 Category 做了一个稳定中间层，这个抽象非常值钱。
3. Skill + MCP 不是全局常驻，而是按需进入
这里有一点很关键：Skill 内嵌的 MCP 不是一直挂着，而是按需启动、任务结束销毁。这带来的直接收益是运行时资源更省、上下文更干净、工具描述不会长期污染当前任务。这说明 omo 对"上下文也是资源"这件事有非常明确的意识。
4. Boulder 让它具备持续推进能力
很多 Agent 工具的问题不是第一次输出不够强，而是不会在"输出之后"继续干活。而 omo 通过 .sisyphus/boulder.json 这套持久化状态和 session.idle 检查逻辑，把"继续推进未完成工作"做成了系统能力。
这意味着它更接近一个持续工作的执行体，而不是一次性应答器。
为什么 ULW 机制让它和普通 Agent 工具拉开差距
我最有感的一部分，其实不是多模型，也不是 Agent 数量，而是 ULW 。因为这套机制抓住了一个很现实的问题：真正复杂的软件任务，不会在一轮响应里彻底结束。
正常情况下，一个任务会经历一轮实现、一轮验证、一轮修复、一轮补测试和一轮收尾。如果系统只在你发消息时工作，那用户就得不断盯着它。而 ULW 机制把"继续推进未完成任务"变成了默认行为。
它的逻辑并不复杂：TODO 未完成，session 进入 idle，Hook 检测到还有 pendingTodos，于是注入继续工作的提示；如果连续失败过多，再指数退避后重试。这个机制的意义非常大，因为它让 Agent 从"等人催一下干一下"，变成了"只要任务没完，我会继续推进"。
我对这个系统的总体判断
如果只看表层，omo 可以被描述成一个 OpenCode 插件、一个多 Agent 工具集、一个带很多 Hook 和 Skill 的增强层。这些描述都不算错，但都不够准确。
我更认同的表述是：omo 是一个建立在 OpenCode 之上的多 Agent 编排系统，它把消息生命周期、模型路由、知识装配、外部能力接入和任务持续执行整合成了一条自动化流水线。
它最强的地方不在某一个单点，而在于这些机制被拼成了完整闭环：用 Hook 接管生命周期，用 Sisyphus 做意图分析与总编排，用 Category 解耦任务类型和模型，用 Skill 组织专业知识与工作流，用 MCP 按需接外部能力，用 Boulder 保证任务不会半路停掉。
很多 AI 工具会让你感觉"它功能很多"，而 omo 给我的感觉是"它真的在认真做系统"。
总结
把 omo 整套机制看完之后，我最大的感受是：它不是试图把一个模型变得更聪明，而是在努力把一组模型和机制组织得更像一个开发团队。
它最值得看的，是它已经不再把 AI 编程理解成"一次对话换一次回答"，而是在往"持续执行的多 Agent 编排系统"这个方向认真走。