Cập nhật kiến trúc không trạng thái cho MCP: Giải pháp mở rộng hạ tầng AI Agent

05/08/2026

Kurtis Van Gent, Kỹ sư phần mềm cấp cao, Google Cloud Data

Khi bạn triển khai các quy trình làm việc đại lý (agentic workflows) và mở rộng quy mô người dùng, các điểm nghẽn của bạn cũng thay đổi theo. Khi Model Context Protocol (MCP) lần đầu được giới thiệu vào cuối năm 2024, nó đã cung cấp một khung làm việc tinh gọn, hướng phiên (session-oriented), cho phép các LLM đàm phán khả năng, gọi các công cụ bên ngoài và truy xuất các tài nguyên theo ngữ cảnh. Nó hoàn hảo cho một client kết nối với một server trên máy cục bộ và được tối ưu hóa cho stdio.

Tuy nhiên, khi chúng tôi tại Google bắt đầu triển khai các MCP server trên cơ sở hạ tầng cloud-native, chúng tôi đã gặp phải một rào cản lớn. Mô hình phiên ở cấp độ giao thức ban đầu yêu cầu trạng thái bền vững (persistent state), bắt tay (handshake) và ghim phiên (session pinning). Tóm lại, nó được xây dựng dựa trên các phương thức truyền tải có trạng thái (stateful transports), vốn phá vỡ các nguyên tắc cốt lõi của khả năng mở rộng cloud-native hiện đại.

Để giải quyết vấn đề này, Google đã tiên phong trong việc tách biệt giao thức khỏi các ràng buộc truyền tải có trạng thái. Các đội ngũ của chúng tôi cần MCP để mở rộng quy mô trên hàng triệu truy vấn đồng thời trên Google Cloud, và chúng tôi biết rằng các bạn cũng cần MCP sẵn sàng cho quy mô doanh nghiệp thực tế. Hợp tác chặt chẽ với Hugging Face và các đối tác trong ngành, chúng tôi đã đồng sáng lập Nhóm công tác MCP Transports (MCP Transports Working Group).

Hôm nay, chúng tôi rất vui mừng được công bố thành quả của công việc đó: bản phát hành ứng viên (release candidate) của đặc tả Model Context Protocol ngày 28/07/2026, vốn đã được áp dụng rộng rãi. Bản phát hành mang tính bước ngoặt này loại bỏ hoàn toàn việc quản lý phiên ở cấp độ truyền tải, mang đến cho bạn một giao thức cốt lõi không trạng thái (stateless) có thể mở rộng trên cơ sở hạ tầng cân bằng tải HTTP thông thường.

Đây là thay đổi lớn nhất đối với đặc tả MCP kể từ khi ra mắt, và nếu bạn không đọc phần còn lại của bài viết này, hãy yên tâm rằng đây là một thay đổi tích cực - mở rộng quy mô tốt hơn, bảo mật hơn và dễ dàng hơn.

Tại sao các phiên (sessions) lại là điểm nghẽn trong sản xuất?

Trong mô hình giao thức ban đầu (phiên bản đặc tả 25/11/2025) [392], việc kết nối với một MCP server qua HTTP yêu cầu một quy trình khởi tạo có trạng thái:

JSON

Đã sao chép

Server phản hồi bằng tiêu đề Mcp-Session-Id. Để thực hiện bất kỳ lệnh gọi công cụ hoặc truy vấn tài nguyên nào sau đó, client phải bao gồm ID phiên duy nhất đó trong mọi yêu cầu, ghim client vào container hoặc pod cụ thể đang lưu giữ trạng thái phiên trong bộ nhớ của nó.

Ràng buộc có trạng thái này phá vỡ các mô hình mở rộng theo chiều ngang (horizontal scaling) mà các kỹ sư cloud-native dựa vào:

Mô hình yêu cầu mới: Chuyển sang hoàn toàn không trạng thái (stateless)

Đặc tả mới ngày 28/07/2026 giải quyết vấn đề này bằng cách làm cho giao thức cốt lõi hoàn toàn không trạng thái. Việc bắt tay đã không còn nữa. Quy trình bắt tay initialize / initialized (SEP-2575) và tiêu đề logic Mcp-Session-Id (SEP-2567) đã bị loại bỏ hoàn toàn.

