MCP Roadmap：長任務、Agent 身分與工具爆量，真正改的是什麼？（2026）

2026 年 8 月 22 日，Model Context Protocol 核心維護者 David Soria Parra 與 Den Delimarsky 在 MCP 官方部落格發布了〈The New MCP Roadmap〉。這份 MCP Roadmap 把長任務、HTTP 傳輸、Agent 身分與委派、工具結果，以及漸進式工具探索列為接下來的優先方向；真正值得注意的，不是又多了五張功能清單，而是 MCP 正從「讓模型接上工具」的接頭，往「讓無人值守 Agent 能長時間、安全、可擴充地工作」的協定底座移動。

先把原文放在桌上。點擊下面的瀏覽器截圖，會在新分頁開啟完整文章；接下來先忠實整理維護者說了什麼，再分清哪些已經進入 2026-07-28 規格、哪些仍只是非約束性的 Roadmap，最後才判斷這條路能不能解掉 production Agent 最難的幾個問題。

---

MCP Roadmap 不是功能發布：先看清已上線與未上線

這篇原文最容易被誤讀的地方，是把「回顧」與「預告」寫在一起。維護者先回顧 7 月 28 日的大改版，再提出未來五大方向。官方 Roadmap 文件給的是未來 6 到 12 個月的方向，同時明示這些內容「不是堅定承諾」，項目可能換做法、延後，甚至改變優先順序。因此，任何把五項工作寫成「下個版本一定上線」的說法，都比原文走得更遠。

議題	2026-07-28 已有的底座	這次 Roadmap 才要推進的事
長任務與訊息	MRTR、subscriptions/listen、進度通知；Tasks 是雙方都要選擇啟用的官方 extension	webhook／channel 等 server-initiated events、跨工作組生命週期整合、讓 Tasks 逐步走向核心規格
傳輸	新版協定層移除 session 與初始化握手；遠端 Streamable HTTP 可無黏著 session 運作	HTTP/2 over stdio、ETag、跨介面的錯誤語意與安全設定
身分與安全	授權 issuer 驗證、issuer-bound client credentials、CIMD；另有 Client Credentials 與 EMA extension	DPoP 採用、workload／Agent 身分、使用者委派、子 Agent 權限縮減
工具與資源	tools/list 等完整結果可帶快取提示；tools/call 仍可同時回傳多種內容形態	統一工具結果契約、漸進式探索、讓 client 不必先吞完整 catalog
SDK	已有 conformance 與 SDK tiering	釐清 extension contract，實驗從規格生成 SDK 與 quickstart，再用 conformance 驗證

截至 2026 年 8 月 25 日，這篇文章在 Hacker News 討論累積 269 points、160 則留言。熱度是真的，但意見遠非共識：討論最集中在「HTTP 是否該成為本機 IPC 的共同外殼」與「OAuth／DPoP 這套身分工程是否過重」。這些留言能證明開發者在爭論什麼，不能代表整個 MCP 生態已經接受答案。

五大優先領域，其實在補三個控制面

原文把工作分成五類，但若從 Agent 執行一個真實任務的路徑看，核心問題只有三個：時間、權限、選擇空間。HTTP 與 SDK 則是讓這三件事能跨語言、跨部署環境一致運作的橫向基建。

• 時間控制面：任務可能跑幾分鐘、幾小時，途中需要進度、取消、補資料、重連與完成通知。
• 權限控制面：執行者不一定是坐在瀏覽器前的本人，可能是雲端 Agent，也可能是它再派出的子 Agent；每一層都要知道「誰代表誰、能做什麼、何時失效」。
• 選擇空間控制面：工具從 10 個長到 100 個，全部塞進 prompt 會吃 context；只載入一小部分，又會多出「找漏工具」的新風險。

一、長任務：協定不能只會「問一次、答一次」

維護者用一句話定義第一個轉折：

Modern agentic workloads no longer fit the standard request-and-response pattern.

