MCP: ไม่ใช่ยาวิเศษ แต่ก็ดีใช้ได้

ในภูมิทัศน์ AI ปัจจุบัน แนวคิดหนึ่งกำลังสร้างกระแสอย่างมาก: MCP หรือ Model Context Protocol ที่น่าแปลกใจคือความสนใจรอบ ๆ ระบบโปรโตคอลนี้บดบังแม้กระทั่งการเปิดตัวโมเดลล่าสุดจาก OpenAI กลายเป็นจุดสนใจของการอภิปรายในอุตสาหกรรม

ความนิยมที่เพิ่มขึ้นของเทคโนโลยี Agent ซึ่งกระตุ้นโดยการเพิ่มขึ้นของ Manus ได้กระตุ้นความกระตือรือร้นของนักพัฒนาทั่วโลก MCP ซึ่งถูกวางตำแหน่งเป็น “โปรโตคอลแบบรวม” สำหรับการเรียกใช้เครื่องมือ Agent ได้รับแรงฉุดอย่างรวดเร็ว โดยได้รับการสนับสนุนจากผู้เล่น AI รายใหญ่เช่น OpenAI และ Google ภายในเวลาเพียงสองเดือน การขึ้นสู่ตำแหน่งอย่างรวดเร็วนี้ได้เปลี่ยน MCP จากข้อกำหนดทางเทคนิคที่ไม่ค่อยมีคนรู้จักให้กลายเป็นมาตรฐานพื้นฐานในระบบนิเวศ AI ถือเป็น “เหตุการณ์พิเศษ” ในขอบเขตของโครงสร้างพื้นฐาน AI

อย่างไรก็ตามเมื่อความตื่นเต้นเริ่มต้นลดลงคำถามที่สำคัญก็เกิดขึ้น: MCP สามารถนำไปใช้ได้อย่างแท้จริงหรือไม่? ความคาดหวังสำหรับความสามารถของมันสูงเกินจริงหรือไม่?

การสำรวจนี้เจาะลึกลงไปในต้นกำเนิดของ MCP โดยแยกแยะจุดแข็งและข้อจำกัดหลัก ๆ ชี้แจงความเข้าใจผิดที่แพร่หลายและตรวจสอบวิถีที่เป็นไปได้ในอนาคต จุดมุ่งหมายไม่ใช่เพื่อปฏิเสธคุณค่าที่แท้จริงของ MCP แต่เพื่อส่งเสริมความเข้าใจที่ลงตัวมากขึ้นเกี่ยวกับบทบาทและขอบเขตของมัน มันเป็นเพียงผ่านความชัดเจนดังกล่าวที่ศักยภาพของมันสามารถตระหนักได้อย่างเต็มที่

การเปิดเผย MCP: โปรโตคอลการเรียกใช้เครื่องมือแบบครบวงจร

การกำหนด MCP

MCP เป็นโปรโตคอลทางเทคนิคแบบเปิดที่ออกแบบมาเพื่อกำหนดวิธีการที่ Large Language Models (LLMs) โต้ตอบกับเครื่องมือและบริการภายนอก ลองนึกภาพว่าเป็นตัวแปลสากลในโลก AI ที่ช่วยให้โมเดล AI ‘สนทนา’ กับเครื่องมือภายนอกที่หลากหลาย มันมีภาษาและโครงสร้างทั่วไปสำหรับ LLMs เพื่อขอและใช้ประโยชน์จากฟังก์ชันที่นำเสนอโดยแอปพลิเคชันและบริการต่างๆ

ความต้องการ MCP

ก่อนการถือกำเนิดของ MCP การเรียกใช้เครื่องมือ AI ถูกรบกวนด้วยความท้าทายที่สำคัญสองประการ:

• ส่วนต่อประสานที่กระจัดกระจาย: LLM แต่ละตัวใช้รูปแบบคำสั่งที่แตกต่างกันในขณะที่แต่ละ API ของเครื่องมือมีโครงสร้างข้อมูลที่เป็นเอกลักษณ์ของตัวเอง นักพัฒนาถูกบังคับให้เขียนโค้ดการเชื่อมต่อแบบกำหนดเองสำหรับทุกชุดค่าผสมนำไปสู่กระบวนการพัฒนาที่ซับซ้อนและไม่มีประสิทธิภาพ
• ประสิทธิภาพการพัฒนา: แนวทาง ‘การแปลแบบหนึ่งต่อหนึ่ง’ นี้มีค่าใช้จ่ายสูงและยากต่อการปรับขนาด มันคล้ายกับการจ้างนักแปลโดยเฉพาะสำหรับลูกค้าต่างประเทศแต่ละรายขัดขวางผลผลิตและความคล่องตัว

