במהלך השנה האחרונה, עבדנו עם עשרות צוותים שבונים סוכני מודלי שפה גדולים (LLM) במגוון תעשיות. מצאנו באופן עקבי שהיישומים המוצלחים ביותר לא השתמשו במסגרות מורכבות או בספריות ייעודיות, אלא נבנו על בסיס תבניות פשוטות וניתנות לשילוב.
בפוסט זה, אנו חולקים את מה שלמדנו מעבודה עם הלקוחות שלנו ומבניית סוכנים בעצמנו, ומספקים עצות מעשיות למפתחים לבניית סוכנים אפקטיביים.
מהם סוכנים?
המונח "סוכן" יכול להיות מוגדר בכמה דרכים. חלק מהלקוחות מגדירים סוכנים כמערכות אוטונומיות לחלוטין הפועלות באופן עצמאי לאורך זמן, תוך שימוש בכלים שונים לביצוע משימות מורכבות. אחרים משתמשים במונח לתיאור יישומים מובנים יותר העוקבים אחר תהליכי עבודה מוגדרים מראש. באנתרופיק, אנו מסווגים את כל הווריאציות הללו כמערכות סוכני, אך מבחינים בהבחנה אדריכלית חשובה בין תהליכי עבודה לסוכנים:
- תהליכי עבודה הן מערכות בהן מודלי LLM וכלים מתואמים באמצעות נתיבי קוד מוגדרים מראש.
- סוכנים, לעומת זאת, הן מערכות בהן מודלי LLM מנהלים באופן דינמי את התהליכים ושימוש בכלים שלהם, ושומרים על שליטה באופן שבו הם מבצעים משימות.
בהמשך, נחקור את שני סוגי המערכות הסוכני לעומק. בנספח 1 ("סוכנים בפועל"), אנו מתארים שני תחומים שבהם לקוחות מצאו ערך מיוחד בשימוש במערכות מסוג זה.
מתי (ומתי לא) להשתמש בסוכנים
בעת בניית יישומים עם מודלי LLM, אנו ממליצים למצוא את הפתרון הפשוט ביותר האפשרי, ולהגביר את המורכבות רק בעת הצורך. ייתכן שמשמעות הדבר היא לא לבנות מערכות סוכני כלל. מערכות סוכני לרוב ממירות זמן השהיה (latency) ועלות בביצועי משימות טובים יותר, ועליכם לשקול מתי פשרה זו הגיונית.
כאשר מורכבות רבה יותר מוצדקת, תהליכי עבודה מציעים יכולת חיזוי ועקביות עבור משימות מוגדרות היטב, בעוד שסוכנים הם האפשרות הטובה יותר כאשר נדרשים גמישות וקבלת החלטות מונחית-מודל בקנה מידה רחב. עבור יישומים רבים, עם זאת, אופטימיזציה של קריאות LLM בודדות עם שליפה ודוגמאות מבוססות הקשר מספיקה בדרך כלל.
מתי ואיך להשתמש במסגרות
ישנן מסגרות רבות המקלות על יישום מערכות סוכני, כולל:
- ה-Claude Agent SDK;
- ה-Strands Agents SDK של AWS;
- Rivet, בונה תהליכי עבודה של LLM עם ממשק משתמש גרפי (Drag and Drop); וכן
- Vellum, כלי GUI נוסף לבנייה ובדיקה של תהליכי עבודה מורכבים.
מסגרות אלו מקלות על תחילת העבודה על ידי פישוט משימות בסיסיות כמו קריאה למודלי LLM, הגדרה וניתוח כלים, ושרשור קריאות יחד. עם זאת, לעיתים קרובות הן יוצרות שכבות הפשטה נוספות שיכולות לטשטש את הפרומפטים והתגובות הבסיסיים, מה שמקשה על ניפוי באגים. הן גם עלולות לפתות להוסיף מורכבות כאשר הגדרה פשוטה יותר הייתה מספיקה.
אנו מציעים למפתחים להתחיל בשימוש ישיר ב-API של מודלי LLM: תבניות רבות ניתנות ליישום בכמה שורות קוד. אם אתם כן משתמשים במסגרת, ודאו שאתם מבינים את הקוד הבסיסי. הנחות שגויות לגבי מה שמתרחש "מתחת למכסה המנוע" הן מקור נפוץ לשגיאות לקוחות.
עיינו בספר המתכונים שלנו לדוגמאות ליישום.
אבני בניין, תהליכי עבודה וסוכנים
בסעיף זה, נחקור את התבניות הנפוצות למערכות סוכני שראינו בשימוש בפועל. נתחיל עם אבן הבניין הבסיסית שלנו – מודל ה-LLM המורחב – ונרחיב בהדרגה את המורכבות, מתהליכי עבודה פשוטים וניתנים להרכבה ועד לסוכנים אוטונומיים.
אבן בניין: מודל ה-LLM המורחב
אבן הבניין הבסיסית של מערכות סוכני היא מודל LLM משופר עם הרחבות כגון שליפה, כלים וזיכרון. המודלים הנוכחיים שלנו יכולים להשתמש באופן פעיל ביכולות אלה – ליצור שאילתות חיפוש משלהם, לבחור כלים מתאימים, ולקבוע איזה מידע לשמר.
אנו ממליצים להתמקד בשני היבטים מרכזיים של היישום: התאמת יכולות אלו למקרה השימוש הספציפי שלכם, והבטחה שהן מספקות ממשק קל ומתועד היטב עבור מודל ה-LLM שלכם. בעוד שיש דרכים רבות ליישם הרחבות אלו, גישה אחת היא באמצעות ה-Model Context Protocol (MCP) ששוחרר לאחרונה, המאפשר למפתחים להשתלב עם מערכת אקולוגית הולכת וגדלה של כלי צד שלישי באמצעות יישום לקוח פשוט.
בהמשך פוסט זה, נניח שלכל קריאת LLM יש גישה ליכולות מורחבות אלו.
תהליך עבודה: שרשור פרומפטים
שרשור פרומפטים מפרק משימה לסדרת שלבים, כאשר כל קריאת LLM מעבדת את הפלט של הקריאה הקודמת. ניתן להוסיף בדיקות תכנותיות (ראו "gate" בתרשים למטה) בכל שלבי ביניים כדי לוודא שהתהליך נשאר במסלול.
מתי להשתמש בתהליך עבודה זה: תהליך עבודה זה אידיאלי למצבים שבהם ניתן לפרק את המשימה בקלות ובבהירות לתת-משימות קבועות. המטרה העיקרית היא להחליף זמן השהיה (latency) בדיוק גבוה יותר, על ידי הפיכת כל קריאת LLM למשימה קלה יותר.
דוגמאות שבהן שרשור פרומפטים שימושי:
- יצירת תוכן שיווקי, ולאחר מכן תרגומו לשפה אחרת.
- כתיבת ראשי פרקים למסמך, בדיקה שהם עומדים בקריטריונים מסוימים, ולאחר מכן כתיבת המסמך על בסיס ראשי הפרקים.
תהליך עבודה: ניתוב
ניתוב (Routing) ממיין קלט ומפנה אותו למשימת המשך מיוחדת. תהליך עבודה זה מאפשר הפרדת אחריות ובניית פרומפטים ייעודיים יותר. ללא תהליך עבודה זה, אופטימיזציה עבור סוג קלט אחד עלולה לפגוע בביצועים על קלטים אחרים.
מתי להשתמש בתהליך עבודה זה: ניתוב עובד היטב עבור משימות מורכבות שבהן קיימות קטגוריות נפרדות שניתן לטפל בהן טוב יותר בנפרד, ושבהן ניתן לטפל בסיווג באופן מדויק, בין אם באמצעות LLM או מודל/אלגוריתם סיווג מסורתי יותר.
דוגמאות שבהן ניתוב שימושי:
- ניתוב סוגים שונים של שאילתות שירות לקוחות (שאלות כלליות, בקשות להחזר כספי, תמיכה טכנית) לתהליכים, פרומפטים וכלים שונים.
- ניתוב שאלות קלות/נפוצות למודלים קטנים וחסכוניים כמו Claude Haiku 4.5, ושאלות קשות/חריגות למודלים בעלי יכולות גבוהות יותר כמו Claude Sonnet 4.5, כדי לייעל את הביצועים.
תהליך עבודה: מקביליות
מודלי LLM יכולים לעיתים לעבוד במקביל על משימה ולאחד את הפלטים שלהם באופן תכנותי. תהליך עבודה זה, מקביליות (Parallelization), מתבטא בשתי וריאציות עיקריות:
- חלוקה לקטעים (Sectioning): פירוק משימה לתת-משימות בלתי תלויות הפועלות במקביל.
- הצבעה (Voting): הפעלת אותה משימה מספר פעמים כדי לקבל פלטים מגוונים.
מתי להשתמש בתהליך עבודה זה: מקביליות יעילה כאשר ניתן לבצע את תת-המשימות המפוצלות במקביל לצורך מהירות, או כאשר נדרשות מספר נקודות מבט או ניסיונות לתוצאות בעלות רמת ודאות גבוהה יותר. עבור משימות מורכבות עם שיקולים מרובים, מודלי LLM בדרך כלל מניבים ביצועים טובים יותר כאשר כל שיקול מטופל על ידי קריאת LLM נפרדת, מה שמאפשר התמקדות בכל היבט ספציפי.
דוגמאות שבהן מקביליות שימושית:
- חלוקה לקטעים:
- יישום מנגנוני הגנה (guardrails) שבהם מופע מודל אחד מעבד שאילתות משתמשים, בעוד אחר מסנן אותן לתוכן או בקשות לא הולמים. זה נוטה להניב ביצועים טובים יותר מאשר כאשר אותה קריאת LLM מטפלת גם במנגנוני ההגנה וגם בתגובה הליבה.
- אוטומציה של הערכות (evals) לביצועי LLM, כאשר כל קריאת LLM מעריכה היבט שונה של ביצועי המודל עבור פרומפט נתון.
- הצבעה:
- בדיקת פיסת קוד לאיתור נקודות תורפה, כאשר מספר פרומפטים שונים בודקים ומסמנים את הקוד אם הם מוצאים בעיה.
- הערכה האם פיסת תוכן נתונה אינה הולמת, כאשר פרומפטים מרובים מעריכים היבטים שונים או דורשים סף הצבעה שונה כדי לאזן בין חיוביים ושליליים כוזבים.
תהליך עבודה: מפקח-עובדים
בתהליך העבודה של מפקח-עובדים (orchestrator-workers), מודל LLM מרכזי מפרק משימות באופן דינמי, מאציל אותן למודלי LLM עובדים, ומסנתז את התוצאות שלהם.
מתי להשתמש בתהליך עבודה זה: תהליך עבודה זה מתאים היטב למשימות מורכבות שבהן אינכם יכולים לחזות את תת-המשימות הנדרשות (בקידוד, למשל, מספר הקבצים שצריך לשנות ואופי השינוי בכל קובץ תלויים ככל הנראה במשימה). בעוד שהוא דומה מבחינה טופוגרפית למקביליות, ההבדל המרכזי הוא גמישותו – תת-המשימות אינן מוגדרות מראש, אלא נקבעות על ידי המפקח על בסיס הקלט הספציפי.
דוגמאות שבהן מפקח-עובדים שימושי:
- מוצרי קידוד שמבצעים שינויים מורכבים במספר קבצים בכל פעם.
- משימות חיפוש הכוללות איסוף וניתוח מידע ממקורות מרובים עבור מידע רלוונטי אפשרי.
תהליך עבודה: מעריך-ממטב
בתהליך העבודה של מעריך-ממטב (evaluator-optimizer), קריאת LLM אחת מייצרת תגובה, בעוד אחרת מספקת הערכה ומשוב בלולאה.
מתי להשתמש בתהליך עבודה זה: תהליך עבודה זה יעיל במיוחד כאשר יש לנו קריטריוני הערכה ברורים, וכאשר שיפור איטרטיבי מספק ערך מדיד. שני הסימנים להתאמה טובה הם, ראשית, שתגובות LLM ניתנות לשיפור באופן מוכח כאשר אדם מביע את משובו; ושנית, שמודל ה-LLM יכול לספק משוב כזה. זה אנלוגי לתהליך הכתיבה האיטרטיבי שעשוי לעבור כותב אנושי בעת הפקת מסמך מלוטש.
דוגמאות שבהן מעריך-ממטב שימושי:
- תרגום ספרותי שבו יש ניואנסים שייתכן שמודל ה-LLM המתרגם לא יקלוט בתחילה, אך מודל LLM מעריך יכול לספק ביקורת מועילה.
- משימות חיפוש מורכבות הדורשות סבבים מרובים של חיפוש וניתוח כדי לאסוף מידע מקיף, כאשר המעריך מחליט אם יש צורך בחיפושים נוספים.
סוכנים
סוכנים מתחילים לצוץ בסביבות ייצור ככל שמודלי LLM מבשילים ביכולות מפתח – הבנת קלטים מורכבים, עיסוק בחשיבה ותכנון, שימוש אמין בכלים, והתאוששות משגיאות. סוכנים מתחילים את עבודתם בפקודה או בדיון אינטראקטיבי עם המשתמש האנושי. לאחר שהמשימה ברורה, סוכנים מתכננים ופועלים באופן עצמאי, ואף עשויים לחזור למשתמש האנושי למידע נוסף או לשיפוט. במהלך הביצוע, חיוני לסוכנים לקבל "אמת בסיסית" (ground truth) מהסביבה בכל שלב (כגון תוצאות קריאת כלים או ביצוע קוד) כדי להעריך את התקדמותם. סוכנים יכולים אז להשהות לצורך משוב אנושי בנקודות בקרה או כאשר הם נתקלים בחסמים. המשימה לרוב מסתיימת עם השלמתה, אך נפוץ גם לכלול תנאי עצירה (כגון מספר איטרציות מקסימלי) כדי לשמור על שליטה.
סוכנים יכולים להתמודד עם משימות מתוחכמות, אך יישומם לרוב פשוט. הם בדרך כלל מודלי LLM המשתמשים בכלים המבוססים על משוב מהסביבה בלולאה. לכן, חיוני לעצב ערכות כלים והתיעוד שלהן באופן ברור ומתחשב. אנו מרחיבים על שיטות עבודה מומלצות לפיתוח כלים בנספח 2 ("הנדסת פרומפטים לכלים שלכם").
מתי להשתמש בסוכנים: סוכנים יכולים לשמש לבעיות פתוחות שבהן קשה או בלתי אפשרי לחזות את מספר השלבים הנדרש, ושבהן אינכם יכולים לקודד נתיב קבוע. מודל ה-LLM יפעל פוטנציאלית במשך איטרציות רבות, ועליכם שתהיה לכם רמה מסוימת של אמון בקבלת ההחלטות שלו. האוטונומיה של הסוכנים הופכת אותם לאידיאליים להרחבת משימות בסביבות מהימנות.
האופי האוטונומי של סוכנים פירושו עלויות גבוהות יותר ופוטנציאל לשגיאות מצטברות. אנו ממליצים על בדיקות מקיפות בסביבות מבודדות (sandboxed environments), יחד עם מנגנוני הגנה מתאימים.
דוגמאות שבהן סוכנים שימושיים:
הדוגמאות הבאות הן מהיישומים שלנו:
- סוכן קידוד לפתרון משימות SWE-bench, הכוללות עריכות בקבצים רבים על בסיס תיאור משימה;
- יישום הייחוס שלנו ל"שימוש במחשב", שבו קלוד משתמש במחשב לביצוע משימות.
שילוב והתאמה אישית של תבניות אלה
אבני הבניין הללו אינן מחייבות. הן תבניות נפוצות שמפתחים יכולים לעצב ולשלב כדי להתאים למקרי שימוש שונים. המפתח להצלחה, כמו בכל תכונות LLM, הוא מדידת ביצועים וביצוע איטרציות על יישומים. כדי לחזור על כך: עליכם לשקול הוספת מורכבות רק כאשר היא משפרת באופן מוכח את התוצאות.
סיכום
הצלחה בתחום ה-LLM אינה קשורה לבניית המערכת המתוחכמת ביותר. היא קשורה לבניית המערכת הנכונה לצרכים שלכם. התחילו עם פרומפטים פשוטים, בצעו להם אופטימיזציה באמצעות הערכה מקיפה, והוסיפו מערכות סוכני מרובות שלבים רק כאשר פתרונות פשוטים יותר אינם מספקים.
בעת יישום סוכנים, אנו מנסים לפעול לפי שלושה עקרונות ליבה:
- שמרו על פשטות בעיצוב הסוכן שלכם.
- תעדוף שקיפות על ידי הצגה מפורשת של שלבי התכנון של הסוכן.
- עצבו בקפידה את ממשק הסוכן-מחשב (ACI) באמצעות תיעוד ובדיקות יסודיים של הכלים.
מסגרות יכולות לעזור לכם להתחיל במהירות, אך אל תהססו להפחית שכבות הפשטה ולבנות עם רכיבים בסיסיים כשאתם עוברים לייצור. על ידי יישום עקרונות אלה, תוכלו ליצור סוכנים שאינם רק חזקים, אלא גם אמינים, ניתנים לתחזוקה ומהימנים על ידי משתמשיהם.
תודות
נכתב על ידי אריק ש' ובארי ז'אנג. עבודה זו נשענת על חוויותינו בבניית סוכנים באנתרופיק ועל התובנות החשובות ששותפו על ידי לקוחותינו, עליהן אנו אסירי תודה עמוקה.
נספח 1: סוכנים בפועל
עבודתנו עם לקוחות חשפה שני יישומים מבטיחים במיוחד עבור סוכני AI, המדגימים את הערך המעשי של התבניות שנדונו לעיל. שני היישומים ממחישים כיצד סוכנים מוסיפים את הערך הרב ביותר למשימות הדורשות הן שיחה והן פעולה, בעלות קריטריוני הצלחה ברורים, מאפשרות לולאות משוב, ומשלבות פיקוח אנושי משמעותי.
א. תמיכת לקוחות
תמיכת לקוחות משלבת ממשקי צ'אטבוט מוכרים עם יכולות משופרות באמצעות שילוב כלים. התאמה זו טבעית לסוכנים פתוחים יותר מכיוון ש:
- אינטראקציות תמיכה עוקבות באופן טבעי אחר זרימת שיחה, תוך דרישה לגישה למידע ופעולות חיצוניים;
- ניתן לשלב כלים לשליפת נתוני לקוחות, היסטוריית הזמנות ומאמרי בסיס ידע;
- פעולות כגון הנפקת החזרים כספיים או עדכון קריאות יכולות להיות מטופלות באופן תכנותי; וגם
- ההצלחה ניתנת למדידה ברורה באמצעות פתרונות המוגדרים על ידי המשתמש.
מספר חברות הוכיחו את היתכנות גישה זו באמצעות מודלי תמחור מבוססי שימוש, הגובים תשלום רק עבור פתרונות מוצלחים, מה שמדגים אמון ביעילות הסוכנים שלהן.
ב. סוכני קידוד
תחום פיתוח התוכנה הראה פוטנציאל יוצא דופן לתכונות LLM, כאשר היכולות מתפתחות מהשלמת קוד ועד לפתרון בעיות אוטונומי. סוכנים יעילים במיוחד מכיוון ש:
- פתרונות קוד ניתנים לאימות באמצעות בדיקות אוטומטיות;
- סוכנים יכולים לבצע איטרציות על פתרונות באמצעות תוצאות בדיקה כמשוב;
- מרחב הבעיה מוגדר היטב ומובנה; וכן
- איכות הפלט ניתנת למדידה אובייקטיבית.
ביישום שלנו, סוכנים יכולים כעת לפתור בעיות GitHub אמיתיות במדד הביצועים SWE-bench Verified על בסיס תיאור בקשת המשיכה בלבד. עם זאת, בעוד שבדיקות אוטומטיות מסייעות לאמת פונקציונליות, סקירה אנושית נותרה קריטית להבטחת התאמת הפתרונות לדרישות המערכת הרחבות יותר.
נספח 2: הנדסת פרומפטים לכלים שלכם
לא משנה איזו מערכת סוכני אתם בונים, כלים יהיו ככל הנראה חלק חשוב מהסוכן שלכם. כלים מאפשרים לקלוד ליצור אינטראקציה עם שירותים ו-API חיצוניים על ידי ציון המבנה וההגדרה המדויקים שלהם ב-API שלנו. כאשר קלוד מגיב, הוא יכלול בלוק של שימוש בכלים בתגובת ה-API אם הוא מתכנן להפעיל כלי. הגדרות ומפרטי כלים צריכים לקבל תשומת לב הנדסת פרומפטים זהה לפרומפטים הכלליים שלכם. בנספח קצר זה, אנו מתארים כיצד לבצע הנדסת פרומפטים לכלים שלכם.
לעתים קרובות ישנן מספר דרכים לציין אותה פעולה. לדוגמה, ניתן לציין עריכת קובץ על ידי כתיבת diff, או על ידי שכתוב הקובץ כולו. עבור פלט מובנה, ניתן להחזיר קוד בתוך markdown או בתוך JSON. בהנדסת תוכנה, הבדלים כאלה הם קוסמטיים וניתנים להמרה ללא אובדן מפורמט אחד לשני. עם זאת, פורמטים מסוימים קשים בהרבה למודל LLM לכתיבה מאחרים. כתיבת diff דורשת ידיעה כמה שורות משתנות בכותרת הבלוק לפני כתיבת הקוד החדש. כתיבת קוד בתוך JSON (לעומת markdown) דורשת בריחה נוספת של מעברי שורה וגרשיים.
הצעותינו לבחירת פורמטים של כלים הן כדלקמן:
- תנו למודל מספיק טוקנים כדי "לחשוב" לפני שהוא מכניס את עצמו לפינה.
- שמרו על פורמט קרוב למה שהמודל ראה באופן טבעי בטקסט באינטרנט.
- ודאו שאין "תקורת" עיצוב כגון צורך לשמור על ספירה מדויקת של אלפי שורות קוד, או ביצוע string-escaping לכל קוד שהוא כותב.
כלל אצבע אחד הוא לחשוב כמה מאמץ מושקע בממשקי אדם-מחשב (HCI), ולתכנן להשקיע בדיוק את אותו מאמץ ביצירת ממשקי סוכן-מחשב (ACI) טובים. הנה כמה מחשבות על איך לעשות זאת:
- הכניסו את עצמכם לנעליים של המודל. האם ברור כיצד להשתמש בכלי זה, בהתבסס על התיאור והפרמטרים, או שתצטרכו לחשוב עליו בקפידה? אם כן, אז זה כנראה נכון גם לגבי המודל. הגדרת כלי טובה כוללת לרוב דוגמאות שימוש, מקרי קצה, דרישות פורמט קלט, וגבולות ברורים מכלים אחרים.
- כיצד תוכלו לשנות שמות או תיאורים של פרמטרים כדי להפוך דברים לברורים יותר? חשבו על כך כעל כתיבת docstring מצוין למפתח ג'וניור בצוות שלכם. זה חשוב במיוחד בעת שימוש בכלים דומים רבים.
- בדקו כיצד המודל משתמש בכלים שלכם: הריצו דוגמאות קלט רבות ב-Workbench שלנו כדי לראות אילו שגיאות המודל עושה, ובצעו איטרציות.
- בצעו Poka-yoke לכלים שלכם. שנו את הארגומנטים כך שיהיה קשה יותר לעשות טעויות.
במהלך בניית הסוכן שלנו עבור SWE-bench, השקענו למעשה יותר זמן באופטימיזציה של הכלים שלנו מאשר בפרומפט הכללי. לדוגמה, גילינו שהמודל יעשה טעויות עם כלים המשתמשים בנתיבי קבצים יחסיים לאחר שהסוכן יצא מספריית השורש. כדי לתקן זאת, שינינו את הכלי לדרוש תמיד נתיבי קבצים מוחלטים – וגילינו שהמודל השתמש בשיטה זו ללא דופי.
