台灣企業該導入 Pi Agent 嗎？揭開權限風險、Containerization 眉角，以及它和 Hermes 的定位差異

Pi Agent 快速回顧：四個工具與多供應商 API 的設計，如何一年累積 9.6 萬星

進入導入決策討論之前，我們先用一章把系列前五天的內容濃縮一次。Pi Agent 是 GitHub 上的 earendil-works/pi，一個以 TypeScript 撰寫的 monorepo，官方定位為 AI agent toolkit。根據 GitHub API 在 2026 年 8 月 24 日的實查資料，這個 2025 年 8 月 9 日才建立的專案，已累積 95，916 顆星、11，864 個 fork，授權為 MIT，一次推送是 2026 年 8 月 23 日，開發節奏依然緊湊。一年左右逼近十萬顆星，在開源軟體圈是很罕見的速度，這股熱度本身就值得我們回頭檢視它到底做對了什麼。

三個核心套件，界線清楚的分工

Pi Agent 採用 monorepo 架構，核心由三個套件組成。pi.dev 官網與公開文件清楚標示：pi-coding-agent 是使用者實際操作的互動式 coding agent CLI；pi-agent-core 是 agent runtime，負責 agent loop 的運行；pi-ai 則是統一多供應商 LLM API 的抽象層，支援 OpenAI、Anthropic、Google 等二十家以上的供應商、三百多個模型。這個切法讓三件事各自獨立：介面、執行邏輯、模型存取。想換模型供應商時，不需要改動 agent 本身的邏輯，這是 Pi 與封閉產品最本質的差異，也是後續所有成本討論的起點。

極簡哲學：四個工具與不到千個 token 的 system prompt

作者 Mario Zechner（GitHub 帳號 badlogic，同時是 libGDX 的作者）曾在個人部落格 說明 Pi 的起源。他原本是重度 Claude Code 使用者，甚至寫了工具追蹤 Claude Code system prompt 的變更紀錄，決定自己動手寫 agent。他的核心論點是：frontier model 已經被強化學習訓練到知道 coding agent 該怎麼運作，不需要一萬個 token 的 system prompt 反覆提醒。模型需要的只有四個工具：read、write、edit、bash。缺功能時，直接問 Pi 自己寫，因為 Pi 可以讀自己的原始碼與文件，擴充就是一支 TypeScript 檔，跑在 agent loop 的同一個 process 裡。2026 年 7 月 Anthropic 為了新一代 Claude 模型刪除 Claude Code 超過八成的 system prompt，等於是官方往 Pi 的方向靠攏，這對極簡路線是很有力的驗證。

「不內建權限系統」是從第一天就存在的決定

很多人把「沒有權限系統」當成 Pi 的缺點，但這其實是作者從第一天就明說的設計決定。README 開宗明義：不內建權限系統，預設以啟動者的權限執行，需要隔離時自己 containerize，官方文件提供 Gondolin 擴充、Plain Docker、OpenShell 三種模式。這個決定換來的是程式碼極度精簡，也讓供應鏈硬化相對容易：npm 依賴全部鎖定版本，lockfile 是 ground truth，CI 跑 npm audit。對企業導入來說，這代表權限管理必須自己扛，這個包袱我們會在後續章節詳細拆解。

實測數據與社群反應

第三方評測方面，Composio 在 2026 年 8 月 10 日發布的實測報告（測試時間一百小時）顯示，自家 tool use eval 中 Pi 通過 20/30 個任務，每個成功成本約 0.028 美元；Claude Code 通過 16/30，每個成功成本約 0.195 美元。結論是 Pi 在成本與通過率上勝出，但多數受測者仍把 Claude Code 當成日常主力。社群有一句流傳很廣的話，出自 IndyDevDan：

Claude Code 是 starter pack，Pi 是 endgame。

MCPlato 在 2026 年 7 月 10 日的五個 agent 比較中，將 Pi 定位為最小終端 harness，適合想自己組工作流的 agent builder。Yage.ai 則在 2026 年 5 月的評論中指出，Pi 的透明度是最大差異，Claude Code 的子代理你看得到結果、看不到過程。

系列前五天結論濃縮

• 第一天：Pi 是對 Claude Code 不滿的產物，但一年近十萬顆星證明這個不滿有大量共鳴。
• 第二天：四個工具加上不到千個 token 的 system prompt，就能與 Claude Code 打平，關鍵在於信任模型本身的能力。
• 第三天：透過 npm 安裝 @earendil-works/pi-coding-agent，接 OpenAI、Anthropic 或本地模型，實際任務可以順暢跑完。
• 第四天：與 Claude Code、Codex 相比，Pi 的優勢是成本與透明度，弱點是權限管理與整合度。
• 第五天：社群用 extension 把 plan mode、sub-agents、MCP 等能力補回來，擴充生態正在快速成形。

風險提醒

九萬多顆星不代表企業成熟度，這是我們必須誠實面對的現實。Pi 的風險清單包括：預設全系統存取、沒有 plan mode 與 sub-agents、無法用 Claude Pro 訂閱價格跑 Claude 模型、新進 contributor 的 PR 會被自動關閉，以及星數在一年內快速累積帶來的熱度膨脹疑慮。這些風險與優點並存，也正是導入決策最需要權衡的地方。

接下來我們進入第六天的正題：台灣企業到底該不該導入 Pi Agent。前面的回顧已經把技術面講完，接下來的討論會聚焦在權限風險、containerization 指引，以及 Pi 與 Hermes 在定位上的差異。這兩個 harness 對我們公司來說都不是學術議題，因為我們內部就跑 Hermes，這份比較是實際的 dogfood 材料。

Pi 與 Hermes 定位差異：最小 harness 對上持久助理，台灣團隊怎麼選

