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

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

מהם סוכנים?

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

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

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

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

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

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

מתי וכיצד להשתמש בפריימוורקים

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

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

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

ראו את ספר המתכונים שלנו ליישומים לדוגמה.

אבני בניין, זרימות עבודה וסוכנים

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

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

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

תרשים המציג LLM מוגבר עם יכולות שליפה, כלים וזיכרון.
התרשים מציג את אבן הבניין הבסיסית של סוכן: LLM המשולב עם יכולות נוספות.

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

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

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

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

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

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

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

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

זרימת עבודה: ניתוב

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

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

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

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

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

זרימת עבודה: הקבלה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוכנים

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

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

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

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

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

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

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

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

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

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

סיכום

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

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

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

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

תודות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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