ทักษะเอเจนต์ (Agent Skills)

 (agentskills.io)
35 คะแนน โดย GN⁺ 2026-02-04 | 6 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทักษะเอเจนต์ คือ ฟอร์แมตแบบเปิด สำหรับเพิ่ม ความสามารถและความเชี่ยวชาญใหม่ ให้กับเอเจนต์ปัญญาประดิษฐ์
  • พัฒนาโดย Anthropic ก่อนเปิดเผยเป็น มาตรฐานเปิด และกำลังถูกรับไปใช้ในผลิตภัณฑ์เอเจนต์หลากหลายประเภท
  • ทักษะอยู่ในรูปแบบโฟลเดอร์ที่ประกอบด้วย คำสั่ง, สคริปต์, ทรัพยากร ซึ่งเอเจนต์สามารถสำรวจและใช้งานเพื่อทำงานได้อย่างแม่นยำและมีประสิทธิภาพมากขึ้น
  • รองรับ ความเชี่ยวชาญเฉพาะโดเมน, การขยายความสามารถใหม่, เวิร์กโฟลว์ที่ทำซ้ำได้, การทำงานร่วมกันได้
  • องค์กรและนักพัฒนาสามารถใช้สิ่งนี้เพื่อทำให้ การนำความรู้องค์กรกลับมาใช้ซ้ำและการทำงานอัตโนมัติของการเผยแพร่ใช้งาน เกิดขึ้นได้

ภาพรวม

  • Agent Skills เป็น รูปแบบที่เรียบง่ายและเปิดกว้าง สำหรับมอบ ความสามารถและความเชี่ยวชาญใหม่ ให้กับเอเจนต์
  • แต่ละทักษะประกอบด้วยโฟลเดอร์ที่มี คำสั่ง, สคริปต์, ทรัพยากร ซึ่งเอเจนต์สามารถโหลดมาใช้เพื่อเพิ่มความแม่นยำและประสิทธิภาพในการทำงาน

ทำไมต้อง Agent Skills

  • เอเจนต์มีความสามารถมากขึ้นเรื่อย ๆ แต่ยังมีปัญหาเรื่อง การขาดข้อมูลบริบท ที่จำเป็นต่อการทำงานจริงอย่างเสถียร
  • ทักษะช่วยให้สามารถโหลด ความรู้เชิงกระบวนการ และ บริบทเฉพาะขององค์กร, ทีม, ผู้ใช้ มาใช้ได้เมื่อต้องการ
  • เอเจนต์ที่มีทักษะสามารถขยายความสามารถได้ตามงานที่ได้รับ
  • ผู้สร้างทักษะ สามารถนำความสามารถที่สร้างครั้งเดียวไปเผยแพร่ให้กับผลิตภัณฑ์เอเจนต์หลายตัวได้
  • เอเจนต์ที่รองรับ ช่วยให้ผู้ใช้เพิ่มความสามารถใหม่ได้ทันที
  • ทีมและองค์กร สามารถเก็บรักษาความรู้ขององค์กรในรูปแบบ แพ็กเกจพกพาที่จัดการเวอร์ชันได้

สิ่งที่ทำได้ด้วย Agent Skills

  • ความเชี่ยวชาญเฉพาะโดเมน: แพ็กความรู้เฉพาะทาง เช่น การตรวจสอบด้านกฎหมาย การวิเคราะห์ข้อมูล เป็นชุดคำสั่งที่นำกลับมาใช้ซ้ำได้
  • ความสามารถใหม่: เพิ่มฟังก์ชันหลากหลาย เช่น การสร้างงานนำเสนอ การสร้างเซิร์ฟเวอร์ MCP การวิเคราะห์ชุดข้อมูล
  • เวิร์กโฟลว์ที่ทำซ้ำได้: เปลี่ยนงานหลายขั้นตอนให้เป็นกระบวนการที่สม่ำเสมอและตรวจสอบย้อนหลังได้
  • การทำงานร่วมกันได้: ใช้ทักษะเดียวกันซ้ำได้ในผลิตภัณฑ์เอเจนต์ที่รองรับหลายตัว

สถานะการนำไปใช้

  • Agent Skills ได้รับการรองรับใน เครื่องมือพัฒนา AI หลายตัว
  • ตัวอย่างเช่น Factory.ai, Gemini CLI, Mux, Ampcode, Letta, Autohand.ai, Spring AI, Goose, Piebald.ai, OpenAI Codex, Cursor, Databricks, Mistral Vibe, Roocode, VS Code, Agentman.ai, Trae.ai, Commandcode.ai, Firebender, Opencode.ai, Claude.ai และอื่น ๆ