MCP แก้ไขปัญหาเหล่านี้โดยการจัดเตรียมกรอบการทำงานที่เป็นมาตรฐานสำหรับ LLMs เพื่อโต้ตอบกับเครื่องมือภายนอกซึ่งทำให้กระบวนการพัฒนาง่ายขึ้นและทำให้สามารถปรับขนาดได้มากขึ้น

ทำความเข้าใจฟังก์ชันการทำงานของ MCP

สถาปัตยกรรมทางเทคนิคของ MCP สามารถสรุปได้ว่าเป็นระบบที่ประกอบด้วยองค์ประกอบหลักสามองค์ประกอบ: MCP Host, MCP Client และ MCP Server องค์ประกอบเหล่านี้ทำงานร่วมกันเพื่ออำนวยความสะดวกในการสื่อสารที่ราบรื่นระหว่างโมเดล AI และโลกภายนอก

เพื่อให้เข้าใจบทบาทของ MCP พิจารณาสภาพแวดล้อมขององค์กรสมัยใหม่ ในการเปรียบเทียบนี้:

• ผู้ใช้ เป็นตัวแทนของผู้บริหารระดับสูงซึ่งรับผิดชอบในการทำความเข้าใจความต้องการของผู้ใช้และทำการตัดสินใจขั้นสุดท้าย
• Large Language Models (LLMs) (เช่น Claude หรือ GPT) เข้าใจคำแนะนำของผู้บริหารวางแผนขั้นตอนของงานกำหนดเวลาที่จะใช้บริการภายนอกและรวบรวมข้อมูลเพื่อให้คำตอบ
• Agent Systems ทำหน้าที่เป็นผู้ช่วยส่วนตัวหรือเลขานุการบริหารดำเนินงานตามคำแนะนำ
• MCP ทำหน้าที่เป็นแพลตฟอร์มการสื่อสารที่เป็นมาตรฐานหรือระบบการเข้าถึงบริการขององค์กรที่เลขานุการใช้ มันไม่ได้ทำการตัดสินใจ แต่ทำตามคำแนะนำสื่อสารกับผู้ให้บริการต่างๆในรูปแบบและโปรโตคอลที่เป็นเอกภาพ

ก่อน MCP การโต้ตอบ AI กับเครื่องมือภายนอกเป็นเหมือนยุคของมาตรฐานการสื่อสารที่วุ่นวาย ทุกครั้งที่เลขานุการ (Agent) ต้องการติดต่อแผนกหรือซัพพลายเออร์ภายนอกที่แตกต่างกันพวกเขาต้องใช้อุปกรณ์สื่อสารหรือซอฟต์แวร์ที่แตกต่างกัน สิ่งนี้ต้องใช้ความคุ้นเคยกับระบบที่หลากหลายส่งผลให้เกิดความไม่มีประสิทธิภาพ นักพัฒนาต้องเขียนโค้ดการเชื่อมต่อแยกต่างหากสำหรับแต่ละเครื่องมือนำไปสู่การเสียเวลาและ จำกัด การปรับขนาด

MCP ปรับปรุงกระบวนการนี้โดยการจัดหาแพลตฟอร์มการสื่อสารที่เป็นเอกภาพช่วยให้เลขานุการสามารถติดต่อแผนกหรือผู้ให้บริการใด ๆ โดยใช้ระบบและโปรโตคอลการสื่อสารเดียวกัน นักพัฒนาต้องการเพียงใช้ส่วนต่อประสาน MCP เพียงครั้งเดียวทำให้ระบบ AI สามารถโต้ตอบกับเครื่องมือทั้งหมดที่รองรับโปรโตคอลได้

MCP: กล่องเครื่องมือที่สร้างขึ้นบน Function Call

สิ่งสำคัญคือต้องเข้าใจว่า MCP ไม่ได้แทนที่ Function Call แบบดั้งเดิม มันเป็นองค์ประกอบเสริมที่ช่วยเพิ่มขีดความสามารถ

