ช่วงนี้คำว่า Agent Skills (ชุดความรู้แพ็คสำเร็จให้ AI) อยู่ทุกที่ จนหลายคนเริ่มถามว่านี่คือจุดจบของ MCP (มาตรฐานที่ต่อ AI เข้ากับเครื่องมือและข้อมูลภายนอก) แล้วจริงแค่ไหน? ในคลิป Agent Skills or MCP in the era of Claude Code? จาก ช่อง Confluent Developer Tim Berglund ขึ้น lightboard มาตอบคำถามนี้แบบไม่เข้าข้างฝ่ายใด คำตอบสั้นๆ คือ Skills ไม่ได้มาฆ่า MCP เพราะทั้งคู่ทำกันคนละงาน ฝั่งหนึ่งทำงานอยู่ในเครื่อง อีกฝั่งต่อออกไปหาโลกภายนอก บทความนี้สรุปเนื้อหาทั้งคลิปเป็นภาษาไทย พร้อมตารางช่วยตัดสินใจว่างานแบบไหนควรเลือกอะไร

MCP คืออะไรแบบเร็วๆ

ก่อนจะตัดสินว่า Skills มาแทนได้ไหม Tim ขอย้อนทบทวน MCP ก่อนว่าภาพรวมมันทำงานอย่างไร จุดตั้งต้นคือมี agent (ตัวช่วยอัตโนมัติที่ทำงานแทนคน) ตัวหนึ่ง ซึ่งอาจรันอยู่บน laptop หรือเป็น microservice บน cloud ก็ได้ เมื่อผู้ใช้ส่ง prompt (คำสั่งที่พิมพ์เข้าไป) เข้ามา agent จะเรียก LLM ขึ้นมาคิดว่าควรทำอะไรต่อ

ปัญหาอยู่ที่ตัว LLM เอง 2 ข้อ ข้อแรกคือมันรู้แค่สิ่งที่อ่านมาจากอินเทอร์เน็ต จึงไม่รู้อะไรเลยเกี่ยวกับเรื่องภายในบริษัท ทั้ง support ticket หน้า wiki หรือ Google Docs ขององค์กร ข้อสองคือมันลงมือทำอะไรเองไม่ได้ ตอบกลับมาได้แค่ text ทั้งที่งานจริงต้องการ agent ที่ลงมือทำแล้วเกิดผลในโลกจริง

ของที่มาเติมช่องว่างสองข้อนี้คือ tools (การกระทำที่ทำให้เกิดผลจริง) กับ resources (เอกสารและข้อมูลภายในบริษัท) แต่ API ที่ใช้เข้าถึงของพวกนี้เป็นอะไรก็ได้ ไม่มีใครรู้ล่วงหน้าว่าแต่ละที่ทำไว้แบบไหน MCP server จึงเข้ามายืนคั่นกลาง หน้าที่ของมันคือ implement API ที่ไปเรียก tools รู้วิธีเข้าถึง resources แล้วยื่น interface มาตรฐานชุดเดียวให้ agent พร้อมประกาศความสามารถของตัวเองให้ agent รับรู้ ผลคือ MCP server กลายเป็นชิ้นส่วนแบบเสียบปลั๊ก แค่ชี้ agent ไปที่ server ตัวนั้น agent ก็เรียนรู้ที่จะทำทุกอย่างได้เอง ซึ่ง Tim มองว่ากลไกนี้ทรงพลังและทำงานได้ดีมาก

ในรอบ 9 ถึง 12 เดือน MCP เปลี่ยนไป 3 อย่าง

ตั้งแต่คลิปก่อนของเขาจนถึงตอนถ่ายคลิปนี้ ราว 9 ถึง 12 เดือน Tim ชี้ว่า MCP มีของใหม่ที่น่าสนใจ 3 อย่าง

เรื่องแรกคือ Resource API แทบไม่มีคนใช้แล้ว Tim สังเกตว่าถ้าไปเปิด docs ของ MCP server ที่ใช้งานจริง ทั้งแบบ cloud และแบบ open source ที่รันในเครื่อง จะเห็นการใช้ Resource API น้อยมาก เพราะ Tools API ทำงานเดียวกันได้เลย การ query resource หนึ่งครั้งก็เหมือนการเรียก tool ครั้งหนึ่ง คล้ายการเรียก method ทั่วไปที่ส่ง parameter เข้าไปแล้วได้ของกลับมา โดยแทบไม่มีผลเสีย ในมุมของเขา นี่เป็นบทเรียนที่น่าสนใจเรื่องความยากของการออกแบบ API เพราะของที่ออกแบบมา ไม่ได้ถูกใช้อย่างที่ตั้งใจไว้เสมอ สุดท้ายชุมชนก็เลือกทางที่ตัวเองถนัด

เรื่องที่สองคือการรองรับ streamable HTTP ก่อนหน้านี้ MCP รองรับแค่ server-sent events (SSE) ซึ่งจัดการ networking ได้ยากเวลา MCP server ไม่ได้รันในเครื่องแต่ไปอยู่บน cloud การเพิ่ม streamable HTTP เข้ามาจึงสะอาดกว่าและ deploy ง่ายกว่าในแง่โครงสร้างพื้นฐาน เป็นการเปลี่ยนแปลงที่ดีขึ้นชัดเจน

