Agent Replay — שחזור מלא של משימת סוכן שנכשלה

מאת צוות מדיה דיל · 12.08.2026 · AI Evals · 5 דק׳

איך בונים יכולת שחזור מדויקת לכל ריצה של סוכן AI: מה חייב להישמר, ההבדל בין Deterministic Replay ל-Re-execution, והפיכת כשלים אמיתיים למקרי בדיקה.

לקוח מדווח שהסוכן "עשה משהו מוזר" בשיחה שהתקיימה אתמול בערב, אבל לא זוכר בדיוק מה קרה, רק שהתוצאה הייתה לא נכונה. מפתח שמנסה לחקור פותח את הלוגים ומוצא שורת טקסט אחת: "agent completed task, status: success" — בלי שום פירוט על מה הסוכן חשב, אילו כלים הוא קרא, ובאיזה סדר. בלי תיעוד מלא, אין שום דרך לדעת מה השתבש, ואי אפשר לשחזר את הבעיה כדי לתקן אותה. Agent Replay הוא היכולת לשחזר במדויק — צעד אחר צעד — כל ריצה היסטורית של הסוכן, כדי לדבג כשל אחרי שהוא קרה, לא רק לדעת שהוא קרה.

מה חייב להישמר כדי ש-Replay יהיה אפשרי בכלל

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

נקודה שקל לפספס: תיעוד המצב הראשוני (initial state) חשוב לא פחות מתיעוד הפעולות עצמן. אם הסוכן קרא לנתוני מלאי בזמן t, וערך המלאי השתנה מאז, ניסיון להריץ מחדש את אותה בקשה "היום" ייתן תוצאה שונה גם אם כל הפרומפטים זהים — כי המציאות החיצונית שהסוכן פעל בתוכה כבר לא קיימת. לכן Replay אמיתי דורש הקפאה (snapshot) של תוצאות הכלים החיצוניים כפי שהיו בזמן הריצה המקורית, לא הרצה חוזרת שלהם.

שני מצבי Replay: Deterministic ו-Re-execution

יש שתי גישות שונות מהותית ל-Replay, ולכל אחת שימוש שונה. Deterministic Replay — משחזרים בדיוק את מה שקרה, על סמך התיעוד השמור בלבד, בלי לקרוא שוב למודל או לכלים חיצוניים. זה מהיר, זול, ותמיד נותן את אותה תוצאה — מצוין להבנת "מה בדיוק קרה" ולהצגה לצוות או ללקוח. Re-execution — מריצים את אותו קלט מחדש דרך המודל והכלים בזמן אמת, כדי לבדוק אם תיקון (בפרומפט, בקוד, בגרסת מודל) פותר את הבעיה. השני שימושי לאימות תיקון, אבל לא בהכרח ייתן את אותה תוצאה בדיוק בגלל אי-דטרמיניזם, וחשוב לא לבלבל בין השניים כשמדווחים ממצאים.

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

Replay כחלק מלולאת הפיתוח, לא רק כלי חירום

השימוש הכי נפוץ ב-Replay הוא כמובן דיבוג תקרית — משהו נשבר, וצריך להבין למה. אבל שימוש חזק לא פחות הוא הפיכת ריצות Replay מעניינות (כשלים מעניינים, מקרי קצה שנתפסו במקרה) ל-Test Cases חדשים בסוויטת ה-Evals. במקום לכתוב מקרה בדיקה מדומה, לוקחים ריצה אמיתית שכשלה, הופכים אותה לקובץ Eval עם ה-assertion המתאים, ומוודאים שהיא לא תכשל שוב באותה צורה. זה הופך כל תקרית פרודקשן להשקעה בכיסוי הבדיקות העתידי, במקום להיות אירוע מבודד שנפתר ונשכח.

הקשר הזה בין Replay לבדיקות אוטומטיות עמוק במיוחד — סוויטת Evals-as-Code איכותית גדלה בעיקר ממקרים אמיתיים שנתפסו ב-Replay, לא ממקרים תיאורטיים שנכתבו מראש. תהליך הזרמת מקרים מ-Replay חזרה לתוך ה-Repository, כולל שיוך לגרסת ה-commit הרלוונטית, מתואר במדריך Evals-as-Code.

עלות אחסון וגישה: הפרדה בין דגימה מלאה לדגימה חלקית

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

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

ממשק חקירה: מה הופך Replay משימושי לחיוני

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

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

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

תגיות: Agent Replay · Debugging · AI Observability · Trace · Incident Response

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