oh-my-pi：一個終端優先的 AI 編碼代理
用於終端的 AI 編碼代理、哈希錨定編輯、最佳化的工具工具、LSP、Python、瀏覽器、子代理程式等。
秒懂
- 它是什麼？
- 從 Pi 分叉的開源終端編碼代理，內建 31 個工具、提供方路由和 Rust 核心。
- 適合誰用？
- oh-my-pi 以 MIT 授權發布，原始碼在 GitHub 上，文件在 omp.sh。 對這個專案的判斷應以 README 中的實際入口為準：先按文件執行專案命令，再檢查產生的設定、服務狀態或輸出是否符合預期；若核心依賴、平台條件或文件未涵蓋的部署細節不合適，就不應只因功能清單完整而採用。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
這是什麼及其來源
oh-my-pi 是一個終端編碼代理，從 Mario Zechner 的 pi-mono 專案分叉而來。README 將其描述為 Pi 的分叉，重寫為以編碼為先的介面。該倉庫使用 TypeScript 和 Rust 編寫，執行在 Bun 上，README 列出了 60 多個受支援的提供方、31 個內建工具、14 個 LSP 操作、28 個 DAP 操作，以及大約 80,000 行 Rust 核心程式碼。該專案採用 MIT 授權，版權歸 Mario Zechner 和 Can Bölük 所有。
安裝與執行模式
安裝方法在 macOS 和 Linux 上透過 curl 腳本、Homebrew、Bun、Windows PowerShell 和 mise 均有文件說明。README 指出 Alpine 和 musl 使用者需要先安裝 libstdc++ 和 libgcc。bash、zsh 和 fish 的 shell 補全由即時 CLI 元資料產生。代理以四種模式執行：互動式 TUI（omp）、單次提示（omp -p）、嵌入式 Node SDK、RPC 模式（omp --mode rpc）以及 ACP 模式（omp acp），後者透過 JSON-RPC 使用 Agent Client Protocol。具體指令在 README 中。
31 個內建工具
工具表面按類別組織：檔案和搜尋、執行時、程式碼智慧、協作、桌面與網頁、記憶體與技能。值得注意的工具包括 read、write、帶 hashline 錨點的 edit、用於結構重寫的 ast_edit、用於 IDE 操作的 lsp、用於 DAP 會話的 debug、用於並行子代理的 task、用於 Puppeteer 的 browser、用於主機桌面控制的 computer，以及 web_search。README 還描述了時間旅行流規則，在 token 中間注入約束，以及一個顧問模型來審查每一輪。大多數工具與 read 和 bash 位於同一命名空間，部分工具位於 xd:// 裝置後面。
提供方與模型路由
README 列出了超過 60 個提供方，包括前沿 API、編碼計劃以及本地伺服器。十個角色按意圖路由工作，包括 default、smol、slow、plan 和 advisor。模型可以在會話中透過 /model 切換，並在啟動時透過 --smol、--slow 或 --plan 覆蓋。自訂 OpenAI 相容提供方可以在 ~/.omp/agent/models.yml 中宣告，並描述了回退鏈、路徑作用域模型集和輪詢憑證作為設定選項。web_search 工具連結了 23 個提供方，並將來自程式碼託管、套件登錄、研究來源和文件的頁面轉換為結構化 markdown。
Rust 原生核心
README 指出，大約 80,000 行 Rust 核心程式碼分佈在九個 crate 中，另外還有 77,000 行 vendored 程式碼。搜尋、shell、AST、語法高亮、PTY、桌面控制、影像解碼和 token 計數都在 libuv 執行緒池上程序內執行，避免了熱路徑上的 fork/exec。shell 基於 vendored 的 brush 分叉，jq 和 46 個 uutils coreutils 編譯在內。平台支援包括 macOS、Linux 和 Windows，x64 二進位同時提供 AVX2 和基線版本。
可擴充性與授權
擴充是 TypeScript 模組，使用與內建工具相同的工具 API、斜線指令登錄表和 TUI 原語。首次執行時，代理會從 .claude、.cursor、.windsurf 和 .github/copilot 等現有目錄匯入規則、技能和 MCP 伺服器。記憶體工具如 retain、learn、recall 和 reflect 可透過本地、Hindsight 或 Mnemopi 後端進行設定。該倉庫採用 MIT 授權，授權文字說明軟體按原樣提供，不提供任何擔保。
針對 can1357-oh-my-pi，閱讀 README 時應把安裝入口和日常使用入口分開看。先確認文件點名的執行檔、套件管理器或容器命令，再對照專案要求的作業系統、執行時版本與外部服務。這些前置條件會直接決定首次啟動能否成功，不能用其他專案的慣例代替。
配置層面的重點在於找出 can1357-oh-my-pi 真正讀取的檔案與參數。若 README 提到環境變數、設定檔、資料目錄、插件或 provider，就應逐一記錄其名稱和預設值，並觀察啟動後產生的日誌與輸出。文檔沒有交代的默認行為，應視為未知，尤其不能自行推定安全性、持久化或相容性。
從維護角度看，can1357-oh-my-pi 的功能清單不等於完整的營運承諾。需要實際檢查 README 列出的版本、依賴、資料格式和錯誤處理，確認升級時哪些狀態會被保留，哪些整合需要額外憑證。若要放入團隊流程，還要先確認其授權文字對分發、修改和商業使用的具體限制。
最小驗證可以沿用 can1357-oh-my-pi 自己提供的命令與檔案：在乾淨目錄建立最小設定，執行文件中的初始化或啟動命令，再查看 README 指定的輸出、狀態頁、產物或日誌。測試至少涵蓋一次成功流程與一次缺少必要參數的失敗流程，這樣才能分辨功能存在與實際可操作之間的差距。
can1357-oh-my-pi 的實際價值還取決於它如何處理日常變更。可以先改動一個 README 明確列出的選項，觀察重載、重新建置、快取失效或資料更新是否符合說明，再恢復原設定確認狀態沒有留下難以察覺的副作用。對需要網路、資料庫、瀏覽器或模型服務的專案，這個步驟也能把程式本身的問題與外部依賴故障區分開。
若 can1357-oh-my-pi 要交給其他人使用，交接內容不能只包含安裝命令。還要記下入口命令的完整參數、需要提交的設定檔、敏感值的存放位置、失敗時應查看的日誌，以及 README 明確列出的不支援情況。這些資訊會影響排障時間，也能避免使用者把社群版、實驗性功能或本地限定能力誤當成穩定服務。
在 can1357-oh-my-pi 的評估中，輸入與輸出的可追蹤性比功能數量更值得核對。保留一次命令執行的參數、產生的檔案名稱和關鍵日誌，才能在重跑時知道差異來自設定、依賴還是資料。若 README 沒有給出某項能力的介面或結果格式，文章只把它列為未說明，不替專案補上承諾。
部署 can1357-oh-my-pi 前也要核對資源與權限邊界。把 README 寫明的資料庫、網路、檔案系統和第三方帳號需求列成清單，逐項確認最小權限是否足夠，並把失敗時的返回值與日誌保存下來。這樣才能判斷它適合個人試用、團隊內部流程，還是需要更完整的運維審查。
採用前可在 can1357-oh-my-pi 的工作目錄執行 README 所列入口，逐項核對輸入、產物與錯誤訊息；文檔沒有承諾的行為不應當作既定能力。
編輯結論
oh-my-pi 以 MIT 授權發布，原始碼在 GitHub 上，文件在 omp.sh。 對這個專案的判斷應以 README 中的實際入口為準：先按文件執行專案命令，再檢查產生的設定、服務狀態或輸出是否符合預期；若核心依賴、平台條件或文件未涵蓋的部署細節不合適，就不應只因功能清單完整而採用。
社群筆記