OmO 把一条 prompt
拆成一张排班表

先把名词拆干净。OmO 的自我定位是 multi-model agent orchestration harness:一个跑在终端里的编码 agent,但它的中心不是"更强的模型",而是"更细的分工"。

传统编码 agent(Claude Code、Cursor 之类)是一个模型干完所有事:读库、写码、跑测试、写文档,都用同一个脑子。OmO 把这条流水线切开:

• 主 agent 跑你的会话模型,只做编排——探索、拆解、派活、验收、记账。
• 执行单元 是临时拉起的子会话,按"任务类别"分配模型与技能,干完回报,不参与上层决策。
• 只读专家(探索、查文档、计划挑刺、计划审核)永远只读,负责提供判断依据。

用作者自己的话说:"当你不得不把方向盘从 agent 手里夺回来时,那不叫协作,那叫系统失败。"整篇 Ultrawork Manifesto 都在论证一件事——人的介入次数是失败指标,不是安全感的来源。

为什么值得花时间理解:它把"多模型协作"这件事从 demo 变成了可操作的产品形态——模型名出现在配置里,而不是出现在 prompt 里;任务类型决定模型,而不是你自己记得哪个模型擅长什么。这套抽象(类别 / 技能 / 编排 / 记忆)正在被其他 agent 项目陆续抄过去。

同一个项目对外有三种形态,装哪种取决于你原来的习惯。它们的配置文件、可用工具集并不完全一样,别混着看文档。

Native 的安装

一行命令,装原生二进制到 ~/.local/bin,安装脚本会核对 release 校验和;镜像不可达时回退到 GitHub Releases。

# macOS / Linux
curl -fsSL https://get.omo.dev/install.sh | bash
omo

# Windows PowerShell
irm https://get.omo.dev/install.ps1 | iex

# 指定预发布通道或固定版本(注意是 bash 之后的参数)
curl -fsSL https://get.omo.dev/install.sh | bash -s -- beta
curl -fsSL https://get.omo.dev/install.sh | bash -s -- 5.1.1

喜欢包管理器的话 bun add -g omo-ai 或 npm i -g omo-ai 装的是同一个东西。注意 npm 上另有一个叫 omo 的包,和这个项目无关。

第一次运行

• 在项目目录里敲 omo,直接描述任务,没有别的初始化步骤。
• /login 接订阅账号:Claude、ChatGPT、Kimi、GLM 都在里面。没有订阅也可以用 API key 的方式接。
• 从 OpenCode 版或 LazyCodex 迁移过 omo setup:它会先打印一份迁移清单(凭据、MCP、技能、自定义 provider、模型选择),你同意一次才写入;OAuth 登录不会被导入,需要在 omo 里重新 /login。
• omo doctor 体检,omo doctor --models 打印每个类别、每个 agent 此刻会落到哪个模型、回退顺序是什么。

日常操作

OmO 最反直觉的设计是不要你记命令。把某个词写进句子里,模式就开了。匹配是纯正则的(项目里叫 IntentGate),不做语义分类:

匹配规则(踩坑点)

• 大小写不敏感;空格、连字符、无间隔等价:ulw loop = ulw-loop = ulwloop。
• 只匹配完整单词,ulwx 不会触发。
• 行内代码和代码块里的词不算——你可以放心讨论这些关键词本身。
• 关键词可以叠加:mass ulw research 会把研究任务做成工作流。
• 只是提到关键词,等于"问 OmO 要不要进这个模式",不等于强制开启。

理解 OmO 的关键不是它支持多少模型,而是继承关系是单向的:主 agent 派活,worker 不能再派活。这个约束消灭了无限套娃,也让每层的行为可预测。

主 agent

就是你现在打字的会话,跑你的会话模型。它持有计划、todo 列表和证据账本,负责决定"这一步该谁做"。在 /ulw-execute 模式下它有一条硬规则:自己绝不写产品代码——所有实现、测试、QA、评审都必须派生出去。它的手只碰 .omo/ 状态、任务分解、调度和验收。

类别 worker

task(category: "...") 拉起一个全新的子会话,配置由类别决定(模型链 + 技能)。它只拿到一个 prompt,干完回报,不能继续派生。所以同一批里 quick 跑在便宜快模型、ultrabrain 跑在最强推理模型上,互不污染。

