Pi 把 coding agent 的核心縮到四個預設工具、一份可讀的 system prompt,以及能自由替換的模型與擴充層。這個設計確實讓 DeepSeek 等模型更容易接入,也讓開發者看得見 context 裡放了什麼。不過,網路流傳的 30 題 benchmark 無法單獨證明「prompt 越短,agent 越強」:測試使用的是功能大幅擴充的 Oh My Pi,原始報告也尚未出現在 Composio 可查核的官方資料中。
先給結論:Pi 值得試,尤其適合想掌控模型、context 與工具的人。選它的理由應該是透明、可塑、跨模型和 session 設計,而不是一張缺少完整方法的排行榜。
Pi 是什麼
Pi 是 Mario Zechner 發起、現由 Earendil 維護的開源 terminal coding harness。官方選擇「minimal agent harness」作為定位:提供一組可運作的 primitives,再讓使用者透過 TypeScript extensions、skills、prompt templates、themes 與 packages 加上自己的工作流。
截至 2026 年 8 月 12 日,官方 repository 採 MIT License,GitHub API 顯示約 8.76 萬個 stars。安裝後可在同一個 session 中切換 Anthropic、OpenAI、Google、Mistral、xAI、Kimi、MiniMax、OpenRouter、Ollama 等 15 個以上的 providers,也能透過 models.json 接入相容端點。
最短安裝方式是:
curl -fsSL https://pi.dev/install.sh | sh
或使用目前的 npm package:
npm install -g --ignore-scripts @earendil-works/pi-coding-agent
Pi 的預設工具仍是 read、bash、edit、write。目前原始碼裡的 system prompt 會列出可用工具、兩條通用行為準則、Pi 文件位置與工作目錄;專案中的 AGENTS.md、skills 與自訂 prompt 會再動態加入。因此「很短」是合理描述,「固定只有幾百 tokens」則不精確,實際長度會隨工具、專案指令與 skills 改變。

真正有價值的是可看見、可替換
許多 agent harness 會把大量產品決策包進看不見的 system prompt、工具描述與 orchestration。這些設計可能提高預設成功率,也可能跟特定模型、專案規則或使用者要求互相打架。Pi 的選擇是把控制權留在本機。
這帶來四個實際好處。
第一,模型切換不必重開對話。輸入 /model 或按 Ctrl+L,可以在保留 session context 的情況下換 provider。跨模型 handoff 仍有格式轉換與 reasoning trace 相容性的限制,但 Pi 至少把這件事當成一等功能。
第二,session 以樹狀結構儲存。用 /tree 可以回到任何較早的訊息分支,從那裡繼續,而不是讓錯誤嘗試永久污染後續 context。所有分支留在同一份 session file,也能匯出 HTML 或分享 gist。
第三,複雜度是選配。Pi 核心沒有內建 MCP、subagents、plan mode、to-do manager 或 background bash;需要時再裝 package,或自己寫 extension。這能避免低頻功能一直佔用 prompt 與 UI,也把維護責任交回使用者。
第四,interactive TUI、print/JSON、RPC 與 SDK 共用同一套核心。個人可以在 terminal 裡操作,團隊也能把同一個 harness 放進 scripts、CI 或自己的介面。

