MCP มองข้ามบทเรียนสำคัญจากระบบกระจายศูนย์ที่สั่งสมมาแล้ว 40 ปี

• MCP (Model Context Protocol) มุ่งเน้นการทำให้การรวมเครื่องมือ AI เป็นมาตรฐาน แต่มีจุดบกพร่องตรงที่มองข้าม best practice ของระบบกระจายศูนย์และ RPC ที่สั่งสมมากว่า 40 ปี
• ผลลัพธ์คือใน สภาพแวดล้อมองค์กร จะขาดความสามารถหลัก เช่น ความเชื่อถือได้ในการดำเนินงาน ความปลอดภัยทางชนิดข้อมูล (type safety) ความปลอดภัย การสังเกตการทำงาน (observability) และการจัดการต้นทุน
• MCP ไม่ได้รวมฟังก์ชันที่จำเป็นไว้ในตัวเอง แต่กลับ พึ่งพาไลบรารีภายนอก เท่านั้น และยังก่อให้เกิดความแตกแยกของโปรโตคอล ความซับซ้อนในการผสานระบบ ตลอดจนภาระงานด้านการตรวจสอบและความปลอดภัย
• distributed tracing, การจัดการเวอร์ชัน schema, service discovery และข้อกำหนดด้านการปฏิบัติการสำคัญอย่างการปรับประสิทธิภาพการทำงานยังคงยังขาดอยู่

---

ความเสี่ยงที่เกิดจากความเรียบง่ายของ MCP

MCP (Model Context Protocol) โดดเด่นในฐานะตัวกลางการรวม AI เครื่องมือตามแนวคิดว่าเป็น "USB-C ของโลก AI" โดยเน้นความเรียบง่ายเพื่อลดอุปสรรคในการนำไปใช้ แต่ความเรียบง่ายเช่นนี้กลับเพิกเฉยต่อ บทเรียนที่สั่งสมมากว่า 40 ปีจากระบบกระจายศูนย์ จนทำให้เกิดข้อบกพร่องด้านฟังก์ชันที่ร้ายแรงในสภาพแวดล้อมจริง

บริษัทที่กำลังนำ MCP มาใช้ในตอนนี้กำลังวางฐานระบบบนโครงสร้างที่ ขาดความสามารถ RPC ที่จำเป็นอย่างพื้นฐาน

ช่องว่างอันตรายระหว่างความคาดหวังกับความเป็นจริง

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

แม้เชื่อมต่อเครื่องมือ AI ได้เร็วในระยะสั้น แต่เมื่อใช้จริงในธุรกิจด้วยระดับคำขอระดับล้านครั้ง จะเผยให้เห็นความอ่อนแอร้ายแรง

ความคาดหวังเกินจริงของตลาดต่อ AI ทำให้การนำมาใช้งานถูกเร่งโดยขาดความเจริญสภาพทางสถาปัตยกรรม ส่งผลให้ความเสี่ยงการล้มเหลวในการดำเนินงานเพิ่มสูงขึ้นอย่างมาก

ข้อผิดพลาดที่เกิดซ้ำจากประวัติศาสตร์ 40 ปี

• UNIX RPC (ปี 1982) นำ XDR (External Data Representation) และ IDL (Interface Definition Language) มาใช้เพื่อให้ข้อมูลระหว่างระบบต่างชนิดเข้ากันได้ รวมถึงตัวเลข 32 บิต และตรวจจับข้อผิดพลาดความไม่สอดคล้องของชนิดข้อมูลในขั้นตอน build-time MCP กลับมองข้ามประสบการณ์นี้และให้เพียง JSON แบบไม่มี schema กับ hint ที่ไม่บังคับเท่านั้น ดังนั้นเกิดข้อผิดพลาดด้านชนิดข้อมูลใน runtime ได้ง่าย และ AI อาจสร้างวันที่ไม่ถูกต้อง ซึ่งนำไปสู่การแปลงข้อมูลผิดพลาดและปัญหาคุณภาพที่ร้ายแรงในงานจริง เช่น การเงิน การแพทย์ การผลิต

• CORBA (ปี 1991) ใช้ OMG IDL เพื่อรับประกันให้เกิด interface เดียวกันข้ามภาษา MCP ถูกนำไป implement แยกกันในแต่ละภาษา ทำให้การ serialization และการจัดการข้อผิดพลาดต่างกันระหว่างภาษา/ไลบรารีและก่อให้เกิด ความฝันร้ายของการผสานระบบ

• REST (ปี 2000) ได้รับความน่าเชื่อถือและขยายขนาดได้สูงด้วยโครงสร้าง stateless การทำความหมายแบบ verb และ headers สำหรับ cache MCP มีความกำกวมระหว่าง stateful/stateless และไม่รองรับการจำแนกความหมายคำขอแบบมาตรฐาน, cache, และ idempotency ทำให้การขยายเซิร์ฟเวอร์ การ retry และ load balancing ทำได้ลำบากมาก

• SOAP/WSDL มีข้อดีเรื่อง สัญญาที่อ่านได้โดยเครื่องได้อย่างแข็งแรง, การทำ automation, และความสามารถขยายด้านความปลอดภัย MCP ให้เฉพาะ schema ของ JSON ที่เรียบง่าย และขาดฟีเจอร์อย่าง machine-readable contract, การสร้างอัตโนมัติ, ความปลอดภัยด้านชนิดข้อมูล, และการตรวจสอบด้านความปลอดภัย เป็นต้น ในกรณีของ OAuth 2.1 ยิ่งถูกเพิ่มเข้ามาในภายหลังเฉพาะที่ HTTP transport และ stdio ก็ยังอาศัยตัวแปรแวดล้อม ทำให้การควบคุมด้านความปลอดภัยไม่ครบถ้วน

