2026 年上半年，两个终端 coding agent 在开发者社区引发了密集讨论：Pi 和 OMP（Oh My Pi）。前者以极简著称，核心代码只有 418 行（我们之前在《Pi Coding Agent：一个 418 行代码的终端 AI 编码代理》中做过详细拆解）；后者是前者的功能增强 fork，用 Rust 重写了约 8 万行底层代码。

讨论的焦点指向一个更根本的问题：模型的能力边界，到底由模型本身决定，还是由包裹它的 harness 决定？

Pi 是什么

Pi 由 Mario Zechner 开发，是一个运行在终端里的 coding agent。它的设计哲学可以用一句话概括：只保留最小可用的工具集。

内置工具只有 4 个：

• read：读取文件
• write：写入文件
• edit：编辑文件
• bash：执行命令

没有内置子 agent，没有 Plan Mode，没有权限确认流程。所有扩展功能通过插件系统按需添加。

这种极简设计带来了两个直接好处。第一，初始 context 很小，模型在会话开始时不需要加载大量工具描述，token 消耗从起点就低。第二，核心循环足够短，开发者可以完整阅读、理解和修改它。

截至 2026 年 8 月，Pi 在 GitHub 上获得超过 84,000 stars，支持 OpenAI、Anthropic、Google、xAI、Groq 等主流 provider，提供交互式、JSON、RPC 和 SDK 四种运行模式。

OMP 是什么

OMP（Oh My Pi）由 Can Bölük 开发，是 Pi 的官方 fork。名字致敬 Oh My Zsh，定位也类似：在精简内核上构建功能丰富的完整体验。

OMP 的核心变化包括：

31 个内置工具，覆盖文件操作、代码搜索、测试运行等完整开发链路。

Rust 核心，约 80,000 行代码，将 ripgrep、globbing、搜索等重操作重写为原生实现。

60+ provider 支持，包括通过现有 Claude Pro 或 ChatGPT Plus 订阅直接连接。

LSP 集成，直接连接语言服务器（TypeScript、Go、Python 等），重构操作基于语义理解而非文本匹配。当要求重命名一个函数时，LSP 会更新所有引用、barrel 文件和 re-export，而不是简单的字符串替换。

DAP 调试器支持，可通过 dlv（Go）、debugpy（Python）、lldb-dap（C/C++）附加到运行中的进程，设置断点、单步执行、检查变量状态。

子 agent 系统，将任务拆分到多个隔离的 worktree 中并行执行，返回结构化结果。

角色路由，为不同任务类型分配不同模型：PLAN 用高推理能力模型，TASK 用快速低成本模型，VISION 用多模态模型。

OMP 于 2025 年 12 月 31 日发布，7 个月内获得 22,000+ stars。

核心差异：Hashline Edits

两个项目最值得关注的技术差异，是文件编辑的实现方式。

传统 AI agent 编辑文件时，需要模型完整重写原文以便系统“定位”修改位置。只要有一个空格、一个 tab 的差异，替换就会失败。

OMP 引入了 Hashline Edits 机制：文件被读取时，每行会生成一个 2-3 字符的内容签名。模型编辑时只需引用签名（如“替换签名 2:f1 的行”），无需重写原文。如果文件在读取后被修改，签名不匹配，替换会被拒绝，避免破坏代码。

这个看似微小的改动带来了惊人的效果。Can Bölük 用 16 个模型在 180 个 React 代码任务上测试（每个任务跑 3 次），结果如下：

16 个模型平均提升约 15 个百分点。

Bölük 有一句总结，“模型是护城河，harness 是桥梁。”模型的上限由其自身能力决定，但用户能否触及这个上限，取决于 harness 的设计。一个便宜模型配合好的编辑格式，可以胜过昂贵模型配合差的编辑格式。

实际使用体验差异

初始上下文与 token 消耗

Pi 只有 4 个内置工具，会话开始时的 context 很小。OMP 有 31 个工具加上子 agent、LSP、DAP 等能力描述，初始 context 显著更大。

一位开发者在两周对比测试中使用相同模型（DeepSeek V4 Flash + Pro），发现 OMP 的 token 消耗比 Pi 高 1-2 倍。测试者在 OMP 上做前端开发，同事在 Pi 上做后端多项目开发，按项目复杂度推算同事的消耗应该更高，但实际结果相反。

UI 与交互

Pi 的界面简洁，信息密度低，适合专注工作。OMP 的界面信息量大，面板多，功能入口丰富。两种风格各有受众。

权限控制

Pi 默认没有权限确认流程，agent 可以直接编辑文件和执行命令。OMP 有权限确认机制。对于偏好“先信任、出问题再介入”的用户，Pi 的设计更符合预期。

子 agent 可靠性

Pi 的子 agent 需要通过第三方扩展实现，自动调用的稳定性存在波动。OMP 的子 agent 是内置功能，调用一致性更好。

Plan Mode

Pi 没有内置 Plan Mode，需要安装扩展。OMP 内置 Plan Mode，生成的计划质量高，但 token 消耗也显著更高。

与 Claude Code 的对比

Standard Compute 对 OMP 和 Claude Code 做了结构化评测（6 个维度）：

• Claude Code 领先：输出质量、自主性、可靠性、易用性
• OMP 领先：速度、性价比

OMP 与 Claude Code 走的是不同技术路线：开源 vs 闭源，60+ provider vs 单一模型锁定，IDE 级工具集成 vs 终端基础能力。

选型参考

适合 Pi 的场景：偏好极简界面；愿意花时间搭建扩展组合（参考我们的实战配置指南和进阶配置指南）；在意 token 成本控制；喜欢“agent 直接干活不问”的工作流。

适合 OMP 的场景：需要 LSP 级别的语义重构；经常需要调试器排查 runtime 问题；想开箱即用；需要子 agent 并行、跨会话记忆等高级功能。

值得思考的问题

Pi 和 OMP 的分野，本质上是对“Harness Problem”的两种回答。我们在《DeepSeek Harness 开源解读》中也讨论过类似的设计取舍，DeepSeek 的 dsh 选择了“一切皆插件”的第三条路。

Pi 的回答是：保持核心最小，让用户自己选择需要什么。代价是初始搭建时间长，第三方扩展质量参差不齐。

OMP 的回答是：把所有可能需要的东西都内置，用户可以禁用不需要的。代价是初始 context 大，每次会话有固定 token 开销。

两种回答各有取舍。选择取决于一个更根本的问题：你更在意启动时的开销，还是每次会话的持续开销？

对于高频使用 coding agent 的开发者，每次会话的 token 成本累积很快，Pi 的极简设计在长期使用中可能更经济。对于偶尔使用、希望快速上手的开发者，OMP 的开箱即用体验更有吸引力。

来源：

• Oh My Pi: The Agent Everyone’s Talking About（YUV.AI，2026 年 8 月 6 日）
• OMP: AI Coding Agent with LSP, DAP Debugger, and Hashline Edits（Better Stack，2026 年 6 月 1 日）
• Pi vs OMP: A Coding Agent Comparison（Marga Satrya，2026 年 7 月 9 日）
• GitHub: oh-my-pi