Agent Frameworks
איזו מסגרת לבחור?
רוצה לבנות סוכן AI רציני? יש עשרות מסגרות, וכל אחת מושכת אותך לכיוון אחר. במדריך נעשה סדר בין חמש המובילות — LangGraph, CrewAI, Claude Agent SDK, AutoGen ו-Pydantic AI — נסביר מתי כל אחת מנצחת, ונראה מתי עדיף לבנות סוכן בלי framework בכלל.
ההחלטה הכי פחות חשובה שתקבלו
הדף הזה משווה מסגרות, וכדאי לפתוח אותו במשפט שחוסך שבועות: בחירת הפריימוורק היא אחת ההחלטות הפחות משפיעות בפרויקט סוכן. סוכנים נכשלים בייצור מסיבות שאף מסגרת לא פותרת — הקשר שתפח, קריאה שבוצעה פעמיים, כלי שהחזיר תשובה ריקה שנראתה כמו הצלחה, ואף אחד לא ידע לומר למה הסוכן החליט מה שהחליט.
מה שכן משתנה בין המסגרות הוא כמה קוד תכתבו וכמה שליטה תוותרו. זה הבדל אמיתי ושווה לבחור בו נכון, והוא לא ההבדל בין פרויקט שמצליח לפרויקט שנתקע.
לכן הדף הזה לא מסתפק בהשוואה: אחרי הסקירה יש שני סעיפים שחשובים ממנה — מה תצטרכו לבנות בעצמכם בכל מקרה, וכמה קשה לצאת ממה שבחרתם.
אם אתם מתלבטים בין שתי מסגרות יותר משלושה ימים — בחרו את זו שהתיעוד שלה ברור לכם יותר והמשיכו. הזמן שנשרף בהתלבטות גדול מההפרש ביניהן.
מה מסגרת באמת נותנת
אפשר לבנות סוכן עם קריאות ישירות למודל, וזו אפילו נקודת הפתיחה הנכונה. מה שמתחיל לכאוב כשהסוכן גדל הוא ארבעה דברים, וזה מה שמסגרת נותנת:
- לולאת ההחלטה. לקרוא למודל, לזהות שהוא ביקש כלי, להריץ אותו, להחזיר את התוצאה, ולחזור — עם תנאי עצירה שמונע לולאה אינסופית.
- ניהול מצב. מה כבר קרה, מה נשאר, ומה התוצאות. כאן נמצא ההבדל הגדול ביותר בין המסגרות.
- חיבור כלים. להפוך פונקציה בקוד להגדרה שהמודל רואה, ולנתב בחזרה את הקריאה.
- תשתית סביב. הזרמה, ניסיונות חוזרים, ולעתים גם תיעוד מובנה.
שימו לב למה שאין ברשימה: אף מסגרת לא תחליט בשבילכם מתי לעצור לאישור אנושי, לא תהפוך כלי לבטוח לקריאה כפולה, ולא תדע אם הסוכן בחר נכון. אלה ההחלטות שקובעות, והן שלכם בכל מקרה.
הציר האמיתי: שליטה מול מהירות
כל המסגרות יושבות על ציר אחד, ושני קצותיו מתאימים למצבים שונים לגמרי.
בקצה השליטה אתם מגדירים כל שלב וכל מעבר במפורש. יותר קוד, ותמורתו: אתם יכולים לענות על השאלה "למה הסוכן עשה את זה" בלי לנחש. זה הקצה שמתאים כשהסוכן נוגע בכסף, במחיקה או בלקוחות.
בקצה המהירות אתם מגדירים תפקידים ומטרה, והמסגרת מתאמת ביניהם. הרבה פחות קוד, ופרוטוטייפ עומד תוך שעות. המחיר מתגלה כשמשהו משתבש: ההתנהגות שלא הגדרתם היא גם ההתנהגות שאי אפשר לתקן במדויק.
הכלל שנובע מזה: ככל שהסוכן עושה יותר נזק כשהוא טועה, כך שווה יותר להיות בקצה השליטה. סוכן שמסכם מסמכים יכול לחיות בקצה המהיר; סוכן ששולח מיילים ללקוחות לא.
איך נראית לולאת סוכן בלי מסגרת
שווה לראות אותה פעם אחת, כי היא מסירה את המסתורין — וגם מבהירה בדיוק מה מסגרת חוסכת:
state = {"done": [], "step": 0}
while state["step"] < MAX_STEPS:
reply = call_model(
system=SYSTEM,
messages=history,
tools=TOOLS, # רק הכלים הרלוונטיים לשלב
)
if not reply.tool_calls: # המודל סיים
return reply.text
for call in reply.tool_calls:
if call.name in NEEDS_APPROVAL:
return ask_human(call) # עוצר ומציג תוכן
key = f"{state['step']}:{call.name}" # מפתח שנוצר אצלנו
result = run_tool(call, request_id=key)
history.append(tool_result(call, prune(result)))
state["done"].append(key)
state["step"] += 1
return {"ok": False, "reason": "הגיע לתקרת הצעדים"}
ארבעה פרטים בקוד הזה חשובים יותר מהמבנה שלו, וכולם נשארים באחריותכם בכל מסגרת: תקרת צעדים שמונעת לולאה אינסופית; מפתח שנוצר מהצעד ולא מהמודל, שהוא מה שהופך קריאה כפולה לבטוחה; prune, שגוזם את תוצאת הכלי לפני שהיא נכנסת להיסטוריה; ועצירה לאישור שמחזירה את התוכן ולא רק את שם הפעולה.
מה תבנו בעצמכם, בכל מסגרת
זה הסעיף שהופך את הבחירה למשנית. חמישה דברים שאף מסגרת לא נותנת מהקופסה, ובלעדיהם סוכן לא מגיע לייצור:
- מצב מחוץ לתמליל. מה כבר בוצע נשמר בטבלה, לא בהיסטוריית ההודעות. זה מה שמונע ביצוע כפול אחרי ניתוק, וזה מה שמאפשר להמשיך מאיפה שנעצרתם. מסגרות מציעות "זיכרון"; ההחלטה מה נכנס אליו היא שלכם.
- אידמפוטנטיות. כל כלי שמחייב, שולח או יוצר רשומה חייב להיות בטוח לקריאה כפולה — עם מפתח ייחודיות שנוצר בקוד שלכם ולא על ידי המודל. סוכנים מנסים שוב; זו לא אפשרות תיאורטית.
- אישור אנושי אמיתי. מסגרות מספקות נקודת עצירה. מה שמגיע למסך — "לאשר הפעלת send_email?" מול "נשלח ללקוח כך וכך, זה הטקסט, זו העלות" — קובע אם האישור שווה משהו אחרי הפעם החמישית.
- מדידה. האם נבחר הכלי הנכון, האם הפרמטרים תקינים, ומה קרה אחרי כישלון. בלי זה כל שינוי בתיאור כלי הוא ניחוש.
- גבולות הרשאה. "אל תמחק" בהנחיה היא בקשה. ההגבלה חייבת להיות במימוש הכלי, לפי זהות המשתמש.
אם תעשו את החמישה האלה היטב, כל מסגרת תעבוד. אם תדלגו עליהם, שום מסגרת לא תציל אתכם — והיא גם תקשה עליכם לאתר את הבעיה, כי היא מסתירה חלק מהלולאה.
המסגרות, בקצרה
בלי להיכנס לגרסאות שמתחלפות, אלה הגישות ומה כל אחת מתאימה לו:
- גרף מצב מפורש (LangGraph). הסוכן מיוצג כגרף — צמתים הם שלבים, קשתות הם מעברים, ומצב עובר ביניהם. אתם מגדירים בדיוק מתי עוברים לאן, כולל לולאות, ניתוב מותנה ונקודות עצירה. יש שמירת מצב בין הרצות, ולכן אפשר לחזור לנקודה ולבדוק מה קרה — היכולת היחידה ברשימה הזו שקשה מאוד לשחזר לבד. עקומת למידה תלולה יחסית.
- תפקידים וצוות (CrewAI). מגדירים סוכנים לפי תפקיד ומטרה, והמסגרת מתאמת ביניהם. הכי מהיר להגיע למשהו שעובד, והכי פחות שליטה בפרטים. מצוין להדגמה ולחקירת רעיון.
- לולאת סוכן מובנית (Claude Agent SDK). לולאה מוכנה עם כלים מובנים, חזקה במיוחד למשימות קוד ועבודה מול מחשב.
- שיחות בין סוכנים (AutoGen ומשפחתו). סוכנים שמדברים זה עם זה. בולט במחקר ובסביבות מיקרוסופט.
- בטיחות טיפוסים (Pydantic AI). פייתוני, עם דגש על פלט מובנה ואימות. מתאים למי שחשוב לו שהתוצאה תיכנס למערכת בלי הפתעות.
ההבדלים האלה אמיתיים — והם קטנים לעומת ההבדל בין סוכן שבנוי נכון לסוכן שלא.
מה נשבר אחרי עשרה צעדים
סוכן שעובד מצוין בשלושה צעדים ומתחיל להתנהג מוזר בשמיני הוא התופעה המוכרת ביותר בתחום, ויש לה שלוש סיבות שחוזרות — אף אחת מהן אינה המודל.
ההקשר מתמלא בארכיאולוגיה. כל צעד הוסיף קריאת כלי ותוצאה מלאה, ובשלב מסוים הסוכן קורא בעיקר תוצאות של בדיקות שהסתיימו מזמן. הוא לא יודע מה כבר לא רלוונטי — הוא רואה טקסט, וכל טקסט נראה לו כמו מידע.
טעויות מצטברות. שגיאה בצעד השני נכנסה להקשר, והשלישי התייחס אליה כעובדה. שרשרת של חמישה צעדים מסוכנת הרבה יותר מפי חמישה מצעד אחד — ולכן שרשראות קצרות עם נקודת עצירה באמצע בטוחות בהרבה מארוכות ברצף.
תכנון מוקדם מדי. מודל שהתבקש לתכנן חמישה צעדים מראש תכנן לפי מה שהניח שיחזור, ואז נצמד לתוכנית גם כשהמציאות שונה. צעד-אחר-צעד — לבצע אחד, לראות מה חזר, להחליט על הבא — עובד טוב יותר כמעט תמיד.
והתיקון לשלושתם אינו מסגרת אחרת אלא גיזום בנקודת המקור וסיכום מצב שנכתב מחדש בכל צעד: שורה אחת עדכנית שאומרת מה כבר בוצע, במקום חמש תוצאות מלאות שמהן צריך להסיק.
מתי לא להשתמש בכלום
זו אפשרות לגיטימית ולעתים קרובות הנכונה, ומעט מדי אנשים שוקלים אותה:
- כשיש שלושה עד חמישה כלים ולולאה פשוטה. לולאת
whileעם קריאה למודל, זיהוי בקשת כלי והרצה היא כמאה שורות. היא גם קלה בהרבה לאבחון, כי אין בה שכבה שמסתירה. - כשהתהליך ידוע מראש. אם תמיד מבצעים א׳ ואז ב׳ ואז ג׳, זו אוטומציה רגילה. אל תיתנו למודל להחליט על משהו שכבר הוחלט — זה גם זול יותר וגם צפוי.
- בפרויקט ראשון. לכתוב את הלולאה פעם אחת ביד מלמד מה מסגרת עושה בשבילכם, ואז הבחירה נעשית מתוך ידיעה ולא מתוך רשימת תכונות.
הכלל: מסגרת מצדיקה את עצמה כשאתם מוצאים את עצמכם כותבים אותה מחדש — ניהול מצב, חידוש אחרי ניתוק, תיאום בין כמה סוכנים. לא לפני.
כמה כלים זה יותר מדי
אין מספר קסם, ויש תופעה עקבית: ככל שרשימת הכלים ארוכה יותר, כך הבחירה מדויקת פחות. עם חמישה כלים מובחנים היטב הדיוק גבוה; עם שלושים שחלקם חופפים, המודל מתחיל לבחור את הדומה במקום את הנכון.
ויש לזה גם מחיר ישיר שקל לשכוח לספור: הגדרות הכלים נשלחות בכל קריאה, כולל תיאורי הפרמטרים. בסוכן שמבצע חמישה־עשר צעדים, אותו נתח קבוע משולם חמש־עשרה פעמים.
שלוש דרכים לטפל, לפי סדר הכדאיות: לאחד כלים שחופפים — אם שניים עושים כמעט אותו דבר, המודל יתלבט ביניהם לנצח; לטעון לפי שלב — סוכן בשלב בירור צריך כלי קריאה בלבד, והשאר נטענים רק בביצוע; וניתוב בשתי רמות, שבו מודל ראשון מחליט על תחום ואז נטענים רק הכלים שלו.
ומה שקובע יותר מהמספר: השם והתיאור. המודל רואה רק אותם — לא את המימוש. cancel_subscription עדיף על subscription_handler, ותיאור שאומר מתי לקרוא עדיף על תיאור שאומר איך הכלי עובד.
כמה קשה לצאת
מסגרות בתחום הזה מתחלפות מהר, וזו לא סיבה לא לבחור — זו סיבה לבחור עם עין אחת על היציאה. שלושה דברים קובעים כמה תכאב ההחלפה:
- איפה יושבת הלוגיקה העסקית. אם הכלים שלכם הם פונקציות פייתון רגילות שהמסגרת רק עוטפת — ההחלפה היא עבודה של ימים. אם הלוגיקה נכתבה בתוך מבני המסגרת, זו כתיבה מחדש.
- איפה יושב המצב. מצב בטבלה שלכם עובר בין מסגרות. מצב במנגנון הפנימי של המסגרת לא עובר.
- מי מחזיק את ההנחיות. טקסטים שנמצאים בקבצים משלכם הם נכס; טקסטים מפוזרים בתוך הגדרות של המסגרת הם חוב.
ההמלצה הפשוטה: כתבו את הכלים ואת הלוגיקה כקוד רגיל, ותנו למסגרת לתאם בלבד. זה עולה מעט יותר בהתחלה ומוריד את עלות ההחלפה כמעט לאפס — וגם מקל על הבדיקות, כי אפשר לבדוק פונקציה בלי להרים סוכן.
איך יודעים שהסוכן עובד
"הסוכן עובד" אינו ממצא, ובלי מדידה כל שינוי בתיאור כלי או בהנחיה הוא ניחוש. שלושה מדדים מפרידים בין בעיות שונות לגמרי ומכוונים את התיקון למקום הנכון:
- דיוק בחירת הכלי. בהינתן מצב, האם נבחר הכלי הנכון. כאן מתגלים תיאורים חלשים ושמות עמומים.
- דיוק הפרמטרים. נבחר הכלי הנכון — האם הערכים תקינים. כאן מתגלים תיאורי פרמטרים חסרים, ובעיקר היעדר פורמט ודוגמה.
- מה קרה אחרי כישלון. האם הסוכן התאושש, ניסה משהו אחר, או נתקע בלולאה. זה המדד שהכי מנבא תקלות בייצור והכי פחות מנוטר.
והדרך לבנות את זה זולה יותר משנדמה: עשרים עד שלושים מצבים אמיתיים עם הקריאה הנכונה מסומנת לצד כל אחד. זה מספיק כדי לתפוס נסיגה ביום הראשון, וזה מה שהופך שינוי מתחושה למספר. אותה גישה מפורטת בEvals.
ונקודה שמשנה תרבות: שינוי מילה בתיאור כלי הוא שינוי התנהגות של המערכת, בדיוק כמו שינוי בתנאי. בפועל תיאורים נערכים כאילו הם הערות, ושבוע אחרי מגלים שהסוכן הפסיק לקרוא לכלי מסוים — בלי שאיש יקשר בין השניים.
כמה סוכנים: מתי זה עוזר ומתי זה אופנה
"צוות סוכנים" נשמע חזק, ולרוב הוא פתרון לבעיה שאין לכם. כל סוכן נוסף מכפיל את מספר הדרכים שבהן המערכת יכולה להשתבש, ומוסיף קריאות, השהיה ועלות.
מתי זה כן מוצדק: כשיש הפרדה אמיתית של הקשר. סוכן משנה שמבצע חקירה ארוכה ומחזיר מסקנה אחת שומר על ההקשר הראשי נקי — וזה יתרון ממשי, כי הקשר שתפח הוא הסיבה הנפוצה ביותר לכך שסוכן מתחיל לחזור על עצמו.
מתי זה לא: כשההפרדה היא רק שמות תפקידים. "חוקר", "כותב" ו"עורך" שכולם רואים את אותו הקשר ומשתמשים באותם כלים הם סוכן אחד עם שלוש הנחיות — ואפשר להשיג את אותו דבר בשלושה שלבים באותה לולאה, בשליש מהמורכבות.
מה זה עולה להריץ סוכן
סוכן יקר בהרבה מקריאה בודדת, ולא תמיד מסיבה שצופים. העלות אינה מספר הצעדים אלא סכום ההקשרים: בכל צעד נשלח מחדש כל מה שהצטבר עד כה. סוכן של עשרה צעדים אינו פי עשרה מקריאה אחת — הוא יותר, כי ההקשר גדל בדרך.
שלושה מקומות שבהם הכסף בורח בשקט:
- תוצאות כלים גולמיות. תשובת API עם ארבעים שדות שמתוכם שלושה רלוונטיים, שנשלחת מחדש בכל צעד עד סוף הריצה. הגיזום בנקודת המקור הוא האופטימיזציה עם ההחזר הגבוה ביותר בתחום.
- רשימת כלים מלאה תמיד. נתח קבוע שמשולם בכל צעד, כולל כשאינו רלוונטי.
- ניסיונות חוזרים שלא נספרים. קריאה שנכשלה ורצה שוב מופיעה פעמיים בחשבון ופעם אחת בלוג — אלא אם תיעדתם אותה במפורש.
והמדד היחיד שאפשר לנהל לפיו: עלות לשיחה מוצלחת, לא עלות לקריאה. הוא גם היחיד שאפשר להשוות לערך העסקי, והוא כמעט תמיד מגלה שמיעוט מהריצות אחראי לרוב ההוצאה — ובדרך כלל מדובר בבאג ולא בשימוש כבד.
מה שלא ישתנה כשהמסגרות יתחלפו
המסגרות בדף הזה יתחלפו — חלקן כבר החליפו שם וארכיטקטורה פעם או פעמיים. מה שלא ישתנה הוא מה שנשאר נכון בכל אחת מהן: שמצב שייך לטבלה ולא לתמליל; שפעולה שאינה הפיכה עוברת דרך אדם; שכלי שמשנה מצב חייב להיות בטוח לקריאה כפולה; שהקשר הוא תקציב; ושבלי מדידה כל שינוי הוא ניחוש.
מי שמחזיק את החמישה האלה מחליף מסגרת בשבוע. מי שלא — כותב מחדש, ומגלה שהבעיות עוברות איתו.
איך לבחור, בפועל
- האם התהליך ידוע מראש? אם כן — לא צריך סוכן, וגם לא מסגרת. אוטומציה רגילה.
- האם יש פחות מחמישה כלים ולולאה פשוטה? אם כן — כתבו אותה ידנית. תבינו מה קורה, וזה יחזיר את עצמו.
- האם הסוכן נוגע בכסף, במחיקה או בלקוחות? אם כן — לכו לקצה השליטה, עם מצב מפורש ונקודות עצירה.
- אתם בחקירה ורוצים לראות אם הרעיון עובד? לכו לקצה המהיר, ותכננו לכתוב מחדש — פרוטוטייפ שנועד להיזרק הוא החלטה לגיטימית, כל עוד היא מודעת ולא מתגלה בדיעבד.
- ובכל מקרה — חמשת הדברים מסעיף "מה תבנו בעצמכם" נכנסים לפני שזה נוגע במשהו אמיתי.
מה שמסגרת מסתירה, ומתי זה מזיק
היתרון של מסגרת הוא שהיא מסתירה את הלולאה. זה גם החיסרון שלה, ושווה לדעת מתי הוא נהיה יקר.
כשמשהו יוצא שגוי, השאלה הראשונה היא מה בדיוק נשלח למודל — לא התבנית כפי שכתובה בקוד, אלא הטקסט הסופי אחרי כל ההצבות וההיסטוריה. במסגרת שמרכיבה את ההקשר בשבילכם, זו לא תמיד שאלה קלה, ובחלק מהמסגרות זה דורש לחפור.
לכן שווה לבדוק, לפני שמתחייבים, דבר אחד בלבד: כמה קל להדפיס את ההקשר המלא שנשלח בפועל. אם התשובה היא "שורה אחת" — מצוין. אם היא "צריך להפעיל מצב ניפוי ולפענח פלט" — תשלמו על זה בכל תקלה.
ובכל מקרה, בין אם יש מסגרת ובין אם לא: תעדו את ההקשר שנשלח, את הפלט המלא, ואת כל קריאות הכלים עם הפרמטרים והתוצאות. זה הפריט שהכי הרבה מערכות מדלגות עליו, והוא זה שהופך חקירה של יום לקריאה של דקה. ההרחבה: תצפית על מערכות AI.
מה משתנה בעברית
- שמות כלים ופרמטרים באנגלית. המודלים ראו מיליוני חתימות פונקציות באנגלית ומעט מאוד בעברית. המבנה באנגלית, הערכים והתיאורים בעברית — זה מוריד שגיאות בלי שום תמורה נגדית.
- ההקשר מתמלא מהר יותר. אותו תוכן נשבר ליותר טוקנים, ולכן גיזום תוצאות כלים חשוב כאן יותר מאשר במערכת אנגלית מקבילה.
- נרמול בקוד. "מחרתיים", "אחרי החג", מספר טלפון בתוך משפט — המודל טוב בהבנת כוונה וגרוע בעקביות פורמט. תנו לו להעביר את מה שנאמר, והמירו אצלכם.
- אישורים בעברית. אם האדם שמאשר קורא עברית, מסך האישור צריך להיות בעברית ולהציג את התוכן — לא את שם הפונקציה.
טעויות שחוזרות
- לבחור מסגרת לפני שברור מה בונים. ההחלטה קלה פי כמה אחרי שכתבתם לולאה אחת.
- לכתוב את הלוגיקה בתוך מבני המסגרת. הופך החלפה לכתיבה מחדש.
- לשמור מצב בתמליל. וזו הדרך שבה סוכן מבצע פעולה פעמיים.
- להתחיל מכמה סוכנים. מכפיל מורכבות לפני שאחד עובד.
- אישור שמראה שם פונקציה. אחרי חמש פעמים לוחצים בלי לקרוא.
- בלי מדידה. ואז אין דרך לדעת אם שינוי בתיאור כלי שיפר או החמיר, ושינויים מצטברים עד שאיש כבר לא יודע למה המערכת מתנהגת כפי שהיא מתנהגת.
- הרשאות בהנחיה. בקשה, לא הגבלה.
- שרשרת ארוכה בלי נקודת עצירה. טעות בצעד השני נכנסת להקשר והשלישי מסתמך עליה כעובדה.
- רשימת כלים שרק גדלה. כלים חופפים גורמים למודל לבחור את הדומה במקום את הנכון.
- תיאור כלי שנכתב למפתח. המודל צריך לדעת מתי לקרוא, לא איך הכלי ממומש.
- לספור צעדים במקום הקשרים. העלות גדלה מהר יותר ממספר הצעדים, כי ההקשר תופח בדרך.