MCP chuyển sang trạng thái phi trạng thái (stateless), và các nhà phát triển đặt câu hỏi liệu điều này có biến nó trở lại thành một API hay không.

Trang chủ InfoQ Tin tức MCP chuyển sang trạng thái phi trạng thái, các nhà phát triển đặt câu hỏi liệu điều này có biến nó thành một API nữa không Điện toán đám mây MCP chuyển sang trạng thái phi trạng thái, các nhà phát triển đặt câu hỏi liệu điều này có biến nó thành một API nữa không Ngày 12/8/2026 4 phút đọc Bởi Steef-Jan Wiggers Theo dõi chúng tôi trên Youtube 232N người theo dõi Linkedin 26N người theo dõi Instagram Mới RSS 19N độc giả X 57,1N người theo dõi Facebook 21N lượt thích Bluesky Mới Nghe bài viết này - 0:00 Âm thanh sẵn sàng phát Trình duyệt của bạn không hỗ trợ phần tử âm thanh. 0:00 0:00 Bình thường 1,25x 1,5x Thích Danh sách đọc Thông số kỹ thuật MCP 2026-07-28 đã loại bỏ các phiên giao thức. Thông tin đưa tin cho đến nay đã coi đây là một thành công về khả năng mở rộng, và đúng là như vậy. Tuy nhiên, cùng một bản phát hành đã thêm hai tiêu đề HTTP bắt buộc, và các tiêu đề này cho phép một cổng (gateway) định tuyến, điều tiết và đo lường lưu lượng tác nhân mà không cần mở phần thân yêu cầu. Các giao thức truyền tải trước đây bắt đầu bằng một trao đổi khởi tạo và đã khởi tạo để thiết lập một phiên, được theo dõi thông qua tiêu đề Mcp-Session-Id. Mọi yêu cầu tiếp theo đều phải định vị trạng thái gắn với phiên đó. Cơ sở hạ tầng tự động mở rộng phải duy trì các phiên, các triển khai phải loại bỏ hoặc di chuyển chúng, và việc cân bằng tải là không thực tế, vì một máy khách bị gắn chặt vào bất kỳ phiên bản nào đang giữ phiên của nó. Giao thức mới loại bỏ quá trình bắt tay, tiêu đề phiên và các phiên giao thức khỏi đường dẫn yêu cầu cốt lõi. Mỗi yêu cầu mang theo phiên bản giao thức, danh tính máy khách và các khả năng cần thiết. Bất kỳ yêu cầu nào cũng có thể đến bất kỳ phiên bản nào. Phần ít được chú ý hơn là điều gì xảy ra với chính yêu cầu đó. Các thông điệp MCP là JSON-RPC qua HTTP, và thông tin về một yêu cầu trước đây chỉ nằm bên trong phần thân JSON. Một cổng phải phân tích cú pháp phần thân đó để biết liệu một yêu cầu có liệt kê các công cụ, gọi một công cụ hay đọc một tài nguyên hay không. Hai tiêu đề hiện là bắt buộc đối với các yêu cầu HTTP có thể truyền tải (Streamable HTTP): Mcp-Method và Mcp-Name. Một lệnh gọi công cụ đến dưới dạng Mcp-Method: tools/call và Mcp-Name: search, với tải trọng JSON-RPC phía sau nó. Matt Carey của Cloudflare đã giải thích rõ lợi ích của điều này. Một cổng, bộ giới hạn tốc độ hoặc WAF có thể đọc các tiêu đề này và hành động dựa trên chúng, theo từng phương thức hoặc từng công cụ, sử dụng các nguyên tắc cơ bản mà nó đã áp dụng cho mọi API khác. Người bình luận evalstate lưu ý rằng thông số kỹ thuật còn đi xa hơn: các đối số của công cụ có thể được sao chép vào các tiêu đề để định tuyến tùy chỉnh. Yêu cầu định tuyến MCP thông qua các điều khiển cổng sử dụng các tiêu đề mới (Nguồn: Cloudflare) Việc quản trị tác nhân (agent governance) từ trước đến nay đã được triển khai theo hướng khác. Tính năng theo dõi tác nhân của Cloudflare và tầng AI Gateway của Azure API Management đều nằm trên giao thức như một lớp kiểm soát riêng biệt. Bản phát hành này đặt siêu dữ liệu vào lớp vận chuyển, nơi các nhóm hạ tầng đã có thể đọc được. Các gián đoạn trong quá trình thu thập thông tin (elicitation breaks). Các yêu cầu do máy chủ khởi tạo trước đây cần một luồng mở. Giờ đây, chúng sử dụng Yêu cầu Đa Chuyến (Multi Round-Trip Requests): máy chủ trả về `input_required`, máy khách thu thập câu trả lời và cuộc gọi được thử lại. Việc phê duyệt trở thành hai yêu cầu thay vì một kết nối được giữ, điều này đơn giản hơn để triển khai nhưng có nghĩa là việc chờ đợi sự can thiệp của con người không còn nằm trong một lần gọi duy nhất. Quyền ủy quyền cũng được thắt chặt, với việc Dynamic Client Registration bị loại bỏ và dự kiến sẽ bị gỡ bỏ sau mùa hè năm 2027, việc nhận dạng nhà phát hành RFC 9207 được áp dụng, và các máy khách gửi URI máy chủ chính tắc làm tài nguyên RFC 8707 để các token chỉ được chấp nhận bởi đối tượng đó. Phản ứng của cộng đồng trên Hacker News đã chia rẽ rõ rệt, và sự chia rẽ không phải về việc liệu trạng thái phi trạng thái (statelessness) có phải là một cải tiến hay không. Mà là về những gì cải tiến đó tiết lộ. Đối với một nhóm, bản phát hành này xác nhận rằng giao thức lẽ ra không bao giờ nên có trạng thái. Như người bình luận drdexebtjl đã nói: "Nhìn lại, MCP có trạng thái rõ ràng là sai lầm. Điều này về cơ bản biến MCP thành một điểm cuối API REST khác, và cho phép bạn sử dụng cùng một hạ tầng mà bạn đã thiết lập cho các API REST (như bộ cân bằng tải, cổng API, triển khai dần dần, v.v.)." Người bình luận pjmlp đã coi đây là một bài học mà ngành công nghiệp liên tục học lại, gợi nhớ đến cùng một kết luận từ Sun RPC: máy chủ phi trạng thái luôn tốt hơn, máy chủ có trạng thái chỉ khi không thể tránh khỏi. Người bình luận luciana1u thẳng thắn hơn: "Chúng ta đã phát minh ra một giao thức có trạng thái, phát hiện ra trạng thái khó mở rộng, loại bỏ nó, và đi đến kết luận 'chỉ cần gửi một yêu cầu POST.' Cộng đồng REST đã tự mãn chờ đợi khoảnh khắc này trong 20 năm." Người bình luận bloppe đã đưa ra phiên bản cấu trúc, mô tả MCP như một API giống REST, cộng với một đặc tả mà OpenAPI đã cung cấp, cộng với ủy quyền cấp độ harness, và lập luận rằng chỉ có phần thứ ba là thực sự mới. Phía bảo vệ không tranh cãi về sự tương đồng mà là về kết luận. Người bình luận lexicality lưu ý rằng MCP thực chất là JSON-RPC, và những gì được phát minh là một quy ước mà các mô hình đã được huấn luyện để sử dụng. Người bình luận vidarh đã trình bày trường hợp một cách kinh tế nhất: "Lợi thế cốt lõi mà MCP mang lại cho bạn là một tiêu chuẩn mà nhờ được các nhà cung cấp AI chấp thuận, mọi người có động lực mạnh mẽ để thực sự triển khai." Các nhà triển khai đã đạt được một phán quyết tương tự từ hướng khác. David Cramer, đồng sáng lập và giám đốc sản phẩm tại Sentry, người trước đây đã công khai viết rằng MCP chưa tốt, đã nói với Cloudflare rằng bản phát hành này đã cải thiện việc xử lý xác thực và công cụ: "Các tác nhân chỉ trở nên hữu ích khi các vấn đề cơ bản không còn là toàn bộ câu chuyện." Một luồng thảo luận song song đặt câu hỏi liệu các tác nhân có cần một giao thức nào cả hay không, thay vì chỉ cần quyền truy cập shell vào các công cụ CLI thông thường. Người bình luận firasd phản bác rằng quan điểm về CLI giả định một nhà phát triển, trên máy tính xách tay, với một shell.