MCPModel Context Protocol的規格更新在7月28日發布了一個重要改動傳輸層走向無狀態。如果你不在AI Agent開發的一線可能對這個變化沒什么感覺。但如果你正在用MCP協議構建Agent工具鏈這個改動會直接影響你的架構設計。先說說MCP協議是什么。它定義了AI模型和外部工具之間的通信標準——模型通過MCP協議調用工具、獲取數據、執行操作。過去一年里MCP在Agent開發社區里逐漸成為事實標準Claude Code、各種IDE插件、Agent框架都在用它。但MCP最初的傳輸協議有一個設計選擇——有狀態連接。模型和工具服務器之間建立的是長連接連接的整個生命周期里消息是相關聯的。這個設計的優點很明顯不需要每次都重新握手消息序列號可以簡化實現。但問題在于——長連接在Agent場景下并不總是最佳選擇。尤其是當Agent需要在多個工具之間快速切換、或者在不同進程之間傳遞上下文時。這次更新的核心變化是MCP的傳輸層現在支持無狀態模式。每個請求獨立攜帶認證信息和上下文服務器不需要維護客戶端狀態。這次改動包含了傳輸協議中狀態管理的全部重新設計——JSON-RPC消息的請求/響應機制變更消息確認機制的調整。從工程角度看這意味著什么第一水平擴展變得簡單了。在有狀態連接模式下需要做會話親和Session Affinity來保證同一個Agent的請求路由到同一個后端實例。這對負載均衡器配置、后端擴容都增加了復雜度。無狀態模式下任何后端實例都可以處理任何請求。如果你跑過Kubernetes上的Agent服務應該清楚session親和性帶來的調度限制——Pod擴縮容時需要重建連接滾動更新時會話會斷。第二故障恢復成本降低了。連接斷開不再意味著會話丟失。Agent只需要重新發送請求服務器端不需要重建狀態。這在Agent執行長任務時尤其有用——一個Agent任務可能持續幾分鐘甚至幾十分鐘保持連接的難度和成本都會累積。第三消息格式更加標準化。新的傳輸規范中請求頭攜帶了更豐富的能力協商信息包括安全策略、數據格式偏好和流控參數。這意味著客戶端和服務端之間不再需要提前約定數據格式而是運行時協商。不過問題在這里無狀態模式對每個請求的開銷更大。每次請求都需要攜帶認證信息和上下文元數據這對于短請求場景影響不大但對于長上下文推理——比如Agent帶著大量歷史信息調用工具——會增加網絡傳輸量。MCP團隊的做法是同時保留有狀態和無狀態兩種模式讓開發者根據場景選擇。對于延遲敏感、需要高頻調用的場景繼續保持有狀態連接。對于需要高可用、水平擴展的場景推薦使用無狀態模式。從協議設計的角度來看這次改動反映了MCP團隊對真實部署場景的理解。MCP最初的協議設計偏理想化——假設Agent和工具之間建立長連接后一直可用。但在生產中Agent經常需要在不同環境中切換上下文或者被調度到不同的計算節點上運行。從實現角度看如果你已經在用MCP的SDK官方的TypeScript、Python、Kotlin SDK升級到新版本后需要做兩件事一是檢查連接管理的代碼是否需要適配無狀態模式二是配置路由層讓服務支持無狀態請求。對開發者來說最直接的體驗變化可能是工具調用錯誤恢復變得更優雅了。現在的Agent在出現連接中斷后不需要重新建立完整的會話只需要重新發送失敗的那個請求就行了。這聽起來是個小改動——但站在傳輸層層面調整狀態管理涉及的實現改動不小。JSON-RPC的message id管理、并發請求控制、超時重試策略都需要重新設計。MCP團隊的roadmap里下一步是推動服務端SDK原生支持無狀態模式包括自動的上下文元數據注入和請求重試機制。從工程角度看這個方向是對的——狀態管理應該在框架層面解決而不是讓每個Agent應用自己實現。關于維基框架維基框架關注企業應用開發中的長期維護問題。在實際項目中業務系統往往同時涉及權限、微服務、接口協議、部署環境等復雜因素因此我們希望提供一套更容易擴展和維護的基礎框架。官網framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例項目gitee.com/cdkjframework/framewiki-example 許可證MulanPSL-2.0木蘭寬松許可證第2版