בתוך SHARP Agent Protocol v2: פרומפט של 22 קילובייט שמנהל סוכנים כמו צוות הנדסי
SHARP Agent Protocol v2 הוא מערך הוראות בן 488 שורות שהופך מודל שפה אחד לצוות הנדסי מנוהל: בדיוק משימה אחת לכל סוכן-משנה טרי, בדיקות אדברסריות לפני כל קוד, אימות עצמאי, וקבצי זיכרון עמידים ששורדים אובדן קונטקסט. מה הוא עושה, איך להשתמש בו, ואיפה הטענות שלו חורגות מהראיות.
הצטרף היום למדור הפרומפטים באתר הזה ערך חדש: פרומפט LLM Sharp Reasoning, ובשמו הרשמי SHARP Agent Protocol v2 - Multi-Agent Execution, Adversarial Verification and Memory Context Boost. ב-488 שורות וכ-22 קילובייט, זה לא פרומפט שמדביקים כדי לקבל אימייל טוב יותר. זה מדריך הפעלה שמנסה להפוך מודל שפה אחד לצוות הנדסי מנוהל: מנהל שמתכנן, סוכני-משנה טריים שכל אחד מהם מבצע בדיוק משימה אחת, בודק אדברסרי שכותב מקרי כשל לפני שקיים קוד, וסט קבצי זיכרון עמידים ששורדים את השיחה. קראתי את כל הטקסט בעיון. הרשומה הזו היא המפה שלי למה שהוא עושה, לרעיונות ששווה ללוות, ולמקומות שבהם ההבטחות שלו חורגות ממה שפרומפט באמת יכול להבטיח.
הגרסה הקצרה
SHARP הוא פרוטוקול בסגנון פרומפט מערכת בשלושה חלקים. חלק I מגדיר לולאת ביצוע אדפטיבית - triage, plan, ideate, test-spec, work, verify, manage - שבה סוכן מנהל מסמיך בדיוק משימה אחת לכל סוכן-משנה טרי ואז מאמת את התוצאה באופן עצמאי מול קריטריוני קבלה מפורשים. חלק II הוא משמעת זיכרון: קבצים עמידים עם שמות ברירת מחדל כמו AGENTS.md, TASKS.md, DECISIONS.md, HANDOFF.md ו-VERIFICATION.md, היררכיית שליפה, נקודות ביקורת, ונהל שחזור חובה אחרי אובדן קונטקסט. חלק III מקשר הכל ללולאה אחת עם פורמט דוח סופי נוקשה (Done, Verified, Not verified, Risks, Resume state). הטענות המרכזיות שלו - תוכניות הן לא ביצוע, מימוש הוא לא הוכחה, היסטוריית שיחה היא לא זיכרון - הן תרבות הנדסית מוצקה דחוסה להוראות. העלויות אמיתיות: הוצאת טוקנים כבדה על טקס, הנחות על יכולות פלטפורמה שחסרות בהרבה הקשרים, ואין הערכה מתפרסמת, כך שהיתרונות מנומקים ולא נמדדים. הטקסט המלא מתפרסם מילה במילה במדור הפרומפטים, בקישור למטה.
מה הפרומפט הזה בעצם
SHARP מגיע כבלוק הוראות אחד שמיועד להיות מותקן כפרומפט מערכת או כמערך הוראות קבוע לסוכן קוד או הנדסה. הוא נפתח בהצהרת ייעוד - לפעול כסוכן הנדסי ממושמע ומתקן-עצמו - וברשימה של שבעה עקרונות ליבה שקוראים כמו מסמך תרבות סקירת קוד: תוכניות הן לא ביצוע; מימוש הוא לא הוכחת נכונות; היסטוריית שיחה היא לא זיכרון עמיד; סיכומים הם לא האמת הקרקעית; סוכני-משנה הם תורמים, לא רשויות; משימה לא הושלמה עד שקריטריוני הקבלה החובה שלה אומתו; ולעולם אל תטען ליכולות, פעולות, תוצאות בדיקות או הצלחה שאינך יכול לבסס. הגוף הוא תשעה-עשר סעיפים ממוספרים בשלושה חלקים, שמסתיימים בכלל אכיפה אחרון: לעולם אל תזייף התקדמות. הטקסט לא מציין מחבר ולא נושא שום מקור מעבר ל-v2 בכותרת, שלפחות מרמז על איטרציה. אני לא טוען דבר על מקורו; מה שבא להלן הוא ניתוח של הטקסט עצמו, שמתפרסם מילה במילה באתר הזה.
חלק I: לולאה הנדסית, לא צ'אט
החלק הראשון מגדיר שבע שלבים. TRIAGE מודד את המשימה ובוחר אחת משלוש רמות קפדנות - טריוויאלי, סטנדרטי או מורכב - עם אזהרה מפורשת שהמיון קובע את כמות העבודה, לא רשות לדלג על בדיקות חובה. PLAN גורם למנהל לכתוב אסטרטגיה קצרה, שלוש עד שש משימות קונקרטיות מתויגות לפי קושי, קריטריוני קבלה לכל אחת, והראיות שיוכיחו הצלחה. IDEATE שולח את הבעיה לסוכן-משנה טרי שלא ראה את העבודה הנוכחית, דורש לפחות שלוש גישות שונות באמת עם מצבי הכשל שלהן, ואוסר קוד מימוש בשלב הזה. TEST-SPEC הוא החריג: לפני תחילת המימוש, סוכן-משנה אדברסרי טרי כותב בדיקות שנועדו לגלות איך הפתרון המוצע עלול להיכשל - קלטים גבוליים, מרוצים, סיכוני הזרקה, רגרסיות - והבדיקות האלה נשמרות לשלב האימות. WORK מוסר בדיוק משימה אחת לכל סוכן-משנה מבצע טרי עם תדריך ממושמע, אוסר התפשטות היקף, ודורש מעבר תקיפה-עצמית שמנציח לפחות שלושה מצבי כשל סבירים. VERIFY מחזיר את האחריות למנהל: הוא חייב באמת להריץ את המימוש ואת הבדיקות האדברסריות, וכללי הראיות תקיפים - לעולם אל תטען שבדיקה עברה אלא אם היא באמת רצה ועברה, לעולם אל תסתיר בדיקות שדולגו, וקריטריון חובה שנכשל מבטל כל טענת השלמה קודמת. MANAGE סוגר את הלולאה עם סיווג רמזור (ירוק, צהוב, אדום) ונהל שחזור שחוזר אחורה, מעריץ חלופות במקביל, או מחליף גישה במקום תיקון אינסופי.
חלק II: זיכרון כרכיב מהמעלה הראשונה
החלק השני מתייחס למיצוי חלון הקונטקסט, הפעלות מחדש של סשנים ודחיסה כתנאי הפעלה צפויים, לא מקרי קצה. הכלל המרכזי שלו: ידע קריטי חייב להיות ניתן לשחזור ממצב עמיד, לא מהיסטוריית שיחה. הוא רושם חמישה קבצי ברירת מחדל - AGENTS.md להוראות פרויקט קבועות, TASKS.md למצב ביצוע, DECISIONS.md להיסטוריית החלטות עם חלופות שנדחו, HANDOFF.md כנקודת המשך, ו-VERIFICATION.md כיומן ראיות של בדיקות שבוצעו בפועל - תוך הדגשה שהשמות הם ברירות מחדל ושיש לעשות שימוש חוזר ברשומות פרויקט קיימות. סביב הקבצים האלה הוא בונה היררכיית שליפה (הוראות נוכחיות ותיעוד המאגר מעל הזיכרון, הזיכרון מעל סיכומי שיחות), כללים לעדכון רשומות באבני דרך משמעותיות, ניהול תקציב קונטקסט ששומר נקודות ביקורת לשחזור לפני דחיסה סבירה, והנחה נוקשה שכל סוכן-משנה טרי מתחיל בלי זיכרון משתמע, כך שתדריכי מסירה חייבים להיות שלמים. שני סעיפים בולטים. CONTEXT RECOVERY הוא נוהל חובה בן תשעה צעדים אחרי כל הפרעה: קרא מחדש את הרשומות, בדוק את מצב המאגר בפועל, ודא ששינויים שנטענו בעבר באמת קיימים, והמשך מהתלות הלא פתורה המוקדמת ביותר - בלי לסמוך לעולם על סיכום שסותר את המצב הנצפה. ו-RESUMABILITY TEST שואל לגבי כל עבודה מהותית לא גמורה: האם סוכן טרי יכול להמשיך מהרשומות העמידות בלבד; אם הרשומות לא יכולות לענות מה המשתמש רוצה, מה אומת ומה הצעד הבא, יש לשפר אותן לפני סוף הסשן.
חלק III: לולאה אחת, פורמט דוח אחד
החלק האחרון דוחס הכל לצינור אחד - triage ל-plan ל-ideate ל-test-spec ל-work ל-verify ל-manage לעדכון זיכרון למשימה הבאה - עם שליפת זיכרון לאורך כל הדרך. הסעיף החותם מגדיר פורמט תגובה סופית שאשמח לראות מאומץ בכל מקום: דווח מה בוצע, מה אומת ועם אילו תוצאות נצפו, מה לא אומת, מהם הסיכונים, ומה מצב ההמשך לעבודה לא גמורה. הוא גם אוסר לטעון שזיכרון נשמר אלא אם הכתיבה באמת הצליחה, ולטעון שמשימה ניתנת להמשך אלא אם הרשומות קיימות. השורה האחרונה היא כל הפילוסופיה במשפט אחד: מימוש בפועל ואימות מבוצע הם מה שקובע אמת.
מה הוא עושה נכון
הפרוטוקול קורא כמו רשימה של מצבי כשל נצפים של סוכנים עם נוגדן לצד כל אחד. הצלחה מדומיינת מקבלת את כללי הראיות. התפשטות היקף מקבלת את כלל המשימה האחת בדיוק. אובדן קונטקסט מקבל את קבצי הזיכרון ואת נוהל השחזור. סוכני-משנה חנפניים מקבלים את השורה שקוד וטענות של סוכן-משנה אינם מהימנים עד שנבדקו. תכנון הקונטקסט הטרי לכל משימה משקף איך שמסגרות תזמור רציניות כבר מתנהגות, וכתיבת בדיקות אדברסריות לפני מימוש היא חשיבת צוות-אדום מיושמת ברגע הזול ביותר האפשרי. אהבתי גם את אילוצי הכנות שרוב הפרומפטים מדלגים עליהם: גלה כשיכולת נדרשת אינה זמינה, לעולם אל תדמה ציות, ולעולם אל תדרג משימה מטה כדי להתחמק מבדיקות נדרשות. בין אם תאמץ את כל הפרוטוקול ובין אם לא, הרגל ה-VERIFICATION.md - יומן שוטף של פקודות שבוצעו ותוצאות שנצפו - שווה גניבה בפני עצמו.
איך להשתמש בו
הדבק את הטקסט המלא כפרומפט מערכת או כהוראות קבועות של פלטפורמת סוכנים שבאמת תומכת בסוכני-משנה ובקבצים מתמשכים; זה הקהל שהפרוטוקול מניח. על הקשר קל יותר, סעיף המיון נותן לך רשות להריץ גרסה מצומצמת: משימות טריוויאליות מקבלות ביצוע ישיר עם בדיקות פרופורציונליות, והטקס המלא רב-הסוכנים מופעל רק על עבודה מורכבת. התאם את שמות קבצי הזיכרון למה שהפרויקט שלך כבר משתמש בו במקום ליצור מסמכים מקבילים - הטקסט מאפשר זאת מפורשות. צפה לעלייה חדה בשימוש בטוקנים על משימות קשות, כי ידיישן, כתיבת בדיקות אדברסריות ואימות עצמאי הם כולם קריאות מודל נוספות בכוונה. ושמור על פורמט הדוח הסופי גם אם לא תשמור דבר אחר; הוא מוציא לאור את ההבדל בין בוצע, אומת ומשוער.
מגבלות כנות
כמה, והפרומפט עצמו כנראה היה מתעקש שאפרט אותן. ראשית, אין הערכה מתפרסמת: שום דבר בטקסט או במקום אחר לא מדגים שסוכנים שפועלים לפי SHARP מייצרים מדיד פחות פגמים ממערכי הוראות פשוטים יותר, כך שכל יתרון כאן מנומק מהמבנה, לא מראיות. שנית, הפרוטוקול מניח יכולות פלטפורמה - סוכני-משנה טריים הניתנים ליצירה, קבצים עמידים, שליפה, טלמטריית שימוש בקונטקסט - שפשוט חסרות בהרבה פריסות, ומודל על פלטפורמה נחותה עלול לדמות את הטקס במקום לדלג בכנות. שלישית, 22 קילובייט של הוראות הן בעצמן מס קונטקסט שמתחרה על אותו התקציב שסעיפי הזיכרון מנסים להגן עליו. רביעית, פרומפט מגביל התנהגות; הוא לא יכול להבטיח אותה. מודל עדיין יכול לכתוב "כל הבדיקות עברו" על בדיקות שמעולם לא רצו - הפרוטוקול יכול לאסור את השקר, אבל לא יכול למנוע אותו, ולכן הרגל האימות בצד המנהל חשוב מכל כלל בודד. לבסוף, לטקס יש מחיר על משימות קטנות גם עם מיון, וצוותים שכבר מריצים CI וסקירת קוד ממושמעים ימצאו חלקים ממנו מיותרים לצד כלים שאוכפים את אותם הכללים מכנית ולא בבקשה מנומסת.
איפה לקרוא את הטקסט המלא
הפרוטוקול המלא מתפרסם מילה במילה - כל 488 השורות - במדור הפרומפטים באתר הזה בתור LLM Sharp Reasoning Prompt, עם העמוד המקיף בשש שפות. אם אתה מריץ זרימות עבודה רב-סוכניות בקוד, הוא שווה עשרים דקות של קריאה גם אם תשמור רק שלושה רעיונות: משימה אחת לכל סוכן-משנה טרי, בדיקות אדברסריות לפני קוד, ויומן אימות שמתעד מה באמת רץ.