---
title: "MCP 2026-07-28 改了什麼？無狀態核心與企業部署指南（下）"
description: "整理 MCP 2026-07-28 規格的無狀態核心、MRTR、HTTP 路由、OAuth 強化、Tasks Extension 與淘汰政策，轉成企業可執行的遷移清單，說明移除 handshake 與 session、HTTP Gateway 路由、MRTR 取代長連線，以及企業立即檢查與新專案建議。"
canonical: "https://yotron-ai.com/blog/mcp-api-cli-guide-2026-part-2"
published: "2026-08-28"
last-updated: "2026-08-28"
---

# MCP 2026-07-28 改了什麼？無狀態核心與企業部署指南（下）

整理 MCP 2026-07-28 規格的無狀態核心、MRTR、HTTP 路由、OAuth 強化、Tasks Extension 與淘汰政策，轉成企業可執行的遷移清單，說明移除 handshake 與 session、HTTP Gateway 路由、MRTR 取代長連線，以及企業立即檢查與新專案建議。

上一篇把 MCP 放回 CLI 與 API 的分層中。本篇處理更實際的問題：2026-07-28 規格為什麼大改，以及已建置 MCP Server 的團隊現在要改什麼。

## 這次是底層重建

MCP 官方將核心改成無狀態（stateless）的請求／回應架構。Inside 的分析也指出，這次改版主要是為了支撐 Serverless、邊緣運算、負載平衡與生產流量，而不只是增加幾個 API。[Inside 報導](https://www.inside.com.tw/article/41971-mcp-2026-07-28-spec-stateless-core-anthropic)

## 1. 移除 handshake 與 session

新版移除：

- `initialize` / `initialized`
- `Mcp-Session-Id`
- 協定層級的 session affinity

每一筆請求都自行攜帶協定版本、Client 身分、能力與必要的 `_meta`。若要事先探索能力，可使用可選的 `server/discover` RPC。

結果是請求可以被一般的 round-robin load balancer 分配到任何 Server instance，不必共享 session storage。狀態仍然可能存在，但應由應用層以 handle 或任務 ID 管理。

## 2. HTTP Gateway 可以直接路由

Streamable HTTP 請求可帶上：

```http
Mcp-Method: tools/call
Mcp-Name: search
```

Gateway、WAF 與服務網格不必先解析 JSON，就能依工具名稱做路由、授權、計費、稽核與流量限制。

## 3. MRTR 取代長連線互動

工具若執行到一半需要使用者補資料，Server 可回傳：

```text
resultType: "input_required"
```

Client 取得答案後，將資料放入 `inputResponses` 再重送請求。這種 Multi Round-Trip Requests（MRTR）不需要持續開啟雙向串流，較適合雲端與暫態連線。

## 4. 工具清單可快取

`tools/list`、`resources/list` 與 `prompts/list` 的回應增加快取提示與確定性排序。企業可以降低重複探索成本，也能減少重新連線造成的提示快取失效。

## 5. OAuth 與企業身分治理強化

新版要求 Client 驗證 OAuth Authorization Server 的 `iss`，降低 mix-up 攻擊風險；憑證也會綁定核發它的 issuer。

DCR（Dynamic Client Registration）開始走向淘汰，長期方向改為 CIMD（Client ID Metadata Documents）。這讓 MCP 更容易接入 Entra、Okta 等企業 IdP。[官方規格公告](https://blog.modelcontextprotocol.io/posts/2026-07-28/)

## 6. Tasks 改成正式 Extension

Tasks 從核心協定移到：

```text
io.modelcontextprotocol/tasks
```

長時間工作可以使用：

- `tasks/get` 查詢狀態。
- `tasks/update` 回報進度。
- 明確的 task handle 管理多次呼叫。

MCP Apps、Tasks 與 Enterprise Managed Authorization（EMA）都納入正式的 Extension framework。長任務與互動式 UI 可以獨立演進，不必每次都修改核心協定。

## 7. 企業需要安排的遷移

### 立即檢查

- 是否依賴 `Mcp-Session-Id` 或固定 Server instance。
- 是否仍使用舊版 HTTP+SSE transport。
- 是否依賴 Roots、Sampling、Logging。
- OAuth 是否驗證 issuer 與 resource indicator。
- 長任務是否有 handle、過期時間、權限檢查與回放紀錄。

### 新專案建議

1. 優先採用無狀態 HTTP。
2. 以 API Gateway 或 WAF 管理 MCP 流量。
3. 高風險工具先維持 read-only 或 draft-only。
4. 長任務採 Tasks Extension，不自行發明 session 協定。
5. 使用官方支援新規格的 TypeScript、Python、Go 或 C# SDK。

## 8. 無狀態不等於無治理

狀態從協定層移到應用層後，責任反而更清楚。企業必須自己管理：

- handle 與 task 的生命週期。
- 每位使用者的資料隔離。
- 工具白名單與最小權限。
- 人工審批與不可逆操作確認。
- 每次工具呼叫的 audit log。
- 失敗時的停止、轉人工與回滾路徑。

MCP 能讓 AI 使用工具，但不會自動替企業完成授權、稽核與風險治理。

## 9. MCP 接下來的改革方向

2026-08-22 發布的官方路線圖，將後續工作集中在五個方向：

- Agentic messaging primitives。
- HTTP-native transport 的統一與強化。
- Agent identity 與企業級安全。
- 更完整的工具與任務原語。
- 更好的 SDK 開發體驗與治理流程。

官方也建立 Contributor Ladder、Working Groups 與正式 feature lifecycle，代表 MCP 正從快速成長的協定，走向有版本治理與企業採用規範的基礎設施。[官方路線圖](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)

## 結論：先保留 API，再增加 AI 工具層

MCP 的正確落地方式不是把現有 API 全部改掉，而是：

```text
既有 API / CLI
      ↓
MCP Server 工具層
      ↓
AI Agent + 權限 + 稽核 + 人工審批
```

2026-07-28 之後，MCP 更容易部署與擴充；同時，狀態、權限與復原責任也更明確地回到應用與企業治理層。

## 來源

- [MCP 官方：2026-07-28 Specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/)，2026-07-28。
- [MCP 官方：2026-07-28 Changelog](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/changelog.mdx)，2026-07-28。
- [MCP 官方：New MCP Roadmap](https://blog.modelcontextprotocol.io/posts/mcp-roadmap/)，2026-08-22。
- [INSIDE：MCP 新版規格上線](https://www.inside.com.tw/article/41971-mcp-2026-07-28-spec-stateless-core-anthropic)，2026-07-30。

---

## 相關推薦與延伸閱讀

- [AI Agent 進入 Production 前，FDE 要先建好控制面](/blog/ai-agent-production-control-plane-fde)：企業 AI Agent 的關鍵不是 demo，而是把權限、成本、觀測、評估與人工升級，做成可營運的控制面。本文從三個近期訊號說明權限、成本與安全為何要一起設計，
- [MCP、API、CLI 差在哪？AI 系統介面的 2026 白話指南（上）](/blog/mcp-api-cli-guide-2026-part-1)：用實際工作流拆解 CLI、API 與 MCP 的角色差異，說明為什麼 MCP 不是 API 的替代品，以及企業該如何選擇正確介面。本文以一張表比較三種介面，說明
- [台灣企業導入 AI Agent：真正要算的不是 token，而是工作流成本](/blog/taiwan-enterprise-ai-agent-workflow-cost)：AI Agent 正從聊天工具進入企業工作流。評論台灣 B2B 與製造業導入時，為什麼要先規劃成本與權限、釐清資料的業務脈絡，並訂定可驗證的成果。文中整理報價彙