הגדרת מערכות מרובות סוכנים עם CrewAI: תפקידים, משימות, Flows

אינטגרציית CrewAI: היכן נשבר סוכן בודד

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

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

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

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

מה נותנת הפרדת תפקידים ומשימות בין הסוכנים

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

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

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

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

אינטגרציית CrewAI: מצבי העבודה של מערכת מרובת-סוכנים

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

אפשרויות לארגון העבודה

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

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

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

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

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

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

סכמת התפקידים, תקנונים ויומני הרצה

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

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

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

מקרה בוחן: תפקידי סוכנים במקום ניתוב ידני

מה היה לפני

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

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

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

מה שינו

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

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

מה נהיה

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

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

מה לעשות אם חלק מהסוכנים כבר פרוסים?

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

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

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

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

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

מגבלות טכניות ותקלות נפוצות

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

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

מה לעשות אם הנתונים רבים מהנפח שנכנס להקשר?

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

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

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

מה עם תמיכה ופיתוח לאחר ההרצה?

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

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

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

כדאי לציין מיד:

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

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

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