นักพัฒนาตั้งคำถามต่อแนวทางเครื่องมือที่ซับซ้อนของ MCP เลือกใช้การรันโค้ดโดยตรงสำหรับ AI Agent

ทีมชุมชน BigGo
นักพัฒนาตั้งคำถามต่อแนวทางเครื่องมือที่ซับซ้อนของ MCP เลือกใช้การรันโค้ดโดยตรงสำหรับ AI Agent

โปรโตคอล Model Context Protocol ( MCP ) ที่ออกแบบมาเพื่อเชื่อมต่อโมเดล AI กับเครื่องมือและบริการภายนอก กำลังเผชิญกับการวิพากษ์วิจารณ์ที่เพิ่มมากขึ้นจากนักพัฒนาที่โต้แย้งว่าแนวทางเครื่องมือหลายตัวของมันสร้างปัญหามากกว่าการแก้ไข การอภิปรายทางเทคนิคล่าสุดได้เน้นย้ำถึงปัญหาพื้นฐานในปรัชญาการออกแบบของ MCP ทำให้เกิดการถกเถียงเกี่ยวกับว่าทางเลือกที่เรียบง่ายกว่าอาจมีประสิทธิภาพมากกว่าหรือไม่

MCP ได้รับการแนะนำโดย Anthropic เป็นวิธีการมาตรฐานในการที่โมเดล AI โต้ตอบกับระบบภายนอก แทนที่จะให้ AI agent เข้าถึงภาษาโปรแกรมหรือเครื่องมือ command-line โดยตรง MCP สร้างอินเทอร์เฟซที่มีโครงสร้างพร้อมฟังก์ชันเฉพาะที่กำหนดไว้ล่วงหน้า อย่างไรก็ตาม แนวทางนี้กำลังถูกตั้งคำถามโดยนักพัฒนาที่พบข้อจำกัดทางปฏิบัติที่สำคัญ

การลดลงของประสิทธิภาพกับเครื่องมือหลายตัว

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

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

ข้อจำกัดด้านประสิทธิภาพของ MCP :

  • ประสิทธิผลของเครื่องมือจะลดลงอย่างมีนัยสำคัญหลังจากใช้เครื่องมือประมาณ 30 ตัว
  • โมเดล AI มีปัญหาในการเลือกเครื่องมือเมื่อตัวเลือกเพิ่มขึ้น
  • ต้องใช้การเรียกเครื่องมือหลายครั้งสำหรับการดำเนินการที่ซับซ้อน เมื่อเทียบกับการเขียนโค้ดแบบครั้งเดียว

ความกังวลด้านความปลอดภัยและความท้าทายในการใช้งาน

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

โมเดลความปลอดภัยจะซับซ้อนยิ่งขึ้นเมื่อพิจารณาว่า AI agent สามารถถูก prompt-inject หรือถูกจัดการให้ทำการกระทำที่ไม่ได้ตั้งใจ กลไกการป้องกันในปัจจุบัน เช่น การตรวจสอบความปลอดภัยล่วงหน้าของ Claude โดยใช้โมเดล Haiku เพิ่มความล่าช้าโดยไม่ให้การรับประกันความปลอดภัยที่แข็งแกร่ง

การเปรียบเทียบด้านความปลอดภัย:

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

กรณีสำหรับการรันโค้ดโดยตรง

แนวทางทางเลือกที่กำลังได้รับความนิยมเกี่ยวข้องกับการให้ AI agent เข้าถึง interpreter ภาษาโปรแกรมแทนที่จะเป็นเครื่องมือเฉพาะหลายตัว วิธีการนี้ใช้ประโยชน์จากความจริงที่ว่าโมเดล AI ได้รับการฝึกฝนอย่างกว้างขวางในภาษาโปรแกรมและเข้าใจรูปแบบโค้ดได้ดีกว่าอินเทอร์เฟซเครื่องมือที่กำหนดเอง

command line ไม่ใช่แค่เครื่องมือหนึ่งตัวจริงๆ — มันคือชุดของเครื่องมือที่สามารถประกอบกันผ่านภาษาโปรแกรม: bash

นักพัฒนาที่ใช้แนวทางนี้รายงานข้อได้เปรียบหลายประการ AI agent สามารถรักษาสถานะได้อย่างมีประสิทธิภาพมากขึ้น ประกอบการดำเนินการที่ซับซ้อนโดยการรวมคำสั่งง่ายๆ และใช้ประโยชน์จากการฝึกฝนอย่างกว้างขวางในภาษาโปรแกรม แนวทางนี้ยังช่วยให้ debug และนำสคริปต์กลับมาใช้ได้ดีขึ้น เนื่องจากโค้ดที่สร้างขึ้นสามารถบันทึกและรันแยกต่างหากได้

แนวทางทางเลือก:

  • เซิร์ฟเวอร์ MCP แบบ "ubertool" เดียวที่มีตัวแปลภาษาโปรแกรม
  • การเข้าถึง bash/shell โดยตรงสำหรับการประกอบคำสั่ง
  • ระบบแบบผสมผสานที่รวมโครงสร้าง MCP เข้ากับความยืดหยุ่นของโค้ด

การพึ่งพาแพลตฟอร์มและปัญหาเอกสาร

การใช้งาน MCP มักจะประสบปัญหาจากข้อจำกัดเฉพาะแพลตฟอร์มและช่องว่างในเอกสาร เครื่องมือ command-line อาจทำงานแตกต่างกันในระบบปฏิบัติการต่างๆ มีการพึ่งพาเวอร์ชัน หรือขาดเอกสารที่ครอบคลุม ปัญหาเหล่านี้จะมีปัญหาเป็นพิเศษเมื่อ AI agent พบเครื่องมือที่ไม่ได้รวมอยู่ในข้อมูลการฝึกฝน

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

การตอบสนองของอุตสาหกรรมและทิศทางในอนาคต

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

การอภิปรายยังเน้นย้ำถึงความจำเป็นในการบูรณาการที่ดีขึ้นระหว่างเครื่องมือพัฒนา AI และโครงสร้างพื้นฐานซอฟต์แวร์ที่มีอยู่ แทนที่จะสร้างโปรโตคอลใหม่ บางคนโต้แย้งเพื่อการใช้ประโยชน์ที่ดีขึ้นจากมาตรฐานที่มีอยู่เช่น language server และ API ที่มีอยู่

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

อ้างอิง: Your MCP Doesn't Need 30 Tools: It Needs Code