Pi 1.0：Codemode、MCP 與 Durable，擴充性換來哪些代價？（2026）

2026 年 10 月 1 日，Earendil 在官網發布了〈Pi 1.0〉：這次 Pi 1.0 把 Codemode、MCP、虛擬模型與延後載入工具納入終端機 Coding Agent，同日另推出實驗性的 Pi Durable。這篇文章先還原原文的主張，再對照官方文件看功能邊界，最後判斷「小核心」能否承受更多擴充。

Pi 1.0 的主張：守住小核心，再開放更多接點

Pi is known for being minimal. We care about holding that line.

中文：Pi 以精簡著稱，團隊希望守住這條界線。

Earendil，〈Pi 1.0〉

這句話是全文的軸線。Earendil 說，會先等新做法證明有用，再衡量功能和複雜度；Pi 1.0 則是它對 Codemode、MCP 等能力做出的取捨。這不是單純的版本號更新：Pi 想保留可改造的 Agent 底座，同時讓模型、工具與對話控制有更多正式入口。原文宣稱每週有數十萬人使用 Pi，這是團隊自己的採用數字，它描述了採用規模的自述，不能單靠這個數字推導可靠性或生產力。

Pi 1.0 實際加入了什麼？

原文列出七項變化。最影響開發者的是前三項：

• Codemode 與 MCP：模型可寫一段 JavaScript，在受限沙盒裡搜尋、呼叫並組合工具；官方 Codemode 文件也說明它可呼叫分類器與影像模型。MCP 工具接入後可設定直接暴露、由 Codemode 呼叫、延後搜尋載入，或隱藏；所以「支援 MCP」並不等於每個工具都常駐模型提示。
• 虛擬模型：擴充套件可以註冊一個可選的模型名稱，逐次請求路由到實際模型。官方文件說明選擇的虛擬模型與真正回答的實體模型會分別記錄，成本也按實際模型呈現。原文的示範是先用 Claude 規劃，再按階段切到 GPT；那是示範工作流，不是每個安裝都會自動得到的路由。
• 延後載入工具：工具可先留在可搜尋清單，需要時才由 tool_search 宣告給模型。這有助於控制工具描述佔用的上下文，但工具是否好找、何時載入，仍要按自己的伺服器和任務驗收。

其餘四項是 Anthropic 模型的快取暖機、可在對話中段加入系統訊息並留下變更紀錄、新 TUI 主題，以及預設全螢幕。1.0.0 更新紀錄補充了全螢幕設定與 Codemode 的變更；快取設定文件也表明暖機受模型快取壽命和節省成本估算限制，不能把它理解成所有請求必然更快或更便宜。原文也提供 macOS／Linux 與 Windows 安裝方式，並標示 Pi 1.0 和 Pi Durable 均採 MIT 授權；要選擇安裝路徑，可從 Pi 官網進入。

Pi Durable：讓工作能接續，但不是「保證只做一次」

It does not replace the Pi coding agent.

中文：它不會取代 Pi Coding Agent。

Earendil Engineering，〈Pi Durable〉

這是最容易被版本新聞混在一起的邊界。Pi 1.0 仍以一個人在終端機操作的 Coding Agent 為中心；Pi Durable 是另行發布的實驗性套件，目標是讓應用跨程序重啟、從不同介面接入，並讓多個對話並行。它把模型請求與工具呼叫視為任務，先寫入檢查點，再執行下一步；重新開啟儲存後可找回未完成任務。原文列出記憶體、SQLite、JSONL 等儲存選項，但這描述的是提供的設計與套件能力，並不等於每個部署環境都已通過故障復原驗收。

更關鍵的是外部副作用。Durable 原文說明：中斷的模型請求會重送；中斷的工具呼叫，只有標記為可安全重跑時才重跑，否則把中斷交還模型判斷。它也用 requestId 去重同一筆提交。這些設計能減少重啟後「不知道做到哪裡」的問題，但對寄信、付款、部署等外部動作，真正避免重複執行仍取決於工具的重試規則與外部系統的冪等設計。可恢復執行與外部動作恰好一次，是兩個不同的保證。

我同意它的方向，也保留三個疑問

一、工具多了，真正的成本轉到配置與驗收

Pi 把 MCP 工具暴露方式與虛擬模型路由交給建構者決定，這讓不同團隊能按任務裁剪提示與能力。代價是配置也成為產品的一部分：同一個 Agent 若換了工具曝光方式、模型路由或權限，失敗點會變。對工程團隊而言，值得比較的不是功能清單長短，而是在相同任務下，工具找得到嗎、錯誤能復原嗎、操作紀錄能追嗎。

二、「精簡」是維護策略，不是品質指標

我同意 Earendil 延後收進新能力的原則：每個常駐工具和介面都會增加使用者與模型要理解的狀態。但「保持精簡」本身無法證明改動降低了故障率，也無法證明新手更容易上手。此處能確認的是架構選擇與功能入口；若要比較效率與穩定度，仍需在同任務、同模型、同成本條件下按工作負載測量。

三、Durable 的價值取決於失敗情境

長時間 Agent 真正難的，往往不是把對話寫到磁碟，而是程序在外部工具「已執行、回覆未保存」的時刻死掉。Pi Durable 的檢查點與重跑宣告正面處理這個邊界，這值得研究；但它目前被作者明確標為實驗性。若要放進實際服務，先以可逆的測試動作驗證：在工具回覆前後各中斷一次，核對任務紀錄、外部結果與重啟後的下一步，再決定哪一類動作可安全重試。若你的整合主要經過 MCP，MCP 逾時結果驗證可幫你設計外部收據與故障注入。

怎麼判斷 Pi 1.0 適不適合你？

若你主要在終端機做開發，而且想自己決定模型、工具與提示的邊界，Pi 1.0 值得拿一個小型、可回滾的任務比較：固定模型和提示，先用基本工具完成，再啟用一組 MCP 工具或一個虛擬模型，記下完成品質、工具誤用、上下文用量與人工修正時間。若需求是跨服務長跑，則把 Pi Durable 當作實驗框架，先驗證中斷與重試，別把展示中的接續能力直接當成正式環境保證。想先觀察 Pi 在受限本機環境的實際操作，可接著看Ling 3.0 Tiny＋Pi 本機任務。

Pi 1.0 的值得關注之處，是它把「可擴充」做成可選的入口，而非要求每位使用者接受同一套工作流。這種自由能否變成可靠成果，最後仍要看你的工具權限、模型路由與失敗測試是否設計得好。