四类只读专家

另外还有三个 omo-native-* 评审员(code review、真实场景 QA、最终门禁),它们会写报告文件,所以不算在只读集合里。

Kibitzer:记忆不是向量库,是 git 里的 markdown

每个主会话配一个常驻的只读侧车。它接收会话里的 prompt、工具调用与结果(有长度上限、敏感信息先脱敏),只在遇到"有印象但还没判定过"的记忆时才唤醒模型去看一眼。一次唤醒最多 8 次只读工具调用,同机最多并行 2 个。

它的唯一输出是一条提醒:recalled memory: <hint>。不能写文件、不能改记忆、不会唤醒空闲会话。关掉它的开关是 memory.recall.enabled: false。

这个设计比"自动注入全部历史"克制得多:记忆不占主上下文,代价是提醒可能来得晚。

为什么用"类别"而不是模型名

prompt 里写模型名,等于把模型的自我认知带进任务;写类别,带进去的是意图:

task({ category: "ultrabrain", prompt: "..." })          // 一个真正难的逻辑问题
task({ category: "visual-engineering", prompt: "..." }) // 前端 / UI / 动效
task({ category: "quick", prompt: "..." })              // 机械改动、单文件、样板代码
task({ subagent_type: "explore", prompt: "..." })      // 只读检索

类别到模型的映射写在配置里,所以换模型不碰 prompt,换 prompt 不碰模型。九类内置的语义与默认模型见第 07 节。

路径 A:一个 ulw 直接开工

适合"目标清楚、上下文麻烦"的活。agent 自己探索、自己写实现笔记、自己拆、自己验。它不会在执行中途回头问你"要不要继续",也不会因为某个子任务失败就停工。

复杂度和说服力都在验证环节:每一小步都要有证据(测试、命令输出、界面截图),而不是"我做完了"。

路径 B:/ulw-plan → 批准 → /ulw-execute

适合多天工程、生产改动、需要留下决策痕迹的工作。计划模式最反常识的一点:它很粘。进入之后,"do X""fix X""just do it" 全都被理解成"plan X"。

1. 探索并行派 explore / librarian,必要时拉 architect 与 ultrabrain 做只读设计咨询。
2. 判断要不要访谈你意图清楚就只问真正属于你的决策(不可逆、花钱、破坏性);意图模糊则直接采用最佳实践默认值,并自动打开高精度评审。
3. 起草草稿落在 .omo/drafts/<slug>.md,这是压缩上下文后的续跑点,包含意图、决策、审批门。
4. 你点头批准只授权"写计划",不授权执行。执行是另一条命令。
5. 缺口分析plan-consultant 把主 agent 脑子里的隐含前提逼到纸面上。
6. 评审轮次plan-reviewer 一轮只看一份完整计划,只驳倒有证据的阻塞项;驳回就改完重提,只剩备注则视为通过。
7. 定稿计划落到 .omo/plans/<slug>.md,每条可执行项是零缩进的 - [ ] N. 标题,带引用、验收标准、QA 场景和推荐的执行类别。

执行阶段

命令是 /ulw-execute [plan-name] [--worktree <path>] [--make-pr] [--ship]。发生的事情按顺序是:

• 选计划:读 .omo/boulder.json,有活跃工作就续上;没有就按名字匹配、自动选中唯一一份,或就一个问题问你。
• 登记目标与 todo:每个勾选框一条,全部先建好,而不是走一步加一条。
• 逐项执行:判断轻/重,拆成 worker 粒度,并行的子任务一次性全发出去。
• 五道验收门:重读计划、自动验证、手动 QA 产物、对抗式 QA、清理回执。证据写进 .omo/ulw-execute/ledger.jsonl;worker 说"做完了"不算,要有独立评审员确认才能打勾。
• 收尾:跑计划级最终验证,同步 .omo/ 状态,按需走 PR 流程,打印 ORCHESTRATION COMPLETE。

断了能续

这是它相对多数 agent 的真实差异点。计划执行的状态在外置文件里,不在上下文里:

