若您曾瀏覽 pi.dev，會發現其上自豪地宣告 Pi 不支援 MCP。若您收聽我們談論 Pi 的播客，也會聽到我們不止一次對 MCP 表示不屑，包括 Mario 的一篇相關貼文。然而，若您升級到 Pi，將會發現 MCP 已成為一項支援的功能。究竟發生了什麼事？
首先要記住的是，世界並非靜態。過去一年來我們一直在關注 MCP，而今日的 MCP 已非昔日可比。不過，這本身並不足以成為將其納入核心的理由。眾所周知，Pi 擁有龐大的擴充功能生態系，MCP 難道不能是個擴充功能嗎？甚至可能是 Earendil 認可的擴充功能。是的，您說得對，MCP 確實曾是個擴充功能。MCP 之所以現在成為核心的一部分，是我們集思廣益、重新思考的結果。
我們將 MCP 納入核心的原因，不僅在於 MCP 本身的變化，更因為我們發現所需的變更普遍都有用。例如，我們為 MCP 所做的變更，也讓 Pi 能更輕鬆地使用 Jev。最終，Pi 所需的與 MCP 所需的相當相似：一個以直譯器為形式的沙盒。
雖然 MCP 有許多改進之處，但也有不少地方並未如此。MCP 最大的問題仍然是難以組合。即使是 Codemode，一個允許組合工具呼叫的簡潔沙盒，MCP 在這方面仍未完全實現。但這 at this point 已不再是 MCP 本身的問題，而是現有的 MCP 伺服器和各種協調器的工作方式。
許多 MCP 伺服器仍是為那種將工具傾倒到上下文（context）中，並試圖透過回傳文字來優化代幣效率的協調器而建構。我們目前對 MCP 的看法是，它應該更接近 OpenAPI，並具備智慧工具發現功能。這意味著工具應該回傳結構化資料，並且工具應該能透過其文件和描述被發現。
命令列介面（CLI）之所以如此功能強大，是因為代理（agent）和模型僅透過高效的 bash 技巧將事物串聯起來。但這其中並沒有根本原因阻止 MCP 也能做到這一點。Pi 中的 MCP 僅是將這些工具暴露給 JavaScript 沙盒，就像 Codex 等其他協調器一樣。
這會引發一個問題：為什麼我們不直接在沒有 MCP 的情況下實現 Codemode？部分答案與 Pi 目前表達工具的方式有關。近幾個月來，我們做了大量工作，讓 Pi 能夠理解支援延遲工具載入、對話中系統訊息和推理層級變更的新模型。然而，我們尚未升級我們的工具載入機制，以更好地適應這些新功能。
在 Codemode 的世界裡，需要決定工具是提供給 LLM 還是僅提供給 LLM 的 Codemode 部分。一個標準的 MCP 擴充功能，從 Pi 的工具載入機制中獲得的元資料（metadata）不足以讓這種體驗順暢運作。因此，我們需要確保工具可以被設定為延遲載入，或僅作為 Codemode 特定的功能。
雖然我們可以透過串聯元資料來啟用更好的 MCP 擴充功能，但我們也認為 MCP 與 Codemode 結合，解決了它傳統上的一些問題。我們相信，正面影響某件事的最佳方式是擁抱它。雖然我們認為現代 MCP 比以往任何時候都處於更好的位置，但伺服器和模式仍有改進的空間。因此，我們希望參與其中，並幫助塑造它，使其能在小型協調器中良好運作，而不是袖手旁觀。
既然我們談論了這麼多 Codemode，或許值得解釋一下它到底是什麼。當協調器執行工具時，它主要有兩個部分：可以在 bash 執行的部分，或可以在協調器代理迴圈（agent loop）執行的部分。這兩部分的信任等級差異很大。協調器迴圈通常在一個受信任的環境中執行，而它執行的工具經常在一個並非真正受信任的沙盒中執行。
Codemode 很特別，因為它在協調器執行的位置執行。最好將其理解為一種協調和組織工具呼叫的機制。它是一個沙盒，允許代理以更靈活的方式發出工具呼叫，決定執行的順序，並允許它使用 JavaScript 將它們組合起來。由於 Codemode 也在協調器端執行，其狀態也會作為會話記錄（session transcript）的一部分來維護，而不是儲存在檔案系統中。
理論上任何語言都可以，但 JavaScript 非常有吸引力，因為小型版本的 JavaScript 可以作為 WASM 二進位檔進行分發，並提供合理的保護等級。
在 Pi 中，當配置 MCP 時，Codemode 會自動載入，或者可以將其作為預設工具添加到配置中。只需要求 Pi 重新配置自身即可啟用 Codemode！然後您就可以用它來做一些非常有趣的事情，而不僅僅是 MCP。例如，當您登入一個提供「Jev」的供應商時，您可以做到以下事情：
使用 typesafe/jev 透過 codemode 在我們的 issue tracker 中尋找 20 位最不滿的評論者
它將巧妙地結合 Linear MCP 和 Jev 等工具來進行分析，直接在 Pi 中完成，而不會浪費任何上下文。
