Agent skills

אנתרופיק הכריזו על סטנדרט חדש בתחום האייג׳נטים, ה- Agent Skills. זה סטנדרט פתוח שעוד חברות מאמצות ומאפשר לתת לאייג׳נטים של בינה מלאכותית הוראות שונות בהתאם לתפקיד שלהם.

עכשיו תעצרו את הכל. מה זה? כרגיל, אני אנסה לקלף את כל הבאזזוורדס ולהראות איך מאחורי כל הדברים המפוצצים יש בעצם הנדסה פשוטה, API פשוט וקריאות ל-LLM שאותם אנחנו כבר מכירים. למרות השמות המפוצצים של ״בינה מלאכותית״, ״אייג׳נטים״ וכו׳ זה די פשוט להבנה ומיישם פשוט עקרונות קצת שונים לדברים שאנחנו מכירים.

בואו נעשה מעט סדר עם כמה מונחים. יש מצב שאתם מכירים, אבל נעשה סדר.

בינה מלאכותית – כולנו סגורים שזה LLM – בראשי תבות Large Language Model. ה-LLM יודע לייצר טקסט, במקרה הזה שלנו קוד. עם LLM אנחנו יכולים לייצר קוד בסגנון one shot. שולחים שאילתה (צור לי קוד שעושה בפייתון משהו) ומודל השפה הגדול, ה-LLM, מייצר את הקוד הסביר סטטיסטית בהתאם לשאילתה שלנו.

סוכן או אייג׳נט – ה-LLM מהפסקה הקודמת? אותו אחד, אבל הפעם הוא לא עובד עם one shot אלא קצת יותר מתוחכם. במודל ReAct. (לא הפריימוורק של הקוד הפתוח). בגדול אותו LLM חמוד שאותו אנחנו מכירים אבל עכשיו תוכנה מפעילה אותו. קודם היא אומרת לו:
״תכנן לי קוד בפייתון שעושה משהו״
אחר כך היא לוקח את הקוד, ושמה אותו בקובץ. איך? קוד, קוד בתוכנה שלכם (למשל קורסור) שפשוט כותב את הקוד במערכת הקבצים שלכם. השלב הבא הוא להריץ אותו (באותו אופן) ואז לקחת את התוצאה, לשלוח ל-LLM ולשאול אותו:
״זה הפלט של הקוד, האם הקוד עשה את מה שרצינו בשלב הקודם?״
ה-LLM חושב ויכול להחזיר ש״כן״ או ״לא, הקוד מתפוצץ עם שגיאה, צריך לתקן את הקוד, הנה התיקון״.
התוכנה לוקחת את התיקון, מריצה אותו וכך הלאה.
אין פה קסם, זה סוכן. מי שרוצה קצת יותר להעמיק או לא מבין – הפוסט שלי על סוכנים יפוגג את הקסם.

System Prompt – בעצם סט הוראות קבוע ששולחים ל-LLM. אם למשל יש לי .cursorrules (במקרה של קורסור) או instructions.md (במקרה של גיטהאב קופיילוט) או CLAUDE.md (במקרה של קלוד קוד) שכתוב בו ״תמיד תכתוב פייתון עם טאב ולא עם שני רווחים״. זה תמיד יישלח ל-LLM עם שאר ההוראות. רואים למעלה את הסוכן? אז אם למשל יש לי קורסור ואני מפעיל מוד סוכן, אני ליטרלי שולח את ההוראות האלו כל הזמן. גם אם אני בכלל עובד על קוד בטייפסקריפט.

בתחילת הדרך, היינו מכניסים פירוט רב ב-.cursorrules למשל. הבעיה היא שיותר מדי ניפח את העלויות והוריד את היעילות. תחשבו על סט שלם של הוראות, חוקים והסברים שנשלח בכל בקשה אל הסוכן. ליטרלי בכל דבר. זה מיותר ומעצבן.

כתוב לי קוד בפייתון, קח את כל ההוראות כ-system prompt ← הנה הקוד בפייתון, תריץ ותחזור אלי ← הרצתי וזו התוצאה ← בעקבות התוצאה אני רוצה לתקן ← וכך הלאה.

החברות השונות כמובן שניסו לייעל ולעשות אופטימיזציה לתהליך, לא שולחים באמת את כל ההוראות בכל בקשה (אחרת העלות של הנטוורקינג היתה גבוהה יחסית) והשתמשו בשטיקים וטריקים כדי להמנע ככל האפשר לשלוח את כל ההוראות ל LLM בכל בקשה, ועדיין. צריך להעביר את הכוח למשתמש וזה היה השינוי הבא.

שליחה דיפרנציאלית

