Level 3 · ใช้ขั้นโปรscheduleอ่าน 14 นาที

Connectors ต่อ AI เข้ากับเครื่องมือจริงด้วย CLI MCP และ API

starsTL;DR

เปรียบเทียบ CLI, MCP และ API แบบภาษาคน ว่าแต่ละอย่างเชื่อม AI กับอะไร ใครควรใช้ ยากแค่ไหน และเมื่อไหร่แค่ prompt หรือ skill ก็พอ ไม่ต้องต่อระบบใหญ่

Connectors ต่อ AI เข้ากับเครื่องมือจริงด้วย CLI MCP และ API

มีจุดหนึ่งที่การใช้ AI เปลี่ยนจาก "ถามตอบในกล่องแชท" ไปเป็น "ให้มันทำงานกับของจริง" เช่นดึง issue จาก GitHub อ่านข้อมูลจากฐานข้อมูล ดู dashboard ในบริษัท ส่งข้อความเข้า Slack หรือรัน script ที่คุณใช้ทุกวัน

พอถึงจุดนี้ คุณจะเริ่มเจอคำที่ฟังเหมือนคนละจักรวาลกัน: CLI, MCP, API, connector, server, tool, skill บางคนบอกให้ใช้ MCP บางคนบอกแค่เรียก CLI ก็พอ บางคนบอกต้องต่อ API เท่านั้น ฟังแล้วเหมือนต้องเป็น engineer ก่อนถึงจะเลือกถูก

จริง ๆ แล้วคำถามพื้นฐานมีแค่นี้

คุณอยากให้ AI แตะอะไร และแตะในระดับไหน

ถ้าแค่สั่งเครื่องมือในเครื่องคุณ อาจเป็น CLI ถ้าต้องให้ AI เห็นระบบภายนอกเป็น tool ที่เรียกได้ อาจเป็น MCP ถ้าคุณกำลังสร้าง product หรือ automation ที่โปรแกรมเรียก model เอง อาจเป็น API และถ้าแค่ต้องการให้ AI ทำตามขั้นตอนเดิมให้สม่ำเสมอ อาจไม่ต้องใช้ connector เลย skill ก็พอ

Connector คืออะไร

คำว่า connector ในบทนี้ไม่ได้หมายถึง feature เดียวของบริษัทเดียว แต่หมายถึง "ทางเชื่อม" ที่ทำให้ AI ไม่ได้อยู่แค่ในกล่องแชท

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

ทางเชื่อมมีหลายแบบ

  • ให้มันสั่งโปรแกรมในเครื่องผ่านคำสั่ง
  • ให้มันเรียก tool จากระบบภายนอกผ่านมาตรฐานกลาง
  • ให้โปรแกรมของคุณเรียก model โดยตรงผ่าน API
  • ให้มันทำตามขั้นตอนที่คุณเก็บไว้ใน skill

แต่ละแบบมีพลังไม่เท่ากัน ความยากไม่เท่ากัน และความเสี่ยงไม่เท่ากัน บทนี้จึงไม่ใช่คู่มือติดตั้ง แต่เป็นแผนที่ตัดสินใจ

CLI คือสั่งเครื่องมือผ่าน command line

เริ่มจากของที่จับต้องง่ายที่สุด CLI ย่อมาจาก command-line interface แปลเป็นภาษาคนคือ โปรแกรมที่สั่งงานด้วยตัวหนังสือใน terminal

เช่น git status ใช้ดูสถานะโค้ด npm test ใช้รัน test gh pr view ใช้ดู pull request ใน GitHub เครื่องมือจำนวนมากมี CLI ของตัวเอง เพราะมันเร็ว ชัด และเอาไปเขียน script ได้

สำหรับ AI, CLI มี 2 มุม

มุมแรก คุณใช้ CLI เพื่อคุยกับ AI เช่น claude เปิด session หรือ claude -p "query" ถามแล้วให้ตอบกลับมาใน terminal เอกสาร Claude Code ระบุว่า CLI ใช้เริ่ม session, pipe content, resume conversation และรันแบบ print mode ได้

มุมที่สอง AI ใช้ CLI เพื่อสั่งเครื่องมืออื่นผ่าน shell เช่นให้มันรัน test, เรียก git, ใช้ gh, เปิดไฟล์, ประมวลผล CSV ด้วย script หรือเรียกโปรแกรมภายในบริษัทที่มี command อยู่แล้ว

