ช่วงนี้คำว่า Agent Skills (ชุดความรู้แพ็คสำเร็จให้ AI) อยู่ทุกที่ หลายคนเลยเริ่มถามว่านี่คือจุดจบของ MCP (มาตรฐานต่อ AI เข้ากับเครื่องมือและข้อมูลภายนอก) แล้วจริงแค่ไหน? ในคลิป Agent Skills or MCP in the era of Claude Code? จาก ช่อง Confluent Developer Tim Berglund ขึ้น lightboard มาตอบคำถามนี้แบบไม่เอนเอียงไปฝ่ายใดฝ่ายหนึ่ง สรุปสั้นๆ คือ Skills ไม่ได้มาฆ่า MCP เพราะทั้งคู่ทำกันคนละงาน ฝั่งหนึ่งทำงานอยู่ในเครื่อง อีกฝั่งต่อออกไปหาโลกภายนอก บทความนี้สรุปเนื้อหาทั้งคลิปเป็นภาษาไทย พร้อมตารางช่วยตัดสินใจว่างานแบบไหนควรใช้อะไร เพื่อให้คนที่ใช้ Claude Code หรือกำลังสร้าง AI agent ของตัวเองเห็นภาพว่าควรวางของสองอย่างนี้ไว้ตรงไหน
คำถามที่ทุกคนถาม Skills มาฆ่า MCP จริงไหม
จุดตั้งต้นของคลิปคือกระแสที่ว่า Skills กำลังจะแทนที่ MCP ทั้งหมด Tim Berglund เปิดด้วยการยอมรับตรงๆ ว่าคำถามนี้ฟังดูมีเหตุผล คนที่ถามไม่ได้คิดไปเอง แต่ก่อนจะรีบตัดสิน เขาขอให้ความเป็นธรรมกับ MCP ก่อน โดยทบทวนว่าตลอดไม่กี่เดือนที่ผ่านมา โลกของ MCP เปลี่ยนไปอย่างไรบ้าง กรอบนี้ทำให้ทั้งคลิปไม่ใช่ hot take ที่เชียร์ฝั่งใดฝั่งหนึ่ง แต่พาไล่ดูทีละชั้นว่าของสองอย่างนี้ทำงานต่างกันตรงไหน
ประเด็นที่ Tim ย้ำตั้งแต่ต้นคือ คำตอบสุดท้ายไม่ใช่ Skill ชนะหรือ MCP ชนะ แต่อยู่ที่การเข้าใจว่าทั้งคู่ทับซ้อนกันตรงไหน และแยกจากกันตรงไหน พอเห็นเส้นแบ่งชัด คำถามว่าจะเลือกอะไรก็จะตอบง่ายขึ้น กลายเป็นว่า "งานตรงหน้าต้องการของฝั่งไหน" ส่วนที่เหลือของบทความจะไล่ตามลำดับเดียวกับที่ Tim เล่าบน lightboard เริ่มจาก MCP คืออะไร แล้วค่อยไปถึง Skill และจุดที่ทั้งสองมาเจอกัน
MCP คืออะไรแบบเร็วๆ
ก่อนจะเทียบกับ Skill Tim Berglund ทบทวน MCP ให้ฟังใหม่อีกรอบ ภาพตั้งต้นคือมี agent (ตัวช่วยอัตโนมัติที่ทำงานแทนคน) ตัวหนึ่ง อาจรันอยู่บน laptop ของใครสักคน หรือเป็น microservice ที่รันอยู่บน cloud ก็ได้ เมื่อผู้ใช้ส่ง prompt (คำสั่งที่พิมพ์เข้าไป) เข้ามา agent จะเรียก LLM ขึ้นมาคิดว่าควรทำอะไรกับ prompt นั้น
ตามที่ Tim อธิบาย ปัญหาอยู่ที่ตัว LLM เอง 2 ข้อ ข้อแรกคือ LLM รู้แค่สิ่งที่มันอ่านมาจากอินเทอร์เน็ต จึงไม่รู้อะไรเลยเกี่ยวกับเรื่องภายในบริษัท ไม่ว่าจะเป็น support ticket หน้า wiki หรือ Google Docs ขององค์กร เพราะไม่มีทางรู้ได้ตั้งแต่แรก ข้อสองคือ LLM ลงมือทำอะไรเองไม่ได้ ทำได้แค่ตอบ text กลับมา ทั้งที่สิ่งที่เราอยากได้คือ agent ที่ลงมือทำแล้วเกิดผลจริงในโลก
Tim เรียกของที่จะมาเติมช่องว่างสองข้อนี้ว่า tools (การกระทำที่ทำให้เกิดผลจริง) กับ resources (เอกสารและข้อมูลภายในบริษัท) ปัญหาคือ API ที่ใช้เข้าถึงของพวกนี้เป็นอะไรก็ได้ ไม่มีใครรู้ล่วงหน้าว่าแต่ละที่ทำไว้แบบไหน MCP server จึงเข้ามายืนคั่นกลางตรงนี้ หน้าที่ของมันคือ implement API ที่ไปเรียก tools รู้วิธีเข้าถึง resources แล้วยื่น interface มาตรฐานชุดเดียวให้ agent พร้อมบอกความสามารถของตัวเองให้ agent รับรู้ ผลคือมันกลายเป็นของที่เสียบปลั๊กได้ แค่ชี้ agent ไปที่ MCP server ตัวนั้น agent ก็เรียนรู้ที่จะทำทุกอย่างได้เอง Tim บอกว่าสิ่งนี้ทรงพลังมากและทำงานได้ดีมาก
ในรอบ 9 ถึง 12 เดือน MCP เปลี่ยนไป 3 อย่าง
หลังทบทวนภาพรวมแล้ว Tim Berglund ชี้ว่าตั้งแต่คลิปก่อนของเขาจนถึงตอนถ่ายคลิปนี้ ราว 9 ถึง 12 เดือน MCP มีของใหม่ที่น่าสนใจ 3 อย่าง
เรื่องแรกคือ Resource API แทบไม่มีคนใช้แล้ว Tim สังเกตเห็นแนวโน้มนี้ และชวนผู้ชมไปลองดูเองว่า ถ้าไปหา MCP server ที่ใช้งานจริง ทั้งแบบ cloud และแบบ open source ที่รันในเครื่องได้ แล้วเปิด docs ดู จะเห็นการใช้ Resource API เยอะแค่ไหน สิ่งที่หลายคนค้นพบคือ ใช้ Tools API ทำงานเดียวกันได้เลย เพราะการ query resource หนึ่งครั้งก็เหมือนการเรียก tool ครั้งหนึ่ง คล้ายการเรียก method ทั่วไปที่ส่ง parameter เข้าไปแล้วได้ของกลับมา โดยแทบไม่มีผลเสียอะไร Tim มองว่านี่เป็นข้อสังเกตที่น่าสนใจเรื่องความยากของการออกแบบ API เพราะของที่ออกแบบมาไม่ได้ถูกใช้อย่างที่ตั้งใจไว้เสมอ สุดท้ายชุมชนก็เลือกทางที่ตัวเองถนัด
เรื่องที่สองคือการรองรับ streamable HTTP ตามที่ Tim เล่า ตอนคลิปก่อนหน้านี้ MCP รองรับแค่ server-sent events (SSE) ทำให้คนใช้หงุดหงิดอยู่บ้าง และจัดการ networking ได้ยากถ้า MCP server ไม่ได้รันในเครื่องแต่ไปรันบน cloud การเพิ่ม streamable HTTP เข้ามาจึงสะอาดกว่าและ deploy ง่ายกว่าในแง่โครงสร้างพื้นฐาน Tim เรียกว่านี่เป็นการเปลี่ยนแปลงที่ดีชัดเจน
เรื่องที่สามคือการรองรับ OAuth 2.1 ซึ่ง Tim ยอมรับว่า authentication เป็นจุดเจ็บของ spec เวอร์ชันแรกอย่างไม่ต้องสงสัย เมื่อก่อนถ้ามี secret ที่ MCP server ต้องใช้ ตัว server เองต้องรู้ secret นั้น โดยใส่ไว้ใน environment variable หรือทำ secret management เองเพื่อ auth ตัวเองกับ backend วิธีนี้พอใช้ได้ในบางงาน แต่ปัญหาเกิดทันทีเมื่อ MCP server พยายามต่อกับบริการอย่าง GitHub เพราะสิ่งที่คนอยากได้จริงๆ คือให้ user หน้าบ้านเจอ OAuth pop-up ตามปกติ แบบที่ขึ้นว่าแอปนี้ขอเข้าถึงบัญชี GitHub เห็นโปรไฟล์และเปิด issue ได้ แล้วกดอนุญาต OAuth 2.1 จึงออกแบบมาเพื่อรองรับเคสที่ agent รันอยู่ในเครื่อง ทำให้มี server เดียวบน cloud ที่ขอ OAuth ไปยัง backend อะไรก็ได้
Tim เสริมว่า ณ ตอนที่ถ่ายคลิป เคส agent รันในเครื่องแบบนี้คือ majority report หรือสิ่งที่เจอบ่อยที่สุดแบบทิ้งห่าง ถ้าเป็นนักพัฒนาที่เคยรัน Claude Code บน laptop ก็น่าจะเคยเจอ pop-up นี้แล้ว และเขาบอกว่าใช้งานได้ดีมาก อย่างไรก็ตาม Tim ตั้งข้อสังเกตว่าถ้าเป็น agentic microservice ที่รันแบบ headless อยู่บน cloud OAuth แบบนี้ยังทำงานได้ไม่ดีนัก จึงมีคำสัญญาว่าจะมีทางออกที่ดีกว่าสำหรับเคส microservice ซึ่งเป็นเคสที่ Tim คาดว่าจะเจอมากขึ้นเรื่อยๆ
แล้ว Skill คืออะไร
พอให้ความเป็นธรรมกับ MCP ครบแล้ว Tim Berglund จึงข้ามมาอธิบายว่า Skill คืออะไรสำหรับคนที่ยังไม่คุ้น แก่นของ Skill คือไฟล์ markdown ไฟล์เดียว เป็นไฟล์ text ที่วางอยู่ในโฟลเดอร์สักที่ที่ agent มองเห็น ภายในไฟล์นั้นมีคำสั่งสำหรับ model เปรียบเหมือน prompt ที่ขยายออกมา พร้อมขั้นตอน คำแนะนำ และเงื่อนไขเฉพาะทางสำหรับทำอะไรสักอย่าง
Tim ยกตัวอย่างงานอย่างการช่วยหางาน การจัดสวนหน้าบ้าน หรือการแก้ไฟล์ Excel ซึ่งเป็นเรื่องที่ LLM พอจะลองทำเองได้อยู่แล้ว แต่ทำได้ไม่เก่งเท่าที่เราอยากให้เป็น สิ่งที่ Skill ทำคือบันทึกความชำนาญในเรื่องนั้นลงไปในไฟล์ เพื่อให้ model ทำงานได้ดีขึ้นในจุดที่มันเคยอ่อน
ใต้ไฟล์ SKILL.md ที่เป็น root ยังมีโฟลเดอร์ย่อยอะไรก็ได้ที่ไฟล์นี้อ้างถึง Tim ยกสองแบบที่พบบ่อย แบบแรกคือโฟลเดอร์ resources/ ซึ่งมักเป็นข้อมูลอ้างอิงนิ่ง เช่น Skill จัดสวนอาจมีข้อมูลภูมิอากาศ ข้อมูลพืช หรือโมเดล 3 มิติของต้นไม้ไว้ render บางอย่างอาจอยู่ใน weights ของ LLM อยู่แล้ว แต่การดึงมาวางไว้ข้างหน้าคือการบอกชัดๆ ว่าเรื่องนี้สำคัญและต้องรู้ แบบที่สองคือโฟลเดอร์ scripts/ ซึ่งเก็บ bash, Python หรือ executable ที่ไปลงมือทำอะไรสักอย่าง เช่น สคริปต์ Python ที่ใช้ API เข้าไปอ่านและแก้ row กับ cell ใน Excel ในแบบที่ model ทำเองได้ยาก
จุดที่ Tim ย้ำชัดคือ Skill เกิดมาเป็น plugin ของ Claude Desktop และ Claude Code มันคือไฟล์กับโครงต้นไม้ของโฟลเดอร์ จึงแจกผ่าน GitHub ได้ ใส่ไว้ใน repository ได้ แต่ Tim ยืนยันว่าคนไม่ได้เอา Skill ไป host บน cloud เพราะนั่นไม่ใช่แนวคิดของมัน Skill คือไฟล์ที่อยู่ในระบบไฟล์ตรงที่ agent มองเห็นเท่านั้น
คนละงานกัน อันหนึ่งอยู่ในเครื่อง อีกอันต่อออกไปข้างนอก
มาถึงหัวใจของคลิป Tim Berglund ชี้ว่าแม้ Skill กับ MCP จะมีคำเรียกบางอย่างคล้ายกัน แต่จริงๆ แล้วเป็นคนละเรื่อง วิธีแยกที่ดีที่สุดคือดูว่าแต่ละฝั่งทำงานอยู่ตรงไหน
เริ่มจากคำว่า resources ที่ทั้งคู่มีเหมือนกัน แต่เป็นคนละแบบ ตามที่ Tim อธิบาย resources ของ Skill คือข้อมูลอ้างอิงแบบนิ่ง ซึ่งอาจมีอยู่ใน weights ของ model อยู่แล้ว แต่ดึงออกมาบอกชัดๆ ว่าเรื่องนี้สำคัญและต้องรู้ ส่วน resources ของ MCP มักเป็นข้อมูลแบบสดและ real-time ไม่ว่าจะเป็น customer data, ticket ในระบบติดตาม หรือข้อมูลที่กำลังไหลเข้ามาจาก Kafka topic ตอนนี้เลย จึงสดและใหม่กว่าในเชิงเวลา
ถัดมาคือ scripts กับ tools ที่ Tim ยอมรับว่าแนวคิดคล้ายกัน จึงเข้าใจได้ว่าทำไมหลายคนคิดว่าเป็นอย่างเดียวกัน แต่ scripts ของ Skill โฟกัสที่ระบบไฟล์ในเครื่องเป็นหลัก จุดนี้สำคัญมากเมื่อดูว่า Claude Code และ coding agent ทำเรื่องใหญ่ในเครื่องได้แค่ไหนในตอนนี้ ส่วน tools ของ MCP มีไว้เปลี่ยนสถานะของสิ่งต่างๆ ในโลกภายนอก เช่นการ deploy resource ขึ้น cloud หรือการเปิด GitHub issue ซึ่งเป็นงานที่ต้อง auth กับ network resource บน cloud ไม่ใช่งานในเครื่อง
Tim สรุปเส้นแบ่งนี้ไว้ง่ายๆ ว่าแต่ละฝั่งทำงานกันคนละที่ ฝั่ง Skill ทำงานอยู่ในเครื่องของคุณ ส่วนฝั่ง MCP ต่อออกไปหาโลกภายนอก เมื่อจับแกนนี้ได้ ของที่ดูเหมือนซ้ำกันก็แยกออกจากกันชัดเจน เพราะมันทำกันคนละงานตั้งแต่แรก
จุดที่มันทับซ้อนกันจริงๆ และจุดที่ไม่ทับ
ส่วนที่ Tim Berglund บอกว่าน่าสนใจที่สุดคือจุดที่ Skill กับ MCP มาเจอกันจริงๆ เขาอธิบายว่าเรามี CLI ดีๆ อยู่ และมีสคริปต์ที่เรียก CLI นั้นได้ ขณะเดียวกัน CLI พวกนี้ก็ deploy ขึ้น cloud ได้ ที่สำคัญคือ CLI เหล่านี้มี authentication ที่ใช้งานได้จริง เพราะเมื่อ login เข้า cloud account แล้ว CLI จะมี token ของตัวเองและทำสิ่งที่ต้องการได้ทันที
เมื่อรวมทุกอย่างเข้าด้วยกัน สคริปต์ที่เรียก CLI จึงเริ่มดูเหมือนของแบบเดียวกับที่เราใช้ MCP server ทำ Tim บอกว่าในเคสของ local coding agent ซึ่ง ณ ตอนถ่ายคลิปคือเคสที่เจอบ่อยที่สุดแบบทิ้งห่าง การแทนกันแบบนี้สมเหตุสมผลมาก นี่เองคือเหตุผลที่ทำให้คนพูดกันว่า Skill มาแทน MCP
แต่ Tim ชี้ต่อทันทีว่าภาพจะเปลี่ยนไปเมื่อย้ายไปมองอีกฝั่ง ถ้าไม่ใช่ coding agent ที่ได้มาจาก foundation lab แต่เป็น agentic microservice ที่เขียนขึ้นเองและต้องเข้าถึงทั้ง tools กับ resources สคริปต์ CLI และ Skill ทั้งหลายก็ใช้ไม่ได้เลย เพราะงานแบบนี้ยังต้องการ interface มาตรฐานที่ MCP มีให้ สำหรับ agent ที่เราเขียนขึ้นเอง พูดอีกแบบคือจุดทับซ้อนเกิดเฉพาะตอนเป็น coding agent ในเครื่อง พอออกนอกกรอบนั้นไป MCP ก็กลับมาจำเป็นทันที
Tim เสริมด้วยว่าแม้แต่เส้นแบ่งนี้ก็ยังขยับ เพราะ ณ ตอนถ่ายคลิป มี Python API ที่ดึงเข้ามาเป็น dependency เพื่อ execute, เข้าถึง และ implement Skill ใน agent ที่เขียนเองได้ ของแบบนี้กำลังจะไหลจากฝั่ง coding agent มาสู่ agent ที่เราเขียนกันเอง แต่ Tim บอกตรงๆ ว่ายังไม่เห็นใช้แพร่หลายในโลกจริง และยังไม่แน่ใจว่าจะไปทางไหน จึงเป็นอีกเรื่องที่ต้องจับตา จุดนี้สำคัญสำหรับผู้อ่านไทย เพราะแปลว่าเส้นแบ่งที่อธิบายไว้คือภาพ ณ ต้นปี 2026 ไม่ใช่กฎตายตัวถาวร
สรุป เมื่อไหร่ใช้อะไร และทำไมคำตอบคือใช้ทั้งคู่
พอเห็นภาพครบทั้งสองฝั่งแล้ว เรื่องจะง่ายขึ้นถ้าเปลี่ยนคำถามจาก "เลือกอะไรดี" เป็น "งานตรงหน้าต้องการของฝั่งไหน" จากสิ่งที่ Tim Berglund วางไว้บน lightboard สรุปเป็นแนวทางตัดสินใจได้ดังนี้
| ถ้าคุณอยากให้ agent... | เลือกใช้ | เพราะ |
|---|---|---|
| รู้เรื่องเฉพาะทาง หรือทำตามขั้นตอนที่กำหนดไว้ | Skill | ความรู้นิ่ง + คำสั่งใน SKILL.md |
| อ่านหรือแก้ไฟล์ และรันสคริปต์ในเครื่อง | Skill | scripts/ โฟกัสระบบไฟล์ local |
| ต่อกับข้อมูลสด เช่น DB, ticket, Kafka, customer data | MCP | resources ของ MCP เป็น real-time |
| ลงมือทำในโลกภายนอก เช่น deploy หรือเปิด GitHub issue | MCP | tools ของ MCP + OAuth ต่อ cloud |
| เขียนหรือรัน agent เอง โดยเฉพาะ microservice บน cloud | MCP | ต้องการ interface มาตรฐาน |
| ทำงานกับ coding agent ในเครื่อง เช่น Claude Code | ทับกันได้ | สคริปต์ + CLI แทน MCP บางเคสได้ |
กฎจำง่ายที่ถอดจากคลิปคือ Skill ดึงความรู้และงานในเครื่องเข้ามา ส่วน MCP ต่อข้อมูลสดและการลงมือในโลกภายนอกออกไป งานจริงส่วนใหญ่มักใช้ทั้งคู่ ดังนั้นถ้าคุณกำลังลังเลว่าจะลงแรงเรียนอันไหนก่อน คำตอบจากคลิปคือไม่ต้องเลือก เพราะมันแก้คนละปัญหา
คำตัดสินสุดท้ายของ Tim ตรงไปตรงมา คือตอนนี้ต้องรู้และใช้ MCP อย่างไม่ต้องสงสัย และต้องรู้และใช้ Skills อย่างไม่ต้องสงสัยเช่นกัน เขาปิดท้ายด้วยมุมจากประสบการณ์ส่วนตัวว่า นี่คือ landscape ที่เปลี่ยนเร็วที่สุดที่เขาเคยเห็นในงานวิศวกรรมซอฟต์แวร์กว่า 30 ปี และยังมีอีกหลายอย่างให้จับตาว่ามันจะไปทางไหนต่อ สำหรับคนไทยที่ใช้ Claude Code หรือกำลังสร้าง agent ของตัวเอง ข้อสรุปจึงไม่ใช่การเชียร์ให้ทิ้งอันใดอันหนึ่ง แต่คือการเข้าใจว่าของสองอย่างนี้ทำกันคนละงาน แล้วหยิบมาใช้ให้ถูกกับงาน
ที่มา: Confluent Developer: Agent Skills or MCP in the era of Claude Code? โดย Tim Berglund (YouTube, อัปโหลด 10 มีนาคม 2026) · บทความนี้สรุปเนื้อหาทั้งหมดจากคลิปดังกล่าวเป็นภาษาไทย
