Pi 的極簡哲學解密：只有四個工具、不到一千個 token 的 system prompt，憑什麼跟 Claude Code 打成平手？

從 Claude Code 出走：Mario Zechner 為什麼要自寫一個 agent

在開源遊戲框架圈，Mario Zechner（網路代號 badlogic）不是陌生人。他一手打造的 libGDX 是 Java 遊戲開發社群最常被提及的跨平台框架，累積了深厚信譽。但 2025 年夏天，他突然把戰場從遊戲開發轉向 AI agent，而且出手就是一個 system prompt 極簡到近乎倔強的工具，取名 Pi。這不是一時興起，而是一個重度 Claude Code 用戶，在被官方工具逼到極限之後的逃離紀錄。

從忠實用戶到黑箱調查者：cchistory 的誕生

Zechner 曾經是 Claude Code 的忠實用戶，忠實到一個地步，他開始對官方沒有揭露的內部機制產生好奇。Claude Code 每次執行任務時，會把一大段 system prompt 送進模型，這段提示詞決定了 agent 的行為框架，但 Anthropic 從未完整公開過它的內容與變更紀錄。Zechner 於是動手寫了一個名為 cchistory 的小工具，專門追蹤 Claude Code system prompt 的每一次變化，把官方藏在黑盒子裡的更新歷程攤在陽光下。他在 2025 年 8 月的部落格文章中記錄了這段過程，字裡行間可以讀到他的擔憂：提示詞正在以驚人的速度膨脹，而且沒有任何人知道盡頭在哪裡。

追蹤還不夠，他甚至直接動手 patch Claude Code 的官方 binary。對一般使用者來說，修改一個商用工具的編譯後產物聽起來像天方夜譚，但 Zechner 憑著多年底層開發的功力，硬是拆開官方套件，調整內部行為後再重新封裝。這個舉動在社群裡引起不小討論，有人覺得太狂，有人則認為這是 power user 對封閉系統的必然反抗。無論如何，這兩件事已經透露一個明確訊號：他對 Claude Code 的耐心正在快速消耗。

一萬個 token 的 system prompt，與出走決定

真正壓垮他的，是 system prompt 的持續膨脹。Zechner 觀察到，Claude Code 的提示詞從最初的簡潔版本，一路漲到超過一萬個 token，裡面塞滿各種指令、範例、注意事項與防呆提醒。但他同時意識到一個關鍵事實：frontier model（前沿模型）在訓練階段，已經被強化學習教會了 coding agent 該怎麼運作，模型本身就知道該讀檔、該搜尋、該編輯，根本不需要一萬個 token 在旁邊反覆叮嚀。那一大段提示詞，有一大部分是在對抗模型的不確定性，而不是在提升模型的能力。

於是他在 2025 年 8 月做出決定，退出 Claude Code，自己動手寫一個 agent。他的設計原則極度苛刻：四個工具（read、write、edit、bash）、幾百個 token 的 system prompt、不內建 MCP、不內建權限系統。他甚至刻意把專案取名為 Pi，原因是「讓別人 Google 不到」，一個帶有反叛氣息的命名。這個專案日後發展成 earendil-works/pi，以 MIT 授權公開，2026 年 4 月他加入 Earendil 團隊之後，核心仍保持開源。他的哲學很簡單：缺功能就去問 Pi 自己寫，因為 Pi 可以讀自己的原始碼與文件，擴充就是一支 TypeScript 檔，直接跑在 agent loop 同一個 process 裡。

極簡路線的雙重驗證

如果只是個人偏執，Pi 不會獲得如此大的迴響。2026 年 7 月，Anthropic 為了新一代 Claude 5 世代模型，刪掉了 Claude Code 超過 80% 的 system prompt，官方自己往 Pi 的方向靠攏。這個動作等於替 Zechner 的判斷背書：模型成熟之後，harness 應該越來越薄，而不是越補越厚。

第三方評測也給出類似訊號。Composio 在 2026 年 8 月 10 日發布的實測報告中，花了 100 小時測試兩個工具，自家 tool use eval 的結果是 Pi 通過 20/30 個任務，每個成功任務成本約 0.028 美元；Claude Code 通過 16/30 個任務，每個成功任務成本約 0.195 美元。Pi 在成功率與成本上雙雙勝出，報告也坦言 Claude Code 仍是多數人的 daily driver，但「更少提示詞、更低成本、更高透明度」的極簡路線，已經被數據證明是可行的。

「Claude Code 是 starter pack，Pi 是 endgame。」社群開發者 IndyDevDan 的這句話在討論串中被反覆引用，雖然他也承認自己八成工作還是開 Claude Code，卻精準點出了 Pi 在極簡路線上的位置。

這段歷史為什麼是理解 Pi 的起點

理解 Pi，不能只看它的功能清單，必須先理解它誕生的原因。Pi 不是從零開始的創新，它是對 Claude Code 的具體不滿所催生的答案。Zechner 的 cchistory 與 patch binary 經驗，讓他比任何人都清楚官方工具哪裡臃腫、哪裡封閉、哪裡可以更省，所以他用四工具加極簡提示詞，砍掉所有他認為多餘的部分。這個出發點也解釋了為什麼 Pi 沒有內建權限系統，因為在極簡哲學下，隔離是容器該處理的事，不是 agent 該處理的事。

