Self-Improving AI Agents: איך לבנות אייג'נט שמשתפר לבד, השיטה של Anthropic

מה זו לולאה אג’נטית, ולמה רוב האנשים בונים אותה לא נכון

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

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

ב-Anthropic בונים את זה אחרת, לולאה שמתקנת ומשפרת את עצמה תוך כדי ריצה. האייג’נט מזהה שגיאות, חוזר לתקן, ומיישר את עצמו בחזרה למסלול, בלי שתצטרכו לפקח על כל צעד. לדבריהם, כל העבודה הפנימית שלהם הפכה “פי 10,000 יותר קלה” בזכות האייג’נטים האלה, ומשימות שנתנו בלילה מסתיימות עד הבוקר, באגים תוקנו והמשימות נסגרו לבד.

שלושת המרכיבים של כל אייג’נט

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

בונים את הלולאה הבסיסית: פרומפט כללי מול פרומפט ספציפי

הטריק הראשון בבנייה נכונה הוא להפריד בין שני סוגי הנחיות:

• פרומפט-המערכת = כללי וניתן לשימוש חוזר. שמים בו את ההנחיות לביצועים טובים שיעבדו על הרבה משימות שונות.
• הפרומפט הראשוני = ספציפי למשימה. שמים בו את המבנה (schema) של הנתונים מראש, ואת שלבי המשימה מפורקים לצעדים.

למה לשים את ה-schema מראש? כדי שהאייג’נט יידע בדיוק איך הנתונים בנויים, ולא יבזבז זמן על חקירה ראשונית. ולמה לפרק לצעדים? כי אייג’נטים הם “שחקנים אקראיים”, אם אתם רוצים פלט צפוי, צריך להיות קצת מכתיבים. בונוס: כשמשהו משתבש, קל לראות באיזה צעד בדיוק זה קרה.

הסוד: להכניס את ה-Eval לתוך הלולאה

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

יש שלושה סוגים של evals שכדאי להכיר:

כך נראית הלולאה כשהשופט יושב בתוכה:

loop:
    output = agent.run(task)          # model + tools + file access
    score  = judge.evaluate(output)   # LLM-as-judge, separate context
    if score >= THRESHOLD:            # e.g. 90%
        break
    # else: the agent revises and loops again

השופט בחלון הקשר נפרד: כדי למנוע הטיה

זה טיפ קריטי שקל לפספס: את השופט צריך להריץ ב-חלון הקשר (context window) נפרד מזה של האייג’נט שיצר את הפלט.

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

אימון עד סף (למשל 90%): מתי הלולאה יודעת לעצור

ברגע שיש שופט בתוך הלולאה, אפשר להגדיר לו יעד מספרי. בדוגמה של Anthropic, אימנו מודל חיזוי עד שהגיע ל-90% דיוק ב-benchmark מסוים. האייג’נט ניסה, נכשל, תיקן וחזר, שוב ושוב, לבד, עד שעבר את הרף.

העיקרון: תנו לאייג’נט לרוץ במעגלים של עצמו כמה שיותר לפני שעיניים אנושיות נכנסות לתמונה. ככה משיגים כמה שיותר התקדמות אוטומטית. שימו לב, זה עיקרון, לא flag קסם: אתם מגדירים יעד מספרי שה-eval הפנימי בודק מולו, ונותנים ללולאה להתכנס אליו.

בן-אדם בתוך הלולאה: אישור לפעולות בלתי-הפיכות

לא כל פעולה צריכה להיות אוטומטית. ה-harness יודע לעצור ולבקש אישור אנושי, וזה מוגדר ברמת הכלי הבודד: לכל כלי אפשר לתת הרשאה של "always allow" (תמיד מותר) או "ask" (בקש אישור).

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

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

מהמחשב האישי לענן: cron, טריגרים, ואייג’נט שרץ לבד

אייג’נט שרץ ב-Claude Code על המחשב שלכם מוגבל למגבלות הלפטופ, כמה זמן הוא דלוק וכמה כוח יש לו. שני צעדים אחרונים הופכים אותו לעובד אמיתי:

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

ולסיום, סדר העבודה המומלץ: קודם vibe test (פשוט לשחק עם האייג’נט ולראות מה מרגיש נכון), אחר כך לתת למשתמשים אמיתיים לגעת בו, ורק כשאי אפשר יותר לאמוד תחושה בקנה מידה גדול, עוברים ל-evals רשמיים. ואל תגזימו ביום הראשון: במקום לנסות לאוטמט workflow של 20 צוותים, תבנו אייג’נט אחד ותראו שהוא באמת עובד ואנשים באמת משתמשים בו.

טיפים אחרונים

• התחילו קטן. אייג’נט אחד שעובד עדיף על תזמורת של אייג’נטים שאף אחד לא משתמש בה.
• אייג’נטים הם שחקנים אקראיים. רוצים פלט צפוי? תנו schema מראש ופרקו את המשימה לצעדים.
• השופט תמיד בחלון נפרד. אחרת הוא מנקד את עצמו גבוה מדי.
• לא כל אייג’נט חייב להיות מושלם. אייג’נט לכמה שבועות שפותר משימה אחת זה בסדר גמור, אפשר לזרוק אותו אחר כך.
• לפעולות מסוכנות: always ask, לא always allow.
• לוקח בערך חצי שעה להקים אייג’נט. שווה לנסות אחד חדש כל כמה שבועות.

לינקים

• הסרטון המלא (40 דקות) של Anthropic: צפייה ב-X
• הדוקומנטציה של Claude Managed Agents: platform.claude.com
• המרצה בסרטון, Jess מ-Anthropic: jess__yan ב-X