Durable AI Agents — סוכנים שממשיכים לעבוד גם אחרי כשל

מאת צוות מדיה דיל · 09.08.2026 · AI · 12 דק׳

מה קורה לסוכן AI כשהשרת שעליו הוא רץ קורס באמצע משימה בת 40 שלבים? מדריך טכני על Durable Execution, event sourcing ו-workflow engines שמאפשרים לסוכנים להמשיך בדיוק מהנקודה שבה נעצרו.

סוכן AI שמבצע תהליך רכש מול ספק — בדיקת מלאי, יצירת הזמנה, חיוב כרטיס אשראי, עדכון מערכת ERP ושליחת אישור ללקוח — יכול לרוץ דקות ארוכות ולכלול עשרות קריאות ל-API חיצוני ולמודל שפה. עכשיו תארו לעצמכם שבשלב 27 מתוך 40 הקונטיינר שבו רץ הסוכן מקבל OOM Kill, ה-pod מתחלף, או פשוט יש דיפלוי שמפעם מחדש את השירות. סוכן AI "רגיל" שרץ כלולאה בזיכרון פשוט נעלם. הוא לא יודע שהוא כבר חייב את כרטיס האשראי, לא יודע אם ההזמנה נוצרה, ואין לו שום דרך לחזור למקום שבו הוא עצר. זה בדיוק הפער ש-Durable AI Agents באים לסגור: יכולת להריץ תהליכים ארוכי-טווח, מרובי-שלבים, שממשיכים בדיוק מהנקודה שבה הם נעצרו — גם אחרי קריסת תהליך, גם אחרי דיפלוי, וגם אחרי כשל ברשת שנמשך דקות.

מה זה בכלל "Durable" ולמה סוכנים רגילים נשברים

ברוב המימושים הנאיביים, סוכן AI הוא לולאת while בתוך תהליך אחד: קורא לכלי, מקבל תוצאה, שולח למודל, מקבל החלטה הבאה, חוזר חלילה. כל המצב — היסטוריית השיחה, תוצאות ביניים, אילו כלים כבר רצו — יושב בזיכרון (RAM) של אותו תהליך. זו ארכיטקטורה שעובדת מצוין בדמו, ונשברת בפרודקשן מהסיבה הפשוטה שתהליכים מתים: קריסות, אוטוסקיילינג, דיפלוימנטים, timeouts של load balancer. Durable execution הופך את ההנחה הזו על פיה: הסטטוס האמיתי של הביצוע לא נמצא בזיכרון של תהליך אחד, אלא ביומן (log) חיצוני ובלתי תלוי בתהליך. כל צעד בביצוע נרשם כאירוע לפני שהוא מתבצע, ואם התהליך מת — תהליך חדש יכול לקרוא את היומן ולדעת בדיוק איפה הוא עצר.

המנגנון מתחת למכסה המנוע — Event Sourcing ו-Deterministic Replay

רוב מנועי ה-durable execution (Temporal, Restate, AWS Step Functions, Azure Durable Functions) מתבססים על עיקרון דומה: event sourcing משולב ב-deterministic replay. במקום לשמור "מצב" (state) כערך נוכחי, שומרים רצף של אירועים — "השלב הזה התחיל", "הכלי הזה הוחזר עם התוצאה X", "המודל החליט Y". כשצריך לשחזר ביצוע שנקטע, המנוע לא "טוען מצב" — הוא מריץ מחדש את קוד ה-workflow מההתחלה, אבל בכל פעם שהקוד מגיע לפעולה שכבר בוצעה (למשל קריאה ל-API), המנוע לא מבצע אותה שוב אלא מחזיר מיד את התוצאה השמורה מהיומן. זה נקרא replay, וזה הופך את כל ה-workflow ל"נראה" כאילו רץ ברצף אחד ללא הפרעה, גם אם בפועל הוא רץ על שלושה תהליכים שונים לאורך שעה.

הדרישה הקריטית שנובעת מזה: קוד ה-workflow עצמו חייב להיות דטרמיניסטי. אסור לקרוא ל-random() או Date.now() ישירות בתוך לוגיקת ה-workflow — כי ה-replay חייב להגיע לאותן החלטות בכל פעם. כל פעולה לא-דטרמיניסטית (קריאה למודל, קריאה ל-API, זמן נוכחי) עוברת דרך "activity" נפרד שהתוצאה שלו נרשמת ביומן ומוחזרת כ-cached value ב-replay.

ארכיטקטורות מימוש: Workflow Engine מול Queue מבוזר עצמאי

יש שתי גישות מרכזיות לבניית durable agents:

  • Workflow Engine ייעודי (Temporal, Restate, Inngest) — מספק את מנגנון ה-replay, ניהול timers, retries מובנים וניראות (visibility) על כל ריצה. העלות: תלות בתשתית נוספת, ולפעמים סד"פ (SDK) שמכתיב איך כותבים קוד.
  • מימוש עצמי מעל Event Log + State Store — שמירת כל צעד בטבלת PostgreSQL או ב-append-only log (למשל Kafka), עם worker שקורא את היומן בהתחלת כל ריצה ובונה מחדש את המצב. גמיש יותר אבל דורש לבנות את מנגנון ה-recovery בעצמכם, כולל טיפול ב-race conditions כשכמה workers מתחרים על אותה משימה.