對台灣的開發者與企業來說，這段歷史的價值在於它提供了一個反思角度：當主流工具不斷往上疊功能時，是不是有一條「減法」的路可以走？開源 MIT 授權、多供應商 API、pay-per-token 的計費方式，讓成本敏感的中小企業不必被單一廠商的訂閱制綁住。當然，極簡也意味著風險自負，Pi 預設以啟動者權限執行，沒有內建 sandbox，導入前必須自己做好 containerization 規劃。這個風險與取捨，我們會在後續章節用實際測試數據繼續深入。

極簡哲學核心：四個工具、不到千個 token 的 system prompt 如何運作

上一章節談到 Pi 的誕生源自對 Claude Code 的不滿，這股不滿最終沉澱成一套明確的極簡哲學。這套哲學的具體產物，就是四個工具加上一段不到 1，000 token 的 system prompt。乍看之下這像是陽春的玩具，但它在第三方實測中確實與 Claude Code 打成平手。這一段我們要拆解這套極簡設計的內部邏輯，並且用 Anthropic 官方的動向來驗證，極簡路線並非偏激的個人偏好，而是模型能力演進後的必然結果。

四個工具，不多也不少

Pi 的核心工具只有四個，分別是 read、write、edit 與 bash。它的官方 repo（截至 2026 年 8 月 24 日，earendil-works/pi 已累積超過 95，900 顆星）對這四個工具的定位描述得非常直接。read 負責讀取檔案內容與目錄結構，write 用來建立新檔案，edit 做精準的局部修改，bash 則執行任何終端指令。沒有 MCP 伺服器、沒有 plan mode、沒有子代理，就是這四把刀子。

為什麼夠用？作者 Mario Zechner 在 cchistory 這篇起源文章中提出一個關鍵論點：現今的 frontier model 已經被強化學習（RL）訓練到一個程度，模型內部早就知道 coding agent 該怎麼做事。打開檔案、讀取內容、修改、執行程式、看錯誤訊息，迴圈反覆，這就是 agent 工作的本質。與其把這些流程用一萬個 token 的提示詞硬寫進 system prompt，不如讓模型自己發揮它已經學會的能力。

這個想法反過來看更清楚。Claude Code 的 system prompt 動輒上萬 token，裡頭塞滿了各種規則、工具說明、行為指示、防錯措施。Mario 用自己寫的 cchistory 工具追蹤 Claude Code 的 system prompt 變更，發現大量內容其實是反覆提醒模型「你是一個 coding agent，你應該依照這個流程工作」。對較早期的模型來說，這些提醒確實必要。但對 2025 年以後的 frontier model，這些知識早就內化了。

舊版模型需要襁褓，新版模型只需要工具

Pi 的 system prompt 有一段廣為流傳的陳述，大意是：如果模型很笨，你寫再多 token 也救不了它；如果模型夠聰明，你只需要給它工具，它就知道怎麼用。這句話聽起來有點挑釁，但背後的邏輯是成立的。模型在 RL 階段被灌入了海量的 agent 行為資料，編寫程式、除錯、執行指令的循環對它來說已經是反射動作。冗長的提示詞不僅沒有幫助，有時反而會干擾模型的判斷，讓它在不相干的規則上浪費注意力。

Pi 的 system prompt 之所以能壓到 1，000 token 以下，另一個原因是它把「擴充的責任」交給使用者。Pi 本身不內建 MCP，也沒有繁雜的工具註冊機制。缺功能時，使用者可以直接讀 Pi 自己的原始碼與文件，動手寫 TypeScript 擴充檔，這些擴充與 agent loop 跑在同一個 process 裡。換句話說，系統提示詞只是核心骨架，真正的血肉由使用者在需要時自己補上。這種設計讓 prompt 保持精簡，同時確保了擴充的高度彈性。

Anthropic 刪掉 80% 以上 system prompt：官方認證的極簡路線

如果只有 Pi 單方面主張極簡，我們可以把它視為一種市場區隔策略。但 2026 年 7 月發生了一件值得注意的事：Anthropic 為了迎接 Claude 5 世代模型，刪除了 Claude Code 中超過 80% 的 system prompt 內容。這個動作等於官方承認，新一代模型已經不需要那麼多提示詞來引導行為。Claude Code 過去是業界公認提示詞工程最完整的整合式系統，如今官方自己動手瘦身，方向恰好與 Pi 不謀而合。

這個事件在開發者圈引起廣泛討論，也成為 Pi 支持者最常引用的證據。它證實了極簡不是妥協，而是模型能力提升後的自然演進。當模型本身的判斷力足夠強悍時，與其把時間花在打磨提示詞，不如把時間花在打磨工具與工作流。Anthropic 的動作與 Pi 的設計哲學殊途同歸，都指向同一個結論：agent 的價值在於工具與迴圈的正確組合，而不是堆疊文字。

第三方實測的佐證：一樣的任務，五分之一的成本

極簡設計不是空談。第三方工具整合平台 Composio 在 2026 年 8 月 10 日發布了一份實測報告，出處為 Composio 的 Pi vs Claude Code 評測。他們花費 100 小時測試兩個工具，在自家的 tool use eval 上，Pi 通過了 30 項中的 20 項，每個成功任務的成本是 0.028 美元；Claude Code 通過 16 項，每個成功任務的成本是 0.195 美元。也就是說，Pi 約以五分之一的成本達到了更高的通過率。這份數據是第三方實測，不是官方宣稱的效能，但它至少說明了一個事實：精簡的提示詞與四個工具，在真實任務中確實具備競爭力。

