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 的預設工具仍是 readbasheditwrite。目前原始碼裡的 system prompt 會列出可用工具、兩條通用行為準則、Pi 文件位置與工作目錄;專案中的 AGENTS.md、skills 與自訂 prompt 會再動態加入。因此「很短」是合理描述,「固定只有幾百 tokens」則不精確,實際長度會隨工具、專案指令與 skills 改變。

Pi 官方首頁展示 minimal agent harness 定位與 terminal 操作介面

真正有價值的是可看見、可替換

許多 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 或自己的介面。

Pi 官方 model picker 展示跨 provider 切換模型

那張 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 官方 session tree 展示對話分支與歷史導覽

一個小型驗收流程

想知道 Pi 是否適合自己的工作,不需要先相信任何 leaderboard。選一個每天真的會做的小任務,跑一輪可重現的比較。

  1. 在隔離的測試 repository 安裝 Pi,固定同一個模型與 provider。
  2. 保留預設四個 tools,先不裝 extensions。
  3. 準備五到十個有測試、lint 或明確 output 的任務。
  4. 記錄完成率、人工修正次數、tokens、成本與時間。
  5. 再加入一個變因,例如 project AGENTS.md、permission extension 或 edit tool。
  6. 重跑同一組任務,查看逐題差異,避免只看平均分數。

如果 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。

權威來源

Author Insight

Pi 最有意思的地方,在於它讓 agent 行為重新成為使用者能閱讀、修改與版本控制的東西。短 system prompt 只是這套設計的一部分。這會增加組裝責任,也讓效能、安全與成本問題更容易被逐層測量。對工程團隊而言,可歸因的實驗通常比一張跨產品排行榜更耐用。

Share this post
Ewan Mak

I'm a Full Stack Developer with expertise in building modern web applications that fast, secure, and scalable. Crafting seamless user experiences with a passion for headless CMS, Vercel and Cloudflare

Loading...