לרוב הצוותים שבונים סוכן production-grade אחד או שניים, מימוש עצמי פשוט מעל טבלת agent_runs ו-agent_steps מספיק ופחות מסובך מלהכניס תלות בפלטפורמת workflow שלמה. כשיש עשרות סוגי workflows מקבילים עם לוגיקת retry, timeout ו-fan-out/fan-in מורכבת — workflow engine ייעודי חוסך הרבה קוד תשתית.

החלטות ארכיטקטורה מרכזיות

גרנולריות ה-checkpoint

כמה תכוף לשמור מצב? checkpoint אחרי כל קריאת כלי הוא הכי בטוח אבל מוסיף latency ועלות I/O. checkpoint רק בין "שלבים לוגיים גדולים" זול יותר אבל מרחיב את חלון האובדן — אם קורסים באמצע שלב, כל מה שנעשה בתוכו הולך לאיבוד (ראו הרחבה במדריך Agent Checkpoints).

Idempotency של side effects

הנקודה העדינה ביותר ב-durable agents: אם צעד "חייב כרטיס אשראי" קרס אחרי שהחיוב בוצע אבל לפני שהתוצאה נרשמה ביומן, ה-replay ינסה לחייב שוב. חובה שכל side effect חיצוני (תשלום, שליחת מייל, יצירת רשומה) יהיה idempotent — למשל באמצעות idempotency key ייחודי לכל ריצת צעד, שנשלח ל-API החיצוני ומבטיח שקריאה כפולה לא תיצור אפקט כפול. זה נושא מרכזי בפני עצמו, ומפורט במדריך Agent Retry Architecture.

Timers וזמני המתנה ארוכים

סוכן שמחכה לאישור אנושי או ל-webhook חיצוני יכול להמתין דקות עד ימים. תהליך שמחזיק thread תקוע כל הזמן הזה לא scalable. מנועי durable execution פותרים זאת עם timers מתמשכים (durable timers) שלא צורכים משאבי compute בזמן ההמתנה — התהליך פשוט "ישן" עד שהאירוע מגיע או הזמן חולף, ומתעורר מחדש כ-replay.

Trade-offs — עלות ומורכבות מול אמינות

Durable execution הוא לא ברירת מחדל שכדאי להחיל על כל סוכן. הוא מוסיף latency (כתיבה ליומן לפני כל side effect), מורכבות תשתיתית, ולעיתים מגבלות על סגנון הקוד (דטרמיניזם). לסוכן שעונה שאלה בודדת מול RAG בתוך שתי שניות — אין בכך שום ערך; כשל פשוט מטופל ע"י retry ברמת ה-HTTP request. הערך של durable execution עולה ביחס ישר לאורך התהליך, למספר ה-side effects הבלתי-הפיכים בו (תשלומים, שינויי מצב במערכות חיצוניות), ולעלות של כשל חלקי — כלומר תהליך ש"נתקע באמצע" ומשאיר את המערכת החיצונית במצב לא עקבי.

דוגמה מהשטח

סוכן שמבצע onboarding אוטומטי ללקוח עסקי: יצירת חשבון, הקצאת הרשאות, יצירת סביבת עבודה, שליחת סדרת מיילים עם השהיה של יום בין כל אחד. תהליך שנמשך שבוע שלם. במימוש נאיבי — לולאה שרצה בזיכרון תמות בדיפלוי הבא ותשאיר את הלקוח באמצע התהליך בלי שאף אחד ידע. במימוש durable, כל שלב נרשם, ה-timers של "חכה יום" הם durable timers שלא צורכים compute, ואם השרת קורס — worker אחר קם, קורא את היומן, ורואה בדיוק שהתהליך ממתין ל-timer שיפוג בעוד 14 שעות. אין צורך בשום "תיקון ידני".

טעויות נפוצות

  • לבנות durable execution מאפס לכל סוכן חדש במקום להפריד תשתית משותפת (state store, idempotency layer) שכל הסוכנים בארגון משתמשים בה.
  • לשכוח מ-idempotency ב-side effects — durable execution בלי idempotency רק מבטיח שהתהליך ימשיך, לא שהוא לא יבצע פעולה כפולה.
  • לכלול לוגיקה לא-דטרמיניסטית בתוך workflow code (זמן נוכחי, מספרים אקראיים, קריאות ישירות ל-API) — זה שובר replay ומייצר באגים שקשה מאוד לאתר.
  • checkpoint גס מדי שמאבד עבודה משמעותית בכל כשל, או checkpoint עדין מדי שהופך את המערכת לאיטית ויקרה.

שכבת ה-Observability של durable agents