中文：現代 Agent 工作負載，已經裝不進標準的一問一答模式。

— The New MCP Roadmap

這個診斷成立，但「MCP 已經支援長任務」需要拆細。Tasks 目前是官方 extension，不是核心規格；client 與 server 都要宣告支援，實作覆蓋也不一致。它可以用 durable task handle 表示工作狀態，輪詢是預設路徑，支援通知的 client 才能透過 subscriptions/listen 接收更新。Roadmap 要補的是 webhook／channel 等 server-initiated events，以及取消、錯誤、輸入需求能否共享同一套生命週期。

另一個已經進入 2026-07-28 核心規格的 MRTR，也不能和「server 主動推播」畫上等號。MRTR 是 server 在回應裡表示還缺輸入，client 收集答案後重送原請求；它解掉 stateless transport 中途向使用者提問的問題，卻不是任意時間從 server 發起訊息。把 MRTR、Tasks、progress 與未來 events 合起來後是否真的只有一套取消與錯誤語意，才是這條 Roadmap 最實際的驗收題；webhook／channel 還要明說 delivery guarantee、排序、去重、重播、backpressure、重連與 idempotency，否則「有事件」仍不等於「任務可恢復」。

二、Agent 身分：DPoP 能防偷票，卻不能替你決定權限

原文第二句關鍵話，點出今天常見流程的預設：

MCP authorization today is built around a person approving access in a browser.

中文：今天的 MCP 授權，主要圍繞著一個人在瀏覽器裡批准存取。

— The New MCP Roadmap

這句話描述的是核心互動模型，不等於「MCP 完全沒有 headless auth」：官方已經有 OAuth Client Credentials extension，企業環境也有穩定但可選的 Enterprise-Managed Authorization。Roadmap 本身仍要定義共同路徑的是：一個 Agent 以自己的 workload identity 呼叫服務時，如何證明它代表哪個使用者，又如何把比自己更窄的權限交給子 Agent。

Roadmap 列出的技術積木各自解不同問題。DPoP（RFC 9449）把 access token 綁到持有者的金鑰，降低 token 外洩後被別人重播的風險；它證明「呼叫者握有這把鑰匙」，不會自動回答「這個 Agent 該不該刪資料」。OAuth Token Exchange（RFC 8693）區分 delegation 與 impersonation，能攜帶「誰代表誰」的鏈；至於 workload identity、跨信任網域與 Agent 鏈式委派，MCP 所倚賴的 WIMSE 仍有多份 Internet-Draft 在演進。

所以這一區最難的，不是再發一種 token，而是把權限縮減、撤銷、歸因與人類在場狀態做成不同廠商都能互通的語意。若只把長效 API key 換成短效 token，卻讓每一個子 Agent 繼承父 Agent 的完整 scope，外型變現代了，爆炸半徑沒有真正縮小。AlphaLab 已在 Agent Runtime Controls 拆過身分、權限、撤銷與歸因四道閘門；這次 Roadmap 的價值，就是承認這四道閘門不該永遠由每個產品各做一套。

三、工具爆量：漸進式探索省了 context，也新增召回風險

原文用「一個 server 有 100 個 tools」描述問題：在使用者還沒問第一句之前，eager client 就可能先把整份工具 catalog 放進模型 context。這不是 MCP 規格強迫所有 client 採用的行為，而且工具數量本身也不是通用的失敗公式；真正影響負擔的還包括 schema 序列化後的 token、工具語意重疊程度、排列位置與模型能力。

Anthropic 曾在自己的平台測試 deferred loading，回報大型工具庫的 token 與選擇準確率都有改善；但那是廠商內部結果，不是跨模型、跨 client 的通用保證。它也說明按需工具搜尋在 client／API 層早已能做，這次 Roadmap 的新意不是發明 lazy loading，而是嘗試把 server 與 client 之間的漸進探索做成共同協定。

