Solutions Choose your path
For individuals Build, learn, and create with simple usage-based access. For business Scale teams, billing, governance, and model workflows. More English 繁體中文 日本語 한국어 Français Deutsch Español Italiano Português Русский العربية ไทย Tiếng Việt Bahasa Indonesia Bahasa Melayu Türkçe Polski Nederlands Danish Norsk Қазақ اردو
เริ่มต้นฟรี เริ่มต้นฟรี
500+ AI Model API, All In One API.
Just In CometAPI © 2026 CometAPI · All rights reserved
Home Blog MCP 2026-07-28 คู่มือการย้าย: เซิร์ฟเวอร์แบบไร้สถานะ technology / งานวิจัย CometAPI
MCP 2026-07-28 คู่มือการย้าย: เซิร์ฟเวอร์แบบไร้สถานะ เรียนรู้วิธีการย้ายไปยัง MCP 2026-07-28 รวมถึงการรับส่งข้อมูลแบบไร้สถานะ, MRTR, ส่วนหัวการกำหนดเส้นทาง, การแคช, การเปลี่ยนแปลงใน OAuth และการอัปเกรด SDK
Mia Maren ทีมวิจัยโมเดล AI และ API เรียนรู้วิธีการย้ายไปยัง MCP 2026-07-28 รวมถึงการรับส่งข้อมูลแบบไร้สถานะ, MRTR, ส่วนหัวการกำหนดเส้นทาง, การแคช, การเปลี่ยนแปลงใน OAuth และการอัปเกรด SDK
ใช้สรุปนี้เพื่อดูคำตอบอย่างรวดเร็ว แล้วอ่านคู่มือเพื่อดูบริบท ตัวอย่าง และรายละเอียดการใช้งาน
from openai import OpenAI
client = OpenAI(
api_key="YOUR_COMETAPI_KEY",
base_url="https://api.cometapi.com/v1",
)
response = client.chat.completions.create(
model="gpt-5-mini",
messages=[{"role": "user", "content": "Build this workflow."}],
)
print(response.choices[0].message.content)TL;DR: MCP 2026-07-28 ยกเลิกเซสชันในระดับโปรโตคอลและการจับมือเริ่มต้นที่บังคับ ทีมโปรดักชันควรค้นหาการพึ่งพาเซสชันที่ซ่อนอยู่ ปรับใช้เมทาดาตาโปรโตคอลต่อคำขอ ดำเนินการ Multi Round-Trip Requests ปรับนโยบายเกตเวย์ และทำแคนารีโปรโตคอลใหม่ก่อนเลิกใช้พฤติกรรมแบบเดิม
สเปก Model Context Protocol ที่ออกเมื่อวันที่ 28 กรกฎาคม 2026 นำเสนอการเปลี่ยนแปลงสถาปัตยกรรมครั้งใหญ่ที่สุดของ MCP นับตั้งแต่มีการเพิ่มการรองรับ remote transport
โปรโตคอลตอนนี้ใช้แกนกลางแบบไร้สถานะในรูปแบบคำขอ-คำตอบ ข้อมูลแลกเปลี่ยน initialize และ notifications/initialized ที่เคยบังคับถูกยกเลิก Mcp-Session-Id ถูกถอดออก และแต่ละคำขอจะพกข้อมูลโปรโตคอลที่จำเป็นต่อการประมวลผลมาด้วย
รุ่นนี้ยังเพิ่ม Multi Round-Trip Requests เฮดเดอร์สำหรับการทำเส้นทาง HTTP การตอบกลับแบบรายการที่แคชได้ พฤติกรรมการอนุญาตที่เข้มงวดขึ้น เฟรมเวิร์กส่วนขยาย และวัฏจักรการเลิกใช้อย่างเป็นทางการ ดู
เรียนรู้ต่อ
เชื่อมโยงบทความนี้กับการตัดสินใจถัดไป ดูทุกหัวข้อ เผยแพร่เมื่อ Jul 29, 2026 ตรวจสอบความชัดเจน การอ้างอิงแหล่งที่มา และคำศัพท์ API ปัจจุบันแล้ว
การเปลี่ยนแปลงเหล่านี้ทำให้เซิร์ฟเวอร์ MCP แบบรีโมตปรับขนาดได้ง่ายขึ้นหลังโครงสร้างพื้นฐาน HTTP มาตรฐาน แต่ไม่ได้ทำให้แอปพลิเคชันที่มีอยู่กลายเป็นไร้สถานะโดยอัตโนมัติ
ในสภาพโปรดักชัน เซิร์ฟเวอร์อาจยังพึ่งพาเวิร์กสเปซในหน่วยความจำ การรูตแบบ sticky ครับเดนเชียลที่ผูกกับเซสชัน สตรีมแบบยาว หรือปฏิสัมพันธ์ที่เริ่มโดยเซิร์ฟเวอร์ คู่มือนี้มุ่งเน้นที่การค้นหาและแทนที่การพึ่งพาเหล่านั้น
ใครต้องย้ายเวอร์ชัน? ระดับความยากขึ้นอยู่กับการใช้งาน MCP ในระบบของคุณ
Local stdio server with one-shot tools Low อัปเกรด SDK และทดสอบการเจรจาโปรโตคอล Remote HTTP server with no cross-request state Medium เพิ่มเมทาดาตาสมัยใหม่ กลไก discovery และเฮดเดอร์ HTTP Server using Mcp-Session-Id for business state High แทนที่สถานะที่ซ่อนอยู่ด้วยแฮนเดิลแบบชัดเจนหรือสตอเรจที่แชร์ Gateway parsing JSON-RPC bodies for routing Medium to high เพิ่มและตรวจสอบเฮดเดอร์การทำเส้นทาง MCP Tools requesting information or approval mid-call High ย้ายปฏิสัมพันธ์ไปใช้ MRTR Client using Dynamic Client Registration High ทำให้การจัดการ issuer เข้มแข็งขึ้นและเตรียมสำหรับ CIMD Server using legacy HTTP+SSE High ย้ายไปใช้ Streamable HTTP Workflow using experimental Tasks High ใช้ส่วนขยาย Tasks อย่างเป็นทางการ
เซิร์ฟเวอร์โลคัลที่ไม่เก็บสถานะข้ามคำขออาจต้องการแค่อัปเกรด SDK และทดสอบความเข้ากันได้
การดีพลอยรีโมตที่ใช้เซสชัน OAuth การสตรีม หรือคำขอที่เริ่มจากเซิร์ฟเวอร์ ต้องการการย้ายเป็นช่วงๆ
มีอะไรเปลี่ยนใน MCP 2026-07-28? Initialization ต้องจับมือ initialize ไม่ต้องจับมือ ลบเกทการ initialize ของคำขอสมัยใหม่ Sessions Mcp-Session-Id ไม่มีเซสชันระดับโปรโตคอล ทำสถานะที่ต้องใช้ให้ชัดเจน Discovery เจรจาระหว่างการ initialize มี server/discover แบบออปชัน ใช้ discovery และการเจรจาเวอร์ชัน Request context เก็บบนคอนเนกชัน รวมใน _meta ของคำขอ ส่งเมทาดาตาโปรโตคอลต่อคำขอ HTTP routing เกตเวย์แยก JSON body เฮดเดอร์ Mcp-Method และ Mcp-Name อัปเดตการทำเส้นทาง นโยบาย และการสังเกตการณ์ Mid-call interaction เซิร์ฟเวอร์ส่ง JSON-RPC เข้าไปกลางคัน ใช้ Multi Round-Trip Requests จัดการ input_required และการรีไทร List caching ดึงแคตตาล็อกซ้ำๆ ttlMs, cacheScope, การจัดเรียงแบบกำหนดได้ เพิ่มแคชที่คำนึงถึงการอนุญาต Notifications GET stream และการสมัคร resource subscriptions/listen ย้ายการแจ้งเปลี่ยนไปสตรีมใหม่ Authorization การลงทะเบียน DCR เป็นศูนย์กลาง กฎ issuer ที่เข้มขึ้น และทิศทางสู่ CIMD ตรวจสอบ OAuth client และที่เก็บ credentials
1. ตรวจสอบการใช้งานที่มีอยู่ ก่อนอัปเกรด ค้นหาในไคลเอนต์ เซิร์ฟเวอร์ เกตเวย์ และคอนฟิกดีพลอยสำหรับสมมติฐานโปรโตคอลแบบเก่า
Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID
เซิร์ฟเวอร์ปฏิเสธการเรียกจนกว่าจะ initialize เสร็จหรือไม่?
session ID ใช้เลือกผู้ใช้ ครับเดนเชียล เวิร์กสเปซ หรือบทสนทนาหรือไม่?
อินสแตนซ์เซิร์ฟเวอร์อื่นสามารถทำต่อจากเวิร์กโฟลว์ที่อินสแตนซ์แรกเริ่มไว้ได้หรือไม่?
ตัวโหลดบาลานเซอร์ต้องใช้ session affinity หรือไม่?
เครื่องมือทำผลข้างเคียงก่อนขอคอนเฟิร์มหรือไม่?
เกตเวย์แยก body เพื่อระบุเมธอดหรือทูลหรือไม่?
เก็บ OAuth credentials โดยไม่มีข้อมูล authorization server ที่ออกให้หรือไม่?
ไคลเอนต์พึ่งพา SSE reconnection หรือการส่งข้อความซ้ำหรือไม่?
รายการเครื่องมือหรือทรัพยากรแตกต่างกันตามคอนเนกชันหรือไม่?
ฟีเจอร์ที่เลิกใช้ใดบ้างยังมีทราฟฟิกโปรดักชัน?
อย่าถอด Mcp-Session-Id ออกจนกว่าจะเข้าใจว่ามีการเก็บอะไรไว้หลังมันในแอปพลิเคชัน
เซิร์ฟเวอร์ที่ถอดเฮดเดอร์นี้ออกแต่ยังคงสถานะไว้ในหน่วยความจำโลคัลอาจใช้งานได้ระหว่างพัฒนา แต่ล้มเหลวเป็นครั้งคราวเมื่อคำขอกระจายไปยังหลายอินสแตนซ์
2. แทนที่สถานะเซสชันที่ซ่อนอยู่ MCP 2026-07-28 ยกเลิกเซสชันระดับโปรโตคอล ไม่ใช่สถานะแอปพลิเคชัน
สถานะที่ต้องใช้ข้ามการเรียกควรใช้หนึ่งในสามแพทเทิร์นนี้
แฮนเดิลแบบชัดเจน คืนแฮนเดิลที่สร้างโดยเซิร์ฟเวอร์จากทูลหนึ่ง แล้วต้องใช้ในคำเรียกถัดไป
{
"resultType" : "complete" ,
"content" : [
{
"type" : "text" ,
"text" : "สร้างเวิร์กสเปซแล้ว"
}
] ,
"structuredContent" : {
"workspaceHandle" : "ws_7f93a2"
}
}
คำขอภายหลังจะส่งแฮนเดิลเป็นอาร์กิวเมนต์ปกติ:
{
"name" : "update_workspace" ,
"arguments" : {
"workspaceHandle" : "ws_7f93a2" ,
"status" : "approved"
}
}
วิธีนี้ทำให้การพึ่งพาปรากฏชัดในสัญญาของทูล และให้เซิร์ฟเวอร์ใดๆ ที่เข้ากันได้ประมวลผลคำขอได้
สตอเรจที่แชร์ ใช้ฐานข้อมูล แคชกระจาย ออบเจ็กต์สโตร์ หรือระบบงานที่ทนทานเมื่อ:
คนงานหลายตัวต้องใช้สถานะเดียวกัน
เวิร์กโฟลว์ต้องอยู่รอดจากการรีสตาร์ต
สถานะใหญ่เกินกว่าจะเป็นแฮนเดิล
เวิร์กโฟลว์นานเกินคำขอเดียว
ต้องการพฤติกรรมแบบทรานแซกชันหรือใช้ครั้งเดียว
requestState ที่ได้รับการป้องกันMRTR สามารถส่งคืนค่า requestState แบบทึบที่ไคลเอนต์สะท้อนคืนเมื่อรีไทรคำขอเดิม
เนื่องจากค่านี้ผ่านไคลเอนต์ ควรป้องกันด้วย HMAC หรือการเข้ารหัสที่พิสูจน์ความถูกต้อง ผูกมันเข้ากับ principal ที่ยืนยันตัวตน เมธอดเดิม พารามิเตอร์สำคัญ เวลา expiration และ nonce เมื่อต้องการการป้องกันการเล่นซ้ำ
อย่าเชื่อถือค่า requestState ที่ไม่มีลายเซ็นเพียงเพราะไคลเอนต์ส่งคืนมาแบบไม่เปลี่ยน
3. ใช้คำขอแบบพึ่งพาตนเองและ Discovery คำขอ MCP สมัยใหม่มีบริบทโปรโตคอลอยู่ใน _meta
คำเรียกทูลผ่าน Streamable HTTP อาจมีหน้าตาแบบนี้:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
"jsonrpc": "2.0",
"id": "req-101",
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"query": "การย้าย MCP แบบไร้สถานะ"
},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "example-client",
"version": "2.0.0"
},
"io.modelcontextprotocol/clientCapabilities": {
"elicitation": {}
}
}
}
}
เซิร์ฟเวอร์ที่รองรับโปรโตคอลใหม่ต้องมี server/discover ซึ่งโฆษณาเวอร์ชันที่รองรับ ความสามารถ และเอกลักษณ์ของเซิร์ฟเวอร์ ไคลเอนต์อาจเรียกก่อนปฏิบัติการอื่น หรือใช้เพื่อดูว่าต้องถอยกลับแบบเดิมหรือไม่
อ่านเอกสาร server/discover documentation สำหรับสัญญาการตอบกลับ
การเจรจาเวอร์ชันใน TypeScript SDK การอัปเกรด TypeScript SDK อย่างเดียวไม่ได้ทำให้ไคลเอนต์สลับไปใช้โปรโตคอลใหม่โดยอัตโนมัติ
ไคลเอนต์ที่ใช้ SDK v2 ต้องระบุให้ชัดเจน:
const client = new Client (
{
name : "my-client" ,
version : "1.0.0"
},
{
versionNegotiation : {
mode : "auto"
}
}
);
await client.connect (transport);
ในโหมดอัตโนมัติ SDK จะสำรวจด้วย server/discover และสามารถถอยกลับไปสู่โฟลว์ initialize แบบเก่าเมื่อเจอเซิร์ฟเวอร์รุ่นเดิม
4. แทนที่คำขอที่เริ่มโดยเซิร์ฟเวอร์ด้วย MRTR การใช้งาน MCP ก่อนหน้าสามารถส่งคำขอเช่น elicitation/create sampling/createMessage หรือ roots/list จากเซิร์ฟเวอร์ไปยังไคลเอนต์ได้
โปรโตคอลใหม่แทนโมเดลนั้นด้วย Multi Round-Trip Requests
ไคลเอนต์ส่งคำขอต้นฉบับ
เซิร์ฟเวอร์ส่งกลับ resultType: "input_required"
ไคลเอนต์รวบรวมข้อมูลหรือการอนุมัติที่ร้องขอ
ไคลเอนต์รีไทรปฏิบัติการเดิมโดยใช้ JSON-RPC ID ใหม่
การรีไทรรวม inputResponses และ requestState เดิม
เซิร์ฟเวอร์ทำคำขอสำเร็จหรือเริ่มรอบใหม่
{
"jsonrpc" : "2.0" ,
"id" : "delete-1" ,
"result" : {
"resultType" : "input_required" ,
"inputRequests" : {
"confirm_delete" : {
"method" : "elicitation/create" ,
"params" : {
"mode" : "form" ,
"message" : "ลบโปรเจกต์ project_123 หรือไม่?" ,
"requestedSchema" : {
"type" : "object" ,
"properties" : {
"confirmed" : {
"type" : "boolean"
}
} ,
"required" : [ "confirmed" ]
}
}
}
} ,
"requestState" : "protected-expiring-state"
}
}
ไคลเอนต์รีไทรปฏิบัติการเดิม:
{
"jsonrpc" : "2.0" ,
"id" : "delete-2" ,
"method" : "tools/call" ,
"params" : {
"name" : "delete_project" ,
"arguments" : {
"projectId" : "project_123"
} ,
"inputResponses" : {
"confirm_delete" : {
"action" : "accept" ,
"content" : {
"confirmed" : true }
}
} ,
"requestState" : "protected-expiring-state"
}
}
การใช้งาน MRTR ในโปรดักชันควรกำหนด:
จำนวนรอบสูงสุด
เวลาหมดอายุของ request-state
พฤติกรรมการยกเลิกและการปฏิเสธ
การตรวจสอบสคีมาของคำตอบ
การตรวจสอบสิทธิ์ทุกครั้งที่รีไทร
การป้องกันการเล่นซ้ำ
ความเป็น idempotent สำหรับผลข้างเคียง
พฤติกรรมเมื่อไคลเอนต์ไม่รองรับความสามารถที่ร้องขอ
หลีกเลี่ยงการทำธุรกรรม เช่น การซื้อ การลบ การหักเครดิต หรือการเขียนภายนอก ให้เสร็จ ก่อนส่ง input_required
ใช้ปฏิบัติการแบบเป็นขั้นหรือตั้งคีย์ idempotency เพื่อให้การรีไทรไม่ทำงานซ้ำ ดู สเปก MRTR อย่างเป็นทางการ สำหรับโมเดลปฏิสัมพันธ์เต็มรูปแบบ
5. อัปเดตเกตเวย์ แคช และการอนุญาต การเปลี่ยนแปลงโครงสร้างพื้นฐานเหล่านี้เกี่ยวข้องกันอย่างใกล้ชิดและควรทดสอบร่วมกัน
ตรวจสอบความถูกต้องของเฮดเดอร์การทำเส้นทาง MCP คำขอ Streamable HTTP แบบ POST ตอนนี้รวม:
MCP-Protocol-VersionMcp-MethodMcp-Name เฮดเดอร์เหล่านี้ช่วยให้เกตเวย์ทำเส้นทาง คิดค่า ใช้สิทธิ์ และจำกัดอัตราทราฟฟิกได้โดยไม่ต้องแยก JSON ทุก body
สามารถรองรับคอนโทรลต่างๆ เช่น:
ขีดจำกัดอัตราแบบเฉพาะทูล
นโยบายแยกสำหรับเมธอดรายการกับเมธอดปฏิบัติการ
พูลคนงานเฉพาะสำหรับทูลที่แพง
การเข้าถึงที่จำกัดสำหรับปฏิบัติการความเสี่ยงสูง
เมตริกความหน่วงและข้อผิดพลาดแยกตามทูล
การจัดสรรต้นทุนโครงสร้างพื้นฐาน
อย่างไรก็ตาม ค่ายังมาจากไคลเอนต์ เปรียบเทียบกับ JSON-RPC body ก่อนบังคับใช้นโยบาย
คำขอจะต้องไม่สามารถอ้างว่าเป็นทูลความเสี่ยงต่ำใน Mcp-Name ขณะเรียกทูลอื่นใน body ได้ ควรปฏิเสธและบันทึกความไม่ตรงกันระหว่างเฮดเดอร์กับ body
ใช้กุญแจแคชที่คำนึงถึงการอนุญาต โปรโตคอลใหม่เพิ่ม ttlMs และ cacheScope ให้กับผลลัพธ์ที่แคชได้ ได้แก่:
tools/listprompts/listresources/listresources/templates/listresources/read protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
อย่านำรายการแคชแบบ private ไปใช้ข้ามผู้ใช้หรือผู้เช่า เพียงเพราะ TTL ยังไม่หมดอายุ
การจัดเรียงทูลแบบกำหนดได้สำคัญเช่นกัน แคตตาล็อกที่เสถียรช่วยหลีกเลี่ยงแคชมิสโดยไม่จำเป็น และอาจเพิ่มโอกาสการใช้ prompt-cache ของโมเดลซ้ำเมื่อมีการแทรกคำจำกัดความของทูลเข้าไปในพรอมต์
ทำให้การจัดการ OAuth Issuer เข้มแข็งขึ้น
ตรวจสอบค่า iss ที่ได้รับเทียบกับ issuer ที่บันทึกไว้สำหรับโฟลว์นั้น
ผูกการเก็บ client credentials ตาม issuer
อย่าใช้ credentials ซ้ำกับ authorization server อื่น
ตั้งค่า application_type ที่เหมาะสมระหว่าง DCR
เตรียมอินทิเกรชันใหม่สำหรับ Client ID Metadata Documents
Dynamic Client Registration ยังคงใช้ได้เพื่อความเข้ากันได้ย้อนหลัง แต่เลิกใช้เป็นแนวทางหลักในการลงทะเบียน
6. ย้าย Notifications, Tasks และฟีเจอร์ที่เลิกใช้ เส้นทางการแจ้งเตือนผ่าน HTTP GET แบบเก่า และโฟลว์ resources/subscribe หรือ resources/unsubscribe ถูกแทนที่ด้วย subscriptions/listen
ไคลเอนต์เปิดสตรีมการตอบกลับ POST แบบยาวและเลือกเข้ารับหมวดการแจ้งเตือนที่ต้องการ การแจ้งเตือนความคืบหน้าและล็อกที่เฉพาะกับคำขอยังคงผูกอยู่กับสตรีมการตอบกลับของคำขอนั้น
สำหรับดีพลอยหลายอินสแตนซ์ ใช้บัสเหตุการณ์ที่แชร์เมื่อการแจ้งเตือนที่สร้างบนอินสแตนซ์หนึ่งต้องไปถึงการสมัครที่เชื่อมต่อกับอีกอินสแตนซ์หนึ่ง
ส่วนขยาย Tasks งานระยะยาวถูกย้ายออกจากคอร์โปรโตคอลเชิงทดลองไปยัง:
io.modelcontextprotocol/tasks
tasks/get สำหรับโพลลิงtasks/update สำหรับอัปเดตจากไคลเอนต์ไปเซิร์ฟเวอร์แฮนเดิลงานแบบทนทาน
subscriptions/listen สำหรับอัปเดตที่เลือกเข้ารับ รูปแบบ tasks/result และ tasks/list แบบเก่าไม่ควรถูกนำไปยังการใช้งานใหม่
ฟีเจอร์ที่เลิกใช้ ฟีเจอร์ต่อไปนี้เลิกใช้แล้ว:
Roots ส่งโฟลเดอร์ผ่านอาร์กิวเมนต์ทูล URI ของ resource หรือคอนฟิก ไม่ต้องจับมือ ลบเกทการ initialize ของคำขอสมัยใหม่ Sampling อินทิเกรตตรงกับ API ของผู้ให้บริการโมเดล ไม่มีเซสชันระดับโปรโตคอล ทำสถานะที่ต้องใช้ให้ชัดเจน Logging ใช้ stderr สำหรับ stdio หรือ OpenTelemetry ในโปรดักชัน มี server/discover แบบออปชัน ใช้ discovery และการเจรจาเวอร์ชัน Dynamic Client Registration มุ่งไปที่ Client ID Metadata Documents รวมเมทาดาตาโปรโตคอลต่อคำขอใน _meta ส่งเมทาดาตาโปรโตคอลต่อคำขอ Legacy HTTP+SSE ย้ายไป Streamable HTTP เฮดเดอร์ Mcp-Method และ Mcp-Name อัปเดตการทำเส้นทาง นโยบาย และการสังเกตการณ์ Deprecated includeContext values ตัดฟิลด์นี้ออกหรือใช้ "none" Multi Round-Trip Requests จัดการ input_required และการรีไทร List caching ดึงแคตตาล็อกซ้ำๆ ttlMs, cacheScope, การจัดเรียงแบบกำหนดได้ เพิ่มแคชที่คำนึงถึงการอนุญาต Notifications GET stream และการสมัคร resource subscriptions/listen ย้ายการแจ้งเปลี่ยนไปสตรีมใหม่ Authorization การลงทะเบียนแบบ DCR เป็นศูนย์กลาง
ฟังก์ชันที่เลิกใช้ยังมีในช่วงหน้าต่างการเลิกใช้ แต่ไม่ควรนำไปใช้ในงานใหม่ นโยบายวัฏจักร MCP ให้ระยะเลิกใช้น้อยที่สุดสิบสองเดือน; ไม่ได้หมายความว่าทุกฟีเจอร์จะมีวันยืนยันการถอดออกเหมือนกัน
7. ปล่อยการย้ายอย่างปลอดภัย อย่าเปลี่ยนไคลเอนต์ เซิร์ฟเวอร์ เกตเวย์ แคช และการอนุญาตในรีลีสที่ไม่มีการสังเกตเดียวกัน
ลำดับการย้ายที่แนะนำ
สำรวจเวอร์ชันโปรโตคอล SDK เซสชัน ทราฟฟิก SSE ไคลเอนต์ DCR และเมธอดที่เลิกใช้
อัปเกรด SDK ในสภาพแวดล้อมที่ไม่ใช่โปรดักชัน
เพิ่ม server/discover และการเจรจาเวอร์ชัน
แทนที่การพึ่งพาเซสชันที่ซ่อนอยู่
ใช้และทำให้ MRTR ปลอดภัย
เพิ่มเฮดเดอร์การทำเส้นทางที่ตรวจสอบได้และแคชแบบกำหนดขอบเขต
ทดสอบขอบเขต issuer ของการอนุญาต
ทำแคนารีโปรโตคอลสมัยใหม่คู่กับเส้นทางรุ่นเดิม
เลิกพฤติกรรมเก่าเมื่อทบทวนเทเลเมทรีแล้วเท่านั้น
ความเข้ากันได้ระหว่างแคนารี Modern client + modern server
→ ใช้ MCP 2026-07-28
Modern client + legacy server
→ สำรวจและถอยกลับเมื่อรองรับ
Legacy client + dual-version server
→ เดินต่อบนเส้นทางรุ่นเดิม
Unsupported combination
→ ส่งคืนข้อผิดพลาดเวอร์ชันโปรโตคอลที่ชัดเจน
การออกสเปก MCP ใหม่ไม่ใช่สวิตช์ของทั้งอีโคซิสเต็ม ไคลเอนต์ เซิร์ฟเวอร์ SDK และแพลตฟอร์มโฮสต์จะย้ายด้วยความเร็วต่างกัน
เทเลเมทรีที่ควรบันทึก Protocol version per request การยอมรับและชุดที่เข้ากันไม่ได้ Discovery success and fallback rate พฤติกรรมการเจรจาเวอร์ชัน Missing or invalid MCP headers ไคลเอนต์เก่าหรือข้อผิดพลาดเกตเวย์ Header/body mismatches บั๊กไคลเอนต์หรือความพยายามหลบนโยบาย MRTR requested and completed ความน่าเชื่อถือของเวิร์กโฟลว์เชิงโต้ตอบ MRTR rejected or timed out เส้นทางความล้มเหลวของผู้ใช้และไคลเอนต์ Request-state verification failures การดัดแปลง การเล่นซ้ำ หรือหมดอายุ Duplicate-operation prevention ประสิทธิผลของการควบคุม idempotency Cache hit rate by scope การลดทราฟฟิกอย่างปลอดภัย Issuer validation failures ปัญหาการคอนฟิก OAuth HTTP+SSE traffic งานย้ายเลเยอร์ขนส่งที่เหลือ Deprecated-method traffic หลักฐานสำหรับการวางแผนเลิกใช้ Tool latency and accepted-task rate ความเชื่อถือได้ที่ผู้ใช้เห็น
คำขอ tools/call แบบ one-shot ที่สำเร็จไม่พอสำหรับวัดการย้าย เวิร์กโฟลว์ที่หมดเวลา ขออินพุตโดยไม่จำเป็น หรือเขียนภายนอกซ้ำ ถือเป็นความล้มเหลวในโปรดักชัน
MCP ไม่ได้แทนที่ API ของโมเดล สองเลเยอร์นี้แก้ปัญหาการเชื่อมต่อคนละแบบ
MCP เชื่อมเอเจนต์กับเครื่องมือ ทรัพยากร พรอมต์ การอนุมัติ และงาน Unified model API เชื่อมแอปกับโมเดล ครอบครองสิทธิ์ การใช้งาน และการคิดเงิน Application orchestration ตัดสินใจว่าเมื่อไรและอย่างไรจะเรียกโมเดลและเครื่องมือ
สถาปัตยกรรมโปรดักชันทั่วไปมีลักษณะดังนี้:
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP ทำให้มาตรฐานการปฏิสัมพันธ์ของเอเจนต์กับเครื่องมือและคอนเท็กซ์ แต่ไม่ได้ทำมาตรฐานราคาของโมเดล ครับเดนเชียลของผู้ให้บริการโมเดล เอ็นด์พอยต์อินเฟอเรนซ์ หรือการเฟลโอเวอร์ของผู้ให้บริการ
การแยกนี้มีประโยชน์อย่างยิ่งเมื่อย้ายออกจากความสามารถ Sampling ที่เลิกใช้ หากเซิร์ฟเวอร์ MCP หรือเอเจนต์ที่ใช้ยังต้องการอินเฟอเรนซ์โมเดล แอปสามารถเรียก API ของโมเดลโดยตรงแทนการพึ่งพาโฟลว์ Sampling เดิมของ MCP
เมื่อไรควรใช้ Unified Model Gateway เกตเวย์โมเดลแบบรวมช่วยลดงานปฏิบัติการเมื่อ:
เซิร์ฟเวอร์ MCP หลายตัวต้องเข้าถึงผู้ให้บริการโมเดลต่างกัน
เครื่องมือต่างกันต้องการโมเดลต่างกัน
ทีมอยากสลับโมเดลโดยไม่ต้องเขียนอินทิเกรชันเฉพาะผู้ให้บริการใหม่
ครอบครองสิทธิ์ การใช้งาน และการคิดเงินต้องการการจัดการแบบศูนย์กลาง
การเข้าถึงโมเดลควรเป็นอิสระจากการเปลี่ยนแปลง transport ของ MCP
CometAPI ให้เอ็นด์พอยต์ที่เข้ากันได้กับ OpenAI ซึ่งใช้เป็นเลเยอร์เข้าถึงโมเดลหลังแอป MCP ได้ ช่วยให้ตรรกะผู้ให้บริการโมเดลแยกจากเครื่องมือ ทรัพยากร และการจัดการงานของ MCP
ตัวอย่าง เครื่องมือ MCP สามารถเรียกโมเดลผ่านไคลเอนต์ที่เข้ากันกับ OpenAI เหมือนส่วนอื่นของแอป:
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.COMETAPI_KEY,
baseURL: "https://api.cometapi.com/v1"
});
export async function summarizeResource(content: string) {
const response = await client.chat.completions.create({
model: "your-selected-model",
messages: [
{
role: "system",
content: "สรุปทรัพยากรที่ให้มาอย่างชัดเจนและกระชับ"
},
{
role: "user",
content
}
]
});
return response.choices[0]?.message?.content ?? "";
}
เซิร์ฟเวอร์ MCP ยังคงรับผิดชอบสัญญาของทูล การอนุญาต สถานะ และการจัดการผลลัพธ์ ส่วนเกตเวย์โมเดลดูแลการเลือกโมเดล การเข้าถึงผู้ให้บริการ และการตอบกลับอินเฟอเรนซ์
การแยกเลเยอร์ให้ประโยชน์เชิงปฏิบัติ 2 ข้อ:
ไคลเอนต์และเซิร์ฟเวอร์ MCP ย้ายไปโปรโตคอลใหม่โดยไม่ต้องเปลี่ยนเลเยอร์อินทิเกรชันโมเดล
ผู้ให้บริการโมเดลสามารถเปลี่ยนได้โดยไม่ต้องออกแบบเครื่องมือ MCP หรือพฤติกรรม transport ใหม่
เช็กลิสต์การย้าย MCP 2026-07-28
Client
อัปเกรดเป็น SDK ที่เข้ากันได้
เปิดใช้การเจรจาเวอร์ชันแบบสมัยใหม่
รองรับ server/discover
ใส่เมทาดาตาโปรโตคอลในทุกคำขอ
จัดการ resultType
รองรับหรือปฏิเสธ MRTR อย่างชัดเจน
ใช้ JSON-RPC ID ใหม่สำหรับการรีไทร
เก็บและส่งคืน requestState
ตรวจสอบ OAuth issuer
เก็บ credentials ตาม issuer
เคารพ cache hints
รองรับ subscriptions/listen เมื่อจำเป็น
Server
ลบเกท initialize ของคำขอสมัยใหม่
ลบการพึ่งพา Mcp-Session-Id
ใช้ server/discover
แทนสถานะที่ซ่อนด้วยแฮนเดิลหรือสตอเรจที่แชร์
ส่งคืน resultType
แทนคำขอที่เริ่มโดยเซิร์ฟเวอร์ด้วย MRTR
ป้องกัน requestState
ตรวจสอบ inputResponses ทั้งหมด
เพิ่ม idempotency สำหรับผลข้างเคียง
ส่งคืนลิสต์แบบกำหนดได้
เผยแพร่ cache hints แบบอนุรักษนิยม
ย้ายงานยาวไปยังส่วนขยาย Tasks
Gateway และโครงสร้างพื้นฐาน
ตรวจสอบความถูกต้องของเฮดเดอร์คำขอ MCP
เปรียบเทียบเฮดเดอร์กับ body ของคำขอ
ลบการรูตแบบ sticky ที่ไม่จำเป็น
ทดสอบคำขอข้ามหลายอินสแตนซ์
แบ่งพาร์ทิชันแคชตามขอบเขตการอนุญาต
เพิ่มบัสการแจ้งเตือนที่แชร์เมื่อจำเป็น
ติดตามทราฟฟิกแบบเดิมและที่เลิกใช้
รักษาเส้นทางย้อนกลับระหว่างแคนารี
คำถามที่พบบ่อย
MCP 2026-07-28 คืออะไร? MCP 2026-07-28 คือสเปก Model Context Protocol ที่เผยแพร่เมื่อวันที่ 28 กรกฎาคม 2026 ซึ่งนำเสนอแกนโปรโตคอลแบบไร้สถานะ Multi Round-Trip Requests เฮดเดอร์สำหรับการทำเส้นทาง HTTP ผลลัพธ์ที่แคชได้ การเปลี่ยนแปลงการอนุญาต ส่วนขยาย และวัฏจักรการเลิกใช้อย่างเป็นทางการ
Mcp-Session-Id ถูกถอดออกหรือไม่?ใช่ โปรโตคอล Streamable HTTP ใหม่ไม่มี Mcp-Session-Id
แอปยังคงเก็บสถานะได้ผ่านแฮนเดิลแบบชัดเจน สตอเรจที่แชร์ งานที่ทนทาน หรือค่า request-state ที่ป้องกันแล้ว
การจับมือเริ่มต้นของ MCP ถูกถอดออกหรือไม่? ใช่ คำขอสมัยใหม่ไม่ต้องแลกเปลี่ยน initialize และ notifications/initialized
เซิร์ฟเวอร์ต้องมี server/discover แม้ไคลเอนต์ไม่ต้องเรียกก่อนทุกปฏิบัติการ
MCP แบบไร้สถานะหมายความว่าเครื่องมือเก็บสถานะไม่ได้หรือไม่? ไม่ ไร้สถานะหมายถึงเลเยอร์โปรโตคอล
เครื่องมือยังสามารถเก็บสถานะได้ แต่การประมวลผลคำขอไม่ควรพึ่งพาการผูกกับทรานสปอร์ตที่ซ่อนอยู่หรือโปรเซสเซิร์ฟเวอร์ตัวเดียว
MRTR คืออะไร? Multi Round-Trip Requests ช่วยให้เซิร์ฟเวอร์ร้องขอข้อมูลหรืออินพุตจากผู้ใช้เพิ่มเติมได้ โดยไม่ต้องส่งคำขอที่เริ่มจากเซิร์ฟเวอร์ผ่านการเชื่อมต่อแบบสองทางที่เปิดทิ้ง
เซิร์ฟเวอร์จะส่งกลับ input_required และไคลเอนต์รีไทรปฏิบัติการเดิมพร้อมคำตอบที่ร้องขอ
HTTP+SSE ถูกถอดออกทันทีหรือไม่? ไม่ ถูกเลิกใช้ แต่ไม่ได้ถอดออกทันที
เซิร์ฟเวอร์ใหม่ควรใช้ Streamable HTTP ขณะที่ระบบที่มีอยู่ควรวัดและย้ายทราฟฟิก HTTP+SSE ที่เหลือ
ไคลเอนต์ TypeScript SDK v2 ใช้ MCP 2026-07-28 โดยอัตโนมัติหรือไม่? ไม่ SDK v2 ต้องกำหนดค่าการเจรจาเวอร์ชันอย่างชัดเจนเพื่อใช้โปรโตคอลสมัยใหม่
ใช้โหมดอัตโนมัติเมื่อไคลเอนต์ต้องทำงานกับทั้งเซิร์ฟเวอร์สมัยใหม่และรุ่นเดิม
ข้อแนะนำสุดท้าย MCP 2026-07-28 ทำให้โครงสร้างพื้นฐาน MCP แบบรีโมตปรับขนาด ทำเส้นทาง แคช และสังเกตการณ์ได้ง่ายขึ้น ความเสี่ยงหลักของการย้ายไม่ใช่แค่การถอดเฮดเดอร์หรือจับมือ แต่มาจากสถานะแอปและตรรกะปฏิสัมพันธ์ที่ซ่อนอยู่ซึ่งอาจยังพึ่งพาสิ่งเหล่านั้น
ค้นหาการพึ่งพาการ initialize และ Mcp-Session-Id ทั้งหมด
ย้ายสถานะที่ต้องใช้ไปยังแฮนเดิลแบบชัดเจนหรือสตอเรจที่แชร์
ใช้ MRTR พร้อมหมดอายุ การป้องกันการเล่นซ้ำ และ idempotency
ตรวจสอบเฮดเดอร์ MCP เทียบกับ JSON-RPC body
แบ่งแคชตามผู้เช่าและขอบเขตการอนุญาต
ทำให้การตรวจ issuer ของ OAuth เข้มแข็ง
วัดเมธอดที่เลิกใช้และทราฟฟิก transport รุ่นเดิม
ทำแคนารีเส้นทางโปรโตคอลสมัยใหม่และรุ่นเดิมก่อนเลิกใช้
มองการย้ายครั้งนี้เป็นการเปลี่ยนโครงสร้างพื้นฐาน ไม่ใช่แค่อัปเกรด SDK ตามปกติ
เมื่อเลเยอร์ MCP ไร้สถานะและสังเกตการณ์ได้แล้ว ให้เก็บการเข้าถึงโมเดลไว้หลังอินเทอร์เฟซแยกต่างหาก เพื่อให้โปรโตคอลเครื่องมือกับเลเยอร์ผู้ให้บริการโมเดลพัฒนาได้อย่างอิสระต่อกัน
Long-running work Tasks เชิงทดลองในคอร์ ส่วนขยาย io.modelcontextprotocol/tasks ย้ายไปสัญญาของส่วนขยาย
Older features Roots, Sampling, Logging, HTTP+SSE เลิกใช้ (Deprecated) หยุดรับรองใหม่และวัดการใช้อยู่เดิม
กฎ issuer ที่เข้มขึ้น และทิศทางสู่ CIMD
ตรวจสอบ OAuth client และที่เก็บ credentials
Long-running work Tasks เชิงทดลองในคอร์ io.modelcontextprotocol/tasks extension ย้ายไปสัญญาของส่วนขยาย
Older features Roots, Sampling, Logging, HTTP+SSE เลิกใช้ หยุดรับรองใหม่และวัดการใช้อยู่เดิม