成本差異的來源也很直白。Pi 採用 pay-per-token 的計費方式，使用者可以自由選擇 OpenAI、Anthropic、Google 或本地模型，不需要綁定月費訂閱。Claude Code 則與 Claude Pro 訂閱制深度整合，對用量小的開發者而言，訂閱制反而不划算。成本敏感的使用者可以根據自己的需求選用不同供應商，甚至把模型換成開源模型，彈性遠高於封閉的整合式產品。

風險自負的背面：沒有權限系統，隔離靠自己

極簡的背面就是風險自負。Pi 的 README 直接承認，它預設以啟動者的權限執行所有指令，沒有內建 sandbox 或權限管理。如果使用者直接在自己的工作機上跑 Pi，任何 bash 指令都有完整的系統存取權限。這在開發生產環境中是不可接受的風險，因此 Pi 官方建議透過容器進行隔離，包括使用 Docker、OpenShell 或社群開發的 Gondolin 擴充等方式。

不過這個設計其實是刻意為之。Pi 的哲學是「隔離是容器該處理的事，不是 agent 該處理的事」。權限系統如果綁在 agent 內部，會增加 prompt 的複雜度，而且每種作業系統的權限模型都不相同，硬要整合進 harness 反而犧牲了可攜性。把隔離交給 Docker 或虛擬機，既符合業界標準，也讓 Pi 本身保持輕量。對有能力撰寫 Dockerfile 的團隊來說，這不是問題；但對缺乏容器經驗的中小企業，這確實是導入時必須跨越的門檻。

對台灣企業而言，Pi 的極簡哲學提供了一個實際的評估框架。當你在評估 AI Coding Agent 時，可以先問一個問題：我們的團隊需要的是「一個什麼都幫你準備好的整合式系統」，還是「一套精簡的工具組，讓我們自己決定工作流程」？如果是後者，Pi 這種 pay-per-token、多供應商、MIT 授權的開源方案，會比每月 20 美元起跳的訂閱制更有吸引力。當然，選擇極簡方案就必須承擔自行管理權限與隔離的責任。這個取捨沒有標準答案，取決於團隊的技術底蘊與風險承受度。下一章我們會實際安裝 Pi，跑一輪真實任務，看看這套極簡哲學在操作面上究竟順不順手。

實測數據對決：Composio 一百小時測試與社群真實使用場景

上一章我們談了 Pi 的極簡哲學，這一章直接看數據。Pi Agent 與 Claude Code 的比較，最常被引用的第三方實測來自 Composio，這家自動化平台在 2026 年 8 月 10 日發布了一份長達一百小時的測試報告，實際跑了兩個工具各三十道任務，橫跨真實的程式開發情境。這份測試之所以有參考價值，是因為它不像多數評測只跑幾個 demo 任務，而是長時間、大量任務的對比，而且公布了成本數字，這對成本敏感的開發者與企業來說非常關鍵。

Composio 一百小時實測：數據怎麼看

根據 Composio 的實測報告（2026-08-10），在他們自家的 tool use eval 上，Pi 通過了三十題中的二十題，每個成功任務的平均成本是 0.028 美元。Claude Code 則通過十六題，每個成功任務的成本是 0.195 美元。兩相比較，Pi 的成功率高於 Claude Code，而且成本只有後者的約七分之一。

這份數據的意義不在於「Pi 打敗了 Claude Code」，而在於它揭示了兩個工具截然不同的成本結構。Pi 採用 pay-per-token 的計費方式，使用者可以自由選擇要接哪一家的模型，甚至可以接本地模型，成本自然可以被壓到極低。Claude Code 則綁定 Anthropic 的模型，透過訂閱制或 API 計費，費用相對固定且偏高。

不過，Composio 的測試團隊在結論中特別強調了一個重點：雖然 Pi 在他們的 eval 上表現更好，但 Claude Code 仍然是多數人的 daily driver，也就是每天打開來處理實際工作的工具。這個結論乍看之下有些矛盾，既然 Pi 比較便宜、成功率又比較高，為什麼大家還是用 Claude Code？這就要從 Reddit 社群的實際使用場景來理解了。

Reddit 轉換文的真實場景

Reddit 的 r/ClaudeCode 板上一篇標題為「Why I switched from Claude Code to Pi the agent」的轉換文，提供了很具體的脈絡。發文者屬於「實用派」，他並不討厭 Claude Code，甚至承認 Claude Code 在某些情境下仍然比較好。他之所以切換到 Pi，主要有幾個原因。

第一個原因是成本。他是獨立開發者，同時維護好幾個專案，每個月 Claude Code 的訂閱費加上 API 用量，是一筆不小的開銷。切換到 Pi 之後，他可以自己挑選要用的模型，甚至在某些簡單任務上使用較便宜的模型，成本大幅下降。第二個原因是透明度。他提到 Pi 的每個工具呼叫都會清楚顯示在終端機上，他看得見 agent 每一步在做什麼，而 Claude Code 的運作過程相對像個黑盒子。這呼應了 Yage.ai 在 2026 年 5 月的分析，Pi 的透明度是其最大差異點，Claude Code 的子代理你看得到結果，卻看不到中間的決策過程。