那張 30 題 benchmark 有兩個缺口
流傳中的說法是:Composio 使用同一個 DeepSeek V4 Flash,分別搭配 Claude Code、Codex、OpenCode 與 Oh My Pi,跑 30 個 agentic tasks;Oh My Pi 完成 17 題,Claude Code 與 Codex 各 16 題,OpenCode 14 題。圖表還列出每題中位時間與成功題目的成本。
這組數字目前不適合當成定論。
第一個缺口是可追溯性。截至本文查核時間,在 Composio 官網、官方 GitHub 與可搜尋內容中,都找不到對應的 30 題報告、task list、commit、harness 版本、完整 log、失敗分類或 verifier。能查到的 Composio 近期官方研究,是另一組 31 題 SaaS 測試:MiniMax M3 加 Composio 與 Opus 4.8 加原生 MCP 都完成 26 題。那份研究確實支持「tool layer 會影響 agent 表現」,卻不是影片描述的 Pi 對決。
第二個缺口是變因沒有隔離。測試對象是 Oh My Pi;vanilla Pi 並未參與。Oh My Pi 的官方 README 列出 31 個內建工具、14 種 LSP 操作、28 種 DAP 操作、約八萬行 Rust core,還包括 hash-anchored edits、browser、subagents、debugger、persistent Python、逐模型 prompt 調校與不同的 tool surface。它保留 Pi 的 lineage,卻已經是一套「batteries included」產品。
因此,就算 17/30 完全正確,也只能說那個版本的 DeepSeek、Oh My Pi、工具、prompt、task set 與 verifier 組合,在那次測試中完成最多題。它無法把勝因單獨歸給 system prompt 長度。
Claude Code 縮短 80%,也不是通用證明
另一個常見論點是:Claude Code 已刪掉約 80% system prompt,表現沒有下降,所以長 prompt 原本都是多餘的。
Anthropic 團隊公開談話提供了更細的版本。2026 年 7 月,Claude Code 團隊的 Cat Wu 與 Thariq Shihipar 表示,Fable 與 Opus 4.8 等前沿模型的 system prompt token 數縮減約 80%。團隊移除許多 examples、硬性「不要做」規則與過度約束,並透過內外部 evals 避免退步。
同一段談話也明確補充:Claude Code 現在依模型使用不同 system prompts;只有較前沿的模型採用 80% 縮減,舊模型仍保留完整版本。團隊甚至坦言,讓較強模型替較小模型產生更詳細指令這件事,還沒有足夠 hard data。
這個細節很重要。Anthropic 的經驗支持「prompt 應隨模型能力調整」,不等於「越便宜的 open model 越需要更短的 prompt」。較小模型可能需要更明確的 examples、驗證規則與 tool schemas;較強模型則可能被同一套細則綁住。
Harness 本來就是模型的一部分
影片有一個核心觀察是對的:harness 並非中性的水管。
模型看到的 tool name、schema、description、error message、file snippet、diff format、context order、compaction summary 與 retry policy,都會改變下一步決策。System prompt 只是其中一層。Oh My Pi 自己展示的 uplift,也把原因放在 edit format、LSP、讀取摘要與逐模型 prompts,而非單純刪字。
比較兩個 harness 時,至少要控制以下變因:
| 變因 | 為什麼會影響結果 |
|---|---|
| 模型與 provider | 同名模型可能有不同 context、reasoning 與 tool-call 相容設定 |
| System prompt | 規則、examples 與優先順序會改變策略 |
| Tool schema | 參數是否清楚、能否 batch,直接影響 call 成功率 |
| Edit format | patch 失敗與重試會消耗時間、tokens,也可能破壞檔案 |
| Context policy | 截斷、摘要、cache 與 branch history 會改變模型看到的證據 |
| Runtime 與 verifier | timeout、sandbox、依賴與驗收方式決定「成功」的定義 |
要證明「短 prompt」是主因,合理的方法是先固定同一個 harness、tools、task set 與模型,只改 system prompt,再跑足夠次數並公開逐題結果。跨四套產品比較可以回答「整套 stack 誰做得好」,不能回答某一個 component 為何勝出。
Pi 最適合哪一類使用者
Pi 適合把 agent 當成可組裝開發環境的人。
- 經常切換模型或自架端點,希望 session 不跟著重來。
- 會維護
AGENTS.md、skills 與 extensions,願意把團隊規則寫成可版本控制的檔案。 - 想檢查 system prompt、session JSON 與 context,討厭產品在背後改行為。
- 需要 print、JSON、RPC 或 SDK,把 terminal workflow 接進自動化。
- 願意自己決定 sandbox、permission gate、subagents 與 plan mode 怎麼組。
若需求是安裝後立刻得到完整 IDE intelligence、debugger、browser、subagents、approval UI 與企業政策,vanilla Pi 反而會顯得太薄。Oh My Pi、Claude Code、Codex 或其他較完整的 harness 可能省下更多組裝時間。極簡是一種 ownership 模式,不是免費午餐。
安全邊界要先補上
Pi 官方文件寫得很直接:它沒有內建 sandbox。Built-in tools 與 extensions 都以啟動 Pi 的使用者權限讀檔、寫檔、修改檔案與執行 shell command。Project trust 只決定是否載入專案內的 settings、packages 與 extensions,並不限制模型之後要求工具做什麼。
處理陌生 repository、無人監看任務或帶有 secrets 的環境時,應把 Pi 放進 container、VM、micro-VM 或受政策控制的 sandbox,並只掛載需要的 workspace、提供最少量 credentials、限制不必要的 network access。這是採用 Pi 前的必要設計,重要性遠高於附錄級提醒。

一個小型驗收流程
想知道 Pi 是否適合自己的工作,不需要先相信任何 leaderboard。選一個每天真的會做的小任務,跑一輪可重現的比較。
- 在隔離的測試 repository 安裝 Pi,固定同一個模型與 provider。
- 保留預設四個 tools,先不裝 extensions。
- 準備五到十個有測試、lint 或明確 output 的任務。
- 記錄完成率、人工修正次數、tokens、成本與時間。
- 再加入一個變因,例如 project
AGENTS.md、permission extension 或 edit tool。 - 重跑同一組任務,查看逐題差異,避免只看平均分數。
如果 DeepSeek 在你的 repository 裡穩定、便宜又可控,那就是比 30 題匿名 benchmark 更有用的答案。
常見問題
Pi 和 Oh My Pi 是同一個工具嗎?
兩者有別。Oh My Pi 是基於 Pi 的 fork,保留部分設計與互動方式,另外加入大量工具、IDE intelligence、debugging、subagents、browser、memory 與逐模型最佳化。兩者可以共享 lineage,benchmark 結果不能直接互換。
Pi 的 system prompt 真的只有幾百 tokens 嗎?
預設骨架很短,原始碼也容易閱讀;實際送給模型的內容還會包含工具描述、工作目錄、專案 context files、skills 與自訂 append prompt。精確 token 數依模型 tokenizer 與專案設定而變。
Claude Code 縮短 prompt 是否證明 Pi 的方向正確?
它證明前沿模型可能受益於更少 examples 與硬性規則,也證明 prompt 需要持續做 eval。Anthropic 同時為不同模型保留不同 prompts,舊模型仍使用較完整版本,沒有推出一條適用所有模型的短度公式。
Pi 適合背景自動化嗎?
它有 print/JSON、RPC 與 SDK,技術上很適合自動化。無人監看時更需要外部 sandbox、最小 credentials、network restrictions 與可驗證的 acceptance tests。
權威來源
- Pi 官方網站與產品 Landing Page
- Pi 官方 system prompt 原始碼
- Pi 官方安全文件
- Mario Zechner:建立極簡 coding agent 的設計筆記
- Oh My Pi 官方 repository
- Simon Willison:Claude Code 團隊談 system prompt 縮減
- Composio:Open-weight agents 與 tool layer 的 31 題研究
Author Insight
Pi 最有意思的地方,在於它讓 agent 行為重新成為使用者能閱讀、修改與版本控制的東西。短 system prompt 只是這套設計的一部分。這會增加組裝責任,也讓效能、安全與成本問題更容易被逐層測量。對工程團隊而言,可歸因的實驗通常比一張跨產品排行榜更耐用。
