פיתוח מתזמר סוכני AI (תזמור סוכנים)

פיתוח אורקסטרטור של סוכני AI: היכן התהליך נשבר

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

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

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

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

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

מה משתנה לאחר הטמעת מערכות סוכנים מנוהלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה בדיוק שינינו

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

לאחר ההפעלה זמן העיבוד הצטמצם מ-18–20 ל-4–6 דקות. שיעור הפניות שנסגרו ללא התערבות ידנית הגיע ל-78%; 22% הנותרים — לא סירובים, אלא הסלמה מודעת במקום שבו מחיר הטעות גבוה מהמהירות.

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

במה אורקסטרטור שונה מקבוצת סקריפטים ותורים?

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

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

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

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

שאלות טכניות: אמינות, הרשאות, בקרה

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

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

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

כיצד לנפות שגיאות בתרחיש שנופל לא תמיד?

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

האם זה ישתלב בשלבים הקיימים שלנו ואילו מגבלות יש?

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

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

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

בסיום הדיון נחזור לא עם תיאור "במילים", אלא עם תוכנית הטמעה הנדסית:

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

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