Skill ของ AI agent ทำงานได้จริง หรือแค่รู้สึกว่าดี? รู้จัก skill-up CLI ที่วัดผลให้เห็นเป็นตัวเลข

โดย Nokka (นก-กา) | ตรวจข้อมูล 24 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ใครที่เคยเขียน Skill ให้ AI agent สักตัวจะรู้จักความรู้สึกนี้ดี แก้คำสั่งใน SKILL.md อยู่สามรอบ ลองถาม agent แล้วคำตอบดูดีขึ้น เลยสรุปว่าเวอร์ชันใหม่ดีกว่า

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

skill-up คือ CLI ที่เกิดมาแก้จุดนี้โดยตรง มันรันชุดกรณีทดสอบกับ agent แล้วให้คะแนนทั้งคำตอบและการเปลี่ยนแปลงไฟล์ใน workspace พร้อมออกรายงานที่เอาไปใส่ CI ได้

repo นี้อยู่ใต้ org alibaba บน GitHub ใช้สัญญาอนุญาต Apache 2.0 ดาวประมาณ 1,279 ดวง ณ วันที่ผมตรวจ และออกรีลีสล่าสุด v0.14.0 เมื่อ 20 ต.ค. 2026 [1][5][6]

มันไม่ได้ทดสอบแค่ Skill แต่ทดสอบได้สามชั้น

แนวคิดเรื่อง behavioral evals มีคนเขียนไว้ก่อนแล้ว ทั้งคู่มือประเมิน Skill ของ agentskills.io [3] และบทความด้าน harness engineering ของ Google [4] ชื่ออาจทำให้คิดว่าเป็นเครื่องมือสำหรับ Skill อย่างเดียว แต่ README แยกงานที่มันทำเป็นสามแบบ ซึ่งใช้ชุดกรณีทดสอบเดียวกันได้ [1]

ทดสอบ Skill: ติดตั้ง Skill แล้ววัดพฤติกรรมข้ามเคส และเทียบผลระหว่าง "มี Skill" กับ "ไม่มี Skill" ได้
ทดสอบ Agent: รันเคสเดียวกันโดยไม่ติดตั้ง Skill เพื่อดูว่า engine หรือ agent ที่คุณต่อเองทำอะไรได้บ้าง
ทดสอบ Workspace: ดูว่า agent ทำงานกับไฟล์และ repo อย่างไร ใช้ fixture ของเคส หรือชี้ไปที่โฟลเดอร์งานจริงด้วย --workspace ก็ได้

ชั้นที่สามนี้สำคัญกับคนที่ทำงานกับ coding agent มาก เพราะสิ่งที่เราอยากรู้บ่อยที่สุดไม่ใช่ "agent ตอบเก่งไหม" แต่เป็น "มันแก้ไฟล์ถูกไหม แก้เกินขอบเขตหรือเปล่า"

วงจรที่มันพยายามปิด: พัง แก้ เพิ่มเคสกันถอย รันใหม่

แนวคิดทั้งหมดของเครื่องมือนี้สรุปได้ในสี่ขั้น คือ Fail, Fix, Regression Test, Re-run [1]

Fail: เจอเคสที่ agent ทำผิด แล้วเขียนมันลงเป็นกรณีทดสอบที่รันซ้ำได้
Fix: แก้ SKILL.md หรือไฟล์ประกอบ
Regression Test: เพิ่มเคสที่ล็อกพฤติกรรมอื่นไว้กันการถอยหลัง
Re-run: รันทั้งชุดใหม่ แล้วดูว่าปัญหาเดิมหายจริงและของเดิมไม่พัง

ลำดับนี้ฟังดูธรรมดา แต่มันเปลี่ยนธรรมชาติของงานเขียน Skill ไปเลย จากงานฝีมือที่ตัดสินด้วยสายตา เป็นงานวิศวกรรมที่มีตัวเลขกำกับ

หน้าตาของ eval จริง

ผมคัดโครงจากเอกสารเขียน eval ของโปรเจกต์มาให้ดูของจริง ไม่ใช่ของที่ผมแต่งขึ้น [2]

