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