Function Call เป็นกลไกหลักที่ LLMs โต้ตอบกับเครื่องมือภายนอกหรือ API มันเป็นความสามารถพื้นฐานของ LLMs ที่ช่วยให้พวกเขาสามารถระบุได้ว่าเมื่อใดที่จำเป็นต้องมีเครื่องมือและเครื่องมือประเภทใดที่จำเป็น

MCP ทำหน้าที่เป็นระบบการจำแนกประเภทเครื่องมือโดยจัดเตรียมกรอบการทำงานที่มีโครงสร้างสำหรับการจัดระเบียบและเข้าถึงเครื่องมือต่างๆ ดังนั้น MCP ไม่ได้แทนที่ Function Call แต่ทำงานร่วมกับ Agents เพื่อทำงานที่ซับซ้อนให้สำเร็จ

กระบวนการเรียกใช้เครื่องมือที่สมบูรณ์เกี่ยวข้องกับการรวมกันของ ‘Function Call + Agent + MCP System’

โดยพื้นฐานแล้ว LLM แสดงความจำเป็นในการเรียกเครื่องมือเฉพาะผ่าน Function Call Agent ทำตามคำแนะนำเพื่อดำเนินการเรียกใช้เครื่องมือในขณะที่ MCP จัดเตรียมข้อกำหนดการเรียกใช้เครื่องมือที่เป็นมาตรฐาน

พิจารณาการเปรียบเทียบต่อไปนี้: เจ้านาย (ผู้ใช้) ต้องการกาแฟ ในสำนักงาน (MCP Host) ผู้จัดการสำนักงาน (LLM) สั่งให้เลขานุการ (Agent) ซื้ออเมริกาโน่ (Function Call) เลขานุการตรวจสอบรายชื่อซัพพลายเออร์และพบว่าซัพพลายเออร์กาแฟอเมริกาโน่ได้รวมเข้ากับ Meituan หรือระบบการจัดซื้อแบบครบวงจรของ บริษัท (ติดตั้ง MCP Server) จากนั้นเลขานุการจะค้นหาซัพพลายเออร์ในระบบการจัดซื้อ (MCP Client) และทำการสั่งซื้อ

ก่อนหน้านี้หากไม่มี MCP เมื่อ LLM ออก Function Call Agent จะแปลและเชื่อมต่อโดยตรงกับ API เพื่อเรียกใช้เครื่องมือ แต่ละ API ต้องการโหมดการเรียกใช้ที่แยกต่างหากและรายการเครื่องมือที่กำหนดไว้และโหมดการเรียกใช้สำหรับ Agent เพื่อตีความ ด้วย MCP API จำนวนมากสามารถสั่งซื้อได้โดยตรงผ่าน MCP Client ของซัพพลายเออร์ช่วยประหยัดเวลาและความพยายามของ Agent อย่างไรก็ตาม Function Call ของ LLM ยังคงไม่เปลี่ยนแปลงยังคงอยู่ในรูปแบบ {tool: ‘buy coffee’, ‘type’: ‘Americano’}

ด้วยการแยกแยะระหว่าง Function Call และ MCP ทำให้เห็นได้ชัดว่า MCP ไม่ได้กำหนดว่าจะใช้เครื่องมือใดและไม่ได้จัดการกับการวางแผนงานหรือความตั้งใจของผู้ใช้ ลักษณะเหล่านี้อยู่ภายใต้ขอบเขตของเลเยอร์ Agent MCP เพียงจัดเตรียมส่วนต่อประสานเครื่องมือที่เป็นเอกภาพกลายเป็นโปรโตคอลมาตรฐานที่เป็นที่รู้จักในอุตสาหกรรม

ความท้าทายในการพัฒนาของ MCP และภูมิทัศน์ของตลาด

ปริศนาการพัฒนา

ตั้งแต่เดือนกุมภาพันธ์ชุมชนพัฒนา AI ได้เห็น ‘MCP gold rush’ ในกรณีที่ไม่มี App Store อย่างเป็นทางการเครื่องมือนับพันได้รวมเข้ากับโปรโตคอล MCP โดยสมัครใจภายในสามเดือน

