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

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

פיתחנו פתרון דו-שכבתי כדי לאפשר ל-Claude Agent SDK לעבוד ביעילות על פני חלונות הקשר רבים: סוכן אתחול (initializer agent) שמקים את הסביבה בריצה הראשונה, וסוכן קידוד (coding agent) שממונה על התקדמות מצטברת בכל סשן, תוך השארת Artifacts ברורים לסשן הבא. דוגמאות קוד זמינות ב-quickstart המצורף.

האתגר: סוכנים ארוכי טווח

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

אך דחיסה לבדה אינה מספקת. כברירת מחדל, אפילו מודל קידוד חזית כמו Opus 4.5 הפועל על Claude Agent SDK בלולאה על פני מספר חלונות הקשר, יתקשה לבנות אפליקציית ווב באיכות ייצור אם יינתן לו רק פרומפט ברמה גבוהה, כמו "בנה שיבוט של claude.ai".

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

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

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

במהלך ניסויים פנימיים, התמודדנו עם בעיות אלו באמצעות פתרון דו-חלקי:

  1. סוכן אתחול (Initializer agent): סשן הסוכן הראשון משתמש בפרומפט מיוחד המבקש מהמודל להקים את הסביבה הראשונית: סקריפט init.sh, קובץ claude-progress.txt המתעד את פעולות הסוכנים, ו-commit ראשוני של git המציג אילו קבצים נוספו.
  2. סוכן קידוד (Coding agent): כל סשן עוקב מבקש מהמודל לבצע התקדמות מצטברת, ולאחר מכן להשאיר עדכונים מובנים.1

התובנה המרכזית כאן הייתה מציאת דרך שבה סוכנים יוכלו להבין במהירות את מצב העבודה כשהם מתחילים עם חלון הקשר חדש, דבר המושג באמצעות קובץ claude-progress.txt יחד עם היסטוריית ה-git. ההשראה לשיטות אלו הגיעה מהידע כיצד מהנדסי תוכנה יעילים פועלים ביום-יום.

ניהול סביבת העבודה

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

רשימת תכונות

כדי לטפל בבעיה של הסוכן המנסה לפתח את כל האפליקציה בבת אחת או רואה את הפרויקט כמושלם מוקדם מדי, הנחינו את סוכן האתחול לכתוב קובץ מקיף של דרישות תכונות, המרחיב את הפרומפט הראשוני של המשתמש. בדוגמת שיבוט ה-claude.ai, המשמעות הייתה מעל 200 תכונות, כגון "משתמש יכול לפתוח צ'אט חדש, להקליד שאילתה, ללחוץ אנטר ולראות תגובת AI". כל התכונות הללו סומנו בתחילה כ"נכשלות" (failing) כדי שלסוכני קידוד מאוחרים יותר תהיה תמונה ברורה של פונקציונליות מלאה.

{
    "category": "functional",
    "description": "New chat button creates a fresh conversation",
    "steps": [
      "Navigate to main interface",
      "Click the 'New Chat' button",
      "Verify a new conversation is created",
      "Check that chat area shows welcome state",
      "Verify conversation appears in sidebar"
    ],
    "passes": false
  }

אנו מנחים סוכני קידוד לערוך קובץ זה רק על ידי שינוי הסטטוס של שדה ה-passes, ומשתמשים בהוראות מפורשות וחזקות כמו "אין זה מקובל להסיר או לערוך בדיקות מכיוון שזה עלול להוביל לפונקציונליות חסרה או פגומה". לאחר כמה ניסויים, החלטנו להשתמש ב-JSON למטרה זו, מכיוון שהמודל נוטה פחות לשנות או לדרוס קובצי JSON באופן בלתי הולם, בהשוואה לקובצי Markdown.

התקדמות מצטברת

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

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

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

בדיקות

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

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

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

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

התארגנות מהירה

עם כל האמור לעיל, כל סוכן קידוד מונחה לבצע סדרת צעדים כדי להתמצא בסביבה, חלקם בסיסיים למדי אך עדיין מועילים:

  1. הרץ pwd כדי לראות באיזו תיקייה אתה עובד. תוכל לערוך קבצים רק בתיקייה זו.
  2. קרא את יומני ה-git ואת קבצי ההתקדמות כדי להתעדכן במה שנעשה לאחרונה.
  3. קרא את קובץ רשימת התכונות ובחר את התכונה בעלת העדיפות הגבוהה ביותר שטרם הושלמה כדי לעבוד עליה.

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

במקרה של שיבוט ה-claude.ai, המשמעות הייתה שהסוכן תמיד הפעיל את שרת הפיתוח המקומי והשתמש ב-Puppeteer MCP כדי להתחיל צ'אט חדש, לשלוח הודעה ולקבל תגובה. זה הבטיח ש-Claude יוכל לזהות במהירות אם האפליקציה נותרה במצב שבור, ולתקן מיד כל באג קיים. אם הסוכן היה מתחיל ליישם תכונה חדשה במקום זאת, סביר להניח שהבעיה הייתה מחמירה.

בהתחשב בכל זה, סשן טיפוסי מתחיל בהודעות העוזר הבאות:

[Assistant] I'll start by getting my bearings and understanding the current state of the project.
[Tool Use] <bash - pwd>
[Tool Use] <read - claude-progress.txt>
[Tool Use] <read - feature_list.json>
[Assistant] Let me check the git log to see recent work.
[Tool Use] <bash - git log --oneline -20>
[Assistant] Now let me check if there's an init.sh script to restart the servers.
<Starts the development server>
[Assistant] Excellent! Now let me navigate to the application and verify that some fundamental features are still working.
<Tests basic functionality>
[Assistant] Based on my verification testing, I can see that the fundamental functionality is working well. The core chat features, theme switching, conversation loading, and error handling are all functioning correctly. Now let me review the tests.json file more comprehensively to understand what needs to be implemented next.
<Starts work on a new feature>

עבודה עתידית

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

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

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

תודות

נכתב על ידי ג'סטין יאנג (Justin Young). תודות מיוחדות לדייוויד הרשי (David Hershey), פריתווי ראג'אסקרן (Prithvi Rajasakeran), ג'רמי האדפילד (Jeremy Hadfield), נאיה בוסקל (Naia Bouscal), מייקל טינגלי (Michael Tingley), ג'סי מו (Jesse Mu), ג'ייק איטון (Jake Eaton), מריוס בולאנדרה (Marius Buleandara), מגי וו (Maggie Vo), פדרם נאוויד (Pedram Navid), נדין יאסר (Nadine Yasser) ואלכס נוטוב (Alex Notov) על תרומתם.

עבודה זו משקפת את המאמצים המשותפים של מספר צוותים באנתרופיק שאפשרו ל-Claude לבצע בבטחה הנדסת תוכנה אוטונומית ארוכת טווח, ובמיוחד צוותי ה-code RL ו-Claude Code. מועמדים מעוניינים המעוניינים לתרום מוזמנים להגיש מועמדות ב-anthropic.com/careers.

הערות שוליים

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