把 Pi 與 Hermes 放在一起比較，乍看像是拿螺絲起子比瑞士刀。兩者都是開源 agent，也都有活躍的社群，但設計的出發點幾乎相反。MCPlato 在 2026-07-10 發布的五 agent 比較報告中，把 Pi 定位成「最小終端 harness」，把 Hermes 定位成「持久助理」，兩者之間的對比對我們公司有直接參考價值，因為我們內部就是 Hermes 的使用者，這份比較是實際的 dogfood 材料。

Pi 的最小終端 harness 定位

Pi 的設計哲學是把 harness 縮到最小。作者 Mario Zechner 在 2025-08 從重度 Claude Code 使用者轉為自寫 agent，他認為 frontier model 已經被訓練到知道 coding agent 該怎麼做，不需要一萬個 token 的 system prompt 提醒。他的實作是四個工具：讀取、寫入、編輯、執行 shell 指令，system prompt 不到一千個 token，沒有內建 MCP，沒有權限系統，預設以啟動者的權限執行。官方 README 自己明白寫著，需要隔離就自行 containerize，這在導入時必須列為優先評估項目，因為一個不小心，agent 就能存取整台機器。

這種極簡設計換來的是什麼？是成本。Composio 的第三方實測（2026-08-10）顯示，在自家 tool use eval 上 Pi 通過 20/30 個任務，每個成功案例成本約 $0.028，而 Claude Code 通過 16/30，每個成功案例成本約 $0.195（Composio，2026）。Pi 的成本大約是五分之一。是完全的掌控權，agent 的每個環節都可以拆開重組，想接哪一家 LLM 供應商就接哪一家，Pi 的 pi-ai 套件支援超過二十家供應商、三百多個模型。

但這個定位也有明確的代價。Pi 沒有聊天頻道整合，沒有記憶機制，沒有排程能力，它的工作範圍就是終端機裡面的 coding 任務。你要它記得昨天的決定，它記不得，除非你把狀態寫成檔案。你要它定時去做某件事，它做不到，因為它就是一個互動式 CLI。要補這些能力，得靠社群用 extension 補齊，或者自己寫 TypeScript 擴充。

Hermes 的持久助理定位

Hermes 走的是完全不同的路線。MCPlato 的報告把它歸類為「持久助理」，意思是它具備記憶、跨頻道與排程能力。Hermes 不只是在終端機裡等指令的 harness，它會記得使用者的偏好與專案脈絡，能夠跨不同的通訊頻道被喚起，也可以排定時間執行週期性的任務。對使用者來說，Hermes 比較像一個長期的協作者，而不是一次性的執行工具。

這兩種定位的差異，具體表現在日常使用場景上。假設一個台灣軟體團隊要追蹤 production server 的錯誤回報，用 Pi 的做法是每天上班時自己打開終端機，下指令讓 Pi 去分析 log，看完之後把結果寫進筆記。用 Hermes 的做法是把錯誤回報的來源接進 Hermes，它會自己收集資料、比對歷史脈絡，時間到就把摘要推到指定的頻道，過程不太需要人介入。

價值不在哪一個比較「聰明」，而在哪一個比較「省事」。Pi 把控制權完整交給使用者，事後想確認 agent 做了什麼，看 terminal 紀錄就好，過程完全透明。Hermes 把例行工作自動化的範圍擴大到聊天與排程，但使用者得信任它對系統的存取範圍，以及它記憶內容的正確性。信任的基礎也不同。

四個方案的定位總覽

把 MCPlato 報告中的四個方案放在一起看，定位差異會更清楚：

這張表的重點是：Pi 與 Hermes 不是競品，它們解決的是不同層次的問題。Pi 回答的是「模型需要多少 harness」，Hermes 回答的是「助理該如何融入使用者的工作循環」。台灣團隊在選擇時，得先問自己的需求是哪一層。

台灣團隊的工作流對照

台灣軟體團隊的日常，大致可以切成兩類工作流。第一類是開發型工作流，工程師坐在終端機前面，要修 bug、寫測試、重構程式碼，工作單位是小時。這一類需求 Pi 的定位非常合適，功能極簡、成本低、過程透明。第二類是維運型工作流，負責人需要追蹤 issue、定期檢查服務狀態、把異常回報整理給相關人員，工作單位是天或週。這一類需求剛好是 Hermes 的強項，因為它有記憶與排程，能跨頻道被喚起。

多數台灣中小型團隊的現實是兩者並存，白天寫功能，晚上要顧服務。但因為人力有限，往往沒有餘裕同時維護兩套 agent 體系。那怎麼選？關鍵看主要瓶頸在哪。如果團隊的痛點是開發成本太高，每個任務都要花大量 token 跟時間在 agent 引導上，Pi 的極簡設計能直接降低每次任務的執行成本。如果團隊的痛點是例行工作太多，每天要花時間彙整資訊、盯排程、轉發進度，那 Hermes 的自動化能力更貼近實際需求。

另一項務實考量是導入成本。Pi 的導入門檻很低，npm 安裝 @earendil-works/pi-coding-agent 就可以開始用，對有技術人員的公司完全可行。但權限管理要自己想辦法，SME 若沒有技術人力，需搭配 containerization 指引才能安心上線。Hermes 的落地牽涉到聊天頻道整合與記憶儲存的管理，需要先想清楚哪些資訊可以被 agent 記住，哪些不行。台灣企業若是首度導入 agent，先從 Pi 這種最小 harness 開始，把信任感建立起來，再評估要不要往 Hermes 那種持久助理延伸，是風險較低的路徑。

替代方案有限公司觀點

我們公司內部就跑 Hermes，同時也長期追蹤 Pi 的發展。以第一線幫台灣客戶導入 agent 的經驗來說，我們觀察到多數客戶的第一個問題不是「哪個 agent 比較強」，而是「這套東西裝完之後，誰來維護」。Pi 的好處是完全開放、沒有訂閱綁定，但相對地，權限管理、容器隔離、擴充維護都要自己扛。Hermes 帶來的主動式協作體驗確實能讓團隊感受到 agent 的價值，但記憶與排程功能也意味著 agent 掌握更多脈絡，這在台灣企業對資料治理特別敏感的文化下，需要更謹慎的設計。

