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

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

מהם סוכנים?

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

  • תהליכי עבודה (Workflows) הן מערכות שבהן LLM וכלים מתואמים באמצעות נתיבי קוד מוגדרים מראש.
  • סוכנים (Agents), לעומת זאת, הן מערכות שבהן LLM מנהלים באופן דינמי את התהליכים ושימוש הכלים שלהם, ושומרים על שליטה באופן שבו הם מבצעים משימות.

בהמשך, נחקור את שני הסוגים הללו של מערכות סוכני AI בפירוט. בנספח 1 ("סוכנים בפועל"), נתאר שני תחומים שבהם לקוחות מצאו ערך מיוחד בשימוש במערכות מסוג זה.

מתי (ומתי לא) להשתמש בסוכנים

בעת בניית יישומים עם LLM, אנו ממליצים למצוא את הפתרון הפשוט ביותר האפשרי, ולהגביר את המורכבות רק בעת הצורך. הדבר עשוי אומר שלא לבנות מערכות סוכני AI כלל. מערכות סוכני AI לרוב מביאות איתן פשרה בין זמן תגובה (latency) ועלות לביצועי משימה טובים יותר, ועליכם לשקול מתי פשרה זו הגיונית.

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

מתי ואיך להשתמש בפריימוורקים

קיימים פריימוורקים רבים שהופכים את מערכות סוכני AI לקלות יותר ליישום, כולל:

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

אנו מציעים למפתחים להתחיל בשימוש ישיר ב-API של LLM: דפוסים רבים ניתנים ליישום בכמה שורות קוד. אם אתם כן משתמשים בפריימוורק, ודאו שאתם מבינים את הקוד הבסיסי. הנחות שגויות לגבי מה שמתחת למכסה המנוע הן מקור נפוץ לשגיאות לקוחות.

ראו את הקוקבוק שלנו ליישומים לדוגמה.

אבני בניין, תהליכי עבודה וסוכנים

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

אבן בניין: ה-LLM המורחב

אבן הבניין הבסיסית של מערכות סוכני AI היא LLM משופר עם הרחבות כגון שליפה (retrieval), כלים וזיכרון. המודלים הנוכחיים שלנו יכולים להשתמש באופן פעיל ביכולות אלו – ליצור שאילתות חיפוש משלהם, לבחור כלים מתאימים ולקבוע איזו מידע לשמר.

תרשים של LLM מורחב עם יכולות שליפה, כלים וזיכרון.
ה-LLM המורחב משלב יכולות כמו שליפה, כלים וזיכרון כדי להרחיב את יכולותיו.

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

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

תהליך עבודה: שרשור פרומפטים

שרשור פרומפטים מפרק משימה לסדרת שלבים, כאשר כל קריאת LLM מעבדת את הפלט של הקודמת. ניתן להוסיף בדיקות תכנותיות (ראו "שער" בתרשים למטה) בכל שלבי הביניים כדי לוודא שהתהליך עדיין במסלול הנכון.

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

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

דוגמאות שבהן שרשור פרומפטים שימושי:

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

תהליך עבודה: ניתוב

ניתוב (Routing) ממיין קלט ומפנה אותו למשימת המשך מיוחדת. תהליך עבודה זה מאפשר הפרדת דאגות (separation of concerns) ובניית פרומפטים ממוקדים יותר. ללא תהליך עבודה זה, אופטימיזציה לסוג קלט אחד עלולה לפגוע בביצועים על קלטים אחרים.

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

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

דוגמאות שבהן ניתוב שימושי:

  • הפניית סוגים שונים של פניות שירות לקוחות (שאלות כלליות, בקשות החזר, תמיכה טכנית) לתהליכים, פרומפטים וכלים שונים במורד הזרם.
  • ניתוב שאלות קלות/נפוצות למודלים קטנים וחסכוניים כמו Claude Haiku 4.5 ושאלות קשות/חריגות למודלים בעלי יכולת גבוהה יותר כמו Claude Sonnet 4.5 כדי לייעל את הביצועים.

תהליך עבודה: מקביליות

LLM יכולים לפעמים לעבוד בו-זמנית על משימה ולאחד את הפלטים שלהם באופן תכנותי. תהליך עבודה זה, מקביליות (parallelization), מתבטא בשתי וריאציות עיקריות:

  • חלוקה לקטעים (Sectioning): פירוק משימה לתתי-משימות עצמאיות המורצות במקביל.
  • הצבעה (Voting): הרצת אותה משימה מספר פעמים כדי לקבל פלטים מגוונים.
