omp 入门：把 IDE 装进终端的编程 agent

关于 AI 编程 agent，社区讨论的重心几乎都在模型上：Claude 还是 GPT，Gemini 这周又发布了什么。omp 的作者 can1357 在 The Harness Problem 里给出了一个相反的判断：模型只是参数，工具链（harness）才是真正可控制的变量，大多数失败发生在"模型知道要改什么"和"改动真正落地"之间。

omp（Oh My Pi）就是围绕这个判断构建的终端 agent。它是 Pi（Mario Zechner 的作品）的 fork，GitHub 上 23k stars，约 8 万行 Rust 引擎做底。它的口号很直白：a coding agent with the IDE wired in——把 IDE 的能力直接接进终端。

定位：模型无关的开源 harness

omp 的形态和 OpenCode 这类终端 agent 类似：一个 TUI，进入项目目录就能和 agent 对话。区别在内部设计。

• 60+ 提供商、1000+ 模型：Anthropic、OpenAI、Gemini、DeepSeek、OpenRouter、本地 Ollama 等，也接受任何 OpenAI 兼容端点
• 10 个模型角色：default / smol / slow / plan / commit 等，按任务意图路由；支持 fallback 链和 API key 轮换
• 四种入口：交互 TUI、omp -p 一次性问答、Node SDK、omp --mode rpc 和 ACP（可被 Zed 等编辑器驱动）

模型无关不只是宣传。由于没有绑定某个厂商，omp 的每个工具都要经受各种模型的检验，这反而成了它的优势：不依赖模型对自家格式的偏好，工具本身要足够宽容。

Hashline：按内容哈希编辑

这是 omp 最核心的设计，也是那篇 harness 文章的实验对象。

传统编辑格式各有各的问题：Codex 的 apply_patch 只有 OpenAI 系模型"说这种语言"，Grok 4 用它时失败率 50.7%；Claude Code 的 str_replace 要求逐字符精确复现旧文本，空格缩进都不能错，"String to replace not found" 成了常见报错，在 GitHub 上有专门的 issue 串。

omp 的做法是：agent 读文件或 grep 时，每一行都附带一个 2–3 字符的内容哈希标签：

hello.js — read
1:a3|function hello() {
2:f1|  return "world";
3:0e|}

编辑时模型引用标签而不是复述内容——"把 2:f1 换成 "hello""。文件如果已经变了，哈希对不上，补丁在造成破坏前就被拒绝。

作者用 React 代码库构造了 180 个 bug 修复任务，跑了 16 个模型、3 种编辑格式，结果是一边倒的：hashline 在 14/16 个模型上优于 patch。Grok Code Fast 1 的通过率从 6.7% 涨到 68.3%，MiniMax 翻倍，Grok 4 Fast 的输出 token 减少 61%——因为它不再把 token 烧在重试循环里。一个格式改动带来的提升，比大多数模型升级还大，而训练成本是零。

代码智能：LSP 和 DAP

多数 agent 靠文本猜测代码结构，omp 直接问语言服务器。

• LSP（14 种操作）：诊断、跳转、符号、重命名、代码动作。重命名会走 workspace/willRenameFiles，re-export、barrel 文件、别名导入在文件移动前就更新好
• DAP（28 种操作）：agent 能驱动真实调试器——C 二进制崩了挂 lldb 看栈帧，Go 服务卡住用 dlv 遍历 goroutine，Python 进程僵了用 debugpy 暂停检查

给 agent 一个"会编译的编辑器"而不是一堆字符串，这是把 IDE 装进终端的直接含义。

原生 Rust 引擎

很多 agent 靠 shell 调用 ripgrep、glob、sed，每次调用都是一次 fork/exec，某些平台上这些二进制还不存在。omp 把实现编译进了进程：

• 6 个 crate、约 8 万行 Rust：搜索、AST、语法高亮、PTY、桌面控制、图片解码都在进程内完成
• bash 用 brush 替代，58 个命令行工具（ls、sed、jq、sort 等）移植进 builtins，零 fork
• macOS / Linux / Windows 同一套二进制，Windows 不需要 WSL 桥接

协作与记忆

• task 子代理：并行派发到隔离的 worktree，各自有独立工具面，返回 schema 验证过的结构化结果，父代理直接读取，不用解析散文
• advisor 角色：配一个独立 reviewer 模型，阅读主代理的每一轮行动并注入笔记，用独立的上下文和模型，能发现执行者匆忙略过的点
• 记忆系统：运行中用 retain 写事实、learn 存教训、recall 检索，会话结束压缩成 mental model，下次启动第一轮就加载。后端可选本地、Hindsight 或 Mnemopi，按项目隔离
• 时间旅行流规则：规则平时不占上下文，模型跑偏时用正则匹配到，中断 token 流、注入规则、从同一位置重试。修正生效且不支付每次对话的上下文税

其他值得提的细节

• omp commit：读取工作树，把无关改动拆成按依赖排序的原子提交，循环依赖直接拒绝；源码权重高于测试和文档
• conflict://：每个 merge conflict 是一个 URL，写 @theirs 或 @ours 一行就解决
• pr://、issue:// 等 16 种内部 scheme：read pr://1428 和 read src/foo.ts 同一套工具面
• 规则格式兼容：直接读 Cursor MDC、Cline .clinerules、Codex AGENTS.md 等 8 种格式，不用迁移脚本
• eval：持久 Python 和 Bun worker，两个内核都能回调 agent 的工具
• /collab：把会话挂到 relay 分享链接，只读或读写，帧在客户端加密

为什么好：它回答了"模型之外的变量"

回到开头的判断。模型能力是一个乘数，harness 是另一个乘数，而 harness 是可以不花一分钱训练算力就改进的。这个角度看，omp 的每一项设计都有明确的针对性：

对我个人而言，omp 值得关注的原因还有一个：它的作者不依赖任何模型厂商的善意，甚至被 Google 封过账号（他在文章里贴了截图），但 harness 的改进照样让 Google 自家模型涨了 8 分。模型是护城河，harness 是桥梁——开源 harness 会为所有模型调优，因为贡献者用不同的模型，修的是自己遇到的失败。这句话是 2026 年编程 agent 领域最值得记住的判断之一。

我还没有把 omp 接入日常流程，但这篇研究让我确认了一件事：当模型竞争白热化时，工具链质量正在成为体验的分水岭。

参考

• omp 官网
• The Harness Problem — Can Bölük
• oh-my-pi GitHub 仓库
• Pi — Mario Zechner
• Diff-XYZ 基准（JetBrains）
• EDIT-Bench 基准