הערה: רוב סביבת הכלים המתוארת בפוסט זה השתנתה מאז דצמבר 2024. לגישה הנוכחית שלנו, ראו כיצד בנינו את Claude Managed Agents ו-התיעוד של Managed Agents.

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

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

מהם סוכנים?

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

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

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

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

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

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

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

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

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

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

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

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

אבן בניין: מודל ה-LLM המורחב (Augmented LLM)

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

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

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

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

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

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

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

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

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

תהליך עבודה: ניתוב (Routing)

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

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

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

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

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

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

תרשים המתאר מקביליות: קלט אחד מוביל לשני LLM או יותר הפועלים במקביל, ותוצאותיהם מתאחדות.
איור 4: תהליך עבודה של מקביליות (Parallelization).

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

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

תהליך עבודה: תזמרן-עובדים (Orchestrator-workers)

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

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

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

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

תהליך עבודה: מעריך-מייעל (Evaluator-optimizer)

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

תרשים המתאר תהליך מעריך-מייעל: LLM מייצר תגובה, LLM אחר מעריך אותה, והמשוב חוזר ל-LLM המייצר בלולאה לשיפור.
איור 6: תהליך עבודה של מעריך-מייעל (Evaluator-optimizer).

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

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

סוכנים (Agents)

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

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

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

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

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

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

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

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

שילוב והתאמה אישית של תבניות אלו

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

סיכום

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

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

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

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

תודות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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