การเติบโตอย่างรวดเร็วนี้ได้ผลักดัน MCP เข้าสู่สปอตไลท์ของอุตสาหกรรม แต่ยังเผยให้เห็นช่องว่างระหว่างความทะเยอทะยานกับความเป็นจริง นักพัฒนาในขั้นต้นมองว่า MCP เป็น ‘กุญแจสากล’ แต่พบว่าเป็น ‘ประแจพิเศษ’ มากกว่าซึ่งเก่งในบางสถานการณ์ แต่พิสูจน์ได้ว่ามีประสิทธิภาพน้อยกว่าในสถานการณ์อื่น ๆ

ผู้เข้าร่วมของ MCP สามารถแบ่งออกเป็นแอปพลิเคชันไคลเอนต์ในเครื่องแอปพลิเคชันไคลเอนต์บนคลาวด์และนักพัฒนา MCP server แอปพลิเคชันในเครื่องคล้ายกับผู้ช่วย AI ในเครื่องในขณะที่แอปพลิเคชันไคลเอนต์บนคลาวด์คล้ายกับ ChatGPT เวอร์ชันบนเว็บ นักพัฒนา MCP server เป็นผู้ให้บริการเครื่องมือจริงที่ต้องบรรจุ API ใหม่เพื่อให้สอดคล้องกับกฎ MCP

การเกิดขึ้นของ MCP ได้รับการต้อนรับในตอนแรกโดยแอปพลิเคชันไคลเอนต์ในเครื่อง แต่แอปพลิเคชันไคลเอนต์บนคลาวด์และนักพัฒนา MCP server เผชิญกับความท้าทาย

MCP มีต้นกำเนิดมาจากแอปพลิเคชัน Claude Desktop ของ Anthropic ซึ่งเดิมออกแบบมาเป็นโปรโตคอลอินเทอร์เฟซสำหรับการเรียกใช้ไฟล์และฟังก์ชันในเครื่องซึ่งหยั่งรากลึกในความต้องการฝั่งไคลเอนต์

สำหรับผู้ใช้ไคลเอนต์ในเครื่อง MCP เป็นตัวแทนของการปฏิวัติโดยนำเสนอกล่องเครื่องมือที่ขยายได้อย่างไม่มีที่สิ้นสุดซึ่งช่วยให้ผู้ใช้สามารถขยายขีดความสามารถของผู้ช่วย AI ได้อย่างต่อเนื่อง

แอปพลิเคชันไคลเอนต์ในเครื่องเช่น Cursor และ Claude Desktop ได้ใช้ประโยชน์จาก MCP เพื่อให้ผู้ใช้สามารถเพิ่มเครื่องมือแบบไดนามิกตามความต้องการของแต่ละบุคคลเพื่อให้บรรลุการขยายขีดความสามารถของผู้ช่วย AI ได้อย่างไม่ จำกัด

MCP แก้ไขปัญหาหลักในการพัฒนาไคลเอนต์ในเครื่อง: วิธีการเปิดใช้งานแอปพลิเคชัน AI เพื่อโต้ตอบกับสภาพแวดล้อมในเครื่องและเครื่องมือภายนอกได้อย่างราบรื่นโดยไม่ต้องพัฒนาอินเทอร์เฟซแยกต่างหากสำหรับแต่ละเครื่องมือ โปรโตคอลที่เป็นเอกภาพนี้ช่วยลดต้นทุนการรวมระบบได้อย่างมากทำให้นักพัฒนาเริ่มต้นขนาดเล็กและบุคคลทั่วไปสามารถสร้างแอปพลิเคชัน AI ที่มีคุณสมบัติหลากหลายพร้อมทรัพยากรที่ จำกัด

อย่างไรก็ตามความน่าสนใจของ MCP ลดลงเมื่อพิจารณาถึงการพัฒนาฝั่งเซิร์ฟเวอร์ (MCP Server) และไคลเอนต์บนคลาวด์ MCP เวอร์ชันแรกใช้กลไก dual-link สำหรับเซิร์ฟเวอร์บนคลาวด์ (ระยะไกล) โดยใช้การเชื่อมต่อแบบยาว SSE สำหรับการผลักดันข้อความทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์และการเชื่อมต่อแบบสั้น HTTP สำหรับการส่งข้อความ

แนวทางนี้ใช้ได้ดีสำหรับการตอบสนองและการแทรกแซงของผู้ใช้ที่ทันท่วงที แต่สร้างความท้าทายทางวิศวกรรมมากมายในสภาพแวดล้อมฝั่งเซิร์ฟเวอร์