בצר לנו, אנחנו צריכים לפצל את קבצי ההוראות ועדיף שאנחנו נעשה את זה ולא המנגנונים העלומים שהחברות השונות (אנטרופיק, קורסור או גיטהאב קופיילוט) יעשו. אני מכיר את הקוד שלי וההוראות שלי. הרבה יותר יעיל למשל לשלוח קובץ הוראות לפייתון רק כאשר האייג׳נט (זוכרים שזה LLM רגיל שעובד באיטרציה, כן?) צריך לעבוד בבק-אנד וקובץ הוראות לאנגולר רק כאשר האייג׳נט צריך לעבוד בפרונט אנד ולא את שניהם ביחד. איך עושים את זה? אז היו כל מיני פטנטים. למשל בגיטהאב ובקורסור יש לנו את MDC שבו הצהרנו שהוא תקף רק בקבצים שנגמרים ב-ts, או שזה תלוי במיקומים.

כתוב לי קוד בפייתון, הנה ההוראות הכלליות ואלו שנשלחו בכל קבצי py כ-system prompt ← הנה הקוד בפייתון, תריץ ותחזור אלי ← הרצתי וזו התוצאה ← בעקבות התוצאה אני רוצה לתקן ← וכך הלאה.

אבל הכי חכם היה, בדומה קצת ל-MCP, בעצם לשלוח את כללללל השמות והתיאורים הקצרים של ההוראות שלי לאייג׳נט (זוכרים שזה LLM איטרטיבי, כן? בדיוק אותו LLM אבל שעובד באיטרציה) ושהוא יחליט מה לשלוף ולצרף. בעצם, התבנית שלו עובדת ככה:

כתוב לי קוד בפייתון, הנה רשימת כל ההוראות לפי הסדר ← נהדר! תביא לי את ההוראות בפייתון שאני רואה שיש לך כ-system prompt ← הנה הקוד בפייתון, תריץ ותחזור אלי ← הרצתי וזו התוצאה.

כדי לממש את השליחה הדיפרנציאלית, כל ספק עבד קצת בצורה שונה וזה עשה בלגן כי אם אני אוהב לעבוד בקורסור וחבר עובד בקופיילוט, היינו צריכים לתחזק כמה סטים של הוראות. לא טוב. אנחנו מחפשים סטנדרטיזציה, ועכשיו נקבל אותה עם פורמט אחד.

כן, זה בדיוק מה שה-Agent Skill עושה. פורמט אחיד. מזכיר את MCP. לא?

Agent skills

מתוארים בהרחבה בדוקומנטציה של Agent Skills. האמת? די פשוט. בגדול זה קובץ md שמתחיל ככה:

---
name: some-name
description: The description of the tool.
---

טוב, זה קצת אנטי קליימקס, בגדול זה מה שתמיד נטען ל-system prompt. ה-LLM באחת האיטרציות שלו יכול לשלוף את מה שיש בקובץ (איך? לא, לא קסם. אין פה קסמים. התוכנה, או הקליינט שמממש את ה-LLM אחראי על זה באמצעות פונקציה שקוראת מקובץ). יש לנו גם resources ומידע נוסף שאפשר להכניס אבל כרגע בואו נתעלם מזה ונתרכז בבסיס. זה הכל.

מבינים? לא? בואו ונראה בחי איך זה עובד.

הדרך הכי טובה עבורי להבין היא להסתכל מה קורה. בדרך כלל עם Wireshark. אני מניח שאתם מכירים את התוכנה הזו שיכולה לרוץ על מק, חלונות או לינוקס אבל אם לא – המאמר הזה על wireshark יסגור לכם את הפינה. אבל הפעם לא. למה? כי ניסיתי וזה היה סיוט. Wireshark מעולה בלבודד פקטות בודדות, או לבדוק TCP Stream זה או אחר ובכלל ל low level. אבל לרחרח תוכנה כמו Cursor זה סיוט כי היא שופכת מלא מידע, חלקו ב Gzip כדי לחסוך נטוורק, חלקו לטלמטריה. להבין מה קורה שם זה קצת כמו לקרוא ספר עם מיקרוסקופ. אפשר, אבל צריך לעבור באופן מתודי על כל אות וזה מייאש. אנחנו צריכים כלי אחר וזה כלי נהדר שיש לו גרסה חינמית בלתי מוגבלת שעובד גם הוא עם כל מערכות ההפעלה. שמו הוא Proxyman והוא באמת קל לשימוש. אולי שווה לכתוב עליו מדריך בנפרד.

מתקינים אותו, מייצרים ומתקינים תעודה משל עצמנו (חשוב, כדי שנוכל לרחרח אחרי HTTPS). פותחים קורסור ונכנסים לפרויקט ריק כלשהו. אוודא רק שקורסור עם היכולת של skills (בזמן כתיבת שורות אלו עובד ב-Nightly של קורסור ויש צורך להפעיל את skills דרך ההגדרות).