第三個原因則與客製化有關。Pi 的擴充機制相對開放，發文者可以自己寫 extension 來補足缺少的功能，而這些 extension 以 TypeScript 撰寫，跑在與 agent 同一個 process 裡，運作上相當流暢。對他來說，Pi 像是一塊可以自由堆疊的樂高底板，而 Claude Code 則是一個功能齊全但相對封閉的套裝產品。

為什麼 Claude Code 仍是多數人的 daily driver

既然 Pi 有這麼多優點，為什麼評測者還是把 Claude Code 當作每日使用的工具？在 Composio 的測試中，他們提到一個關鍵的場景差異：當開發者「坐下來要修 bug」的時候，多數人還是會開啟 Claude Code。而 MCPlato 在 2026 年 7 月的五種 agent 比較中也指出，Claude Code 是「整合式 coding 系統」，也就是說它把所有功能打包在一起，開箱即用，不需要額外設定。

這背後反映的其實是兩種不同的使用哲學。Claude Code 的使用者要的是「一個工具搞定所有事」，他們不想要花時間研究模型供應商、比較 token 價格、自己建構權限管理。他們要的是打開終端機，輸入指令，然後得到結果。Claude Code 的子代理、plan mode、MCP 支援，這些功能對進階使用者來說是加分項，對一般開發者來說則是省時間的利器。

另外，Claude Code 與 Anthropic 模型的深度整合，讓它在某些複雜任務上仍然有優勢。Composio 的測試雖然顯示 Pi 的成功率較高，但那是他們自己的 eval 集，不代表所有場景都是如此。在某些需要大量上下文理解、多步驟推理的任務上，Claude 模型本身的品質仍然佔有領先地位。Pi 的架構雖然精簡，但接上不同的模型，表現就會隨之波動，開發者必須自己承擔模型選擇的風險。

還有一個現實因素，就是「轉換成本」。許多團隊已經投資了大量時間在 Claude Code 的工作流程、MCP server 設定、以及團隊成員的習慣養成上。當一個工具已經融入日常工作流程，即使另一個工具在某些面向表現更好，要全面切換仍然需要很大的動力。Composio 的測試者也承認，他們 80% 的工作仍然在 Claude Code 上完成。

對於台灣企業來說，這個現象提供了一個重要的啟示：選擇 AI Coding Agent 不只是比較 benchmark 數字，還要考量團隊的工作習慣與技術底蘊。Pi 的成本優勢與透明性確實吸引人，但如果團隊成員習慣了 Claude Code 的整合體驗，硬要切換可能反而降低生產力。比較務實的做法，是在導入初期讓兩種工具並行，針對不同類型的任務選用不同的工具，等團隊累積足夠的使用經驗之後，再決定是否全面遷移。

擴充機制與生態：用 extension 把 Claude Code 功能補回來

前文提到，Pi 因為只有四個工具與不到一千個 token 的 system prompt，常被質疑功能太簡陋。但作者 Mario Zechner 從設計第一天就留下一條出路，這條出路就是 extension 機制。與其把 MCP、plan mode、sub-agents 全部塞進核心，Pi 選擇讓核心保持極簡，再用擴充把功能一樣一樣長回來。這個設計，正是 Pi 能快速累積到超過九萬顆星、卻還能維持單一 codebase 單純性的關鍵。

擴充是一支 TypeScript 檔，跑在 agent loop 的同一個 process

要理解 Pi 的擴充機制，必須先看懂它跟 Claude Code 的 plugin 本質差異。Pi 的擴充不是一個獨立執行、用 JSON 溝通的 subprocess，也不是要另外拉一套 SDK 的第三方程式。擴充就是一支 TypeScript 檔，直接跑在 agent loop 的同一支 process 內，代表擴充程式可以讀取 agent 的內部狀態、直接呼叫 read、write、edit、bash 四個核心工具，甚至替換掉預設的行為。換句話說，擴充跟核心工具之間的界線是模糊的，寫擴充等於在改寫 agent 本身。

更特別的是，Pi 可以讀自己的原始碼與 docs。當使用者想要某個功能而 Pi 沒有內建，不需要翻完文件再猜半天，可以直接問 Pi：「我要怎麼寫一個 extension 來支援 MCP？」Pi 會自己打開原始碼找出掛載點，把正確的 API 與註冊流程列出來。作者在 2025 年 8 月的起源文章裡說得很明白：缺功能，就問 Pi 自己寫。這個「自我閱讀」的能力，讓擴充的學習門檻大幅降低，也讓使用者不再被官方功能清單綁住。

社群把 MCP、plan mode、sub-agents 一個一個補回來

實際運作上，社群已經用 extension 補回了好幾項 Claude Code 內建、而 Pi 刻意不做的功能：

• MCP 支援：Pi 官方不內建 MCP client，社群寫了 extension 串接各家 MCP server，把工具目錄直接掛進 agent loop。
• plan mode：透過擴充攔截 agent loop，先產生完整計畫、詢問使用者確認後才開始執行，補回類似 Claude Code 的 plan 工作流。
• sub-agents：擴充可以同時產生多個子任務，各自帶不同的 system prompt 與工具權限，讓 Pi 也能做平行探索。
• 權限管理：因為 Pi 預設不帶權限系統，社群發展出多種 sandbox 擴充，例如用 Docker 或 bubblewrap 隔離檔案系統與網路。