ประการแรกการใช้ส่วนต่อประสาน MCP แสดงถึงภาระงานเพิ่มเติมสำหรับผู้ให้บริการระดับองค์กรขนาดใหญ่โดยไม่จำเป็นต้องให้ผลประโยชน์ที่สอดคล้องกัน บริการเหล่านี้มักจะมีระบบ API ที่เป็นผู้ใหญ่และการจัดเตรียมเลเยอร์การปรับตัว MCP เพิ่มเติมอาจเพิ่มต้นทุนการบำรุงรักษาโดยไม่สร้างมูลค่าที่สำคัญ แอปพลิเคชันระดับองค์กรมักชอบกลไกการเรียกใช้เครื่องมือแบบปิดที่ควบคุมได้มากกว่าระบบนิเวศแบบเปิดของ MCP

นอกจากนี้ในการจัดการการเรียกใช้ที่มีความพร้อมใช้งานสูงบริการ MCP มักจะต้องปรับขนาดเป็นสถาปัตยกรรมแบบหลายเซิร์ฟเวอร์ รูปแบบการเชื่อมต่อคู่ของ MCP แนะนำความซับซ้อนของการระบุข้ามเครื่อง เมื่อมีการสร้างการเชื่อมต่อที่ยาวนานบนเซิร์ฟเวอร์เครื่องหนึ่งและคำขอถูกส่งไปยังเซิร์ฟเวอร์อื่นจำเป็นต้องมีกลไกคิวออกอากาศเพิ่มเติมเพื่อประสานการเชื่อมต่อแบบกระจายเหล่านี้ซึ่งจะเพิ่มความยากลำบากในการใช้งานและต้นทุนการบำรุงรักษาอย่างมาก

ประการที่สอง MCP มีข้อ จำกัด ในขอบเขตของแอปพลิเคชันบนคลาวด์ Cloud AI Agents (Agents ฝั่งเซิร์ฟเวอร์) โดยทั่วไปจะทำงานในบริการที่ไม่มีสถานะประมวลผลงานหลังจากยอมรับและปล่อยทรัพยากรเมื่อเสร็จสิ้น การใช้ MCP Client ทางฝั่งเซิร์ฟเวอร์ต้องสร้างลิงก์ SSE ชั่วคราวส่งคำขอเรียกใช้เครื่องมือรับผลลัพธ์จาก SSE แล้วปิดลิงก์ SSE ซึ่งเป็นแนวทางที่ไม่มีประสิทธิภาพซึ่งจะเพิ่มความซับซ้อนและลดประสิทธิภาพ คำขอ RPC เดียวก็เพียงพอในสถานการณ์นี้

ในทางปฏิบัติแอปพลิเคชันบนคลาวด์ที่ใช้ MCP มักจะอาศัยชุดเครื่องมือที่ตั้งไว้ล่วงหน้าและไม่ได้ใช้ความสามารถด้านลายเซ็นของ MCP ในการค้นหาเครื่องมือแบบไดนามิกและการโหลดที่ยืดหยุ่น

โหมดการโต้ตอบข้อมูลของสภาพแวดล้อมบนคลาวด์ จำกัด ความสามารถในการใช้เครื่องมือได้อย่างอิสระตามที่ MCP ตั้งใจไว้ มันต้องการกระบวนการที่เป็นมาตรฐานสูงสำหรับการเรียกใช้เครื่องมือที่เข้ารหัสอย่างหนักโดยเฉพาะอย่างยิ่งซึ่งจะเสียสละความยืดหยุ่น

ทีม MCP ได้แสดงให้เห็นถึงการตอบสนองต่อความคิดเห็นของผู้ใช้ หลังจากได้รับความคิดเห็นจากนักพัฒนาฝั่งเซิร์ฟเวอร์ MCP ได้อัปเดตโปรโตคอลในวันที่ 26 มีนาคมโดยแทนที่การขนส่ง SSE เดิมด้วยการขนส่ง HTTP ที่สตรีมได้ โปรโตคอลใหม่รองรับทั้งสถานการณ์บริการที่ไม่มีสถานะที่ต้องการเพียงคำขอเรียกใช้เครื่องมือเดียวและความต้องการผลักดันตามเวลาจริงที่เคยพบก่อนหน้านี้ผ่านลิงก์คู่ HTTP + SSE