我們的建議是不要急著定案。先用 Pi 跑一週的真實開發任務，紀錄花費與成果，同時用 Hermes 接一兩個非敏感的維運流程，感受持久助理與例行工作結合的效果。兩週後再回頭看數據，哪一個定位解決了比較多的痛點，就讓那個方案先落地。工具沒有絕對優劣，只有適不適合當下的工作流。

Containerization 三模式實作：Gondolin、Plain Docker、OpenShell 怎麼裝與怎麼取捨

Pi 的官方 README 寫得很直接：這個 agent 不內建權限系統，指令一發出去就以啟動者的權限執行。換句話說，你給 Pi 一把鎚子，它不會主動問你這面牆能不能敲。官方建議的解法是 containerize，也就是把 agent 關進容器裡，讓它在沙盒中工作。官方文件列出了三種模式：Gondolin 擴充、Plain Docker、OpenShell。這一章我們把三種模式的安裝指令、設定步驟與隔離強度攤開來比較，回答一個實際問題：沒有容器經驗的中小企業，到底該從哪一種開始。

為什麼要容器化：先看懂 Pi 的權限設計

Pi 的設計哲學是極簡，system prompt 不到一千個 token、工具只有 read、write、edit、bash 四種。好處是模型不需要被一堆規則綁住，壞處是它沒有自己的判斷力去區分「可以刪的檔案」與「不能動的目錄」。你叫它清理暫存檔，它可能順手把備份也清掉，因為 bash 工具就是以你的使用者身分執行。Mario Zechner 在 README 中直接承認這點，並建議需要隔離環境的使用者自行 containerize。這不是缺陷，而是取捨：Pi 把權限決策交給使用者，而不是替使用者做決定。實務上，任何要接進正式環境的 Pi 工作流，都應該先想清楚容器策略。

模式一：Plain Docker，最樸素的隔離

Plain Docker 是指用標準的 docker run 把 Pi 包進一個容器，不另外安裝擴充。安裝步驟大致如下：

1. 建立工作目錄，例如 ~/pi-workspace。
2. 寫一個 Dockerfile，基底映像檔用 node:20-slim，安裝 @earendil-works/pi-coding-agent。
3. 用 docker build 建立映像檔。
4. 啟動時掛載工作目錄：docker run -v ~/pi-workspace:/workspace。
5. 把 API 金鑰用環境變數傳入，例如 ANTHROPIC_API_KEY。

這個模式的好處是概念簡單，團隊裡只要有人會 Docker，就能在十分鐘內架好。缺點是隔離很粗糙：容器內的 agent 依然能存取掛載進來的目錄，如果只是為了「避免誤刪系統檔案」這個目的，效果有限。另外，Pi 需要自己的設定檔與憑證，這些都要手動掛載，啟動成本其實不低。比較適合已經有 Docker 維運經驗、只是想把 agent 關進沙盒的團隊。

模式二：Gondolin 擴充，把隔離內建進 agent loop

Gondolin 是 Pi 官方推薦的隔離擴充，名字取自托爾金筆下的隱藏城市，概念上就是「把 agent 藏在堅固的城牆內」。安裝方式是在 Pi 的設定檔中啟用 Gondolin 擴充，實際指令以 pi.dev 官方文件為準，大致的流程是：

pi config set extensions gondolin

設定之後，Gondolin 會攔截 bash 工具的指令，在動態建立的容器內執行，再把結果回傳。換句話說，Pi 主程序跑在你本機，但每一次指令呼叫都被轉進容器，讓 agent 以為自己在操作真實環境，實際上它碰到的是一層透明沙盒。這種做法的隔離強度比 Plain Docker 高，因為連指令層級的破壞都被攔截，agent 無法直接改到主機的檔案系統。缺點是 Gondolin 需要先裝好容器執行環境，而且每次指令呼叫都會多一層容器啟動的延遲，開發體驗會稍微變慢。對想要「開發時安全、正式時乾淨」的團隊，Gondolin 是比較平衡的選擇。

模式三：OpenShell，把 shell 關進沙盒

OpenShell 是第三種模式，概念上介於前兩者之間。它不是把整個 Pi 包進容器，而是把 bash 工具的執行環境替換成一個隔離的 shell。安裝方式類似：

pi config set tool.bash.impl openshell

OpenShell 的名稱常讓人誤解，以為它只是換一個 shell 程式，實際上它會攔截所有外部指令，限制網路存取與檔案寫入範圍。它的優勢是啟動成本最低，幾乎感覺不到延遲，適合開發者日常使用。缺點是隔離範圍僅限於 shell 層級，如果 Pi 透過其他工具執行檔案操作，仍可能繞過保護。換句話說，OpenShell 是「夠用但不嚴密」的選擇，適合個人開發者，不適合需要嚴格稽核的企業環境。

三模式比較：隔離強度、啟動成本與維運負擔

沒有容器經驗的 SME 該從哪裡開始

如果你的公司在台灣，平常沒有專職的 DevOps，我的建議是分階段走。第一個禮拜先用 OpenShell 跑，因為安裝只要一行指令，團隊不會被容器概念嚇到，先把 Pi 用起來、觀察它怎麼做事。等到確定 Pi 有留下來的價值，再升級到 Gondolin，並請顧問或擅長 Docker 的工程師協助建立標準映像檔。Plain Docker 反而可以擺在後段，原因是它的彈性最大但定型最難，團隊必須自己決定掛載哪些目錄、怎麼管理憑證，這些都是 SME 最欠缺的知識。

另外要提醒一點：容器隔離解決的是「agent 不要搞壞你的系統」，不是「agent 不會外洩資料」。Composio 在 2026 年 8 月的實測顯示，Pi 在工具使用評測拿到 20/30 的成績，每個成功案例成本約 0.028 美元，只有對手的七分之一，但評測也強調 Pi 適合自訂工作流與成本敏感的場景。如果企業的痛點是資料治理，容器化只是第一步，還需要配合 API 金鑰的定期輪換、log 的留存政策，甚至考慮本地模型跑在內網，才能把資料留在台灣境內。

