ExplainThis 全端開發雙週報 #85 從 MCP 核心協定轉為無狀態，談有狀態與無狀態的設計如何取捨

嗨～歡迎閱讀第 84 期 ExplainThis 全端開發雙週報！

在進到正式的內容前想與大家分享，在這週 ExplainThis 的 E+ 會員方案 (連結)，上架了《寫出好維護的程式碼 (下) — 日常開發中的實用方法》。對比起先前在《寫出好維護的程式碼 (上) — 經典的程式設計觀點》以經典理論為主，這門新課程專注在每天寫程式時都可以運用上的方法。

想提升自己程式碼品質，讓自己能寫出更好維護的程式碼的讀者，歡迎加入 E+ 會員 (連結) 觀看～

備註：如果所任職的公司有教育補助，透過補助購買，E+ 會開立有統編的發票。不用花自己的錢，也能每週透過深度主題文與社群交流，拓展技術視野、加速職涯成長。上個月有超過一半的新會員是透過教育訓練補助購買 E+ 。

從 MCP 核心協定轉為無狀態，談有狀態與無狀態的設計如何取捨

不論在前端或後端，在做軟體設計與開發時，不免會遇到要有狀態 (stateful) 還是無狀態 (stateless) 這個問題。在面試中也經常會有面試官問「XX 在設計上是有狀態的還是無狀態的? 為什麼?」，這邊的 XX 可以帶入許多不同的技術名詞，例如驗證 (auth) 上可以選有狀態的 session-based 或無狀態的 token-based，在通訊 (communication) 上可以選有狀態的 WebSockets 或無狀態的 HTTP。

而近兩年在社群中非常熱門的 MCP，也從最開始的有狀態協定，在這一週正式改為無狀態的核心協定 (連結)。要了解這個改變，就需要了解有狀態與無狀態設計該如何取捨，而這也是在面試中經常會出現的問題。

要能夠回答好這個面試問題，或者在工作上做技術決策時要能選到合適的，就需要理解這兩種選擇會遇到的取捨。在這篇文章，我們會透過實際的案例，來討論兩者的區別與取捨。

從驗證的角度看有狀態與無狀態

在 90 年代的網頁開發，session-based 是主流的驗證方式。session-based 的驗證方式會需要透過伺服器端來管理 session，這種作法的問題在於，今天假如網站流量變大，想要多加幾台伺服器做水平擴展，就會有 session 要如何處理的難題。

其中一種解法，是確保同一個使用者的請求都進到同個伺服器 (俗稱 sticky session 的作法)；但是這種作法會讓特定使用者的狀態依賴特定伺服器。如果該伺服器掛掉，而 session 又沒有同步到共享儲存，使用者的請求雖然可以被導到別台伺服器，卻可能因為缺少原本的 session 狀態而失敗。這是一種潛在的單點故障問題 (single point of failure)。

舉例來說，在電商結帳流程，如果把商品加入購物車時，session 狀態保存在 A 伺服器，但結帳時 A 伺服器掛掉，所以請求被負載均衡器導向備援用的 B 伺服器，這時因為 B 伺服器沒有相關 session，可能導致購物車清空或直接報錯 (備註：這裡是以簡化版的購物車暫存來說明狀態綁在單台機器上的風險；實務上的電商系統通常會再把購物車狀態放到共享儲存、資料庫或快取中，避免只依賴單台伺服器記憶體)。

又或者在線上表單的填寫過程，如果要維持填寫紀錄。在填完部分資料後，狀態暫存在 A 伺服器的 Session 裡。但這時如果 A 伺服器掛掉，使用者回來繼續填寫後續步驟，送出時請求進到別台伺服器，前面填寫的資料會就此消失，讓整個流程必須從頭來過，使用體驗會很不理想。

假如我們從狀態的角度來看，上面這種 session-based 的設計，會被稱為有狀態 (stateful) 的設計。但為什麼這會被稱為有狀態？讓我們進一步來談相關的定義。