這些擴充不是實驗性質的玩具。根據 Composio 在 2026 年 8 月公布的 實測報告，在自家 tool use 評測中 Pi 通過 20／30 個任務，每個成功任務成本約 0.028 美元；Claude Code 通過 16／30 個，每個成功任務成本約 0.195 美元。也就是說，Pi 在補上擴充之後，不僅成功率更高，成本還不到 Claude Code 的六分之一。

這份數據同時也呼應了 Anthropic 官方最近的動向。2026 年 7 月，Anthropic 為了下一代 Claude 5 世代模型，刪除了 Claude Code 八成以上的 system prompt，官方自己往 Pi 的方向靠。當大模型已經知道 coding agent 該怎麼做事，寫越長的提示詞反而變成累贅，這正是 Pi 敢用不到千個 token 維持極簡的原因。

核心極簡，卻沒有功能天花板

Pi 用四個工具撐起基本盤，再用 extension 讓社群把缺的功能補回來。這不是偷懶，而是對模型能力的信任。模型自己知道該做什麼，harness 只需要留一個靈活的掛載點，讓使用者依照自己的 workflow 長出需要的功能。因為擴充與 agent loop 同 process，任何社群貢獻的功能都能無縫融入，不會有「外掛程式跟本體溝通不良」的窘境。

對台灣開發者來說，這種架構是很難得的學習素材。Pi 的 codebase 使用 TypeScript 撰寫、結構清楚，官方 repo 就在 GitHub 上，任何人都能翻閱 agent loop 的實作方式。想導入 AI 工具的團隊，也可以先從社群維護的 extension 清單開始，確認自己需要的功能是否已經有人寫好，大幅降低入門成本。

如同社群開發者 IndyDevDan 所說：「Claude Code 是 starter pack，Pi 是 endgame。」

當然，我們也要提醒讀者，這是態度鮮明的社群觀點，不代表每個團隊都該立刻遷移。擴充機制雖然靈活，但它們直接跑在 agent 的 process 內，寫得不好可能影響整個 session 的穩定性。企業若要在正式環境採用，團隊需要建立 code review 機制，確認每一支擴充的來源可靠、更新頻率正常，才能在享受極簡核心與生態紅利的同時，把營運風險降到最低。Pi 的擴充生態才剛開始成熟，接下來勢必還會長出更多意想不到的玩法，值得持續關注。

風險與批評：無權限系統的實際影響與社群爭議

Pi Agent 在 GitHub 上已經累積超過九萬五千顆星（2026-08-24 查證為 95，916 顆），走紅速度驚人。不過，熱度沒有讓爭議消失，它的極簡哲學同時也是批評者最常攻擊的弱點。最受矚目的就是 README 直接承認的「不內建權限系統」，另外還有訂閱定價鎖定、PR 自動關閉政策，以及九萬顆星與企業成熟度之間的落差。本節把這些質疑攤開來檢視，幫助讀者判斷風險是否在自己可承受的範圍內。

無內建權限系統，預設以啟動者權限執行

Pi 的權限設計非常直接，它不做身分驗證、不設定檔案存取範圍，預設就是用啟動程式的使用者權限來執行所有動作。你用它操作哪一個帳號的環境，它就擁有那個帳號能讀寫的檔案、能呼叫的網路服務，以及能執行的系統指令。對個人開發者而言，這種設計大幅降低了設定成本，打開終端機就能開始工作，不需要先學習複雜的 Policy 語言。

可是換到團隊環境，問題就出現了。共用開發機、公司內部的 CI 機器，或者任何不只有單一使用者的伺服器，都可能在無意間讓 Pi 接觸到不該碰的目錄。一次失誤的 bash 指令，也許就會改到專案以外的檔案，甚至影響到隔壁服務的設定。研究資料也指出，多數評測者認為 Pi 比較省錢、比較透明，但要「坐下來修 bug」時，很多人還是會打開 Claude Code，其中一個原因正是權限管理帶來的安心感。

README 的三種 containerize 隔離路線

面對權限風險，Pi 官方文件（pi.dev/docs/latest）提供的答案不是把權限系統做進核心，而是要求使用者自行 containerize，把整個執行環境包進隔離容器。文件給出三種方向：

• Gondolin 擴充：以擴充形式提供隔離機制，適合需要較多控制選項的使用者自行組合。
• Plain Docker：直接用 Docker 容器包住 Pi 的執行環境，只開放必要的目錄與網路，用團隊最熟悉的方式建立邊界。
• OpenShell：透過受限的 shell 環境限制指令的影響範圍，偏向以指令層級做控管。

這三條路線各有取捨。Docker 最直觀，但要懂得寫 Dockerfile、管理掛載與網路設定；Gondolin 擴充自然一些，卻需要信任擴充的程式碼品質；OpenShell 則要理解指令層級的過濾規則。無論選哪一條，隔離工作都落在使用者身上，這正是 Pi 與企業級產品最大的差異所在。

訂閱定價鎖定，切換成本被低估

另一個經常被忽略的風險是訂閱定價鎖定。Claude Pro 的訂閱費用綁在 Claude Code 的使用情境上，Pi 無法使用訂閱制的額度來呼叫 Claude 模型，只能改走 API 計費。對用量不大的個人使用者來說，pay-per-token 反而可能比固定月費更省；但對於已經長期付費訂閱的人，切換到 Pi 等於放棄手上的既有額度，這是一筆實際的轉換成本。