מערכת durable execution בלי נראות (visibility) על מה שקורה בפועל היא בעיה בפני עצמה — עכשיו יש לכם תהליכים שיכולים לרוץ ימים, "לישון" בין timers, ולהתעורר מחדש, וקשה לדעת בכל רגע נתון כמה ריצות פעילות, אילו מהן תקועות, ואילו קרובות לחריגה מ-SLA. מנועי workflow ייעודיים מספקים לרוב UI מובנה שמראה את מצב כל ריצה, את היסטוריית האירועים שלה, ואת נקודת ה-replay הנוכחית. במימוש עצמי, יש לבנות את זה במפורש — טבלת סטטוס עם שאילתות סטנדרטיות ("כל הריצות שתקועות מעל שעה", "כל הריצות שנכשלו בניסיון האחרון"), ולחבר אותן להתראות. ללא זה, כשל שקט (silent failure) בתהליך ארוך-טווח יכול לעבור בלי לב שם לב במשך ימים, בדיוק כמו שמתואר במדריך LLM Observability.

ניהול גרסאות (Versioning) של Workflows

נקודת כאב אמיתית שכמעט כל צוות שמיישם durable execution נתקל בה במוקדם או במאוחר: מה קורה כשמשנים את קוד ה-workflow בזמן שריצות ישנות עדיין "באמצע הדרך"? אם ריצה שהתחילה לפני הפריסה החדשה מגיעה ל-replay אחרי הפריסה, וקוד ה-workflow השתנה — ה-replay עלול "לסטות" מההיסטוריה השמורה ולהיכנס למצב לא עקבי, כי הלוגיקה שהוא מנסה לשחזר כבר לא קיימת באותה צורה. הפתרון המקובל הוא versioning מפורש: כל ריצה נושאת תג גרסה, וקוד ה-workflow בודק את התג ומריץ את ההסתעפות המתאימה (if (version >= 3) { ... } else { ... }), כך שריצות ישנות ממשיכות לפי הלוגיקה שהיו אמורות לרוץ לפיה, וריצות חדשות מקבלות את הלוגיקה העדכנית. זה מוסיף מורכבות קוד, אבל החלופה — פשוט לדרוס את הלוגיקה הישנה — עלולה לשבור ריצות אמיתיות באמצע ביצוע.

מתי לא להשתמש ב-Durable Execution בכלל

חשוב לומר את זה במפורש: לא כל מערכת AI זקוקה לשכבה הזו, ולפעמים ההימנעות ממנה היא ההחלטה הנכונה. אם התהליך שלכם קצר (שניות בודדות), הפיך לגמרי (אין side effects בלתי-הפיכים), ורץ בתדירות גבוהה מאוד עם עלות נמוכה לחזרה — התקורה התפעולית של durable execution (עוד שירות לתחזק, עוד קוד מורכב, עוד נקודות כשל פוטנציאליות בעצמה) עלולה לעלות יותר מהתועלת. במקרים כאלה, retry פשוט ברמת ה-HTTP request, בשילוב עם לוגים טובים, נותן כיסוי סביר ברוב המקרים. ההחלטה צריכה להתבסס על שאלה כמותית: מה העלות הצפויה (בזמן, בכסף, במוניטין) של כשל חלקי שמשאיר תהליך "תקוע באמצע" — ולא על תחושת בטן שדורשת "אמינות מקסימלית" בכל מחיר.

Durable execution קשור הדוק לשאלת ה-ניהול ה-State של הסוכן, ולעיתים קרובות מיושם כחלק מארכיטקטורת Orchestration רחבה יותר. אם אתם בונים סוכן שמבצע תהליכים ארוכי-טווח עם השלכות עסקיות אמיתיות — כדאי לתכנן את שכבת ה-durability מהיום הראשון, לא כתוספת אחרי תקרית בפרודקשן.

שאלות נפוצות

האם צריך durable execution לכל סוכן AI?

לא. סוכן קצר-טווח (שניות עד דקה) עם side effects הפיכים יכול להסתפק ב-retry פשוט ברמת הבקשה. durable execution משתלם כשהתהליך ארוך, מרובה-שלבים, וכולל פעולות בלתי-הפיכות.

מה ההבדל בין durable agent ל-checkpointing רגיל?

checkpointing הוא מנגנון אחד מתוך ארגז הכלים של durable execution — שמירת מצב בנקודות זמן. durable execution המלא כולל גם event log, replay דטרמיניסטי, timers מתמשכים וטיפול ב-idempotency.

האם Temporal או Restate מתאימים לכל פרויקט?

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

איך durable execution משפיע על latency?

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

מה קורה אם ה-workflow עצמו משתנה (קוד חדש) באמצע ריצה קיימת?

זו נקודת כאב אמיתית — שינוי בלוגיקת ה-workflow יכול לשבור replay של ריצות ישנות. פתרונות כוללים versioning מפורש של workflows ותמיכה ב-side-by-side execution של גרסאות שונות.

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

תגיות: Durable AI Agents · Durable Execution · Temporal · Event Sourcing · Idempotency · AI Agents · Workflow Engine

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