三種模式沒有絕對優劣，只有取捨。Plain Docker 給團隊最大的控制權，Gondolin 給 agent 最完整的保護，OpenShell 給開發者最順手的速度。Pi 的 README 之所以把選擇權交給使用者，正是因為不同團隊的風險承受度與技術底子不一樣。先從最輕的開始，等需求明確了再往上加，這比一開始就追求最嚴格的隔離，更容易讓 Pi 在組織裡活下來。

無內建權限系統風險盤點：預設全系統存取，真實工作流會發生什麼

Pi 的官方 README 在安全章節寫得十分直白：沒有內建權限系統，預設以啟動者權限執行 bash 工具，需要隔離就自行 containerize。這段話只有短短幾行，對開發者來說可能只是產品定位的聲明，實際意涵卻比表面深得多。啟動者權限代表 agent 能讀寫本機帳號能讀寫的一切，包括整份程式碼庫、環境變數、SSH 金鑰，甚至整個家目錄的個人檔案。對有專職資安工程師的大型組織，這或許只是部署流程的一環；但對沒有專職技術人力的中小企業（SME），這幾個字可能就是災難的起點。

情境一：誤刪專案檔案，沒有確認也沒有復原

假設設計團隊請 Pi 把某個 WordPress 子主題的目錄結構整理乾淨。Pi 接手後判斷「assets/old-banners」沒有被任何頁面引用，便執行 rm -rf assets/old-banners。在沒有權限機制的 Pi 上，這道指令會直接通過，不會有任何確認對話框。如果團隊成員在同一個資料夾裡還放了尚未上傳 Git 的原始設計稿，這些檔案就會瞬間消失，而且無法救援。

對照 Claude Code 的預設行為，刪除類指令會觸發權限提示，使用者有機會在執行前攔截。這不是「Claude Code 比較保守」的風格差異，而是兩種產品對 agent 自主性的界線畫在不同位置。Pi 的哲學是模型已經夠聰明，不需要過度提示；但聰明與謹慎是兩回事，尤其當 agent 跑在正式環境，一個判斷失誤可能就是整季的設計資產付之一炬。

情境二：讀取 .env 密鑰，機密跟著對話離開內網

很多團隊習慣把 API 金鑰、資料庫連線字串、第三方服務密鑰放在專案根目錄的 .env 檔案。Pi 的 bash 工具可以執行 cat .env，這個動作不會有任何警告。更棘手的是，一旦 agent 把讀到的內容放進對話脈絡，而對話紀錄又透過 API 供應商同步到雲端，密鑰就等於離開公司內網，流向不可控的外部環境。若 Pi 連接的是 OpenRouter 這類多供應商服務，請求到底轉給哪家模型供應商，開發者不一定每次都能掌握。

2026 年 8 月Composio 發布的實測顯示，Pi 在 tool use 任務上以 20/30 的成績勝過 Claude Code 的 16/30，單次成功成本更是只要 $0.028 美元。但表現亮眼與密鑰治理是兩條平行線，分數再高都無法回答一個問題：你的密鑰現在在哪裡？導入 Pi 之前必須假設 agent 隨時可能讀取所有檔案，提前把密鑰從檔案系統中抽離，才不會把生產環境的鑰匙交到一個沒有門鎖的盒子裡。

情境三：覆寫程式碼庫，改動邊界無人把關

開發者請 Pi「把這個外掛所有 API 呼叫從 v1 升級到 v2」。Pi 可能用 sed 或整批替換的方式改動幾十個檔案，由於沒有變更預覽與確認機制，改完之後開發者才發現某個共用函式庫的版本號也被波及。如果該專案沒有完善的分支保護，這些變更會直接被 commit，甚至 push 到遠端 main，影響所有協作者。

Claude Code 在類似場景會逐檔顯示 diff，並要求使用者確認後才寫入。Pi 的設計沒有這一關，它預設「模型知道自己在做什麼」。問題是模型的理解來自訓練資料與當下脈絡，它看不出這個專案哪支檔案是客戶手改過、尚未備份的版本。程式碼覆寫的風險不在於模型笨，而在於它根本不知道人類沒有說出口的脈絡。

Pi 與 Claude Code 的權限行為對照

這張表不是要否定 Pi，而是要畫出風險邊界。Pi 的GitHub 頁面在 2026 年 8 月 24 日查證時已有 95，916 顆星，MIT 授權、npm 依賴全數 pinned，供應鏈硬化做得很紮實。但原始碼乾淨與執行權限是兩件事，就像一輛煞車性能優異的車，不代表你可以不繫安全帶。

SME 導入前必須補上的防護清單

沒有專職技術人力的團隊，不可能要求成員都懂容器網路與 seccomp 設定。以下六項防護措施不需要資安背景，只需花一個下午照做，就能把 Pi 的預設權限從「全系統存取」降到「可控範圍」：

• 容器隔離優先：使用 Gondolin 擴充或 Plain Docker 模式執行 Pi，讓 agent 的檔案系統與實體機隔離。就算 Pi 誤刪目錄，傷害也只留在容器內。
• 最小權限帳號：建立專屬作業系統帳號給 Pi 使用，該帳號只能讀寫特定工作目錄，不具 sudo 權限。這能避免 agent 動到系統層級的設定。
• 密鑰全面外移：把 .env 改為由 CI/CD 系統或密鑰管理服務注入，agent 的工作目錄不放任何明文密鑰。沒有密鑰可以讀，情境二就不會發生。
• Git 工作流保護：要求 agent 執行變更前先確認工作區乾淨，並一律在 feature branch 作業，透過 git hook 阻擋直接 push 到 main。
• 網路出口控管：以防火牆限制 agent 只能連到白名單的 API 端點，避免密鑰或程式碼被送往未知服務。
• 操作日誌留存：開啟 Pi 的指令紀錄，定期稽核 agent 執行了哪些 bash 指令。很多 SME 忽略這點，出事時連事發過程都還原不出來。

