เวลาพูดถึง AI Agent หลายคนนึกถึงแชทบอทที่ฉลาดขึ้น แต่ agent จริงๆ ต้องทำมากกว่านั้น มันต้องออกไปเชื่อมต่อระบบภายนอก ดึงข้อมูลจริง และดำเนินการจริง สิ่งที่ทำให้ agent แตกต่างจากแชทบอทธรรมดาคือความสามารถในการเรียกใช้ tools ผ่านสองกลไกหลัก ได้แก่ API กับ MCP ซึ่ง AI with Surya ช่อง YouTube ด้านพัฒนา AI agent ได้สาธิตผ่าน demo สามตัวอย่างที่ทำให้เห็นภาพชัดเจนว่าระบบทั้งสองทำงานต่างกันอย่างไร
แต่ละตัวได้รับโจทย์เดียวกัน — ถามสภาพอากาศในออสติน — แต่ตอบด้วยกระบวนการที่ต่างกันโดยสิ้นเชิง ตัวแรกใช้ API อย่างเดียว ตัวที่สองใช้ MCP และตัวที่สามใช้ทั้งคู่รวมกัน ผลที่ได้ไม่เพียงแสดงให้เห็นความต่าง แต่ยังตอบว่าควรใช้อะไรเมื่อไร และเมื่อใดที่รวมกันถึงจะได้ผลดีที่สุด
- MCP คือ "ประตูที่ถามได้เอง" — agent เชื่อมต่อแล้วถามว่า "คุณทำอะไรได้บ้าง?" ระบบตอบเองในรูปแบบมาตรฐานที่ AI ทุกตัวเข้าใจ
- ใช้ API อย่างเดียว → agent รู้แค่ทักษะที่เขียนโค้ดไว้ เพิ่มความสามารถใหม่ต้องเขียนโค้ดเพิ่มทุกครั้ง
- MCP server เดียวใช้กับ Gemini, Claude, ChatGPT ได้ทั้งหมด — build ครั้งเดียวใช้กับทุก AI ที่รองรับ protocol
- Production agent จริงใช้ทั้งสอง — MCP สำหรับ tools ที่ค้นพบได้ + API โดยตรงสำหรับงานที่ต้องความแม่นยำสูง
API: ประตูที่มีกฎ
API คือวิธีที่โปรแกรมสองตัวคุยกัน ลองนึกภาพมันเป็น "ประตูที่มีกฎ" — โปรแกรมหนึ่งเคาะประตูในรูปแบบที่กำหนดไว้ ได้รับคำตอบกลับมาในรูปแบบที่กำหนดไว้เช่นกัน ในโลกจริงมี API หลายแบบที่เจอบ่อย REST คือมาตรฐานหลักที่เว็บส่วนใหญ่ใช้ GraphQL คือแบบที่ขอ fields เฉพาะที่ต้องการได้โดยไม่ต้องรับข้อมูลทั้งก้อน และ Webhook คือแบบที่ระบบจะเรียกกลับมาเองเมื่อมีเหตุการณ์เกิดขึ้นตามที่กำหนด
เวลา agent ใช้ API ก็เหมือนนักพัฒนาอ่านเอกสาร API แล้วเขียนโค้ดเชื่อมต่อด้วยตนเอง ทุก endpoint ที่ต้องการต้องเขียนโค้ดกำหนดไว้ล่วงหน้าทั้งหมด ใน demo agent ตัวแรกมีเครื่องมือเดียวคือ get_current_weather — เมื่อถามสภาพอากาศมันเรียก weather API เมื่อถามราคาหุ้นก็เรียก finance API อีกตัว แต่ละ tool เขียนแยกกัน ทำงานได้ดีในขอบเขตที่กำหนดไว้ แต่ไม่รู้จักอะไรเลยนอกจากที่โค้ดบอกไว้ สิ่งที่ดีของแบบนี้คือความชัดเจน — นักพัฒนารู้ทุกอย่างว่าใช้ endpoint ไหน ส่งอะไรไป รับอะไรกลับมา ดีบักและ monitor ได้ง่าย แต่ก็หมายความว่าทุกความสามารถใหม่ต้องผ่านกระบวนการเดิมทั้งหมด
ข้อจำกัดของ API ในระบบ Agent ขนาดใหญ่
ปัญหาเริ่มชัดเมื่อระบบขยายตัว ลองนึกถึงบริษัทที่ต้องการให้ agent เชื่อมต่อ 5 ระบบที่แตกต่างกัน นั่นหมายถึง 5 integrations แยกกัน และถ้าแต่ละระบบมีคำถามหลายประเภท ก็อาจหมายถึง tools อีกหลายสิบตัวที่ต้องเขียน ทดสอบ และดูแลรักษาตลอดไป ทุกความสามารถใหม่คือโค้ดใหม่ที่ต้องเพิ่ม ทุก endpoint ใหม่คือ maintenance เพิ่มขึ้น
ที่สำคัญกว่านั้น agent ที่ใช้ API อย่างเดียวจะ "รู้แค่ที่เขียนไว้" มันไม่สามารถค้นพบความสามารถใหม่ได้เอง ถ้าเพิ่ม tool ใหม่เข้าระบบ ต้องบอก agent ในโค้ดแล้ว deploy ใหม่ ยิ่งทำในระดับองค์กรที่มีทีมหลายทีมต้องการ agent ทำงานได้หลายอย่าง ยิ่งเห็นชัดว่าการเขียน integration ด้วยมือทีละ endpoint ไม่ใช่ทางออกระยะยาว
MCP: ระบบที่ Agent ค้นพบ Tools เอง
MCP หรือ Model Context Protocol แก้ปัญหานี้ด้วยแนวคิดง่ายๆ แทนที่นักพัฒนาจะต้องเขียนโค้ดเชื่อมต่อทุก endpoint เอง agent เพียงแค่เชื่อมต่อกับ MCP server แล้วถามว่า "คุณทำอะไรได้บ้าง?" server จะตอบเองในรูปแบบมาตรฐานที่ AI ทุกตัวเข้าใจ โดยบอก tools ที่มีอยู่ ชื่อเรียก สิ่งที่ต้องการ และสิ่งที่จะคืนกลับมา agent เรียนรู้ทั้งหมดนี้ที่ runtime ไม่ใช่ตอน code time
ใน demo เมื่อ agent ถามสภาพอากาศผ่าน MCP สิ่งแรกที่เกิดขึ้นคือ agent ถาม server ว่ามี tools อะไรบ้าง server ตอบว่ามีสาม tools: สภาพอากาศปัจจุบัน พยากรณ์อากาศ และคุณภาพอากาศ จากนั้น agent เลือก tool ที่เหมาะกับคำถามเอง เมื่อถามเปรียบเทียบอากาศวันนี้กับพรุ่งนี้ agent ก็เรียกทั้งสอง tools ต่อกันเองโดยไม่ต้องมีใครบอก ลำดับในการเรียก tool ที่ถูกต้องนั้นเป็นการตัดสินใจของ LLM ทั้งหมด ไม่ใช่ hard code ในโค้ด
ความแตกต่างสำคัญ: กับ API คนพัฒนาเป็นคนเชื่อมทุกอย่างด้วยมือ กับ MCP server เป็นคนประกาศตัวเอง agent เป็นคนค้นพบ
สิ่งที่ทำให้ MCP น่าสนใจอีกอย่างคือ MCP server เดียวใช้กับ AI ทุกตัวได้ ไม่ว่าจะเป็น Gemini, Claude หรือ ChatGPT ตราบที่ทุกตัวพูดภาษา protocol เดียวกัน build server ครั้งเดียวก็ใช้ได้กับทุก AI จึงไม่แปลกที่ทั้งอุตสาหกรรมหนุนหลัง ช่วงปลายปีที่ผ่านมา MCP ถูกส่งมอบให้กับ Linux Foundation โดยมีทั้ง Anthropic, OpenAI, Google, Microsoft, Amazon ลงนามสนับสนุนร่วมกัน นี่ไม่ใช่แค่ protocol ของบริษัทใดบริษัทหนึ่ง แต่กำลังกลายเป็นมาตรฐานกลางของอุตสาหกรรม
ใช้ทั้งสอง: วิธีที่ Agent จริงในโปรดักชันทำ
Demo ตัวที่สามแสดงให้เห็นภาพที่ใกล้เคียงกับการใช้งานจริงมากที่สุด agent ตัวนี้ใช้ทั้ง weather MCP และ Google Maps Places API โดยตรง เมื่อถามว่า "แนะนำสวนสาธารณะในออสตินหน่อย" agent ตรวจสภาพอากาศผ่าน MCP ก่อน แล้วส่งข้อมูลอากาศนั้นไปประกอบการค้นหาสวนที่เหมาะสมผ่าน Places API แล้วแสดงแผนที่พร้อมคำอธิบายว่าทำไมถึงแนะนำจุดนั้นในวันนั้น
MCP กับ API ไม่ใช่ทางเลือกที่ต้องเลือกอย่างใดอย่างหนึ่ง API ยังเหมาะกับงานที่ต้องการความแม่นยำสูง มี endpoint เฉพาะทาง หรือต้องการควบคุม flow อย่างละเอียด MCP เหมาะกับงานที่ต้องการ tools หลายตัวที่ agent ค้นพบเองได้ หรือต้องการให้ server เดียวใช้กับ AI หลายตัวโดยไม่ต้องเขียนโค้ดซ้ำ ลองถามตัวเองสองข้อ: tools ที่ต้องการมีนิยามชัดเจนและจำนวนน้อยพอที่จะเขียนด้วยมือได้ไหม ถ้าใช่ API ตรงๆ อาจง่ายกว่า ต้องการให้ agent ค้นพบ tools ใหม่ได้เองหรือแชร์ server กับ AI หลายตัวไหม ถ้าใช่ ลงทุนตั้ง MCP server ตั้งแต่ต้นคุ้มกว่า
บทสรุป
API กับ MCP ไม่ใช่เรื่องของการเลือกฝ่ายใดฝ่ายหนึ่ง API เป็น backbone ที่ทำงานได้ดีในงานที่ต้องการความชัดเจนและควบคุมได้ ส่วน MCP ช่วยให้ agent ค้นพบและใช้งาน tools ได้อย่างยืดหยุ่นโดยไม่ต้องเขียนโค้ดเชื่อมต่อทุกอย่างด้วยมือ Production agent จริงส่วนใหญ่ใช้ทั้งสองรวมกัน เลือกแต่ละแบบตามลักษณะงานที่เหมาะสม
สำหรับใครที่กำลังเริ่มสร้าง agent ครั้งแรก ความเข้าใจสองเรื่องนี้จะช่วยให้ตัดสินใจ architecture ได้ชัดขึ้นมาก และไม่ว่าจะเลือกแบบไหน จุดร่วมสำคัญคือ agent ที่ดีไม่ใช่แค่แชทบอทที่ฉลาดขึ้น แต่คือระบบที่ออกไปทำงานได้จริงกับโลกภายนอก
