สร้างครั้งเดียวใช้ได้ทุกตัว: คู่มือการใช้ Agent Skills เพิ่มประสิทธิภาพ AI

ในหนึ่งสัปดาห์ คุณต้องอธิบายงานเดิมซ้ำๆ ให้เอเจนต์ฟังกี่รอบ? หรือต้องถามเพื่อนร่วมงานเกี่ยวกับวิธีแก้ปัญหาเฉพาะทางกี่ครั้ง? บริบทเหล่านี้ไม่ควรหายไปในแชทหรือถูกเก็บไว้ในหัวของใครคนใดคนหนึ่ง ทักษะเอเจนต์ (agent skills) จะช่วยคุณบันทึกคำแนะนำที่ทำซ้ำได้ เพื่อให้คุณและเอเจนต์นำกลับมาใช้ใหม่ได้ทันที และทักษะที่คุณเขียนขึ้นในคืนนี้ อาจกลายเป็นส่วนสำคัญในไปป์ไลน์ของทีมในอนาคต

ทักษะเอเจนต์คือไดเรกทอรีที่มีการคุมเวอร์ชัน (versioned directory) ซึ่งมีศูนย์กลางอยู่ที่ไฟล์ SKILL.md สำหรับระบุว่าควรทำภารกิจที่ทำซ้ำได้นั้นเมื่อใดและอย่างไร คุณสามารถแชร์คำแนะนำเหล่านี้ข้ามเอเจนต์ได้ แต่สภาพแวดล้อมยังคงต้องจัดเตรียมเครื่องมือ, ข้อมูลระบุตัวตน (credentials) และการอนุญาตสิทธิ์เพื่อดำเนินการ ตัวอย่างเช่น ทักษะสามารถอธิบายวิธีคิวรีฐานข้อมูลได้ แต่ตัวทักษะเองไม่ได้ให้สิทธิ์ในการเข้าถึงฐานข้อมูลนั้น

ผมได้พูดคุยในหัวข้อนี้ร่วมกับ Shishir Tewari ผู้จัดการอาวุโสด้าน Data Engineering ของ Procore ในงาน GitHub Universe 2026 เซสชันของเรามีชื่อว่า “Build once, run on any agent: a practical guide to agent skills”

นิยามหนึ่งงานและช่วงเวลาที่ต้องใช้

ทักษะจะทำงานได้ดีที่สุดเมื่อมีหน้าที่ อินพุต และเอาต์พุตที่ชัดเจน สมมติว่าคุณสร้างเอเจนต์เพื่อตรวจสอบการเปลี่ยนแปลงที่สร้างโดย AI หากเอเจนต์ตัวเดิมเป็นผู้ประเมินงานตัวเอง คำอธิบายของมันอาจมีอคติต่อการรีวิวได้ ใน Proof Agent เราจึงใช้ตัวตรวจสอบแยกต่างหากเพื่อพิจารณาการเปลี่ยนแปลงและจัดเตรียมหลักฐาน โดยกำหนดชื่อและวัตถุประสงค์ใน frontmatter ดังนี้:

---
name: proof-agent
description: Adversarial verification of AI-generated work. Spawns an independent verifier to check for false claims, broken code, and security issues.
---

หัวใจสำคัญคือกฎง่ายๆ ที่ว่า "การตรวจสอบตัวเองไม่ใช่การตรวจสอบ" (self-verification is not verification)

ส่วน When to Verify ใน SKILL.md ของ Proof Agent จะระบุเงื่อนไขการเรียกใช้ทักษะ ส่วนคำแนะนำที่เหลือจะอธิบายสิ่งที่ตัวตรวจสอบต้องรีวิวและหลักฐานที่ต้องระบุลงในผลลัพธ์

ประสานงานหลายทักษะเพื่อเวิร์กโฟลว์ที่ใหญ่ขึ้น

เมื่อการตัดสินใจในดาต้าไปป์ไลน์ถูกเก็บไว้ในหัวของคนเพียงไม่กี่คน ความคืบหน้าของโครงการก็จะขึ้นอยู่กับความว่างของคนกลุ่มนั้นเท่านั้น Data Forge จึงเป็นตัวอย่างของการบันทึกการตัดสินใจไว้ในทักษะที่ทำงานร่วมกัน

