Agent Fleet Management — ניהול עשרות סוכנים פועלים במקביל
מאת צוות מדיה דיל · 12.08.2026 · Agent Infrastructure · 5 דק׳
כשעשרות סוכני AI רצים במקביל בפרודקשן, השאלות משתנות: לא 'האם הסוכן עובד' אלא 'איזה מתוך חמישים תקוע עכשיו'. כך בונים שכבת ניהול צי.
צוות תפעול בחברת לוגיסטיקה הפעיל בהדרגה יותר ויותר סוכני AI — אחד לתיאום משלוחים, אחד למעקב מלאי, אחד לתקשורת עם ספקים — עד שיום אחד גילו שיש להם 47 סוכנים פעילים, חלקם רצים כל הזמן וחלקם מופעלים אד-הוק, ואף אחד בצוות לא יודע לענות במדויק על "כמה סוכנים פעילים כרגע" או "איזה מהם צורך הכי הרבה תקציב". כל סוכן נבנה בנפרד, עם ה-Logging שלו, ה-Deployment שלו וה-Monitoring שלו — וכשמשהו השתבש, הפתרון היה לחפש ידנית באיזה מהעשרות סוכנים הבעיה מקורה. זו נקודת המעבר שבה ניהול סוכן בודד הופך לבעיה שונה איכותית: ניהול Fleet. השאלות שרלוונטיות ב-Fleet — קיבולת, עדיפות, בידוד כשלים, עלות מצטברת — שונות מהותית מהשאלות שרלוונטיות לסוכן יחיד, וגם הכלים שנדרשים כדי לענות עליהן שונים.
מה משתנה כשעוברים מסוכן בודד ל-Fleet
סוכן בודד נשאל "האם הוא עובד". Fleet נשאל שאלות אחרות לגמרי: איזה אחוז מהסוכנים פעילים כרגע תקינים, מהם מקוטלגים כתקועים, ומהם ממתינים בתור בגלל עומס. ניהול Fleet דורש שכבת בקרה מרכזית שרואה את כל הסוכנים כאוכלוסייה אחת, ולא כאוסף של פרויקטים נפרדים. הבסיס לכך הוא Registry מרכזי — קטלוג שמכיל את כל הסוכנים הקיימים, הגרסה הפעילה של כל אחד, וההרשאות שהוענקו לו. בלי Registry כזה, אין דרך אמינה לענות אפילו על השאלה הבסיסית ביותר: "אילו סוכנים בכלל קיימים במערכת שלנו כרגע".
מעבר לקטלוג, Fleet Management צריך גם שכבת מחזור חיים אחידה: כל סוכן עובר את אותם שלבים — פיתוח, בדיקה, פריסה מבוקרת, ניטור, ולבסוף גריעה (retirement) כשהוא כבר לא נחוץ. בלי תהליך אחיד, כל סוכן "חי" לפי כללים משלו, מה שהופך כל שינוי רוחבי (עדכון מדיניות אבטחה, שדרוג ספריית תלות משותפת) לפרויקט נפרד לכל סוכן במקום פעולה אחת שחלה על כולם.
קיבולת ותעדוף: מי מקבל את המשאבים כשיש עומס
ב-Fleet של עשרות סוכנים, משאבים משותפים — quota של API חיצוני, תקציב טוקנים חודשי, קיבולת חישוב — הם משאב סופי שצריך לחלק ביניהם במודע. בלי תעדוף מפורש, הסוכן שרץ הכי הרבה, או פשוט זה שנטען ראשון, "זוכה" בפועל במרבית המשאבים, בעוד סוכנים קריטיים יותר עסקית מתעכבים בשקט. הפתרון הוא מדיניות תעדוף מפורשת ברמת ה-Fleet: לכל סוכן, או קבוצת סוכנים, מוגדרת רמת עדיפות ומכסת משאבים משלו, ומנגנון תזמון מרכזי (scheduler) אוכף את החלוקה במקום להשאיר אותה למקרה.
- מכסת טוקנים ותקציב לכל סוכן או קבוצת סוכנים, לא מאגר משותף ללא הפרדה
- רמת עדיפות מפורשת: אילו סוכנים חייבים תגובה מיידית, ואילו יכולים להמתין בתור
- Rate Limit פר-סוכן מול משאבים חיצוניים משותפים, כדי שסוכן אחד לא "יבלע" מכסה גלובלית
- Circuit Breaker ברמת Fleet: אם סוכן ספציפי חורג מתקציב חוזר ונשנה, הוא מושהה אוטומטית לבדיקה
בידוד כשלים: מונעים אפקט דומינו
אחד הסיכונים הכי לא אינטואיטיביים ב-Fleet גדול הוא שכשל בסוכן אחד "מדביק" סוכנים אחרים — למשל, סוכן שנתקע בלולאה ומציף שירות משותף (בסיס נתונים, API חיצוני) עד שכל שאר הסוכנים שתלויים באותו שירות מתחילים לקבל timeout גם הם, למרות שהם עצמם תקינים לחלוטין. הפתרון הוא בידוד ברמת תשתית: כל סוכן רץ ב-Runtime מבודד משלו, עם quota משאבים משלו, כך שכשל בסוכן אחד לא יכול לצרוך את כל הקיבולת המשותפת. גם ברמת ה-Fleet Manager עצמו כדאי Circuit Breaker גלובלי: אם שירות חיצוני משותף מתחיל להחזיר שגיאות בקצב חריג, ה-Fleet Manager יכול להשהות זמנית את כל הסוכנים שתלויים בו, במקום לתת לכל אחד מהם לגלות את זה בנפרד ולנסות שוב ושוב.
נראות מרכזית: Dashboard אחד לכל ה-Fleet
שאלת המפתח שצריך לענות עליה תוך שניות היא "מה קורה עכשיו בכל המערכת". Dashboard ברמת Fleet מציג לכל סוכן: סטטוס נוכחי (רץ, ממתין, תקוע, כושל), עומס נוכחי מול קיבולת מוקצית, וצריכת עלות מצטברת בזמן אמת. השילוב הזה מאפשר לזהות בעיה לפני שהיא הופכת לתקרית — למשל, סוכן שצריכת הטוקנים שלו קפצה פי שלושה מהרגיל, עוד לפני שהוא בכלל נכשל, הוא סימן אזהרה מוקדם שכדאי לבדוק. בלי Dashboard מרכזי, אותו מידע קיים אמנם בלוגים נפרדים של כל סוכן, אבל הזמן שלוקח לחבר את הנקודות ידנית — במיוחד תחת לחץ, כשמשהו כבר שבור — הוא בדיוק הזמן שהופך תקלה קטנה לתקרית גדולה.
מתי כדאי להשקיע בכלי Fleet ייעודי
לצוות עם שני-שלושה סוכנים, כלי Fleet ייעודי הוא בדרך כלל מיותר — Dashboard פשוט וכמה Alert ידניים מספיקים. הסף שבו ההשקעה משתלמת הוא בדרך כלל סביב 10-15 סוכנים פעילים, או כשיש יותר מצוות אחד שמפתח ומפעיל סוכנים באופן עצמאי, כי אז חוסר תיאום מרכזי הופך לבעיה ארגונית ולא רק טכנית. ההשקעה הכי משתלמת בשלב מוקדם היא לא בכלי Dashboard מפואר, אלא בשני יסודות בסיסיים: Registry מרכזי שכל סוכן חדש נרשם אליו כחלק מתהליך הפריסה, ו-trace_id או session_id אחיד שמאפשר לחבר בין לוגים של סוכנים שונים. שני הדברים האלה זולים יחסית לבנות מוקדם, ויקרים מאוד לשחזר אחרי שיש כבר עשרות סוכנים שנבנו בלעדיהם.
שיקול נוסף שקשור ישירות להחלטה הזו הוא ניהול גרסאות בתוך Fleet חי — שאלה שלא מקבלת תשומת לב מספקת עד שהיא הופכת לבעיה אמיתית: מה קורה כששני צוותים שונים מפעילים גרסאות שונות של אותו סוכן במקביל? צוות אחד עדיין רץ על גרסה יציבה שנבדקה היטב, בעוד צוות שני כבר עבר לגרסה חדשה עם פרומפט משופר וכלים נוספים. בלי מדיניות ברורה, קל להגיע למצב שבו אירוע כשל מיוחס בטעות לגרסה הלא נכונה, כי אין הפרדה ברורה בין הרצות של גרסה ישנה לחדשה בתוך אותו Dashboard. הפתרון הוא לתייג כל הרצה בגרסה ספציפית של הסוכן — לא רק שם הסוכן, אלא מספר גרסה מדויק — כך שכל מדד, כל לוג וכל Alert אפשר לפלח לפי גרסה. זה גם מה שמאפשר לבצע Rollout הדרגתי אמיתי: מתחילים עם אחוז קטן מהתעבורה על הגרסה החדשה, משווים ביצועים מול הגרסה הישנה תוך כדי תנועה, ורק אחרי שהמדדים מוכיחים את עצמם עוברים להעברה מלאה — במקום להחליף את כל ה-Fleet בבת אחת ולגלות בעיה רק אחרי שהיא כבר פגעה בכל התעבורה.
תגיות: Agent Fleet Management · Agent Registry · Circuit Breaker · Resource Quota · Observability