Oh My Pi

为什么选择 Oh My Pi？

Oh My Pi 面向喜欢终端智能体工作流，又不想放弃 IDE 级代码理解能力的开发者。

这一定位比工具清单有多长更重要。许多 CLI 编程智能体都能读文件、执行 shell 命令和应用补丁。OMP 更进一步，将语言服务器、调试器、浏览器自动化、智能体编排、持久执行内核、模型路由和代码库操作整合为统一的智能体能力。

因此，它不像只是给 shell 套了一层聊天界面，更像是把整套工程工作站直接交给智能体使用。

它的来源也解释了产品理念。OMP 源自 Pi，后者的吸引力在于小巧且可扩展的智能体内核；Oh My Pi 则向另一端发展：保留开放扩展机制，同时默认提供更多功能。对于原本需要花大量时间围绕极简框架组合插件、钩子、脚本和 MCP 服务器的进阶用户，这很有吸引力。

代价是复杂度。OMP 提供更多可调选项，需要认证的提供商更多，执行路径也更多。工作流确实需要时，这种灵活性很有价值；但如果只是想让模型改几个文件、跑测试，它就可能带来不必要的负担。

核心工作流程

高效的 OMP 会话通常从代码库开始，而不是从空白对话开始。

智能体可以利用项目上下文、现有规则、语言服务器状态、Git 历史、搜索和运行时工具，先理解代码库再修改。开始实现后，工作流可以在语义导航、文件编辑、shell 执行、诊断和调试器调查之间切换，而不只依赖文本搜索和编译器输出。

在涉及整个代码库的改动中，这一点尤其有用。

例如，要在多个包中重命名某个 API。纯文本智能体可以搜索符号并替换字符串，但遇到重新导出、别名、生成文件、重载或恰好同名的引用时，这种方法容易出错。OMP 的 LSP 工作流让智能体能够使用编辑器进行导航和重命名时所依赖的语义信息。

调试也是类似的思路。在语言生态支持 DAP 的情况下，智能体可以直接使用调试会话，而不用反复修改源代码添加日志。解决问题的过程由 edit, print, rerun 转向 reproduce, pause, inspect, reason, patch, verify，也就是先复现、暂停并检查状态，再推理、修复和验证。

大型任务中，主智能体不必将所有调查都放在一个上下文里。子智能体可以负责独立的研究或实现分支，隔离机制有助于减少编辑冲突。实际价值不只是并行，更在于上下文分离。依赖调查、失败测试分析、文档整理和实现任务，无需全部占用主智能体的工作上下文。

模型路由为什么重要

OMP 在 CLI 智能体中较为特别，因为它不将模型选择视为单一的全局设置。

按角色路由让不同工作可以分配给不同模型。较便宜的模型负责范围明确的子任务，推理能力更强的模型负责架构或疑难调试。独立顾问还可以在不同上下文中审查主智能体的工作。

这种架构有助于控制成本，但前提是配置与实际任务相匹配。

让昂贵的前沿模型负责每次搜索、分类、实现步骤和子智能体，配置简单、容易理解，却可能抵消编排带来的大部分成本优势。反过来，把重要实现任务交给能力不足的模型，也可能增加重试和无效工具调用。

因此，实用配置应有意识地分配模型角色：

• default 用于日常交互式实现。
• smol 用于低成本并行研究和范围明确的执行任务。
• slow 用于困难推理或调查。
• advisor 用于值得额外调用模型进行独立审查的场景。
• 如果编程质量足够，本地模型适合明确可预期、重视隐私或低成本的任务。

主要优势并不是能接入几十家提供商，而是能够构建模型能力与任务难度匹配的工作流。

OMP 与 Claude Code 的区别

Claude Code 和 Oh My Pi 承担的工作高度重叠：检查代码库、修改代码、运行命令、排查故障，以及完成多步骤工程任务。

区别主要在产品理念。

Claude Code 提供以 Anthropic 为核心的紧密集成体验。OMP 则刻意保持模型无关，并提供更广泛的路由层。开发者可以在 Anthropic、OpenAI、Gemini、xAI、网关、订阅式编程套餐和本地推理之间切换，无需重建周边编程工作流。

OMP 还特别重视 LSP、DAP、自定义执行环境、子智能体编排及可由用户扩展的内部机制。

因此，已经统一使用 Anthropic 的团队可能觉得 Claude Code 更简单。如果提供商独立性、本地模型、自定义智能体基础设施或多模型路由是核心需求，OMP 就更有吸引力。

OMP 与 Codex CLI 的区别

Codex CLI 和 OMP 都很适合终端驱动的开发。

如果工作流围绕 OpenAI 的编程模型和生态展开，Codex CLI 最直接。OMP 则更像通用框架，可以同时使用 OpenAI 和许多其他提供商。

对经常更换模型的用户，这一区别很重要。在 OMP 中，推理后端变化时，周边工具、会话机制、规则和编排策略可以保持稳定。

OMP 还通过扩展、RPC、ACP 和 SDK，将更多内部能力作为可编程平台开放。如果开发者要构建自己的智能体界面，或把编程智能体嵌入更大的自动化系统，这一点可能很有价值。

OMP 与 Aider 的区别

Aider 长期专注于终端编程助手，对于看重 Git 编辑工作流和较直接的模型到代码交互的人，仍有吸引力。

OMP 的智能体能力覆盖更广。

额外的语义代码理解、调试器集成、浏览器控制、持久求值、子智能体编排和可编程运行时，让它适合超出补丁生成范围的工作流。代价是更大的运维负担，以及变化更快的配置体系。

