MCP 的下一步：代理式訊息傳遞、Agent 身分識別，與單一 HTTP 傳輸層

Model Context Protocol（MCP）——這個已悄然成為 AI 模型連接工具、資料與彼此之事實標準的開放協定——剛剛拿到了下一階段的行動綱領。2026 年 8 月 22 日，首席維護者 David Soria Parra 與 Den Delimarsky 發布了全新路線圖，揭示五大優先領域，將決定接下來的規格版本走向，也將決定建立在它之上的代理式軟體生態系的架構樣貌。

時機點至關重要。MCP 已經跨越了從實驗性規格到生產環境基礎設施的鴻溝：它同時獲得 OpenAI、Google 與 Anthropic 生態系支援，被內建進 Claude Code、Cursor、Codex 等編程代理，也被企業用來把 AI 系統接上內部 API。當協定的維護者重新調整優先順序，成千上萬的下游開發者與廠商都會跟著轉向。這份路線圖發布後數小時內就衝上 Hacker News 首頁，討論熱度正反映了開發者社群的密切關注。

為什麼一個協定需要路線圖？

MCP 於 2024 年底問世，是 Anthropic 對碎片化問題提出的解答：每個 AI 應用都在發明自己的一套方式把模型接上外部工具。MCP 把這個介面標準化——一種主從式協定，由宿主應用程式（IDE、聊天客戶端、代理執行環境）連接到提供工具、資源與提示詞的伺服器。

在爆炸性成長的十八個月後，這個協定正被當初設計者未曾預期的工作負載考驗著。新路線圖對此毫不諱言：「現代的代理式工作負載已經不再符合標準的請求—回應模式。迴圈可以跑得更久、伺服器可以推送串流結果，而且明顯需要在執行中途導引工作。」

這句話就是整份文件的命題。後續的五大優先領域，全都源自同一個體悟：MCP 是為互動式應用設計的，但它如今最大的使用者，是自主運作的 Agent。

五大優先領域

1. 代理式訊息傳遞原語

第一項、也可以說影響最深遠的優先事項，是為 Agent 重新思考協定的訊息模型。MCP 已經長出了 Tasks、subscriptions/listen 與進度通知；路線圖現在正式承諾伺服器主動發起的事件——webhooks 與 channels，讓客戶端不必再輪詢結果——同時跨越 Agents、Transports 與 Triggers & Events 三個工作小組進行組合審查，並讓 Tasks 擴充功能（SEP-2663）成熟到可以進入核心規格。

實務上，這代表長時間執行的代理任務——一個跑二十分鐘的研究 Agent、一個管理建置管線的編程代理——將獲得協定層級的第一手支援，而不是各憑本事的變通做法。

2. HTTP 原生傳輸統一

隨著 2026-07-28 版本發布，遠端 MCP 伺服器已「與任何其他 HTTP 工作負載無異」——可以架設在組織既有 API 基礎設施上。路線圖進一步把這個模型延伸到其他部署模式，包括透過 stdio 講 Streamable HTTP 的本地伺服器。一種傳輸，走遍天下。對維運人員來說，這意味著 stdio 本地伺服器與 HTTP 遠端伺服器的精神分裂世界，將收斂為單一而簡單的部署故事。

3. Agent 身分識別與企業級安全

這可能是最雄心勃勃的項目：MCP 目前的授權模型「是圍繞著一個人在瀏覽器裡核准存取而建構的」。這對互動式客戶端沒問題，但正如路線圖指出，「愈來愈多的呼叫者是擁有自身身分、以雲端工作負載形式運行的 Agent，它們代表不在場的使用者行動，或把較窄的權限委派給子代理」。

計畫是給 MCP 伺服器一套標準化的方式來辨識並信任這些 Agent 身分——「建立在既有標準之上，而不是貼上 API 金鑰與長效權杖」。具體而言：完成 Demonstrating Proof of Possession（DPoP） 的定案並推動採用，透過 Workload Identity Federation、支撐企業託管授權的 ID-JAG 授權與標準權杖交換，為 Agent 身分與委派定義一條有主見的路徑。團隊也將持續與 IETF OAuth 及 WIMSE 工作小組合作，讓底層網路標準演化出 Agent 身分所需的建構元件。

