פיתוח מערכות AI מרובות סוכנים מקצה לקצה עם ערבות

מדוע מערכת ריבוי-סוכנים נשברת במשימות אמיתיות

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

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

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

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

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

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

מה משתנה אחרי ההטמעה: אפקט מדיד

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

זמן עיבוד

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

שיעור הפעולות הידניות

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

סוגי כשל שהוסרו

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

חיזוי בעומסי שיא

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

אפשרויות אורקסטרציה: השוואה בין גישות ומגבלות

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: צמצמנו את הטיפול הידני בפניות פי שלושה

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

מדדים לפני: היכן אבד הזמן

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

מה שינינו

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

מדדים אחרי: מה השתנה

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

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

במה נבדלת מערכת ריבוי-סוכנים מעוזר אחד?

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

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

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

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

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

ספקות טכניים: עונים לפני תחילת העבודה

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

כיצד מוגדרות הרשאות הגישה?

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

אצלנו כבר פרוסה אוטומציה — האם צריך לבנות אותה מחדש?

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

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

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

מה נדרש כדי למסור את המערכת לצוות פנימי?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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

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