更有趣的是，第三方實測結果顯示成本差異確實存在。Composio 在 2026-08-10 公布的評測中（Composio 實測報告）顯示，Pi 在 30 題 tool use 任務中通過 20 題，每次成功成本約 0.028 美元；Claude Code 通過 16 題，每次成功成本約 0.195 美元。也就是說，當團隊的用量穩定、API 成本可以預估時，Pi 確實有明顯的經濟優勢。但這項優點的前提是使用者有能力自己管理權限與隔離，否則省下來的成本可能轉嫁成安全事故的維修費用。

PR 自動關閉機制，社群觀感的兩面評價

Pi 對新進貢獻者的態度也引起討論。根據研究資料，Pi 的自動化流程會直接關閉新進 contributor 的 pull request，改由維護者每天集中審查。這項設計的用意很實際，避免大量未經驗證的外部變更湧入核心程式庫，確保維護者掌握每一次程式碼變動，但副作用就是新手的第一次貢獻很容易被機器人擋下，留下的訊息若沒有充分說明，社群觀感就會顯得強硬。

社群中有人認同這種做法，認為大型專案本來就需要嚴格的進入門檻；也有人覺得自動關閉機制缺乏溫度，容易嚇跑想參與的開發者。這個爭論短期內不會有標準答案，但它提醒我們，Pi 的治理風格偏向單一維護者集中決策，與大型基金會主導的開源專案節奏不太一樣。企業若要長期依賴這套工具，最好先評估自身是否接受這種決策模式。

九萬五千顆星的熱度，與企業成熟度的落差

還有一個需要分開檢視的面向：星數與成熟度之間的落差。95，916 顆星是非常亮眼的數字（來源：GitHub 官方頁面，2026-08-24 查證），但這個專案在 2025-08 才建立，換句話說，這批星數是在一年左右的時間內快速累積的。星數反映的是關注度與期待值，不代表所有功能都已經過大規模企業環境的考驗。

截至 2026-08-24，專案仍有 133 個未關閉的 issue，雖然這在某種程度上屬於開源專案的常態，但也說明了還有不少使用情境有待處理。作者 Mario Zechner 已經在 2026-04 加入 Earendil 公司，核心授權維持 MIT，這是好消息，只是公司化的資源投入與長期的維護承諾，仍然需要時間觀察。對有意導入的企業來說，星數代表的是聲量，真實部署案例的數量與回饋，才是評估成熟度更可靠的依據。

回到台灣團隊的處境，Pi 的風險從來不是「能不能跑」，而是「有沒有能力駕馭它的自由度」。擁有容器化與安全基礎的團隊，可以透過 containerize 補上權限管理，並把 API 計費的彈性轉化為成本優勢。缺少相關技術人力的組織，則要謹慎思考這套極簡設計是否會讓營運風險超出預期。開源熱度能為產品帶來話題，但唯有自己補齊安全與維運配套，才能讓這份熱度轉為實際的生產力。

替代方案有限公司觀點：Pi vs Hermes 的定位差異與台灣 SME 導入評估

我們公司在日常維運中同時跑著兩套開源 agent，一套是本章主角 Pi，另一套是 Nous Research 的 Hermes。這個組合乍看有點矛盾，一個是極簡 coding harness，一個是強調記憶與跨頻道的持久助理，但正是這種並行運作的經驗，讓我們對兩者的定位差異有了比任何評測文章都更直接的體會。

我們自己的 dogfood 經驗：Hermes 處理例行公事，Pi 處理一次性任務

我們從 2026 年初開始把 Hermes 接進內部 Slack 頻道，讓它負責排程提醒、會議紀錄整理，以及跨專案的資訊彙整。Hermes 的持久記憶與跨頻道能力，確實讓它成為團隊裡一個「甩不掉」的成員，我們可以前一天晚上丟一句「明天早上幫我把三個客戶的提案進度整理成表格」，隔天它就會主動回報。這種「一直都在」的特性，是它作為持久助理的核心價值。

而 Pi 在我們的工作流裡，角色完全不一樣。當工程師需要快速改一個 TypeScript 函式、補一個測試案例，或是在本地終端機裡跑一段一輪到底的程式碼任務時，Pi 那四個工具（讀檔、寫檔、編輯、執行指令）的極簡設計反而讓它非常俐落。不需要額外的權限對話、沒有冗長的 system prompt 前置作業，丟進去就能跑。我們的觀察是，Pi 比較像一個「隨叫隨到的一次性約聘工程師」，而 Hermes 比較像「坐在辦公室裡的固定助理」，兩者服務的時空尺度根本不同。

定位差異的本質：一個是 harness，一個是生活伴侶

MCPlato 在 2026 年 7 月發布的五款 agent 比較中，將 Pi 定位為「最小終端 harness」，將 Hermes 定位為「持久助理」，這個分類與我們的實戰經驗完全吻合。Pi 的設計哲學是「把 agent loop 的掌控權全部還給使用者」，它不綁聊天頻道、不綁排程、不綁記憶，這些都是可以自己用 extension 補上的功能。Hermes 則相反，它把記憶、跨頻道、排程這些「助理感」的功能內建得像呼吸一樣自然。