Thay vào đó, mọi yêu cầu hiện nay đều tự mô tả và độc lập. Phiên bản giao thức, thông tin client và khả năng của client vốn từng được trao đổi một lần khi thiết lập kết nối, giờ đây được truyền trong trường _meta nội dòng (inline) trên mỗi yêu cầu.

Dưới đây là cách một lệnh gọi công cụ không trạng thái trông như thế nào theo đặc tả mới ngày 28/07/2026:

Văn bản thuần (Plain text)

Đã sao chép

Ưu điểm kiến trúc của cốt lõi không trạng thái

Chuẩn hóa HTTP: Có thể định tuyến, lưu vào bộ nhớ đệm và truy vết

Nếu không có các phiên giao thức, chúng tôi cần các cơ chế tiêu chuẩn để định tuyến và quản lý lưu lượng truy cập một cách hiệu quả. Làm việc trong Nhóm công tác Transports, chúng tôi đã giúp thiết kế SEP-2243 (Chuẩn hóa HTTP) [302, 542].

Các yêu cầu HTTP POST có thể truyền phát (streamable) hiện mang các tiêu đề HTTP cụ thể:

Các tiêu đề này được phản chiếu để khớp với phần thân JSON-RPC. Nếu chúng không khớp, server sẽ từ chối yêu cầu với mã lỗi không khớp tiêu đề -32020.

Không còn kiểm tra gói tin sâu (Deep Packet Inspection)

Bằng cách nâng các giá trị này lên thành tiêu đề HTTP tiêu chuẩn, các proxy, gateway và bộ cân bằng tải có thể định tuyến, giới hạn tốc độ và kiểm tra lưu lượng truy cập mà không cần kiểm tra phần thân yêu cầu. Đối với các nhóm bảo mật và ghi nhật ký, đây là một thắng lợi lớn giúp giảm đáng kể độ trễ và chi phí xử lý tại lớp gateway.

Lưu vào bộ nhớ đệm thông minh với ttlMs (SEP-2549)

Để loại bỏ nhu cầu về các kết nối Server-Sent Events (SSE) tồn tại lâu dài chỉ để theo dõi xem danh sách công cụ hoặc lời nhắc (prompt) có thay đổi hay không, đặc tả giới thiệu các trường lưu vào bộ nhớ đệm được mô phỏng theo Cache-Control của HTTP. Kết quả của công cụ và tài nguyên hiện có thể trả về một ttlMs (Thời gian tồn tại tính bằng mili giây) và một cacheScope. Client biết chính xác thời gian phản hồi tools/list còn mới và liệu có an toàn để lưu vào bộ nhớ đệm cho nhiều người dùng hay không.

Yêu cầu đa vòng lặp (MRTR): Xử lý các yêu cầu làm rõ (Elicitations) một cách không trạng thái

Một trong những thách thức phức tạp nhất mà chúng tôi phải đối mặt trong thế giới không trạng thái là cách xử lý các yêu cầu từ server đến client. Theo các phiên bản trước, nếu một MCP server cần sự làm rõ từ người dùng ("lời nhắc làm rõ" - elicitation prompt) hoặc xác nhận trong khi gọi công cụ, nó phải giữ kết nối SSE mở để đẩy yêu cầu đó đến client.

Yêu cầu đa vòng lặp (SEP-2322) giải quyết vấn đề này một cách tuyệt vời bằng cách tái cấu trúc vòng đời tương tác thành các bước khép kín:

Thay vì chặn luồng hoặc giữ kết nối mở, server ngay lập tức trả về một InputRequiredResult với payload requestState chứa ngữ cảnh đã được tuần tự hóa [398]:

JSON

Đã sao chép

Client nhắc người dùng, thu thập câu trả lời boolean và thực hiện lại lệnh gọi với inputResponses cùng với requestState được phản hồi lại. Vì requestState chứa mọi thứ cần thiết để tiếp tục tác vụ, bất kỳ instance server nào phía sau bộ cân bằng tải của bạn đều có thể tiếp nhận yêu cầu thử lại này!