ใน ตัวอย่าง support-desk pipeline เริ่มต้นด้วยการนับจำนวนเหตุการณ์ที่เกิดขึ้น ทักษะ forge-init จะค้นหารายละเอียด เช่น ตารางต้นทางและรูปแบบการตั้งชื่อ แล้วบันทึกลงใน resolved manifest เพื่อให้ทักษะอื่นๆ อ่านบริบทไปใช้งานต่อได้

จากนั้นทักษะ forge-builder จะประสานงานตั้งแต่ขั้นตอน issue ไปจนถึง pull request โดยใช้ forge-dbx เพื่อคิวรีแพลตฟอร์มข้อมูล และใช้ forge-lint เพื่อปรับใช้มาตรฐานของทีมตลอดการออกแบบ โดยมีมนุษย์คอยรีวิวการตัดสินใจในทุกขั้นตอน ผลลัพธ์ที่ได้คือ pull request ที่ประกอบด้วยโค้ดไปป์ไลน์ การเปลี่ยนแปลง schema และการทดสอบที่สมบูรณ์

แต่ละทักษะมีความรับผิดชอบชัดเจนและแชร์บริบทร่วมกันได้ เมื่อขั้นตอนใดเปลี่ยนไป คุณเพียงแค่แก้ไขทักษะเดียวโดยไม่กระทบส่วนอื่น ทักษะจึงเหมาะกับงานที่มีขอบเขตชัดเจน เช่น checklist, การ release หรือการ migration หากเวิร์กโฟลว์ต้องการอินเทอร์เฟซที่ซับซ้อนหรือการควบคุมสิทธิ์นอกโมเดล การสร้างเป็นแอปพลิเคชันจะเหมาะสมกว่า

แยกการกำหนดค่าโปรเจกต์ออกจากทักษะ

เราไม่ควรฮาร์ดโค้ดรายละเอียดโปรเจกต์ลงในทักษะโดยตรง ในตัวอย่างของ Data Forge ไฟล์ manifest จะทำหน้าที่อธิบายโปรเจกต์และแพลตฟอร์ม เพื่อให้ทักษะดึงข้อมูลไปใช้ได้ถูกต้อง:

project:
  name: "support-desk"
  store_name: "support_metric_store"
 
platform:
  engine: "duckdb"
  pipeline_framework: "spark_python"
  duckdb_dir: "warehouse"

การแยกรายละเอียดโปรเจกต์ออกจากมาตรฐานของทีมเป็นเรื่องสำคัญ ทักษะ forge-init จะตรวจสอบ schema เดิม ส่วน forge-lint จะบังคับใช้กฎใหม่ การแยกส่วนเช่นนี้ช่วยให้คนสามารถรีวิวและตัดสินใจเชิงธุรกิจได้ง่ายขึ้น หากต้องการตรวจสอบความยืดหยุ่น (portability) ให้ลองถามว่าทีมอื่นสามารถนำทักษะเหล่านี้ไปใช้กับ manifest ของตัวเองได้ทันทีหรือไม่

แชร์เส้นทางการประมวลผลระหว่างทักษะ

ทักษะ forge-dbx ช่วยให้ทักษะอื่นๆ เข้าถึงแพลตฟอร์มข้อมูลผ่านช่องทางเดียว โดยจะเลือก adapter ที่เหมาะสม เช่น Databricks หรือ DuckDB ตามที่ระบุใน manifest ทำให้แต่ละทักษะไม่ต้องเขียนตรรกะการเชื่อมต่อซ้ำซ้อน

แม้ manifest จะเลือกใช้ DuckDB ได้ แต่ไม่สามารถติดตั้งซอฟต์แวร์หรือให้สิทธิ์เข้าถึงฐานข้อมูลโดยตรงได้ สิ่งเหล่านั้นยังคงเป็นหน้าที่ของสภาพแวดล้อมและผู้ใช้งาน โดย manifest ทำหน้าที่เป็นตัวเลือก engine ส่วนโฮสต์ทำหน้าที่ให้สิทธิ์การเข้าถึง