周一 09:00  /ulw-plan "做用户认证"   → 计划定稿、评审通过
周一 09:40  /ulw-execute           → 建成 boulder 状态,任务 1–2 落地
周一 10:30  会话结束(关机 / 断网 / 崩了)
周一 14:00  /ulw-execute           → "Resuming 'user-auth' - 2 of 8 tasks complete"
                                  → 从任务 3 继续

空闲时它会自己续跑,最多连续 8 次;每轮用户输入也会追加一条"读状态、按计划推进"的提醒。/stop-continuation 一次性关掉这些续跑机制。

对抗版本:/hyperplan

觉得一个规划者不够严,/hyperplan 会组建一支互相攻击的评审队,先把计划互相驳一遍再定稿。产物还是同一份 .omo/plans/*.md。它依赖 team mode 开启。

另一种"持续":/goal

/goal "目标" 给会话挂一个持久目标,每次空闲都重新注入续跑提示,直到 agent 在完成审计后主动标记完成。/goal pause 暂停续跑但保留目标,/goal clear 清除。目标子系统默认关闭,需要在配置里打开 goal.enabled。

mass ulw:有依赖的任务图

当任务之间存在真实的先后关系(任务 C 要等 A、B 完成),关键词 mass ulw 会把工作变成一个 workflow:节点带 id、prompt、category、dependsOn。没有依赖的节点立刻开跑,一条波次跑完解锁下一波。

mass ulw fix every failing test in packages/api, one task per test file 是它文档里的典型例子:一个测试文件一个任务,谁先跑完谁解锁后续。

• 失败节点可以 retry、send(补一句指示)或 amend(改任务),不用重跑已完成的。
• 一次 run 覆盖一个阶段,下一阶段是新 run。
• 桌面端的 Workflows 面板能看到每个任务的状态、依赖图和实时输出。

team mode:成员之间能对话

和 task 派活的区别是成员之间可以互相发消息,共享一份任务列表。默认关闭,要在配置里显式打开:

{
  "team_mode": {
    "enabled": true,
    "max_parallel_members": 4,
    "max_members": 8,
    "tmux_visualization": false
  }
}

打开后多出 12 个 team_* 工具:创建/销毁、成员关机协商、成员间信箱、共享任务列表、状态汇总。tmux_visualization 能给每个成员开一个 pane,实时看它在敲什么(需要跑在 tmux 里)。

边界写得很明确:最多 8 个成员、4 个并发;单条消息 32 KB,单收件人未读 256 KB;每次 run 最多 1 万条消息、120 分钟、每成员 500 轮。不允许嵌套团队,成员也不能再拉团队。team_send_message 是 fire-and-forget,没有同步等待。

主会话模型有三种定法,优先级从高到低:命令行/会话里显式指定 > 配置文件里写死的具体模型 > 按意图选的 profile > 引擎默认。

profile 只写意图,不写型号:

{ "model_profile": "capable" }    // 最强的通用模型,按序取第一个可用的
{ "model_profile": "deep work" }  // 最重的推理
{ "model_profile": "anthropic/claude-opus-5-5" } // 带 / 就是钉死

会话开始时它会逐个走这条链,选第一个你已连上的 provider,并打印一条通知告诉你跳过了哪些档。这个切换只作用于当前会话,不写回 settings.json。

九个类别,一个路由表

型号会随上游更新频繁变动,以上是 2026-10-27 文档里的默认链。以 omo doctor --models 的实时输出为准。

每个类别和每个专家都是一条回退链,按序找第一个你已连上的 provider。所以某些类别在你没接对应模型家族时会显示"不可用",而不是静默换成别的家族——这点比"看起来能用其实降级"要诚实。

覆盖某一格

{
  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/dev/assets/omo.schema.json",
  "categories": {
    "ultrabrain": { "model": "openai/gpt-6-astra", "reasoning": "max" },
    "writing":    { "model": "anthropic/claude-opus-5-5", "reasoning": "low" }
  },
  "agents": {
    "explore":   { "models": ["openai/gpt-6-luna-fast"], "reasoning": "low" },
    "librarian": { "models": ["openai/gpt-6-luna-fast"] }
  }
}

• model 单个,models 是有序回退链;后者是推荐写法。
• 不想让某个模型出现在任何链里,用 exclude_models,比逐个类别删更彻底。
• 配置分两级:~/.omo/omo.jsonc(用户)与项目里的 .omo/omo.jsonc;离得近的那份赢。
• reasoning 统一取 off / minimal / low / medium / high / xhigh / max / auto,旧的 variant、reasoningEffort 是废弃别名。

编排之上的这些能力,决定了它能不能干真活。挑几个对使用影响最大的。

LSP 与结构化编辑

内置 lsp MCP 提供 9 个工具:诊断(编译前就知道错)、符号大纲、跳转定义、全库引用、跨文件重命名、格式化。对"改一个别名"这类任务,引用查询比全文搜索可靠得多。

哈希锚定编辑(默认关)

常见失败是模型复述不出原文那几行,编辑就失败。OmO 的做法是给每行 LINE#ID 哈希,应用前校验,过期就拒。这个能力默认关闭,要显式打开 hashline_edit: true。

AGENTS.md 分层注入

读某个文件时,从该文件目录一路向上到项目根,把沿途的 AGENTS.md 依次注入。项目根写全局约定,子目录写局部约束,不需要手工挂载。

技能带 MCP

技能不只是段落文字,可以捆绑自己的 MCP server,按任务临时挂载。二十个工具不会常驻上下文,只在需要时出现。内置技能包括 debugging、frontend、playwright、git-master、review-work、security-review、visual-qa 等;浏览器相关会按可用的 provider 只激活一个。

Claude Code 兼容层

它能直接读 Claude Code 的配置资产:命令(.claude/commands/)、技能(.claude/skills/)、agent(.claude/agents/)、MCP(.mcp.json、~/.claude.json)、条件规则(.claude/rules/)。迁移成本因此很低,也能逐项关掉:

{ "claude_code": { "mcp": false, "hooks": false, "plugins": false } }

非交互运行

omo run "<message>" 跑一次性会话,退出条件很严:主会话空闲、所有 todo 完成或取消、所有派生会话空闲、没有续跑挂起。--json 出结构化结果,--on-complete 接后续命令,适合进 CI 或脚本。

遥测与隐私

默认开启匿名遥测(PostHog,设备标识做 SHA-256 哈希)。关掉:OMO_SEND_ANONYMOUS_TELEMETRY=0 或 OMO_DISABLE_POSTHOG=1,插件配置里也可以写 "telemetry": false。会话内 /bug 提交报告前可以完整预览:环境、脱敏后的配置、会话记录、设备名、安装 ID 都会列出来给你看。

会话内

终端

omo-agent-toolkit 是发布包里的短名 bin;oh-my-openagent 与 oh-my-opencode 是同一份 CLI 的两个名字。

这个项目在 GitHub 上热度极高(7 万星),README 的措辞也很有煽动力。以下是我按文档与代码结构做出的判断,不是转述。

适合谁

• 已经在用两个以上模型订阅,想让它们各干各擅长的事。
• 经常处理"半天说不清上下文"的中大型改造,愿意先花 10 分钟换计划。
• 在意可审计性:每个勾都有人验、有证据、断了能续。

不适合谁

• 只想改一行配置、跑个脚本——一个更强的单模型 agent 更省事。
• 环境不允许遥测、或需要 OSI 许可才能在公司内部推广。
• 团队没有统一订阅,很多类别会长期显示不可用。

试用的最小路径

1. 装 Native 版:curl -fsSL https://get.omo.dev/install.sh | bash。
2. omo 进入,/login 接你已有的订阅。
3. omo doctor --models 看一眼哪些类别真的可用——这一步能提前暴露"模型没接上"的问题。
4. 挑一个真实的中等任务,直接打 ulw,不要先上 plan 流程。
5. 觉得验证不够,再试 /ulw-plan → /ulw-execute;觉得任务量大但独立,再用 mass ulw。

• 仓库主页 · 官网 · 在线文档
• What Is Oh My OpenAgent? —— 产品定位与 profile
• Keywords —— 关键词与匹配规则
• Orchestration System Guide —— 计划、执行、boulder 状态
• Features Reference —— 类别、工具、技能、钩子全表
• Team Mode · CLI Reference
• Ultrawork Manifesto —— 作者的设计立场

本文基于 2026-10-27 的 dev 分支文档与 v5.1.48 发布版本整理;型号、默认链与命令会随版本变化,以仓库文档与 omo doctor 输出为准。