בונים סוכני AI יעילים? אנתרופיק חושפת את התובנות מהשטח

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

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

מהם סוכני AI?

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

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

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

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

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

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

מתי ואיך להשתמש בפלטפורמות פיתוח?

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

• ה-Claude Agent SDK;
• Strands Agents SDK מבית AWS;
• Rivet, בונה תהליכי עבודה ויזואלי למודלי LLM בשיטת גרור ושחרר; וכן
• Vellum, כלי GUI נוסף לבנייה ובדיקה של תהליכי עבודה מורכבים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוכנים (Agents)

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

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

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

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

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

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

• סוכן קידוד (Coding Agent) לפתרון משימות SWE-bench, הכוללות עריכות בקבצים רבים בהתבסס על תיאור המשימה;
• יישום הייחוס שלנו 'שימוש במחשב', שבו קלוד משתמש במחשב לביצוע משימות.

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

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

סיכום

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

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

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

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

תודות

נכתב על ידי אריק שלונץ (Erik Schluntz) ובארי ז'אנג (Barry Zhang). עבודה זו נשענת על חוויותינו בבניית סוכנים באנתרופיק ועל התובנות היקרות ששיתפו לקוחותינו, שלהם אנו אסירי תודה עמוקה.

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

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

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

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

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

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

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

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

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

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

נספח 2: Prompt Engineering לכלים שלכם

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

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

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

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

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

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

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