הגדרה ומנגנון: מה קורה בפועל כשסוכן "מעביר" שיחה
העברה בין סוכנים (Agent Handoff / Agent-to-Agent Handoff) היא מסירת שיחה או משימה שכבר בעיצומה מסוכן-AI אחד לסוכן אחר (או לנציג-אנושי), תוך שימור מלא של ההקשר וההיסטוריה שנצברו עד לרגע ההעברה — כך שהצד המקבל "ממשיך מאיפה שהצד הקודם עצר", בלי שהמשתמש צריך לחזור על עצמו מההתחלה ולתאר שוב את כל מה שכבר נאמר. ההבדל המרכזי מול ניתוב רגיל (Routing) הוא העיתוי: ניתוב מתרחש בתחילת האינטראקציה, לפני שכל טיפול ממשי בתוכן הבקשה בכלל התחיל — מעין "שער-כניסה" שממיין בקשות נכנסות לפי סיווג-ראשוני. העברה, לעומת זאת, מתרחשת באמצע התהליך: סוכן שכבר החל לטפל בבקשה מגלה, תוך-כדי-עבודה, שהיא חורגת מתחום-המומחיות שלו, ומעביר את השליטה המלאה הלאה — כולל כל מה שכבר נאמר ונעשה עד לאותו רגע — לסוכן מתאים יותר, שממשיך את הטיפול כאילו היה מעורב בו מההתחלה. חשוב להדגיש שההעברה היא העברת-שליטה מלאה, לא רק שיתוף-מידע: מרגע ההעברה ואילך, הסוכן המקבל הוא זה שמחליט על הצעד הבא, מפעיל כלים, ועונה למשתמש — הסוכן שהעביר בדרך-כלל יוצא לגמרי מהתמונה, ולא ממשיך לפקח על הטיפול או להתערב בו מבחוץ.
הבסיס התיעודי: Handoffs ב-OpenAI Agents SDK
המנגנון מתועד באופן מדויק ב-Agents SDK של OpenAI, שמגדיר "Handoffs" כרכיב מובנה: "העברות מאפשרות לסוכן להאציל משימות לסוכן אחר. זה שימושי בפרט בתרחישים שבהם סוכנים שונים מתמחים בתחומים נבדלים". טכנית, כל העברה מיוצגת בפני מודל-השפה כ"כלי" (Tool) עם שם בתבנית transfer_to_<שם-הסוכן> — כך שהמודל "בוחר" העברה בדיוק כפי שהוא בוחר בכל כלי אחר, בלי צורך במנגנון-החלטה נפרד מחוץ ללולאת-החשיבה-הרגילה שלו. ברגע שההעברה מופעלת, "הסוכן החדש למעשה לוקח על עצמו את השיחה, ורואה את כל היסטוריית-השיחה הקודמת" — כלומר הוא מקבל, בברירת-מחדל, את מלוא ההקשר שנצבר, ולא רק תקציר. ה-SDK מאפשר גם התאמות עדינות: פרמטר input_type מוסיף מטא-דאטה מובנית (למשל "סיבת-ההעברה" או "רמת-דחיפות") שהמודל ממלא בעת ההעברה עצמה; פונקציית-callback בשם on_handoff יכולה להתבצע ברגע ההעברה, שימושית לשליפת-מידע נוסף או תיעוד; ו-input_filter מאפשר לסנן איזה חלק מההיסטוריה בפועל יגיע לסוכן המקבל, אם לא רוצים להעביר את הכול. ה-SDK גם מבהיר את ההבדל מול ניתוב פשוט: בעוד ניתוב בוחר יעד אחד מבין אפשרויות, העברה יכולה להירשם כמה פעמים כ"כלים" נפרדים, והמודל עצמו בוחר איזה מהם להפעיל בהתאם להתפתחות השיחה.
Handoff Orchestration אצל מיקרוסופט, ודוגמת-מוקד-התמיכה
מיקרוסופט מתעדת דפוס מקביל תחת השם "Handoff Orchestration" הן במסגרת Semantic Kernel (החל ממאי 2025) והן במדריך-הארכיטקטורה של Azure, שם הוא מוגדר כך: "דפוס-ההעברה מאפשר האצלה דינמית של משימות בין סוכנים מתמחים. כל סוכן יכול להעריך את המשימה שלפניו ולהחליט אם לטפל בה ישירות או להעביר אותה לסוכן מתאים יותר". Azure מציינת גם כינויים-חלופיים נפוצים למונח: routing, triage, transfer, dispatch, delegation — וממחישה אותו בדוגמת-מוקד-תמיכה טלקומוניקציוני: סוכן-מיון (Triage Agent) מנסה לטפל בפנייה, ואם היא חורגת מסמכותו — למשל תקלה טכנית מורכבת — הוא מעביר אותה לסוכן-תשתיות; אם זו מחלוקת-חיוב, לסוכן-כספים; ואם מדובר בבעיית-גישה-לחשבון, לסוכן-חשבונות — וכל אחד מהם יכול, בתורו, להעביר הלאה לסוכן נוסף אם הוא מזהה שהבעיה חורגת גם מהיכולת שלו-עצמו, וליצור בכך "שרשרת-העברות" רב-שלבית. בכל שלב עוברת שליטה מלאה מסוכן אחד למשנהו, ורק אחד מהם פעיל בכל רגע נתון (בניגוד לדפוס-עבודה-מקבילית, שם כמה סוכנים פועלים בו-זמנית על אותה בקשה). Azure ממליצה על הדפוס דווקא כשלא ניתן לדעת מראש אילו סוכנים יידרשו או באיזה סדר, ומזהירה מפניו כשניתוב-קבוע-מראש (Routing דטרמיניסטי, לפי כללים ידועים) מספיק — שכן הפעלת-דפוס-העברה דינמי במקרה כזה רק מוסיפה מורכבות בלי תועלת ממשית.
הבדל מ"ניתוב-סוכנים": מתי מחליטים, ומה עובר הלאה
ההבחנה בין "ניתוב-סוכנים" (Agent Routing) ל"העברה בין סוכנים" חשובה כי שתי הפעולות משתמשות לעיתים במונחים חופפים בתעשייה (וכפי שצוין, Azure עצמה מכנה את ההעברה גם "routing" בהקשרים מסוימים), אך הן פותרות בעיה שונה: ניתוב מבוצע לרוב על-ידי שכבה נפרדת (מסווג-כניסה קטן ומהיר) שמחליטה מראש לאן לשלוח כל בקשה חדשה — לפני שהתחיל טיפול ממשי בתוכן שלה; העברה מתבצעת על-ידי הסוכן עצמו, שכבר באמצע-הטיפול בבקשה, ומחליט "תוך-כדי-עבודה" שהוא הגיע לגבול-היכולת שלו. במונחי Azure: ניתוב מתאים כש"הסוכן המתאים ידוע כבר מהקלט הראשוני", ואילו העברה מתאימה דווקא כש"דרישות-המומחיות מתבררות רק במהלך העיבוד" — כלומר כשהצורך בהעברה עצמו הוא תגלית שמתרחשת רק לאחר שהעבודה כבר החלה, ולא ניתן היה לצפות אותה מראש בשלב-הכניסה. Azure ממליצה גם להימנע מדפוס-העברה כשניתן לזהות מראש את רצף-הסוכנים המדויק הדרוש — ובמקרה כזה עדיף ניתוב דטרמיניסטי או דיספצ'ר פשוט, שקל יותר לבחון ולתחזק.
העברה לבן-אדם: human-in-the-loop כחלק מהדפוס
היבט מרכזי נוסף של הדפוס הוא העברה לא רק בין שני סוכני-AI, אלא גם מסוכן-AI לנציג אנושי. גם ה-SDK של OpenAI וגם Handoff Orchestration של מיקרוסופט תומכים בכך במפורש: סוכן שמזהה שהמשימה חורגת מיכולת כל הסוכנים הזמינים, או שהיא רגישה מדי לביצוע-אוטונומי-מלא, יכול "להעביר" את השיחה — עם כל ההקשר שנצבר — לנציג-שירות אנושי, במקום להמציא תשובה או לבצע פעולה שגויה. תבנית זו ממשיכה למעשה נוהג ותיק ממוקדי-שירות-לקוחות טלפוניים: "העברה חמה" (Warm Transfer), שבה נציג-מוקד מדבר תחילה עם הנציג הבא לפני שהשיחה מועברת אליו בפועל, בניגוד ל"העברה קרה" (Cold Transfer) שבה רק נמסר למתקשר מספר להתקשר אליו בעצמו, בלי כל תיאום מוקדם בין הצדדים. גרסת-ה-AI של הדפוס דורשת פתרון טכני ייעודי מקביל ל"העברה החמה": להעביר לא רק "תיאור-הבעיה" אלא את מלוא היסטוריית-הכלים-שהופעלו וההחלטות-שכבר-התקבלו, כדי שהנציג האנושי (או הסוכן הבא) לא יצטרך לשחזר אותן בעצמו — בדיוק כפי שנציג-אנושי בהעברה-חמה מקבל תדרוך-קצר לפני שהוא נכנס לשיחה, ולא רק מחובר אליה בלי הקשר.
שרשרת-העברות מלאה, ומתי בכלל לא כדאי להשתמש בדפוס
התיעוד של מיקרוסופט ממחיש שרשרת-העברות מלאה ולא רק העברה בודדת: "מתחיל עם סוכן-המיון שמפרש את הבקשה ומנסה לטפל בבעיות נפוצות ישירות. כשהוא מגיע לגבולות-היכולת שלו, הוא מעביר בעיות הלאה" — למשל, בעיית-רשת מועברת לסוכן-תשתיות-טכניות, ומחלוקת-חיוב מועברת לסוכן-פתרון-כספי; ו"העברות נוספות מתרחשות בתוך אותם סוכנים כשהסוכן-הנוכחי מזהה את גבולות-היכולת שלו-עצמו ויודע שסוכן אחר יכול לסייע ללקוח טוב יותר" — כלומר שרשרת שיכולה לכלול כמה תחנות-ביניים לפני שמגיעים לתשובה סופית או לנציג-אנושי. יחד עם זאת, Azure עצמה מפרטת מתי דווקא כדאי להימנע מהדפוס: כשהסוכן המתאים (או רצף-הסוכנים המתאים) ניתן לזיהוי כבר מהקלט הראשוני — ואז עדיף ניתוב-דטרמיניסטי פשוט או דיספצ'ר שלא לוקח חלק פעיל בעיבוד עצמו — וכן כשהניתוב הוא כללי-מבוסס-חוקים ולא תלוי בפרשנות-דינמית של חלון-ההקשר. שימוש בדפוס-העברה במקום שבו ניתוב-קבוע מספיק מוסיף שכבת-האצלה מיותרת, ועימה גם השהיה נוספת וסיכון להעברה מיותרת שרק מאריכה את הטיפול בפנייה.
סיכון-נלווה: הצטברות-הקשר ו"סחיבת" מידע מיותר בין תחנות
מכיוון שברירת-המחדל של דפוס-ההעברה היא להעביר את מלוא היסטוריית-השיחה לכל סוכן חדש בשרשרת, שרשרת-העברות ארוכה עלולה לגרום להצטברות הדרגתית של חלון-ההקשר: כל תחנה נוספת יורשת לא רק את המידע הרלוונטי-לה, אלא גם פרטים שהצטברו בתחנות קודמות ואינם רלוונטיים עוד למשימה שלפני הסוכן הנוכחי — בדיוק הסיבה ש-Agents SDK של OpenAI מציע את פרמטר input_filter, שמאפשר לסוכן-מעביר לבחור במפורש אילו חלקים מההיסטוריה יגיעו לסוכן הבא, ולא רק להעביר הכול כברירת-מחדל. זהו איזון מובנה בדפוס: העברה מלאה של הקשר חוסכת מהמשתמש לחזור על עצמו, אבל עלולה "לגרור" רעש מיותר וטוקנים מבוזבזים ככל שהשרשרת מתארכת; סינון-סלקטיבי חוסך בטוקנים ומשמר מיקוד, אבל מוסיף מורכבות-תכנון — צריך להחליט מראש, לכל צומת-העברה בשרשרת, מה בדיוק חייב לעבור הלאה ומה אפשר להשמיט בלי לפגוע ביכולת הסוכן הבא לטפל בבקשה כראוי.
העברה בתוך מערכת אחת מול העברה בין ארגונים שונים
כל הדוגמאות שתוארו כאן — Agents SDK של OpenAI, Handoff Orchestration של מיקרוסופט — מיישמות העברה "פנים-מסגרתית": כל הסוכנים המעורבים רצים תחת אותה תשתית-תוכנה, לרוב אצל אותו ספק, וההעברה היא פשוטה יחסית כי כל הצדדים "מדברים" באותו פורמט-פנימי. מצב שונה ומורכב-יותר נוצר כשרוצים להעביר שיחה בין סוכנים שנבנו על-ידי ארגונים שונים, על גבי מסגרות-תוכנה שונות לגמרי — למשל סוכן-שירות-לקוחות שנבנה בחברה אחת מעביר משימה לסוכן-לוגיסטיקה של ספק-חיצוני. לתרחיש כזה נדרש תקן-תקשורת משותף שגם צדדים שלא בנו את הסוכן השני מסכימים עליו מראש — תפקיד שממלאים פרוטוקולי-אינטראופרביליות ייעודיים בין-סוכנים, כמו פרוטוקול A2A (Agent2Agent), שמגדירים פורמט-חוצה-ספקים למשימות, מצבים ומעברי-שליטה. ההבדל המהותי: דפוס-ההעברה כפי שתואר כאן הוא התבנית-המושגית ("מה קורה כשסוכן מעביר שליטה"), בעוד פרוטוקול חוצה-ארגונים הוא המנגנון-הטכני הספציפי שמאפשר להעברה כזו להתרחש גם כשהסוכן השולח והסוכן המקבל לא נכתבו על-ידי אותו צד כלל.