有狀態與無狀態的差別是什麼?

在軟體設計中，所謂的有狀態，是指某一個元件 (例如上述例子中的伺服器) 保有了與之互動所需的資訊 (例如上述提到的購物車中的資訊、填表暫存的資訊)。而無狀態則意味著，該元件本身不帶任何資訊，當需要用該元件時，就要帶上完整的資訊來跟該元件互動。

在日常生活中，也有類似的比喻。在早年醫療資訊還不發達時，去診所看醫生會類似於有狀態，多數人會去家裡附近的診所，而診所醫生的紙本病歷有過去所有的紀錄，甚至有些人如果比較頻繁看病，醫生會特別熟悉，下次去看病時甚至不用拿出病歷也能問診。這種狀況下，醫生的看診速度會很快；但如果今天換一家診所，新診所的醫生沒有過去的病歷，問診上可能會比較困難。

到了近代，許多醫療系統開始往電子病歷與跨院所資料交換的方向發展，這在概念上更接近把狀態從單一診所的紙本病歷，移到某種可被其他醫療單位查詢的共享系統。因此，這種做法也更像是無狀態的設計，不管在哪看診，病歷都是上傳到雲端，而不是放在診所的紙本病歷。醫生都能馬上調出過去的病歷紀錄。這樣一來，即使換診所、換醫生，新的醫生還是能根據過去的病歷來快速了解病人。

回到驗證的案例中，另一種 token-based 的驗證方式，是使用自包含的 token (例如 JWT)。這種設計可以讓驗證流程更接近無狀態，因為伺服器不一定要保存每個使用者的 session，只要驗證 token 的簽章與內容即可。換句話說每一個請求都要自帶足夠的資訊，讓任何一台伺服器都能獨立處理。

具體的作法來說，伺服器產生一個編碼後的 token 給客戶端，裡面已經包含驗證所需的資訊。之後每次請求都把 token 帶上，伺服器不需要保存狀態，只要驗證 token 就夠了。當狀態不是綁定在某台伺服器上，這樣即使 A 伺服器掛掉也不擔心，換成 B 伺服器一樣可行。

MCP 該是有狀態還是無狀態?

在有了上述的理解後，接著讓我們來討論一個新一點的問題「MCP 的設計應該是有狀態，還是無狀態?」。MCP 是個相對新的協定，在最開始提出時是預設有狀態的，但是提出後技術社群一直有不同的聲音；透過思考這個仍在演化中的問題，對於磨練技術設計來說會更有臨場感。

在 MCP 剛被推出的時候，是選擇有狀態的設計。這個設計很大一部分是基於當時 MCP 的使用情境，由於最開始 MCP 主要是透過 stdio 讓客戶端跟在本地運行的伺服器溝通。在這個脈絡下，選擇有狀態的設計能夠有效減少不必要的溝通成本，每次客戶端與伺服器端握完手後，之後客戶端來的請求都可以不再需要這個流程。

但隨著業界對 MCP 的採用越來越高，開始有聲音提出要預設無狀態的 MCP。其中 SEP-1442 (連結) 是由包含 Google Cloud 等多家公司的代表共同提出的議題。在 SEP-1442 中，他們提到有狀態的 MCP 讓遠端多機台的部署難度變高，這點原因跟最開頭提到的驗證問題類似；現行有狀態的設計，讓遠端多機台 MCP 的部署變得困難，例如沒辦法用簡單的負載均衡方式來處理請求。除此之外，從遠端部署的角度來看，如果今天某台部署 MCP 的伺服器掛掉，狀態就會有丟失的風險。

上述的兩種設計，是基於不同的出發點。最初 MCP 之所以選有狀態的設計，出發的角度是從 AI 代理本身的角度出發。假如今天 AI 代理在本地運行、呼叫來自本地運行的不同工具，這時用有狀態的設計非常合理。進一步說，MCP 當時在設計上借鏡 LSP 這種有狀態的協定，某種程度上預設了 AI 代理需要長連線的狀態 (例如持續運行數分鐘、瀏覽多個檔案、呼叫多個工具)，這時透過維持狀態減少重新連線，成本會更低一點。

