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

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

Diagram of AI agent orchestration: a user's multi-step goal goes to an orchestrator, which routes work to agents, models, and tools to produce a final output, while breaking down tasks, tracking dependencies, delegating execution, managing shared context, and combining outputs.

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

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

מהו תזמור סוכני AI?

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

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

איך תזמור סוכני AI עובד: מבט אל תוך מנוע הביצוע

בואו נראה מה קורה אחרי שנותנים למתזמר משימה.

נבחן דוגמה מסדנת Computer של Perplexity: בניית לוח מחוונים של מודיעין לקוחות באמצעות מידע מ-Salesforce, מ-Snowflake, מהדוא״ל, מהיומן ומחדשות עדכניות.

  1. הבנת המטרה ותכנון העבודה. המתזמר מתחיל מהתוצאה המבוקשת ומפרק אותה למשימות עם תלויות מפורשות. בדוגמת לוח המחוונים שלנו, הדבר כולל איסוף מידע ממקורות שונים והפיכתו לתוצר מוגמר. המתכנן קובע אילו שלבים תלויים באחרים ואילו יכולים לרוץ באופן עצמאי.
  2. ניתוב משימות לסוכנים המתאימים. המתזמר מזהה משימות שהתלויות שלהן מולאו ומאציל את העבודה לסוכנים או למודלים ייעודיים. משימות תלויות ממתינות לתנאים המקדימים שלהן. Perplexity Computer משתמש במספר מודלי חזית ומנתב חלקים שונים של תהליך העבודה למערכות שמתאימות למשימות האלה. כך גם עבודה עצמאית יכולה לרוץ במקביל.
  3. ביצוע קריאות לכלים בסביבות מבוקרות. סוכנים מקיימים אינטראקציה עם הסביבה שלהם באמצעות כלים, כמו חיפוש באינטרנט, ממשקי API, אפליקציות מחוברות, פעולות על קבצים או הרצת קוד. שכבת הביצוע מריצה את הפעולות האלה ומחזירה את התוצאות לסוכנים.
  4. העברת תוצאות והקשר בין סוכנים. כשסוכן מסיים את המשימה שלו, הסוכן הבא בשרשרת זקוק לפלט הרלוונטי כדי להמשיך. רשומת העברה יכולה לכלול מזהה משימה, הפניה לפלט, גרסת סכימה ומטא-נתונים של המקור. המתזמר מתאם את ההעברות האלה תוך שמירה על ההקשר הדרוש לשלבים הבאים. חשוב לציין שסוכנים לא צריכים לשאת את כל ההיסטוריה של העבודה של כל סוכן אחר בחלונות ההקשר שלהם.
  5. תיעוד מצב הביצוע בנפרד מההקשר של הסוכן. כשסוכנים מתחילים משימות, משלימים אותן או נכשלים בהן, מנוע הביצוע מעדכן רשומה מתמשכת של תהליך העבודה עם סטטוסי המשימות, ניסיונות הביצוע, הפניות לפלטים והעבודה שנותרה. רשומה זו מאפשרת למתזמר לעקוב אחר ההתקדמות ולהמשיך אחרי הפרעות, בלי להסתמך על LLM כדי לשחזר את תהליך העבודה מהיסטוריית השיחה.
  6. אימות התוצאות והחלטה על המשך. כשמשימה חוזרת, שכבת התזמור בודקת אם הפלט שלה עומד בחוזה הצפוי ואם התלויות של המשימה הבאה מתקיימות. אם מתגלה בעיה, תהליך העבודה יכול לחזור לשלב מוקדם יותר לתיקון או לעבור להשהיה. אחרת, הוא ממשיך לקראת השלמה.

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

מתי כדאי להשתמש בתזמור סוכני AI?

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

לכן, תזמור מועיל בשלושה תרחישים:

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

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

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

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

ארכיטקטורות לתזמור סוכני AI והפשרות שלהן

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

תזמור ריכוזי

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

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

תזמור מבוזר

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

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

תזמור היררכי

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

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

מבנה זה יכול לעזור כשתהליכי העבודה רחבים מדי מכדי שמתזמר אחד ינהל אותם ביעילות.

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

השוואה בין הארכיטקטורות:

קריטריונים

ריכוזי

מבוזר

היררכי

בעלות על הביצוע

מתזמר אחד שולט בהאצלה

הסוכנים מתאמים ביניהם ישירות או דרך מצב משותף

האחריות מחולקת בין רמות התזמור

עקביות המצב

קל יותר לתאם דרך נקודת בקרה אחת

דורש סנכרון מפורש וטיפול בהתנגשויות

דורש תיאום בתוך הענפים וביניהם

בידוד כשלים

