小墨同學札記 · 文章導讀
Pi 為什麼又接納了 MCP
如果你更早接觸 Pi，大概記得它的官網曾經明確寫著“不支援 MCP”，作者在播客和文章裡也不止一次表達過對 MCP 的懷疑。可升級到 0.99.0 之後，你會發現 MCP 已經成了 Pi 的內建功能。2026 年 9 月 29 日，Earendil 發表了《“You Said No MCP!”》，專門回答這個轉變。
這篇導讀用我自己的話梳理文章的四個要點。想看原文論證，請讀英文原文。
一、不是突然改口，是 MCP 和 Pi 都變了
文章的出發點很樸素：世界不是靜止的。團隊過去一年一直在觀察 MCP，今天的 MCP 已經不是當初那個樣子。
但僅僅“MCP 變好了”並不足以讓它進入核心。Pi 本來就有成熟的擴充功能（Extension）生態，MCP 早就可以、也確實以擴充功能的形式存在過。真正讓團隊決定把它放進核心的，是重新思考之後發現：支援 MCP 所需的那些改動，本身對 Pi 也普遍有用。
二、到底變了什麼
我把文章裡的判斷歸納成三層：
| 層面 | 文章的判斷 |
|---|---|
| Pi 自己需要的 | 一個可以“玩耍”的沙箱，也就是一個直譯器。這恰好也是 MCP 需要的。同一套改動還讓 Pi 更方便呼叫 Jev 這類分類模型。 |
| MCP 仍然沒解決的 | 最大的問題依舊是難以組合。不過作者認為，這更多是現有 MCP 伺服器和各家代理框架（Agent Harness）用法的問題，而不是協議本身。 |
| 理想中的 MCP | 更接近“帶智慧發現能力的 OpenAPI”：工具返回結構化資料，並能靠文件和描述被找到，而不是一股腦塞進上下文、靠返回純文字省 token。 |
文章還給了一個對比：CLI 好用，是因為模型能用簡潔的 Shell 寫法把命令串起來。MCP 沒有理由做不到這一點。Pi 的做法是把 MCP 工具暴露給一個 JavaScript 沙箱，讓模型像寫指令碼一樣組合它們。
三、為什麼不只做 Codemode，不做 MCP
這是文章預料到的追問。回答分兩部分：
- Pi 的工具設定需要升級。 新一代模型支援延遲載入工具、對話中途插入系統訊息、切換推理強度，Pi 前幾個月已經為這些能力做了大量適配，但工具的“裝配方式”還沒跟上。在 Codemode 裡，每個工具都要決定：是直接給模型用，還是隻在 Codemode 指令碼里可見。普通的 MCP 擴充功能拿不到足夠的後設資料來做好這件事。
- 主動參與比旁觀更有影響力。 團隊認為 MCP 加上 Codemode，能解決 MCP 過去的不少毛病，而現有伺服器和使用模式仍有改進空間。與其站在場外看，不如參與進來，推動 MCP 在小巧的代理框架裡也好用。
這一點對應 0.99.0 更新記錄裡的工具暴露方式（直接、僅模型、Codemode、延遲、隱藏），可以在版本檔案裡對照檢視。
四、Codemode 是什麼
文章用“信賴邊界”來解釋。代理框架執行工具大致有兩個位置：
- Shell 執行的地方：通常在不太可信的沙箱裡。
- 代理框架自身的 Agent 迴圈執行的地方：通常是可信環境。
Codemode 特別之處在於它執行在代理框架這一側。最好把它理解成編排工具呼叫的機制：模型可以用 JavaScript 決定呼叫順序、並行呼叫、把多個工具的結果組合起來。因為它執行在代理框架側，它的狀態儲存在工作階段記錄裡，而不是檔案系統裡。
為什麼選 JavaScript？文章的解釋是，小型 JavaScript 執行時可以打包成 WASM，體積小，也能提供合理的隔離。按 0.99.0 的更新記錄，Pi 用的是 QuickJS 沙箱。
文章最後演示了一個例子：在 Pi 裡用一句話，讓 Codemode 透過 Linear 的 MCP 拉取 issue，再交給 Jev 分類模型逐條判斷評論語氣，最後彙總出情緒最激動的幾條。整個過程中，大量中間資料留在 Codemode 指令碼里處理，而不是灌進對話上下文。
對藍皮書讀者意味著什麼
- 新手不需要因此改變學習順序。 固定流程和檢查標準仍然優先寫成技能（Skill）；已有 CLI 能做好的事，仍然先用 CLI。參考手冊的 技能和 MCP 怎麼選 已按 0.99.0 更新。
- 設定了 MCP，Codemode 會自動載入；沒設定 MCP 也可以把 Codemode 加為預設工具。原文建議直接讓 Pi 自己改設定來啟用它。
- MCP 進入核心，不等於“裝得越多越好”。 每接入一個伺服器，都要承擔工具說明、認證和維護成本；先確認它解決了什麼具體問題，再接入。