# evals/eval.yaml schema_version: v1alpha1 environment: type: none # none / docker / opensandbox engine: name: claude_code # หรือ codex / qodercli / qwen_code cases: files: - evals/cases/null-check.yaml parallelism: 2 retry_policy: max_retries: 1 retry_on: [timeout, error] benchmark: enabled: true # รันทั้งแบบมี Skill และไม่มี Skill report: formats: [json, html] # json / junit / html artifacts: [transcript]

ตัวเคสแยกเป็นไฟล์ของตัวเอง ชื่อไฟล์คือ id ของเคสโดยปริยาย

# evals/cases/null-check.yaml id: find-null-bug title: ต้องจับ null pointer ได้ input: prompt: | ตรวจ diff ปัจจุบันแล้วรายงานสิ่งที่พบ context: repo_fixture: evals/fixtures/repos/null-check-bug git: init: true checkout: main apply_diff: evals/fixtures/diffs/null-check.patch constraints: timeout_seconds: 180 max_turns: 8 expect: # เกตถูก ๆ ที่กรองก่อน must_contain: ["null", "bug"] must_not_contain: ["LGTM"] exit_code: 0 judge: # ให้คะแนนคุณภาพ type: rule_based success: - output_contains: all: ["null", "bug"] - exit_code: 0

จุดที่ผมชอบคือมันแยก เกต ออกจาก การให้คะแนน ชัดเจน expect เอาไว้กรองเคสที่พลาดแบบหยาบ ๆ ส่วน judge เอาไว้ตัดสินคุณภาพ ซึ่งประหยัดเงินได้มาก เพราะเคสที่ตกเกตไม่ต้องเสียเงินเรียกโมเดลมาตรวจ

สามวิธีตัดสิน และเหตุผลที่คนมักเลือกผิด

judge รองรับสามแบบ [1][2]

rule_based: ตรวจเงื่อนไขจากคำตอบและ exit code ถูกและเร็วที่สุด แต่เปราะถ้อยคำ
script: เรียกสคริปต์ของเราเอง ตรวจไฟล์ใน workspace ได้ ยืดหยุ่นที่สุดแต่ต้องเขียนเอง
agent_judge: ให้โมเดลอีกตัวตัดสิน ใช้เมื่อคำตอบเป็นงานเขียนหรือการตัดสินเชิงคุณภาพ

หลายคนเริ่มจาก agent_judge เพราะรู้สึกว่าฉลาดกว่า แต่ในมุมมองของผม ตัว judge ที่ดีที่สุดคือตัวที่แพงน้อยที่สุดที่ยังจับความผิดได้ สคริปต์ตรวจไฟล์มักชนะการให้โมเดลอ่านคำตอบ เพราะมันดูของจริงใน workspace ไม่ใช่ดูคำพูดว่าได้ทำแล้ว

เทียบมี Skill กับไม่มี Skill คือหัวใจของการวัด

ถ้าเปิด benchmark.enabled: true เครื่องมือจะรันทั้งแบบติดตั้ง Skill และไม่ติดตั้ง แล้วเทียบให้ [1]

ตรงนี้คือสิ่งที่ทำให้คำถาม "Skill นี้ช่วยจริงไหม" มีคำตอบเป็นตัวเลข แทนที่จะเป็นความเชื่อ

และมันยังใช้ตอบคำถามตรงข้ามได้ด้วย คือ Skill ที่เขียนมาอาจไม่ได้ช่วยอะไรเลย หรือแย่ลงด้วยซ้ำ ถ้ามันไปแย่งบริบทของ agent

สภาพแวดล้อมและ engine ที่รองรับ

สภาพแวดล้อมมีสามแบบ คือ none (รันบนเครื่องตรง ๆ), docker, และ opensandbox [1][2]
engine ที่มี adapter ในโค้ดมีห้าตัว คือ claude_code, codex, opencode, qodercli, qwen_code และต่อ engine ของตัวเองได้ผ่าน engine.custom [1][2] ส่วน README นับ built-in ไม่ตรงกันเอง (บางจุดนับสาม อีกจุดนับสี่) [1]
รองรับ MCP server ทั้งแบบของจริงและแบบ mock ต่อเคส [1][2]
นำเข้า evals.json แบบที่ Anthropic ใช้ได้ด้วยคำสั่ง skill-up import [1]

ข้อสุดท้ายนี้มีประโยชน์กับคนที่มีชุดทดสอบอยู่แล้ว ไม่ต้องเขียนใหม่ทั้งหมด