以台灣市場的實際情況來看，導入 AI 工具最常卡關的不是預算，而是「出了事誰負責」。Pi 把權限責任全部交給使用者，靈活度極高，但 SME 若無人力維護容器環境，至少要保留一套詳實的日誌與定期備份機制。備份不能用「好像有排程」當答案，必須實際測試還原流程，否則防護清單寫得再漂亮都是紙上談兵。

Pi 的極簡哲學確實讓它成為成本敏感團隊的務實選擇，Composio 的數據也證明它在工具呼叫上比 Claude Code 更省更快。但「省」與「快」的前提是風險可控。把上述六項防護補上之後，Pi 的全系統存取預設就會變成「隔離容器內的全系統存取」，邊界清楚，責任明確，團隊才能安心享受開源授權與低廉成本的紅利。

Composio 100 小時實測拆解：20/30 通過率與單次 $0.028 的數字從哪來

Composio 在 2026-08-10 發布了一份 實測報告，內容是自家 tool use eval 上 Pi 與 Claude Code 的捉對比較。測試團隊花了 100 小時跑完兩套工具，得到的數字是 Pi 三十個任務通過二十個，Claude Code 通過十六個。更吸引人的是成本：Pi 每次成功成本只要 $0.028，Claude Code 要 $0.195，兩者相差將近七倍。這份數據在社群引起不少討論，支持開源極簡路線的人把它當作 Pi 優於 Claude Code 的證據。不過把數字放大看，事情沒有表面那麼簡單。

這份評測到底怎麼測的

Composio 是專門做 agent tooling 的廠商，自家產品就是幫 AI agent 接第三方工具，所以它的評測場景集中在 tool use，也就是「模型能不能正確決定呼叫哪個工具、傳入正確參數、處理工具回傳的結果」。測試過程裡，每個任務都有一個明確的成功標準，例如把某個 API 的資料抓下來、轉成特定格式、寫進指定位置。一百小時的工時包含設定環境、排錯、重跑與人工判定。

三十個任務的數量不算大，但涵蓋的類型算廣，包括檔案讀寫、命令列操作、網路請求與簡單的程式碼修改。兩個 agent 都用同樣的任務清單，所以不是某一方被刻意刁難。Composio 公布的每次成功成本，是以測試期間的 API 花費除以成功任務數，Pi 側的 $0.028 來自較低的模型計價與精簡的 token 用量，Claude Code 的 $0.195 則反映了 Anthropic 原生模型較高的收費水準。

20/30 與 $0.028 的數字細節

先看整體結果，Pi 在三十個任務中通過二十個，通過率約 66.7%，Claude Code 通過十六個，通過率約 53.3%。兩者差距只有四個任務，Composio 的整體判讀是 Pi 稍占優勢，真正拉開差距的是成本。

假設一個團隊每天要跑五十個成功任務，用 Pi 的成本一天約 1.4 美元，用 Claude Code 則將近十美元。以一個月二十個工作天計算，每月差距從三十美元拉到兩百美元。對個人開發者或新創團隊來說，這筆帳很容易算出來。

這份數據的適用範圍與限制

這份評測的任務樣本只有三十個，統計上說服力有限。三十個任務裡 Pi 多過四個，但樣本數小，誤差範圍可能很大。再者，Composio 的任務著重在工具呼叫的正確性，不是長時間的真實開發。真實專案裡，工程師會遇到既有程式碼架構、模糊需求、需要跨多個檔案追蹤線索的狀況，這些都很難用三十個任務重現。

還有一個角色衝突的問題。Composio 自己是 agent tooling 廠商，而 Pi 的擴充生態恰好也涵蓋工具接入，兩者某種程度存在競爭關係。這不代表數據造假，但讀者心裡要有底：一份由工具廠商執行的評測，題目設計多少會往自己擅長的方向傾斜。最保險的用法是把它當作參考指標，不是唯一真理。

Reddit 轉換文與 Yage.ai 的交叉觀察

Reddit r/ClaudeCode 上有一篇實用派轉換文，標題是 Why I switched from Claude Code to Pi。作者不是為了開源理想而搬遷，而是實際工作流程裡 Pi 的終端體驗更順手，log 更清楚，模型可以自己選，不被單一廠商綁住。那篇文下方的討論相當熱烈，許多人提到 Pi 的透明度讓除錯更容易。

Yage.ai 在 2026-05-18 的分析也點出同樣的關鍵：Pi 最明顯的差異在於透明度。Claude Code 的子代理，使用者看得到結果，看不到中間過程；Pi 因為架構極簡，每一步用了什麼工具、下了什麼指令都攤在眼前。對需要向客戶交代執行細節的顧問型團隊來說，這種可解釋性比單純的成功率更有價值。

評測贏了，為什麼多數人還是把 Claude Code 當 daily driver

Composio 自己的結論也承認，Claude Code 仍然是大宗使用者的每日工具。原因可以歸納成以下幾點：

• 整合度：Claude Code 綁定 Anthropic 生態，安裝完就有 plan mode、sub-agents、MCP 支援與官方持續更新，團隊不需要自己組裝。Pi 的極簡設計意味著這些功能都得靠擴充補齊，工程師要願意花時間打磨。
• 權限控制：Pi 預設沒有權限系統，以啟動者權限執行所有操作，安全性完全靠使用者自己把關。Claude Code 內建了權限提示與驗證流程，對非技術背景的使用者更友善。
• 企業支援：多數公司導入 AI 工具時會考慮供應商穩定性與合約保障，Anthropic 的企業方案在這點上比開源專案更容易說服採購單位。
• 心理帳戶：Claude Pro 訂閱一個月二十美元，使用者視為固定開銷，用多用少都一樣；Pi 走 API 計費，用量暴漲時帳單跟著暴漲，反而讓有些人心生顧慮。這也解釋了為什麼成本明明比較低，很多人還是留在訂閱制：預算穩定性的價值，不是表格上的數字能完全呈現的。