然而，在 MCP 爆紅後，隨著 MCP 被用於遠端部署與第三方工具整合，藉此來對接到更廣泛的不同工具。對於遠端部署來說，無法擴展的問題是更大的痛點，但這個問題不在原先 MCP 設計的預想中 (本來的設計沒有考量要讓 MCP 伺服器部署在數十個不同的 pods)。

社群希望 MCP 改成預設無狀態設計，並不能說最開始的有狀態設計不好，而是實際的使用場景超乎了原本的預料，本地工具協定走向遠端平台化後，原本的最佳解開始承受新的部署壓力。設計沒有永遠的絕對正確，只是在某個場景下更合適，從這個例子來看，根據真實需求持續演化設計，會是在軟體設計中非常重要的。

而到了這週，在 2026-07-28 的最新版 MCP，已經正式把核心協定改為無狀態的，在官方的公告中有以下的影片，說明了關鍵的區別。在修改後的版本，可以透過負載平衡器，讓客戶端的請求，被導去任何的實例當中，對於可擴展性的幫助很大。

閱讀更多

如果你覺得 ExplainThis 的分享有幫助，想閱讀更深入的內容，歡迎加入 E+ 會員 (連結)。除了有會員專屬的深度文與影片，探討前後端開發、AI 工程、職涯發展，同時有 Discord 社群一同交流與成長。

本期推薦

• 近期社群討論度高的 Octane 開源專案保留 React 的 Hooks、Suspense 與元件等寫法，再透過編譯器直接更新 DOM (連結)，如果想用 React 的模式寫，但又不想被 React 的部分規則限制，推薦可以一試
• 《The startup’s Postgres survival guide》一文中，把團隊兩年來維運 PostgreSQL 遇過的問題，整理成一份面向新創工程師的實戰指南 (連結) 從資料表設計、索引、交易與連線管理，一路談到查詢計畫、批次寫入、自動清理和大型資料遷移
• Beyond Coding 訪問前 Google、AWS 軟體架構師 Gregor Hohpe，討論真正優秀的軟體架構師，和只會提供答案或堆疊術語的人有什麼不同 (連結) ，正在往資深工程師或架構師發展的人可以從中找到不少具體建議
• 最近重讀 Jeff Atwood 的經典文章《The Best Code is No Code At All》中，提醒工程師每增加一行程式碼，也同時增加除錯、閱讀、維護與支援成本 (連結) ；雖然寫於 2007 年，放到今天的軟體開發仍然很有參考價值。
• 這兩天社群中有個令人感到意外，同時也值得深思的事。前 OpenAI 安全系統的副總，同時也是 Thinking Machines Lab 的共同創辦人 Lilian Weng，在公司剛發布第一個開放權重模型 Inkling 後沒多久，宣布因為身體健康因素，離開自己共同創辦的公司。我們讀了特別有感，寫了一篇貼文談值得打造的未來，不該先耗盡打造的人 (連結)
• 今年數學界最高榮譽之一的菲爾茲獎得主公佈後，社群有極大的討論。其中王虹是史上第三位，也是首位華人女性得主。有一些報導用連跳兩級 16 歲進入北大、麻省理工 (MIT) 博士等標籤來描述王虹，彷彿這種天才般的經歷下，拿獎是再自然不過的事。但讀了比較深度的專訪後，才知道原來王虹的經歷不是如此線性、順遂，當中也有許多值得我們反思的點 (連結)。
• 最近 Kimi 推出 K3 模型後，由於在部分評測中表現超越 Claude Fable，在社群引起廣大的討論。Kimi 的創辦人兼執行長 Zhilin Yang，是在美國的卡內基美隆大學 (CMU) 拿到博士學位，他當年的導師 Russ Salakhutdinov 在社群發文，引起對於獨立學習的討論 (連結)