ביקורת חדשה על 2,465 "מיומנויות" (skills) של סוכני AI הרשומות בפומבי מצאה כי יותר ממחציתן מפרות את המפרט שפורסם, ו-7.8 אחוזים אפילו אינם ניתנים לבחירה על ידי סוכן מכיוון שחסרים להן המטא-דאטה הנדרשים. הליקויים הללו מאיימים על האמינות של כל מערכת שמגלה וטוענת מיומנויות אלו באופן אוטומטי.
למה הביקורת חשובה
רישומי מיומנויות סוכנים (Agent-skill registries) מאפשרים למפתחים לפרסם יכולות ניתנות לשימוש חוזר — חבילות קוד שסוכן אוטונומי יכול להפעיל לפי דרישה. סוכן סורק את הרישום, קורא את ה-YAML frontmatter של כל מיומנות (בלוק קטן של טקסט מובנה שחייב להכיל לפחות שם ותיאור), ומחליט האם המיומנות תואמת למטרותיו. אם ה-frontmatter חסר או פגום, המיומנות נעלמת מהתפריט של הסוכן. בעולם שבו סוכנים אוטונומיים קובעים פגישות, פותרים תקלות בשרתים ועוד, מיומנות תקולה שוברת את זרימת העבודה (workflow).
מה המספרים חושפים
- 57.8% מהמיומנויות כוללות לפחות הפרה אחת של המפרט.
- 29.2% מציינות שם שאינו תואם ל-slug של הרישום (מזהה ה-URL).
- 18.1% מכילות נתיבי חבילה שבורים או קישורים שאינם פעילים.
- 7.8% (192 מיומנויות) אינן כוללות YAML frontmatter כלל, מה שמותיר אותן ללא שם וללא תיאור.
- 3.8% מטמיעות נתיבי קבצים מוחלטים (absolute file paths) שקיימים רק במחשב של המחבר.
- 2.4% משתמשות שלא כשורה בשדה
allowed-tools, מה שהופך אותו לבלתי קריא עבור סוכנים. - 2.1% חושפות מפתחות API באמצעות משתני סביבה, מה שמהווה נורת אזהרה אבטחתית.
- 1.3% קוראות לכלי שורת פקודה חיצוניים מבלי להצהיר עליהם, מה שמפר את כלל הניידות (portability).
בעיית הניידות מופיעה בתדירות הגבוהה ביותר. נתיב מוחלט כגון /home/USER/.local/bin/tool יעבוד עבור המפתח שכתב את המיומנות, אך ייכשל עבור כל משתמש אחר, מה שיגרום לשגיאות זמן ריצה (runtime errors) שבבדיקות סטטיות לעולם לא יתפסו.
מבט מעמיק יותר: מקרה ה-openclaw
הביקורת בחנה גם 46 מיומנויות שנאספו במאגר (repository) של openclaw. לאחר שכללה את סקריפט הבדיקה כדי למנוע התראות שווא, הבודק חשף 59 ליקויים אמיתיים — תזכורת לכך שכלים מסוג linters אגרסיביים מדי עלולים להוביל לתוצאה הפוכה. כאשר כלי מסמן יותר מדי בעיות שאינן מזיקות, מפתחים מפסיקים להשתמש בו, ובעיות אמיתיות מחליקות דרך.
שני הליקויים ב-openclaw הצביעו על קבצים שאינם קיימים עוד במאגר. המנהל (maintainer) מיזג תיקון שמחזיר את ההפניות החסרות, מה שמראה כיצד pull request בודד יכול לנקות שרשרת תלות (dependency chain) שבורה.
תגובות המפתחים
הבודק פתח ב-issues (דיווחים) במאגרי המיומנויות המקוריים. דיווח אחד נדחה; המנהל טען כי יש לשפוט "תקוליות" לפי התנהגות זמן ריצה בפועל, ולא לפי בדיקה סטטית של הקבצים. הבודק הסכים כי הגדרה קשיחה של תקוליות חייבת להתיישב עם האופן שבו המיומנות מתבצעת בפועל. issue אחר התקבל, והתיקון המתאים כבר זמין כעת.
מי עומד להרוויח — או להפסיד
- סוכנים ומשתמשי קצה נהנים מהתנהגות חלקה וצפויה יותר כאשר הרישום מכיל רק מיומנויות תואמות וניידות.
- מחברי מיומנויות מקבלים כללי אימות ברורים יותר שתופסים טעויות לפני הפרסום, מה שמפחית את הצורך בתקשורת הלוך ושוב לצורך טיפול ב-issues.
- מפעילי רישומים חייבים לבנות או לשלב תהליכי אימות (validation pipelines) מחמירים יותר; בלעדיהם, המערכת (ecosystem) מסתכנת באובדן אמון.
אימות רשלני מעודד הגשות "מהירות ומלוכלכות" שעלולות לשבור סוכנים בסביבת ייצור (production), מה שעלול לגרום להשבתה יקרה או לחשיפת אבטחה.
נקודת מבט נגדית: האם כל ההפרות הן קטלניות?
יש הטוענים כי "שגיאות" מסוימות אינן מזיקות. שם שאינו תואם עשוי שלא להשפיע על סוכן שבוחר מיומנויות לפי ה-slug ולא לפי השם המוצג. קריאת מפתחות API מהסביבה יכולה להיות בחירה עיצובית מכוונת עבור פיתוח מקומי. עם זאת, אחוזי הביקורת מתייחסים לכל סטייה מהמפרט כהפרה, מה שעשוי להגזים בהשפעה המעשית של חלק מהבעיות.
מה כדאי לעקוב אחריו בהמשך
- linters משופרים שיפרידו בין באגים אמיתיים של ניידות לבין מוזרויות שאינן מזיקות.
- validation hooks בצד הרישום שידחו הגשות חסרות frontmatter נדרש או כאלו המכילות נתיבים מוחלטים.
- ביקורות מונעות קהילה שיחשפו ליקויים נסתרים לפני שהם מגיעים לסוכני ייצור.
- עדכוני מפרט פוטנציאליים שיבהירו שדות מעורפלים כמו
allowed-toolsויגדירו שימוש מקובל במשתני סביבה.
הגל הבא של כלי הפיתוח ככל הנראה ישלב בדיקות אלו בתוך תהליכי continuous-integration, ובכך יהפוך את העמידה במפרט מפעולה ידנית שמתבצעת בדיעבד לשער בקרה אוטומטי.
שורה תחתונה
A majority of publicly listed AI-agent skills fail basic compliance checks, and a non-trivial slice cannot be selected at all. The findings underline a clear need for stricter validation, better linting tools, and a community culture that treats spec adherence as a prerequisite for publishing. Until those safeguards are in place, agents will continue to stumble over brittle, non-portable skills.