Stateful Agent Communication — שמירת הקשר בתהליכים בין מספר סוכנים

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

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

מערכת תמיכה אג'נטית העבירה פנייה של לקוח מסוכן סיווג ראשוני לסוכן טכני מתמחה, וזה האחרון שאל את הלקוח שוב את השאלות שכבר נענו בשלב הקודם — כי כל מה שעבר בין הסוכנים היה תקציר קצר של שורה אחת, לא ה-context המלא של השיחה. לקוח שכבר הסביר את הבעיה פעמיים מתוסכל, ושוב לא בגלל שהמערכת "טיפשה" אלא כי היא נבנתה בלי מנגנון מסודר לשמירת state בין סוכנים. Stateful Agent Communication הוא התחום שעוסק בדיוק בבעיה הזו: איך שומרים הקשר מלא ועקבי לאורך תהליך שעובר בין כמה סוכנים עצמאיים, שלכל אחד מהם יש זיכרון עבודה משלו, בלי לאבד מידע בדרך ובלי לשכפל אותו לאינסוף.

ההבדל בין Stateless ל-Stateful בהקשר של A2A

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

קריאת MCP בודדת היא לרוב stateless — כל קריאה עצמאית, לא תלויה בקריאות קודמות. אבל תהליך שעובר בין סוכנים דרך A2A הוא מטבעו stateful: ה-Task, כפי שמתואר במדריך A2A 1.0, נושא context שנצבר לאורך זמן. הבעיה מתחילה כשהתהליך עובר handoff — סוכן א' מסיים את חלקו ומעביר לסוכן ב', וצריך להעביר איתו לא רק את התוצאה הסופית, אלא גם את ההיסטוריה הרלוונטית שהובילה אליה. אם המידע הזה לא עובר במבנה מפורש, סוכן ב' מתחיל "מאפס" ומאבד כל מה שכבר סוכם.

הפתרון הארכיטקטוני הוא הפרדה בין שני סוגי state: Task State — הסטטוס הפורמלי (submitted, working, completed) שמנוהל ברמת הפרוטוקול, ו-Conversation Context — התוכן המהותי שנצבר: מה הלקוח ביקש, אילו הבהרות ניתנו, אילו החלטות התקבלו. ה-Conversation Context צריך לעבור במפורש בכל handoff, לא להישאר "מובן מאליו" בזיכרון של הסוכן הראשון בלבד.

מנגנוני שמירה: Shared Memory מול Context Passing

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

יש שתי גישות עיקריות לפתרון. הראשונה, Shared Memory, שומרת את כל ה-context במאגר מרכזי (מסד נתונים, Redis, או vector store) שכל הסוכנים המעורבים ניגשים אליו לפי Task ID משותף. היתרון: אין כפילות, וכל סוכן רואה תמונה מלאה ועדכנית. החיסרון: יוצר תלות בזמינות המאגר המרכזי, ומעלה שאלות הרשאה — לא כל סוכן צריך לראות את כל ה-context, במיוחד כשמדובר בסוכנים משני ארגונים שונים.

הגישה השנייה, Context Passing, מצרפת את ה-context הרלוונטי ישירות להודעת ה-handoff עצמה — כל סוכן מקבל בדיוק את מה שהוא צריך, לא יותר. זה פותר את בעיית ההרשאה (הסוכן המקבל רואה רק מה שהועבר לו במפורש) אבל דורש תכנון קפדני יותר: מי מחליט מה "רלוונטי" להעביר, ומה לא. ברוב המערכות המוצלחות ב-2026 נהוג שילוב: state פנימי ורגיש נשמר ב-Shared Memory בתוך גבולות הארגון, ורק סיכום context מסונן ומאושר עובר ב-Context Passing כשהתהליך חוצה גבול ארגוני אל סוכן חיצוני.

• Shared Memory — יעיל בתוך ארגון אחד, מהיר, אבל דורש שליטה בהרשאות
• Context Passing — בטוח יותר בין ארגונים, אבל דורש בחירה מודעת מה להעביר
• גישה היברידית — state מלא פנימי, סיכום מסונן חוצה גבול

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

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

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

מדידה: איך יודעים שה-context לא הולך לאיבוד

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

ניהול גודל ה-context לאורך שרשרת ארוכה

בעיה נוספת שמופיעה בתהליכים ארוכים במיוחד, עם חמישה או שישה handoffs ברצף, היא התנפחות context: כל סוכן מוסיף את הפלט שלו לערימה, וסוכן ה-handoff האחרון בשרשרת מקבל payload עצום שרובו לא רלוונטי לתפקידו הספציפי. הפתרון הנפוץ הוא summarization מדורג — כל handoff לא מעביר את כל ההיסטוריה הגולמית, אלא סיכום מובנה של מה שרלוונטי להמשך, בצירוף קישור (reference) להיסטוריה המלאה במאגר המרכזי למי שבאמת צריך לחזור אליה. כך הסוכן במורד השרשרת מקבל context קריא ורלוונטי, אבל שום מידע לא הולך לאיבוד לגמרי — הוא רק לא נדחף באופן גורף לכל שלב.

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

תגיות: stateful agents · A2A · context passing · multi-agent handoff · shared memory · task state

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