אם אתם מסתבכים עם סקילים (Skills) של סוכני AI, אתם לא לבד. כשאני מראה איך ה-Agentic OS (מערכת ההפעלה האייג'נטית) שלי רצה בלי שגיאות, השאלה הראשונה שאני מקבל היא: "איך הסקילים האלה עובדים בדיוק? ואיך הסוכן יודע מה לעשות?"
הרבה מפתחים מחפשים את ה-prompt המושלם. אבל הסוד האמיתי הוא לא פרומפט אחד ארוך ומסורבל - אלא ארכיטקטורה מובנית של שלוש שכבות סקילים. ההפרדה בין מי הסוכן, מה הוא עושה, ומה הוא צריך לדעת היא זו ששומרת עליו ממוקד, מהיר וחסכוני בטוקנים (token units).
הנה המבנה המדויק של שלוש שכבות הסקילים שאני מריץ אצלי יום-יום.
1. שכבת הזהות (Identity Layer)
השכבה הראשונה מגדירה מי הסוכן בכל סשן (session) עבודה. היא לא מכילה רשימת כלים או הוראות לביצוע משימה ספציפית. במקום זה, היא מגדירה את הערכים שלו, טון הדיבור, ההקשר העסקי וחוקים נוקשים של מה אסור לו לעשות לעולם.
במערכת המקומית שלי, זה מנוהל בשני קבצים מרכזיים: קובץ ההנחיות CLAUDE.md (נטען אוטומטית בכל תחילת שיחה) וקובץ הליבה שלי ronit-master-skill/SKILL.md (שמגדיר את הקול של המותג ומערכות היחסים העסקיות שלי).
בלי השכבה הזו, הסוכן מתנהג כמו עובד קבלן זמני שמגיע כל בוקר למשרד ושוכח בשביל מי הוא עובד, מה מייחד את המותג, ואיך אתם אוהבים שהעבודה מתבצעת. שכבת הזהות היא העוגן של המערכת כולה.
2. שכבת הניתוב (Router Layer)
השכבה השנייה מורכבת מקבצי ניתוב (Router documents). קובץ ניתוב הוא לא רשימת הנחיות ענקית - הוא טריגר (trigger). התפקיד שלו הוא לטעון את ההקשר (context) המדויק למשימה הספציפית ברגע הנכון.
לדוגמה, כשאני מריץ את הפקודה /newsletter בטרמינל (Terminal), הסוכן לא טוען את כל הידע העסקי שלי. הוא טוען אך ורק את הקובץ שמסביר איך מנסחים, מעצבים ובודקים ניוזלטר. כשאני מקליד /social-poster, נטען הקשר שונה לחלוטין שמיועד לכתיבה בלינקדאין ובאינסטגרם.
זהו המפתח לחיסכון בטוקנים. אצלי במערכת, קובץ ניתוב טוען 200 שורות של הקשר ממוקד במקום לגרור 2,000 שורות של היסטוריה מנופחת. התוצאה היא סוכן חד יותר, מהיר יותר וזול משמעותית. אפילו מודלים קטנים וזולים יותר מתפקדים ברמה של מודלי קצה (frontier models) כשההקשר שלהם נקי ומדויק.
3. שכבת הידע (Knowledge Layer)
השכבה השלישית היא שכבת הידע (Knowledge Layer). אלו הם הקבצים שמונעים מהסוכן לנחש. אם תבקשו מסוכן לכתוב הצעת מחיר בלי שיש לו גישה למחירון העדכני שלכם, הוא פשוט ימציא מספרים.
מסמכי ידע הם מסמכי ייחוס קבועים שיושבים בתוך ויקי (Wiki) מקומי. הם כוללים פרטי לקוחות, מדריכים טכניים של כלי עבודה חיצוניים, מחקרי מתחרים ומחירונים.
אצלי, למשל, מסמך הידע של מערכת הדיוור Mailcoach מכיל את כתובות ה-API, לוגיקת הסגמנטים ואזהרות חשובות. כשסוכן הניוזלטר מופעל, הוא פונה למסמך הזה כדי למשוך את ההגדרות הנכונות. הסוכן צובר מומחיות לאורך זמן, וחוסך מכם את הצורך להסביר לו את אותם דברים שוב ושוב.
זה יסוד למערכת אייג'נטית בלתי תלויה !
מכיוון שמערכת שלוש השכבות הזו בנויה כולה מקבצי Markdown פשוטים וסקריפטים מקומיים, היא אינה תלויה במודל ספציפי. אם מחר ישוחרר מודל מהיר או זול יותר, אני לא צריך לשנות אף שורת קוד עסקית במערכת שלי. אני פשוט מחליף את מנוע הריצה.
קבצי הזהות, תהליכי העבודה, הסקריפטים ומנגנוני האישור האנושיים שלי נשארים בדיוק אותו הדבר. הגיע הזמן להפסיק לבנות סוכני API עצמאיים שנשברים בכל עדכון גרסה של המפתחים, ולהתחיל לבנות מערכת הפעלה מקומית שמריצה אותם.