เรื่องที่สามคือการรองรับ OAuth 2.1 ซึ่ง authentication เป็นจุดเจ็บของ spec เวอร์ชันแรกอย่างไม่ต้องสงสัย เมื่อก่อนถ้ามี secret ที่ MCP server ต้องใช้ ตัว server เองต้องรู้ secret นั้น โดยเก็บไว้ใน environment variable หรือทำ secret management เองเพื่อ auth กับ backend วิธีนี้พอใช้ได้ในบางงาน แต่ติดทันทีเมื่อ MCP server ต้องต่อกับบริการอย่าง GitHub เพราะสิ่งที่ผู้ใช้อยากได้คือ OAuth pop-up หน้าบ้านตามปกติ แบบที่ขึ้นว่าแอปนี้ขอเข้าถึงบัญชี GitHub เห็นโปรไฟล์และเปิด issue ได้ แล้วกดอนุญาต OAuth 2.1 จึงออกแบบมาเพื่อรองรับเคสที่ agent รันอยู่ในเครื่อง โดยให้มี server กลางบน cloud คอยขอ OAuth ไปยัง backend อะไรก็ได้

Tim ตั้งข้อสังเกตว่า ณ ตอนถ่ายคลิป เคส agent รันในเครื่องแบบนี้คือ majority report หรือสิ่งที่เจอบ่อยที่สุดแบบทิ้งห่าง นักพัฒนาที่เคยรัน Claude Code บน laptop ก็น่าจะเคยเห็น pop-up นี้แล้ว แต่ถ้าเป็น agentic microservice ที่รันแบบ headless บน cloud OAuth แบบนี้ยังทำงานได้ไม่ดีนัก จึงมีคำสัญญาว่าจะมีทางออกที่ดีกว่าสำหรับเคสนั้น ซึ่งเป็นเคสที่เขาคาดว่าจะพบมากขึ้นเรื่อยๆ

แล้ว Skill คืออะไร

ฝั่ง Skill นั้น Tim อธิบายว่าแก่นของมันคือไฟล์ markdown ไฟล์เดียว เป็นไฟล์ text ที่วางอยู่ในโฟลเดอร์สักที่ที่ agent มองเห็น ภายในไฟล์มีคำสั่งสำหรับ model เปรียบเหมือน prompt ที่ขยายออกมา พร้อมขั้นตอน คำแนะนำ และเงื่อนไขเฉพาะทางสำหรับทำงานอย่างใดอย่างหนึ่ง

ตัวอย่างงานที่ LLM พอจะทำเองได้อยู่แล้วแต่ยังไม่เก่งนัก เช่น ช่วยหางาน จัดสวนหน้าบ้าน หรือแก้ไฟล์ Excel สิ่งที่ Skill ทำคือบันทึกความชำนาญในเรื่องนั้นลงไปในไฟล์ เพื่อให้ model ทำงานได้ดีขึ้นในจุดที่เคยอ่อน

ใต้ไฟล์ SKILL.md ที่เป็น root ยังมีโฟลเดอร์ย่อยที่ไฟล์นี้อ้างถึงได้ สองแบบที่พบบ่อยคือ 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 ได้ แต่คนไม่ได้เอา Skill ไป host บน cloud เพราะนั่นไม่ใช่แนวคิดของมัน Skill คือไฟล์ที่อยู่ในระบบไฟล์ตรงที่ agent มองเห็นเท่านั้น

คนละงานกัน อันหนึ่งอยู่ในเครื่อง อีกอันต่อออกไปข้างนอก

หัวใจของคลิปอยู่ตรงนี้ Tim ชี้ว่าแม้ Skill กับ MCP จะมีคำเรียกบางอย่างคล้ายกัน แต่จริงๆ แล้วเป็นคนละเรื่อง วิธีแยกที่ชัดที่สุดคือดูว่าแต่ละฝั่งทำงานอยู่ตรงไหน

เริ่มจากคำว่า resources ที่ทั้งคู่มีเหมือนกันแต่เป็นคนละแบบ resources ของ Skill คือข้อมูลอ้างอิงแบบนิ่ง ซึ่งอาจมีอยู่ใน weights ของ model อยู่แล้ว แต่ดึงออกมาเน้นว่าเรื่องนี้สำคัญและต้องรู้ ส่วน resources ของ MCP มักเป็นข้อมูลแบบสดและ real-time ทั้ง customer data, ticket ในระบบติดตาม หรือข้อมูลที่กำลังไหลเข้ามาจาก Kafka topic ตอนนั้นเลย จึงสดและใหม่กว่าในเชิงเวลา

