oh-my-pi：21K Star 的 Coding Agent，把 55,000 行 Rust 塞进你的终端

问题：其他 Coding Agent 都在"壳"外面绕

你用 Claude Code 或 Codex CLI 写代码时，有没有遇到过这些场景：

改一个函数，改到一半忘到九霄云外——跨会话没有记忆，每次重来
Agent 说"已修复"，但 diff 是错的——模型不擅长精确定位行号
前端 Bug 你让 Agent 修，它只能看源码——没有 LSP，不知道引用链
多任务并行时 Agent 互相踩脚——没有真正的子 Agent 隔离
想换模型，配置改到天荒地老——每个 Agent 都有自己的格式

这些问题的根因，在于大多数 Coding Agent 的 harness（工作框架）写得不够深——它们只是把 LLM API 包了一层 CLI，底层工具调用还是 fork/exec 外部进程（grep、find、bash）。

oh-my-pi（简称 omp）换了个思路：把底层工具全部用 Rust 内联到进程里，让 Agent 像一个真正有 IDE 经验的工程师一样干活。

它到底是什么

oh-my-pi 是 Pi（由 Mario Zechner / badlogic 创作）的 Fork 和深度进化版，由 Can Bölük 维护。它不是一个全新的 Agent，而是在 Pi 的地基上，把所有 Coding Agent 应该有的能力全部补齐。

核心数据：

21,019 Star，MIT 协议
~55,000 行 Rust 代码，编译成 N-API 插件嵌入 Node.js 进程
40+ LLM 提供商，覆盖 Anthropic、OpenAI、Google、xAI、MiniMax、Moonshot 等
32 个内置工具，覆盖文件、搜索、LSP、调试、子 Agent、浏览器等
TypeScript 主逻辑 + Rust 底层性能，两全其美

真正有用的 12 个能力

omp 的特性列表很长，但真正让 Coding Agent 体验质变的，是这几件事：

1. Hashline 编辑：让 Agent 永远改对地方

大多数 Agent 写代码时，会返回完整的「前后文 + 要改的内容」给 LLM，LLM 再返回一个 diff。但 LLM 经常把行号数错，或者你的文件刚好被人改过一行，整个 diff 就错位了。

omp 的做法是 hashline——用内容哈希锚点而不是行号来定位。模型只需要说"找到包含 function foo(x, y) 的那行"，omp 自动定位并应用修改。文件变动时锚点自动失效，拒绝应用错误的 patch。

实测效果：Grok 4 Fast 用 hashline 后，输出 token 减少了 61%，因为模型不用再重复输出它只想改那一行周围的内容。

2. LSP 直连：Agent 拥有 IDE 的全部知识

omp 把 LSP（Language Server Protocol）直接集成到工具链里。当 Agent 做 rename 操作时，它会走 workspace/willRenameFiles，自动更新所有引用—— barrel 文件、别名导入、导出重定向，全部同步。

你：把 formatBytes 改成 humanizeBytes
Agent：→ lsp rename formatBytes humanizeBytes
→ read format.ts 确认改动
→ read report.ts 确认改动
→ read cli.ts 确认改动
→ 5 处修改全部完成

这比你让 Agent 用 sed/regex 改要靠谱得多——LSP 知道你的代码结构，Agent 也就知道了。

3. 真实调试器驱动：不再 print 打天下

大多数 Coding Agent 遇到 Bug 的做法是让你加 console.log 或者 print。omp 的 Agent 可以直接驱动真实调试器（DAP）：

C 程序 segfault？Agent attach lldb，step 到出问题的指针，读栈帧
Go 服务 hang？Agent attach dlv，walk goroutine 看卡在哪
Python 进程卡死？debugpy pause，inspect，evaluate

你：这个 C 程序在 xorshift32 处崩溃
Agent：→ debug attach /tmp/demo
→ step to line 6
→ read variable x = 57351
→ "x went from 7 → 57351 (= 7 ^ (7<<13))，这是对的，崩溃在后续"
→ 继续调试...

3. 子 Agent 并行：task 工具

omp 有一个 task 工具，可以把一个大任务拆成多个子 Agent 并行执行，每个子 Agent 在自己的 workspace 里工作，互不干扰，最后聚合结果。

你：把这个功能拆成三个模块重写
Agent：→ task → 启动 3 个子 Agent
  → 子 Agent A：重写 auth 模块
  → 子 Agent B：重写 routes 模块
  → 子 Agent C：重写 utils 模块
  → 等待全部完成 → 聚合结果

子 Agent 的输出是 schema-validated 的结构化数据，主 Agent 可以直接读取字段，不需要从大段文本里解析。

4. Advisor 模式：第二个模型在看

omp 支持在同一个会话里跑两个模型——主模型负责干活，副模型（Advisor）负责读每一个回合的输出，发现问题时插入提示让主模型修正。

主模型（Grok 4 Fast）：我把错误处理改成吞掉所有异常
Advisor（Claude Sonnet）：⚠ 注意，这不符合用户之前的需求——用户明确要求错误要向上抛出
主模型：好的，我改回来，改用 try-catch + 日志

这个设计很像 Pair Programming——一个写，一个 review，实时交互。

5. 5 分钟记忆系统（Hindsight）

omp 的 Agent 有持久记忆，但不是靠 remember.md 文件。它用 SQLite 做本地存储，Agent 可以在运行中用 retain 工具写入关键事实，下次会话开始时用 recall 自动检索。

Agent：retain("项目使用 PostgreSQL，连接字符串在 .env")
Agent：retain("API 规范遵循 OpenAPI 3.0，详见 docs/api.yaml")

（下次会话）
Agent：recall("数据库连接配置")
→ 自动加载之前记住的事实

记忆是 project-scoped 的——这个项目记住的不会污染另一个项目。