รายงานที่ได้ เอาเข้า CI ได้ทันที

คำสั่งหลักมีไม่กี่ตัว คือ run, validate, list-cases, report, import และ debug [1]

ผลลัพธ์ออกได้หลายแบบ ทั้ง result.json, JUnit XML สำหรับ CI, HTML สำหรับอ่านคนเดียว และไฟล์รูปแบบที่เข้ากับของ Anthropic อย่าง grading.json กับ benchmark.json [1]

มี GitHub Action ให้ใช้ด้วย โดยเป็น Docker container action ที่รันได้เฉพาะ Linux และต้องเก็บ credential ของโมเดลไว้เป็น secret ของ repo [1]

จุดที่ผมอยากเตือนคือ เวอร์ชัน CLI ที่ฝังใน image ของ Action ถูก pin ไว้ ไม่ได้ตาม latest และการออกรีลีส CLI ใหม่ไม่ได้อัปเดต image ให้อัตโนมัติ [1] แปลว่าถ้าคุณอยากได้ฟีเจอร์ใหม่ ต้องรอผู้ดูแลโปรเจกต์อัปเดต image หรือสร้างเอง

skill-upper: ให้ agent เขียนชุดทดสอบให้เรา

โปรเจกต์นี้แถม Skill ชื่อ skill-upper มาด้วย ติดตั้งผ่าน npx skills add แล้วสั่งเป็นภาษาคนได้เลย [1]

มันจะอ่าน SKILL.md ของคุณ หาพฤติกรรมสำคัญ เขียนเคสและ judge ให้ รัน skill-up แล้วสรุปว่าเคสไหนพังหนักที่สุด

จากนั้นเราเดินวงจรต่อในบทสนทนาเดิม คือให้มันดูผลล่าสุด แยกว่า Skill ผิดหรือเคสผิด แก้ แล้วเพิ่มเคสกันถอย

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

ทางป้องกันง่าย ๆ คือเขียนเคสสำคัญด้วยมือก่อนสักสองสามข้อ แล้วให้ skill-upper เติมส่วนที่เหลือ

ข้อจำกัดที่ควรรู้ก่อนติดตั้ง

ผมไล่เอกสารแล้วเจอหลายจุดที่ควรบอกก่อนใครจะลอง

ต้องใช้ Go 1.26 ขึ้นไป ถ้าจะ build เอง (ไฟล์ go.mod ของ repo ระบุ go 1.26.0) [1]
Windows มีข้อจำกัด เอกสารแยกหน้าไว้ต่างหาก [1]
Action รันได้เฉพาะ Linux เพราะเป็น container action [1]
เอกสารในโปรเจกต์ไม่ตรงกันเอง หน้า writing-evals มีหัวข้อ OpenCode engine เต็ม ๆ และใช้ engine: opencode ในตัวอย่าง แต่ README นับ engine ในตัวไว้สามหรือสี่ตัวแล้วแต่บรรทัด [1][2] ผมถือว่านี่คือสัญญาณว่าโปรเจกต์ยังขยับเร็ว และควรอ่านทั้ง README กับเอกสารประกอบกัน
ขนาดชุมชนยังเล็ก 1,279 ดาว กับ 22 issue ที่เปิดอยู่ [5] ไม่ได้แปลว่าไม่ดี แต่แปลว่าคุณอาจเป็นคนแรกที่เจอบั๊กบางอย่าง

ใครควรใช้ และใครยังไม่ต้อง

ผมจะบอกแบบตรง ๆ ครับ

ควรใช้ถ้า คุณดูแล Skill หรือ agent ที่คนอื่นใช้ด้วย, มีเคสที่เคยพังซ้ำ ๆ, หรือทำงานในทีมที่ต้องอธิบายว่าทำไมเวอร์ชันใหม่ถึงดีกว่าเวอร์ชันเก่า

ยังไม่ต้องถ้า คุณเพิ่งเขียน Skill แรกเสร็จหนึ่งอัน และยังไม่รู้ว่ามันควรทำอะไรได้บ้าง ในขั้นนั้นการนั่งอ่านผลลัพธ์เองสิบเคสยังมีค่ากว่าการสร้างระบบวัด

เพราะเครื่องมือวัดไม่ได้บอกว่าอะไรสำคัญ มันบอกแค่ว่าอะไรเปลี่ยน