Pi 極簡 Agent 為何反而更快：每輪少送 3 倍 context，成本差距可逾 2 倍

編按：本文綜合整理自 Earendil 原文、Databricks 內部 coding-agent benchmark、Shopify Engineering 的 Autoresearch 實錄、Pi 官方程式庫與 Hacker News 討論，並加入 Siami 編輯部的數據解讀與限制分析。Earendil 是 Pi 背後團隊，其文章具有產品立場；效能主張因此必須回到 Databricks、Shopify 等原始測試脈絡查核。

AI coding agent 的競爭通常被描述成模型競賽：哪個模型推理更強、輸入價格更低、context window 更長。不過 Databricks 對自家多語言、數百萬行程式碼庫進行內部測試後，指出另一個容易被忽略的變數——同一模型外面的 agent harness，也就是負責 system prompt、工具定義、檔案讀取、命令執行、對話歷史與 context 管理的那層軟體。

Pi 選擇把預設介面壓到四個工具，system prompt 與工具定義合計低於 1,000 token。Earendil 的主張不是「功能越少一定越好」，而是先提供可完成大部分工作的 read、write、edit、bash 等基本能力，再讓團隊透過 extensions、skills 與 prompt templates 按需求增加複雜度。

Databricks 測到的不是模型差異，而是 harness 差異

Databricks 沒直接沿用 SWE-bench 或 TerminalBench，而是從內部已合併的 pull request 建立測試，涵蓋 Scala、Go、Rust、Java、Python、Bazel、Protobuf 等十多種語言與技術。這種設計降低公開答案滲入訓練資料的影響，也比較接近該公司工程師每天真的會做的任務。

研究最值得注意的結果，是把模型與 harness 拆開來比較。Databricks 表示，同一模型、相同 thinking effort 分別透過 Claude Code／Codex 與 Pi 執行時，部分組合的單任務成本差距超過 2 倍，但品質維持相同。主要差異不是標價，而是每一輪餵給模型的內容量：

• Pi 每輪送出的 context 約少 3 倍。
• 工作集合較緊，不必反覆重送大量無關內容。
• 在部分任務中，以較少 runs 完成工作。
• 同一模型的 token 單價不變，最終帳單仍可能因 harness 大幅不同。

Databricks 也提供一個反直覺例子：Sonnet 5 每 token 比 Opus 4.8 便宜，但在該公司的任務中，Sonnet 平均每題花 2.09 美元，Opus 則為 1.94 美元；完成率分別為 81% 與 87%。原因之一是 Sonnet 工作更久、讀取更多內容，總 token 消耗約高出 1.9 倍。因此「選便宜模型」不等於「每個完成任務更便宜」。

Pi 的極簡到底省在哪裡

Harness 成本不是只付一次 system prompt。Agent 每做一次工具呼叫、讀取輸出並繼續推理，服務端通常都要處理累積對話與當前工作集合。若預設工具定義很長、背景規則繁複、每輪又塞回大量檔案，少量固定 overhead 會隨多輪任務放大。

Pi 把模型可見介面維持在較小範圍，並強調 context discipline：不在使用者未要求時任意改變 context，避免重複 prefill。這對本地模型尤其重要，因為本地推論常受限於較小 context window、記憶體頻寬與 prefill 時間；穩定的 prompt prefix 也比較容易利用快取。

這種架構的工程取捨可整理成四點：

1. 預設工具少：減少每輪都要帶上的 schema 與說明。
2. 工作集合小：讓模型聚焦當前檔案與證據，不把整個 repository 當背景噪音。
3. 擴充由需求驅動：只有能證明價值的 extension 才加入，不預載所有人的功能。
4. 模型與 harness 分離：能替換模型並實測成本，而不是把模型品牌與操作介面綁死。

「同一模型與相同 thinking effort，透過不同 harness 執行，單任務成本在部分情況相差超過 2 倍；Pi 每輪送出的 context 約少 3 倍。」—— Databricks 內部 benchmark

Shopify 證明「少功能」不等於不能做長流程

極簡架構最常被質疑的是：如果預設沒有專用工作流，團隊是否得反覆造輪子？Shopify 的 pi-autoresearch 提供一個實際案例。工程師 David Cortés 讓 Pi 讀取自己的 extension 文件，再建立自動最佳化迴圈；agent 會提出修改、執行 benchmark、保留改善、回滾退步，然後繼續下一次實驗。

Shopify 公開的成果涵蓋四十多項指標，案例包括單元測試最高加速 300 倍、React component mounting 加速 20%、部分 CI build time 降低 65%，以及改善 pnpm 效能。這些數字不是 Pi 開箱即得的通用保證，而是特定程式碼、特定指標與可反覆驗證的實驗結果；真正可泛化的價值，是 extension 能把「猜一個最佳化方案」改造成「量測、保留、回滾」的閉環。

Pi 並未把 autoresearch 預裝給每位使用者。這正是其設計觀：核心只負責可靠的 agent loop 與基本工具，領域流程留給 extension。好處是不用讓不做效能研究的人承擔相關 prompt 與工具成本；代價則是團隊必須審核生成的擴充、處理 sandbox 權限，並確保 benchmark 沒有被 agent 鑽漏洞。

延伸影片：Pi 創作者 Mario Zechner 說明極簡 harness、context 管理與 AI 生成大量低品質程式碼的風險，可作為理解設計哲學的第一手背景。

數據解讀：3 倍少 context 不等於所有帳單都少 3 倍

