← 回到 Reading
ExplainThis 2026-08-02

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

ExplainThis announced the release of a new course titled 'Writing Maintainable Code (Part 2) — Practical Methods in Daily Development' on its E+ membership platform. While the first part focused on classical software design theory, this continuation targets actionable techniques for daily engineering tasks to improve code quality. The newsletter also highlights that readers can purchase E+ memberships using corporate education training subsidies, noting that over half of recent new members enrolled via this approach. In software architecture across both frontend and backend development, engineers frequently face the choice between stateful and stateless design patterns. Common examples include choosing between session-based versus token-based authentication, as well as WebSockets versus HTTP for communication. The Model Context Protocol (MCP) recently transitioned its core protocol from stateful to stateless. Mastering the trade-offs between these two paradigms is critical for making sound architectural decisions and answering technical interview questions. 在 1990 年代的網頁開發中,基於 Session 的驗證方式是主流,但其依賴伺服器端管理狀態,在系統進行水平擴展時會面臨 Session 處理的挑戰。常見的解決方案之一是使用黏性 Session(sticky session),將特定使用者的請求綁定至單一伺服器。然而,這種作法會造成特定使用者狀態對特定機器的依賴,一旦伺服器故障且狀態未同步至共享儲存,便會引發單點故障(SPOF),導致購物車或表單資料遺失。這種架構在概念上屬於典型的高風險「有狀態」(stateful)設計。

閱讀原文 ↗
目錄 7 段
  1. 01ExplainThis 全端開發雙週報 #85 從 MCP 核心協定轉為無狀態,談有狀態與無狀態的設計如何取捨
  2. 02從 MCP 核心協定轉為無狀態,談有狀態與無狀態的設計如何取捨
  3. 03從驗證的角度看有狀態與無狀態
  4. 04有狀態與無狀態的差別是什麼?
  5. 05MCP 該是有狀態還是無狀態?
  6. 06閱讀更多
  7. 07本期推薦

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

ExplainThis announced the release of a new course titled 'Writing Maintainable Code (Part 2) — Practical Methods in Daily Development' on its E+ membership platform. While the first part focused on classical software design theory, this continuation targets actionable techniques for daily engineering tasks to improve code quality. The newsletter also highlights that readers can purchase E+ memberships using corporate education training subsidies, noting that over half of recent new members enrolled via this approach.

  • ExplainThis launched 'Writing Maintainable Code (Part 2) — Practical Methods in Daily Development' on its E+ platform.
  • Part 2 focuses on actionable daily development practices, contrasting with the theoretical emphasis of Part 1.
  • E+ memberships can be invoiced with unified business numbers (統編) for corporate education subsidy reimbursement.
  • More than half of new E+ subscribers in the preceding month used company training subsidies to join.

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

In software architecture across both frontend and backend development, engineers frequently face the choice between stateful and stateless design patterns. Common examples include choosing between session-based versus token-based authentication, as well as WebSockets versus HTTP for communication. The Model Context Protocol (MCP) recently transitioned its core protocol from stateful to stateless. Mastering the trade-offs between these two paradigms is critical for making sound architectural decisions and answering technical interview questions.

  • Software architecture in frontend and backend systems regularly requires choosing between stateful and stateless designs.
  • Authentication can be implemented as stateful (session-based) or stateless (token-based).
  • Communication protocols illustrate statefulness trade-offs, such as stateful WebSockets versus stateless HTTP.
  • The Model Context Protocol (MCP) officially transitioned its core protocol from stateful to stateless.
  • Evaluating stateful versus stateless trade-offs is a standard topic in technical interviews and system design.

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

在 1990 年代的網頁開發中,基於 Session 的驗證方式是主流,但其依賴伺服器端管理狀態,在系統進行水平擴展時會面臨 Session 處理的挑戰。常見的解決方案之一是使用黏性 Session(sticky session),將特定使用者的請求綁定至單一伺服器。然而,這種作法會造成特定使用者狀態對特定機器的依賴,一旦伺服器故障且狀態未同步至共享儲存,便會引發單點故障(SPOF),導致購物車或表單資料遺失。這種架構在概念上屬於典型的高風險「有狀態」(stateful)設計。

  • 90 年代的網頁開發以 session-based 作為主流驗證方式,需要伺服器端負責管理 session。
  • 當網站流量增加需要水平擴展時,session-based 驗證會面臨跨伺服器狀態共享的挑戰。
  • Sticky session 確保同一使用者的請求都發往同一台伺服器,但容易引發單點故障問題 (SPOF)。
  • 若單台伺服器掛掉且 session 未同步到共享儲存,使用者請求被導到其他機器時會因缺少狀態而中斷操作(如購物車清空或表單遺失)。
  • 依賴伺服器端保存並管理狀態的架構設計被定義為有狀態(stateful)架構。

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