ถัดมาคือ scripts กับ tools ที่แนวคิดคล้ายกันจนเข้าใจได้ว่าทำไมหลายคนคิดว่าเป็นอย่างเดียวกัน แต่ scripts ของ Skill โฟกัสที่ระบบไฟล์ในเครื่องเป็นหลัก ซึ่งสำคัญมากเมื่อดูว่า Claude Code และ coding agent ทำงานใหญ่ในเครื่องได้แค่ไหนในตอนนี้ ส่วน tools ของ MCP มีไว้เปลี่ยนสถานะของสิ่งต่างๆ ในโลกภายนอก เช่น deploy resource ขึ้น cloud หรือเปิด GitHub issue ซึ่งเป็นงานที่ต้อง auth กับ network บน cloud ไม่ใช่งานในเครื่อง

Tim สรุปเส้นแบ่งนี้ไว้ง่ายๆ ว่าแต่ละฝั่งทำงานกันคนละที่ ฝั่ง Skill ทำงานอยู่ในเครื่องของผู้ใช้ ส่วนฝั่ง MCP ต่อออกไปหาโลกภายนอก เมื่อจับแกนนี้ได้ ของที่ดูเหมือนซ้ำกันก็แยกออกจากกันชัดเจน เพราะมันทำกันคนละงานตั้งแต่แรก

จุดที่มันทับซ้อนกันจริงๆ และจุดที่ไม่ทับ

จุดที่ Tim บอกว่าน่าสนใจที่สุดคือตรงที่ Skill กับ MCP มาเจอกันจริงๆ ภาพคือเรามี CLI ดีๆ อยู่แล้ว และมีสคริปต์ที่เรียก CLI เหล่านั้นได้ ขณะเดียวกัน CLI พวกนี้ก็ deploy ขึ้น cloud ได้ และมี authentication ที่ใช้งานได้จริง เพราะเมื่อ login เข้า cloud account แล้ว CLI จะถือ token ของตัวเองและทำสิ่งที่ต้องการได้ทันที เมื่อรวมทุกอย่างเข้าด้วยกัน สคริปต์ที่เรียก CLI จึงเริ่มดูเหมือนของแบบเดียวกับที่ MCP server เคยทำ

ในเคสของ local coding agent ซึ่ง Tim ระบุว่า ณ ตอนถ่ายคลิปคือเคสที่เจอบ่อยที่สุดแบบทิ้งห่าง การแทนกันแบบนี้สมเหตุสมผลมาก นี่เองคือเหตุผลที่ทำให้คนพูดกันว่า Skill มาแทน MCP

แต่ภาพจะเปลี่ยนทันทีเมื่อย้ายไปมองอีกฝั่ง ถ้าไม่ใช่ 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 ที่เขียนกันเอง แต่เขาบอกตรงๆ ว่ายังไม่เห็นใช้แพร่หลายในโลกจริง และยังไม่แน่ใจว่าจะไปทางไหน จึงเป็นอีกเรื่องที่ต้องจับตา จุดนี้สำคัญสำหรับผู้อ่าน เพราะแปลว่าเส้นแบ่งที่อธิบายมาทั้งหมดคือภาพ ณ ต้นปี 2026 ไม่ใช่กฎตายตัวถาวร

สรุป เมื่อไหร่ใช้อะไร และทำไมคำตอบคือใช้ทั้งคู่

เมื่อเห็นภาพครบทั้งสองฝั่งแล้ว เรื่องจะง่ายขึ้นถ้าเปลี่ยนคำถามจาก "เลือกอะไรดี" เป็น "งานตรงหน้าต้องการของฝั่งไหน" จากสิ่งที่ Tim วางไว้บน lightboard สรุปเป็นแนวทางตัดสินใจได้ดังนี้

กฎจำง่ายคือ Skill ดึงความรู้และงานในเครื่องเข้ามา ส่วน MCP ต่อข้อมูลสดและการลงมือในโลกภายนอกออกไป และงานจริงส่วนใหญ่มักใช้ทั้งคู่ ดังนั้นถ้ายังลังเลว่าจะลงแรงเรียนอันไหนก่อน คำตอบจากคลิปคือไม่ต้องเลือก เพราะมันแก้คนละปัญหา

คำตัดสินสุดท้ายของ Tim ตรงไปตรงมา คือตอนนี้ต้องรู้และใช้ MCP อย่างไม่ต้องสงสัย และต้องรู้และใช้ Skills อย่างไม่ต้องสงสัยเช่นกัน เขาปิดท้ายด้วยมุมจากประสบการณ์ส่วนตัวว่า นี่คือ landscape ที่เปลี่ยนเร็วที่สุดที่เขาเคยเห็นในงานวิศวกรรมซอฟต์แวร์กว่า 30 ปี และยังมีอีกหลายอย่างให้จับตาว่าจะไปทางไหนต่อ สำหรับนักพัฒนาและคนที่ใช้ Claude Code หรือกำลังสร้าง agent ของตัวเอง ข้อสรุปจึงไม่ใช่การเชียร์ให้ทิ้งอันใดอันหนึ่ง แต่คือการเข้าใจว่าของสองอย่างนี้ทำกันคนละงาน แล้วหยิบมาใช้ให้ถูกกับงาน