תרשים של תהליך עבודה של מקביליות עם חלוקה לקטעים או הצבעה.
מקביליות מאפשרת לחלק משימות לתתי-משימות מקבילות או להריץ את אותה משימה מספר פעמים.

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

דוגמאות שבהן מקביליות שימושית:

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

תהליך עבודה: מנהל תזמורת-עובדים

בתהליך העבודה של מנהל תזמורת-עובדים (Orchestrator-workers), LLM מרכזי מפרק משימות באופן דינמי, מפצל אותן ל-LLM עובדים, ומסנתז את תוצאותיהם.

תרשים של תהליך עבודה מנהל תזמורת-עובדים, עם LLM מרכזי המפזר משימות ל-LLM עובדים.
מודל LLM מרכזי מנהל פירוק והאצלת משימות למודלים עובדים וסינתוז התוצאות.

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

דוגמאות שבהן מנהל תזמורת-עובדים שימושי:

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

תהליך עבודה: מעריך-מייעל

בתהליך העבודה של מעריך-מייעל (Evaluator-optimizer), קריאת LLM אחת מייצרת תגובה בעוד אחרת מספקת הערכה ופידבק בלולאה.

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

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

דוגמאות שבהן מעריך-מייעל שימושי:

  • תרגום ספרותי שבו יש ניואנסים ש-LLM המתרגם עשוי שלא לקלוט בתחילה, אך שבו LLM מעריך יכול לספק ביקורות שימושיות.
  • משימות חיפוש מורכבות הדורשות סבבים מרובים של חיפוש וניתוח כדי לאסוף מידע מקיף, כאשר המעריך מחליט אם יש צורך בחיפושים נוספים.

סוכנים

סוכנים מתחילים לצוץ בפרודקשן ככל שה-LLM מבשילים ביכולות מפתח – הבנת קלטים מורכבים, מעורבות בחשיבה ותכנון, שימוש אמין בכלים, והתאוששות משגיאות. סוכנים מתחילים את עבודתם בפקודה מהמשתמש האנושי או בדיון אינטראקטיבי עמו. לאחר שהמשימה ברורה, סוכנים מתכננים ופועלים באופן עצמאי, ואף יכולים לחזור לאדם למידע או שיפוט נוסף. במהלך הביצוע, חיוני לסוכנים לקבל "אמת בסיס" (ground truth) מהסביבה בכל שלב (כגון תוצאות קריאת כלי או ביצוע קוד) כדי להעריך את התקדמותם. סוכנים יכולים אז לעצור לפידבק אנושי בנקודות בקרה או כאשר הם נתקלים בחסימות. המשימה לרוב מסתיימת עם השלמתה, אך נפוץ גם לכלול תנאי עצירה (כגון מספר איטרציות מקסימלי) כדי לשמור על שליטה.

סוכנים יכולים להתמודד עם משימות מתוחכמות, אך היישום שלהם לרוב פשוט. הם בדרך כלל LLM המשתמשים בכלים המבוססים על פידבק סביבתי בלולאה. לכן, חיוני לתכנן ערכות כלים והתיעוד שלהם באופן ברור ומתחשב. אנו מרחיבים על שיטות עבודה מומלצות לפיתוח כלים בנספח 2 ("הנדסת פרומפטים עבור הכלים שלכם").

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

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

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

דוגמאות שבהן סוכנים שימושיים:

הדוגמאות הבאות הן מהיישומים שלנו:

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

שילוב והתאמה אישית של דפוסים אלו

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

סיכום

הצלחה בתחום ה-LLM אינה קשורה לבניית המערכת המתוחכמת ביותר. היא קשורה לבניית המערכת הנכונה לצרכים שלכם. התחילו עם פרומפטים פשוטים, בצעו להם אופטימיזציה עם הערכה מקיפה, והוסיפו מערכות סוכני AI מרובות שלבים רק כאשר פתרונות פשוטים יותר אינם מספקים.