台灣企業該怎麼看這份數字

對台灣企業來說，Composio 的數據最大價值不是證明誰贏，而是提供一個成本量級的概念。假設公司要導入 AI agent 協助工程團隊，先以三十個內部任務跑一輪 pilot，用 Pi 的成本預估可能只要幾美元，用 Claude Code 則要到幾十美元。差異夠大，值得花時間做內部驗證。

但選擇哪個 agent 不能只看評測。企業要考慮團隊是否有人熟悉容器隔離，因為 Pi 沒有內建權限系統；要考慮法遵或資安政策是否允許把程式碼送上外部 API；也要考慮維運量，終端工具對習慣圖形介面的同事並不友善。把這些因素放進去之後，那份漂亮的 benchmark 就只是決策起點，不是結論。完整的架構說明與原始碼可以參考 GitHub 上的 earendil-works/pi，想深入了解的人可以直接翻原始碼，驗證文中的說法。

台灣 SME 導入決策框架：技術人力、API 用量、模型供應商三條件檢核

台灣中小企業在評估 Pi Agent 時，最常問的問題是「它跟 Claude Code 比起來誰比較強」。這個問題其實問錯了方向。Pi 的定位與 Claude Code 完全不同，它不是用來取代既有工具，而是提供另一條導入路徑。要判斷自己的公司適不適合，應該先檢核三個條件：技術人力結構、每月 API 用量、以及對模型供應商的依賴態度。這三個檢核點不需要寫程式就能完成，決策者只要老實回答三個問題，答案組合自然會導向適合的選擇。

檢核點一：團隊裡有沒有人能在終端機前獨立作業？

Pi 的安裝與日常操作都在終端機上進行。官方文件指出，安裝方式是用 npm 安裝 @earendil-works/pi-coding-agent（來源：GitHub 官方 README，2026-08-24 查證）。這代表團隊需要有人熟悉 Node.js 環境、指令列操作、環境變數設定。台灣 SME 常見的資訊部門編制，多半只有一兩位工程師，甚至把系統維運外包給接案公司。如果公司內部無人具備這些基礎，導入 Pi 的初期成本會比預期高很多。

Claude Code 雖然也是終端工具，但它有官方提供的完整引導流程，也有圖形介面的網頁後台可以查看用量與帳單。Pi 沒有內建權限系統，任何以 Pi 啟動的指令，都會以啟動者的作業系統權限執行（來源：GitHub 官方 README，2026-08-24 查證）。團隊若連 Docker 或容器隔離都不熟悉，Pi 的風險管理就會變成額外負擔。反過來說，如果公司有一位熟悉終端與容器化的工程師，Pi 的極簡設計反而能縮短學習曲線。它的核心操作濃縮在 read、write、edit、bash 四個工具，加上不到一千個 token 的 system prompt，對有經驗的開發者來說幾乎沒有學習成本。

檢核點二：每月 API 用量落在哪個級距？

Pi 的計費模型是 pay-per-token，也就是用多少付多少。Claude Code 則是訂閱制，官方定價每月 20 美元起跳，用量大的團隊另有更高階的方案。對台灣多數 SME 來說，AI coding agent 不是每天全天候運作，而是集中在一週幾個下午的小型任務。比方說修一個棘手的 bug、為舊專案補測試、或是批次整理遺留程式碼。這種使用型態下，實際 API 用量很容易低於訂閱制的隱含成本。

第三方實測也支持這個觀察。Composio 在 2026-08-10 發布的評測顯示，在自家 tool use 測試中，Pi 完成每個成功任務的平均成本為美金 0.028 元，Claude Code 則為美金 0.195 元（來源：Composio 官方評測，2026-08-10）。這個數字不能直接解讀為「Pi 一定比較便宜」，因為前提是使用者自備 API key，而且選用的模型是成本較低的型號。但對每月用量低於數美元的團隊，訂閱制的 20 美元底價形同強迫吃到飽的月費。pay-per-token 的好處，是讓帳單金額與實際產出直接對齊，沒有用量就沒有支出。

檢核點三：是否想保留更換模型供應商的空間？

Pi 透過 pi-ai 套件統一串接 OpenAI、Anthropic、Google 等二十多家供應商、三百多個模型（來源：GitHub 官方 README，2026-08-24 查證）。今天用 Anthropic 的模型寫程式，明天想改用 Google 的 Gemini，或是換成公司內部的本地模型，只需要調整設定，不需要重寫工作流程。Claude Code 則綁定 Anthropic 生態，無法用同一個 harness 執行其他家的模型。

台灣 SME 在意的通常不是「哪家模型最強」，而是「供應商漲價時我有沒有退路」。模型供應商的定價與政策變動速度很快，今年的優勢組合是 Anthropic 的程式碼模型加上 OpenAI 的通用模型，明年可能又不一樣。如果公司的開發流程長在單一供應商平台上，日後想轉換的遷移成本會被合約綁死。Pi 這種多供應商的架構，本質上把選擇權還給企業自己。官方 GitHub 頁面上也註明，Pi 支援本地模型，這對重視資料落地、不希望原始碼離開公司的台灣製造業或金融業，提供了另一條務實路徑。

將檢核結果對應到兩張清單

三個檢核點都回答完之後，可以用底下兩張清單做最終確認。符合左邊條件越多，導入 Pi 的成功率越高；符合右邊條件越多，則建議先補足能力或改用其他工具。

適合導入 Pi Agent 的台灣 SME 條件

• 團隊中至少有一位熟悉 npm、終端指令與 Docker 的工程師，能自行處理 sandbox 隔離。
• 每月模型 API 花費穩定低於訂閱制月費，或者用量起伏很大，不想被固定月費綁住。
• 公司有明確的程式碼外送政策，允許把片段送上外部 API，或願意改用本地模型。
• 希望保留多模型供應商彈性，避免被單一廠商的定價與政策變動牽著走。
• 偏好開源軟體，重視可檢視性，希望 agent 的每一行指令、每一次取用都能被追蹤。

