Agent Session Handoff — העברת משימה בין מופעי סוכן

מאת צוות מדיה דיל · 12.08.2026 · Agent Infrastructure · 5 דק׳

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

שירות תמיכה מבוסס סוכן AI רץ על צי workers שמתחלף באופן טבעי — deploy חדש כל כמה שעות, auto-scaling שמוריד ומעלה instances לפי עומס, ולפעמים worker שפשוט קורס. במערכת פשוטה זה לא בעיה: כל בקשה עצמאית, וכל worker יכול לטפל בה. אבל בשיחה ארוכה עם לקוח — כזו שכוללת עשרות הודעות, כמה קריאות כלי, ואולי אפילו המתנה לאישור אנושי — מה קורה כשה-worker שהחזיק את השיחה נעלם באמצע? אם התשובה היא "השיחה מתחילה מחדש", המשתמש חווה את זה כאילו הסוכן "שכח" הכול, ולעיתים אף חוזר על שאלות שכבר נענו. Session Handoff הוא הפתרון: היכולת להעביר משימה פעילה ממופע סוכן אחד למופע אחר — worker חדש, שרת אחר, לפעמים אפילו סוכן מגרסה חדשה — בלי שההקשר, ההתקדמות, או המשתמש בקצה השני, ירגישו את המעבר.

למה Handoff שונה מ-Checkpoint רגיל

Checkpoint, כפי שנדון במדריך Agent Checkpoints, פותר בעיה של שחזור אחרי כשל — נקודת עצירה שממנה אפשר להמשיך. Handoff הוא רחב יותר: הוא לא רק "מה לשמור כדי לשחזר", אלא "איך מעבירים בעלות (ownership) על משימה חיה בין שני מופעים, בלי חלון זמן שבו אף אחד לא באמת אחראי עליה — ובלי חלון זמן שבו שני מופעים חושבים ששניהם אחראים". ההבדל הזה קריטי: אם שני workers חושבים ששניהם מטפלים באותה שיחה בו-זמנית, אפשר לקבל שתי תשובות סותרות למשתמש, או גרוע מכך — שתי פעולות כפולות שמבוצעות במקביל בטעות.

פרוטוקול Handoff מסודר

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

await sessionStore.transfer({
  sessionId,
  fromOwner: workerA,
  toOwner: workerB,
  state: currentContext,
});
// רק אחרי אישור, workerA מפסיק לחלוטין לטפל בsession זה
// וworkerB הופך לבעלים הרשמי היחיד

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

מה מעבירים, ומה לא

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

Handoff יזום מול Handoff כפוי

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

Handoff בתוך שרשראות מרובות סוכנים

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

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

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

תגיות: Session Handoff · Agent Checkpoints · Stateful Agents · Worker Failover · Session Ownership

← חזרה לבלוג · צור קשר