6. GitHub 当文件系统用

omp 让 Agent 可以用 read pr://1428、read issue://99、search github:// 这样的路径直接读取 PR、issue、代码。不需要记住一堆 GitHub CLI 的参数，一个接口统一。

你：看看这个 PR 的 diff，告诉我能不能合
Agent：→ read pr://1428
→ /diff/1 读取第一个 hunk
→ 分析变更内容
→ "可以合，但有一个小问题：第 42 行的 import 没有用到"

7. 25 个搜索后端，一个 web_search 工具

omp 内置了 web_search 工具，背后挂了 25 个搜索引擎——Perplexity、Gemini、xAI、Exa、Tavily、Brave、Kagi、DuckDuckGo、Bing 等。你不需要一个个配，auto 模式会自动遍历。

更关键的是，它会把搜索结果的网页结构化提取成 Markdown——GitHub 页面、arXiv PDF、Stack Overflow、npm 文档，都能返回带锚点的结构化内容，Agent 可以直接引用和溯源。

8. 协作模式：一个链接，拉人入局

omp 有个 /collab 命令，把你的会话通过中继转发出去，生成一个链接和二维码。队友可以用 omp join 加入你的终端，或者直接在浏览器里看——只能看不能操作。

你：/collab
Agent：Collab session started!
→ omp join ws://relay.omp.sh/xxx
→ 二维码已生成

这是一个很适合 code review、结对编程的场景。

9. 自动导入已有配置

omp 会自动读取你电脑上已有的 Agent 配置——Claude Code 的 .claude/、Cursor 的 .cursor/、Windsurf 的 .windsurf/、Gemini 的 .gemini/、Codex 的 AGENTS.md、Copilot 的 .github/copilot/ 等。你之前配置好的规则和 skills，直接继承，不用迁移。

10. omp commit：原子提交，智能拆分

omp 内置了一个 omp commit 命令，它不会盲目地 git add -A && git commit。它会用 git diff 分析你的改动，把不相关的修改自动拆分成多个原子 commit，按依赖顺序排列。source 文件 > test 文件 > docs > config，lock files 不参与分析。

技术架构

omp 的架构分三层：

层级	技术	做什么
Rust 原生层	N-API + libuv	grep、bash shell、AST、高亮、PTY、图片解码——全部内联，零 fork/exec
TypeScript 运行时	Bun + Node.js	Agent 调度、工具编排、会话管理、LLM 客户端、记忆系统
TUI 层	TypeScript	终端 UI，工具调用卡片渲染、编辑预览、交互式选择器

Rust 部分 ~55,000 行，分四个 crate：pi-natives（核心 N-API 绑定）、pi-shell（嵌入式 bash/PTY）、pi-ast（tree-sitter AST 解析，支持 50+ 语言）、pi-iso（工作空间隔离，APFS clone / btrfs reflink / overlayfs）。

怎么接入

# macOS / Linux（推荐）
curl -fsSL https://omp.sh/install | sh

# Homebrew
brew install can1357/tap/omp

# Bun
bun install -g @oh-my-pi/pi-coding-agent

# Windows PowerShell
irm https://omp.sh/install.ps1 | iex

装完直接 omp 启动 TUI，omp -p "你的问题" 一次问答退出。

支持 Zed 编辑器集成（ACP 协议），可以直接在 Zed 里跑同样的 Agent——读的是你正在看的 buffer，写的是编辑器的保存路径。

和同类工具对比

工具	定位	omp 的优势
Claude Code	Anthropic 官方，TypeScript	omp 支持 40+ 提供商，不绑定 Anthropic
OpenAI Codex CLI	OpenAI 官方，TypeScript	omp 内置 LSP + DAP + 25 搜索后端，Codex 没有
Pi（原版）	Agent 框架，TypeScript	omp 是在 Pi 基础上加了 coding 全部能力
jcode	Rust harness，单二进制	omp 功能更完整（LSP/DAP/子Agent/记忆），jcode 主打极致轻量
Cursor / Windsurf	IDE 插件	omp 是终端优先 + Zed 集成，不绑定特定 IDE

实际体验的一些坑

Windows 支持还在追赶——macOS / Linux 体验最好，Windows 版有但文档相对少
配置项多——40+ 提供商、role 路由、fallback chains，初次上手需要花点时间
内存占用不算低——Rust 层虽然快，但 TypeScript 运行时 + 多个 LSP 进程起来后，内存占用和 Claude Code 差不多
社区还在积累——21K Star 增长很快，但 skill 生态和 Pi 相比还比较小
PR 开放测试期——目前 PR 是开放接受的试验期，之后可能恢复 vouch 制度

适合谁用

已经用 Claude Code / Codex CLI，但想要更多模型选择——换个 harness，不用换配置
需要 LSP + 调试器的 Coding Agent 工作流——omp 内置，不用额外配
想做多子 Agent 并行——task 工具原生支持，schema 校验输出
在意模型成本——hashline 编辑省 61% token，多个模型可路由到便宜的那一个
想用 GitHub 当文件系统——pr://、issue:// 直接读，比 CLI 方便

总结

oh-my-pi 是目前功能最全面的 Coding Agent harness 之一。它不是"又一个 Agent"，而是把 Pi 的灵活性和 Coding Agent 需要的全部基础设施（LSP、DAP、子 Agent、记忆、协作、搜索）整合到了一个项目里。~55,000 行 Rust 打底，让工具调用不再 fork/exec，21K Star 说明它在社区里已经找到了自己的位置。

如果你在找 Claude Code 的替代品，或者想让现有的 Agent 工作流多一个更强大的选择，oh-my-pi 值得一试。

项目地址：github.com/can1357/oh-my-pi · 官网：omp.sh