ใส่จุดตรวจสอบและการอนุมัติในเวิร์กโฟลว์

เวิร์กโฟลว์ของ Data Forge มีจุดตรวจสอบโดยมนุษย์ในทั้งเจ็ดขั้นตอน ภาพรวมของเวิร์กโฟลว์ แสดงให้เห็นว่าต้องมีการตรวจสอบความสำเร็จของขั้นตอนก่อนหน้า และต้องได้รับการอนุมัติก่อนเริ่มเปลี่ยนแปลง schema เสมอ

ใน Proof Agent ก็ใช้หลักการเดียวกันกับการรีวิวโค้ด โดยเวิร์กโฟลว์ GitHub Actions จะส่งคำขอต้นฉบับและการเปลี่ยนแปลงให้ตัวตรวจสอบพิจารณา และให้ผลลัพธ์เป็น PASS, FAIL หรือ PARTIAL พร้อมหลักฐาน โดยปกติแล้ว FAIL จะบล็อกการ merge หากกำหนดให้การเช็คนั้นจำเป็น จุดมุ่งหมายคือการใช้ CI checks และกฎของ repository ในการควบคุมคุณภาพขั้นสุดท้าย

แพ็คเกจสำหรับแต่ละไคลเอนต์และตรวจสอบการตั้งค่า เพื่อให้รองรับหลายไคลเอนต์ได้โดยไม่ต้องแก้ไขซ้ำซ้อน เราจะเก็บ skills/*/SKILL.md ไว้เป็นต้นฉบับและใช้สคริปต์แพ็คเกจเพื่อสร้างไฟล์เฉพาะสำหรับแต่ละแพลตฟอร์ม เช่น .claude-plugin/plugin.json สำหรับ Claude Code หรือ .github/agents/*.agent.md สำหรับ GitHub Copilot พร้อมมีโหมดตรวจสอบผ่าน CI:

node scripts/package.mjs --check
``` เนื่องจากไคลเอนต์แต่ละตัวมีความแตกต่างกัน ทั้งเรื่องโมเดลและสิทธิ์การเข้าถึง เมื่อติดตั้งทักษะแล้วควรตรวจสอบว่าไคลเอนต์รับรู้ทักษะที่ตั้งใจไว้หรือไม่ สามารถเรียกใช้เครื่องมือที่จำเป็นได้หรือไม่ และส่งคืนหลักฐานได้ถูกต้องตามที่กำหนดหรือไม่
 
## 3 แนวทางปฏิบัติในการสร้างทักษะเอเจนต์
 
1. **รวมบริบทธุรกิจไว้ที่เดียว:** เก็บข้อมูลเฉพาะของโปรเจกต์ไว้ใน manifest เพื่อให้ทุกทักษะอ่านจากจุดเดียว ช่วยให้อัปเดตการกำหนดค่าได้ง่ายและชัดเจน
2. **ใช้แพลตฟอร์มมาตรฐานเดียวกัน:** ให้ทักษะที่เกี่ยวข้องเข้าถึงข้อมูลผ่านช่องทางเดียวกันแทนการเขียนตรรกะเชื่อมต่อเอง เพื่อให้ง่ายต่อการตรวจสอบพฤติกรรมในแต่ละไคลเอนต์
3. **ใช้คำแนะนำนำทางและใช้การเช็คยืนยัน:** ใช้ทักษะบอกเอเจนต์ถึงมาตรฐานที่ต้องทำ แต่ให้ใช้การรีวิวโดยมนุษย์และการทดสอบ CI checks ในขั้นตอนสำคัญเพื่อดักจับปัญหาก่อน deployment
 
เริ่มต้นจากงานที่คุณเบื่อที่จะอธิบายซ้ำๆ เขียนความต้องการและผลลัพธ์ที่คาดหวัง จากนั้นลองนำไปใช้กับเอเจนต์ตัวต่างๆ เพื่อปรับปรุงให้สมบูรณ์ยิ่งขึ้น
 
[เพิ่มทักษะเอเจนต์ใน GitHub Copilot >](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/add-skills)