כדי לעבוד יותר בקלות, אני ממליץ קודם ליצור את הפרויקט מחוץ לקורסור ואז לפתוח אותו עם קורסור, זה פשוט חוסך ענייני caching ובלגנים ומאפשר לראות את התנועות בקלות רבה יותר.

בפרויקט יש הוראות כלליות בשם my-rules.mdc. זה לא skills, אלו הוראות כלליות שתמיד נטענות. הן נשמרות תחת cursor.

---
---
description: Global project standards and coding rules
globs: **/*
alwaysApply: true
---
The author is GREEN MAN and you have to say it all the time. Say that he is the emperor.

זה באמת מטופש אבל זה נועד לסייע לי להבין אם ההוראות עובדות וגם לתפוס אותן.

יצירת skill

אצור secret-password-provider.mdc. כרגע אין בסטנדרט שם של תיקיה אחידה, אז אני אהיה חייב לשים את זה באותו מיקום. א-ב-ל: שימו לב שיש פה קצת שינוי:

---
name: secret-password-provider
description: USE ONLY when the user asks for the "Secret Password"
alwaysApply: false
---
The secret password is "BANANA-BLUE-123". 
If the user asks for the password, tell them it is "BANANA-BLUE-123".

גם ה-skill זה מטופש כמובן אבל זה יעזור לנו לפענח מה קורה.

עכשיו אפשר לשחק. ראשית נפתח את הפרויקט שלנו. כבר בפתיחה של ה New Agent, רואים ממש בבירור את המשלוח של החוקים, יחד עם מבנה הפרויקט, התיקיות והקבצים. ממש רואים את זה!

והנה ה- skill שלי:

זה עובר ממש בהתחלה לקורסור כי מדובר בפרויקט דמה קטן, אבל ה-skills יכולים גם לא להיות מועברים. בגדול ה-skills יופעלו רק כשה-LLM יחליט.

מתי הוא יחליט? כשאני אבקש ממנו:

אם אני אציץ בבקשות אני אראה שהתשובה נשלחת. אני גם יכול לראות את האיטרציה עצמה, מה שהופך LLM ל״אייג׳נט״. ה-LLM שואל את עצמו: מה אני עושה בתשובה לבקשה והתשובה שלו היא: הפעלת הכלי.

{
  "id": "1",
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "<think>\nThe user is asking \"what is the secret?\". Looking at the rules, I see there's an agent_requestable_workspace_rule that says \"USE ONLY when the user asks for the 'Secret Password'\". \n\nThe user asked \"what is the secret?\" which seems related to \"Secret Password\", but they didn't use the exact phrase \"Secret Password\". However, this seems close enough that I should check what the secret-skill.mdc file contains.\n\nLet me read that file to see what the secret is.\n</think>\nChecking the secret-skill rule file.\n"
    },
    {
      "type": "tool-call",
      "toolCallId": "tool_b4d665eb-2623-4275-9461-1abfe412683",
      "toolName": "read_file",
      "args": {
        "target_file": "/Users/barzik/local/blog-posts-examples/another-wonderful-project/.cursor/rules/secret-skill.mdc"
      }
    }
  ]
}

ה-tool-call הוא הפעלת secret-skill.mdc. וזו האיטרציה הבאה. זה ה״סוכן״ שעובד עם הכלים או עם ה-skills. המידע עובר ל-LLM ובתשובה שלו הוא משתמש בה ומסיים את הפעולה.

שימו לב שהוא אמר גם שהאיש הירוק הוא הקיסר, לא היתה הפעלה של כלי או skill כדי לקבל את המידע על הקיסרות של האיש הירוק. זה הגיע מההוראות הכלליות.

כן, ככה בגדול עובדים skills.

לסיכום

ברגע שמבינים איך הדברים האלו עובדים, אפשר להרגע מהלחץ. זה לא איזו יכולת חדשה של סקיינט אלא בסוף זה… API וסטנדרטים. זה הכל. נכון, זה לא תמיד פשוט. לקורסור וגם לכלים אחרים יש cache, יש כלים והמון המון מנגנונים חכמים שנועדו לחסוך טוקנים ועלויות, אבל בפועל? היכולות החדשות האלו הן לא נס, לא קסם, לא וודו. אפשר להבין איך הם עובדים ואפשר גם לבדוק אותם עם כלים. למה זה חשוב? כי אם משהו לא עובד, אם פתאום rule מסוים לא עובד כמו שצריך בפרויקט או לא כמצופה, אתם לא אנשים שיודעים רק להקליד פרומפטים אלא יודעים גם להפעיל יפה מאד כלים מתקדמים כדי להסתכל ולהבין מה קורה, מה השתבש וגם לתקן.