換句話說，Pi 回答的問題是「一個 frontier model 到底需要多少 harness 才能做好 coding」，而 Hermes 回答的問題是「一個 agent 要怎麼融入團隊的日常溝通」。前者是工具，後者是成員，把兩者放在同一個天秤上比較，本身就容易誤導决策。

台灣 SME 導入評估：三個我們天天被客戶問到的面向

作為一間在台灣幫客戶導入 AI Agent 的公司，我們最常被問的不是「Pi 跟 Hermes 哪個強」，而是以下三個務實問題。

• npm 安裝門檻：Pi 的安裝方式就是一行 npm install，官方 GitHub 倉庫明列相依套件全部鎖版本，lockfile 是 ground truth，CI 還會跑 npm audit。對有技術人員的 SME 來說，這確實是低到幾乎沒有門檻的導入路徑。但請注意，這句話的關鍵是「有技術人員」。我們的客戶裡有不少傳產轉型的公司，團隊裡只有一兩位會寫 script 的工程師，這種規模下 Pi 的自由度反而是負擔，因為沒有內建的權限系統，所有安全決策都要自己負責。
• pay-per-token 計費：Pi 不走訂閱制，而是用哪家模型就付哪家的 API 費用，也可以接 OpenRouter 或本地模型。對用量小的 SME，這比每個月固定繳交 20 美元起跳的 Claude Pro 訂閱更省。Composio 在 2026 年 8 月的實測顯示，Pi 每個成功任務的成本約為 0.028 美元，Claude Code 則約為 0.195 美元，兩者相差將近七倍。但我們要誠實指出，這個數字來自特定 tool use eval，不代表所有任務都適用，而且 API 計費的缺點是帳單會波動，不像訂閱制那麼好預測。
• containerization 指引需求：Pi 的 README 明言不內建權限系統，預設以啟動者權限執行，需要隔離就得自己 containerize。對台灣 SME 來說，這代表導入前必須先回答「誰可以讓 Pi 跑什麼指令」這個問題。我們在協助客戶導入時，通常會要求先建立 Docker 隔離環境的標準操作流程，否則一個誤下指令的 rm -rf 可能就把開發環境清空。這不是 Pi 的缺陷，而是它的設計選擇，但 SME 若沒有相關技術人力，就必須把這項工作外包給導入顧問。

我們的結論：先搞清楚你要的是工具還是成員

我們認為，台灣成本敏感的小型團隊在評估 Pi 之前，應該先回答一個問題：「我們要的是一個偶爾來幫忙寫程式的約聘工程師，還是一個每天坐在辦公室裡的助理？」如果答案是前者，Pi 的極簡設計、MIT 授權、多供應商 API 彈性，會讓它成為極具競爭力的選項；如果答案是後者，Hermes 這類持久助理才符合需求

結論：極簡 harness 如何重新定義 AI Agent 的產業問題

回到我們在系列第一篇提出的那個問題：一個 frontier model 到底需要多少 harness？Pi 給出的答案，不是十幾個工具、不是上萬個 token 的 system prompt、也不是層層疊疊的權限框架，而是四個工具、不到一千個 token 的 system prompt，以及一個近乎固執的信念：模型比你以為的更會寫程式，你只需要給它一條乾淨的路。

這個答案在 2025 年 8 月剛出現時，看起來像是一個 libGDX 作者對 Claude Code 的個人叛逆。但到了 2026 年，事情開始變得不太一樣。Anthropic 在 2026 年 7 月為了 Claude 5 世代模型，刪掉了 Claude Code 超過 80% 的 system prompt，官方自己往 Pi 的方向靠攏。這不是巧合，而是 RL 訓練帶來的必然結果：當模型越來越強，你不再需要鉅細靡遺地告訴它每個步驟，它自己知道該怎麼做。

極簡不是偷懶，而是對模型能力的重新信任

Pi 的核心貢獻，在於它把「agent harness 該長什麼樣子」這個問題，從「能塞多少功能」逆轉成「最少需要什麼」。read、write、edit、bash，這四個工具幾乎是所有 coding agent 的共通語言，Pi 把它們砍到不能再砍，然後把剩下的空間留給模型自己發揮。這種設計哲學的背後，是對 frontier model 的深度信任：如果一個模型已經被訓練成知道 coding agent 該怎麼運作，那麼過多的提示詞反而會成為束縛，讓模型的判斷力被淹沒在指令的雜訊裡。

更關鍵的是，Pi 把「擴充」這件事情變成一個開放迴路。缺什麼功能？問 Pi 自己，它可以讀自己的原始碼和文件，然後用 TypeScript 寫一個 extension，跑在與 agent loop 同一個 process 裡。這意味著 Pi 不是一個封閉的產品，而是一個可以自我迭代的平台。這種設計讓它的極簡不會變成陽春，因為每一次擴充都是一次有意識的選擇，而不是預設塞給你一堆你用不到的功能。

從產業角度來看，Pi 重新定義了 harness 的評價標準。過去我們評斷一個 agent 框架，看的是它整合了多少工具、支援多少協定、內建多少自動化。Pi 讓我們重新思考：這些功能到底是為了幫使用者解決問題，還是為了讓產品看起來更完整？當一個不到千個 token 的 system prompt 就能與 Claude Code 打平，那原本那些號稱「企業級」的複雜 harness，是不是有很大一部分都在處理自己製造出來的複雜度？

數據實證：成本與透明度的雙重勝利