การพัฒนาแบบเปิด

  • ฟอร์แมต Agent Skills ถูกพัฒนาขึ้นครั้งแรกโดย Anthropic และเปิดเผยเป็น มาตรฐานเปิด
  • หลังจากนั้นผลิตภัณฑ์เอเจนต์หลากหลายตัวได้นำไปใช้ และเปิดให้มี การมีส่วนร่วมจากทั้งอีโคซิสเต็ม
  • สามารถดูฟอร์แมตและตัวอย่างทักษะได้ผ่านคลัง GitHub

เริ่มต้นใช้งาน

  • สามารถเรียนรู้โครงสร้างและวิธีการทำงานของทักษะได้ที่หน้า “What are skills?”
  • สามารถดู ข้อกำหนดฟอร์แมตของไฟล์ SKILL.md ได้ที่ “Specification”
  • สามารถเพิ่มการรองรับทักษะให้กับเอเจนต์หรือเครื่องมือได้ผ่าน “Integrate skills”
  • สามารถสำรวจ ตัวอย่างทักษะ และ ไลบรารีอ้างอิง ได้บน GitHub

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

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

 
cgl00 2026-02-04

มีเรโปอย่างเป็นทางการของ anthropic อยู่แล้ว แล้วทำไมถึงมีโปรเจ็กต์แบบนี้จากฝั่ง third-party อีกล่ะครับ?
 
skageektp 2026-02-04

> Agent Skills เป็นฟอร์แมตแบบเปิดที่ดูแลโดย Anthropic และเปิดรับการมีส่วนร่วมจากชุมชน

สรุปว่ามาตรฐานนี้ Anthropic เป็นคนสร้างขึ้นสินะ
 
cgl00 2026-02-04

ที่นี่ก็เป็นของทางการเหมือนกันสินะ.. อันนี้กับ https://github.com/anthropics/skills น่าจะคนละอย่างกันใช่ไหม?
 
skageektp 2026-02-04

ใช่ครับ อันที่คุณส่งมานั่นคือ implementation
ส่วนที่แชร์ไว้ในเนื้อหาคือ spec

ประมาณว่า
มาตรฐานของอะไรอย่าง Docker = OCI
Docker, podman = container runtime ที่ implement OCI

(อาจจะผิดก็ได้นะครับ)
 
cgl00 2026-02-04

อ๋อ คือสเปกกับตัว implementation สินะครับ.. ขอบคุณครับ
 
GN⁺ 2026-02-04
ความคิดเห็นจาก Hacker News

  • การถกเถียงนี้เริ่มจากคำถามเรื่อง ความจำเป็นของการทำให้เป็นมาตรฐาน
    ฉันยังคิดว่าหัวใจของเอกสารที่ดีคือ “เขียนให้อ่านง่ายสำหรับคน” อยู่ดี เลยสงสัยว่าจำเป็นต้องบังคับใช้ฟอร์แมตใหม่จริงหรือไม่ ถ้าช่วยเพิ่มประสิทธิภาพได้จริง ก็น่าจะพิสูจน์ได้ด้วยการศึกษาเปรียบเทียบ

    • นอกจากที่คนอื่นพูดไปแล้ว ฉันมองว่าการทำให้เป็นมาตรฐานยังเปิดโอกาสให้นำไปใช้กับ การฝึกและ RL ได้ด้วย
    • มีการทดลองเปรียบเทียบจริง ๆ โดยพนักงานของ Hugging Face บอกว่าหลังจาก fine-tune โมเดล Qwen3-0.6B ด้วย codex + skills แล้ว คะแนน humaneval เพิ่มขึ้น +6 ลิงก์ที่เกี่ยวข้องอยู่ที่นี่ และโปรเจกต์คือ huggingface/upskill
    • ระบบนี้ไม่ใช่แค่เอกสารธรรมดา แต่สร้าง ดัชนีของ skills ทั้งหมด แล้วส่งให้ LLM ในทุกบทสนทนา วิธีนี้ทำให้ LLM อ่าน skill เฉพาะตอนที่จำเป็น เป็นแนวคิดคล้ายกับการค้นหาฟังก์ชันใน GUI ส่วนตัวฉันรู้สึกว่าโครงสร้างแบบ README เป็นศูนย์กลางเข้าใจง่ายกว่า
    • ฉันใช้ Claude Code ทำงานอัตโนมัติและเชื่อมแต่ละงานไว้เป็นคำสั่ง slash สุดท้ายแล้วก็รู้สึกว่า skills เป็นเพียงอีกรูปแบบหนึ่งของการทำเอกสาร ในระยะยาวฉันคิดว่ากระบวนทัศน์ของ skills อาจหายไปเมื่อ context window ขยายขึ้น และโมเดลฉลาดขึ้น
    • แต่ถ้ามองจากโมเดลปัจจุบัน Claude มักอ่านแค่คำอธิบาย skill แล้วหยุด จึงมี ผลในการประหยัดโทเคน สูงมาก ในรีโพขนาดใหญ่จะรู้สึกถึงความต่างได้จริง รูปแบบนี้จึงมีคุณค่าพอจะเผยแพร่ให้กว้างขึ้น

  • ทีมของเราประสบความสำเร็จโดยปฏิบัติกับ skills เหมือน ฟังก์ชันกึ่งกำหนดแน่นอนที่นำกลับมาใช้ซ้ำได้
    ตัวอย่างเช่น skill /create-new-endpoint จะรวม boilerplate ทั้งหมดไว้ เช่น การอัปเดต OpenAPI และการเพิ่ม integration test เมื่อกรอกหมายเลขตั๋ว JIRA ใน CLI แล้ว LLM จะทำงานเสร็จด้วยคุณภาพที่สม่ำเสมอ

    • มีคนถามว่า “แล้วจะทดสอบความสม่ำเสมอเมื่อเวลาผ่านไปได้อย่างไร”

  • มีข้อเสนอให้ทำโครงสร้างโฟลเดอร์ให้เป็นมาตรฐาน

    .claude/skills