• gRPC (ปี 2016) มี distributed tracing, service-to-service observability, bidirectional streaming, deadline และรหัสข้อผิดพลาดแบบโครงสร้างในตัว MCP รองรับเฉพาะการส่งข้อมูลแบบ one-way event streaming เท่านั้น จึงไม่มีประสิทธิภาพสำหรับ interaction ที่ซับซ้อน และขาดองค์ประกอบสำคัญอย่าง trace context, deadline, การจำแนกข้อผิดพลาด

ความเสี่ยงของคำแนะนำแบบ 'ใช้แต่ไลบรารีนี้'

เมื่อมีการชี้จุดบกพร่องร้ายแรงใน MCP คำตอบมักเป็นการเพิ่มไลบรารี third-party แทน (เช่น mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator) แต่สิ่งเหล่านี้สะท้อน จุดล้มเหลวเชิงโครงสร้างของโปรโตคอล เอง

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

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

แพตช์ชั่วคราวที่ค่อยๆ ซ้อนกัน

เวอร์ชัน MCP เมื่อวันที่ 2025–03–26 ดูราวกับเป็น release note ของการเพิ่มแพตช์ให้กับข้อบกพร่องที่เพิ่งค้นพบใน production

OAuth, การจัดการเซสชัน, tool attributes (annotation), และการแจ้งสถานะความคืบหน้า ล้วนเป็นฟีเจอร์ที่ควรมีตั้งแต่เริ่มต้นแต่ถูกเพิ่มเข้ามาทีหลังเท่านั้น

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

ภัยพิบัติในการดีบักและความยากในการติดตามการดำเนินงาน

ในสภาพแวดล้อม gRPC สามารถดีบักได้รวดเร็วและสม่ำเสมอผ่าน distributed tracing และ trace ID แต่ MCP ขาด correlation ID ระหว่างคำขอ, format ของ log ไม่สอดคล้องกัน และมักต้องการการ implement แบบ custom เสมอ ทำให้ การดีบักและติดตามข้อผิดพลาดต้องใช้เวลาหลายวัน

ด้านการดำเนินงานและธุรกิจ MCP ยังไม่รองรับ การกระจายต้นทุนและการจัดการ usage (header, การนับ token, quota ฯลฯ) ทำให้แทบไม่สามารถติดตามต้นทุน AI และการรับผิดชอบได้

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

ปัญหาการดำเนินงานที่ยังคงหลงเหลือ

• การขาด service discovery ทำให้ความพร้อมใช้งาน การขยายหลายภูมิภาค และการ deploy แบบไม่หยุดทำงานเป็นไปได้ยาก
• การขาดการจัดการเวอร์ชัน schema ต่อเครื่องมือ ทำให้เมื่อมีการอัปเดตเครื่องมือ ลูกค้า (client) ทั้งหมดอาจล่มได้ทันทีโดยไม่มีการแจ้งเตือนล่วงหน้า
• ขีดจำกัดด้านประสิทธิภาพ: overhead ของ JSON, ขาด connection pooling, ขาดการสื่อสารแบบ binary protocol/การบีบอัด และการวนกลับไปใช้รูปแบบการสื่อสารแบบ process-level ซึ่งล้าสมัย

ความเสี่ยงร้ายแรงเมื่อใช้กับองค์กร

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

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

กลยุทธ์ "ทำเร็วแล้วพัง" ที่เหมาะกับระดับโปรโตไทป์ทดลอง กลับอาจก่อผลลัพธ์ร้ายแรงต่อบริการที่สำคัญ

แนวทางพัฒนาและข้อกำหนดระยะยาว

• ระยะสั้น: ต้องฝัง type safety, distributed tracing (trace correlation ID), การอนุญาตสิทธิ์, รูปแบบ audit มาตรฐาน และการจัดการเวอร์ชัน schema แยกรายเครื่องมือไว้ในระดับโปรโตคอลเอง
• ด้านการปฏิบัติการ: service discovery, connection pooling, binary transport, deadline, และนโยบาย error/retry มาตรฐานเป็นสิ่งที่ต้องการ
• ระยะยาว: รองรับ bidirectional streaming, การจัดการ quota และต้นทุนในตัว, SLA enforcement, workflow orchestration และความสามารถระดับองค์กรอื่นๆ

ข้อสรุป

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

การนำ MCP มาใช้ก่อนเวลาอันควรตามกระแส AI ทำให้การเพิ่มฟีเจอร์สำคัญเช่นความปลอดภัย, observability, ความเสถียรในการดำเนินงาน ในภายหลังแบบชั่วคราวเกิดขึ้นซ้ำแล้วซ้ำเล่า

ท้ายที่สุด ความเสี่ยงของ การแตกเป็นชิ้นๆ และการพัฒนาซ้ำซ้อน ซึ่งโปรโตคอลต้องการป้องกัน กลับอาจเกิดขึ้นบนแพลตฟอร์ม MCP เอง

อุตสาหกรรม AI กำลังยืนอยู่ที่ทางแยกว่าจะกลับไปเจอปัญหาที่เคยแก้แล้วในประวัติศาสตร์ 40 ปีของระบบกระจายศูนย์ หรือเรียนรู้จากประวัติศาสตร์และก้าวข้ามมัน

หากเป็นเช่นนี้ การนำไปใช้ที่ล้มเหลว, ช่องโหว่ความปลอดภัย, ฝันร้ายในการดำเนินงาน จะซ้ำรอยกัน และต้นทุนทั้งหมดจะตกอยู่ที่องค์กรเป็นผู้รับภาระทั้งหมด