כל מערכת סוכן (agent system) ניצבת בפני אותה פשרה לא נעימה. אתם רוצים בסיס ידע עמוק ומאורגן היטב ששורד סקירות קוד והיסטוריית git. אך אתם גם זקוקים לזמן הריצה (runtime) שיהיה מהיר וישמור על מיקוד. שני הצרכים הללו פועלים זה נגד זה. ככל ששומרים יותר הוראות, כך גדל הפיתיון להעתיק את כולן לתוך הפרומפט ולקוות לטוב. התקווה הזו יקרה.
באקוסיסטם של Agent Project Context, המתח הזה מתחלק בבירור לשתי שכבות. APC מטפל בעמידות (durability). APX מטפל במהירות. הבנת האופן שבו הם מתקשרים — ומדוע APX מסרב לטעון מראש כל הגדרת מיומנות (skill definition) — חושפת על הנדסת פרומפטים יותר ממה שרוב מדריכי האופטימיזציה יגידו לכם.
הארכיון והמנוע
התפקיד של APC הוא קביעות. הוא מאחסן קבצי מיומנויות (skills) ניתנים לשימוש חוזר תחת .apc/skills/ כקבצי Markdown פשוטים. מכיוון שקבצים אלו חיים בתוך המאגר (repository) שלכם, הם נלווים לבקרת הגרסאות. אתם יכולים לפתוח pull request שמשנה תהליך פריסה (deployment). אתם יכולים לבצע diff לביטול (rollback) של מדיניות אבטחה מלפני שישה שבועות. אתם יכולים לבקר בדיוק מה הסוכן היה אמור לדעת ומתי. היכולת לבצע ביקורת כזו חשובה כאשר פריסה שגויה עולה לאוויר או כאשר מבקר תאימות (compliance auditor) מתחיל לשאול שאלות.
APX, לעומת זאת, חי ברגע. הוא מנהל את השיחה בפועל ביןכם לבין המודל. המטרה שלו אינה לארכב ידע אלא להשתמש בו בדיוק רב. כאשר APX מתייחס למיומנויות כאל מטען קבוע, כל המערכת מואטת. חלון ההקשר (context window) מתמלא. עלויות הטוקנים עולות. גרוע מכך, הקשב של המודל מתפזר בין הוראות שאין להן שום קשר לבקשה הנוכחית.
זו הסיבה שגופי המיומנויות (skill bodies) נטענים לפי דרישה.
המחיר האמיתי של פרומפט נפוח
רוב הצוותים מבינים שטוקנים עולים כסף. פחות צוותים מבינים שטוקנים לא רלוונטיים עולים בדיוק.
כאשר APX מזריק כל מיומנות זמינה לכל סבב (turn), הפרומפט הופך לרועש. המודל מקבל את ספר ההפעלה (runbook) של הפריסה, את מדריך האבטחה, את ייחוס סגנון ה-API, את רשימת הבדיקות (testing checklist) ואת שאלות ה-onboarding FAQ – הכל בבת אחת. גם עם חלון הקשר גדול, איכות ההסקה (reasoning) יורדת כאשר המודל חייב תחילה לסנן רעש כדי למצוא אות (signal). הוא עלול להיצמד לדרישת אבטחה המיועדת לפריסות פרודקשן בזמן שהוא עונה על שאלה לגבי הגדרת בדיקה מקומית. הוא עלול להזות (hallucinate) שלבים מרשימת שחרור (release checklist) לתוך תיקון באג פשוט. כל פסקה נוספת של טקסט לא קשור היא הסחת דעת שמחכה לקרות.
המתמטיקה פשוטה. רוב הסבבים אינם זקוקים לרוב המיומנויות. אם אתם מבקשים תיקון מהיר ליומן שגיאות (error log), אינכם זקוקים לטקסט המלא של ספר הפעלה של פריסה או למדריך להקשחת אבטחה (security hardening). אתם צריכים שהמודל יראה את השגיאה, יבין את מוסכמות הפרויקט שלכם ויערוך את הקובץ הנכון. טעינה של גופי מיומנויות לא רלוונטיים אינה עוזרת למודל לעשות זאת. היא מאלצת את המודל לסנן נתונים מיותרים עוד לפני שהוא מתחיל לעבוד על הבעיה האמיתית שלכם.
איך טעינה לפי דרישה עובדת
המנגנון פשוט אך מכוון. APC ממשיך להחזיק ב"אמת המוחלטת" (ground truth). הגדרות המיומנויות שלכם נשארות במקום שבו הן שייכות: ב-.apc/skills/<name>.md.
APX אינו משקף את הקבצים הללו לזיכרון הפעיל. במקום זאת, הוא בונה רישום (registry) תמציתי של שמות המיומנויות. המודל רואה את הרשימה הזו ומבין שקיים קטלוג. אם הוא צריך לדפדף או לאשר אילו יכולות זמינות, הוא יכול להפעיל קריאה ל-list_skills. זה מעניק לו נראות ללא עומס.
כאשר המשימה דורשת בפועל את התחביר המדויק, השלבים המפורטים או האילוצים הספציפיים המקודדים בקובץ מיומנות, המודל קורא ל-load_skill. בנקודה זו, ורק בנקודה זו, APX שולף את גוף ה-Markdown המלא מ-APC ומזריק אותו להקשר (context). ההוראה מגיעה "חמה", בשימוש חד-פעמי למטרה המיועדת לה, והמערכת נמנעת מהובלתה כמשקל מת.
חשבו על ההבדל בין ייבוא ספרייה לבין הדבקת כל הגדרת פונקציה בתוך הקובץ הראשי שלכם. גישה אחת שומרת על בסיס הקוד שלכם ניתן לניווט. השנייה יוצרת בלגן שמתקמפל רק במקרה.
מי מנצח כשמיומנויות מתנגשות
APX גם אוכפת סדר עדיפויות ברור כאשר היא טוענת מיומנויות. לא כל סביבה היא זהה, ועצות כלליות לעולם לא צריכות לבטל ידע מקומי.
מיומנויות פרויקט (Project skills) הן בעלות העדיפות העליונה. קבצים אלו נמצאים במאגר (repository) הנוכחי שלך תחת .apc/skills/. הם לוכדים את המוסכמות הספציפיות של הצוות שלך, את ה-wrappers המותאמים אישית שלך, את תקני השמות הישנים (legacy) שלך ואת שרשרת הכלים (toolchain) הייחודית שלך. אם הפרויקט שלך מגדיר דרך משלו לניהול מיגרציות מסד נתונים, ההגדרה הזו היא הקובעת.
מיומנויות גלובליות (Global skills) מגיעות לאחר מכן. אלו מכסות תבניות ברמת הארגון שחלות כאשר הפרויקט עצמו אינו מגדיר דבר. הן משמשות כספרייה סטנדרטית.
מיומנויות runtime מובנות (Built-in runtime skills) נמצאות בתחתית כברירת מחדל (fallback). הן מטפלות ביכולות גנריות שכל סוכן (agent) אמור להבין, אך ששום פרויקט ספציפי לא טרח להגדיר מחדש.
גישה שכבתית זו פירושה שהמאגר שלך שומר על שליטה בהתנהגותו שלו. מיומנות גלובלית או מובנית אינה יכולה לחטוף בטעות תהליך עבודה (workflow) שהצוות שלך התאים אישית בכוונה.
איך זה נראה בפועל
דמיינו משימת תחזוקה טיפוסית. חבר צוות מדביק לוג שגיאה (error log) בצ'אט. ה-traceback מצביע על הפניה בודדת ל-null במודול עזר (utility module). התיקון הוא ככל הנראה שתי שורות של כתיבת קוד הגנתית (defensive coding).
במערכת ללא טעינה לפי דרישה (on-demand loading), APX היה דוחס את ההקשר (context) עם כל מיומנות שהוא מכיר. כעת יש למודל ארבעים דפי טקסט לשקול לפני שהוא נוגע בשתי השורות הללו. הוא רואה את רשימת הבדיקה לשחרור (release checklist) ותוהה אם עליו להעלות גרסה. הוא רואה את מדריך האבטחה ושוקל אימות קלט (input validation) בפונקציה שרק זקוקה לבדיקת null. הוא רואה את מדריך הפריסה (deployment runbook) ומתחיל לחשוב על סביבות staging. המודל מאבד ריכוז. התגובה לוקחת יותר זמן. מד הטוקנים מסתובב ללא הפסקה.
עם העיצוב של APX המבוסס על טעינה לפי דרישה, המודל רואה רק את השמות. הוא יודע ש-[release-checklist], [security-guide], [deployment-runbook], ו-[error-handling] קיימים. הוא מתעלם משלושת הראשונים. הוא עשוי לטעון את [error-handling] אם המוסכמות של הפרויקט שלך לגבי בטיחות null הן ספציפיות. הוא מתקן את הבאג. המיומנויות הלא קשורות מעולם לא נכנסו לחלון ההקשר (context window). המודל נשאר ממוקד כי הפרומפט נשאר נקי.
אותו היגיון תקף גם כאשר המשימה היא באמת מורכבת. אם תבקשו מאוחר יותר מהסוכן להכין פריסה לסביבת ייצור (production deployment), הוא יוכל לטעון את מדריך הפריסה, להתייעץ עם מדריך האבטחה ולפעול לפי רשימת הבדיקה לשחרור בדיוק ברגע שהצעדים הללו הופכים לרלוונטיים. הידע תמיד היה שם. הוא פשוט חיכה לרגע הנכון.
משמעת פרומפט כארכיטקטורה
ההפרדה בין APC ל-APX אינה רק פרט של מימוש. זוהי פילוסופיה של משמעת פרומפט. APC שומרת על ידע לנצח, מה שהופך אותו לניתן לסקירה, בעל גרסאות ובטוח. APX מחליטה כמה מהידע הזה ראוי לתפוס מקום בהקשר הפעיל ברגע זה.
קטלוג מיומנויות עשיר הוא נכס. פרומפט נפוח הוא נטל. המטרה היא לשמור על ההקשר שלך נייד (portable) מבלי להפוך אותו לפעיל תמיד. המאגר שלך צריך להכיל כל הוראה שהצוות שלך אי פעם כתב, אך הסוכן צריך לקרוא רק את אלו שעוזרות למשימה המיידית.
אם המערכת שלך מאלצת את המודל לשאת את כל גוף המיומנות בכל תור (turn), אתה לא בונה עוזר חכם. אתה בונה ספרן שגורר את הארכיון כולו לכל שאלה בדלפק המידע. שמרו הכל. טענו מה שחשוב. כך שומרים על סוכנים מהירים, הקשר נקי וחשיבה חדה.