如果你用 Claude Code 或 Codex CLI 改过代码，你一定碰到过这个场景：Agent 改了一行，空格缩进差了一点，patch 匹配失败。重试，再失败，再重试。你眼睁睁看着 token 在烧，改的是一个变量名，花的却是重构整个模块的预算。
不是模型不行，是编辑格式在拖后腿。can1357 的 oh-my-pi（命令行敲 omp）用了一种叫 Hashline 的方案来解决这件事：给每行代码加一个内容哈希，编辑时按哈希定位，不跟空格死磕。
实测数据摆在面前：Grok Code Fast 的编辑成功率从 6.7% 拉到 68.3%，token 消耗少了 61%。这不是换个模型、加个 Prompt 能啃下来的收益，是把编辑这个最基础的操作重新设计了一遍。
但 Hashline 只是它 32 个内置工具里最亮眼的一个。把 IDE 的 LSP、调试器、浏览器和持久化运行时全接进终端 Agent，才是 omp 在回答的那个根本问题：如果终端 Agent 不是”带 AI 的命令行”，而是”去掉了 GUI 的完整 IDE”，会发生什么？
打动我的不是 Star 数，是它把三件大事做对了
omp 的 GitHub 描述很克制：“A coding agent with the IDE wired in.” 克制背后是野心。它 fork 自 Mario Zechner 的 Pi 项目，然后塞进了约 55,000 行 Rust 核心、15 个 TypeScript 包的 monorepo、40+ 模型提供商和 25 个搜索后端。四个月从 3.4K Stars 冲到 16.7K，不是靠营销，是靠把别人需要装插件的东西做成出厂自带。
LSP 集成是第一个分水岭。普通终端 Agent 重命名变量，本质是全局搜索替换，跟按 Ctrl+H 没区别。遇到桶导出文件（barrel files）或动态导入，漏引用是常态。omp 走的是 workspace/willRenameFiles 协议，所有引用、重导出、别名导入，在文件移动前全部更新完毕。Agent 知道的符号表，和 VS Code 知道的是同一份。formatBytes 改名，5 个引用分布在 3 个文件里，全部正确处理。
调试器是第二个。C 程序 segfault，omp 接管 lldb，走到崩溃帧，读局部变量，给答案。不是 print 调试，是真调试器，支持 lldb、dlv、debugpy 共 28 种 DAP 操作。这在终端 Agent 品类里，目前 omp 是独一份。
第三个是子 Agent 设计。普通 Agent 处理复杂任务一路串行，中间某步错了要重头来。omp 把任务分发到隔离 git worktree 的多个 Worker，并行出结果，再汇总。每个子 Agent 可以跑不同模型，互发消息。这跟人类团队的 task force 模式更像，而不是 pipeline。
还有个容易被忽视的细节：配置继承。omp 启动时自动检测 Cursor、Windsurf、Claude Code、Codex、Gemini CLI、Cline 等 8 种工具的配置文件并导入。如果你花过时间调 CLAUDE.MD 或 MCP 配置，那些规则直接继承，不用重写。这个设计让迁移成本变成了零。
除此之外，它有套叫 Advisor 的机制值得一提：第二个模型观察每一个回合，在 Agent 输出里注入行内注释，相当于有个老工程师在旁边盯着你的 Agent 干活，错了当场纠正。还有协作模式的 collab 功能，通过中继服务器共享实时会话，一个链接就能让同事看到你的 Agent 在做什么。这套组合把”一个人用终端 Agent”的体验变成了”一个团队用 Agent 协作”的雏形。
跑起来很简单，但坑你得提前知道
安装三选一，curl 最省事。但如果你在意启动速度和包管理，我建议用 Bun 装：
curl -fsSL https://omp.sh/install | sh
Bun 是推荐方式，安装路径在 ~/.bun/bin，不会跟系统 Node 冲突：
bun install -g @oh-my-pi/pi-coding-agent
Homebrew 用户也可以走 tap 渠道，Windows 用户有专门的 PowerShell 安装脚本。三种方式装完后敲 omp --version 确认一下，当前最新是 v17.1.7。
装完在项目目录敲 omp 就能进交互式 TUI。第一次跑会引导你选模型，40+ 提供商从 Anthropic、OpenAI、Google Gemini、xAI、Mistral、Groq 到 Ollama、OpenRouter 全有。角色路由支持五个槽位：default、smol（便宜模型）、slow（深度推理）、plan（规划）、commit（提交信息）。小任务走便宜模型，重推理走贵的，一个项目混着用，整体成本比全用旗舰模型低一截。
但诚实地说，坑点也得摆出来。这些都是实测和 Issue 区里确实有人在抱怨的：
-
WSL 用户别把项目放在 /mnt/c 下，I/O 慢到怀疑人生。装到 ~/.bun/bin 里。 -
Windows 支持存在但不完美。调试器行为没有专门文档，lldb 依赖需要额外折腾。 -
约 617 个 Open Issue 中相当部分是功能请求和边缘兼容性问题。动手前翻一下有没有踩到你用的语言。 -
版本号跳得比语义化版本规范快得多。四个月从 v3 冲到 v17.1.7，BREAKING CHANGES 偶尔藏在 patch 版本里，升级前看一眼 CHANGELOG。
功能亮点说完了，但光看功能列表你只能判断它”能做哪些事”。真正该问的是：你该不该用？
什么时候用，什么时候别用
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| 终端重度用户（ssh + tmux） | 后端/DevOps | 无 GUI 依赖，全终端操作 | TUI 操作习惯需要适应 |
| 多模型成本优化 | 独立开发者/小团队 | 角色路由，便宜模型干粗活 | 自己调模型选择策略 |
| LSP/调试器深度依赖 | 系统/底层开发者 | 真 LSP + DAP，非 grep 替代 | 需本地装对应语言服务器 |
| 多项目并行开发 | 全栈/开源贡献者 | Git worktree 子 Agent 隔离并行 | 内存占用比单 Agent 高 |
表里的场景能覆盖大部分用户画像，但有几类人我建议先别急着装。不适用的情况直接说清楚：
-
你从不进终端，代码全在 VS Code 里点按钮改。用 Cursor 或 Copilot 更省事。 -
你从不进终端，代码全在 VS Code 里点按钮改。用 Cursor 或 Copilot 更省事。 -
你的项目是前端 UI 页面为主，变量重命名需求很少。omp 的 LSP 深度集成对你有点 overkill。 -
你需要企业级 SLA 和支持合同。omp 是个人维护的社区 fork，没有商业支持。 -
你没有稳定的 API 预算。omp 不卖模型，你自己付 API 费，重度使用一个月 token 花销可能上百美元。
体验和场景都聊得差不多了，但还有一个关键问题没碰：这个项目能不能活到明年？这就得看社区了。
社区：一个人的项目跑出了第一梯队的声量
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | ~16.7K（截至 2026 年 7 月） | 4 个月从 3.4K 冲到 16.7K，增速凶猛 |
| 核心维护者 | 1 人（can1357） | Bus Factor 高风险，高度依赖单一开发者 |
| Open Issues | ~617 | 功能请求占比高，bug 类比例不夸张 |
| 协议 | MIT | 商业友好，可商用可魔改 |
can1357 是这个项目的灵魂。15,874 次提交，一人扛 TypeScript 应用层和 Rust 核心引擎的开发。190+ 贡献者参与但核心架构决策基本单线程。对快速迭代期的项目来说不一定是坏事，但如果要在生产环境长期依赖它，Bus Factor=1 这个事实必须正视。
HackerNews 上的评价分化得很有意思。有用户说 “extremely hackable with sensible defaults”，另一个用户称 “the first coding agent that really empowered me to morph it to fit the way my brain works”。但也有反对声音，有人直接管它叫 “oh-my-bloat”，认为相对于原始 Pi 的极简哲学，omp 往里塞了太多东西。
arcbjorn 博客 2026 年 7 月的 CLI Agent 市场调查给出了更冷静的结论：Claude Code、Codex CLI 和 omp 现在已经”大致持平”，区分它们的不是模型能力，是 harness 层在正确时刻给 Agent 递上正确工具的能力。在这个维度上，omp 的 32 个内置工具确实比竞品多一截，但维护资源的差距也同样明显。这份调查还提到一个有意思的细节：它统计了 35 个活跃维护的 CLI Agent，三个头部工具之外，剩下的 32 个绝大多数只在某一个小维度上有区分度。omp 是这 35 个里面功能最宽的，也是唯一一个社区 fork 跑进第一梯队的。
社区数据好看，竞品对比也不落下风。但所有这些分析做完之后，我真正关心的只剩一个问题：它值不值得你把工作流押上去？
它不是”又一个 Claude Code 替代品”，它是另一种思路
我跟这个项目相处下来，感受不是”它很强”，是”它把很多人在各自工具里偷偷做的事，集中到一个地方公开做了”。Hashline 不是全新的 idea，内容寻址编辑在文件同步领域早就有人用。但把它从文件同步迁移到 Agent 编辑，并且用 16 个模型 × 180 个任务 × 3 遍重复跑了基准测试来验证，这个工程严谨度在开源 Agent 项目里不多见。can1357 花在 benchmark 上的那 300 美元 API 费用，比大多数项目的 README 都有说服力。
但 omp 目前的状态像一个还在疯狂扩建的工地。功能很多，文档很长，但不同模块的打磨程度参差不齐。LSP 和调试器已经很稳，浏览器自动化和子 Agent 还在快速变动。如果追求开箱即用不折腾，Claude Code 的交互体验仍然更干净。但如果你愿意花时间调工具链，omp 给的可定制空间是封闭产品给不了的。
说实话，omp 最让我意外的不是它的功能数量。它让我意识到，这一轮 AI 编程工具的竞争已经不发生在模型层了。Claude Code、Codex CLI、omp 三个工具，你用同一个 Sonnet 4 模型跑，输出质量差距其实很小。真正拉开距离的是 harness：谁能在 Agent 需要的时候递上最合适的工具，谁更快，谁更不容易出错。omp 在这个维度上做了最多的实验，也承担了最大的复杂度。
有个趋势值得盯紧了：Hashline 编辑格式已经被提出作为跨工具标准化候选方案。arcbjorn 的调查提到了这个动向。如果它真的成了标准，omp 就不再只是”Claude Code 替代品”，而是定义了一部分 Agent 基础设施的底层协议。从”好用”走向”重要”，这一步才是它真正的天花板。
还有一件事让我对 omp 的长期潜力多了一点信心：它的 Rust 核心模块设计是精心分层而非随意堆砌的。shell、grep、ast、text、summary 每个模块界限清晰，通过 N-API 绑定到 TypeScript 层，而不是用大量 FFI 胶水代码硬凑。这种架构让每个 Rust 模块可以独立演进和测试，也降低了外部贡献者参与特定模块的门槛。对于 Bus Factor=1 的项目来说，清晰的模块边界是降低维护风险最务实的办法。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/can1357/oh-my-pi |
| 官方网站 | https://omp.sh |
社区和洞察都聊完了，最后的最后，回到一个最实际的问题：你现在该做什么。
先跑起来，再决定要不要深入
如果你已经在终端里写代码，花五分钟装个 omp 试试 Hashline 编辑功能，配上一个 API key 就能跑起来。从这个小切口入手，比你对着文档研究全部三十二个内置工具划算得多。
还在观望的话，盯两个指标：can1357 能不能吸引到第二个核心维护者。四个月冲到 16.7K Stars 的项目，如果一直是单维护者，天花板会来得比想象中早。另一点是 Hashline 格式的标准化进展，这决定了 omp 能不能从”好用的个人工具”变成”基础设施的一部分”。这两个信号比任何功能更新都更能说明 omp 的长期走向。
好 harness 比好模型值钱。这句话我们 2025 年不信，2026 年开始信，2027 年可能要靠它吃饭了。