不適合導入 Pi Agent 的台灣 SME 條件

• 資訊人力長期吃緊，沒有專人負責終端操作與容器隔離，發生問題時無人能處理。
• 每月實際用量已經超過訂閱制的隱含成本，使用 Claude Code 的固定月費反而更划算。
• 公司合規部門要求所有 AI 工具都必須有廠商支援窗口，無法接受社群型開源專案。
• 團隊成員完全不熟悉指令列，需要圖形介面與逐步引導的設定流程。
• 現有流程深度整合 Claude Code 的專屬功能，例如 plan mode、子代理，或是既有訂閱合約尚未到期。

整體而言，三個檢核點的答案會相互牽動。公司若沒有終端人力，就算 API 用量再低也不適合導入；公司若非常在意供應商綁定，即使要承擔容器隔離的技術債，Pi 仍然值得一試。決策時不必追求完美答案，只要把這三個條件逐項列出來，用實際數字對照，就能得到比任何 benchmark 都可靠的判斷。星數與評測只能說明工具本身的能力，無法說明它在你公司的環境裡是否好用，這個決策框架，正是把工具能力轉換成組織行動力的關鍵環節。

替代方案有限公司觀點：我們自己跑 Hermes 與 Pi 的第一手選型心得

我們公司從 2026 年初開始，同時在內部運行 Hermes 與 Pi。這不是為了追逐工具熱度，而是因為客戶諮詢中反覆出現同一個問題：「我們到底該選哪個 harness？」如果我們自己沒有親身跑過一輪，給出的建議就只是紙上談兵。這篇文章是我們自己的 dogfood 記錄，也是我們在導入服務現場最常拿出來跟客戶分享的判斷邏輯。

兩個工具，兩種截然不同的性格

把 Hermes 與 Pi 放在一起比較，本身就是一種誤會，但客戶偏偏最常把兩者搞混。Pi 的定位非常單純，它是極簡的 coding agent harness，作者 Mario Zechner 在 README 裡明講，模型只需要 read、write、edit、bash 四個工具，system prompt 控制在千個 token 以內。我們實際跑下來的經驗是，Pi 在終端裡處理一次性、高強度的程式碼任務非常俐落，Composio 在 2026-08-10 的第三方實測中也驗證了這點，Pi 以 20/30 通過自家 tool use eval，每個成功案例成本 0.028 美元，Claude Code 是 16/30、每個成功案例成本 0.195 美元，成本差了將近七倍（來源：Composio 實測報告）。

Hermes 則是完全不同的物種。它擅長的是長時間陪伴、跨頻道整合、排程與記憶，MCPlato 在 2026-07-10 的五個 agent 比較文章中，把 Hermes 歸類為「持久助理」，把 Pi 歸類為「最小終端 harness」（來源：MCPlato 比較文章）。我們的實測體驗也吻合這個分類：Hermes 適合掛在 Slack 或 Discord 上慢慢累積脈絡，Pi 適合關在終端裡一次解決一個明確的工程任務。

誠實地說，Pi 不是沒有缺點。它沒有內建 plan mode、沒有子代理、沒有 MCP，這些功能都要靠社群擴充補回來。我們第一次把 Pi 交給工程師用，對方第一個反應是「怎麼連個計畫模式都沒有」，這確實是實際的門檻，不是可以粉飾的小事。

客戶諮詢中最常見的兩個混淆：定位問題與權限問題

我們在導入諮詢中發現，客戶的疑問有八成可以歸結成兩類。第一類是「定位問題」，客戶把 coding agent 當成助理在問，或者反過來問助理能不能當 coding agent 用。有一位客戶問我們，Pi 能不能幫他每天整理郵件、排行程、回覆訊息，其實他要的是 Hermes 這個物種。另一位客戶問 Hermes 能不能直接進他的 repo 重構程式碼，這又是把持久助理誤當成終端工人。

第二類是「權限問題」。Pi 的官方 README 非常誠實，它不內建權限系統，預設以啟動者的權限執行所有操作，要隔離就得自行 containerize（來源：Pi 官方 GitHub repo，2026-08-24 查證）。我們在現場最常遇到的對話是，客戶問「工具會不會亂動我的系統？」，然後接著問「那我要不要買企業版才有權限管理？」前者是正確的警覺，後者是把權限問題誤解成付費功能。其實 Pi 的解法不在訂閱方案裡，而是在容器、sandbox 與執行環境的設計中。

我們怎麼幫客戶在 Pi、Claude Code、Hermes 之間做決定

我們的決策框架是三個條件，逐項過濾，不繞圈子。

• 工作型態：客戶要的是「坐在終端前把程式寫完」，優先考慮 Pi 或 Claude Code；客戶要的是「掛在通訊軟體上長期陪伴、跨頻道排程」，那 Hermes 才是正解。我們會直接拿 MCPlato 的比較表給客戶看，避免雙方在錯誤的賽道裡討論優劣。
• 成本結構：Claude Code 走訂閱制，門檻低但供應商綁定深；Pi 走 pay-per-token，可用 OpenRouter 或本地模型，對用量小的台灣中小企業反而更省。Composio 的實測數字證明，相同任務量下 Pi 的成本只有 Claude Code 的七分之一左右，這對預算敏感的客戶非常有吸引力。
• 技術人力：這是最殘酷的一道濾網。Pi 沒有內建權限系統，公司若沒有工程師能處理容器隔離，導入風險會直接轉嫁給營運團隊。我們不會為了推廣工具而隱瞞這點。

Claude Code 依然適合不想折騰、已經有訂閱、需要完整整合體驗的團隊。Pi 適合有技術人力、在意成本與供應商綁定、願意自己補齊權限管理的公司。Hermes 則適合把「助理」當成核心工作負載的組織。沒有任何 benchmark 可以替客戶回答這三個問題，這是我們跑了一整年最深刻的體會。

公司觀點：台灣市場的落地建議

