MCP无状态化背后的真正逻辑

Anthropic在2024年11月推出的MCP協議已成為行業標準。在7月28日的新規範發布中，官方做出了一個大膽決定：彻底移除所有有狀態機制，包括握手、Session ID、服務器反向推送等。這看起來像是一場「史上最大改版」，評論區因此出現了「重寫」與「終於」兩派爭議。然而，這種恐慌往往是基於直覺的猜測。只要花10分鐘用grep命令自查，就能發現真相：90%的應用從未使用過Session ID，僅升級SDK即可；另外7%的應用僅涉及瑣碎改動或構造參數刪除。真正需要重構架構的，只有那2.5%將Session作為存儲介質的項目。官方對1000個開源服務器的調研充分驗證了這個結論的科學性。

新協議移除有狀態機制的根本原因在於解決水平擴展的瓶頸。過去的架構要求服務器為每個客戶端記賬，一旦單點故障就會導致整個Session鏈路中斷。新架構下，網關無需解析Body即可進行路由，負載均衡也能輕鬆進行輪詢。同時，官方在5月鎖定RC版本並預留10週驗證期，展現了對如此龐大改版的謹慎態度——TypeScript SDK一週下載量就超過4000萬。目前TypeScript和Python已發布正式版，其他SDK也在按計畫跟進，這個節奏反映出Anthropic對開發者生態的尊重。

新協議的核心創新是引入了「顯示句柄」（Opaque Handle）和「MRTR」（多輪重試）機制。顯示句柄本質上就是普通的工具參數，比如購物車ID。模型既能看見它，也能對其進行推理。但這裡有一條鐵律：持有不等於授權。句柄會進入聊天記錄和子代理提示詞，任何拿到這個字符串的人都可能發起調用。因此在有認證機制時，必須每次驗證句柄與身份的配對。如果沒有認證，句柄本身就要充當令牌，需要128位以上的高安全熵並限定生命週期。同時，新協議取消了握手機制，改為名為「Server Discover」的普通RPC調用。客戶端可以選擇不預先調用，直接發送請求；如果遇到版本不支持的情況，系統會返回帶有支持版本列表的錯誤碼，客戶端只需切換版本重試即可。

這次改版中最真正的危險點有三個。首先，推送式交互被徹底物理移除，無寬限期。過去服務器依賴SSE流向客戶端發起請求以獲取用戶確認或目錄信息，但新協議中這條通道完全消失。當客戶端協商進入新協議後，任何推送請求都會在本地拋出類型化錯誤。為了替代推送，新協議引入了MRTR機制：服務器返回一份問題清單，由客戶端作答後重新發起請求。所有交互式工具都必須優先改用這種方法，這是比其他廢棄特性的12個月過渡期更加緊迫的變更。其次，新協議引入了Request States字段，允許服務器在MRTR中打包狀態。但這是把雙刃劍：客戶端必須在不查看、不修改的前提下逐字節原樣回顯，而規範明確指出這個Blob數據本質上是敵意輸入，因為它經過了可能被篡改或重放的客戶端。開發者必須對其進行ROO、HMAC或AEAD的完整性保護和加密封簽，驗簽失敗時直接拒絕。第三，狀態安全完全由開發者負責。雖然規範要求服務端驗證Request States，但各SDK的默認保護機制存在差異，開發者必須依據具體使用的SDK進行獨立驗證。

迴歸具體工程實踐，幾個關鍵的陷阱暴露了這次遷移的複雜性。Lambda環境中首次調用成功但第二次調用崩潰，根本原因是Mangum在每次調用都重新進入生命週期，導致全局實例被反復初始化。MRTR機制會導致延遲統計失效，因為多輪重試導致請求ID發生變化，這會欺騙依賴ID關聯的監控工具，錯誤的關聯比不關聯更具破壞性。TypeScript中使用ErrorCode === 401作為類型判斷會導致許多錯誤路徑無法被正確捕獲。Python的HTTP客戶端改用系統信任庫後，缺乏系統CA的容器中會突然出現握手失敗卻沒有錯誤提示的情況。CORS規範的精確匹配要求原數據中的Redirect URIs必須包含端口號，曾有客戶端因漏寫端口號被授權服務器直接拒絕的真實案例。這些坑點的共同特徵是：都涉及狀態轉移和安全邊界的收緊。

面對這些變更，開發者不必盲目跟風全員重寫。官方至少為Route Sampling和Logging等廢棄能力提供了12個月的過渡窗口。舊服務器能否繼續無縫使用，取決於客戶端和SDK是否保留了版本協商的回退機制。當新客戶端遇到舊服務器且探測失敗時，它會自動回退至舊版握手流程。必須明確的是：升級SDK與啟用新協議是兩個完全獨立的決策。TypeScript默認保持舊版協商，需顯式開啟新協議；Python則默認自動探測。整個遷移節奏完全掌握在開發者自己手中。

立即需要執行的只有三件事。首先是審計Session依賴，花10分鐘時間用grep搜索「mcp-session-id」、「initialize」及舊傳輸類名稱，精準定位應用現狀。其次是在測試環境中安裝新版本並驗證。對於TypeScript項目可配合官方codemod進行升級。最後是嚴格按照兼容矩陣進行驗證，不僅要測試新舊客戶端與服務器間的連接性，還要全面覆蓋工具發現、錯誤處理、認證、超時、請求取消及負載均衡等核心場景。特別需要注意的是，舊客戶端遇到純新服務器時會發生硬失敗，因此在遷移期間新服務器最好提供一個能同時兼容新舊協議的端點。

未來的進展方向非常明確。首先是擁抱無狀態部署，因為協議層不再管理狀態，開發者必須時刻保持清醒——句柄需要自己鑄造，加密簽名需要自己實現，安全邊界也必須由自己親自劃定。其次是關注擴展生態，因為TESCS等實驗性功能正從實驗轉為正式，各SDK的支持度存在差異，這很可能成為下一個競爭焦點。同時也要注意規範的兩個顯著缺口：文件和二進制傳輸仍停留在草案階段，Token膨脹問題雖然官方最優實現需約15萬Token，但漸進式發現僅需2000Token左右，這尚未成為標配功能。