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