.codex/skills
.opencode/skills
.github/skills
    • แม้ยังไม่ใช่มาตรฐาน แต่เครื่องมือ CLI ส่วนใหญ่จะสแกนไฟล์ .md แล้วนำไปใช้ ถึงอย่างนั้นก็น่าจะดีถ้ามี มาตรฐานแบบบูรณาการที่รวมถึงปลั๊กอิน ด้วย
    • มีคนบอกว่า Codex เริ่มก่อน แล้ว OpenCode ก็ตามมาติด ๆ ทวีตที่เกี่ยวข้อง
    • การถกเถียงนี้กำลังดำเนินอยู่ใน agentskills/agentskills#15 ด้วย
    • บางคนบอกว่า “ตอนนี้ยังเร็วเกินไป การทำให้เป็นมาตรฐานอาจไปจำกัดความคิดสร้างสรรค์”
    • อีกคนแย้งว่าควรใช้พาธแบบ ~/.config/claude ตาม XDG base spec มากกว่า ปัจจุบันวิธี ~/.claude ใช้งานไม่สะดวก

  • มีทิปให้สร้าง README.md ในแต่ละโฟลเดอร์ย่อยแล้ว ลิงก์ skill ที่เกี่ยวข้อง เข้าไว้ด้วย ซึ่งมีประโยชน์กับมนุษย์เช่นกัน บทความที่เกี่ยวข้องคือ Claude Skills Considered Harmful

    • มีความเห็นว่า “ท้ายที่สุดแล้ว skills ก็เป็นแค่ README สำหรับหัวข้อเฉพาะ” สิ่งที่ต้องอธิบายซ้ำ ๆ ก็จัดเป็น skill ได้ ไม่จำเป็นต้องตามโฟลเดอร์มาตรฐาน และถ้าจำเป็นก็ค่อยเพิ่มเข้า context โดยตรง
    • อีกคนบอกว่าถ้าใช้ ตัวรันคำสั่ง อย่าง just ก็จะเป็นประโยชน์ทั้งกับคนและเอเจนต์

  • ฉันพบว่าการมอง skills เป็น เวิร์กโฟลว์แบบชัดเจน ได้ผลมาก
    ถ้านิยามเป็นขั้นตอนที่ครบจบแบบ “ทำ X จากนั้นทำ Y แล้วตรวจสอบ Z” เอเจนต์จะรับรู้มันเป็นโหมดหนึ่งไปเลย ในทางกลับกัน ถ้าเป็นแนวทางกำกวมมักถูกมองข้ามได้ง่าย

    • มีคนบอกว่าตนเองนำ ระบบ hook มาใช้กับ Claude เพื่อเปิด skill อัตโนมัติในบางสถานการณ์ เช่น เมื่อจัดการไฟล์ Python ก็จะเรียก skill ที่เกี่ยวข้องขึ้นมาอัตโนมัติ
    • อีกคนชี้ว่าความต่างระหว่าง skill กับ command นั้นไม่ชัดเจน สุดท้ายถ้าทั้งคู่ถูกใช้งานเหมือนคำสั่ง ก็ยังต้องแยกกันจริงหรือ
    • บางคนบอกว่าโครงสร้างนี้คล้ายโน้ตใน Obsidian หรือชุดคำสั่ง CLI
    • อีกคนเน้นว่าต้อง ระบุเงื่อนไขการเปิดใช้งาน ของ skill ให้ชัดมาก ใน Claude Code สามารถเรียกแบบชัดแจ้งอย่าง /foo ได้ จึงชอบวิธีนั้นมากกว่า

  • มีคนมองว่า skills ช่วยทำให้ ความรู้เชิงโดเมนที่เคยซ่อนอยู่ ถูกบันทึกเป็นเอกสารได้ กฎที่เคยอยู่ในหัวนักพัฒนาจะถูกจดไว้และนำกลับไปใช้กับการฝึก LLM ได้อีก

  • มีคำถามว่า “ถ้าเอเจนต์ไม่ร้องขอ มันก็จะไม่ใช้ skills ใช่ไหม”

    • หลายคนก็เจอปัญหาเดียวกัน โมเดลปัจจุบันยังไม่ได้ผ่านการฝึก RLVR บนฐาน skills จึงสับสนอยู่ คาดว่าโมเดลรุ่นถัดไป เช่น Opus จะใช้ skills ได้เสถียรกว่ามาก
    • ในการประเมินของ Vercel ก็พบว่า 56% ของกรณีไม่มีการเรียกใช้ skill เลย แต่รายงานว่าแนวทาง AGENTS.md กลับได้ผลในขอบเขตที่กว้างกว่า บล็อกที่เกี่ยวข้อง
    • คนที่ใช้ Codex บอกว่าถ้าระบุไดเรกทอรี skill ไว้ใน AGENTS.md มันทำงานได้ดีพอสมควร แต่ยิ่งมี skills มาก โอกาสชนกันก็ยิ่งสูง จึงควรรักษาให้เรียบง่าย
    • อีกคนบอกว่าแทบใช้ skills ไม่สำเร็จเลย และการเอาเนื้อหา skill ไปใส่ใน AGENTS.md โดยตรงกลับแม่นยำกว่า

  • มีคนบอกว่า skill ที่ได้รับความนิยมอันดับสามบน skills.sh เป็นแค่ลิงก์ดาวน์โหลดคำสั่งธรรมดา ไฟล์อย่าง SKILLS.md/AGENTS.md/COMMANDS.md เหล่านี้สุดท้ายก็เป็นเพียง ชุดของพรอมป์ต์ และถ้าใช้ไม่ดีอาจอันตรายได้

    • แต่อีกคนก็ตอบว่า “ท้ายที่สุดแล้ว เครื่องมือสำคัญที่ การใช้อย่างมีความรับผิดชอบ”

  • คนที่กำลังพัฒนาภาษาโปรแกรมใหม่บอกว่าใช้ AGENTS.md และ SKILLS เพื่อช่วยให้ LLM เข้าใจภาษาที่มันยังไม่เคยฝึกมา และการทำให้เป็นมาตรฐานก็ช่วยให้รวมเข้ากับเครื่องมือต่าง ๆ ได้ง่ายขึ้น

  • คุณค่าที่แท้จริงไม่ได้อยู่ที่ฟอร์แมต แต่อยู่ที่ การเปิดเผยข้อมูลแบบค่อยเป็นค่อยไป (progressive disclosure)
    ถ้ายัดคำแนะนำทั้งหมดไว้ในเอกสารเดียว ก็จะเปลืองโทเคนโดยไม่จำเป็น รูปแบบ skills ช่วยให้เรียกอ่านรายละเอียดเฉพาะตอนจำเป็น ส่วนการทำให้เป็นมาตรฐานมีไว้เพื่อ การแจกจ่ายและการนำกลับมาใช้ซ้ำ เป็นหลัก

    • นักพัฒนาของโปรเจกต์ MOOLLM อธิบายว่าได้ขยายแนวคิดนี้ด้วยแนวคิด “Semantic Image Pyramid”
      ใช้การไล่ระดับรายละเอียดแบบค่อยเป็นค่อยไปตามลำดับ GLANCE.yml → CARD.yml → SKILL.md → README.md
      GLANCE ยาว 5~70 บรรทัด ใช้ตัดสินเพียงว่า “เกี่ยวข้องหรือไม่”, CARD ใช้นิยามอินเทอร์เฟซ, SKILL คือขั้นตอนจริง, และ README คือคำอธิบายสำหรับมนุษย์
      เขาบอกว่า INDEX.md มีอัตราการบีบอัดดีกว่า INDEX.yml มากกว่า 80% และยังให้ โครงสร้างเชิงบรรยาย ด้วย
      ลิงก์ที่เกี่ยวข้อง: INDEX.yml, INDEX.md
      นอกจากนี้ยังมีโครงสร้าง sniffable-python ที่ทำให้อ่านเพียง 50 บรรทัดแรกของโค้ดก็เข้าใจ API ได้
      เอกสารที่เกี่ยวข้อง: คำอธิบาย Semantic Image Pyramid, sister-script, sniffable-python README, sniffable-python SKILL