ผู้ดูแล Model Context Protocol (MCP) ได้เผยแพร่แผนงานที่ได้รับการปรับปรุง ซึ่งจะกำหนดรูปแบบการเปิดตัวข้อกำหนดถัดไปของโปรโตคอล ซึ่งกลายเป็นมาตรฐานโดยพฤตินัยสำหรับการเชื่อมต่อโมเดล AI กับเครื่องมือและข้อมูลภายนอก โพสต์เมื่อวันที่ 22 สิงหาคม เขียนโดยหัวหน้าผู้ดูแล David Soria Parra และ Den Delimarsky กล่าวถึงประเด็นสำคัญ 5 ประการ ตั้งแต่การส่งข้อความแบบเอเจนต์ไปจนถึงข้อมูลประจำตัวของเอเจนต์มาตรฐาน และมาถึงเพียงไม่กี่สัปดาห์หลังจากการยกเครื่องข้อกำหนดหลักสำคัญในปี 2026-07-28 ของโปรโตคอล
การอัปเดตนี้ดึงดูดความสนใจจากชุมชนนักพัฒนาซอฟต์แวร์ทันที โดยมีการประกาศแผนงานซึ่งรวบรวมผู้โหวตเห็นด้วยมากกว่า 240 คน และความคิดเห็นมากกว่า 140 รายการเกี่ยวกับ Hacker News ภายในไม่กี่วัน สำหรับนักพัฒนาที่สร้างแอปพลิเคชันเอเจนต์ เอกสารจะส่งสัญญาณว่าผู้ดูแลหลักของโปรโตคอลและคณะทำงานจะใช้เวลาตรวจสอบที่ใด และข้อเสนอใดจะเคลื่อนผ่านคิวเร็วที่สุด For more context on this story, see our ongoing AI industry coverage.
สิ่งที่สเปคเดือนกรกฎาคมเปลี่ยนแปลงไปแล้ว
ก่อนที่จะกำหนดลำดับความสำคัญใหม่ ผู้ดูแลได้รวบรวมแผนงานก่อนหน้านี้ซึ่งเผยแพร่ในเดือนมีนาคม พ.ศ. 2569 ซึ่งมุ่งเน้นไปที่สี่ด้าน ได้แก่ วิวัฒนาการและความสามารถในการปรับขนาดของการขนส่ง การสื่อสารของตัวแทน การเจริญเติบโตของการกำกับดูแล และความพร้อมขององค์กร ตามโพสต์ในบล็อก "ความคืบหน้าที่สำคัญ" ถูกสร้างขึ้นในทั้งสี่แนวรบ โดยการเปลี่ยนแปลงจำนวนมากจะเข้าสู่การเปิดเผยข้อมูลจำเพาะประจำปี 2026-07-28
การเปลี่ยนแปลงที่เป็นผลสืบเนื่องมากที่สุดคือการลบเซสชันระดับโปรโตคอลและการจับมือเริ่มต้น ซึ่งมีการติดตามใน SEP-2575 และ SEP-2567 การเปลี่ยนแปลงนี้หมายความว่าเซิร์ฟเวอร์ MCP สามารถปรับขนาดในแนวนอนโดยไม่ต้องมีสถานะคงอยู่ ซึ่งเป็นการปรับปรุงพื้นฐานที่ทำให้เซิร์ฟเวอร์ MCP ระยะไกลทำงานเหมือนกับบริการบนเว็บทั่วไป ลูกค้ายังสามารถเรียกใช้ตำแหน่งข้อมูล `server/discover` ใหม่เพื่อเรียนรู้เวอร์ชันและความสามารถที่รองรับของเซิร์ฟเวอร์ก่อนที่จะดำเนินการใดๆ และผลลัพธ์ของรายการจะกลายเป็นแคชได้ภายใต้ SEP-2549
ในด้านการสื่อสารของตัวแทน โครงสร้าง Tasks ได้รับการแก้ไขใหม่เป็นส่วนขยายอย่างเป็นทางการ (SEP-2663) ในขณะที่รูปแบบคำขอ Multi Round-Trip ใหม่ (SEP-2322) แทนที่คำขอที่เริ่มต้นโดยเซิร์ฟเวอร์ เพื่อให้การไหลเหมือนกับการดึงข้อมูลออกมาทำงานบนเซิร์ฟเวอร์ไร้สัญชาติ การกำกับดูแลมีความสมบูรณ์เช่นกัน: โครงการได้นำ Contributor Ladder มาใช้อย่างเป็นทางการ ขณะนี้คณะทำงานคัดแยกข้อเสนอการปรับปรุงของตนเอง และข้อกำหนดได้รับวงจรการใช้งานฟีเจอร์และนโยบายการเลิกใช้งานที่เหมาะสม
งานเตรียมความพร้อมระดับองค์กรมุ่งเน้นไปที่การอนุญาต การตรวจสอบผู้ออกการจัดส่ง ข้อมูลรับรองลูกค้าที่ผูกมัดกับผู้ออก และเอกสารข้อมูลเมตารหัสลูกค้าเป็นเส้นทางการลงทะเบียนลูกค้าที่ต้องการ โดยที่การอนุญาตที่จัดการโดยองค์กรได้รับการเลื่อนระดับให้เป็นส่วนขยายที่มีความเสถียร
ลำดับความสำคัญห้าประการสำหรับรอบการเปิดตัวครั้งถัดไป
1. การส่งข้อความแบบดั้งเดิมแบบตัวแทน
สิ่งสำคัญอันดับแรกยอมรับว่า "ปริมาณงานเอเจนต์สมัยใหม่ไม่สอดคล้องกับรูปแบบคำขอและการตอบสนองมาตรฐานอีกต่อไป" ลูปทำงานนานขึ้น เซิร์ฟเวอร์ส่งผลลัพธ์แบบสตรีม และนักพัฒนาต้องการความสามารถในการควบคุมงานกลางอากาศ MCP เติบโตตามข้อกำหนดเหล่านี้ด้วยงาน การสมัครรับข้อมูลและการดำเนินการฟัง และการแจ้งเตือนความคืบหน้า แต่ผู้ดูแลต้องการให้ทำงานร่วมกันได้ดี
งานที่วางแผนไว้ประกอบด้วยเหตุการณ์ที่เริ่มต้นโดยเซิร์ฟเวอร์ซึ่งส่งผ่าน webhooks และช่องทาง "เพื่อให้ลูกค้าไม่ต้องโพลเพื่อหาผลลัพธ์" การตรวจสอบองค์ประกอบที่ครอบคลุมคณะทำงานของ Agent, Transports และ Triggers & Events และการทำให้ส่วนขยาย Tasks ครบกำหนดเพื่อให้สามารถย้ายไปยังข้อกำหนดหลักได้
2. การรวมการขนส่งแบบ HTTP-Native
ในการเปิดตัวเดือนกรกฎาคม ผู้ดูแลเขียนว่า "เซิร์ฟเวอร์ MCP ระยะไกลตอนนี้ไม่แตกต่างจากปริมาณงาน HTTP อื่นๆ" ทำให้เซิร์ฟเวอร์ MCP ง่ายต่อการโฮสต์บนองค์กรโครงสร้างพื้นฐานที่ใช้กับ API อยู่แล้ว แนวทางนี้ "ได้รับการพิสูจน์แล้วว่าสามารถปรับขนาดได้" และแผนงานในขณะนี้เสนอให้ขยายให้ครอบคลุมเซิร์ฟเวอร์ในเครื่องที่พูด HTTP แบบสตรีมได้ผ่านอินพุตและเอาต์พุตมาตรฐาน โพสต์ระบุว่าการรวมเป็นหนึ่งเดียวในการขนส่งจะทำให้ทั้งเซิร์ฟเวอร์ MCP และการพัฒนาไคลเอนต์ง่ายขึ้น
3. ข้อมูลระบุตัวตนของตัวแทนและการรักษาความปลอดภัยที่พร้อมสำหรับองค์กร
บางทีลำดับความสำคัญที่เป็นการคาดการณ์ล่วงหน้ามากที่สุดอาจช่วยแก้ไขช่องว่างระหว่างวิธีการทำงานของการอนุญาต MCP ในปัจจุบันและวิธีดำเนินการจริงของตัวแทน การอนุญาตในปัจจุบันสร้างขึ้นจากบุคคลที่อนุมัติการเข้าถึงในเบราว์เซอร์ — เหมาะสำหรับไคลเอนต์แบบโต้ตอบ แต่กลับไม่เป็นไปตามความเป็นจริงมากขึ้นเรื่อยๆ
“ผู้โทรจำนวนมากขึ้นเรื่อยๆ เป็นตัวแทนที่ทำงานเป็นปริมาณงานบนคลาวด์ที่มีตัวตนของตนเอง ดำเนินการในนามของผู้ใช้ที่ไม่อยู่ หรือมอบหมายอำนาจที่แคบลงให้กับตัวแทนย่อย” ผู้ดูแลเขียน เป้าหมายคือวิธีที่เป็นมาตรฐานสำหรับเซิร์ฟเวอร์ MCP ในการรับรู้และเชื่อถือข้อมูลระบุตัวตนของเอเจนต์เหล่านั้น "สร้างขึ้นจากมาตรฐานที่มีอยู่แทนที่จะวางคีย์ API และโทเค็นที่มีอายุการใช้งานยาวนาน"
โดยสรุปแล้ว งานนี้ครอบคลุมถึงการสรุปผล Demonstrating Proof of Possession (DPoP) และการผลักดันให้เกิดการยอมรับ การกำหนดเส้นทางที่มีความคิดเห็นสำหรับตัวตนของตัวแทนและการมอบหมายผ่าน Workload Identity Federation การให้สิทธิ์ ID-JAG ที่อยู่เบื้องหลัง Enterprise-Managed Authorization และการแลกเปลี่ยนโทเค็นมาตรฐาน ทีมงานจะยังคงมีส่วนร่วมกับคณะทำงาน IETF OAuth และ WIMSE ต่อไป เพื่อช่วยพัฒนามาตรฐานพื้นฐาน
4. ปรับปรุงการค้นพบเครื่องมือดั้งเดิมและก้าวหน้า
การเรียกเครื่องมือยังคงเป็นส่วนหนึ่งของ MCP ที่นักพัฒนาส่วนใหญ่สัมผัสเป็นอันดับแรก และตามโพสต์ดังกล่าวก็ "ทำได้ดี" แต่การจัดการผลลัพธ์มีน้อย: การตอบสนองแบบ "เครื่องมือ/การเรียก" สามารถส่งเอาต์พุตเดียวกันในรูปแบบมากกว่าหนึ่งรูปแบบ และนักพัฒนาเซิร์ฟเวอร์ไม่มีทางรู้ได้เลยว่าไคลเอ็นต์ที่กำหนดจะใส่รูปแบบใดไว้ข้างหน้าโมเดล แผนงานนี้มีจุดมุ่งหมายเพื่อสร้างมาตรฐานให้กับสัญญาที่ชัดเจนเพียงฉบับเดียว
ผู้ดูแลยังตั้งข้อสังเกตถึงปัญหาเรื่องขนาดอีกด้วย "การเชื่อมต่อกับเซิร์ฟเวอร์ด้วยเครื่องมือนับร้อยหมายความว่าโมเดลจะจ่ายเงินสำหรับพื้นผิวทั้งหมดก่อนที่ผู้ใช้จะถามคำถามเดียว และการเลือกเครื่องมือมีแนวโน้มที่จะแย่ลงเมื่อรายการเติบโตขึ้น" พวกเขาเขียน คำตอบคือความพยายามในการค้นหาที่ก้าวหน้า โดยปล่อยให้เซิร์ฟเวอร์เสนอจุดเริ่มต้นเล็กๆ และเปิดเผยแค็ตตาล็อกเพิ่มเติมเมื่อการสนทนาแคบลง
5. ปรับปรุงประสบการณ์นักพัฒนา SDK
สุดท้ายนี้ ผู้ดูแลให้คำมั่นว่าจะลงทุนใน SDK ซึ่งนักพัฒนาส่วนใหญ่ได้สัมผัสกับ MCP ไม่ว่าจะเป็นการยศาสตร์ ความสอดคล้องกับข้อกำหนด และเอกสารประกอบในทุกแพลตฟอร์มและภาษาที่รองรับ พวกเขาตั้งข้อสังเกตว่าขณะนี้นักพัฒนาจำนวนมากสร้างไคลเอนต์ MCP และเซิร์ฟเวอร์ "โดยการชี้ตัวแทนไปที่ไลบรารีของเรา" ซึ่ง API ที่ชัดเจนและเอกสารประกอบที่ถูกต้องจะตัดสินว่าโค้ดที่สร้างขึ้นนั้นทำงานโดยมีแรงเสียดทานน้อยที่สุดหรือไม่ พวกเขาตั้งข้อสังเกตว่าเดิมพันได้เพิ่มขึ้นแล้ว
มันหมายถึงอะไรสำหรับระบบนิเวศ
แผนงานประกอบด้วยโครงสร้างสิ่งจูงใจที่ใช้งานได้จริง: ข้อเสนอการปรับปรุงข้อมูลจำเพาะ (SEP) ที่อยู่ภายในพื้นที่สำคัญจะได้รับการตรวจสอบอย่างเร่งด่วนและโอกาสที่ดีที่สุดในการยอมรับ ในขณะที่ข้อเสนอที่อยู่นอกขอบเขตจะไม่ถูกปฏิเสธโดยอัตโนมัติ แต่จะได้รับเวลาบำรุงรักษาที่จำกัดเป็นครั้งสุดท้าย พื้นที่สำคัญแต่ละพื้นที่ได้ตั้งชื่อผู้ดูแลหลักและกลุ่มทำงานหนึ่งกลุ่มขึ้นไป ซึ่งทั้งหมดมีพื้นที่ว่างสำหรับผู้ร่วมให้ข้อมูลมากขึ้น และกลไกการขยายการทดลองภายใต้ SEP-2133 ช่วยให้กลุ่มต่างๆ ทดสอบแนวคิดก่อนข้อเสนออย่างเป็นทางการได้
นับตั้งแต่ Anthropic เปิดตัวและ MCP แบบโอเพ่นซอร์สในช่วงปลายปี 2024 โปรโตคอลดังกล่าวได้แพร่กระจายไปทั่วทั้งอุตสาหกรรม โดยผู้จำหน่าย AI รายใหญ่และผู้สร้างเครื่องมือได้นำโปรโตคอลนี้มาใช้เป็นวิธีทั่วไปในการให้โมเดลเข้าถึงระบบภายนอกได้ โรดแมปเดือนสิงหาคมแนะนำว่าระยะต่อไปของโปรโตคอลจะถูกกำหนดให้น้อยลงโดยการเชื่อมต่อพื้นฐาน และมากขึ้นจากปัญหาที่ยากขึ้นในยุคตัวแทน: การระบุใครหรืออะไรที่กำลังโทรมาจริง ๆ ทำให้งานที่ต้องดำเนินการมายาวนานสามารถควบคุมได้ และทำให้เครื่องมือที่เจ้าหน้าที่ต้องนำทางนั้นเชื่องช้า
สำหรับนักพัฒนาและทีมแพลตฟอร์มที่เดิมพัน MCP ข้อความนั้นชัดเจน: ขณะนี้การดำเนินการ HTTP ไร้สถานะถือเป็นพื้นฐาน และจุดศูนย์ถ่วงของโปรโตคอลกำลังเปลี่ยนไปสู่ตัวแทนที่ดำเนินการโดยอัตโนมัติ มีตัวตนที่ตรวจสอบได้ของตนเอง และค้นพบความสามารถแบบก้าวหน้ามากกว่าทั้งหมดในคราวเดียว
---
Stay Ahead of AIGet the latest AI news, analysis, and breakthroughs — all in one place.
Read more AI news →