בעת יישום סוכנים, אנו מנסים לעקוב אחר שלושה עקרונות ליבה:

  1. שמרו על פשטות בעיצוב הסוכן שלכם.
  2. תעדיפו שקיפות על ידי הצגה מפורשת של שלבי התכנון של הסוכן.
  3. עצבו בקפידה את ממשק הסוכן-מחשב (ACI) שלכם באמצעות תיעוד ובדיקות יסודיות של הכלים.

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

תודות

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

נספח 1: סוכנים בפועל

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

א. תמיכת לקוחות

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

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

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

ב. סוכני קידוד

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

  • פתרונות קוד ניתנים לאימות באמצעות בדיקות אוטומטיות;
  • סוכנים יכולים לבצע איטרציות על פתרונות באמצעות תוצאות בדיקה כפידבק;
  • מרחב הבעיה מוגדר היטב ומבני; ו-
  • ניתן למדוד את איכות הפלט באופן אובייקטיבי.

ביישום שלנו, סוכנים יכולים כעת לפתור בעיות GitHub אמיתיות במדד הביצועים SWE-bench Verified בהתבסס על תיאור ה-pull request בלבד. עם זאת, בעוד שבדיקות אוטומטיות עוזרות לאמת פונקציונליות, סקירה אנושית נשארת קריטית להבטחת התאמת הפתרונות לדרישות המערכת הרחבות יותר.

נספח 2: הנדסת פרומפטים עבור הכלים שלכם

לא משנה איזו מערכת סוכני AI אתם בונים, כלים יהיו ככל הנראה חלק חשוב מהסוכן שלכם. כלים מאפשרים לקלוד ליצור אינטראקציה עם שירותים ו-API חיצוניים על ידי ציון המבנה וההגדרה המדויקים שלהם ב-API שלנו. כאשר קלוד מגיב, הוא יכלול בלוק שימוש בכלי בתגובת ה-API אם הוא מתכנן להפעיל כלי. יש להקדיש להגדרות ולמפרטים של הכלים תשומת לב הנדסת פרומפטים (prompt engineering) זהה לזו של הפרומפטים הכלליים שלכם. בנספח קצר זה, נתאר כיצד לבצע הנדסת פרומפטים עבור הכלים שלכם.

לעתים קרובות קיימות מספר דרכים לציין את אותה פעולה. לדוגמה, ניתן לציין עריכת קובץ על ידי כתיבת diff, או על ידי שכתוב הקובץ כולו. עבור פלט מובנה, ניתן להחזיר קוד בתוך markdown או בתוך JSON. בהנדסת תוכנה, הבדלים כאלה הם קוסמטיים וניתן להמיר אותם ללא אובדן מפורמט אחד למשנהו. עם זאת, פורמטים מסוימים קשים בהרבה ל-LLM לכתיבה מאחרים. כתיבת diff דורשת ידיעה כמה שורות משתנות בכותרת הנתח לפני כתיבת הקוד החדש. כתיבת קוד בתוך JSON (בהשוואה ל-markdown) דורשת בריחה (escaping) נוספת של שורות חדשות וגרשיים.

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

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

כלל אצבע אחד הוא לחשוב כמה מאמץ מושקע בממשקי אדם-מחשב (HCI), ולתכנן להשקיע מאמץ דומה ביצירת ממשקי סוכן-מחשב (ACI) טובים. הנה כמה מחשבות על איך לעשות זאת:

  • שימו את עצמכם בנעלי המודל. האם ברור כיצד להשתמש בכלי זה, בהתבסס על התיאור והפרמטרים, או שתצטרכו לחשוב עליו בזהירות? אם כן, אז כנראה שזה נכון גם לגבי המודל. הגדרת כלי טובה כוללת לרוב שימוש לדוגמה, מקרי קצה, דרישות פורמט קלט, וגבולות ברורים מכלים אחרים.
  • כיצד תוכלו לשנות שמות פרמטרים או תיאורים כדי להפוך דברים לברורים יותר? חשבו על זה כעל כתיבת docstring מצוין למפתח ג'וניור בצוות שלכם. זה חשוב במיוחד בעת שימוש בכלים דומים רבים.
  • בחנו כיצד המודל משתמש בכלים שלכם: הריצו קלטים לדוגמה רבים ב-Workbench שלנו כדי לראות אילו שגיאות המודל עושה, ובצעו איטרציות.
  • בצעו Poka-yoke לכלים שלכם. שנו את הארגומנטים כך שיהיה קשה יותר לעשות טעויות.

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