Kill Switch לסוכני AI — עצירת פעילות חריגה בזמן אמת

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

למה 'לעצור Agent' קשה יותר מלעצור שירות רגיל, איך בונים ערוץ עצירה Out-of-Band שנבדק בין כל פעולה, ולמה Time-to-Halt הוא המדד שבאמת קובע.

שלוש בלילה, Agent אוטומטי שאמור לעדכן מחירים בקטלוג לפי משוב תחרותי מתחיל, בעקבות באג בפרשנות נתונים, להוריד מחירים של אלפי מוצרים ל-90 אחוז הנחה, אחד אחרי השני, בקצב של כמה עשרות לשנייה. הצוות המתריע רואה את זה בדשבורד רק אחרי כמה דקות. השאלה שקובעת אם מדובר באירוע מביך או באסון כספי אמיתי היא לא "האם היה בלאג", אלא "כמה זמן לקח מרגע הזיהוי ועד שהפעילות נעצרה בפועל". Kill Switch הוא בדיוק המנגנון שאמור לענות לשאלה הזו במספר יחיד: שניות, לא דקות.

למה "לעצור Agent" קשה יותר מ"לעצור שירות"

עצירת שירות רגיל היא פעולה מוכרת - Kill Process, Scale to Zero, ניתוק מ-Load Balancer. עצירת Agent מורכבת יותר משתי סיבות. ראשית, פעילות Agent לרוב מבוזרת: יש לו כמה משימות מקבילות פעילות, חלקן כבר באמצע קריאה לכלי חיצוני עם Side Effect בלתי הפיך (שליחת בקשת HTTP שכבר יצאה, למשל) - עצירת התהליך עצמו לא עוצרת פעולות שכבר יצאו לדרך ומחכות לתגובה. שנית, יש שאלה אמיתית של Kill רך מול קשה: עצירה מיידית וגסה (SIGKILL) עלולה להשאיר עסקאות במצב ביניים לא עקבי - למשל תשלום שנשלח אך לא נרשם כמושלם - ואילו המתנה ל"סיום מסודר" עלולה לקחת יותר מדי זמן במצב חירום שבו כל שנייה נוספת מייצרת נזק נוסף. אין תשובה אחת נכונה; יש צורך בשני מסלולים נפרדים ומוגדרים מראש: עצירה רכה (הפסק לקבל משימות חדשות, סיים את מה שכבר באמצע) ועצירה קשה (עצור הכל, כולל השלכת עבודה באמצע ביצוע), עם קריטריון ברור מתי משתמשים בכל אחת.

ארכיטקטורת האות: איך אות עצירה מגיע לכל Worker

הטעות הנפוצה ביותר היא לבנות Kill Switch שהוא בעצם רק Flag בבסיס נתונים שנבדק "בהזדמנות הבאה" - כלומר בתחילת המשימה הבאה של כל Worker. אם Worker כבר באמצע לולאת פעולות ארוכה (כמו התרחיש עם עדכון אלפי מחירים ברצף), הוא לא יבדוק את ה-Flag הזה עד שהלולאה שלו תסתיים - מה שהופך את ה-Kill Switch לחסר תועלת בדיוק ברגע שהוא הכי נחוץ. הפתרון הוא ערוץ עצירה Out-of-Band עם Push, לא Poll: Pub/Sub ייעודי (Redis Pub/Sub, SNS, או אפילו Signal ברמת מערכת ההפעלה) ששולח אות עצירה שנבדק בין כל פעולה בודדת בתוך הלולאה, לא רק בין משימות. זה דורש לבנות את הלולאה עצמה מודעת-עצירה מלכתחילה - כל איטרציה בודקת את האות לפני שהיא ממשיכה לאיטרציה הבאה, לא רק בתחילת המשימה כולה.

for (const item of priceUpdateQueue) {
  if (await killSignal.isActive("pricing-agent")) {
    await gracefulHalt(item);
    break;
  }
  await updatePrice(item);
}

מי מפעיל את זה, וכמה זמן זה לוקח בפועל

מנגנון טכני מושלם חסר ערך אם ההפעלה בפועל תלויה במישהו שצריך למצוא את הכפתור הנכון בממשק לא מוכר בשעה שלוש בלילה. Kill Switch יעיל דורש נגישות מיידית: כפתור עצירה בדשבורד המרכזי שנגיש מכל מכשיר, כולל טלפון נייד; אפשרות הפעלה דרך פקודת CLI פשוטה שלא דורשת גישה לממשק גרפי כלל; ובמקרים קריטיים, אפילו אינטגרציה עם ערוץ תקשורת קיים (הודעת Slack עם פקודה מוגדרת מראש שמפעילה עצירה מיידית). המדד שקובע אם המנגנון עובד באמת הוא Time-to-Halt - כמה זמן חולף בין הרגע שמישהו מחליט לעצור לבין הרגע שהפעילות בפועל נעצרת - ומדד הזה צריך להימדד בפועל, לא רק להיות מוערך תיאורטית, דרך תרגילי Game Day תקופתיים שמדמים תקרית אמיתית.

מה קורה אחרי העצירה: לא רק "לעצור" אלא גם "לתקן"

עצירת הפעילות היא רק החצי הראשון. החצי השני הוא שחזור למצב תקין: תיעוד מדויק של כל פעולה שבוצעה עד רגע העצירה (כדי לדעת מה צריך לתקן), ומנגנון Rollback או Compensating Transaction לפעולות שכבר יצאו לדרך ואי אפשר לבטל ישירות (במקרה של המחירים - שחזור אוטומטי מגיבוי, לא תיקון ידני מוצר-מוצר). מערכת שיודעת לעצור אך לא בנתה מראש את מסלול השחזור מגלה, ברגע האמת, שהיא צריכה לבנות את שניהם בו-זמנית תחת לחץ - התרחיש הכי גרוע לבניית תשתית קריטית. הקשר בין Kill Switch לבין Human Override Protocols חשוב כאן: Kill Switch הוא הכלי לעצירת חירום מלאה במצב חריג בלתי צפוי, ואילו Override הוא מנגנון עדין יותר להתערבות נקודתית באמצע זרימה תקינה - שני כלים משלימים, לא זהים, שכל מערכת Agent אוטונומית צריכה את שניהם.

זיהוי אוטומטי: מתי המערכת עוצרת את עצמה

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

בדיקה לפני שקורה אירוע אמיתי

אף Kill Switch לא צריך להיבדק לראשונה בזמן אירוע אמיתי - זו הדרך הבטוחה ביותר לגלות שהוא לא עובד בדיוק ברגע שהכי צריך אותו. תרגילי Game Day תקופתיים, שבהם מפעילים את מנגנון העצירה בכוונה על סביבת Staging תוך סימולציה של תרחיש חריג (למשל הרצת Agent שמבצע פעולות בקצב גבוה בכוונה), חושפים בעיות שקשה לצפות מראש: אות עצירה שמגיע אך לא נבדק בגלל תזמון לא נכון בלולאה, Worker שנתקע במצב ביניים כי לא טופל Timeout, או פשוט זמן תגובה אנושי איטי מדי כי איש לא ידע איפה הכפתור. הבדיקה הזו קשורה הדוקות לתחום הרחב יותר של בדיקות אבטחה ל-Agents, ומן הראוי לכלול תרחיש Kill Switch ספציפי בכל מחזור בדיקה תקופתי, לא רק כחלק מבדיקת חדירה חד-פעמית.

תגיות: Kill Switch AI · circuit breaker agent · emergency stop · Time-to-Halt · agent runaway · graceful halt

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