ข้อดีของ CLI คือเรียบง่ายและโปร่งใส คำสั่งที่รันเห็นเป็นตัวหนังสือ output กลับมาก็เป็นตัวหนังสือ เหมาะกับงานบนเครื่องหรือใน repo ที่มีเครื่องมือ command line อยู่แล้ว

ข้อเสียคือ CLI ต้องอยู่ใน environment ที่ตั้งค่าพร้อมแล้ว ถ้าต้อง login, set token, ตั้ง path, ติดตั้ง binary หรือจัด permission ผิด มันก็พังได้ และ AI อาจรันคำสั่งที่มีผลข้างเคียงถ้าคุณให้ permission กว้างเกินไป เรื่อง permission mode จึงสำคัญมาก แต่บทนั้นจะไปอยู่ใน วิจารณญาณและความปลอดภัย

💡 ใจความสำคัญ: CLI เหมาะเมื่อเครื่องมือมีคำสั่งอยู่แล้ว และคุณอยากให้ AI ใช้มันใน environment ของคุณ โดยเห็นคำสั่งและผลลัพธ์เป็นข้อความชัด ๆ

MCP คือ USB-C สำหรับ tool ของ AI

ต่อมาคือคำที่มาแรงที่สุดในกลุ่มนี้ MCP ย่อมาจาก Model Context Protocol

อธิบายแบบไม่เทคนิค MCP คือมาตรฐานกลางที่บอกว่า "ถ้าระบบภายนอกอยากให้ AI ใช้งานได้ ควรประกาศตัวเองเป็น tool หรือ resource แบบไหน" เหมือน USB-C ที่อุปกรณ์หลายชนิดใช้หัวเดียวกันได้ จอ ฮาร์ดดิสก์ ชาร์จเจอร์ คนละชนิดแต่เสียบพอร์ตเดียวกันได้เพราะตกลงมาตรฐานร่วมกัน

MCP server คือโปรแกรมฝั่ง tool ที่เปิดความสามารถให้ AI เรียก เช่น GitHub server อาจมี tool สำหรับอ่าน issue, สร้าง pull request, คอมเมนต์ review Postgres server อาจให้ดู schema หรือ query ฐานข้อมูล Docs server อาจให้ค้นเอกสารภายในบริษัท

Claude Code docs อธิบายว่า MCP servers ให้ Claude Code เข้าถึง tools, databases และ APIs ภายนอกได้ และ resources จาก MCP สามารถถูกอ้างถึงใน prompt ด้วย @server:protocol://resource/path คล้ายการอ้างไฟล์

จุดสำคัญคือ MCP ไม่ใช่ model และไม่ใช่ API ของ model มันเป็นมาตรฐานเชื่อม tool เข้ากับ AI host เช่น Claude Code ถ้า API คือทางให้โปรแกรมของคุณเรียก model MCP คือทางให้ model หรือ agent เรียก tool ของคุณ

API คือทางให้โปรแกรมเรียก model ดิบ

API เราเคยปูไว้แล้วในบท ทำไมใช้ผ่าน API ถึงไม่เหมือนใช้แอป จึงไม่ต้องสอนใหม่ทั้งหมด ตรงนี้ขอวางตำแหน่งในแผนที่เท่านั้น

API คือทางให้โปรแกรมของคุณส่งข้อความเข้า model แล้วรับข้อความออกมา ไม่มีหน้าจอ ไม่มี memory ไม่มี harness สำเร็จรูป เว้นแต่คุณสร้างเอง

ใช้ API เมื่อคุณไม่ได้แค่ให้ AI ใช้ tool ใน session ของคุณ แต่กำลังสร้างระบบที่เรียก AI เป็นส่วนหนึ่งของโปรแกรม เช่น chatbot ในเว็บบริษัท, ระบบสรุป ticket อัตโนมัติ, pipeline แปลเอกสาร 10,000 ฉบับ, หรือ product AI ที่คุณขายให้ลูกค้า

API จึงอยู่คนละฝั่งกับ MCP

  • API: โปรแกรมของคุณเรียก model
  • MCP: model หรือ agent เรียก tool ของคุณ

