Oh-My-Pi(OMP)完整上手:32 个内置工具 + 多模型路由 + 4 套 Agent 工作流实测
最近在终端里跑 Agentic Coding 任务,几乎被一个反直觉的事实反复教育:AI 写不好代码,往往不是大模型不够聪明,而是外围的 Harness 太脆弱。把这条理念做成产品的,除了已经讲过的 Pi Agent 零基础入门 和 Pi Agent 必装 8 个插件,还有今天的主角——Oh-My-Pi(下文简称 OMP)。
OMP 是 Pi Agent 爱好者把整个代码 fork 之后,在其上做的「开箱即用」发行版。它和 Pi Agent 共享一套内核,但开箱就从 4 个工具直接扩到 32 个,把 LSP、DAP 调试、多智能体协作、模型路由、Advisor 监工等 IDE 级能力一次性塞进同一个 binary。下面把这几天的实测整理出来,按「设计理念 → 安装 → 模型路由 → 关键设置 → 上下文文件 → 工作流 → 实战演示 → 生态复用」的顺序,把 OMP 用透。
一、为什么需要 OMP:从 Pi Agent 到 Harness Problem
Pi Agent 的设计哲学是「少即是多」——初次打开只有文件读、文件写、文件编辑、Bash 执行四件套,够轻、够克制,几乎是最小化的 Harness。对追求极致自定义的硬核用户来说,这是梦寐以求的起点;但对希望「装上就能干活」的开发者来说,这套极简几乎等同于「无从下手」。
OMP 的作者属于后者。他在 fork 后的项目里明确提出一个新视角——Harness Problem:
AI 写不好代码,很多时候不是大模型不够聪明,而是外围的 Harness 太脆弱。
换句话说,真正决定一个 Agent 能不能跑通生产链路的是工具链、上下文管理、权限控制、模型调度、协作机制这套「外骨骼」,不是模型本身。基于这个判断,OMP 把 Pi Agent 当作内核,在外面套了一整套 IDE 级别的工程能力,让你不必再自己造轮子。
具体而言,OMP 在三件事上比 Pi Agent 走得更远:
| 维度 | Pi Agent | OMP |
|---|---|---|
| 内置工具 | 4 个 | 32 个(含 LSP、DAP、多 Agent 等) |
| 工作流 | 靠插件 / 命令自己拼 | 4 套内置工作流:/plan /go /vibe /prework |
| 模型调度 | 单模型 + 手动切换 | 60+ 供应商 + 角色路由(tiny / small / slow / chat / image / embedding / search) |
| 协作 | 靠插件 | 原生多智能体 + Advisor 监工(三级风险拦截) |
| 生态 | 自有 catalog | 完全复用 Pi Agent 生态 |
这些能力不是堆砌出来的噱头,而是 OMP 想做的核心定位——一个完整的、由 Agent 驱动的 IDE 平台。
二、OMP 与主流 Harness 工具的差别
在实测之前,先把它和市面上几个常被拿来对比的选手摆清楚——Codex 的半年更新、Claude Code、Cursor。
先说 Pi Agent——它们一棵树内核一脉相承,Pi Agent 的扩展包、配置体系、上下文文件,OMP 几乎都能直接用。差别不在能力,在使用习惯和场景:
- Pi Agent = 给你四件工具,你自己组装。
- OMP = 帮你组装好,开箱即用。
可以把 OMP 理解成 Pi Agent 的全副武装版——同样的内核,但 IDE 该有的能力都内置了。
再说 Claude Code / Codex / Cursor——它们都是非常优秀的 Harness,但深度绑定了自家的模型或生态。OMP 走的是相反的路线:
| 能力 | Claude Code / Codex / Cursor | OMP |
|---|---|---|
| 模型供应商 | 深度绑定自家 | 集成 60+ Provider,不锁定任何一家 |
| 角色路由 | 主要靠单模型 + 手动切换 | 按角色自动路由(规划用强模型,执行用便宜模型) |
| IDE 能力 | 通过插件或外部 IDE | 把 IDE 能力搬进内核——LSP 跨文件联动、DAP 原生 debug |
| 工具链 | 部分需要子进程 / WSL | search、share 等编进同一个 binary,Windows 不走 WSL |
| 多智能体 | 受限 | 原生支持,主 Agent 实时可见、可打断 |
| 迁移成本 | — | 几乎零:已有的 AGENTS.md、CLAUDE.md、CURSOR_RULES 都能直接读 |
最后一个迁移成本对存量项目尤其重要——你项目里早就写好的上下文文件,OMP 直接读,不需要搬家。
三、安装与配置目录结构
OMP 的安装方式覆盖全平台,在 macOS 上最快是 Homebrew:
1 | brew install oh-my-pi |
如果你已经装过,升级一条命令搞定:
1 | brew upgrade oh-my-pi |
装完先别急着启动,先看一眼配置目录的层级,这一步决定了你后面 80% 的设置能不能一次到位。
3.1 配置目录:全局 vs 项目级
OMP 的全局配置目录位于 ~/.omp/agent/,与 Pi Agent 的 ~/.pi/agent/ 几乎一一对应:
1 | ~/.omp/agent/ |
优先级规则(与 Pi Agent 完全一致):
- 项目目录下的同名配置文件 > 全局配置
- 项目级
AGENTS.md> 全局AGENTS.md system.md作为唯一系统指令;append_system.md作为 OMP 内嵌指令的补充
这条规则的实际意义是:如果你打算在多个 Harness 之间切换,把所有上下文文件放在项目目录根下是最稳的,放到 ~/.omp/ 下反而绑死了工具。
3.2 进入 IDE 能力前:装好 LSP 与 Bun
OMP 只是一个 Agent 客户端,要想用上 LSP 跨文件联动、DAP 原生调试,对应语言的 LSP 必须先装好。比如后面实战里要用 JS 的 LSP,就得提前装:
1 | # 例:为 JS/TS 装语言服务器 |
另外,OMP 的插件体系依赖 Bun,所以建议一并装上并加入 PATH:
1 | curl -fsSL https://bun.sh/install | bash |
这两步做完,OMP 才算进入完整形态。
四、首次启动:30 秒跑通的模型配置
启动命令极简:
1 | omp |
界面相比 Pi Agent 的极简风格多了不少装饰,实际手感仍然在终端里完成所有操作——Tab 切换窗口、回车选项、ESC 退到上一层,熟练之后效率明显高于 GUI。
4.1 供应商配置:/connect
进入后第一步是用 /connect 配置模型供应商。OMP 适配了 60 多家 provider,不仅包括 DeepSeek、Anthropic、OpenAI、Google 这类标准 API,还复用了 Codex、Anti-Gravity、Claude Code 等登录平台的能力——你日常用哪家,基本都能挂上来。
4.2 模型配置:/model 的两条路径
供应商配好后,用 /model 进入模型设置。这里提供两种用法,可以混着来:
路径 A:单模型 + 手动切换
和大多数 Harness 一样,只设一个默认模型,在特定场景下用 /switch 手工换。简单直接,但每次任务都要算账。
路径 B:角色路由表(推荐)
OMP 提供一套「使用场景 ↔ 模型」的映射表,匹配完成后会自动按场景切换模型。这是我在所有 Harness 工具里最希望看到的功能——
打开 /model 后切到 rules 分类,可以看到 OMP 默认按下面这些维度切分场景:
| 维度 | 场景 | 用途 |
|---|---|---|
| 任务难度 | tiny |
简单文字、零碎语言处理 |
small |
中等任务,需要多步完成 / 轻量推理 | |
slow |
复杂推理、规划、深度任务 | |
default |
默认场景 | |
| 任务类型 | chat |
对话模型 |
image |
图片生成 | |
embedding |
向量生成 | |
search |
网络搜索 |
这里的
tiny / small / slow / default名字是 OMP 自己的角色标签,不是某个具体模型。同一款模型也可以挂到不同角色下,关键看你想让它承担哪类工作。
举个例子,实测里我会把 tiny 指向 Gemini 3.5 Flash、small 指向 DeepSeek V3、slow 指向某个推理强模型、default 留给 /plan 用更稳的型号。每个角色还能独立设置思考等级(继承 / low / medium / high)。
经验之谈:初次配置不用追求最优,先用主观判断设一遍,跑两周再根据实际账单和效果迭代。
五、必看设置:权限、Memory、Session 三件套
供应商和模型都搞定之后,别急着开始干活——下面这三组设置决定了 OMP 在生产里能不能稳。
5.1 权限控制:三档 + 自定义
进入 /settings,选 Interaction → Approvals,可以看到 OMP 内置了三档权限 + 一档自定义:
| 档位 | 行为 | 适合场景 |
|---|---|---|
always-ask |
只读操作自动放行,写文件 / 命令必须确认 | 重要项目、生产环境 |
write |
读 / 写文件自动放行,命令必须确认 | 日常开发 |
yolo |
全自动审批 | demo / 临时项目 |
| 自定义 | 逐工具定义权限,如 bash: allow |
精细管控 |
实测建议:对重要项目保持 always-ask 或自定义;对 demo / 学习项目直接 yolo,省心。
如果自定义粒度够细,可以直接写:
1 | approvals: |
OMP 会按你写的策略执行,同时仍然尊重上下文文件里要求的二次确认——这是双保险。
5.2 Memory:四种后端,按场景选
进入 /settings → Memory,OMP 提供了四种 Memory 存储方案:
| 后端 | 形态 | 特点 |
|---|---|---|
local |
本地 MD 文件 | 最简单,所有记忆落到 Markdown,适合个人 |
hindsight |
在线服务(图核心) | 长期记忆的颠覆性方案,能自我总结优化 |
monopoly |
本地 SQLite | 区分全局 / 项目作用域,检索方便 |
sniper |
项目级决策层记忆 | 专为 coding 设计,只记项目开发过程中的决策 |
对纯 coding 场景,sniper 值得专门说一下:它只存储在项目目录下,只记录开发过程中的决策(代码规范、技术选型),后续开发能保持一致性,而且支持指定专属模型(sniper model),不设的话默认走 small 场景的模型。
对大多数个人开发者,先用 local,等会话沉淀到一定规模再切 sniper 或 hindsight。
5.3 Session 管理:断线续传 + 历史回溯
OMP 继承了 Pi Agent 优秀的 Session 能力,并加了几条实用命令:
| 命令 | 作用 |
|---|---|
omp -c |
继续最近一次 session(远程服务器断线重连救命) |
/session |
查看当前 session 状态 |
/resume |
列出历史 session 列表,可选任意一条回退 |
/tree |
回溯当前 session 的历史对话节点,从那里继续 |
/branch |
在当前 session 内开新分支 |
/fork |
以当前对话为基底生成新 session |
/rename |
给当前 session 命名,方便查找 |
/pn |
把当前 session 推到历史列表最上方 |
对长任务、多 Agent 协作,/branch 和 /fork 是两个救命工具——主线走偏时不必从头再来,直接分支即可。
六、上下文文件体系:AGENTS.md / system.md / WATCHDOG.md
OMP 对上下文文件的处理是它和 Pi Agent 一脉相承的关键证据——同一套目录、同一种优先级,意味着存量项目的上下文文件可以直接搬过来。
| 文件 | 优先级 | 作用 |
|---|---|---|
AGENTS.md |
项目级 > 全局 | 项目专属上下文:开发规范、技术栈、交付目标、可做与不可做 |
system.md |
唯一系统指令 | 顶层系统级指令 |
append_system.md |
补充系统指令 | 作为 OMP 内嵌指令的补充 |
RULES.md |
全局 > 项目级 | 平台硬性规则:工具响应方式、输出格式、质量标准 |
WATCHDOG.md |
项目级 | Advisor 监工的判定规则 |
实测建议:
- AGENTS.md 放项目根目录,不要放
~/.omp/下——这样换工具时不需要改路径。 - system.md 和 append_system.md 按需启用,大多数项目只用 AGENTS.md 就够。
- RULES.md 写硬性红线(比如「不允许修改
package.json的依赖版本」),用机器能解析的判断口径。 - WATCHDOG.md 等开了 Advisor 模式再写,刚开始可以直接用默认规则。
七、4 套内置工作流:plan / go / vibe / prework
OMP 真正区分于「工具型 Harness」的能力来自这 4 套工作流——它们都用 / 命令触发,可以直接当成 Agent 团队里的不同岗位。
7.1 /plan:复杂需求的规划师
适合需求模糊、要先理清现状再动手的场景。/plan 会先梳理项目目录下已有代码,再根据用户需求提出一套可执行的方案。
复杂需求建议直接用
/plan启动;可以给它单独指定一个强模型(plan model),规划阶段值得花贵一点的算力。
7.2 /go:有预算的执行者
/go 是带 token 预算 的执行流,启动时直接写:
1 | /go <目标描述> --budget 50000 |
执行结束只有两种结果:完成目标,或者 token 预算耗尽。在执行过程中,/go 会自动把目标拆解成步骤,逐步推进,中途可以用:
/go show— 查看当前目标拆解/go pause— 暂停/go resume— 恢复
7.3 /vibe:多智能体的项目经理
/vibe 是多智能体协作管理工作流,主对话里的智能体会自动成为「Director」,把不同子任务分派给不同的子 Agent 并行执行。
典型场景:一个项目涉及前端 + 后端,/vibe 可以把任务分派给两个子 Agent 分别负责,主 Agent 负责整合和最终交付。特别适合「一个人顶一个团队」的小项目。
7.4 /prework:质优价廉的执行编排
/prework 是我最看好的工作流之一——
- 设计完成后,先用强模型做项目实现规划
- 再把具体编码交给更便宜的模型执行
这套编排让质量、成本之间找到了一个很舒服的平衡点。对国内做长任务、低预算跑生产链路的团队尤其有用。
八、Advisor 监工:三级风险拦截
Advisor 是 OMP 的另一项独家能力——它在主 Agent 之外开一个独立 session,扮演「顾问 / 监工」的角色,实时监控主 session 的运行状态。
8.1 三级风险模型
Advisor 把所有风险分成三档:
| 等级 | 处理方式 |
|---|---|
need |
轻度问题,加注释提示主 Agent 评估是否修改 |
concern |
中度风险,在下一轮交付中注入修改 |
blocker |
严重问题,直接阻断开发流程,要求主 Agent 修复并验证后再继续 |
8.2 WATCHDOG.md:监工的判定规则
Advisor 的判定标准完全由项目根目录下的 WATCHDOG.md 控制。你可以在里面定义:
- 哪些情况算
need、哪些算concern、哪些算blocker - 硬性红线(一旦违反,直接 blocker)
- 审查顺序(从重到轻)
实测时这一机制救了一次场:在「给太阳系加月球」的任务里,Advisor 拦住了一次明显越界的轨迹计算,要求主 Agent 修复后再继续。
8.3 启用与避坑
启用 Advisor 用 -advisor-on,关闭用 -advisor-off。注意三点:
- Advisor 会显著拉长项目运行时间——它每轮都要独立跑一遍判断。
- Advisor 可能给出不合理建议——这时候先优化
WATCHDOG.md,其次切换 Advisor 专属模型,最后才考虑关掉。 - 指令里可以直接忽略 Advisor 的建议——如果你明确知道某条建议是错的,在 prompt 里写明即可。
九、实战:用 OMP 做一个太阳系交互网页
理论说够了,接下来用一个完整的 demo 把上面这些能力串起来——用 OMP 做一个给小朋友演示的太阳系交互网页。
9.1 先写两份上下文文件
进入项目目录,先建两份文件:
AGENTS.md(开发规范):
1 | # 项目规则 |
WATCHDOG.md(监工规则):
1 | # Advisor 规则 |
9.2 启动 OMP,确认 plan mode 的模型
1 | omp |
9.3 /plan 启动规划
1 | /plan 用 HTML + Three.js 做一个交互式太阳系网页:八大行星 + 自转 + 公转 + 可点击查看详情,允许使用真实天文数据。 |
/plan 第一步先扫整个项目目录(空的,所以基本无负担),第二步开始从官方文档 / 权威来源搜集天文数据,所有信息搜集完成之后才进入计划撰写——这一步它严格遵守了 AGENTS.md 里「编程之前把信息搜集完整」的规则。
大概 3 分钟,计划生成完毕。OMP 的 plan 界面分三个窗口:
- 左:计划大纲(目录)
- 右:具体细节
- 底:操作选项(
approved and execute/refine plan/save and quit)
确认无误后,选 approved and execute,并指定用 slow 场景的模型执行(这里我故意用相对重的模型,展示 Advisor 不触发的情况)。
9.4 多 Agent 并行执行
执行一开始,状态栏右下角显示 2 个 Agent 同时运行——
- Agent 1:3D 场景实施(Three.js 路线)
- Agent 2:Canvas 画布场景实施(2D 路线)
OMP 自动判断这两个任务没有相互依赖,所以并行分配。大概 10 分钟,两个 Agent 都完成,主 Agent 做最终整合,网页可以正常打开——八大行星、轨道、自转公转都符合预期。
9.5 /go 加一个新功能:月球
第一步完成后,用 /go 加一个新需求——月球在地球附近环绕。
1 | /go 在地球附近增加月球,月球绕地球旋转,速度合理 |
/go 自动分析目标 → 拆解步骤 → 逐步执行。这个过程里 Advisor 触发了一次——拦住了月球轨迹计算的一个明显越界推理,要求主 Agent 修复后再继续。最后交付的网页里,月球很自然地绕地球旋转,速度肉眼看上去也合理。
9.6 看一下成品效果
完成后打开本地服务器,八大行星按比例排列、自转公转运行流畅、点击任意行星弹出详情面板——一个完整的、给小朋友演示用的交互式太阳系网页,实测从规划到交付 13 分钟左右。
整个流程跑下来,印证了一件事:OMP 把规划、执行、监工三件事拆得很清楚,并且每一层都允许单独指定模型——这对成本敏感型的团队是个相当务实的工程方案。
十、LSP 跨文件重命名 + 复用 Pi Agent 生态
10.1 LSP 跨文件重命名
LSP 最常用的场景是标识符重命名——改了某个函数名,OMP 通过 LSP 自动找到所有引用并修改。实测一次不到 1 分钟,所有引用同步更新,代码前后一致性得到有效保证。
前提还是那句话:先装好对应语言的 LSP,然后在 OMP 里要求它「使用并激活 LSP」即可。
10.2 直接复用 Pi Agent 生态
因为 OMP 与 Pi Agent 共用一套内核,Pi Agent catalog 里的插件在 OMP 里也能直接用:
手动安装方式——把 pi install npm <插件名> 直接换成 omp install npm <插件名>:
1 | omp install npm ask-question |
Marketplace 方式——装一个 zmarket 扩展,它会把 Pi Agent 和 OMP 的扩展市场聚合在一起:
1 | omp install npm zmarket |
进入 OMP,执行 /zmarket,可以直接搜索 / 安装 / 浏览跨 Harness 的扩展包,每条都贴心地标了它跟哪些 Harness 工具适配。
这意味着 Pi Agent 上验证过的所有插件,在 OMP 上是零迁移成本——这一点对已经在 Pi 生态里深耕过的开发者来说,是切换到 OMP 最大的利好。
十一、谁该用 OMP,谁该继续用 Pi Agent
把整套实测拉回小目标:
优先选 OMP 的场景:
- 想装好就用,不愿自己组装 Harness的开发者
- 项目需要多模型路由(不同任务用不同模型),且预算敏感
- 需要原生 LSP / DAP 能力,做严肃的工程开发
- 项目里上下文文件已经按 AGENTS.md 体系写好了,希望工具自动读
- 需要 Advisor 监工,对生产链路风险敏感
继续用 Pi Agent 的场景:
- 你是极简主义者,享受从 4 个工具自己拼装的快感
- 项目规模小,根本不需要多智能体协作
- 你已经在 Pi 生态里深度定制,迁移成本反而比新增工具低
- 想要最轻量的 TUI 体验,不希望界面有装饰元素
一句话总结:OMP 是 Pi Agent 的「全副武装版」,不是替代品——你装哪个,取决于你想要「少即是多」还是「多即是省心」。
总结与配套资源
最后把这次实测的所有关键点收一下,给一份上手优先级清单:
- 第一件事:安装 +
/connect+/model路由表——这三步是 OMP 的入口,缺一不可。 - 第二件事:
/settings里把 Approvals 调到适合自己的档位——yolo 之前想清楚后果。 - 第三件事:Memory 先用
local,跑两周再换sniper或hindsight——别一上来就上最复杂的方案。 - 第四件事:
AGENTS.md写好就开/plan,复杂需求不要直接/go。 - 第五件事:Advisor 不是越多越好,第一次用建议关掉,等熟悉工作流后再开。
配套命令速查:
1 | # 安装 |
如果你之前就在用 Pi Agent,这篇可以当成对照参考——不需要切换,只需要知道 OMP 在哪些能力上做了加强。如果你刚准备入 Agentic Coding 的坑,OMP 是当前少数能把「开箱即用」和「高自由度」两端都做扎实的工具,值得花一晚上先跑一遍上面的实战。
更多 Pi Agent 的深度内容,可以看 Pi Agent 必装 8 个插件实测 和 Pi Agent 零基础入门——把它们当成「轻装版 + 全装版」的对照读,会对 OMP 的设计取舍理解得更透。