การปรับปรุงเหล่านี้ชี้ให้เห็นว่าปัญหา MCP ปัจจุบันเกิดจากข้อ จำกัด ในการออกแบบเริ่มต้น แต่ไม่สามารถเอาชนะได้

ความผิดปกติของตลาด

ความท้าทายอีกประการหนึ่งที่ MCP เผชิญคือความสามารถในการใช้งานต่ำของการใช้งานจำนวนมากในตลาด

ตลาด MCP ปัจจุบันกำลังประสบกับวงจรการโฆษณาเทคโนโลยีทั่วไป คล้ายกับความวุ่นวายของ App Store ในยุคแรกเครื่องมือ MCP น้อยกว่า 20% จากเครื่องมือนับพันที่มีอยู่ในปัจจุบันมีคุณค่าในทางปฏิบัติ การใช้งานจำนวนมากมีปัญหาที่ร้ายแรงตั้งแต่ข้อผิดพลาดในการกำหนดค่าอย่างง่ายไปจนถึงความไม่สามารถใช้งานได้อย่างสมบูรณ์ บางส่วนเร่งรีบออกสู่ตลาดโดยไม่มีการทดสอบที่เพียงพอในขณะที่บางส่วนเป็นผลิตภัณฑ์ทดลองที่ไม่เคยมีจุดประสงค์เพื่อการใช้งานจริง

ปัญหาพื้นฐานมากกว่าคือการใช้งาน MCP จำนวนมากอาจไม่จำเป็นสำหรับตลาด เครื่องมือจำนวนมากที่นำเสนอผ่าน MCP เป็นเพียง API ที่บรรจุใหม่ซึ่งมีอยู่และใช้งานแล้วก่อนการเกิดขึ้นของ MCP ซึ่งเพิ่มมูลค่าที่ไม่เหมือนใครเพียงเล็กน้อย

ตัวอย่างเช่นบริการค้นหาหลายสิบรายการมีให้ผ่าน MCP แต่คุณภาพของมันแตกต่างกันอย่างมาก บริการบางอย่างอาจไม่ถูกต้องหรือช้าทำให้เป็นที่ต้องการน้อยกว่าโซลูชันที่มีอยู่

นอกจากนี้ MCP ขาดระบบประเมินผลที่แข็งแกร่งทำให้ Agent ไม่สามารถเลือกเครื่องมือที่เหมาะสมที่สุดตามเมตริกที่เชื่อถือได้ กระบวนการคัดเลือกที่ไม่มีประสิทธิภาพนี้สิ้นเปลืองทรัพยากรคอมพิวเตอร์ขยายเวลาการทำงานให้เสร็จสมบูรณ์และลดทอนประสบการณ์ผู้ใช้

การขาดระบบประเมินผลทำให้ Agent ไม่สามารถเลือกเครื่องมือที่เหมาะสมที่สุดได้ หากบริการ MCP หลายแห่งมีเครื่องมือที่มีชื่อและคำอธิบายที่คล้ายกัน Agent อาจต้องดิ้นรนเพื่อเลือกตัวเลือกที่ดีที่สุดนำไปสู่โทเค็นที่สูญเปล่าและลดประสิทธิภาพ

แอปพลิเคชัน AI ที่ประสบความสำเร็จมากที่สุดมักจะใช้วิธีการตรงกันข้ามโดยจัดหาเครื่องมือที่แม่นยำยิ่งขึ้นมากกว่าเครื่องมือจำนวนมาก ตัวอย่างเช่น Manus เลือกที่จะสร้างแอปพลิเคชันภายในแทนที่จะนำโปรโตคอล MCP มาใช้แม้ว่าจะมีอยู่ Manus ให้ความสำคัญกับความถูกต้องและความเสถียรในการโทรมากกว่าการรวมเข้ากับระบบนิเวศ MCP

โปรแกรมแก้ไขโค้ดเช่น Cursor มีฟังก์ชันการพัฒนาในตัวทำให้เครื่องมือ MCP ภายนอกส่วนใหญ่ซ้ำซ้อน