獨立研究提供了另一半答案。ACL 2025 的 ToolRet 研究用 7,615 個任務與 43,215 個工具測試 retrieval，發現一般資訊檢索很強的模型，到了工具檢索仍可能表現不佳，而且 retrieval 品質會拖累最終任務通過率。換句話說，漸進式探索不是把問題消失，而是把問題從「prompt 裝不下」換成「retriever 能不能把正確工具找回來」。

這裡還有三個很像、其實不同的 discovery：

• server/discover：已在 2026-07-28 規格中，client 對一個已知 server查詢版本與 capabilities。
• Server Card／.well-known：讓 registry 或其他系統在連線前理解 server，仍由工作組推進。
• progressive discovery：這次 Roadmap 的未來工作，讓 client 隨對話收斂才逐步取得工具與資源。

三者混在一起，最容易把未來功能誤寫成已上線。現有的 SEP-2636 Progressive Tool Disclosure 截至本文研究日仍是 open Draft、沒有 sponsor，Roadmap 也尚未把其中的 tools/catalog 或搜尋方法定為最終設計。

想先在自己的系統實作「Search → Inspect → Execute」代理層，可接著看 MCP 工具搜尋與 Lazy Schema Loading；真正要驗收的指標不是只看省下多少 token，還要一起量 required-tool-set recall、錯工具率、額外延遲、快取命中、stale schema／TOCTOU 與 metadata poisoning。

四、HTTP 統一：少維護一套協定，還是把複雜度搬進 stdio？

2026-07-28 已把遠端 MCP 改造成更接近普通 HTTP workload 的樣子：協定層 session 與初始化握手被移除，每個 request 自帶版本與 client 資訊，gateway 可讀 header 路由，完整 list 結果能帶 TTL 與 cache scope。這裡要精準一點：stateless 的是新版協定層，不是宣告所有應用都不再需要狀態；購物車、瀏覽器 session、長任務 handle 仍可能存於應用層。

未來方向更激進：連本機 stdio 也考慮承載 Streamable HTTP，官方 Roadmap 寫的是「相信可用 HTTP/2 over stdio」；但 Transport Working Group 的公開 strawman 連 HTTP/1.1 或 HTTP/2、是否成為新 transport，以及本機授權語意都仍列為 open decisions。好處可能是 SDK 少維護一條語意分岔的 transport pipeline，header、狀態碼與快取概念也能共用；代價是原本極薄的 newline-delimited JSON-RPC 本機路徑，會多出 HTTP framing、flow control 與實作相容性的成本。Hacker News 對這一點的分歧並非誰「不懂標準」，而是兩種合理優先順序：一派要操作一致性，一派要本機路徑保持簡單。最後該由跨 SDK 的故障率、效能、除錯與遷移成本裁決，而不是由「HTTP 到處都有」這句話裁決。

五、SDK 與結果契約：標準真正的產品，是互通性

工具結果看似小題，卻直接影響模型看到什麼。現行 tools/call 規格允許 content 與 structuredContent 同時存在，不同 client 可能選擇不同形態送給模型。Roadmap 想統一結果契約，價值不在少一個欄位，而在相同 server 回到不同 client 時，不再暗中改變模型輸入；真正完整的契約還得處理 provenance、prompt injection、大型 blob／stream、partial result、schema migration 與舊版相容。

SDK 方向也透露同一個企圖：把規格與人類審查過的 conformance suite 當成 source of truth，再實驗生成 Tier 1 SDK 與 quickstart。這能減少「文件改了、四個 SDK 各自追」的漂移，但也要防止把同一個生成錯誤一次複製到所有語言。真正的安全網不是「由模型生成」或「由人手寫」哪個標籤，而是可重跑的互通測試、版本矩陣與明確 extension contract。

---

AlphaLab 的判讀：方向對了，但成功不等於 SEP 變多

判讀一：MCP 正在承認 Agent 的三個成本不是模型能自己猜掉的