הבקר המרכזי עלול להפוך לתלות קריטית

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

אם התכנון כולל התאוששות, ניתן להכיל כשלים בתוך הענפים

אכיפת מדיניות

ניתן לאכוף בקרות משותפות באופן מרכזי

יש לאכוף מדיניות באופן עקבי בקרב כל המשתתפים

ניתן להחיל בקרות ברמה הגלובלית וברמת התחום

מורכבות תפעולית

נמוכה בדרך כלל

מורכבות תיאום גבוהה יותר

מורכבות גבוהה יותר בשל שכבות תזמור מרובות

ביצוע רציף, מקבילי ומבוסס העברת שליטה

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

אלה שלושה דפוסי ביצוע:

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

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

כשלים נפוצים בתזמור סוכני AI

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

  • העברות בין סוכנים שמאבדות מידע. מתזמר מעביר תוכנית מסוכמת לסוכן מומחה, אבל הסיכום משמיט אילוצים, תלויות או פרטי מימוש.
  • איחוד תוצאות (fan-in) מוקדם מדי. סוכן במורד הזרם מתחיל לאגד תוצאות לפני שכל המשימות במעלה הזרם הסתיימו.
  • עדכוני מצב משותף לא דטרמיניסטיים. סוכנים מקביליים כותבים לאותם מפתחות מצב ללא סמנטיקת מיזוג מוגדרת היטב. בהתאם לאופן שבו המסגרת מטפלת בעדכונים, הדבר עלול לגרום לאובדן כתיבות, לשכפול נתונים, לפלט שתלוי בסדר או לשינויים סותרים.
  • פער בין נקודת ביקורת לתופעות לוואי. משימה מבצעת פעולה חיצונית, אבל הביצוע המוצלח שלה לא נרשם באופן עמיד לפני שרכיב העיבוד (worker) נכשל. בעת ההתאוששות, המתזמר רואה משימה שלא הושלמה ומריץ אותה שוב.
  • תנאי מרוץ בחידוש הביצוע לאחר אישור אנושי. השהיה וחידוש של הביצוע יוצרים בעיות סנכרון משלהם.
  • לולאות האצלה והגברת ניסיונות חוזרים. סוכנים מעבירים עבודה זה לזה שוב ושוב משום שתחומי האחריות שלהם חופפים, התלויות מעגליות או שתנאי ההשלמה אינם חד-משמעיים.
  • בקרות ברמת ההנחיות שנחשבות בטעות לאבטחת ביצוע. מתזמר עשוי להורות לסוכנים לא לגשת למשאבים מסוימים או לא לבצע פעולות רגישות, אבל הנחיות למודל אינן אוכפות הרשאות של מערכת ההפעלה, הגבלות רשת או גבולות הרשאה. מחקר הנדסת האבטחה של Perplexity מדגיש מדוע סוכנים עלולים לחצות גבולות אבטחה בזמן שהם חותרים למטרות לגיטימיות, גם ללא הנחיות זדוניות

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

7 שיטות עבודה מומלצות לתזמור סוכני AI לאמינות בסביבת ייצור

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

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

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

  • מטרה: לזהות ולתקן את הגורם לבדיקת אינטגרציה לא יציבה של ה-API של תהליך התשלום.
  • קלטים: קוד המקור של הבדיקה, יומני הכשלים ב-CI, קומיטים אחרונים וקוד האפליקציה הרלוונטי.
  • אילוצים: אין להשבית בדיקות, להקל על טענות (assertions) או לשנות התנהגות לא קשורה של האפליקציה.
  • פלט צפוי: תיקון קוד (patch), הסבר על שורש הבעיה ותוצאות הרצת הבדיקות.
  • קריטריוני קבלה: הבדיקה שנכשלה קודם עוברת ב-10 הרצות רצופות, וחבילת בדיקות הרגרסיה הרלוונטית עוברת.
  • תנאי כישלון: לא ניתן לזהות את שורש הבעיה, התיקון גורם לרגרסיות, או שסביבת הבדיקות הנדרשת אינה זמינה.

אבל יש עוד חלק חשוב: מתי הסוכן צריך לעצור?

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

בחזרה לדוגמת ה-CI שלנו. אפשר להגדיר את תנאי העצירה הבאים:

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

2. שמרו על מתזמרים רזים ואכפו העברות מובנות

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

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

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

json
{ "task_id": "fix-42", "status": "completed", "artifact_ref": "patch-17", "test_status": "pending", "blockers": [] }

3. שמרו את מצב תהליך העבודה באופן עמיד ושלטו בגידול ההקשר

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

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

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