สถานะที่วุ่นวายในปัจจุบันของตลาด MCP ไม่จำเป็นต้องเป็นสัญญาณของความล้มเหลว แต่เป็นขั้นตอนที่จำเป็นในการเติบโตสำหรับระบบนิเวศเทคโนโลยีที่เกิดขึ้นใหม่ ประธานทางประวัติศาสตร์ชี้ให้เห็นว่าการขยายตัวมากเกินไปในขั้นต้นนี้จะค่อยๆบรรจบกันผ่านกลไกการคัดเลือกของตลาดทิ้งองค์ประกอบที่มีค่าที่สุดไว้เบื้องหลัง

กระบวนการนี้จะช่วยให้อุตสาหกรรมเรียนรู้จากความท้าทายในปัจจุบันและสร้างกรอบ MCP ที่แข็งแกร่งและน่าเชื่อถือมากขึ้น คล้ายกับวิธีที่ฟองสบู่อินเทอร์เน็ตนำไปสู่นวัตกรรมที่เปลี่ยนแปลงเกมในการพาณิชย์อิเล็กทรอนิกส์และโซเชียลมีเดียแนวโน้ม MCP อาจนำไปสู่ระบบนิเวศเครื่องมือที่มีความคล่องตัวและมีค่ามากขึ้น

ทัศนคติที่เปิดกว้างของทีม MCP ต่อความคิดเห็นของผู้ใช้เป็นกำลังใจและอุตสาหกรรมต้องการเครื่องมือที่ดีกว่าในการประเมินและรับรองคุณภาพของบริการ MCP ซึ่งจะช่วยทำให้ระบบนิเวศสามารถใช้งานได้มากขึ้น

MCP นั้นดีไม่ใช่ยาวิเศษ

ปัญหาที่กล่าวถึงข้างต้นมาจากข้อ จำกัด และข้อบกพร่องของ MCP โดยเน้นว่าสิ่งที่สามารถทำได้อย่างสมจริง อย่างไรก็ตามคำวิจารณ์อื่น ๆ มาจากความคาดหวังที่ไม่สมจริง

บทวิจารณ์ล่าสุดวิพากษ์วิจารณ์ว่า MCP เป็นโปรโตคอลที่บกพร่องเพราะไม่ได้กำหนดรูปแบบการโต้ตอบระหว่าง LLMs และ MCP

บางคนคาดหวังว่า MCP จะปรับปรุงการตัดสินใจของระบบ AI โดยอัตโนมัติหรือเพิ่มประสิทธิภาพการวางแผนงาน ความคาดหวังนี้สับสนเครื่องมือกับช่างฝีมือ

ปัญหาเกิดจากการไม่ตรงกันทางความคิด - คาดหวังว่าโปรโตคอลการสื่อสารจะทำงานของระบบอัจฉริยะ นี่เหมือนกับการตำหนิ USB ที่ไม่ได้แก้ไขรูปภาพหรือตำหนิมาตรฐาน 5G ที่ไม่ได้เขียนโค้ด MCP เป็น ‘ซ็อกเก็ตเครื่องมือ’ ที่เป็นมาตรฐานเป็นหลักเพื่อให้แน่ใจว่าความเข้ากันได้ของปลั๊กมากกว่าการกำหนดว่าจะใช้อุปกรณ์ใดหรืออย่างไร

ประสิทธิภาพของการเรียกใช้เครื่องมือ Agent ขึ้นอยู่กับปัจจัยต่างๆเช่นความสามารถในการเลือกเครื่องมือทักษะการวางแผนงานและความเข้าใจบริบทซึ่งไม่มีข้อใดตกอยู่ภายใต้ขอบเขตของ MCP MCP รับประกันเฉพาะส่วนต่อประสานเครื่องมือที่เป็นมาตรฐานไม่ใช่ว่าจะเลือกและรวมเครื่องมือเหล่านั้นอย่างไร

เรามักจะแสวงหากระสุนเงินในเทคโนโลยีโซลูชันที่ใช้ได้ทั่วสากล เช่นเดียวกับสัจพจน์ ‘ไม่มีกระสุนเงิน’ ของวิศวกรรมซอฟต์แวร์การใช้เครื่องมือ AI ไม่มีโซลูชันเวทย์มนตร์ ระบบ AI ที่แข็งแกร่งต้องการส่วนประกอบที่ออกแบบ: LLMs สำหรับการทำความเข้าใจและการสร้างกรอบการทำงาน Agent สำหรับการวางแผนและการดำเนินการและ MCP ที่เน้นส่วนต่อประสานเครื่องมือที่เป็นเอกภาพ

