讲 Pi 的文章，喜欢夸它“克制”：只有四个基础工具，其他能力需要时再加，子 Agent、代码智能、计划模式，都没有默认塞进底座。
问题是，从“什么都能自己搭”到“装好就能干活”，中间还差一段路。
大多数人并不想从几千个扩展里慢慢试，也不想自己研究代码智能怎么接、子 Agent 怎么管、长任务怎么压缩。
对不想自己搭工作台的人，更省事的选择，是有人先把反复用到的能力挑出来、调通，再组合成一套靠谱的默认方案。
看到 Oh My Pi（omp） 这个名字，很容易以为它和 Oh My Zsh 差不多：给 Pi 装上一批插件，再配一套漂亮的默认设置。
继续看仓库才会发现，不是这么回事。
omp 有自己的命令、软件包、配置目录、发布版本和跨平台安装包。它还改了文件怎么读、代码怎么改、任务怎么分、会话怎么保存，并加入了自己的 Rust 底层。
它不是 Pi 的插件包，而是从 Pi 分支出来、重新整合过的一套 Coding Agent。
Oh My Pi 欢迎界面。
它也不只是把 IDE 搬进终端。
它把一批经过选择和调校的做法放进同一个产品：代码导航、调试器、浏览器、子 Agent、记忆和代码审查。其中一些默认可用，记忆等能力则需要另行启用和配置。
omp 又确实是从 Pi 发展出来的，Pi 作者 Mario Zechner 还公开推荐过它。
它们分歧是：写代码时那些绕不开的麻烦，到底该由开发者自己解决，还是由工具提前接住？
Pi 把选择权交给你，也把搭建和维护的活交给你。
omp 选择自己把这些活干了。
先别数工具，看看它到底解决了什么
按 2026 年 8 月 11 日的官方说法，omp 有 31 个内置工具、60 多个模型服务商，以及约 8 万行 Rust 核心代码。
这些数字没什么好吹的。工具再多，解决不了实际问题，也只是菜单更长。
omp 值得看的地方，是它从接任务开始，一直管到代码交付。
1. 找问题：别一上来就把整个仓库塞给模型
Agent 接到任务后，第一步通常不是写代码，而是找入口。
相关文件在哪？谁调用了它？最近哪个改动碰过这里？文档里有没有说明？
这一步很容易浪费上下文。
模型打开一个几千行的文件，终端倒出一大段日志，再从网页复制一整页文档。真正有用的信息还没找到，上下文先被原始材料塞满了。
omp 的“读”和“搜”沿用同一套路径。代码、目录、PDF、网页，以及 GitHub 上的问题和代码合并请求，都能顺着往下读。
遇到符合条件的长代码文件，它会保留结构、折叠无关部分，而不是默认整份倒给模型。
重点不在能不能搜，而在于少往上下文里倒垃圾。
Pi 的办法更朴素：让模型通过命令行，按需读取工具说明，再去找资料。
好处是工具少。搜索、网页读取和 GitHub 信息怎么接，则要你自己选方案。
2. 改文件：模型会写代码，却经常把修改贴不上去
让 Agent 改文件，常见的失败并不是代码不会写，而是修改指令对不上：行号变了、缩进差一个空格、原文件刚被别的工具改过。
模型只能重试。几次不成，干脆把整段重写。
这不仅浪费模型调用额度，也容易顺手改坏本来没问题的代码。
omp 的 Hashline 会给读过的内容加上短标记。模型修改时，对着标记下手。
文件没变，修改落地；文件已经变了，旧标记失效，修改会被拒绝，不会落到错误位置。
它还准备了另一套批量修改工具。
比如把项目里的 console.log 换成统一日志函数，可以先预览会改哪些地方，确认后再一次落盘，不会改到一半留下半成品。
批量修改会先显示影响范围，确认后再应用。
作者用 16 个模型、180 个任务做过编辑工具测试，部分模型的成功率提升明显，输出也短了很多。Mario Zechner 也公开称赞过 Hashline。
但“某种编辑方式更好用”不等于“整个 Agent 成功率提升十倍”。公众号里常见的“少 61% Token、成功率高 10 倍”，测的是特定编辑任务，不是完整的软件开发过程。
3. 跨文件修改：改了名字，别处还在用旧的
给一个函数改名，漏掉的通常不是定义本身，而是其他文件里的引用、重新导出的入口、用了别名的地方。
只做文本替换，很容易留下半新半旧的一套代码。
omp 接入了和 IDE 同类的代码智能。它知道一个符号在哪里定义、被谁引用；移动文件或改名时，也能联动更新相关位置。
改完以后，诊断结果会马上回来，告诉模型还有哪里没处理干净。
一次改名，联动三个文件中的五处引用，并检查旧名称是否还有残留。来源：Oh My Pi 官方演示。
这项能力有用，但“马上反馈”并不总是好事。
跨多个文件的重构，中间过程本来就可能暂时跑不起来。如果模型每改一处就收到一批报错，它也可能误以为方案错了，提前回头。
Pi 没把代码智能做成默认能力，至少避开了这种干扰。
更合适的做法是分清阶段：小改动及时检查，大重构等一组修改完成后再统一验收。
4. 调试：日志和 print 查不出的东西，得进调试器看
很多 Agent 所谓的调试，就是读报错、加几行 print、重新跑一次。
普通脚本够用，碰到程序崩溃、服务卡死、线程互相等着，就不够了。
omp 接了真实调试器。
C 程序崩了，它可以停在出错位置看调用栈；Go 服务挂住了，可以看有哪些协程堵着；Python 进程卡住了，可以暂停后检查变量。
这是很实在的能力。过去 Agent 只能根据文字线索猜，现在它能看到程序出问题那一刻的现场。
它也不是人人需要。做系统、服务端、底层开发的人会很有感觉；主要写页面、脚本和文档的人，可能很久都用不到。
Pi 选择不内置，理由也很简单：少数场景需要的重工具，不必让所有人每次都背着。
5. 并行干活：几个 Agent 一起上，最怕互相踩文件
任务一大，很多人会想多开几个 Agent：一个查代码，一个改实现，一个补测试。
实际跑起来，问题很快就来了。
它们可能同时改同一份文件；有人做了别人已经做过的事；最后交回来的报告又全是自然语言，主 Agent 还得猜哪个结果能信。
omp 支持为子 Agent 开启工作区隔离。开启后，每个任务可以在独立工作区中运行，避免直接在同一目录互相覆盖；不过这项隔离默认关闭，需要用户选择合适的模式。
任务还可以通过 schema 约定返回字段，让子 Agent 的结果经过结构检查，而不是让主 Agent 从一大段话里捞结论。没有提供 schema 时，返回的仍是普通任务输出。运行中的 Agent 也能集中查看和干预。
同时启动三个 Agent，分别分析不同模块。
这些机制给文件冲突、重复劳动和结果难汇总提供了处理办法，但隔离和结构化返回都不是无条件生效。
Pi 不内置子 Agent，更愿意让用户开多个独立实例，自己看着每个实例怎么工作。
透明是透明，但协调、合并和验收也都落回用户手里。
当然，多 Agent 不是越多越好。任务拆错了，开十个也只是十个人一起走弯路。工具能解决协作秩序，解决不了任务该不该拆。
6. 长任务：聊到后面，它开始忘记前面说过什么
会话越来越长，旧内容总得压缩。常见做法是再叫一个模型来写摘要，然后删掉原文。
问题是，摘要会自作主张。
它觉得不重要的文件名、参数或约束，可能正好是后面要用的。等你发现，原文已经不在上下文里了。
omp 的 Snapcompact 很特别：它把旧对话排成一张密密麻麻的文字图片，再让能看图的模型读回来。
这样不用额外调用模型写摘要，也不会先由另一个模型决定什么该留、什么该删。
作者在 SQuAD 上做的问答与召回自测显示，部分模型配合优化后的图片配置，这项指标可以接近直接保留原始文本；不同模型之间的差异很大。它不能直接代表真实编码任务中的压缩效果。
但目前我没看到独立团队公开复现，而且它只适合能看图的模型。现在还不能说它一定更好，不过“压缩不一定非得先改写内容”这个想法值得看。
Pi 本身也内置了自动压缩、手动 /compact 和分支摘要。它走的是摘要式压缩：调用模型把较早的对话整理成结构化摘要，同时保留最近内容。omp 的不同之处，是又尝试了 Snapcompact 这类不先改写原文的方案。
7. 第二天再来：它别又把项目忘得一干二净
今天跟 Agent 讲了三个小时：哪个接口不能动、哪个测试偶尔会失败、为什么上次没有选方案 B。
明天开个新会话，又得从头交代。
omp 的本地记忆默认关闭。启用并配置 memory.backend: local 后，它会从过去的持久化会话中提取项目事实，整理成摘要，在以后进入同一项目时注入上下文。
这套流程会跳过子 Agent 和没有保存到会话文件的临时会话，所以不能把它理解成所有 Agent 默认共享一份记忆。
记忆的难点从来不是存下来，而是什么时候该忘。
过期的接口、已经修好的临时问题、后来被推翻的决定，如果一直留着，Agent 会带着旧地图找新路。
Pi 的办法是人工维护 AGENTS.md。麻烦一些，但你知道里面写了什么。omp 自动得更多，也更需要让人看见它记住了什么、为什么还没删。
8. 团队规范：规则写了，Agent 还是会忘
团队会有很多硬要求：不能调用某个旧接口，改数据库前必须确认，生产代码不能用某种偷懒写法。
全塞进系统提示词，每一轮都要带上；写得太长，模型也未必始终照做。
omp 的**流式回溯规则（Time-Traveling Stream Rules，简称 TTSR）**平时不出现。当模型生成文字或准备执行操作时，一旦命中预先设好的条件，系统会中断当前输出，插入对应提醒，让模型重新生成。
相当于平时不唠叨，真要犯错时才拉一下。
这对能明确识别的坏习惯很有用，比如出现某个危险函数、执行某类命令。更复杂的架构判断和业务边界，靠关键词和固定模式识别不出来，仍然需要测试、审查和人来把关。
Pi 走的是明牌：规则写进系统提示词或 AGENTS.md，每轮都带着。笨一点，但你始终知道模型看到了什么。
9. 交付前：别把一堆杂乱修改直接扔给同事
Agent 改完代码，不等于工作结束。你还得看它有没有漏掉严重问题，改动是否能拆成清楚的提交，合并冲突有没有处理干净。
omp 把这几步也接了进来：
- 代码审查会把问题标成 P0 到 P3，附上置信度和是否可发布的判断，严重问题至少会更显眼；
- 一次改了几件事，可以拆成相对独立的提交；
- 遇到合并冲突，扫描后每个冲突块都有单独入口，可以逐块处理。
冲突扫描后，每个冲突块都有单独入口，可以逐块处理。
这些功能不保证审查一定正确，也不该替人按下发布按钮。它们解决的是另一种浪费：Agent 干得很快，最后人却花大量时间清理一团乱麻。
10. 换工具：以前写的规则别全部作废
Cursor、Claude Code、Codex、Cline、Copilot 都有自己的规则文件。
换一个 Agent，最烦的不是重新安装，而是过去积累的项目要求又要翻译一遍。
omp 会扫描 Cursor、Cline、Windsurf、GitHub Copilot 等工具留下的配置。
Cursor、Cline 和 Copilot 的规则有明确的导入路径，旧内容不必全部从头重写。
不同工具支持的规则并不完全一样，迁过来以后仍然要检查。至少不用从一张白纸开始。
这些能力，为什么不能只靠插件拼起来
从找入口、改文件，到调试、并行、长任务和最后交付，omp 把前后步骤接成了一条工作流。
关键不只是预装 31 个工具，而是让它们认识彼此的结果。
读文件留下的短标记，修改工具要能认；代码改完，代码智能和审查工具要能接着检查；为子 Agent 开启隔离时，还要把项目规则和任务约束带过去；长对话压缩之后，还得保住继续任务所需的信息；审查发现的问题，最后要能进入提交和冲突处理。
这些能力如果来自不同作者的插件，很容易各管一段：接口不一样、状态互相不认识，一个插件升级，另一个插件可能就失效。最后还是用户充当集成工程师，把它们粘在一起。
这也是 omp 需要从 Pi 分支、做成独立产品的原因。它赌的是：有些问题已经反复出现，解决办法也开始趋同，值得由同一个维护者做进底层，而不是让每个用户从头拼一遍。
用户不用为了完成一次像样的任务，先搭半天 Agent 工作台。这才是全家桶的意义。
这条路也有代价。
工具多，模型要学会什么时候用哪个。
不同模型、调试器、代码服务和记忆模块拼在一起，边界问题会更多。项目更新很快，今天好用的配置，下个版本可能需要调整。
GitHub 上开放 issue 和合并请求的数量变化很快，也不能直接当作 bug 数。不过在公开 issue 中，确实有用户报告过角色回退可能选错模型链、第三方插件安装后可能加载失败等问题。这些是用户提交的复现报告，不代表维护者已经逐项确认，也不代表当前版本仍然必现。
项目还年轻，版本和配置变化都很快，没到装一次就能安稳用一年的阶段。
两种路线，怎么选
看完这十个痛点，更稳妥的结论是：omp 替用户承担更多集成成本，Pi 把更多选择和维护留给用户。
Pi 的判断是，现在还没有一套适合所有人的 Coding Agent。工具不是越多越好，把底座做小，把选择留给用户，才方便继续试。
omp 的判断更激进：有些问题已经反复出现，继续让每个人从头搭一遍，只是在浪费时间。维护者应该把有效做法做进产品，并负责把它们接起来。
就产品方向而言，我更认同 omp：我打开 Coding Agent，是想把手头的活干完，不是先研究扩展市场，再维护一套私人底座。不过这只是我初步安装体验后对产品取向的选择，还不能证明 omp 在长期使用中一定更稳定、更省钱或完成任务更好。
但最佳实践写进产品，也会变成作者的偏见：什么时候检查代码、任务该怎么拆、哪些内容值得长期记住，都是维护者替用户做的决定。
因此 omp 也不能一直做加法。稳定、常用、能验证效果的能力可以内置；个人偏好强、变化快的工作流，应该留给扩展。否则豪华版继续堆下去，迟早也会变成一艘难以理解的“重型武器”。
