ผลการตรวจสอบ (audit) ล่าสุดของ "ทักษะ" (skills) ของ AI agent ที่เปิดเผยต่อสาธารณะจำนวน 2,465 รายการ พบว่ามากกว่าครึ่งหนึ่งไม่เป็นไปตามข้อกำหนด (specification) ที่ประกาศไว้ และ 7.8 เปอร์เซ็นต์ไม่สามารถถูกเลือกโดย agent ได้เลยเนื่องจากขาด metadata ที่จำเป็น ข้อบกพร่องเหล่านี้คุกคามความน่าเชื่อถือของระบบใดๆ ที่ทำการค้นหาและโหลดทักษะเหล่านี้โดยอัตโนมัติ
ทำไมการตรวจสอบนี้จึงสำคัญ
เรจิสทรีสำหรับทักษะของ agent (Agent-skill registries) ช่วยให้นักพัฒนาสามารถเผยแพร่ความสามารถที่นำกลับมาใช้ใหม่ได้ ซึ่งก็คือแพ็กเกจโค้ดที่ autonomous agent สามารถเรียกใช้งานได้ตามต้องการ Agent จะสแกนเรจิสทรี อ่าน YAML frontmatter ของแต่ละทักษะ (บล็อกข้อความที่มีโครงสร้างขนาดเล็กซึ่งต้องมีอย่างน้อยชื่อและคำอธิบาย) และตัดสินใจว่าทักษะนั้นตรงกับเป้าหมายของมันหรือไม่ หาก frontmatter หายไปหรือรูปแบบผิดพลาด ทักษะนั้นจะหายไปจากเมนูของ agent ในโลกที่ autonomous agent ทำหน้าที่นัดหมายการประชุม แก้ไขปัญหาเซิร์ฟเวอร์ และอื่นๆ ทักษะที่ทำงานผิดพลาดจะทำให้เวิร์กโฟลว์ (workflow) พังลง
ตัวเลขเหล่านี้บ่งบอกอะไร
- 57.8% ของทักษะมีการละเมิดข้อกำหนดอย่างน้อยหนึ่งอย่าง
- 29.2% ระบุชื่อที่ไม่ตรงกับ registry slug (ตัวระบุ URL)
- 18.1% มีเส้นทางแพ็กเกจ (package paths) ที่เสียหรือลิงก์ที่ใช้งานไม่ได้
- 7.8% (192 ทักษะ) ไม่มี YAML frontmatter เลย ทำให้ไม่มีทั้งชื่อและคำอธิบาย
- 3.8% ฝัง absolute file paths ที่มีอยู่เฉพาะในเครื่องของผู้เขียนเท่านั้น
- 2.4% ใช้ฟิลด์
allowed-toolsผิดวิธี ทำให้ agent อ่านไม่ได้ - 2.1% เปิดเผย API keys ผ่าน environment variables ซึ่งเป็นสัญญาณอันตรายด้านความปลอดภัย
- 1.3% เรียกใช้เครื่องมือ command-line ภายนอกโดยไม่ได้ประกาศไว้ ซึ่งเป็นการละเมิดกฎเรื่อง portability (ความสามารถในการใช้งานข้ามระบบ)
Portability เป็นปัญหาที่พบได้บ่อยที่สุด เส้นทางแบบ absolute เช่น /home/USER/.local/bin/tool อาจใช้งานได้สำหรับนักพัฒนาที่เขียนทักษะนั้น แต่จะล้มเหลวสำหรับผู้ใช้คนอื่นๆ ทั้งหมด ทำให้เกิด runtime errors ที่การตรวจสอบแบบ static (static checks) ไม่สามารถตรวจพบได้
เจาะลึกกรณีของ openclaw
การตรวจสอบยังได้ตรวจสอบทักษะ 46 รายการที่รวมอยู่ใน openclaw repository หลังจากปรับปรุงสคริปต์การทดสอบเพื่อลดการแจ้งเตือนที่ผิดพลาด (false alarms) ผู้ตรวจสอบพบ ข้อบกพร่องที่แท้จริง 59 รายการ ซึ่งเป็นเครื่องเตือนใจว่า linter ที่เข้มงวดเกินไปอาจส่งผลเสียได้ เมื่อเครื่องมือแจ้งเตือนปัญหาที่ไม่มีอันตรายมากเกินไป นักพัฒนาจะเลิกใช้งานมัน และปัญหาที่แท้จริงก็จะหลุดรอดไป
ข้อบกพร่องสองรายการของ openclaw ชี้ไปยังไฟล์ที่ไม่มีอยู่ใน repository อีกต่อไป ผู้ดูแล (maintainer) ได้รวมการแก้ไข (merge a fix) เพื่อคืนค่าการอ้างอิงที่หายไป แสดงให้เห็นว่า pull request เพียงรายการเดียวสามารถจัดการกับสายโซ่ของ dependency ที่เสียได้
ปฏิกิริยาจากนักพัฒนา
ผู้ตรวจสอบได้เปิด issue ใน repository ของทักษะต้นฉบับ รายงานหนึ่งถูกปฏิเสธ โดยผู้ดูแลโต้แย้งว่า "ความเสีย" (broken) ควรตัดสินจากพฤติกรรมการทำงานจริง (runtime behavior) ไม่ใช่จากการตรวจสอบไฟล์แบบ static ผู้ตรวจสอบเห็นด้วยว่านิยามที่เข้มงวดของคำว่า "เสีย" ต้องสอดคล้องกับวิธีที่ทักษะนั้นทำงานในทางปฏิบัติ ส่วนอีก issue หนึ่งได้รับการยอมรับ และการแก้ไขที่เกี่ยวข้องก็ได้เปิดใช้งานแล้ว
ใครจะได้ประโยชน์—หรือเสียประโยชน์
- Agents และผู้ใช้งานปลายทาง จะได้รับประสบการณ์ที่ราบรื่นและคาดเดาได้มากขึ้น เมื่อเรจิสทรีมีเพียงทักษะที่ถูกต้องตามข้อกำหนดและมีความสามารถในการใช้งานข้ามระบบ (portable)
- ผู้เขียนทักษะ (Skill authors) จะได้รับกฎการตรวจสอบที่ชัดเจนขึ้น ซึ่งช่วยตรวจจับข้อผิดพลาดก่อนการเผยแพร่ ลดการโต้ตอบไปมาในการจัดการ issue
- ผู้ดูแลเรจิสทรี (Registry operators) ต้องสร้างหรือรวม pipeline การตรวจสอบที่เข้มงวดขึ้น หากไม่มีสิ่งนี้ ระบบนิเวศอาจเสี่ยงต่อการสูญเสียความเชื่อมั่น
การตรวจสอบที่หละหลวมจะส่งเสริมการส่งข้อมูลแบบ "ทำส่งๆ ไปก่อน" (quick-and-dirty) ซึ่งอาจทำให้ agent พังในสภาพแวดล้อมการทำงานจริง (production) และอาจก่อให้เกิด downtime ที่มีค่าใช้จ่ายสูงหรือความเสี่ยงด้านความปลอดภัย
มุมมองต่าง: ข้อผิดพลาดทั้งหมดนั้นร้ายแรงจริงหรือ?
บางคนแย้งว่า "ข้อผิดพลาด" บางอย่างไม่มีอันตราย ชื่อที่ไม่ตรงกันอาจไม่ส่งผลกระทบต่อ agent ที่เลือกทักษะโดยใช้ slug แทนที่จะเป็นชื่อที่แสดงผล การอ่าน API keys จาก environment อาจเป็นทางเลือกในการออกแบบที่ตั้งใจไว้สำหรับการพัฒนาในเครื่อง (local development) อย่างไรก็ตาม เปอร์เซ็นต์จากการตรวจสอบนี้ถือว่าการเบี่ยงเบนใดๆ จากข้อกำหนดถือเป็นการละเมิด ซึ่งอาจเป็นการกล่าวเกินจริงถึงผลกระทบในทางปฏิบัติของบางปัญหา
สิ่งที่ต้องจับตามองต่อไป
- Linter ที่ได้รับการปรับปรุง ซึ่งสามารถแยกแยะระหว่างบั๊กด้าน portability ที่แท้จริงกับความผิดปกติเล็กน้อยที่ไม่มีอันตราย
- Registry-side validation hooks ที่ปฏิเสธการส่งข้อมูลที่ขาด frontmatter ที่จำเป็น หรือที่มี absolute paths
- การตรวจสอบโดยชุมชน (Community-driven audits) ที่ช่วยเผยข้อบกพร่องที่ซ่อนอยู่ก่อนที่มันจะไปถึง agent ในสภาพแวดล้อมการทำงานจริง
- การปรับปรุงข้อกำหนด (spec revisions) ที่อาจเกิดขึ้น เพื่อทำความเข้าใจฟิลด์ที่คลุมเครือ เช่น
allowed-toolsและกำหนดการใช้งาน environment variables ที่ยอมรับได้
เครื่องมือในระลอกถัดไปน่าจะฝังการตรวจสอบเหล่านี้ไว้ใน pipeline การรวมโค้ดอย่างต่อเนื่อง (continuous-integration pipelines) เปลี่ยนการปฏิบัติตามข้อกำหนดจากการตรวจสอบด้วยมือในภายหลัง ให้กลายเป็นด่านตรวจอัตโนมัติ
บทสรุป
ทักษะของ AI agent ส่วนใหญ่ที่เปิดเผยต่อสาธารณะไม่ผ่านการตรวจสอบความสอดคล้อง (compliance) ขั้นพื้นฐาน และมีสัดส่วนที่มีนัยสำคัญที่ไม่สามารถเลือกใช้งานได้เลย ผลการศึกษานี้เน้นย้ำถึงความจำเป็นที่ชัดเจนในการตรวจสอบความถูกต้อง (validation) ที่เข้มงวดขึ้น เครื่องมือ linting ที่ดีขึ้น และวัฒนธรรมของชุมชนที่ถือว่าการปฏิบัติตามข้อกำหนด (spec adherence) เป็นเงื่อนไขเบื้องต้นสำหรับการเผยแพร่ จนกว่าจะมีมาตรการป้องกันเหล่านี้ AI agent จะยังคงประสบปัญหาจากทักษะที่เปราะบางและไม่สามารถนำไปใช้ข้ามระบบได้ (non-portable)