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

 (julsimon.medium.com)
3 คะแนน โดย GN⁺ 2025-08-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • 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 ปีของระบบกระจายศูนย์ หรือเรียนรู้จากประวัติศาสตร์และก้าวข้ามมัน

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-10
ความคิดเห็นบน Hacker News

  • ตอนแรกผมเห็นแค่หัวข้อก็คิดว่าอาจเป็นเรื่องแค่อย่างเชื่อมโยงความปลอดภัยแบบเดิม แต่พออ่านแล้วกลับรู้สึกว่ามีมุมมองที่ยอดเยี่ยมจริง ๆ โดยเฉพาะตรงนี้: MCP กำลังมองข้ามบทเรียนแบบนี้ โดยใช้ hint แบบไม่บังคับกับ JSON ที่ไม่มี schema ทำให้เกิดการตรวจสอบชนิดข้อมูลใน runtime หรืออาจไม่ตรวจสอบเลย ตัวอย่างเช่น หาก AI tool คาดหวัง timestamp แบบ ISO-8601 แต่ได้รับค่า Unix epoch กลับมา โมเดลอาจไม่ล้มเหลวอย่างเหมาะสมและยังสร้างวันที่ใดก็ได้ได้ นี่คือสิ่งที่อาจเกิดในบริการการเงินเมื่อ AI ตีความตัวเลขผิดจนรันการซื้อขายด้วยความละเอียดทศนิยมที่ไม่ถูกต้อง ในด้านสุขภาพ การแปลงชนิดข้อมูลผู้ป่วยผิดพลาดอาจนำไปสู่การแนะนำปริมาณยาที่ไม่ถูกต้องได้ และในอุตสาหกรรมการผลิต การสูญเสียความแม่นยำของข้อมูลเซนเซอร์ระหว่างการ serialize JSON อาจนำไปสู่ปัญหาควบคุมคุณภาพได้ ผมทำงานกับ LLM ทุกวัน จึงเห็นปัญหานี้เกิดขึ้นได้ค่อนข้างบ่อย ในอนาคตอาจเกิดเหตุการณ์สำคัญขึ้นที่ระบบใดระบบหนึ่งที่ใช้ MCP และเมื่อดูรายงานเหตุการณ์จะเห็นว่า MCP server ส่งข้อมูลผิดไป แล้ว LLM รับข้อมูลนั้นแล้วสร้างผลลัพธ์ที่หลงผิดอย่างผิดทาง ทำให้ปัญหาขยายต่อเนื่องเป็นผลกระทบที่ใหญ่ขึ้นเรื่อย ๆ หากรวมความผิดพลาดของมนุษย์ ลักษณะของ LLM ที่ไม่มีการจัดการข้อยกเว้น (เกิด hallucination) และวัฒนธรรมของ startup ที่เร่งปล่อยบริการใหม่เข้าด้วยกัน มันแทบจะหลีกเลี่ยงไม่ให้เกิด bug ประเภทใหม่ได้ และเมื่อปัญหานี้ปะทุขึ้น คาดว่าผู้ใช้ Twitter จะอ้าปากคุยกันไม่รู้จบว่าระบบ AGI กำลังแฮ็กโค้ดการยิงขีปนาวุธนิวเคลียร์ ซึ่งคงเป็นฉากที่น่าสนใจไม่น้อย

    • ซื่อสัตย์แล้ว ก่อนปี 2023 ผมคิดว่า “บั๊กเทคนิค” ใน Star Trek เหล่านั้นฟังดูเวอร์ชันว่ายังไม่ถึงขั้นเกิดขึ้นจริง แต่หลังจากมี LLM แล้ว กลับรู้สึกว่ามันน่าจะเกิดขึ้นจริงได้แน่นอน ผมไม่แน่ใจแล้วว่า LLM integration ยังคงเกี่ยวข้องอะไรกับวิศวกรรมอยู่รึเปล่า และการที่องค์กรปล่อยการควบคุมโครงสร้างพื้นฐานทั้งหมดยกให้ภายนอกมันสมเหตุผลไหม ที่สำคัญ เมื่อพิจารณาปัญหาความไม่สามารถทำซ้ำได้ การพึ่ง “ทำ ๆ ไป” ไม่สามารถเรียกว่า engineering ได้

    • ผมไม่ค่อยเข้าใจข้อวิจารณ์ที่ผู้เขียนพูดถึงนัก แม้ว่า MCP รองรับ JSON Schema และ response จากเซิร์ฟเวอร์ต้องตรงกับ schema นั้นตามกฎ หาก schema ต้องการ ISO-8601 timestamp แต่ server กลับส่งค่า Unix epoch นี้ถือเป็นการละเมิดโปรโตคอลอย่างชัดเจน ส่วนบทความที่ว่า MCP รองรับ JSON Schema แต่สร้าง type-safe client ไม่ได้ ผมคิดว่าไม่ตรงกับความจริง เพราะมี JSON Schema code generator ที่มีอยู่อยู่แล้วจำนวนมาก

    • PEBKAC (user error) ก็มีอยู่แล้ว แต่ LLM คือการอัตโนมัติที่พาไปสู่ระดับนั้น

    • ข้อสังเกตเรื่องการคำนวณขนาดยาในสุขภาพผิดพลาดจากการแปลงชนิดข้อมูล ผมรู้สึกตรงนี้จริง ๆ เพราะงาน medical telemetry ที่ทำมาก่อน มันทำให้เห็นความสำคัญของ parsing timestamp ให้ถูกต้อง ผมว่าอาจเป็นเหตุผลหนึ่งที่ทำให้เริ่มเขียน unit test มา เพราะเมื่อไม่มี NTP เราต้องคำนวณ timestamp ใน header ซ้ำเพื่อชดเชย ความพยายามเหล่านี้เกิดจากเหตุผลเกี่ยวกับการ review อุบัติเหตุและความรับผิดชอบด้านความผิดพลาดทางการแพทย์ ตัวอย่างเช่น ความต่างของเวลาที่ให้ยากับผู้ป่วยก่อนเกิด cardiac arrest กับเวลาหลังจากนั้นเพียงช่วงสั้นอาจหมายถึงเรื่องชีวิตและความตาย และอย่างล่าสุดในกรณี UK Post Office ข้อผิดพลาดข้อมูลเพียงหนึ่งรายการสามารถทำให้ชีวิตคนพังได้ และข้อมูลทางการแพทย์ต่างกันเพียง 1 นาทีอาจเปลี่ยนโลกได้

    • MCP มีวัตถุประสงค์ที่การส่งผ่านและจัดการ context เท่านั้น กล่าวคือ ความรับผิดชอบในการทำ interface อย่างมีเหตุผล เช่น การนิยามและตรวจสอบ schema ยังอยู่ที่ผู้ใช้ นี่เหมือนกับข้อวิจารณ์ว่า “HTTP ไม่รองรับการตรวจสอบ JSON” ซึ่งเป็นเรื่องธรรมดา

  • MCP อาจเป็น “USB-C ของโลก AI” ก็ได้ แต่ในทางกลับกัน ผมมองว่านี่สะท้อนข้อบกพร่องของ USB-C มากกว่าความสำเร็จของ MCP USB-C เชื่อมต่อได้เกือบทุกอย่าง แต่การปฏิบัติตามมาตรฐานแย่มาก จึงคล้ายกับ JSON parsing และความไม่ปฏิบัติตามโปรโตคอลที่ไม่สม่ำเสมอของ MCP ที่หลายคนพูดถึง ตัวอย่างความจริงที่มี cable USB-C หลายแบบ ทำให้เหมือนยูนิเวอร์แซลแต่อยู่หลังฉากแล้วมีความซับซ้อนมากมาย แท้จริงแยก API/protocol อย่างชัดเจนคงดีกว่า

    • ตัวอย่างความผิดพลาดแบบสุดโต่งของ USB-C คือเมื่อ Apple ตัดพอร์ต USB-A ออกจาก Mac mini M4 รุ่นใหม่ โดยพอร์ตที่หน้าตาคล้ายกันจริง ๆ แล้วให้ประสิทธิภาพต่างกัน และผู้ใช้กว่าจะรู้เรื่องก็หลังประกาศผลิตภัณฑ์ไปแล้ว ก่อนหน้านี้ใครอยู่บน Apple Silicon desktop/laptop มักคาดหวังว่า USB-C ทุกพอร์ตจะเป็น Thunderbolt 40Gbps ได้ แต่วันนี้มีบางพอร์ตที่เหลือแค่ USB3 10Gbps ต้องดูสเปกหรือตัวไอคอนเล็ก ๆ เพื่อแยกก่อนใช้งาน ถ้าพวกเขายังเหลือพอร์ต USB-A บางส่วนไว้ สัญญาณของความจำกัด 10Gbps คงเห็นชัดขึ้น และก็ยิ่งทำให้คุณค่าของแบรนด์ USB-C ถูกเจือจางลงมากขึ้น ผลลัพธ์คืออุปกรณ์ USB-C ส่วนใหญ่ก็ยังต้องพึ่ง adapter ต่อ USB-A เสมอ USB-C กลายเป็นของแพงและหายาก และบางครั้งคุณภาพยังไม่ดี แต่โลกนี้ hype กับ fandom ชนะความ practical และ usability เสมอ

    • ผมขำมากที่เห็น “แนวคิด USB-C = ยูนิเวอร์แซลแต่มองไม่ชัด” สมกับตัวเอง เป้าหมายสำเร็จ พูดแล้วรู้สึกขำแทน

  • เกี่ยวกับ SOAP มีคนชมว่า “แม้ verbose มาก แต่มีบางอย่างที่ MCP ยังไม่รู้” ซึ่งความจริงแล้ว SOAP เองก็ไม่ได้ถูกเข้าใจมากนัก ผมเคยดูแลระบบ legacy SOAP มองกลับกันเลยว่า ไม่มีอะไรที่อยากชม SOAP ได้เลย มันไม่ควรเป็น role model

    • SOAP จริง ๆ แล้วเป็นหายนะขนาดใหญ่ น่าทึ่งว่าคอนเซปต์ที่ควรจะง่ายถูกทำให้ซับซ้อนขึ้นอย่างไร XML เองก็ซับซ้อนแล้ว บวกกับ WSDL/HTTP multi-part และเกณฑ์การนิยามที่ไม่ชัดเจน รวมถึงการขาด interoperability ระหว่างภาษา (เช่น ประสบการณ์ SOAP ระหว่างเซิร์ฟเวอร์ .NET กับ Java client) ถึงเวลาผ่านไปคนอาจจำแต่ด้านดี ผมเลือกทำงานกับ JSON API แบบไม่มี schema อยู่เสมอ 50 ปีมากกว่าเดิมก็ยังดีกว่าใช้ SOAP เพียง 1 เดือน และส่วนตัวผมเห็นว่า protobuf กับ capnp ดีกว่ามาก

    • ผมคิดว่า REST (หรือ JSON-RPC จริง ๆ) และ GraphQL กำลังพยายามตามฟีเจอร์ที่ SOAP และ SOA เคยมีอยู่นี้อยู่ และมันน่ารำคาญที่เมื่อเทคโนโลยีใหม่มา เรากลับทิ้งความดีเก่าไปด้วย

    • โปรโตคอลที่มีคำว่า ‘Simple’ อยู่มักไม่เคยง่ายจริง ๆ ผมได้ยินเหมือนกันว่าจะมีโปรโตคอลแบบ SMCP มาอีก

    • มีลิงก์อธิบาย SOAP ที่ทั้งตลกและแม่นมาก เลยอยากแชร์ https://harmful.cat-v.org/software/xml/soap/simple ผมเป็นคนชอบเทคโนโลยีที่อิง XML และเชื่อว่าความสามารถในการผสมชนิดข้อมูลและตรวจสอบของ XML Schema ยังเป็นที่หนึ่งเสมอ แต่ SOAP กลับดูเหมือนหมู่นายกองขนาดยักษ์ ที่มีเพียงความต้องการสเปก remote call ง่าย ๆ แต่พอกำหนดทุกอย่างทิ้งแล้วก็จัดการอะไรได้ไม่ครบ สิ่งที่ SOAP โฆษณาว่ารองรับ protocol ได้หลากหลาย (ตั้งแต่ SOAP over email), RPC หลายแบบ, UDDI และ RPC เชิงอัตโนมัติทั้งหลาย แต่ในความจริง สิ่งสำคัญอย่าง authentication, caching และ HTTP response code ยังคงเป็นหน้าที่ผู้ใช้เอง

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

  • CORBA เกิดขึ้นในปี 1991 จากความเข้าใจว่าในสภาพแวดล้อม heterogeneous ไม่ใช่ว่า implement โปรโตคอลเพียงคนละภาษาพอ และ OMG IDL ทำได้ดีตรงที่สร้าง binding เดียวกันได้หลายภาษา ป้องกันปัญหาความสอดคล้องของ interface และ serialization ได้ ผมยอมรับตรงนี้แต่ก็ยังสงสัยว่ามันประสบความสำเร็จจริงแค่ไหน

    • สภาพแวดล้อม API ที่เน้น JSON ในตอนนี้ดูเหมือนเป็นผลตอบแทนต่อความล้มเหลวของ CORBA และ SOAP มากกว่าการหลงลืมบทเรียนของ CORBA เพราะจริง ๆ แล้วเป็นการปฏิเสธอย่างตั้งใจ

    • ผมเคยทำงานในที่ที่ใช้ CORBA ได้ผลดีมาก และเชื่อว่าได้เพราะมี engineer senior ที่มีประสบการณ์ CORBA หนักในทีม

    • ปี 1998 ผมเคยสมัครเข้าไปทำงานที่ AT&T ที่ใช้ CORBA นั่นเป็นประสบการณ์สุดท้ายกับ CORBA ก่อนหน้านั้น (และหลังจากนั้นยกเว้นการรอ JDK download ช้า ๆ ก็แทบไม่เจอมันอีก) ตอนสัมภาษณ์ ผู้สัมภาษณ์บอกว่าโค้ด concurrency ของผมไม่ชอบ และแม้จะเสนอทางเลือกที่มีเรื่อง race condition ก็ยังอธิบายไม่ชนะ สุดท้ายทางกลับกันความจริงคือคำตอบของผมถูกตาม Java Memory Model

    • CORBA ทำหลายอย่างได้ดี แต่เป็นลูกหลานยุคต้นของเครือข่ายโทรคมนาคมดั้งเดิมและกระแส OOP ปลายยุค 80 จึงฝังสมมติฐานว่า network นั้นมีความโปร่งใส เชื่อถือได้ และ symmetric ได้ ทั้งที่โลกจริงไม่เป็นแบบนั้นเลย—มี timeout, retry, network congestion, system crash และปัญหาอื่น ๆ เต็มไปหมด โดยเฉพาะ binding ของ CORBA C++ ในช่วงก่อน STL ที่ยิ่งเลวร้าย และภาษาอื่นบางตัวกลับทำได้ดีกว่า

    • บนโครงการที่เทคโนโลยีดีแต่เชิงพาณิชย์พังก็ยังควรยอมรับความเก่งของมันได้

  • สิ่งที่หลุดจากการสนทนาเกี่ยวกับ MCP และ ‘บทเรียนที่ MCP ควรได้มาแล้วอย่างแท้จริง’ คือสิ่งตรงกันข้ามเลยคือฟีเจอร์ที่ซับซ้อนมากมักผลักให้เราตัดสินใจใช้สิ่งที่เรียบง่ายในทางปฏิบัติ เพราะฉะนั้นจึงมี JSON over HTTP ได้เป็นมาตรฐานหลักได้เช่นนั้น การย้ายระบบของบริษัทยักษ์ไป gRPC ซึ่งมี serialization ฟีเจอร์สูงอาจใช้เวลาหลายปีและอาจล้มเหลวหลายรอบ บทบาทแท้จริงของ MCP คือการมาตรฐานสัญญา JSON API ที่ไม่ซับซ้อน เพื่อให้การ generate token และรูปแบบการเรียก tool สำหรับ LLM ทำได้ง่ายขึ้น

    • อยากทราบความหมายของ HTTP blobs ไหม? ดูเหมือนว่าผู้เขียนจะพยายามอธิบายเหตุผลที่ JSON ชนะ XML น่าจะเป็นเหตุผลหลัก

  • MCP ไม่ได้สมบูรณ์แบบ แต่ผมคิดว่า MCP เรียนรู้บทเรียนสำคัญจากประวัติศาสตร์ RPC กว่า 40 กว่าปีได้อย่างถูกต้องแล้ว (คล้ายกับการก้าวขึ้นมาของ JSON เหนือ XML) SOAP ซับซ้อนเกินจำเป็นเพื่อให้เกิด interoperability ระหว่างระบบ และ XML พร้อม schema ก็ verbose มากเกินไป CORBA ก็ซับซ้อนเรื่องไลบรารี/เฟรมเวิร์กมากจนเวลานั้นเป็นภาษาทันสมัยหลายตัวที่หลีกเลี่ยงมัน gRPC เร็วแต่การอ่านยากและต้อง map เพิ่มเติม โครงกระดูกของ RPC สมัยนี้คือ REST กับ JSON มาตรฐานเดิมๆ ถูกผลักไปเป็นส่วนที่น้อย หรือ gRPC ถูกทิ้งไว้เฉพาะกรณีที่ต้องการความเร็วสูงสุด สาเหตุที่ REST และ JSON กลายเป็นกระแสหลักก็คือชัยชนะของความเรียบง่าย และ MCP ก็เป็นผลผลิตที่ออกแบบให้สอดคล้องกับแนวโน้มนี้

  • มีความเห็นดี ๆ เยอะมาก เราคงตีความ MCP พลาดอยู่ จุดสำคัญกว่านั้นคือความเข้าใจผิดทั่วทั้งอุตสาหกรรมว่าสิ่งที่เรียกว่า agent คืออะไร และอนาคตจะไปทางไหน ปัจจุบันหลาย web platform เชื่อว่าทุก agent ต้องฝังอยู่ในโครงสร้างพื้นฐานกระจายเครือข่าย จึงตั้งเป้าว่า MCP ต้องอยู่กับ agent ทุกตัวที่อยู่ใน container ผ่าน service mesh ทางความคิดของผม ผมไม่เห็นด้วยกับแนวคิดว่า ‘web-native agent และ SDK/framework ควรถูก deploy แบบ server app’ แบบนั้นไม่ถูก และมันก็ไม่ใช่ agent ในความหมายที่แท้จริง และยังไม่ใช่รูปแบบเริ่มต้นของวิวัฒนาการด้วย จนกว่าตอนนี้จริง ๆ แล้ว harness ของ agent ควรเป็นหน้าที่ผู้ให้บริการน้อยคน เช่น Frontier Labs และค่อย ๆ กลับไปสู่การใช้งานแบบส่วนตัวมากขึ้น (เช่น มี MCP server ตัวเดียวบนเดสก์ท็อปของผมเพื่อใช้กับ Claude Desktop) MCP server โดยเดิมมุ่งไปที่ single instance และ harness อย่างนั้น

    • ปัญหาของ MCP ไม่ได้อยู่ที่การออกแบบให้ไม่เหมาะกับ enterprise อย่างที่คิด แต่เป็นการใช้ LLM ในที่ที่ไม่เหมาะสมมากกว่า เช่น ในบริการการเงินที่ LLM รันคำสั่งซื้อขายด้วย error ของ precision ทศนิยมเป็นตัวปัญหาไม่ใช่เรื่องโปรโตคอล แต่เป็นการให้ LLM ที่ไร้ข้อจำกัดมาทำงานเทรด และการที่ LLM ทำความเข้าใจ format วันเวลาไม่ตรงจนสร้างค่า hallucination ก็เป็นผลจากการเอา LLM เข้าไปใช้ในสภาพแวดล้อม critical อย่างไม่เหมาะสม

  • อยากให้ใครสักคนอธิบายชัด ๆ ว่าทำไมต้องมี MCP ในเมื่อมี Swagger หรือ proto อยู่แล้ว

    • OpenAPI (Swagger) และ Proto (protobuf) ล้วนไม่สามารถครอบคลุมบทบาทของ MCP ได้เต็มที่ แนวคิดทฤษฎีคือซ้อน MCP บนพวกมันได้ แต่ใน local use case ของ MCP วิธีสมมติการสื่อสารของ Swagger ไม่ตรง และ protobuf ไม่ได้รวมโปรโตคอลการสื่อสารในตัว จึงยังต้องออกแบบเพิ่ม อีกทั้งแทนที่ JSON-RPC ก็ยังต้องเก็บสเปก MCP ไว้เกือบทั้งหมด จึงยุ่งยากกว่าเดิม

    • MCP เป็นเทคโนโลยีใหม่

    • MCP รองรับ streaming response ได้ แม้จะทำโดย polling หรือ state ใน session ก็ได้ แต่ก็เป็นการแก้ปัญหาชั่วคราวที่ไม่คุ้ม

  • เมื่อ OpenAI ระบุว่ามีการเรียกใช้ API เดือนที่แล้วมูลค่า 50,000 ดอลลาร์ คงระบุไม่ได้ว่าแผนกไหนของเครื่องมือ MCP ทำให้ต้นทุนนี้เกิดขึ้น หรือมีการเรียก tool คนไหน ผู้ใช้คนไหน use case ไหนบ้าง ปัญหาคือเทคโนโลยี AI ส่วนใหญ่มักแก้ที่ตามปัญหาไม่ทัน แต่เช่นเว็บเฟรมเวิร์ก บล็อกเชน พอเทคโนโลยีซับซ้อนมากในช่วงเริ่ม มันก็ยากที่จะรู้ทุกอย่าง ช่องว่างนั้นจะค่อย ๆ ลดลงในที่สุด และผมเห็นด้วยว่าควรแชร์ไอเดียและความตื่นตัวกันต่อเนื่องในด้าน AI สมัยนี้เป็นช่วงที่น่าสนใจจริง ๆ

  • เมื่อเจอสถานการณ์ต้องเลือกระหว่างการออกแบบที่ดีกว่าและการออกแบบที่ “พอใช้ได้” ผมเชื่อเสมอว่าข้าง “พอใช้ได้” จะชนะเสมอ เราเห็นตัวอย่างแบบนี้ได้ไม่ขาด ไม่ว่าจะเป็น Multics vs Unix, SOAP แบบ XML-based vs REST แบบ JSON-based, ความล้มเหลวของ xhtml, จนถึงตัว JavaScript เอง หากแต่ละรอบนี้ มนุษย์มักไป implement สิ่งที่พอใช้ได้ใหม่ ๆ และเมื่อปัญหาเปิดเผยก็ฉีดแปะ patch ชั่วคราวเพื่อแก้ต่อไป จนกลายเป็นชะตาของเรา

    • นี้คือการเกิดซ้ำของปรากฏการณ์ Worse is Better ที่คุ้นหูกันแล้ว (https://en.m.wikipedia.org/wiki/Worse_is_better). หลักฐานนี้ผ่านมาหลายครั้งแล้ว ผมเองก็ชอบเสาะหา solution ที่ “ดีกว่า” อยู่ตลอด แต่มันไม่ใช่ความจริงเสมอไป

    • สำหรับ xforms 2.0 น่าจะมีช่วงไว้อาลัย 1 นาที โลกที่เราอาจมีได้ก็คือฟอร์มเว็บที่ทำงาน valid ได้จริงและ microdata...