Pi.dev MCP 整合與 Codemode 的推出

Pi.dev 已正式將 Model Context Protocol (MCP) 整合至其核心功能中，改變了先前公開反對該協定的立場。此轉變是因 MCP 的演進以及對更強大工具呼叫協調機制的需求所驅動，Pi 透過推出「Codemode」——一個基於 JavaScript 的沙箱環境，來解決此問題。

將 MCP 整入核心

Pi 已將 MCP 從可選擴充功能轉為核心功能，因為支援 MCP 所需的架構變更被發現對整個系統普遍有益。具體而言，此整合使得在 Pi 中更輕鬆地使用 Jev 成為可能，並提供了 MCP 與 Pi 所需的必要解釋器沙箱。

儘管 Pi 承認 MCP 仍面臨挑戰——特別是在組合性方面——但團隊認為目前協定的狀態已顯著優於早期版本。Pi 對 MCP 的處理方式類似於 OpenAPI，強調智慧型工具發現，即工具回傳結構化資料，並可透過文件與描述進行發現。

Codemode：新的協調層

Codemode 是一個運行在 harness 側（即代理迴圈所在位置）而非工具側（即 bash 或其他外部程序運行位置）的 JavaScript 沙箱。它作為協調與指揮工具呼叫的機制，讓代理能使用 JavaScript 更靈活地組合多個工具，並控制執行順序。

Codemode 的關鍵技術特徵

執行環境：在 harness 執行的位置運行，表示其狀態作為會話轉錄的一部分被維護，而非儲存在本地檔案系統上。
實作方式：使用以 WASM 二進位檔分發的小型 JavaScript 版本，以取得保護與效能之間的平衡。
自動載入：當配置 MCP 時，Codemode 會自動載入，但也可透過 Pi 的設定作為預設工具啟用。
目的：它在直接的 JSON/XML 工具呼叫（安全但功能有限）與 Bash 執行（功能強大但缺乏內建安全性與類型檢查）之間取得平衡。

解決組合問題

引入 Codemode 搭配 MCP 的主要原因之一，是為了解決傳統 MCP 所面臨的組合問題。透過使用 JavaScript 沙箱，Pi 讓模型能更有效地串接工具。例如，使用者可要求 Pi 使用「typesafe/jev 透過 codemode 找出我們問題追蹤系統中情緒最不滿的 20 位使用者」，系統將結合 Linear MCP 與 Jev 進行分析，而不會浪費上下文。

社群觀點與技術論辯

此公告在開發者社群中引發了關於 MCP 與傳統 CLI 工具使用優劣的技術論辯。

支持 MCP 與 Codemode 的論點

相容性：部分開發者認為 MCP 提供了一個廣泛相容的生態系，類似 USB-C，廣泛採用比少數「最佳化」但碎片化的專有解決方案更具價值。
迭代開發：MCP 允許開發者更快地迭代工具介面，因為代理通常比硬編碼腳本更能容忍介面變更。
MCP 作為設定工具：使用者報告已利用 MCP 透過自然語言配置複雜的 macOS 應用程式，並利用現有的應用邏輯，而非要求模型從零開始撰寫複雜程式碼。

反對與替代方案

Codemode 的冗餘性：部分批評者認為 Codemode 是多餘的，因為 LLM 已經非常擅長使用 Bash 或 Python 腳本串接工具。
協定批判：部分使用者認為 MCP 本質上只是 REST API 或 OpenAPI 的替代品，並質疑為何不直接以標準 HTTP 協定起始。
複雜性：有人擔憂核心整合的趨勢會為原本簡潔且可擴充的 harness 增加「臃腫」。

"人們犯下的關鍵錯誤是，他們只從自己的工作流程與本地堆疊角度思考，而非團隊的工作流程與團隊的運營堆疊。" — @CharlieDigital