Xây dựng với CometAPICần một API cho nhiều mô hình?Kiểm thử quy trình trong Playground, sau đó tạo API key khi mô hình và chi phí phù hợp với trường hợp sử dụng của bạn.
MCP 2026-07-28 Hướng dẫn chuyển đổi: Máy chủ không trạng thái
Tìm hiểu cách chuyển sang MCP 2026-07-28, bao gồm truyền tải không trạng thái, MRTR, các header định tuyến, bộ nhớ đệm, các thay đổi về OAuth, nâng cấp SDK.
TL;DR: MCP 2026-07-28 loại bỏ phiên ở cấp giao thức và thủ tục bắt tay khởi tạo bắt buộc. Nhóm vận hành sản xuất nên tìm các phụ thuộc phiên ẩn, áp dụng siêu dữ liệu giao thức theo từng yêu cầu, triển khai Yêu cầu Nhiều vòng khứ hồi (MRTR), cập nhật chính sách gateway, và triển khai canary giao thức mới trước khi ngừng hành vi cũ.
Bản đặc tả Model Context Protocol phát hành ngày 28 tháng 7, 2026 giới thiệu thay đổi kiến trúc lớn nhất cho MCP kể từ khi hỗ trợ transport từ xa được bổ sung.
Giao thức giờ đây sử dụng lõi yêu cầu–phản hồi không trạng thái. Trao đổi bắt buộc initialize và notifications/initialized đã bị loại bỏ, Mcp-Session-Id đã bị gỡ, và mỗi yêu cầu mang theo thông tin giao thức cần thiết để xử lý.
Đã được xem xét về độ rõ ràng, ghi nguồn và thuật ngữ API hiện tại.
Bản phát hành cũng giới thiệu Yêu cầu Nhiều vòng khứ hồi (MRTR), header định tuyến HTTP, phản hồi danh sách có thể cache, hành vi uỷ quyền nghiêm ngặt hơn, framework tiện ích mở rộng, và vòng đời ngừng hỗ trợ chính thức. Xem thông báo phát hành MCP 2026-07-28 chính thức và nhật ký thay đổi đặc tả đầy đủ để biết chi tiết cấp giao thức.
Những thay đổi này giúp máy chủ MCP từ xa dễ dàng mở rộng sau hạ tầng HTTP tiêu chuẩn. Chúng không tự động khiến ứng dụng hiện có trở nên không trạng thái.
Một máy chủ sản xuất vẫn có thể dựa vào workspace trong bộ nhớ, định tuyến dính, thông tin xác thực gắn với phiên, luồng sống lâu, hoặc tương tác do máy chủ khởi tạo. Hướng dẫn này tập trung vào việc tìm và thay thế các phụ thuộc đó.
Máy chủ có từ chối cuộc gọi cho đến khi hoàn tất khởi tạo không?
Một session ID có chọn người dùng, thông tin xác thực, workspace, hay cuộc hội thoại không?
Một instance máy chủ khác có thể tiếp tục quy trình công việc bắt đầu bởi instance đầu tiên không?
Load balancer có yêu cầu dính phiên không?
Một công cụ có thực hiện tác dụng phụ trước khi yêu cầu xác nhận không?
Gateway có phân tích body để xác định method hay tool không?
Thông tin xác thực OAuth có được lưu mà không kèm máy chủ uỷ quyền phát hành (issuer) của chúng không?
Client có phụ thuộc vào kết nối lại SSE hoặc phát lại thông điệp không?
Danh sách công cụ hay resource có thay đổi theo kết nối không?
Những tính năng bị ngừng hỗ trợ nào vẫn nhận traffic sản xuất?
Không gỡ Mcp-Session-Id cho đến khi bạn hiểu ứng dụng đang lưu gì phía sau nó.
Một máy chủ gỡ header này nhưng vẫn giữ trạng thái trong bộ nhớ cục bộ có thể hoạt động trong phát triển và lỗi ngắt quãng khi yêu cầu được phân phối qua nhiều instance.
2. Thay thế trạng thái phiên ẩn
MCP 2026-07-28 gỡ các phiên ở cấp giao thức, không phải trạng thái ứng dụng.
Trạng thái cần qua nhiều cuộc gọi nên dùng một trong ba mẫu.
Handle tường minh
Trả về handle do máy chủ cấp từ một công cụ và yêu cầu nó trong các cuộc gọi sau.
Điều này làm cho phụ thuộc trở nên hiển thị trong hợp đồng công cụ và cho phép bất kỳ instance máy chủ tương thích nào xử lý yêu cầu.
Lưu trữ chia sẻ
Dùng cơ sở dữ liệu, cache phân tán, object store, hoặc hệ thống tác vụ bền bỉ khi:
nhiều worker cần cùng trạng thái;
quy trình phải sống sót qua khởi động lại;
trạng thái quá lớn cho một handle;
quy trình kéo dài hơn một yêu cầu;
yêu cầu hành vi giao dịch hoặc sử dụng một lần.
requestState được bảo vệ
MRTR có thể trả về giá trị requestState mờ đục để client phản hồi lại khi retry yêu cầu gốc.
Vì giá trị đi qua client, hãy bảo vệ nó bằng HMAC hoặc mã hoá xác thực. Ràng buộc nó với chủ thể đã xác thực, thao tác gốc, tham số quan trọng, thời hạn, và một nonce khi cần chống replay.
Không bao giờ tin giá trị requestState chưa ký chỉ vì client trả lại nguyên vẹn.
3. Áp dụng yêu cầu tự chứa và khám phá
Yêu cầu MCP hiện đại bao gồm ngữ cảnh giao thức trong _meta.
Một cuộc gọi công cụ qua Streamable HTTP có thể trông như sau:
Máy chủ nhắm tới giao thức mới phải triển khai server/discover, quảng bá phiên bản được hỗ trợ, khả năng, và định danh máy chủ. Client có thể gọi trước một thao tác khác hoặc dùng để xác định có cần fallback cũ không.
Đọc server/discover documentation chính thức để biết hợp đồng phản hồi.
Thương lượng phiên bản SDK TypeScript
Chỉ nâng cấp SDK TypeScript không tự động chuyển client sang giao thức mới.
hành vi khi client không hỗ trợ khả năng được yêu cầu.
Tránh hoàn tất mua hàng, xoá, trừ tín dụng, hoặc ghi ra ngoài trước khi trả input_required.
Dùng thao tác theo giai đoạn hoặc khoá idempotency để các lần retry không thể nhân đôi hành động. Xem đặc tả MRTR chính thức để biết mô hình tương tác đầy đủ.
5. Cập nhật gateway, cache, và uỷ quyền
Các thay đổi hạ tầng có liên quan chặt chẽ và nên được kiểm thử cùng nhau.
Xác thực header định tuyến MCP
Yêu cầu POST Streamable HTTP giờ bao gồm:
MCP-Protocol-Version
Mcp-Method
Mcp-Name
Các header này cho phép gateway định tuyến, đo đạc, uỷ quyền, và giới hạn tốc mà không cần phân tích mọi body JSON.
Chúng có thể hỗ trợ các kiểm soát như:
giới hạn tốc độ theo từng công cụ;
chính sách riêng cho phương thức liệt kê và thực thi;
pool worker chuyên biệt cho công cụ tốn kém;
truy cập hạn chế cho thao tác rủi ro cao;
số liệu độ trễ và lỗi theo công cụ;
quy trách nhiệm chi phí hạ tầng.
Giá trị vẫn do client cung cấp. So sánh chúng với body JSON-RPC trước khi áp dụng chính sách.
Một yêu cầu không được phép khai báo công cụ rủi ro thấp trong Mcp-Name trong khi gọi công cụ khác trong body. Sai lệch giữa header và body nên bị từ chối và ghi log.
Dùng khoá cache nhận thức uỷ quyền
Giao thức mới thêm ttlMs và cacheScope cho các kết quả có thể cache bao gồm:
tools/list
prompts/list
resources/list
resources/templates/list
resources/read
Khoá cache thông thường nên bao gồm:
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
Không tái sử dụng mục cache riêng tư giữa người dùng hoặc tenant chỉ vì TTL chưa hết hạn.
Sắp xếp công cụ quyết định được cũng quan trọng. Danh mục ổn định tránh miss cache không cần thiết và có thể cải thiện tái sử dụng prompt-cache của mô hình khi định nghĩa công cụ được chèn vào prompt.
Tăng cường xử lý issuer của OAuth
Trong quá trình di trú uỷ quyền:
xác thực giá trị iss trả về với issuer được ghi nhận cho luồng;
khoá thông tin xác thực client được lưu theo issuer;
không bao giờ tái sử dụng thông tin xác thực với máy chủ uỷ quyền khác;
đặt application_type phù hợp trong DCR;
chuẩn bị tích hợp mới cho Client ID Metadata Documents.
Dynamic Client Registration vẫn khả dụng cho tương thích ngược, nhưng bị ngừng ưu tiên như phương thức đăng ký ưa dùng.
6. Di trú thông báo, Tasks, và tính năng ngừng hỗ trợ
Đường thông báo HTTP GET cũ và luồng resources/subscribe hoặc resources/unsubscribe đã được thay bằng subscriptions/listen.
Client mở một luồng phản hồi POST sống lâu và chọn tham gia các nhóm thông báo cần thiết. Thông báo tiến trình và log theo yêu cầu vẫn gắn với luồng phản hồi cho yêu cầu mà chúng mô tả.
Đối với triển khai nhiều instance, dùng bus sự kiện chia sẻ khi thông báo sinh ra ở một instance phải đến một đăng ký kết nối với instance khác.
Tiện ích mở rộng Tasks
Công việc dài hạn đã được chuyển khỏi core thử nghiệm sang:
io.modelcontextprotocol/tasks
Tiện ích mở rộng dùng:
tasks/get để polling;
tasks/update cho cập nhật từ client đến server;
handle tác vụ bền bỉ;
subscriptions/listen cho cập nhật đã opt-in.
Mẫu tasks/result và tasks/list cũ không nên được mang sang triển khai mới.
Tính năng bị ngừng hỗ trợ
Các tính năng sau bị ngừng hỗ trợ:
Tính năng
Hướng khuyến nghị
MCP 2026-07-28
Hành động di trú
Roots
Truyền thư mục qua tham số công cụ, URI resource, hoặc cấu hình
Không có bắt tay bắt buộc
Gỡ các cổng khởi tạo cho yêu cầu hiện đại
Sampling
Tích hợp trực tiếp với API nhà cung cấp mô hình
Không có phiên ở cấp giao thức
Biến trạng thái bắt buộc thành tường minh
Logging
Dùng stderr cho stdio hoặc OpenTelemetry trong sản xuất
Gọi server/discover tùy chọn
Triển khai khám phá và thương lượng phiên bản
Dynamic Client Registration
Chuyển sang Client ID Metadata Documents
Bao gồm trong _meta của yêu cầu
Gửi siêu dữ liệu giao thức theo từng yêu cầu
Legacy HTTP+SSE
Di trú sang Streamable HTTP
Header Mcp-Method và Mcp-Name
Cập nhật định tuyến, chính sách, và quan sát
Giá trị includeContext lỗi thời
Bỏ trường hoặc dùng "none"
Yêu cầu Nhiều vòng khứ hồi
Xử lý input_required và retry
Cache danh sách
Danh mục bị fetch lặp lại
ttlMs, cacheScope, sắp xếp quyết định được
Thêm cache nhận thức uỷ quyền
Thông báo
GET stream và đăng ký resource
subscriptions/listen
Chuyển thông báo thay đổi sang luồng mới
Uỷ quyền
Đăng ký trung tâm DCR
Chức năng bị ngừng hỗ trợ vẫn khả dụng trong cửa sổ ngừng hỗ trợ, nhưng triển khai mới không nên áp dụng. Chính sách vòng đời MCP cung cấp tối thiểu mười hai tháng ngừng hỗ trợ; không có nghĩa mọi tính năng đều có ngày gỡ bỏ xác nhận như nhau.
Không thay đổi client, server, gateway, cache, và uỷ quyền trong một bản phát hành thiếu quan sát.
Thứ tự di trú khuyến nghị
Kiểm kê phiên bản giao thức, SDK, phiên, traffic SSE, client DCR, và phương thức lỗi thời.
Nâng cấp SDK môi trường không sản xuất.
Thêm server/discover và thương lượng phiên bản.
Thay thế phụ thuộc phiên ẩn.
Triển khai và bảo mật MRTR.
Thêm header định tuyến được xác thực và cache theo phạm vi.
Kiểm thử ranh giới issuer uỷ quyền.
Canary giao thức hiện đại song song đường cũ.
Chỉ nghỉ hưu hành vi cũ sau khi xem xét telemetry.
Khả năng tương thích trong giai đoạn canary
Modern client + modern server
→ Use MCP 2026-07-28
Modern client + legacy server
→ Probe and fall back when supported
Legacy client + dual-version server
→ Continue on the legacy path
Unsupported combination
→ Return a clear protocol-version error
Phát hành một đặc tả MCP mới không phải là công tắc cho toàn hệ sinh thái. Client, server, SDK, và nền tảng hosted sẽ di trú với tốc độ khác nhau.
Telemetry cần ghi
Tín hiệu
Điều tiết lộ
Phiên bản giao thức theo yêu cầu
Mức độ áp dụng và tổ hợp không tương thích
Tỉ lệ khám phá thành công và fallback
Hành vi thương lượng phiên bản
Header MCP thiếu hoặc không hợp lệ
Client lỗi thời hoặc lỗi gateway
Sai lệch giữa header/body
Lỗi client hoặc nỗ lực vượt chính sách
MRTR được yêu cầu và hoàn tất
Độ tin cậy của quy trình tương tác
MRTR bị từ chối hoặc hết hạn
Lộ trình lỗi của người dùng và client
Lỗi xác minh request-state
Can thiệp, replay, hoặc hết hạn
Ngăn chặn thao tác trùng lặp
Hiệu quả của kiểm soát idempotency
Tỉ lệ cache hit theo phạm vi
Giảm tải an toàn
Lỗi xác thực issuer
Vấn đề cấu hình OAuth
Traffic HTTP+SSE
Công việc di trú transport còn lại
Traffic phương thức lỗi thời
Cơ sở cho kế hoạch nghỉ hưu
Độ trễ công cụ và tỉ lệ tác vụ chấp nhận
Độ tin cậy hiển thị với người dùng
Các yêu cầu tools/call one-shot thành công là chưa đủ để đo di trú. Một quy trình lặp lại hết hạn, yêu cầu input không cần thiết, hoặc nhân đôi ghi ra ngoài vẫn là thất bại sản xuất.
CometAPI phù hợp với kiến trúc MCP như thế nào
MCP không thay thế API mô hình. Hai lớp giải quyết các vấn đề tích hợp khác nhau.
Lớp
Trách nhiệm chính
MCP
Kết nối agent với công cụ, resource, prompt, phê duyệt, và tác vụ
Unified model API
Kết nối ứng dụng với mô hình, thông tin xác thực, sử dụng, và tính phí
Điều phối ứng dụng
Quyết định khi nào và cách gọi mô hình và công cụ
Kiến trúc sản xuất điển hình trông như sau:
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP tiêu chuẩn hoá cách agent tương tác với công cụ và ngữ cảnh. MCP không tiêu chuẩn hoá giá mô hình, thông tin xác thực nhà cung cấp, endpoint suy luận, hoặc failover nhà cung cấp.
Sự phân tách này đặc biệt hữu ích khi di trú khỏi khả năng Sampling bị ngừng hỗ trợ. Nếu một máy chủ MCP hoặc agent tiêu thụ nó vẫn cần suy luận mô hình, ứng dụng có thể gọi API mô hình trực tiếp thay vì phụ thuộc vào luồng Sampling cũ của MCP.
Khi nào một cổng mô hình hợp nhất hữu ích
Cổng mô hình hợp nhất có thể giảm công việc vận hành khi:
nhiều máy chủ MCP cần truy cập các nhà cung cấp mô hình khác nhau;
các công cụ khác nhau cần mô hình khác nhau;
đội muốn chuyển đổi mô hình mà không viết lại tích hợp đặc thù nhà cung cấp;
thông tin xác thực, sử dụng, và tính phí cần được quản lý tập trung;
truy cập mô hình nên độc lập với thay đổi transport MCP.
CometAPI cung cấp endpoint tương thích OpenAI có thể dùng làm lớp truy cập mô hình phía sau ứng dụng MCP. Điều này giữ logic nhà cung cấp mô hình tách biệt khỏi công cụ, resource, và điều phối tác vụ của MCP.
Ví dụ, một công cụ MCP có thể gọi mô hình qua cùng client tương thích OpenAI dùng ở nơi khác trong ứng dụng:
Máy chủ MCP vẫn chịu trách nhiệm cho hợp đồng công cụ, uỷ quyền, trạng thái, và xử lý kết quả. Cổng mô hình xử lý lựa chọn mô hình, truy cập nhà cung cấp, và phản hồi suy luận.
Giữ các lớp này tách biệt mang lại hai lợi ích thực tế:
Client và server MCP có thể di trú sang giao thức mới mà không thay đổi lớp tích hợp mô hình.
Nhà cung cấp mô hình có thể được thay đổi mà không phải thiết kế lại công cụ MCP hoặc hành vi transport.
Thay thế trạng thái ẩn bằng handle hoặc lưu trữ chia sẻ.
Trả về resultType.
Thay yêu cầu do máy chủ khởi tạo bằng MRTR.
Bảo vệ requestState.
Xác thực mọi inputResponses.
Thêm tính idempotent cho tác dụng phụ.
Trả về danh sách quyết định được.
Công bố gợi ý cache thận trọng.
Di trú công việc dài hạn sang tiện ích mở rộng Tasks.
Gateway và hạ tầng
Xác thực header yêu cầu MCP.
So sánh header với body yêu cầu.
Gỡ định tuyến dính không cần thiết.
Kiểm thử yêu cầu qua nhiều instance.
Phân vùng cache theo ranh giới uỷ quyền.
Thêm bus thông báo chia sẻ khi cần.
Theo dõi traffic kế thừa và lỗi thời.
Duy trì đường rollback trong giai đoạn canary.
Câu hỏi thường gặp
MCP 2026-07-28 là gì?
MCP 2026-07-28 là đặc tả Model Context Protocol phát hành ngày 28 tháng 7, 2026. Nó giới thiệu lõi giao thức không trạng thái, Yêu cầu Nhiều vòng khứ hồi, header định tuyến HTTP, kết quả có thể cache, thay đổi uỷ quyền, tiện ích mở rộng, và vòng đời ngừng hỗ trợ chính thức.
Mcp-Session-Id có bị gỡ không?
Có. Giao thức Streamable HTTP mới không còn dùng Mcp-Session-Id.
Ứng dụng vẫn có thể bảo tồn trạng thái qua handle tường minh, lưu trữ chia sẻ, tác vụ bền bỉ, hoặc giá trị request-state được bảo vệ.
Thủ tục bắt tay khởi tạo MCP có bị gỡ không?
Có. Yêu cầu hiện đại không còn bắt buộc trao đổi initialize và notifications/initialized.
Máy chủ phải triển khai server/discover, mặc dù client không cần gọi trước mọi thao tác.
MCP không trạng thái có nghĩa công cụ không thể bảo tồn trạng thái?
Không. Không trạng thái đề cập đến lớp giao thức.
Một công cụ vẫn có thể lưu trạng thái, nhưng xử lý yêu cầu không nên phụ thuộc vào affinity transport ẩn hoặc một tiến trình máy chủ cụ thể.
MRTR là gì?
Yêu cầu Nhiều vòng khứ hồi cho phép máy chủ yêu cầu thêm đầu vào từ client hoặc người dùng mà không gửi yêu cầu do máy chủ khởi tạo qua kết nối hai chiều mở liên tục.
Máy chủ trả về input_required, và client retry thao tác gốc với phản hồi được yêu cầu.
HTTP+SSE có bị gỡ ngay không?
Không. Nó bị ngừng hỗ trợ thay vì gỡ ngay.
Máy chủ mới nên dùng Streamable HTTP, trong khi hệ thống hiện có nên đo lường và di trú traffic HTTP+SSE còn lại.
Client SDK TypeScript v2 có tự động dùng MCP 2026-07-28 không?
Không. SDK v2 cần cấu hình thương lượng phiên bản rõ ràng để dùng giao thức hiện đại.
Dùng thương lượng tự động khi client phải hoạt động với cả máy chủ hiện đại và kế thừa.
Khuyến nghị cuối cùng
MCP 2026-07-28 giúp hạ tầng MCP từ xa dễ mở rộng, định tuyến, cache, và quan sát. Rủi ro di trú chính không chỉ là gỡ một header hay thủ tục bắt tay. Đó là trạng thái ứng dụng ẩn và logic tương tác có thể vẫn phụ thuộc vào chúng.
Trước khi triển khai giao thức mới:
Tìm mọi phụ thuộc vào khởi tạo và Mcp-Session-Id.
Chuyển trạng thái bắt buộc vào handle tường minh hoặc lưu trữ chia sẻ.
Triển khai MRTR với hết hạn, bảo vệ chống replay, và tính idempotent.
Xác thực header MCP với body JSON-RPC.
Phân vùng cache theo tenant và phạm vi uỷ quyền.
Củng cố xác thực issuer của OAuth.
Đo các phương thức bị ngừng hỗ trợ và traffic transport kế thừa.
Canary đường giao thức hiện đại và cũ trước khi nghỉ hưu.
Hãy coi di trú là thay đổi hạ tầng thay vì nâng cấp SDK thường lệ.
Khi lớp MCP đã không trạng thái và quan sát được, hãy giữ truy cập mô hình phía sau một giao diện riêng. Điều này cho phép giao thức công cụ và lớp nhà cung cấp mô hình phát triển độc lập.
Kiểm toán client OAuth và lưu trữ thông tin xác thực
Công việc dài hạn
Tasks thử nghiệm trong core
Tiện ích mở rộng io.modelcontextprotocol/tasks
Chuyển sang hợp đồng tiện ích mở rộng
Tính năng cũ
Roots, Sampling, Logging, HTTP+SSE
Bị ngừng hỗ trợ
Ngừng áp dụng mới và đo lường mức sử dụng hiện tại
Quy tắc issuer mạnh hơn và hướng CIMD
Kiểm toán client OAuth và lưu trữ thông tin xác thực
Công việc dài hạn
Tasks thử nghiệm trong core
Tiện ích mở rộng io.modelcontextprotocol/tasks
Chuyển sang hợp đồng tiện ích mở rộng
Tính năng cũ
Roots, Sampling, Logging, HTTP+SSE
Bị ngừng hỗ trợ
Ngừng áp dụng mới và đo lường mức sử dụng hiện tại
MCP 2026-07-28 Hướng dẫn chuyển đổi: Máy chủ không trạng thái - CometAPI