時間、權限與工具選擇，都屬於系統語意。再聰明的模型，也無法只靠推理知道一個 task handle 能保留多久、某個 token 能否委派、某個 client 會把哪種 tool result 放進 context。把這些條件從「各家默契」提升成可測的協定，是這份 Roadmap 最有價值的地方。

判讀二：身分是必要條件，卻不是最小權限的替代品

Agent 有自己的 identity，能改善稽核與 token 綁定；但一個能被辨識的 Agent，仍可能拿著過大的權限做錯事。下一步若只展示 DPoP 驗證成功，卻沒有 parent → child 的 scope attenuation、即時撤銷與 actor chain，Roadmap 只完成了門禁卡，還沒完成權限治理。

判讀三：漸進式探索的 KPI 應該是「不漏」，不只是「省」

token 節省很好量，也很適合做發布會數字；漏掉正確工具則更難被看見，因為 Agent 往往會用錯工具完成一個看似合理的答案。未來規格若沒有標準 eval corpus、Top-k recall 與 fallback 行為，progressive discovery 可能把 context 成本換成沉默失敗。可以參考 MCP vs CLI Token A/B Test 的做法，把 schema、cache、retry 與結果回填分開計量，不要把所有差異歸因給協定名稱。

判讀四：最大的風險不是設計太多，而是只實作一半

Roadmap 同時觸碰 transport、events、identity、tool contract 與 code generation，範圍很大。若每個 client 只挑最容易的一半，MCP 會得到更多 capability flags，卻不一定得到更好的互通性。Tasks 已經示範了這個現實：規格存在，不代表 host 都能用。每一項新能力都需要 support matrix、conformance case、legacy fallback 與清楚的失敗語意。

我同意什麼，又存疑什麼？

我同意的：MCP 維護者抓到了 production Agent 的真問題。下一階段的瓶頸不只是「模型會不會 call tool」，而是長任務能否重連、權限能否縮減、工具能否按需找到，以及相同規格能否在不同 SDK 得到相同結果。這些都是該由公開標準承擔的公共基建。

我存疑的：五條線同時推進，很容易讓「協定統一」變成「所有複雜度都進協定」。HTTP over stdio 是否真的降低總成本、Agent delegation 是否能跨 IdP 互通、progressive discovery 是否能在省 context 的同時維持 recall，目前都還需要實作與測試回答。Roadmap 的誠實之處，正是沒有替這些問題假裝給出交付日期。

現在要怎麼做：別等 Roadmap，先留下可對帳的基線

如果你正在建 MCP client、server 或 Agent，今天最務實的動作不是預先押注每個草案，而是先把未來遷移需要比較的基線存下來：

1. 釘選 protocol revision 與 SDK 版本。把 2026-07-28 與 legacy 路徑分開測；若要理解 session 遷移，可接著讀 Stateless MCP。
2. 把長任務當狀態機。記錄 start、input_required、cancel、reconnect、terminal result 與 expiry，不把「連線還在」當成任務還活著。
3. 把授權拆成 identity、scope、delegation、revocation。高風險工具維持執行時再授權，子 Agent 預設拿更窄 scope。
4. 為工具 catalog 建立 A/B 基線。同一組任務比較全部載入與按需探索，至少量 token、P95 latency、Top-k recall、錯工具率與任務通過率。
5. 把 extension support 當相容性矩陣。不要因為規格有 Tasks、EMA 或通知，就推定使用者的 host 已實作；未支援時要有明確退路。

接下來真正值得追的，不是下一篇 Roadmap 又新增幾個名詞，而是五個能被外部驗證的訊號：Tasks 的 client matrix 是否擴大、HTTP over stdio 是否有跨 SDK prototype、DPoP／WIF 草案是否進入可互通 profile、progressive discovery 是否公開 recall benchmark、生成 SDK 是否真的通過同一套 conformance。當這五件事開始有跨廠商證據，MCP 才算從「共同方向」走向「共同能力」。