我們觀察到台灣的導入風氣有兩種極端，一種是迷信星數，看到 Pi 有 95，916 顆星（GitHub 資料，2026-08-24 查證）就覺得非用不可；另一種是恐懼開源，覺得沒有企業版就等於沒有保障。這兩種心態都會讓決策失焦，星數說明的是社群關注度，不是企業成熟度，Pi 在 2025-08 才創建，一年內衝高熱度，但企業導入需要的穩定度與權限治理，仍然要靠導入方自己補齊。

我們內部的判斷是，台灣中小企業導入這類工具，應該先從一個小團隊、一個明確的專案開始，不要直接把 harness 選擇升級成年度數位轉型專案。，權責管理是真正的進入門檻，沒有技術人力的公司，我們會建議搭配容器化指引，或直接找外部顧問協助建置。Pi 的多供應商設計讓企業可以逐年比價換供應商，台灣的企業不需要一開始就被單一廠商綁死。

我們自己也在 dogfood 中調整了工作流程，簡單的擴充功能我們會直接寫成 Pi 的 extension，複雜的長期任務還是交給 Hermes 掛在頻道裡。工具之間不是替換關係，而是分工關係，我們帶給客戶的價值，是協助他們釐清自己真正的工作型態，再選擇對應的工具。這才是 AI Agent 導入諮詢的核心。

選 harness 沒有標準答案，但一定有適合你組織的答案。我們能做的，是讓你在錯誤的賽道上跑太久之前，先幫你把地圖攤開。

結語：台灣企業導入 Pi Agent 的最終建議與五項檢查清單

Pi Agent 用不到千個 token 的 system prompt 加上四個工具，就交出讓第三方評測驚豔的成績，這對台灣企業來說是一件好事。它證明了 AI Agent 導入不必從第一天就被單一廠商綁死，工具選擇可以更輕、更省、更透明。但「輕量」不等於「隨便落地」，導入前的決策品質，決定半年後這個工具是生產力，還是另一座整理不完的孤島。把整系列文章濃縮成一句話：Pi 不是萬靈丹，它是一面鏡子，照出你團隊真正的技術底子與工作型態。

導入決策的五項檢查

簽約、裝機、串 API 之前，請先誠實回答下面五個問題。任何一項卡住，都代表導入條件還沒成熟。

1. 權限隔離有沒有做好？Pi 的 官方 README（2026-08-24 查證）明說不內建權限系統，預設以啟動者的權限執行任何指令。如果團隊讓 agent 直接跑在開發者筆電上，它讀得到什麼就改得動什麼。容器化是官方建議的解法，Gondolin 擴充、Plain Docker、OpenShell 三條路至少要選一條走完，再讓它碰正式環境。
2. 模型供應商有沒有備案？Pi 的 pi-ai 套件串接 OpenAI、Anthropic、Google 等二十多家供應商、三百多個模型。供應商漲價、限流或政策轉彎時，換一組 API 金鑰比換整套工具快得多。對把風險分散寫進採購政策的企業來說，這是結構性優勢，但前提是你真的準備好第二份金鑰，而不是只有一份。
3. 技術人力夠不夠？安裝只要 npm 一行指令，但寫 extension、調整 prompt、維護容器化環境，都需要熟悉 TypeScript 與終端流程的人。Pi 的擴充機制很自由，自由度本身就是門檻。人力不是選配，是必要條件。沒有這個條件，後面四項檢查都很難維持。
4. 成本模型合不合？Composio 在 2026-08-10 的實測報告中統計，Pi 每個成功任務的平均成本是 0.028 美元，Claude Code 是 0.195 美元。但兩者計費邏輯不同，Pi 走 API 按 token 計費，無法用月費訂閱價跑 Claude 模型。用量小的團隊反而吃香，用量大的團隊要把 API 價格曲線攤開來算，別只看到單價就衝。
5. 與 Hermes 的定位有沒有重疊？MCPlato 在 2026-07-10 的五款 agent 比較中，把 Pi 定位為最小終端 harness，把 Hermes 定位為持久助理。裝了 Pi 不等於不需要 Hermes，兩者處理的是不同時間尺度的任務。Pi 負責當下的程式碼修改，Hermes 承擔跨頻道、排程與記憶的長期工作。先釐清你的任務落在哪一邊，再決定要裝哪一個，或是兩個都要。

什麼條件的台灣企業，今天就能導入 Pi

如果你的公司至少有一位熟悉終端與 TypeScript 的工程師，程式碼工作量屬於中小型，並且對每一筆 token 的成本與行為透明度都很在意，Pi 可以今天就裝起來跑一輪真實任務。它採用 MIT 授權，沒有綁定成本，用不順手丟掉也不心疼。這類團隊通常也具備自行判斷 containerization 邊界的能力，權限風險可以控制在可接受範圍內。對他們來說，Pi 不是冒險，而是把原本花在訂閱費上的錢，轉換成更精準的運算支出。

什麼條件的企業，該先補上技術缺口

反過來看，沒有專職技術人力、程式碼資產涉及高敏感資料、或需要受管方案來承擔維運責任的團隊，應該先把容器化與備援方案補齊，再考慮導入。工具本身不壞，但 Pi 把安全責任直接交給使用者，這份責任不能外包給開源社群。欠缺內部人力的情況下，直接選擇 OpenAI Codex 這類受管產品，或先找外部顧問做一次導入評估，都比硬裝一套無人維護的 harness 更務實。技術債不會因為工具很潮就自動消失。

這一整篇系列從 Pi 的起源、哲學、實測、對決到擴充生態，繞了一大圈，還是回到一件簡單的事：工具要配合工作型態，不是工作型態去遷就工具。我們在公司內部同時運行 Pi 與 Hermes，很清楚兩者的分工界線，也知道這條界線會隨著團隊成長而移動。如果你看完這系列文章，仍然拿不定主意，歡迎把你的情境丟給我們，我們可以一起把地圖攤開。📩 有任何問題或需要協助，歡迎聯絡我們：[email protected]