הטמעת CAMEL לאינטראקציה בין סוכנים מרובים

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

כשסוכן CAMEL AI בודד נתקל בגבול המורכבות

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

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

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

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

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

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

מה נותן אינטראקציה רב-סוכנית: אפקטים מדידים

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

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

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

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

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

מצבי CAMEL AI: שיתוף פעולה, תחרות ותזמור

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

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

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

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

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

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

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

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

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

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

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

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

חבילת המסירה: קונפיגורציות, תפקידים ותקנוני תמיכה

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

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

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

מקרה בוחן: ניתוח משימה ארוכה הואץ פי שלושה

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

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

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

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

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

במה נבדלת סכימה רב-סוכנית משרשרת ארוכה של קריאות

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

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

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

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

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

ספקות טכניים: בידוד, כשלים, תמיכה

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

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

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

מה קורה אם סוכן החזיר תוצאה שגויה?

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

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

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

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

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

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

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

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

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

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

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

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