ביקורת פעולות של סוכני AI: היכן אובדת היכולת להתחקות
שרשרת סוכנית לעיתים רחוקות נראית כמו בקשה אחת ותשובה אחת. אפילו משימה פשוטה היא רצף של מעברים: המודל מהרהר, קורא לכלי, מקבל תוצאה, מתקן את התוכנית וממשיך הלאה. היכולת להתחקות אחר שרשראות סוכניות מחזיקה מעמד בדיוק כל עוד כל מעבר כזה מתועד יחד עם הקלט, הפלט וההחלטה שהתקבלה בו.
הפער נוצר לא בתוך המודל, אלא בנקודות החיבור. קריאות כלים שאינן מתועדות הן החור הנפוץ ביותר: הסוכן פונה למערכת פנימית, תשובתה משפיעה על הפעולה הסופית, אבל ביומן נותר רק טקסט ההודעה הסופית. הרשומה קיימת, אך לא ניתן עוד לשחזר ממנה את סיבת ההחלטה.
לאחר מכן נכנסות לתמונה ניסיונות חוזרים, ענפים מקבילים וכשלים חלקיים. הקריאה נשלחה פעמיים, אחת נפלה בזמן קצוב (timeout), השנייה החזירה נתונים — ובלי מזהה שלב מקצה לקצה לא ניתן לקשר בין הרשומות הללו. ביומן מופיע אוסף של אירועים מנותקים, ואת הסדר והקשר ביניהם יש לנחש.
המחיר מתגלה ברגע חקירת תקלה עם סוכן. במקום לפתוח את העקבות ולראות איזה ארגומנט נשלח לכלי ומה חזר, הצוות משחזר את התמונה לפי סימנים עקיפים: שברי תשובות, מדדים, תשאול עדים. על כך הולכים ימים, והמסקנות נותרות הסתברותיות — קשה להציג אותן ללקוח ולמערך האבטחה. בלי עקבה מלאה לא ניתן לשחזר את התקלה, ומכאן שאין דרך לוודא שהתיקון אכן סוגר את הבעיה.
ביקורת פעולות של סוכני AI נבנית לא על כמות הלוגים, אלא על הקשר מקצה לקצה בין השלבים. נפרט כיצד הדבר נסגר מבחינה טכנית.
מה משתנה לאחר ההטמעה: חקירת תקלות ונסיגות
זמן איתור הסיבה
בעבר החקירה החלה בהצלבת לוגים מנותקים: שלבי הסוכן נשמרו במקום אחד, קריאות הכלים — במקום אחר, וההרשאות — במקום שלישי. הסיבה צפה רק לאחר שעות, וחלק מהמקרים נותרו עם גרסה לא מאומתת.
לאחר ההטמעה היומן נבנה סביב מזהה ה-trace: השלב, הקריאה, הארגומנטים והתשובה משויכים לסשן אחד, ולכן השרשרת משוחזרת תוך דקות ולאורך משמרת שלמה.
שיעור התקלות עם סיבה לא מאומתת יורד למקרים בודדים — בכל אחד יש נתוני קלט, החלטת הסוכן ותוצאת הבדיקה שלו. העיקרון זהה לזה של ניטור שירותים ב-OpenTelemetry, אלא שהסימון הורחב לפעולות הסוכן: רואים לא «משהו נפל», אלא באיזה שלב ובאישורו של מי.
אילו סוגי כשלים נעלמים
- פעולות חוזרות של הסוכן — מפתחות אידמפוטנטיים ודדופליקציה של קריאות: שני חיובים או שני מכתבים זהים לא עוברים.
- חריגה מגבולות ההרשאות — הרשאות נבדקות בכל קריאה, ולא פעם אחת בתחילת הסשן; ניסיון לחרוג מהמסגרת מתועד ונחסם.
- דליפת נתונים בתשובה — בדיקה ביציאה עורכת שדות רגישים לפני השליחה למשתמש.
שחזור הסשן סוגר גם את החקירה וגם את הרגרסיה: הקלטים, גרסאות המדיניות והחלטות הסוכן נשמרים, ולכן אפשר להריץ את המקרה מחדש ולוודא שהתיקון הסיר את הכשל ולא רק הסווה אותו.
דרכים לאיסוף אירועים: השוואת אפשרויות
שלמות היומן תלויה בנקודה שבה נתפס האירוע. ככל שקרוב יותר לסוכן, כך נכנסות לרשומה יותר פרטים — תוכניות, שיקולים ביניים, ארגומנטים של קריאות; ככל שמתרחקים ממנו, כך נמוכה יותר תקורת הכתיבה וקטן הסיכוי לאבד אירוע בעת כשל של הסוכן עצמו. בפועל האפשרויות אינן מתחרות זו בזו, אלא משלימות זו את זו.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| איסוף אירועים בתוך הסוכן | נדרשים שיקולים, תוכניות ושלבי ביניים, ולא רק עצם הקריאה | נשען על משמעת בקוד: פספסו קריאה — האירוע נעלם מהיומן |
| יירוט קריאות כלים בשכבת ביניים | הסוכן פונה לשירותים חיצוניים, למסדי נתונים ולקבצים | ברשומה נראות רק קריאות הכלים, הלוגיקה הפנימית נשארת מחוץ לתמונה |
| איסוף בצד המארגן (orchestrator) | בתהליך פועלים כמה סוכנים ותתי-משימות, וחשוב הניתוב | רמת הפירוט נמוכה יותר, והעומס נופל על צומת האורקסטרציה |
| זרם מספק המודל | המודל חיצוני, ואין גישה לקוד שלו | הרכב השדות וההשהיה נקבעים על ידי הספק, וחלק מהפרטים לא נמסרים |
הבחירה נקבעת לפי השאלה: אילו אירועים חייבים לשרוד כשל ואת החקירה שלאחריו. עבור תקלה נוטים לקחת שני רבדים — יירוט קריאות כלים בתוספת יומן האורקסטרטור, ואיסוף פנימי מוסיפים במקום שבו נדרשת לוגיקת קבלת ההחלטה.
סדר ההטמעה: מסכימת האירועים ועד למסירה
את סדר העבודה מקבעים לפני שורת הקוד הראשונה: תחילה מתארים מה נחשב לפעולה של הסוכן, ורק אחר כך מקימים את האיסוף. אחרת היומן יוצא או עודף, או שאינו עונה על השאלה המרכזית — מי עשה את הקריאה ובאיזה בסיס.
- מיפוי השרשראות הקיימות: עוברים על קריאות למודל, על הכלים ועל השירותים החיצוניים, ומסמנים היכן אובד מזהה הסשן והיכן מתקבלת החלטה ללא תיעוד.
- סכימת האירועים: מאשרים רשימה סגורה — פנייה למודל, קריאה לכלי, סירוב של מדיניות, שינוי מצב. לכל אירוע מקצים מאפיינים מחייבים וקישור לפי מזהה השרשרת.
- מילון שדות היומן: טיפוסים, חובת מילוי, פורמט הזמן וכללי הסוואת נתונים אישיים — לפני שהרשומות מתחילות להצטבר.
- הגדרת איסוף האירועים: מחברים מקורות, חוצצים (buffer) למקרה של אי-זמינות של מאגר הנתונים והגנה מפני אובדן רשומות בעת כשל של הסוכן.
- הפרדת הרשאות גישה: תפקידים לקריאה, לייצוא ולניהול; גם הפנייה ליומן עצמו היא אירוע.
- בדיקה במתחם ניסוי: קריאה מוצלחת, סירוב, ניתוק קשר, משלוח חוזר — בודקים את שלמות הרשומות ואת שחזור השרשרת לפי המזהה.
- קבלת מערכת הביקורת ומסירה: מנתחים מדגם של שרשראות אמיתיות, מוסרים תיעוד ומכשירים את משמרת התורנות לחקירת תקלות.
סכימת האירועים ומילון השדות נשארים אצלכם כמסמך עבודה: לפיהם משנים סוכנים ומגדירים כללי תגובה, בלי לפנות אלינו בכל התאמה.
הערכה בסיום: סכימות, מדיניות, נהלים
לאחר ההרצה נותר אצל הלקוח מערך עבודה שלפיו היומן ממשיך להתקיים בלעדינו: אפשר להרחיב אותו, לנקות אותו ולהעביר אותו למהנדסים חדשים. כל פריט משויך לפעולה מוגדרת — הוספת אירוע, חקירת תקלה, מתן הרשאה.
- סכימת זרמי האירועים — המסלול מקריאה של הסוכן לכלי ועד לכתיבה במאגר: נקודות היירוט, החוצץ, משלוחים חוזרים, ההתנהגות כאשר היעד אינו זמין. לפיה רואים אילו פעולות של הסוכן אינן נכנסות ליומן.
- מילון השדות — המשמעות של כל שדה, חובת המילוי, הפורמטים המותרים. בלעדיו חקירת תקלה הופכת לניחושים לגבי מה בדיוק רשם הסוכן.
- מדיניות גישה ליומן — מי ובאילו תנאים קורא את הרשומות, תקופת השמירה, האיסור על עריכה. היומן הוא append-only: לא ניתן לשנות רשומה קודמת מבחינה טכנית, ולא «לפי ההנחיות».
- תפקידים והרשאות קריאה — מערכים נפרדים למשמרת התורנות, לחקירת תקלות, לביקורת ולמערך האבטחה: כל אחד רואה את החתך שלו, וגישה מלאה אינה ניתנת כברירת מחדל.
- כללי הסוואת נתונים — מה נחתך לפני הכתיבה: נתונים אישיים, מפתחות גישה, תוכן הפניות. ההסוואה פועלת בכניסה, ולכן ערכים רגישים אינם מגיעים למאגר.
- נוהל חקירת תקלות — סיווג האירועים, זמן התגובה, מי מחליט לעצור את הסוכן, וכיצד מתעדים את המסקנות. לצדו מצורפות הנחיות למשמרת התורנות: מה לבדוק ומה לאסוף לפני שמערבים את החוקר.
את התיעוד מעבירים למאגר שלכם ומלווים את השינויים הראשונים, עד שהצוות יתחיל לערוך אותו בעצמו.
מקרה בוחן: חקירת תקלה לפני ואחרי הטמעת היומן
הטריגר היה תקלה עם סוכן תמיכה: הסוכן, המחובר למערכת פנימית דרך כלים, שינה מחוץ לתרחיש סטטוסים וסכומים בחלק מההזמנות. נודע על כך מהלקוחות — השינויים כבר עברו לחיוב.
החקירה התנהלה בלי יומן: בלוגים של האפליקציה היו קריאות למתודות, אך לא היה מזהה סוכן, לא גרסת הנחיות ולא שיוך של הקריאה לסשן. שלושה שבועות של הצלבה ידנית הניבו ייחוס לפחות ממחצית הפעולות, גבולות התקלה נותרו מטושטשים, והנסיגה נעשתה על כל המאגר — יחד עם שינויים לגיטימיים.
מה שינו
הנהיגו יומן בלתי ניתן לשינוי: רשומות רק מתווספות, עריכה ומחיקה אינן אפשריות. בכל קריאה לכלי נרשמים הסוכן וגרסת ההנחיות שלו, נתוני הקלט והפלט, נימוק ההחלטה, מזהי הסשן והמשימה האב.
הרשומות הותאמו לפורמט ה-trace של OpenTelemetry ושומרות גיבוב (hash) של הרשומה הקודמת — השמטה או החלפה מתגלות, ורק סביבת ההרצה של הסוכן יכולה לכתוב.
מדדים לפני ואחרי
- חקירת מקרה: שלושה שבועות של חיפוש ידני → שליפה לפי סוכן, סשן וטווח זמן בתוך שעות.
- ייחוס פעולות: אומת לפחות ממחצית הקריאות → 100%, עם גרסת ההנחיות והיוזם בכל שלב.
- נסיגה: שחזור מלא של המאגר → נסיגה ממוקדת של הרשומות שנפגעו בלבד.
«מקרה דומה נפתר בתוך יום ונמצאה סיבת השורש — חפיפה בהרשאות של שני כלים, ולא טעות של המודל», — ראש תחום.
מה עושים אם המערכת כבר פועלת בפרודקשן?
אין צורך לעצור את הסוכנים: איסוף האירועים משתלב כשכבה נוספת מעל הנקודות שבהן הסוכן קורא לכלים ולשירותים חיצוניים. הקוד של הסוכנים אינו נכתב מחדש — המיירט מתעד את נתוני הקלט והפלט של הקריאה ומעביר את האירוע בזרם נפרד, כדי שזמן התגובה לא יגדל.
ההדרגתיות כאן אינה פשרה, אלא דרך להקטין סיכון. תחילה נכנסים לתצפית התרחישים המסוכנים ביותר — אלה שמשנים נתונים, כותבים למערכות חיצוניות או מוחקים רשומות. פעולות כאלה אינן הפיכות, ודווקא לגביהן שואלים לרוב «מי עשה זאת ובאיזה בסיס». השאר מצטרפים בגלים הבאים, כאשר האירועים הראשונים כבר נבדקו לשלמות.
כל גל הוא קונפיגורציה, ולא בנייה חדשה של השירות. המיירט מופעל בדגל על קבוצת תרחישים, הכללים מסווים נתונים אישיים בכניסה, והאירועים נשלחים לתור ומשם למאגר. אם המאגר אינו זמין, הם מצטברים בחוצץ מקומי ונשלחים לאחר חידוש הקשר: כשל קצר לא אמור לעלות בהיסטוריית הפעולות.
התעדוף נבנה על שני צירים — הסתברות הטעות בתרחיש ומחיר השלכותיה. פעולות בלתי הפיכות ואינטגרציות חיצוניות באות ראשונות, תרחישי שיחה ותרחישי מידע — אחרונות. האפקט ניכר כבר מהגל הראשון: יומן הביקורת מכסה בדיוק את המסלולים שבהם בעבר חקירת התקלה הייתה בלתי אפשרית.
גם נסיגה נכללת בתכנון: הסרת הדגל מחזירה את המערכת להתנהגות המקורית, והאירועים שכבר נאספו נותרים זמינים. אם הסוכנים שלכם כבר בפעולה — ספרו לנו אילו תרחישים מעוררים את מירב השאלות, ונחזור עם תוכנית הטמעה מדורגת המותאמת למערך שלכם.
ספקות לגבי יומן הביקורת: מפרקים סעיף-סעיף
ההתנגדויות ליומן ביקורת הן בדרך כלל אותן התנגדויות, והן מוצדקות: קל להפוך רשומה לבלתי שלמה, קל לשכתב אותה, קל להפוך אותה למזבלה של נתונים אישיים. להלן כיצד אנו סוגרים את ארבעת הספקות הנפוצים ביותר ברמת סכימת האחסון וכללי הכתיבה.
הסוכן יקרא למודל ישירות, תוך עקיפת השער המשותף — הרשומה תאבד?
אנחנו אוספים אירועים משני רבדים: יירוט ברמת התעבורה ומטפלים בתוך תהליך הסוכן, שבהם מתועדות קריאות לכלים ופניות לשירותים חיצוניים. אם אירוע עבר רק בנתיב אחד, ברשומה נשארת ציון על חוסר שלמות של השרשרת, והחוצץ המקומי שולח את החסר בהזדמנות הראשונה. הפער נראה בדוח, ואינו מוסתר.
ברשומות יימצאו נתונים אישיים — מה עושים עם זה?
כברירת מחדל היומן שומר מזהה של נושא הנתונים ומטא-נתונים של הקריאה, ולא את גוף הבקשה והתשובה. במקום שבו הטקסט המלא באמת נדרש לחקירה, מפעילים הסוואת שדות ופסבדונימיזציה — הזיקה לזהות נשמרת בנפרד ונגישה למעגל מצומצם של תפקידים.
כמה זמן לשמור רשומות כדי שהיומן לא יהפוך לנטל?
התקופה נקבעת לפי סוג האירוע, ולא במספר אחד אחיד: רשומות תפעוליות נשמרות זמן קצר, והרשאות והחלטות משמעותיות — זמן ארוך. מכאן פועל כלל מחזור החיים: מה שפג תוקפו מיוצא לאחסון קר, ובשלב מאוחר יותר נמחק יחד עם המפתחות.
ניתן לשכתב רשומות בדיעבד — כיצד מונעים זאת?
כל רשומה מקבלת טביעת אצבע של הקודמת וחתימה של הצומת שיצר אותה, ולכן עריכה באמצע שוברת את כל השרשרת שאחריה. את טביעת האצבע השורשית מקבעים מעת לעת בצד חיצוני, ואת המאגר עצמו מחזיקים במצב append-only — אי אפשר למחוק או להחליף את העבר בלי להשאיר עקבה.
נדון במשימה שלכם ונחזור עם תוכנית
כדי לעבור משיחה לתוכנית, די בתיאור המערך: אילו סוכנים פועלים, מי יוזם את הקריאות, דרך אילו שירותים עוברות הבקשות, היכן נמצא המאגר ומי אחראי על התשתית. זה מספיק כדי לפרק את המשימה לשלבים ולחזור עם אומדן לוחות זמנים וגבולות העבודה — בלי מחזור מקדים ארוך.
- דיון במשימה: מנתחים את תרחישי הסוכנים, מי מקבל החלטות, מה נחשב לפעולה רגישה ומה בדיוק צריך להיכנס לביקורת הפעולות של סוכני AI.
- סכימת האיסוף: מגדירים את נקודות היירוט — שער לפני המודלים, קריאות לכלים, פניות למסדי נתונים — ואת פורמט האירוע: מי, מה, מתי, עם איזה הקשר ואיזו תוצאה.
- תוכנית שלבי ההטמעה: פיילוט על סוכן אחד, אחר כך שכפול, הגדרת אחסון ותקופות שמירה, חיבור חיפוש וייצוא.
- היקף העבודה בביקורת: רשימת האינטגרציות, כללי נרמול האירועים, הפרדת הגישה ליומנים, הגנה מפני החלפת רשומות.
- קריטריוני קבלה: שיעור הפעולות של הסוכנים המכוסות בתיעוד, שלמות ההקשר בכל שלב, זמן איתור התקלה, שחזור שרשרת ההחלטות מהבקשה ועד לתוצאה.
- מה לשלוח: רשימת השירותים והסוכנים, דוגמה לבקשה ולתשובה אופייניות, דרישות של רגולטורים או של מחלקות פנים-ארגוניות, מגבלות על תקופות השמירה.
- צעדים הבאים: מאשרים את הגבולות, מקבעים את תוכנית השלבים ואת קריטריוני הקבלה, ולאחר מכן מתחילים בפיילוט.
תארו את המשימה בצורה הזו — ונחזור עם אומדן, תוכנית שלבים והיקף העבודה.