MCP แสดงการออกแบบโปรโตคอลที่ดี - เน้นที่ปัญหาเดียวและแก้ไขได้ดีแทนที่จะเป็นทั้งหมด การยับยั้งชั่งใจช่วยให้มีความคืบหน้าในการรวมเครื่องมือฝั่งไคลเอนต์

หน่วยงานเช่น Qwen ของอาลีบาบา ‘Xinxiang’ ของ Baidu และ Kouzi Space ของ ByteDance ยอมรับโปรโตคอล MCP พยายามที่จะสร้างระบบนิเวศ MCP ภายในที่มีประสิทธิภาพมากขึ้น

อย่างไรก็ตามมีความแตกต่างที่สำคัญในการปรับใช้: Baidu และ ByteDance มีความก้าวร้าวมากขึ้น Baidu พยายามใช้วิธี C-end โดยการรวมโมเดล AI หลายแบบและเครื่องมือภายนอกผ่าน ‘Xinxiang’ (Kokone) ที่ใช้ประโยชน์จากโปรโตคอล MCP เป็นหลักสำหรับอุปกรณ์มือถือเพื่อรวมเข้ากับชีวิตประจำวันของผู้ใช้และส่งเสริมการนำไปใช้

Kouzi Space ของ ByteDance มีปลั๊กอินส่วนขยาย MCP มากกว่า 60 รายการ เข้าถึงได้ผ่านหน้าเว็บ นอกจากนี้ยังเปิดตัว IDE ดั้งเดิมของ AI Trae ซึ่งรองรับ MCP โดยกำหนดเป้าหมายหลักไปที่สถานการณ์ด้านประสิทธิภาพการทำงาน

อาลีบาบาได้รวมโปรโตคอล MCP เข้ากับผลิตภัณฑ์เช่น Alipay ทำให้สามารถเรียกใช้เครื่องมือ AI ได้ด้วยคลิกเดียวและเปิดซอร์สโมเดล Qwen3 ซึ่งรองรับโปรโตคอล MCP ช่วยเพิ่มขีดความสามารถของ Agent

นักพัฒนา Tencent Cloud เปิดตัวชุดพัฒนา AI ที่รองรับบริการโฮสติ้งปลั๊กอิน MCP เอ็นจินความรู้โมเดลขนาดใหญ่ของ Tencent Cloud ช่วยให้ผู้ใช้สามารถเรียกใช้ปลั๊กอิน MCP ได้ Agent อัจฉริยะสำหรับการพัฒนาซอฟต์แวร์ Craft ที่เปิดตัวโดย CodeBuddy ของ Tencent Cloud เข้ากันได้กับระบบนิเวศแบบเปิด MCP นอกจากนี้ Tencent Maps และ Tencent Cloud Storage ได้เปิดตัว MCP SERVER ของตนเอง

การใช้เครื่องมือ AI อาจพัฒนาจากการทำงานโดยตรงของเครื่องมือเดียวไปสู่การทำงานร่วมกันของ Agent อย่างมืออาชีพเช่นเดียวกับที่รูปแบบการเขียนโปรแกรมพัฒนาจากภาษาแอสเซมบลีไปสู่การวางแนววัตถุ

ในกระบวนทัศน์นี้ MCP อาจกลายเป็นส่วนหนึ่งของโครงสร้างพื้นฐานพื้นฐานแทนที่จะเป็นอินเทอร์เฟซที่หันหน้าไปทางผู้ใช้หรือนักพัฒนา แผนที่สมบูรณ์ยิ่งขึ้นอาจต้องการสถาปัตยกรรมเช่น Agent to Agents (A2A) เพื่อเพิ่มประสิทธิภาพการวางแผนงานและการเลือกเครื่องมือโดยการเพิ่มระดับนามธรรม

โดยการส่งคืน MCP ไปยังบทบาท ‘โปรโตคอล’ เราสามารถรับรู้ถึงพลังที่แท้จริงในการขับเคลื่อนการสร้างมาตรฐานอุตสาหกรรม - นี่อาจเป็นช่วงเวลา ‘การลดทอนความลึกลับ’ ที่หวงแหนมากที่สุดในการวิวัฒนาการของเทคโนโลยี