Composio 在 2026 年 8 月 10 日公布的實測結果，為這場辯論提供了具體的數據。在自家 tool use eval 上，Pi 以 20/30 的成績通過，每個成功案例的成本是 $0.028；Claude Code 則是 16/30，每個成功案例的成本高達 $0.195。兩者相比，Pi 的成本只有 Claude Code 的七分之一左右，成功率卻高出四成。這不是實驗室裡精心設計的場景，而是第三方團隊花了 100 小時、用兩個工具實測出來的結果。

我們必須強調，這份數據是第三方評測，不是 Pi 官方宣稱的數字，但它仍然具有參考價值。它點出了一個常被忽略的事實：極簡 harness 的優勢不僅僅是哲學上的，更是實務上的。當你的 system prompt 只有不到一千個 token，每次呼叫模型時消耗的輸入 token 自然大幅減少；當你的工具只有四個，模型在決策時需要考慮的選項也變少了，這直接反映在延遲與成本上。

除了成本，透明度也是 Pi 的一大差異點。Yage.ai 在 2026 年 5 月的比較中點出，Claude Code 的子代理你看得到結果，卻看不到過程；Pi 則把整個決策軌跡攤在你眼前。對開發者來說，這種透明度不只是心理上的安心，更是實際除錯的利器。當 agent 給出錯誤的結果時，你能夠回頭檢視它到底做了哪些假設、下了哪些指令，然後針對性地修正 prompt 或擴充，而不是把整個系統當成一個黑盒子來猜。

MIT 開源與多供應商 API：打破單一廠商綁定的產業意義

如果說極簡哲學是 Pi 的內在靈魂，那麼 MIT 授權與多供應商 API 支援，就是它對產業格局的外在衝擊。Pi 的 LICENSE 檔清清楚楚寫著 MIT，Copyright 2025 Mario Zechner，這代表任何企業都可以自由使用、修改、甚至商用，不需要支付授權費，也不需要擔心被突然收回授權。對照 Claude Code 的訂閱制、OpenAI Codex 的受管服務，Pi 把 agent harness 變成了一個真正意義上的開放基礎設施。

多供應商 API 的支援更是打破綁定的關鍵。Pi 的 pi-ai 套件統一了 OpenAI、Anthropic、Google 等超過 20 家 provider、300 多個模型的介面，你可以在同一個 agent loop 裡切換不同廠商的模型，甚至混用互補。這對企業的意義在於，你不再需要因為選擇了某個 agent harness，就被綁死在特定一家雲端廠商。模型供應商的供應鏈風險被大幅分散，定價話語權也回到了使用者手上。

對台灣的資訊服務業者與中小型企業來說，這是一個非常實際的利多。過去想要導入 AI coding agent，選項幾乎只有國外大廠的訂閱服務，每個月固定支出、模型選擇有限、客製化彈性低落。Pi 的出現，讓成本敏感的小型團隊可以用 pay-per-token 的方式，自由組合最符合預算與任務需求的模型，甚至可以接上本地模型或 OpenRouter，把每一塊錢都花在刀口上。

替代方案有限公司的觀點：從選工具到建能力的思維轉變

作為一家實際在幫台灣企業導入 AI Agent 的顧問公司，我們想說的是：Pi 的意義不只在於它是「另一個好用的工具」，而在於它把產業的注意力，從「挑一個最完整的平台」，轉移到「打造自己的能力」。過去客戶來找我們，最常問的是「Claude Code 還是 Codex 哪個比較強？」現在我們會反問：「你們團隊能接受多少複雜度？你們需要的是被引導的工程師，還是一套可以自己長大的框架？」

我們自己在內部就有跑 Hermes 作為持久助理，也用 Pi 來處理純 coding 任務。兩者的定位截然不同，Hermes 是那個記得你所有偏好的辦公室助理，Pi 則是那個坐在終端機前、使命必達的約聘工程師。對台灣的多數 SME 來說，我們建議的落地路徑是：先用 Pi 跑幾個低風險的內部專案，讓團隊熟悉 prompt 與工具協作的方式，同時透過與我們的導入顧問合作，補上權限管理與 containerization 的缺口。Pi 沒有內建權限系統，這不是缺陷，而是它對自我負責的使用者的一種信任，但這個信任需要相對應的技術紀律來承接。

我們也觀察到，台灣企業在評估 AI Agent 時，常常陷入「想要一次到位」的迷思，希望找到一個什麼都做好的產品。但 Pi 的成功提示我們，下一個世代的 AI 導入，重點不是選擇一個功能最齊全的平台，而是建立一個能夠快速適應模型迭代的架構。當模型每半年就有一次大幅躍進，一套精簡、開放、可替換核心元件的 harness，反而比一個綁手綁腳的龐然大物更具長期價值。

整體而言，Pi 以四個工具與不到千個 token 的 system prompt，回應了產業對 harness 的集體焦慮。它讓我們看到，複雜度不是 agent 成功的必要條件，對模型能力的信任才是。當一家公司願意把不必要的層層包裹卸下，留下來的，就是 AI 協作最純粹的樣貌。

如果你正在猶豫該選擇哪一個 agent harness、評估 Pi 是否適合你的團隊，或者想知道如何把權限管理與 containerization 落到實務上，歡迎來信與我們聊聊。我們很樂意分享第一手的導入經驗，協助你的團隊找到最適合自己的協作方式。

📩 聯絡我們：[email protected]