บางระบบใช้ทั้งคู่พร้อมกันได้ เช่นคุณสร้าง agent ด้วย API แล้วต่อ MCP servers ให้ agent นั้นใช้ tools ภายนอก แต่สำหรับคนเริ่มต้น แยกสองประโยคข้างบนให้ได้ก่อนก็พอ

ตารางเดียว: CLI vs MCP vs API

ถ้าต้องเลือกเร็ว ๆ ให้ดูตารางนี้

ทางเชื่อมเชื่อมอะไรใครมักใช้เหมาะกับงานความยากจุดเสี่ยง
CLIAI สั่งโปรแกรมในเครื่องผ่าน commandคนทำงานกับไฟล์ โค้ด script terminalรัน test, git, แปลงไฟล์, automation ในเครื่องกลางpermission, environment, คำสั่งมีผลข้างเคียง
MCPAI host ต่อกับ tool/data ภายนอกผ่านมาตรฐานกลางpower user, ทีม tech, บริษัทที่มีระบบหลายตัวGitHub, database, docs, Slack, issue tracker, dashboardกลางถึงสูงสิทธิ์เข้าถึงข้อมูล, tool เยอะกิน context, auth
APIโปรแกรมของคุณเรียก model โดยตรงdeveloper, product team, automation builderสร้าง product, batch, backend workflow, ระบบอัตโนมัติสูงบิล, privacy, ต้องสร้าง harness เอง

ตารางนี้ไม่ได้บอกว่าอันไหนดีที่สุด มันบอกว่าแต่ละอันเกิดมาแก้คนละปัญหา

ลองทำดู: แยกโจทย์ 5 แบบ

ลองอ่าน 5 งานนี้ แล้วตอบว่าควรเริ่มจาก prompt, skill, CLI, MCP หรือ API

1. สรุป meeting note ให้เป็นรูปแบบเดิมทุกครั้ง
2. ให้ AI รัน test ใน repo แล้วอธิบาย error
3. ให้ AI อ่าน issue จาก GitHub โดยไม่ต้อง copy paste
4. สร้างเว็บที่ลูกค้าคุยกับ chatbot ของบริษัทได้
5. ให้ AI ใช้ checklist review บทความ v3 ทุกบท

คำตอบที่สมเหตุสมผลคือ 1 ใช้ skill หรือ prompt, 2 ใช้ CLI, 3 ใช้ MCP หรือ plugin ที่ต่อ GitHub, 4 ใช้ API, 5 ใช้ skill

เมื่อไหร่แค่ prompt ก็พอ

ก่อนจะต่อระบบอะไร ให้ถามคำถามที่น่าเบื่อแต่ช่วยประหยัดชีวิตมาก: แค่ prompt พอไหม

ถ้างานเกิดครั้งเดียว ข้อมูลอยู่ตรงหน้าคุณ และไม่มี tool ภายนอกที่ต้องแตะ อย่าต่ออะไรให้ยุ่ง เปิดแชทแล้วพิมพ์ให้ดีพอ

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

prompt เหมาะเมื่อ

  • งานใช้ครั้งเดียว
  • ข้อมูลไม่เยอะ
  • ไม่มีการทำซ้ำเป็น pattern
  • ไม่ต้องเข้าถึงระบบภายนอก
  • ถ้าพลาดก็แก้ด้วยการคุยต่อได้

เมื่อไหร่ใช้ skill

skill เหมาะเมื่อคุณยังไม่ต้องเชื่อมระบบภายนอก แต่มีวิธีทำงานที่อยากเก็บไว้เรียกซ้ำ

ถ้างานคือ "ทุกครั้งที่ review บทความ ให้ดู voice, coverage, accuracy, image spacing แล้วสรุป verdict" นี่คือ skill ไม่ใช่ MCP เพราะ AI ไม่ได้ต้องต่อระบบใหม่ มันแค่ต้องทำตาม procedure เดิม

ถ้างานคือ "ทุกครั้งที่เขียน report ให้ใช้ format นี้ เปิดด้วย executive summary แล้วมี risk section" นี่ก็ skill

ถ้างานคือ "ให้ AI อ่าน dashboard live จากระบบ monitoring" นั่นไม่ใช่ skill อย่างเดียว เพราะ skill ไม่มีมือไปดึงข้อมูลสด ถ้าจะไม่ copy paste คุณต้องมี CLI, MCP หรือ API ของระบบ monitoring เข้ามาเกี่ยว