因此，两者之间的选择，不应只看是否都能修改代码，更应看期望采用的智能体运行方式。

Aider 适合需要专注编程、Git 工作流完善的助手的用户。OMP 则适合希望将终端智能体变成可编程工程环境的用户。

配置建议

面对高度可配置的智能体，人们往往想把所有功能都打开。但这通常不是最可靠的配置。

更好的方式是让主要执行路径保持精简，只有在解决反复出现的问题时才有意识地增加能力。

先配置一个可靠的默认模型和一个更便宜的执行模型。只有复杂任务需要时，再添加专门的慢速推理模型。如果独立审查的价值足以抵得上额外一份模型上下文的费用，再引入顾问模型。

语言服务器应针对代码库的主要语言配置。如果 LSP 总是初始化失败，只会增加延迟，无法提供语义价值。

MCP 服务器和扩展也适用同样原则。OMP 可以发现其他多个编程智能体生态中的配置，迁移时很方便；但自动继承多年积累的工具和规则，可能让环境出现意料之外的噪声。应审查发现的内容，不要默认所有导入的集成都应继续启用。

考虑模型隐私时，可以将不需要前沿模型质量的任务分配给本地后端。但敏感代码库仍需整体评估，因为即使主模型在本地，网页搜索、外部 MCP 服务器、扩展、协作功能或其他已配置服务仍可能产生网络通信。

本地模型与自带密钥策略

相比智能体循环默认依赖某家云厂商的工具，OMP 的本地模型支持更有用。

本地 Ollama、LM Studio、llama.cpp 或 vLLM 部署可以成为同一工作流中的另一个后端。这适合重复的代码库查询、私密实验、离线开发，或更重视 token 成本而非最高模型质量的任务。

不过，本地并不自动意味着更好。

编程框架要求模型可靠调用工具、遵循结构约束、保留上下文并精确编辑。较小的本地模型可能需要更多重试，或给出较弱的计划。如果不断执行失败，便宜的 token 最终也可能让任务成本变高。

合理的策略是在任务层面评估模型，而不是只看基准分数。如果小型本地模型能可靠地搜索代码、总结文件或执行范围明确的子任务，即使无法主导整个代码库会话，也可能是合适的执行模型。

迁移建议

对工作站上已经散落着各种编程智能体配置的开发者，OMP 尤其友好。

其发现层可以从多个生态读取规则、上下文、技能和相关配置，不要求立即转换为专有格式。这降低了在现有智能体旁边试用 OMP 的门槛。

不过，迁移应当是一次审查，而不是盲目导入。

为 Cursor 编写的规则可能假设存在编辑器上下文。面向 Claude 的指令可能依赖 Claude 专属行为。MCP 服务器可能与 OMP 内置工具重复。旧项目说明也可能与较新的 AGENTS.md 文件冲突。

清晰的迁移流程可以是：

1. 在有代表性的代码库中启动 OMP。
2. 检查发现了哪些规则、技能、MCP 服务器和上下文文件。
3. 删除重复项和过时指令。
4. 明确选择模型角色，避免无意中沿用提供商默认设置。
5. 先完成几项常规开发任务，再启用复杂编排。
6. 只有简单工作流暴露出实际需求时，再添加子智能体、顾问模型、记忆、浏览器自动化或自定义扩展。

这种方式保留了 OMP 的主要优势之一——与现有智能体生态兼容，同时避免让历史配置变成看不见的技术债。

OMP 适合的使用场景

代码库级重构

当改动跨越包、符号和依赖边界时，基于 LSP 的导航与重命名可能比纯文本编辑更可靠。

疑难调试

DAP 集成让智能体可以直接检查运行时状态，而不必只依赖日志和测试输出。

多模型工程开发

使用多家 AI 提供商的团队或个人，可以保留同一编程框架，将不同任务路由到不同后端。

并行调查

子智能体可以将研究、调试、实现和审查的上下文分开，由主智能体统筹结果。

智能体平台开发

SDK、RPC 模式、ACP 支持、扩展、技能和自定义工具，让 OMP 不仅适合手动交互，也适合希望基于智能体继续开发的开发者。

实际取舍

OMP 最大的优点和缺点其实相同：能力覆盖面很广。

项目尝试把几乎所有实用的工程能力放进一个终端智能体。这减少了拼接独立工具的需要，但也意味着更多配置、更多运行组件，以及提供商、插件、语言服务器、工具和权限之间更多潜在交互。

发布节奏进一步放大了这一取舍。OMP 迭代快，用户能迅速获得新能力；但面向生产的团队应固定版本并审查更新日志，而不是假设每次更新都不会影响运维。

提供商独立性也需要有序管理。一次会话可能涉及主模型、便宜的执行模型、顾问、网页搜索提供商、图像或语音服务，以及外部 MCP 工具。这种灵活性很强，但成本和隐私取决于整个已配置工作流，不只是状态栏中显示的模型。

选型指南

如果开发者已经清楚自己为什么需要超越简单编程聊天机器人的工具，Oh My Pi 最有吸引力。

当终端交互、语义代码理解、调试器访问、模型提供商独立性、本地推理、子智能体和可编程能力在同一工作流中都有实际价值时，可以选择它。

如果工作主要是 edit these files and run the tests，也就是改文件并运行测试，更简单的 CLI 智能体可能更合适。如果图形化差异审查、行内补全和可视化工作区集成比终端自动化更重要，AI 原生编辑器可能更好。

OMP 位于两者之间：一个越来越同时具备 IDE 和智能体框架特征的 CLI 智能体。