ארבעה סוכני AI אוטונומיים יכולים כעת לזהות תקלה בתוכנה, לערוך את הקוד הבעייתי ולאשר את התיקון — וכל זאת בפחות מדקה, הודות לתהליך עבודה (workflow) חדש מבוסס observability שנבנה עבור ה-hackathon של SigNoz.
המערכת, המכונה AgentOps, מנטרת את SigNoz לאיתור קפיצות בשגיאות, שולפת את הלוגים (logs) והעקבות (traces) הרלוונטיים, מזהה בדיוק את הקובץ והשורה האחראים, עורכת את המקור בתוך sandbox, ואז מריצה מחדש את הבקשה כדי להוכיח שהבאג נעלם. כל מחזור מלא מסתיים תוך 30–60 שניות, וכל התהליך מתבצע ללא צורך בהנחיה (prompt) אנושית אחת.
למה observability חשוב לסוכני AI
פרקטיקת SRE מסורתית מתייחסת ללוגים, למטריקות ולעקבות מבוזרים (distributed traces) כאל "העיניים" של השירות. כאשר בקשה נכשלת, מהנדס עוקב אחר ה-trace עד לרכיב הבעייתי. אותו עיקרון מניע כעת את AgentOps, אך ה"שירות" הנצפה הוא סוכן ה-AI עצמו.
כל כלי שהסוכן מפעיל — בין אם מדובר בקריאה למודל שפה, עריכת מערכת קבצים או מריצת בדיקות (test runner) — יוצר span בתוך ה-trace. ה-span מתעד את זמן ההתחלה, משך הזמן וסטטוס ההצלחה, כך שהסוכן יכול לראות כמה זמן ארך כל שלב חשיבה והאם הוא הצליח. על ידי חיבור ה-spans הללו יחד, הסוכן בונה תמונה מלאה של תהליך החשיבה שלו, בדיוק כפי שבן אדם היה עושה בעת ניפוי שגיאות (debugging) ידני.
השינוי המרכזי הוא מ-"observability כשכבת דיווח" ל-"observability כתפיסה". AgentOps מזינה את נתוני ה-trace חזרה אל הסוכנים, מה שמאפשר להם להסיק מסקנות לגבי הפעולות שלהם בזמן אמת. התוצאה היא לולאה שבה ה-AI לא רק מייצר היפותזה, אלא גם מאמת אותה מול אותה טלמטריה (telemetry) שבה הוא משתמש כדי לזהות את הבעיה.
תהליך העבודה בן ארבעת השלבים
- Monitor (ניטור) – "Watcher" קל-משקל סורק את SigNoz לאיתור שגיאות שדווחו לאחרונה.
- Diagnose (אבחון) – הסוכן שולף את הלוגים וה-traces הקשורים, מחלץ את ה-stack, ומבודד את קובץ המקור ומספר השורה שגרמו לכשל.
- Fix (תיקון) – באמצעות שרת מערכת קבצים בתוך sandbox, הסוכן כותב patch לשורה שזוהתה. ה-sandbox אוכף הרשאות מחמירות ומבצע rollback אוטומטי אם העריכה מפרה את המדיניות.
- Verify (אימות) – הסוכן שולח מחדש את הבקשה המקורית מול הקוד המתוקן. אם ה-trace מראה ריצה תקינה, התיקון מאושר (committed); אחרת, הסוכן חוזר על התהליך.
כל השלבים מנוהלים (orchestrated) על ידי אותה קבוצת סוכנים, כאשר כל אחד פועל כמיקרו-שירות (micro-service) אוטונומי. ניתן לצפות בכל השרשרת באמצעות spans תואמי OpenTelemetry, ש-SigNoz קולטת ומציגה ויזואלית.
לקחים שנלמדו בדרך הקשה בנושא אמינות
בהירות השגיאות
סטטוס כללי של "failed" אינו מלמד דבר. הצוות הוסיף סיבות כשל מפורטות — למשל, "היפותזה שגויה" או "ה-patch שבר את התהליך" — כדי שסוכנים בשלבים הבאים יוכלו להחליט אם לנסות שוב, לחזור אחורה או לבטל. זה משקף את הדרך שבה בני אדם מגדירים סיבות שורש בדו"חות post-mortem.
השהיית נתונים (Data latency)
טלמטריה אינה מופיעה באופן מיידי. הסוכנים כוללים כעת הפסקה קצרה ובדיקת תקינות (sanity check) כדי לוודא שהלוגים הנדרשים אכן הגיעו לפני שהם מאשרים תיקון. ללא הגנה זו, סוכן עלול לפעול על בסיס נתונים חסרים ולהפיק תוצאה חיובית שגויה (false positive).
גבולות אבטחה
מתן אפשרות ל-AI לכתוב קוד מהווה סיכון של Privilege escalation (הסלמת הרשאות). ה-sandbox פועל מאחורי שרת מערכת קבצים ייעודי המגביל את היקף הכתיבה לרפוזיטורי היעד ומחזיר אוטומטית למצב הקודם אם בדיקה נכשלת. מודל הכלה זה שומר על כוחו של ה-AI תחת שליטה.
מגבלות טוקנים (Token limits)
מודלי שפה גדולים צורכים טוקנים של API, והמכסות היומיות עלולות להיגמר באמצע חקירה. AgentOps עוקב אחר השימוש בטוקנים לכל תקרית ומגביל (throttles) קריאות נוספות ברגע שמגיעים לסף מסוים, ובכך מונע שרשרת של תיקונים שנכשלו כשהמכסה נגמרת.
מה הדמו הוכיח
הצוות הכניס באג חדש לגמרי שמעולם לא הופיע בבסיס הקוד. AgentOps זיהה את האנומליה, עקב אחריה עד לשורה המדויקת, יצר עריכה מתקנת, החיל את ה-patch בתוך ה-sandbox ואימת שהבקשה הצליחה — וכל זאת ללא שינויי קוד ידניים או הנחיות (prompts) חדשות. הזמן מקצה לקצה נשאר מתחת לדקה, בהתאם למשך של 30–60 שניות שדווח.
נקודת מבט נגדית: אוטונומיה אינה פתרון קסם
מה לעקוב אחריו בהמשך
- טלמטריה אגנוסטית למודל – ככל שיותר ספקים יחשפו spans תואמים ל-OpenTelemetry, הגישה עשויה להפוך לניטרלית לספק, מה שיקל על האימוץ במערכות (stacks) הטרוגניות.
- מנגנוני הגנה מבוססי מדיניות – הטמעת מדיניות ניתנת להגדרה הקובעת אילו קבצים סוכן (agent) רשאי לערוך, או אילו סדרות בדיקות (test suites) חייבות לעבור לפני commit, תיתן מענה לחששות של ממשל (governance).
- תקצוב טוקנים מודע לעלות – הקצאת טוקנים דינמית המבוססת על חומרת האירוע עשויה למנוע התרוקנות של מכסה (quota), תוך שמירה על היכולת לטפל בבאגים בעלי השפעה גבוהה.
AgentOps מראה שסבב תיקון הבאגים יכול לארוך 30–60 שניות. הניסוי מדגים הוכחת יכולת (proof-of-concept) לכך שניתן להשתמש ב-observability על ידי עוזרים תוכנה אוטונומיים.