4. תכננו ניסיונות חוזרים מודעי כשלים והרצת כלים הניתנת להתאוששות

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

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

  • שגיאות זמניות (429, 503): נסו שוב עם השהיה אקספוננציאלית מוגבלת ורעש אקראי (jitter), תוך כיבוד Retry-After כשהוא מסופק.
  • שגיאות אימות או הרשאה (400, 403): עצרו או תקנו את הבעיה הבסיסית במקום לחזור על אותה בקשה.
  • תוצאות לא חד-משמעיות (חריגה מזמן קצוב לאחר כתיבה אפשרית): בדקו אם הפעולה הצליחה לפני שתנסו לבצע אותה שוב.

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

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

כשאי אפשר לקבוע מה קרה, עצרו והסלימו.

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

python
op_id = get_or_create_operation_id( task_id=task_id, patch_id=patch_id, action="start_ci_run" ) try: return ci.start_run(commit, request_id=op_id) except TimeoutError: run = ci.find_by_request_id(op_id) if run: return run if ci.supports_idempotency: return bounded_retry( lambda: ci.start_run(commit, request_id=op_id) ) raise NeedsReconciliation(op_id)

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

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

5. נתבו ובצעו עבודה במקביל עם תקציבי משאבים מפורשים

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

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

לדוגמה, Effort Mode ב-Perplexity Computer מאפשר לכם לבחור כמה מאמץ משימה מצדיקה, בלי לבחור מודל באופן ידני. בחרו Light, Standard, High או Ultra, ו-Perplexity בוחרת באופן אוטומטי את המודל המתזמר ואת רמת ההנמקה שלו. לאחר מכן המתזמר מאציל משימות משנה לסוכנים תומכים, שיכולים להשתמש במודלים של ספקים שונים.

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

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

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

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

6. אכפו אישורים ובודדו את הביצוע של הסוכנים

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

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

לפעולות שדורשות אישור אנושי, השהו את הביצוע ושמרו את הפעולה המוצעת המדויקת:

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

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

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

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

7. אמתו פלטים באופן עצמאי ובדקו את התנהגות ההתאוששות

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

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

עקבו אחר תהליך העבודה כדי לזהות מה השתבש

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

המוסכמות הסמנטיות ל-GenAI של OpenTelemetry מספקות דרך סטנדרטית לתאר את הפעולות האלה. לדוגמה, invoke_workflow מזהה ביצוע של תהליך עבודה, invoke_agent מזהה הפעלה של סוכן, ו-execute_tool מזהה קריאה לכלי. כל פעולה יכולה להירשם כ-span עם התזמון, הסטטוס והמטא-נתונים הרלוונטיים שלה.

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

plaintext
invoke_agent generate_patch OK execute_tool start_ci_run OK run_id=9812 execute_tool get_ci_result TIMEOUT agent_response: "Success"

דוגמה להמחשה של מעקב ביצוע.

בדקו את הפלט באופן עצמאי

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

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

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

הזריקו כשלים כדי לבדוק התאוששות

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

כדי לבדוק זאת, הזריקו תקלות באופן מכוון בסביבת בדיקה:

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

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

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

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

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

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

שאלות נפוצות על תזמור סוכני AI

מדוע סוכני AI מבודדים נכשלים בקנה מידה ארגוני?

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

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

כיצד מונעים לולאות אינסופיות של ניסיונות חוזרים בסוכני AI?

הגדירו מגבלות בכמה רמות: מספר מרבי של ניסיונות חוזרים לקריאות לכלים, מספר מרבי של איטרציות לסוכן, עומק האצלה ומועד סיום כולל לתהליך העבודה. סווגו כשלים לפני ניסיון חוזר. עבור תגובות 429 זמניות, כבדו את Retry-After כאשר הוא מסופק. אחרת, השתמשו בהשהיה מעריכית מוגבלת (exponential backoff) עם רכיב אקראי (jitter).

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

כיצד ממשיכים תהליך עבודה של סוכן AI לאחר קריסה?

מנגנון ההתאוששות תלוי בסביבת זמן הריצה שלכם. ב-LangGraph, checkpointer מתמיד כגון PostgresSaver שומר את מצב הגרף תחת thread_id, וכך מאפשר להמשיך את הביצוע מהמצב השמור. ב-Temporal, worker אחר יכול לשחזר תהליך עבודה באמצעות הרצה חוזרת של היסטוריית האירועים שלו. במהלך ההרצה החוזרת, הוא עושה שימוש חוזר בתוצאות הפעילויות (activities) שתועדו קודם לכן.

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

כיצד בודקים את האמינות של תזמור סוכני AI?

הריצו את אותן משימות מייצגות מספר פעמים, והבחינו בין pass@k (האם לפחות אחד מתוך k הניסיונות מצליח) לבין pass^k (האם כל k הניסיונות מצליחים)

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