編按：本文綜合整理自 Earendil 官方部落格原文，並加入 Siami 編輯部觀點與分析。
Pi 這個由 Mario Zechner 打造的極簡 AI 編碼代理（coding agent），過去曾公開宣告不支援 MCP（Model Context Protocol）。然而在 2026 年 9 月 29 日的最新文章中，Earendil 工程團隊正式宣布：MCP 已經被納入 Pi 的核心功能，並非以擴充套件形式提供。這項轉變在 Hacker News 引發熱烈討論，397 分、215 則留言，登上當日熱門榜第四名。
為什麼一個曾經公開批評 MCP 的團隊，最終選擇把它放進核心？這篇官方文章給出了詳盡答案。
從「Pi 不支援 MCP」到「Pi 把 MCP 放進核心」
如果你曾經造訪過 pi.dev 的舊版網站，首頁會有一個驕傲的宣告：「Pi 不支援 MCP」。Mario 與團隊成員在 podcast 上也發表過不少對 MCP 不以為然的言論，包含 Mario 親自撰寫的批評文章。
但只要把 Pi 升級到最新版本，就會發現 MCP 變成了核心支援的功能。這個 180 度大轉彎，讓長期追蹤 Pi 的開發者社群一片譁然。究竟是什麼讓 Earendil 改變心意？
三個關鍵原因促成改變
Earendil 工程團隊在原文把決策過程拆解得很清楚。第一個原因是「世界在變」：過去一年他們持續觀察 MCP 演進，今天的 MCP 已經不是一年前的 MCP。光是協議本身改變，並不足以讓團隊決定把 MCP 納入核心——真正的轉折點是接下來的兩件事。
第二個原因是核心重構的副產品。團隊發現，要讓 MCP 順暢整合進 Pi 所需的改動，正好也能讓另一個功能「Jev」在 Pi 裡更容易使用。最終歸納出一個共通點：Pi 與 MCP 都需要一個可以操作的沙盒（sandbox），形式則是一個直譯器（interpreter）。這種「一次重構，兩邊受惠」的設計，正是程式設計裡最理想的狀況。
第三個原因是影響力的策略選擇。Earendil 團隊明確表示：「我們相信正面影響一件事最好的方式，就是去擁抱它。」他們認為現代 MCP 已經比過去好很多，但市面上的 MCP server 與使用模式仍有很大改善空間。Pi 選擇站進場內參與塑造，而不是站在場外當觀眾。
MCP 最大的問題：難以組合
即便 MCP 經過一年多的演進，仍有核心問題沒解決：組合性（composability）不足。即使有 codemode 這種小沙盒機制來協調工具呼叫，MCP 仍然無法完全解決組合問題。
Earendil 點出癥結點：很多 MCP server 是為「把所有工具塞進 context、靠回傳文字節省 token」這種簡單 harness 設計的。Earendil 對現代 MCP 的期待更接近 OpenAPI + 智慧型工具探索：工具應該回傳結構化資料、應該可以透過文件說明自動被發現。
這也是 CLI 為什麼這麼好用——agent 與模型可以用 bash 把所有東西輕巧地串起來。Earendil 在 Pi 裡做的就是把 MCP 工具暴露給 JavaScript 沙盒，這與 Codex 等其他 harness 的設計一致。
為什麼不只做 Codemode，而要連 MCP 也一起做？
這個疑問很合理：Codemode 本身就是一個工具協調機制，為什麼還需要再綁 MCP？答案牽涉到 Pi 內部的「工具表達方式」。
Earendil 過去幾個月做了大量工作，讓 Pi 能善用新一代模型的特性：延遲工具載入（deferred tool loading）、對話中途變更系統訊息（mid-conversation system messages）、調整推理強度（reasoning level changes）。然而他們還沒把工具配置升級到能完整對應這些新能力。
在 Codemode 架構下，必須決定某個工具是要開放給整個 LLM，還是只給 codemode 子集使用。一般的 MCP 擴充套件沒有足夠的中介資料（metadata）讓 Pi 的工具配置正確運作。因此團隊必須重做工具配置邏輯，讓工具可以被標記為「延遲載入」或「僅限 codemode 使用」。
團隊原本可以只把中介資料補好、單獨強化 MCP 擴充套件就好。但他們認為「MCP 加上 Codemode 能解決很多 MCP 傳統上難解的問題」，因此決定把兩者一起納入核心。
Codemode 到底是什麼？
對大多數人來說，「Codemode」是一個陌生的詞。Earendil 用一個很具體的方式解釋它：
執行工具時，harness 通常有兩個執行環境——bash 端，以及 harness agent loop 端。兩邊的可信度等級差很多：harness loop 通常在受信任的環境，而工具則跑在不完全受信任的沙盒裡。
Codemode 特別之處在於它跑在 harness 那一邊。它本質上是一個工具呼叫協調機制，讓 agent 可以更靈活地決定呼叫順序，並用 JavaScript 把多個工具串接起來。因為它跑在 harness 端，所以狀態是保存在 session 對話記錄中，而不是寫到檔案系統。
理論上任何語言都能做這件事，但 JavaScript 有個優勢：輕量版 JavaScript 可以被打包成 WASM 二進位檔，提供合理程度的安全防護。
在 Pi 裡，只要設定好 MCP，Codemode 就會自動載入；也可以手動把它加進設定作為預設工具。只要對 Pi 說「幫我重新設定啟用 codemode」，它就會自動處理好。
實際應用：從 Linear 抓 Issue、用 Jev 分析社群情緒
文章附上一個精彩範例。Earendil 團隊用 Pi 執行一個複雜任務：「用 typesafe/jev 透過 codemode，找出我們 issue tracker 上最挫折的 20 個留言者。」
Pi 會聰明地串接 Linear MCP（抓議題資料）與 Jev（情緒分類模型），整個過程完全不浪費 context：
- 從 Linear 拉出 250 筆 open issue
- 用 Jev 分類模型判斷每個 issue 留言的情緒強度（中性 / 輕度不滿 / 明顯憤怒）
- 計算分數並排序，把最有問題的 issue 列出來
實際結果顯示：167 個 open issue 裡，156 個被 Jev 評為中性、11 個輕度不滿、0 個高度憤怒。最關鍵的案例包括「README 缺安裝說明（PI-6907）」、「Pi 在思考時卡在『Working…』（PI-10031）」、「macOS 長時間 session CPU 過高（PI-7730）」。
這個示範展示了 Codemode 不只是 MCP 的附屬品，而是一種全新的 agent 編程模式——在 context 預算內完成多步驟資料處理。
為什麼這件事重要
從一個曾公開拒絕 MCP 的團隊，到主動把 MCP 放進核心，這個轉變象徵意義大於技術意義。Earendil 的決定反映了 AI 編碼工具市場的三個現實：
第一，AI 編碼代理的標準化戰爭正在收斂。MCP 自 2024 年底由 Anthropic 提出後，經過兩年的快速演進，已經從「一個有爭議的協議」變成「不得不支援的基礎設施」。即使像 Pi 這樣有強烈產品哲學的極簡工具，最終也得妥協。
第二，「擁抱比批評更能改變生態」。Earendil 團隊自己點出這個策略：如果覺得 MCP 還不夠好，最有效的做法是進場改它，而不是在旁邊看。這個觀點對所有想影響開源標準的團隊都有參考價值。
第三，Pi 的極簡哲學並未消失，而是換了形式。MCP 從「外部擴充」升級為「核心功能」，看似違反極簡原則，但實際上團隊把 MCP、Codemode、Jev 整合成一個統一的工具協調層，反而比「核心 + 一堆擴充」更簡潔。
想更深入了解 Pi 的設計哲學，可以看 Mario Zechner 與 Armin Ronacher 的對談 podcast：
數據解讀：社群反應與真實採用意願
Hacker News 397 分、215 則留言的數字背後，有些值得拆解的訊號。
第一，反對派的聲音集中在「極簡派」。HN 留言區有不少長期 Pi 使用者表達擔憂：把 MCP 放進核心，會不會讓 Pi 變得跟 Claude Code 一樣臃腫？Earendil 的回應是「Codemode 是新型的極簡——把多步驟邏輯封裝成單一 JavaScript 區塊」，這是設計取捨問題，不是黑白對錯。
第二，「擁抱派」認為時機已到。有留言指出，MCP 在 2026 年的成熟度跟 2024 年完全不能比——結構化資料回傳、工具探索機制、認證標準都已經到位。Pi 現在加入 MCP，技術上是合理的時機點。
第三，真正考驗是後續的 MCP server 生態。文章直言：「很多 MCP server 是為把工具塞進 context、靠文字回傳節省 token 設計的。」這個批評反映出 Pi 對「高品質 MCP server」的期待——只支援 codemode 不夠，還需要 server 端配合改寫。這部分需要整個生態系配合，不是 Earendil 一家能推動的。
編按：本文綜合整理自 Earendil 官方部落格原文、Pi.dev 官網、Hacker News 討論串，並加入 Siami 編輯部觀點與分析。
網友熱門留言 (1)