מתג החירום של הסוכן הוא אשליה: למה כיבוי תהליכים לא פותר נזק

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

תמצית מנהלים

• מתג עצירה תהליכי (SIGKILL או עצירת קונטיינר) עוצר רק את לולאת הריצה של המודל, ולא מבטל קריאות API, עסקאות מסד נתונים או הודעות שנשלחו לצד שלישי.
• פעולת פיצוי אינה מסע בזמן אחורה אלא ביצוע פעולה חדשה לפנים (Forward Execution) שמטרתה להביא את המערכת למצב סביר.
• סיווג פעולות סוכן לארבע שכבות הפיכות מאפשר לקבוע מראש מתי נדרש אישור אנושי ומתי מותר לבצע פעולה אוטונומית מוגבלת.
• שימוש בקבלות פיצוי (Compensation Receipts) מתעד את הפעולה המקורית, פעולת הנגד ואת השאריות שאי אפשר למחוק.

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

ראיתי את הטעות הזו קורית שוב ושוב.

עצירת תהליך אינה ביטול פעולה. כשאנחנו עוצרים מנוע הרצה של מודל שפה, אנחנו רק מפסיקים את ייצור הטוקנים הבאים. הפעולות שכבר נשלחו ל-Slack, שורות החשבונית שנרשמו ב-Stripe, ו⁨מחיקת ההרשאות שכבר רצה ב-IAM⁩ לא נעלמות. הן נשארות שם, פצועות ומנותקות מקונטקסט.

סוכנים אינם טרנזקציות מסד נתונים מבודדות. הם ⁨מערכות מבוזרות⁩ שנעות בקצב מהיר, וכשהם נכשלים, מתג החירום משאיר אחריו ערימה של שברי מידע.

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

במערכות תוכנה קלאסיות, תהליך שמקבל פקודת עצירה פשוט משחרר זיכרון. אם השתמשנו במסד נתונים יחסי (Relational Database, מערכת לניהול מידע בטבלאות עם עקרונות תאימות קשיחים), פקודת Rollback מחזירה את המצב לקדמותו תוך מילישניות.

סוכן אוטונומי (Autonomous Agent, מערכת תוכנה המונעת על ידי בינה מלאכותית ומקבלת החלטות על הפעלת כלים ללא הנחיה אנושית צמודה) פועל בעולם שונה לחלוטין. הוא פועל על ידי שרשור כלים (Tool Chaining).

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

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

שלושת ממדי ההפיכות של רדיוס הפגיעה

כדי לתכנן מערכות סוכנים עמידות, אנחנו חייבים להפסיק לחשוב על פעולות במונחים של קריאה מול כתיבה. המדד האמיתי שקובע הוא רמת ההפיכות (Reversibility).

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

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

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

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

למה משתנה בוליאני של גלגול לאחור הוא שקר הנדסי

במערכות רבות אני רואה בבסיסי הנתונים עמודה בשם rolled_back: true. זהו שקר מנחם. משתנה בוליאני בודד לא יכול לתאר את המורכבות של התאוששות בעולם האמיתי.

פיצוי אינו מסע בזמן. פיצוי הוא תנועה לפנים (Forward Execution). אם שילמתם לספק בטעות, הפיצוי אינו מחיקת התשלום מההיסטוריה, אלא יצירת פעולת זיכוי חדשה. הזיכוי הזה מגיע עם מזהה משלו, חותמת זמן משלו, ועלויות נלוות.

במאמר המכונן של rokoss21.tech על קבלות פיצוי לסוכנים, המחבר מתאר בדיוק את הבעיה הזו: ניסיון לתמצת התאוששות למילה אחת מסתיר את השאריות שהסוכן השאיר אחריו. במקום דגל בוליאני, המערכת חייבת לייצר קבלת פיצוי (Compensation Receipt, מסמך מובנה המתעד איזה נזק תוקן, איזו פעולת נגד הופעלה ואילו שיירי מידע נותרו במערכת).

הקבלה הזו חייבת לכלול את המזהה של הפעולה המקורית, אימות סמכות לפעולת התיקון, ואת רשימת השיירים (Residuals). אם שלחנו הודעה שגויה ללקוח, פעולת הפיצוי תהיה שליחת הודעת התנצלות, והשייר יהיה העובדה שהלקוח עדיין ראה את שתי ההודעות. שקיפות לגבי שיירי מצב היא ההבדל בין מערכת יציבה לבין פצצת זמן של נתונים פגומים.

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

סדר פעולות לפי דרגת התאוששות

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

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

הפרק על טרנזקציות ופיצוי בסוכנים מבית Programmer.ie מציג את השאלה המרכזית: מה קורה כשהסוכן שינה את העולם ושלב 2 נכשל? התשובה ההנדסית טמונה בדפוס הסאגה (Saga Pattern, דפוס ארכיטקטוני לניהול עסקאות מבוזרות שבו כל פעולה מוצלחת מלווה ברישום מראש של פעולת הפיצוי המתאימה לה).

זה אומר שלפני ששלב כלשהו יוצא לפועל, מנגנון הפיצוי שלו כבר רשום במסד הנתונים של ה-Orchestrator. אם הרשת מתנתקת בדיוק אחרי הפעלת ה-API החיצוני, המערכת יודעת בדיוק מהו נתיב הנסיגה עוד לפני שהתקבלה תשובה חיובית.

מקורות

• Advanced Agents From First Principles 40: Your Agent Changed the World. What Happens When Step Two Fails? Build Transactions, Compensation and Reconciliation (web)
• Compensation Receipts for AI Agent Recovery (web)
• Agent Rollback and Checkpoint Patterns: A Reference (web)
• The Agent Blast Radius Model: Matching AI Agent Autonomy to Access, Risk, and Reversibility (web)
• Blast Radius Containment: Isolating Agent Failures Before They Cascade (web)

שאלות נפוצות

למה פקודת Kill רגילה לא מספיקה לעצירת סוכני AI?

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

מה ההבדל בין Rollback רגיל לבין עסקת פיצוי?

פקודת Rollback מוחקת שינויים במסד נתונים ומחזירה אותו למצב הקודם כאילו דבר לא קרה. עסקת פיצוי היא פעולה חדשה לגמרי שמתקנת תוצאה של פעולה בעולם האמיתי שכבר פורסמה ולא ניתנת למחיקה.

איך קבלת פיצוי מסייעת לאבטחת מידע ותאימות?

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

דברים שחשוב לזכור

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

איזה כלי באוטומציה שלכם מבצע כרגע שינויים בלתי הפיכים בעולם האמיתי בלי שיש לו נתיב פיצוי מוגדר מראש?