Databricks 的「每輪少約 3 倍 context」是其內部任務與測試組合的觀察，不能直接推導成任何 repository、任何模型都節省 66.7% 費用。實際成本還受到輸入與輸出 token 比例、prompt caching、工具回傳長度、任務輪數、模型重試、並行執行和供應商計價影響。若一個 extension 回傳幾萬行 log，極小 system prompt 也救不了膨脹的 context。

同樣地，「品質相同而成本差逾 2 倍」只適用於報告中對應的模型、thinking effort 與任務。Databricks 自己也強調，結論不是 Pi 永遠最便宜，更不是原生 harness 一定比較差。較穩健的解讀是：模型名稱不足以預測單任務成本，harness 必須成為 benchmark 的一級變數。

Earendil 原文宣稱 Pi 搭配 Opus 4.8 xhigh 取得最高整體 pass rate，且比 Claude Code 與 Codex 便宜；這仍應以 Databricks 圖表與測試設定為準，不能外推成公開 coding benchmark 排名。企業真正該複製的是測試方法：拿內部已完成任務建立小型評測集，同時記錄成功率、總 token、總費用、執行時間與人工返工，而不是只看一張跨公司的排行榜。

為什麼這件事重要

Agent 產業正快速堆疊 MCP servers、記憶模組、子 agent、規劃器、規則檔與背景索引。每一項功能單獨看都合理，合在一起卻可能形成「context 稅」：模型在真正閱讀程式碼前，先花大量注意力理解工具與規則；之後每輪又重新處理這些固定內容。當工作需要數十輪，成本、延遲與指令衝突便一起放大。

Pi 與 Databricks 的案例提醒團隊，context engineering 不只是如何塞入更多知識，也包括哪些資訊不該在這一輪出現。更大的 context window 不代表應該填滿；工具越多也不代表模型越能選對工具。把核心介面保持小而穩定，能讓新增功能必須用實測結果證明自己值得佔用 context。

這對採用本地或開放模型的團隊尤其關鍵。當模型能力略低、context 較小或硬體 prefill 較慢時，冗長 harness 的傷害可能比在旗艦雲端模型上更明顯。反過來，若任務需要企業權限、稽核、複雜 IDE 整合或跨服務資料，完整 harness 的預設能力可能比極簡更省人工。重點不是把「簡單」變成教條，而是把每一層複雜度視為需要回收成本的投資。

質疑與限制：極簡把責任轉移給使用者

Hacker News 討論並非一面倒讚美。部分開發者認為 Pi 預設過於簡陋；另有使用者指出啟動速度、按鍵綁定、XDG 目錄規範、UI 重疊與偶發 crash 等問題。還有人提醒，模型供應商會持續縮短原生 harness 的 system prompt；若 Claude Code 已在新模型上移除大量提示內容，七月的成本差距可能很快縮小。

更重要的風險，是「可讓 agent 自己寫 extension」不等於「extension 天然可靠」。生成的工具可能權限過大、錯誤處理不足、污染 context，甚至讓 benchmark 只對單一測試過度最佳化。Production 導入至少需要：

• 在 sandbox 或受限帳號執行 shell 與檔案操作。
• 對 extension 做 code review、版本鎖定與回滾。
• 將工具輸出截斷、摘要或存檔，避免 log 淹沒 context。
• 用多次重跑與 holdout tasks 驗證改善，不只看單次成功。
• 持續比較升級後的 Pi、Claude Code、Codex 與其他 harness，避免 benchmark 過期。

另一個限制是來源立場。Earendil 是 Pi 團隊，其文章選取 Databricks 與 Shopify 的成功案例來支持產品哲學，屬於帶觀點的官方敘事。本文因此把關鍵數據回查到 Databricks 與 Shopify 原始頁面，並保留負面社群回應；但仍缺少由獨立第三方在同一套任務上長期重現的完整資料。

網路社群怎麼看

本文整理時，Hacker News API 顯示討論串已達 469 分、237 則後代留言，高於 feeds.json 較早擷取的 170 分與 62 則，代表話題仍在快速升溫。支持者重視四工具預設、文件與擴充性，也有人把 Pi 包進 XMPP、NixOS 或自建多 agent 系統；反對者則認為「像 Emacs」既是優點也是警訊，需要使用者自行承擔組裝與維護成本。

官方 X 帳號 @pidotdev 轉發 Earendil 對 Databricks、Shopify 的案例整理；@ShopifyEng 則公開列出 300 倍單元測試、20% React mounting 與 65% CI build time 改善。前者是產品方宣傳，後者是實際工程案例，但兩者都不能取代跨任務、跨團隊的獨立評測。

團隊現在可以怎麼驗證

與其立刻更換 coding agent，較務實的方法是做一個一週內能完成的小型 A/B test：

1. 從近期已合併 PR 挑出 20 至 50 個可自動驗證的任務，避免把解答直接放入 prompt。
2. 固定模型版本、thinking effort、環境與工具權限，只替換 harness。
3. 記錄 pass rate、輸入／輸出 token、cache hit、工具輪數、執行時間、美元成本與人工修正時間。
4. 檢查失敗類型：是找錯檔案、context 污染、工具不足、模型推理錯誤，還是環境問題。
5. 只有在 extension 能穩定改善 holdout tasks 時才保留，否則回滾。

Pi 提出的真正挑戰，不是「四個工具能不能打敗所有產品」，而是讓團隊重新回答一個基礎問題：每次送進模型的規則、工具和背景資料，是否真的對完成當前任務有幫助？當 token、延遲與可靠度都能量測時，最有價值的 agent 功能，可能不是再增加一層編排，而是勇敢刪掉沒有證據支持的那一層。