在軟體架構中,有狀態架構表示元件保留互動所需的上下文資訊,而無狀態架構則要求客戶端在每次請求中提供完整資訊。生活中早期紙本病歷依賴單一診所屬於有狀態設計,現代跨院所雲端病歷系統則接近無狀態概念。在身份驗證技術上,使用自包含的 JWT 等 token-based 機制能達成無狀態驗證,伺服器僅需驗證 token 簽章而不必保留使用者 session,進而提升系統容錯與橫向擴展能力。

  • 有狀態(Stateful)代表元件本身保存了與客戶端互動所需的上下文與狀態資料。
  • 無狀態(Stateless)代表元件不留存狀態,每次請求皆需攜帶完整資訊供元件處理。
  • 電子病歷與雲端共享系統將狀態從單一節點抽出,概念上類似於無狀態設計。
  • Token-based 驗證(如 JWT)自帶驗證資訊與簽章,使伺服器無需在本地保存 session。
  • 無狀態設計使得單一伺服器故障時,其他伺服器仍能獨立接手處理請求。

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

This section examines the architectural evolution of the Model Context Protocol (MCP) regarding stateful versus stateless designs. Originally designed to be stateful for local execution over stdio and inspired by LSP, MCP minimized handshake and reconnection overhead for local AI agents. However, as MCP expanded to remote multi-node environments and cloud deployments, statefulness introduced load balancing and scalability bottlenecks, prompting proposals like SEP-1442. Consequently, MCP officially shifted its core protocol to a default stateless model to support better remote scalability and load balancing.

  • MCP was originally designed as a stateful protocol primarily for local stdio communication between clients and local servers.
  • The original stateful design drew inspiration from the Language Server Protocol (LSP), targeting long-running connections for local AI agents.
  • Stateful architecture made multi-machine remote deployment and load balancing difficult, creating single points of failure if a server crashed.
  • SEP-1442, backed by companies including Google Cloud, proposed shifting MCP toward a stateless architecture.
  • On 2026-07-28, MCP officially changed its core protocol to stateless, allowing load balancers to route requests to arbitrary instances for enhanced scalability.

閱讀更多

ExplainThis offers a premium membership program called E+ for readers seeking deeper technical content. The subscription provides exclusive in-depth articles and videos focused on frontend and backend development, AI engineering, and career advancement. Additionally, subscribers gain access to a private Discord community for peer networking and professional growth.

  • ExplainThis provides a paid membership program known as E+.
  • E+ members gain access to exclusive articles and videos covering frontend/backend development, AI engineering, and career growth.
  • The E+ program includes access to a dedicated Discord community for collaborative discussion and networking.

本期推薦

This newsletter section highlights notable technical resources, industry updates, and noteworthy community news across software engineering, AI, and mathematics. In open-source software, the new project Octane adapts React paradigms with direct DOM compilation, and practical guides for PostgreSQL maintenance and architectural thinking are recommended. In AI, former OpenAI executive Lilian Weng stepped down from Thinking Machines Lab following the release of the Inkling model, while Kimi's new K3 model sparked discussions on graduate mentoring after outperforming Claude Fable in benchmark tests. Additionally, the section highlights mathematician Hong Wang's historic Fields Medal win and reflections on software minimalism inspired by Jeff Atwood.

  • Octane is an open-source project that retains React concepts like Hooks and Suspense while updating the DOM directly via a compiler.
  • Lilian Weng, former VP of Safety Systems at OpenAI and co-founder of Thinking Machines Lab, stepped down due to health reasons shortly after the release of the open-weight model Inkling.
  • Hong Wang became the third woman and the first Chinese woman to be awarded the Fields Medal.
  • Kimi released the K3 model, which outperformed Claude Fable in several evaluations, sparking community discussions led by founder Zhilin Yang's CMU PhD advisor Russ Salakhutdinov.
  • The article 'The startup’s Postgres survival guide' outlines two years of production lessons covering schema design, indexing, connection pooling, and migrations.