这是「omp 编程工具使用探讨」专栏的第 1 篇。专栏记录我用 omp 作为主要编程工具的实战经验：架构理解、Rules 与 TTSR、Skill 工程化、多 agent 协作。
一句话定位
omp（Oh My Pi）是一个跑在终端里的 AI 编程助手，fork 自 badlogic/pi-mono，可以理解成 Cursor / Windsurf 的 CLI 版本。你在终端跟 AI 对话，它能读写文件、执行命令、搜索代码、浏览网页——一个把”对话即编程”做到极致的命令行工具。
它在工具坐标里的位置
把它和熟悉的工具摆在一起对比会更清楚：
| 维度 | Cursor / Windsurf | Claude Code | omp | GitHub Copilot CLI |
|---|---|---|---|---|
| 形态 | IDE | 终端 | 终端 | 终端（一次性） |
| 会话状态 | 项目感知 | 长会话 | 长会话 + session tree | 无状态 |
| 工具调用 | 内嵌 | 内嵌 | 内嵌 + 自定义工具 | 受限 |
| 规则系统 | .cursor/rules | CLAUDE.md | 多格式兼容 + TTSR 实时中断 | 无 |
| 多 agent | 部分（Composer） | 子任务 | swarm 扩展 | 无 |
| 扩展机制 | 插件 | MCP | MCP + 插件 + skill | 无 |
omp 的差异化主要在三处：TTSR 实时中断（agent 输出到一半能被规则打回）、Skill 工程化（把工作流固化成可复用知识）、多 agent 协作（一个 session 调度多个子 agent）。这三点正是这个专栏后续要展开的主题。
技术栈速览
- 运行时：Bun（>=1.3.7）
- 主语言：TypeScript
- 性能层：Rust（通过 N-API 暴露给 TS，差异渲染、字符串处理等热路径走 native）
- Lint/Format：Biome
- 包管理：Bun workspaces（monorepo）
monorepo 大致结构：
oh-my-pi/├── packages/│ ├── coding-agent/ 主包，CLI 入口 (bin: omp)│ ├── ai/ 统一 LLM 客户端│ ├── agent/ Agent 运行时│ ├── tui/ 终端 UI│ ├── natives/ Node native 绑定│ └── swarm-extension/ 多 agent 协作扩展└── crates/ └── pi-natives/ Rust cdylib记不住没关系——专栏里会按需展开。你只需要记住一个入口：omp 这个命令。所有会话、工具、规则、扩展都从这个命令进入。
为什么我想专门写一个专栏
我已经把这个博客本身做成了”AI-Agent-native”——站点定位里就这么写的。意思是：博客的主要创作者不是我，而是 omp 这个 agent。人类（我）负责方向、判断和品味；agent 负责执行：写代码、改样式、调 bug、部署、写文章。
这种工作方式跑了几个月后，我攒下不少经验值得整理：
- Rules / TTSR 怎么写才不啰嗦又不漏
- Skill 怎么抽象才不会被 agent 误触发或漏触发
- 多 agent 什么时候用，什么时候反而比单 agent 慢
- approval mode（auto-edit / full-auto / ask）怎么按任务选
- 跟 Cursor / Windsurf 比有哪些真实取舍
这些零散笔记凑成博客文章都太单薄，但串成连载正好。这也是这个专栏的由来——用博客本身验证”AI agent 当主要创作者”是否可行。
这个专栏会写什么
预计的文章（顺序可能调整）：
- omp 是什么（本文）
- Session 与会话树：长任务怎么不丢上下文
- Rules 入门：把项目约束写成 agent 能读懂的规则
- TTSR 实时中断：让 agent 输出到一半自动回头
- Skill 工程化：从一次性 prompt 到可复用知识
- 多 agent 协作：swarm 扩展的使用与陷阱
- Approval modes：auto-edit / full-auto / ask 的选择策略
- 与 Cursor/Windsurf 的真实对比
每篇都会带可复现的真实案例——多半就来自这个博客本身的开发记录。
怎么跟上这个专栏
- 访问 专栏目录页 看所有已发布文章
- 在文章底部的「上一篇 / 下一篇」按发布顺序通读
- 关注
omp标签获取相关零散笔记
下一篇我们会拆开 omp 的 session 机制：为什么它的会话可以跑几个小时不丢上下文，以及 session tree 怎么让长任务可回溯。