別再被複雜框架綁架：pi-mono 回歸直覺的 TypeScript AI Agent 開發框架

如果你最近在看開源 AI coding agent，badlogic/pi-mono 這個 repo 很容易被誤判。第一眼看上去，它像是另一個 terminal 裡的 AI 助手；但我實際把 README、pi-coding-agent 文件、providers 文件和 changelog 讀完之後，我的感覺是：Pi 真正想做的，不是一個更花俏的聊天 CLI，而是一個把 agent runtime、模型抽象層、終端介面與可擴充工作流包在一起的開發者底座。

截至 2026 年 5 月 2 日，badlogic/pi-mono 在 GitHub 約有 43,777 stars，最新 release 是 v0.72.1，而且過去幾天都還在高頻更新。這種節奏代表兩件事：一方面它不是冷門實驗品，另一方面它也還處在快速演化期。所以我不會把 Pi 看成一個「穩定到像既有 IDE 一樣」的成品，而會把它看成一個非常有方向感的 agent toolkit。

如果你要找的是一個開箱即用、把所有工作方法都替你決定好的產品，Pi 不一定最適合；但如果你在意的是 agent CLI 可不可以延伸成自己的工具鏈、可不可以接不同模型、可不可以把 workflow 做成 package、skill 或 extension，那它很值得仔細研究。我認為這個專案目前最值得注意的地方，可以先拆成 5 個產品判斷。

1. 它不是單一 CLI，而是一個 agent toolkit 的 monorepo

Pi 的 repo 首頁沒有把自己包裝成「一個超強的 AI 終端」，而是很直接列出 5 個 package：

@mariozechner/pi-ai
@mariozechner/pi-agent-core
@mariozechner/pi-coding-agent
@mariozechner/pi-tui
@mariozechner/pi-web-ui

這個訊號很重要。因為它說明 Pi 的核心價值不只在最上層那個 CLI，而在於它把模型層、agent runtime、terminal UI、web UI 都拆成可組合的模組。這和很多「只有一個 CLI binary」的 agent 工具不一樣。

對我來說，這種結構的真正價值是：如果你最後不想只用官方預設介面，你不需要整個 fork 掉再重做。你可以只拿其中幾層，例如保留 pi-ai 的模型統一層，或保留 pi-tui / pi-web-ui 的介面能力，再把自己的 agent workflow 接上去。

也就是說，Pi 從一開始就不是把自己定義成單點產品，而是比較接近agent 開發底層套件集合。

2. 它主打的是可擴充工作流，不是內建一切

pi-coding-agent README 的一句話很能代表它的產品哲學：adapt pi to your workflows, not the other way around。官方做法不是把所有熱門功能都硬塞進核心，而是把擴充點留得非常前面，例如：

Skills
Prompt Templates
Extensions
Themes
Pi Packages

這個方向我認為非常務實。因為現在很多 agent 工具一開始都想做大而全，最後常見結果是：你可以 demo 很多功能，但真的進團隊之後，每個人都得和工具的預設流程妥協。

Pi 的路線剛好相反。它先把核心保持小，然後把「你想怎麼工作」這件事交給 skill、extension 或 package。這樣的好處是彈性高；代價則是你不能期待它像消費級產品一樣幫你把所有默認決策都做好。

所以如果你問我 Pi 的解法是什麼，我會說它解的不是「怎麼再做一個更會聊的 agent」，而是「怎麼讓 agent harness 變成可以被你重組的工作層」。

3. 它對模型與供應商的抽象做得很完整

Pi 目前支援的模型來源很多，包含訂閱型登入和 API key 路線。以 2026 年 5 月 2 日的文件來看，它支援：

ChatGPT Plus 或 Pro
Claude Pro 或 Max
GitHub Copilot
OpenAI、Anthropic、Gemini、Bedrock、OpenRouter、Groq、Mistral、Cloudflare 等 API key provider

而且它不是只停在「支援很多家」而已。官方還提供 ~/.pi/agent/models.json 讓你加自訂 provider 或 model，對 OpenAI-compatible、Anthropic Messages、Google Generative AI 這些 API 類型都有明確抽象。這點很關鍵，因為很多團隊不是沒有模型，而是沒有一個足夠乾淨的切換層。

我特別在意這一點，是因為真實世界的 agent 導入通常不會永遠鎖在一個 provider。你今天可能想用官方 OpenAI，明天可能改走 Bedrock、Cloudflare gateway、Ollama、vLLM 或公司內部 proxy。如果 CLI 或 agent runtime 對供應商綁得太死，後面你會花非常多時間重做整個堆疊。

Pi 在這裡的價值，不是告訴你哪個模型最強，而是提供一個相對一致的模型接入口。

4. 它刻意不內建某些熱門功能，這不是缺點，而是立場

Pi 的 Philosophy 寫得很直白：它沒有內建 MCP、沒有內建 sub-agents、沒有 plan mode、沒有 permission popups、沒有 built-in to-dos。很多人看到這裡第一反應會是「是不是功能不完整」，但我反而認為這是它最值得讀的地方。

因為這代表作者不是做不到，而是刻意把這些東西留在外層處理：

要 sub-agents，你可以用 extension 自己做
要 plan mode，你可以寫成檔案或擴充功能
要 permission flow，你可以依自己的安全模型設計
要 MCP，你可以自己加支援層

這種選擇背後其實是一個很強的產品判斷：agent 工具真正該穩定的，是核心 runtime 和擴充邊界，不一定是每一種使用方法的官方實作。

這個判斷當然不是每個人都會喜歡。對想要即刻上手的人來說，它的確比較不友善；但對想把 agent 變成團隊基礎設施的人來說，這反而是很大的優勢。因為你的 workflow 不需要等官方 roadmap，同樣也不必被官方 roadmap 綁住。