กฎสั้น ๆ คือ skill เก็บ "วิธีทำ" ไม่ได้เชื่อม "แหล่งข้อมูลสด" เอง เว้นแต่ skill จะเรียก script หรือ tool ที่คุณให้มันใช้ ซึ่งพอถึงจุดนั้นคุณต้องคิดเรื่อง permission และ security เพิ่ม

เมื่อไหร่ใช้ CLI

CLI เหมาะเมื่อเครื่องมือที่ต้องใช้มี command อยู่แล้ว และงานเกิดใน environment ที่ AI รันคำสั่งได้

ตัวอย่างเช่น

  • รัน npm test แล้วอธิบาย error
  • ใช้ git diff เพื่อสรุปสิ่งที่เปลี่ยน
  • ใช้ gh issue view 123 เพื่อดู issue จาก GitHub ถ้าเครื่องคุณ login GitHub CLI ไว้แล้ว
  • ใช้ script ภายในบริษัทแปลงไฟล์ CSV เป็นรายงาน
  • pipe log เข้า claude -p เพื่อให้สรุปแบบ non-interactive

CLI ดีเมื่อคุณอยากเห็นคำสั่งที่รันและ output ที่กลับมา เหมาะกับงาน local, repo, script และ automation ที่ไม่ได้ต้องประกาศ tool schema ซับซ้อน

แต่ถ้างานต้องให้ AI browse resource จำนวนมากจากระบบภายนอก พร้อม autocomplete, auth, tool ที่ structured และใช้ได้ข้าม project MCP อาจเหมาะกว่า

เมื่อไหร่ใช้ MCP

MCP เหมาะเมื่อคุณอยากให้ AI host มองระบบภายนอกเป็นชุดเครื่องมือที่เรียกได้อย่างเป็นระเบียบ ไม่ใช่แค่รัน command ดิบ ๆ

ตัวอย่างเช่น

  • ให้ Claude อ่าน issue, branch, pull request จาก GitHub plugin
  • ให้ AI query schema ฐานข้อมูลผ่าน server ที่จำกัดสิทธิ์ไว้
  • ให้ AI ค้น docs ภายในบริษัทด้วย @docs:file://...
  • ให้ AI อ่าน alert จาก monitoring dashboard
  • ให้ AI สร้าง ticket หรือคอมเมนต์ในระบบงานโดยใช้ tool ที่ออกแบบไว้

MCP เหมาะเมื่อมีหลาย tool หลาย resource และอยากให้ AI discover ได้ว่าอะไรมีให้ใช้บ้าง แต่ข้อแลกเปลี่ยนคือ tool schemas และ resource listings อาจกิน context เพิ่ม ถ้าต่อ MCP server เยอะโดยไม่คุม คุณอาจทำให้ session หนักโดยไม่จำเป็น เรื่องนี้โยงกลับไปบท Token optimization ตรง ๆ

อีกจุดคือ MCP คือสะพานเข้า data จริง ดังนั้น permission สำคัญมาก ต่อ database แบบ read-only ต่างจากต่อแบบ write ได้ ต่อ GitHub ที่อ่าน issue ได้ ต่างจากต่อแบบ merge PR ได้ ตั้ง scope ให้แคบที่สุดเท่าที่งานต้องใช้

💡 ใจความสำคัญ: MCP เหมาะเมื่อ AI ต้องเข้าถึง tool หรือข้อมูลภายนอกซ้ำ ๆ อย่างเป็นระบบ ไม่ใช่เมื่อคุณแค่อยากให้มันทำตาม checklist เดิม

เมื่อไหร่ใช้ API

ใช้ API เมื่อคุณกำลังสร้างระบบที่ โปรแกรมของคุณ ต้องเรียก AI เอง

ถ้ามีคนต้องนั่งเปิด Claude Code หรือ ChatGPT แล้วกดสั่งทีละครั้ง นั่นยังไม่ใช่ API use case ที่แท้จริง แต่ถ้าคุณอยากให้ระบบหลังบ้านรันเองทุกคืน อยากให้ลูกค้ากดปุ่มบนเว็บแล้ว AI ตอบ อยากให้ pipeline ประมวลผลเอกสารเป็นพันฉบับ หรืออยากขาย product AI ของตัวเอง นั่นคือ API

