技術分享
Multi-Agent 架構模式：哪種協作拓撲配哪種任務
多數 Multi-Agent 專案的失敗，源於一開始沒選對協作拓撲，而不是 Agent 不夠強。本文用一張對照表，把主控-工作者、階層式、對等式、管線式四種拓撲各配上 LangGraph、Anthropic、CrewAI、OpenAI、MetaGPT 的真實用法與實測數據，教你怎麼選。
MCP 規格改版，十二個月的遷移時鐘已經開始走
Model Context Protocol（MCP）官方於 2026 年 7 月 28 日發布 2026-07-28 規格版，這是 MCP 問世以來幅度最大的一次改版：協定核心從「有狀態、雙向」改為「無狀態、請求／回應」，同時把 Roots、Sampling、Logging 三項功能正式列為棄用。四個 Tier 1 SDK（TypeScript、Python、Go、C#）當天同步更新，官方部落格提到這些 SDK 合計月下載量已接近五億次——受影響的不是少數實驗專案，而是整批已經進生產環境的工具鏈。
對決策者而言，該問的不是規格條文怎麼寫，而是三件事：手上哪些系統會受影響、遷移要花多少工、什麼時候必須做完。官方這次同步訂出正式的功能生命週期政策，棄用功能保證至少十二個月過渡期。這是好消息，但也代表時鐘已經開始走。
無狀態核心：省下的是基礎設施帳單
改版主軸是拿掉協定層的 session。舊版的 initialize 握手與 Mcp-Session-Id 標頭一併移除，每個請求自行攜帶協定版本與用戶端能力資訊。過去一條 MCP 連線會被綁在處理握手的那台伺服器上，要橫向擴充就得配 sticky session 或共用 session 儲存；新版之後，遠端 MCP Server 可以直接掛在一般的輪詢式負載平衡器後面。
對已經把 MCP Server 開放給外部或跨部門使用的企業，這是直接的成本與可靠度改善：少一層黏著設定、少一個共用狀態元件、擴縮容也不必再排空連線。代價是斷線不再能續傳——串流中斷等於該次請求作廢，用戶端必須以新請求重送；長時間任務則要改走官方的 Tasks 擴充，以輪詢方式處理。
不只是拿掉 session：三個會改寫串接方式的細節
除了架構層的變動，還有三項改動會直接影響既有程式碼怎麼寫。第一是 MRTR（Multi Round-Trip Requests）：伺服器不再主動向用戶端發請求，改為回傳 input_required 狀態並列出所需資訊，由用戶端補齊後重送原請求；所有回應也新增必填的 resultType 欄位。第二是標頭路由，Streamable HTTP 的 POST 必須帶上 Mcp-Method 與 Mcp-Name 標頭，讓 API 閘道與流量限制器不必解析 JSON 內容就能完成路由與授權——對已建置 API Gateway 的企業，這反而是省事的改動。第三是列表結果可快取，tools/list、resources/list 等回應必須帶上 ttlMs 與 cacheScope，用戶端可據此快取、減少無謂輪詢，也能提高 LLM 的 prompt 快取命中率。此外新增的 server/discover 為必實作方法，用來公告支援的協定版本與能力，是新舊版本相容協商的入口。
三個棄用功能：先盤點，再排期
Roots、Sampling、Logging 在過渡期內仍可運作，但新專案不應再採用。官方建議的替代路徑很明確：
- Roots：改用工具參數、資源 URI 或伺服器設定來傳遞目錄與檔案範圍。
- Sampling：改為直接串接 LLM 供應商的 API，不再由用戶端代為推論。
- Logging：stdio 模式寫入 stderr，或直接接上 OpenTelemetry。
另有兩項進入移除時程：2025 年就已軟性棄用的 HTTP+SSE 傳輸正式列管，應改用 Streamable HTTP；OAuth 2.0 動態用戶端註冊（RFC 7591）則讓位給 Client ID Metadata Documents。
授權加固：資安與合規的連帶功課
這次改版也補上授權層幾個實務漏洞：授權伺服器應依 RFC 9207 回傳 iss 參數，用戶端必須驗證後才能兌換授權碼；動態註冊時必須指定 application_type，避免 localhost 重導向被誤用；用戶端憑證明確綁定發證的授權伺服器，換一家就得重新註冊。若企業的 MCP 串接已經走過資安審查，這些條款很可能需要重新送評一次。
一份今天就能開始的盤點清單
不必急著全面改寫，但建議一個月內完成盤點：清點自建與外採的 MCP Server 各有幾套、分別由誰維護；確認每套是否用到 Roots／Sampling／Logging 或 HTTP+SSE；向外部供應商索取升級時程；把有狀態設計改成由伺服器發放、以工具參數傳遞的明確 handle；最後把遷移排進十二個月內的維運排程，而不是等功能真的被移除才動作。
恩梯科技協助企業把這類協定改版落地到既有系統：從盤點自建與外採的 MCP Server、標記各套用到的棄用功能與相依範圍，到改寫有狀態設計、補上授權加固條款，並把遷移排進十二個月內的維運節奏。我們的做法是先挑一套風險最低的服務試改、確認擴充與快取行為穩定後再擴大，把最容易被忽略的環節——外部供應商的升級時程——放在最前面確認。若你的團隊已經把 MCP 接進生產環境，卻還沒盤清這次改版會動到哪些地方，歡迎與恩梯科技討論，一起把規格改版從突發事件變成可預期的維運工作。
參考資料
- Model Context Protocol Blog，〈The 2026-07-28 Specification〉，2026。來源連結
- Model Context Protocol，〈Key Changes（2026-07-28 Changelog）〉，2026。來源連結
- Model Context Protocol Blog，〈Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here〉，2026。來源連結
- Model Context Protocol，〈Feature Lifecycle and Deprecation Policy〉，2026。來源連結
- Model Context Protocol，〈Deprecated Features Registry〉，2026。來源連結
- The Register，〈Model Context Protocol prepares to break with its stateful past〉，2026。來源連結
