Undo Architecture לסוכנים — כיצד מאפשרים לבטל פעולה בעולם האמיתי

מאת צוות מדיה דיל · 12.08.2026 · Generative UI · 5 דק׳

מדריך ארכיטקטוני לבניית מנגנון Undo לפעולות סוכן AI בעולם האמיתי: סיווג פעולות לפי הפיכות, dry-run לפני ביצוע, Event Sourcing וחלונות זמן לביטול.

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

לא כל פעולה ניתנת לביטול באותה צורה

הצעד הראשון הוא סיווג פעולות לפי מידת ההפיכות שלהן. פעולות הפיכות לגמרי (שינוי שם קובץ, עדכון שדה בטופס טיוטה) אפשר לבטל בפשטות עם snapshot של המצב הקודם. פעולות הפיכות חלקית (מחיקת רשומה שאפשר לשחזר מ-soft delete, אבל אם עבר זמן רב מדי המידע הקשור אליה כבר השתנה) דורשות חלון זמן מוגדר לביטול. פעולות בלתי הפיכות מטבען (שליחת מייל, ביצוע תשלום, פרסום פוסט ציבורי) לא ניתנות לביטול אמיתי בשום ארכיטקטורה — מה שאפשר לעשות זה רק פעולת תיקון מפצה (compensating action), כמו שליחת מייל תיקון או ביטול עסקה מול הצד השני. הסיווג הזה חייב להיקבע מראש לכל סוג פעולה שהסוכן מסוגל לבצע, לא להיבחן case-by-case בזמן ריצה — כי סוכן שצריך "להחליט" בעצמו אם פעולה הפיכה עלול לטעות בדיוק במקרה הקריטי ביותר.

Dry-Run לפני ביצוע אמיתי

הכלי היעיל ביותר למניעת נזק הוא לא ביטול אחרי מעשה אלא הדמיה לפני מעשה: לפני שפעולה בלתי הפיכה או קשה לביטול מתבצעת בפועל, הסוכן מריץ אותה במצב dry-run שמחשב את התוצאה הצפויה בלי להחיל אותה בפועל, ומציג את זה למשתמש לאישור. עבור הדוגמה של ניקוי תיבת מייל, dry-run היה מציג "אני עומד למחוק 300 הודעות, כולל 2 שמסומנות כחשבוניות — להמשיך?" במקום לבצע ולגלות בדיעבד. המימוש הטכני דורש שכל פעולה תוכל לרוץ בשני מצבים — סימולציה וביצוע אמיתי — עם אותה לוגיקה בדיוק, כדי שה-dry-run יהיה חיזוי אמין ולא הערכה גסה שמפספסת מקרי קצה.

העיקרון הזה מתחבר ישירות לשכבת האישור בזמן אמת שתיארנו במדריך על AG-UI: נקודת העצירה לאישור לא צריכה להיות "תיאור מילולי של מה שיקרה", אלא תוצאה מחושבת בפועל, כדי שהמשתמש מאשר משהו קונקרטי ולא הבטחה מופשטת.

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

יומן פעולות הפיך (Event Sourcing לסוכנים)

הבסיס הטכני שמאפשר undo אמיתי הוא לתעד כל פעולת סוכן כאירוע נפרד ביומן בלתי משתנה (append-only log), עם כל הנתונים הדרושים כדי להפוך אותה — לא רק "מה נעשה" אלא "מה היה המצב לפני". זו בדיוק אותה גישת Event Sourcing שמשמשת בארכיטקטורות מונחות-אירועים קלאסיות, רק שכאן מקור האירועים הוא סוכן AI ולא משתמש אנושי בלבד. כל פעולה נשמרת עם: זהות מבצע הפעולה (הסוכן, ובאיזו הרשאת משתמש), מצב before, מצב after, וזמן ביצוע. undo הוא אז פעולה טכנית פשוטה יחסית — שחזור מצב before — אבל רק אם היומן נשמר בקפידה מהרגע הראשון.

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

חלונות זמן וגבולות אחריות

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

לבסוף, כדאי לקבוע מראש מי אחראי לאשר undo של פעולות רגישות — לפעמים זה לא אותו משתמש שביקש את הפעולה המקורית, אלא בעל הרשאה גבוהה יותר, בדומה למנגנוני אישור כפול (four-eyes principle) שקיימים בתהליכים פיננסיים מסורתיים. סוכן שיכול גם לבצע וגם לבטל פעולות רגישות בלי בקרה נוספת יוצר משטח סיכון חדש בפני עצמו, ולכן הפרדת התפקידים הזו היא חלק בלתי נפרד מתכנון הארכיטקטורה, לא תוספת מאוחרת.

בדיקות: לוודא שביטול באמת מחזיר למצב המקורי

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

תגיות: Undo Architecture · Event Sourcing · AI Agents · Reversibility · Dry Run · Agent Safety

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