API ให้ความยืดหยุ่นสูงสุด แต่คุณต้องสร้างของที่แอปสำเร็จรูปให้มาฟรีเอง เช่น memory, tool calling, logging, monitoring, auth, UI, rate limit, cost control, privacy policy และ fallback เวลาระบบล่ม

ดังนั้นสำหรับผู้ใช้ทั่วไป API ไม่ใช่ next step โดยอัตโนมัติ มันคือทางเลือกตอนคุณข้ามจาก "ใช้ AI" ไปเป็น "สร้างระบบที่ใช้ AI"

ลำดับตัดสินใจแบบไม่หลง

เวลาเจอโจทย์ใหม่ ให้ไล่คำถามแบบนี้

  1. ใช้ครั้งเดียวไหม ถ้าใช่ เริ่มจาก prompt
  2. ทำซ้ำแบบเดิมบ่อยไหม ถ้าใช่ ทำเป็น skill
  3. ต้องรันเครื่องมือในเครื่องหรือ repo ไหม ถ้าใช่ ใช้ CLI
  4. ต้องให้ AI เข้าถึงระบบภายนอกเป็น tool/resource ซ้ำ ๆ ไหม ถ้าใช่ ใช้ MCP
  5. ต้องให้โปรแกรมของคุณเรียก model เองโดยไม่มีคนนั่งแชทไหม ถ้าใช่ ใช้ API

ลำดับนี้ตั้งใจเริ่มจากของง่ายที่สุดก่อน เพราะ connector ที่ซับซ้อนขึ้นไม่ได้แปลว่าดีกว่าเสมอไป มันแค่ให้ reach มากขึ้น และทุกครั้งที่ reach เพิ่ม ความเสี่ยงกับต้นทุนก็เพิ่มตาม

ลองทำดู: เขียน connector brief

ก่อนต่ออะไรจริง ให้เขียน brief สั้น ๆ แบบนี้

ฉันอยากให้ AI ทำงานอะไร
ข้อมูลหรือเครื่องมืออยู่ที่ไหน
ต้องอ่านอย่างเดียว หรือเขียน/แก้/ส่งออกได้ด้วย
งานนี้ใช้ครั้งเดียว ทำซ้ำบ่อย หรือเป็นระบบอัตโนมัติ
ถ้า AI ทำผิด ความเสียหายคืออะไร
ทางง่ายที่สุดที่พอทำงานได้คือ prompt, skill, CLI, MCP หรือ API

brief นี้ช่วยกันความอยาก "ต่อของเท่ ๆ" ก่อนเข้าใจว่าจริง ๆ ต้องการอะไร

สรุป: อย่าเลือก connector จากชื่อเท่ ให้เลือกจาก reach

CLI, MCP และ API ไม่ได้แข่งกันว่าอะไรทันสมัยกว่า มันเป็นทางเชื่อมคนละระดับ

CLI คือให้ AI ใช้คำสั่งใน environment ของคุณ เหมาะกับไฟล์ repo script และ automation local ที่เห็นคำสั่งชัด

MCP คือมาตรฐานเสียบ tool และ data source เข้ากับ AI host เหมาะกับระบบภายนอกที่ต้องใช้ซ้ำเป็น tool หรือ resource เช่น GitHub, database, docs, dashboard

API คือช่องทางให้โปรแกรมของคุณเรียก model ดิบ เหมาะกับการสร้าง product, backend workflow, batch, automation ที่ไม่ต้องมีคนนั่งแชท

และบ่อยครั้งคำตอบที่ถูกไม่ใช่สามอย่างนี้เลย แค่ prompt หรือ skill ก็พอ ถ้างานคือการทำตามขั้นตอนซ้ำ ไม่ได้ต้องแตะข้อมูลสดข้างนอก อย่าต่อระบบใหญ่ให้รก

บทถัดไปจะติดป้ายชัดว่าเป็นสาย builder มากขึ้น เราจะดูความรู้ tech ที่ยกระดับการใช้ AI จริง ๆ เช่น Playwright, tmux, GitHub, worktrees และสิ่งที่คนไม่สายเทคควรรู้เฉพาะตอนเริ่มลงมือสร้างของจริง

อ่านต่อ: Builder track ความรู้สาย tech ที่ยกระดับการใช้ AI

แหล่งอ้างอิง