5. 它的重點不是「像誰」，而是能不能成為你自己的 agent 平台

Pi README 裡甚至直接提到，你可以用 extension 讓它看起來像 Claude Code，也可以加遊戲、加自訂 UI、加 MCP、加自訂 provider、加自訂工具。這句話很有代表性，因為它反映的不是單一產品功能，而是Pi 把自己當作平台，而不是唯一正確的體驗。

我覺得這也是 Pi 和很多熱門 coding agent 最大的差別。多數產品想做的是「最好用的那一個既定體驗」；Pi 比較像在說：「我先給你一個可運作核心，剩下你自己決定。」

這樣的設計會讓 Pi 對兩種人特別有吸引力：

想打造自家 agent workflow 的工程團隊
想研究 agent product design，而不只想找現成 CLI 的開發者

如果你只是要一個越少設定越好的 coding assistant，Pi 不一定是第一選擇；但如果你想做的是自己的 agent 平台或團隊工作底座，Pi 的價值就會開始放大。

怎麼開始用 Pi？我建議先做這 4 步

如果你想判斷 Pi 到底適不適合你，我不建議一開始就研究 extension API 或 package system。比較好的做法，是先跑一條最短的驗證路徑：裝起來、選模型、做第一個任務、確認 session 與擴充入口都說得通。

第 1 步：先把 `pi-coding-agent` 裝起來

官方 quick start 很直接：

npm install -g @mariozechner/pi-coding-agent

前置條件是 Node.js >=20.6.0。如果你只是想快速確認 Pi 的互動方式，這一步就夠了。它不需要你先讀完整個 monorepo，也不用先理解所有 package 關係。

第 2 步：先選一條認證路徑，不要同時開太多 provider

Pi 提供兩條主要路線：

直接用訂閱登入：/login
用 API key：例如 OPENAI_API_KEY、ANTHROPIC_API_KEY

如果你是第一次試，我建議先只選一條，避免把「工具好不好用」和「provider 設定是否正確」混在一起。官方文件也提到，你可以在互動模式用 /model 切換模型，或把可輪換模型範圍限制在常用清單內。

對多模型使用者來說，這一步最有價值的地方不是模型清單有多長，而是你不需要換一個 CLI 才能換一個 provider。

第 3 步：用一個可以驗證的任務測互動模式

啟動方式很單純：

pi

第一次不要只輸入「你好」，而是直接丟一個可以驗證結果的任務，例如：

幫我整理目前 repo 的檔案結構
幫我讀 README 並列出 3 個核心模組
幫我比較這個專案的 skill 與 extension 差異
幫我找出哪些檔案是 provider 設定的入口

這類任務的好處是，你很快就能確認 Pi 的基本工具模型是否符合你的期待。根據官方 README，Pi 預設會給模型 read、write、edit、bash 四種工具。對 coding agent 來說，這組預設其實已經夠你看出它的工作方式。

第 4 步：再往下看 sessions、skills 和 packages

如果前面都順，我下一步會測三件事：

pi -c 或 /resume 的 session 延續是否符合習慣
/skill:name 與 skill 載入機制是否好用
pi install / pi list / pi update 這條 package workflow 是否夠乾淨

這是因為 Pi 真正的差異化，不在第一輪對話，而在你能不能把第二輪、第三輪、長期 workflow 都積起來。session tree、skill commands、package 安裝與更新，才是它作為 agent 平台的長期價值所在。

Pi 的限制與現實邊界

Pi 很值得看，但我不會把它寫成萬能解答。它至少有幾個明確邊界。

第一，它的抽象層很多。對進階使用者來說這是優勢，對只想快速完成任務的人來說則是負擔。

第二，它的產品哲學很強。像「不內建 sub-agents」「不內建 plan mode」這種決策，會讓一部分人覺得乾淨，也會讓另一部分人覺得少了安全感。

第三，它更新很快。從 2026-04-28 到 2026-05-02，release 已經從 v0.70.6 走到 v0.72.1。高迭代速度代表活力，但也代表你要接受設定、文件和概念持續變化。

第四，它比較像 builder-oriented 產品，不是 team-wide 標準化產品。也就是說，它更適合懂得自己要什麼的工程團隊，而不是所有人一裝就能用得很順的通用工具。

Pi 比較適合誰先試？

如果你屬於下面幾類，我認為 Pi 很值得試：

想把 coding agent 從單一工具升級成可擴充平台的工程團隊
需要在多模型、多供應商之間切換的使用者
想把 skills、prompt templates、extensions 包成可重用 workflow 的團隊
正在研究 agent product architecture，而不只是在找一個能寫 code 的 CLI

反過來說，如果你現在最在意的是：

極低學習成本
固定且高度產品化的體驗
少設定、少抽象、馬上能用

那 Pi 可能不是你最順手的起點。

結語

我看 Pi 的核心感想是：它不是在競爭「誰比較像某個既有 AI coding 工具」，而是在競爭「誰能更早成為可被重組的 agent 平台」。

這個方向比較難，因為它不只要回答模型怎麼接、工具怎麼用，還要回答 workflow 怎麼擴充、package 怎麼分發、session 怎麼延續、provider 怎麼抽象。但也正因為它把這些問題放進同一個設計裡，Pi 才不像另一個只會聊天的 CLI，而更像一個給開發者搭自己的 agent 系統用的底座。

如果你只想找一個更方便的 AI 終端，Pi 也許不是第一順位；但如果你在找的是能不能從 CLI 長成平台的那條路，它非常值得看。

參考資料