這正是企業安全團隊引頸期盼的部分。「代表使用者行動的 Agent」與「為人類設計的 OAuth」之間的鴻溝，是目前大多數企業 MCP 部署卡關的地方——或者更糟，默默累積長效 API 金鑰帶來的風險。

4. 改進原語

工具呼叫——大多數開發者最先接觸的 MCP 部分——即將獲得打磨。路線圖點名兩個問題。第一，tools/call 回應可以用多種形式承載相同輸出，而伺服器開發者無從得知客戶端會把哪種形式呈現給模型；路線圖承諾「標準化為一個清晰的契約」。第二個問題更有意思：漸進式探索（progressive discovery）。連上一個有一百個工具的伺服器，意味著「在使用者還沒問任何問題之前，模型就得為整個工具面付出代價，而且工具清單愈長，選擇品質愈差」。解方——一個小入口，隨著對話聚焦逐步揭示更多目錄——直接打擊大型工具伺服器的上下文視窗經濟學。

5. 改進 SDK 開發者體驗

最後一項樸實但具戰略意義：SDK 的人體工學、規格一致性，以及所有支援平台與語言的文件品質。維護者特別指出，這在「許多開發者現在是把 Agent 指向我們的函式庫來建構 MCP 客戶端與伺服器」的時代愈發重要——等於承認這個協定自己的 SDK，正逐漸由 AI 編程代理來消費，而「清晰的 API 與準確的文件，決定了程式碼能否以最小摩擦運作」。

這對代理式技術堆疊釋出什麼訊號

綜觀五大優先領域，描繪的是一個從「AI 工具的 USB 插槽」成長為代理網路的神經系統的協定——具備標準化身分、可委派的權限、事件驅動的訊息傳遞與可規模化的探索機制。

對於在這個領域做建造的人，有幾個訊號值得注意：

• 企業拿到了答案。 透過 Workload Identity Federation 與 DPoP 實現的 Agent 身分，是受監管產業的解鎖鑰匙——它們原本無法把瀏覽器流程的 OAuth 套在無人值守的 Agent 前面。這些功能一旦進入規格，企業級 MCP 採用可望加速。
• 上下文經濟學成為協定層級的關切。 漸進式探索承認工具面的 token 成本是真實的稅。以窄入口加隨需深度設計的伺服器，將勝過大雜燴式的工具傾倒。
• HTTP 無所簡化了託管。 統一採用 Streamable HTTP——即使透過 stdio——意味著基礎設施團隊可以像經營任何其他網路服務一樣經營 MCP 伺服器：同樣的負載平衡器、同樣的可觀測性、同樣的安全工具。
• 治理模型運作正常。 這份路線圖由核心維護者與工作小組共同發展，功能透過 SEP 提案審查，並在 Linux Foundation 的 LF Projects 傘下運作。對一個承載如此重責的協定而言，無聊而可課責的治理是一項優點。

前方的路

路線圖也謹慎說明了它不是什麼：它不會自動拒絕優先領域以外的想法。但它明言「維護者的審查時間稀缺，會優先投入路線圖」。對提案作者而言，與這五大領域對齊，就是現在的快車道。

對更廣大的 AI 產業來說，這份文件是代理式基礎設施走向的清晰快照：遠離人類在迴圈中的請求—回應模式，走向能長時間運行、委派、串流，並以密碼學方式表明身分的機器。MCP 正在把它的未來押在成為那個世界的共同基板上——從這份路線圖背後的動能來看，這個賭注愈來愈穩。

規格工作是公開進行的：工作小組正在招募、SEP 開放評論，實驗性擴充功能可以在正式提案前依 SEP-2133 啟動。如果你正在打造 Agent，現在正是參與塑造它們未來賴以運作的管線的時刻。