צוות Foundry של Microsoft הוסיף מעקב (tracing) מבוסס OpenTelemetry למסגרת הסוכנים (agent framework) שלו, מה שמאפשר למפתחים לראות ביצוע מקצה לקצה לאורך סוכנים הטרוגניים המונעים על ידי LLM.

למה מערכות מרובות-סוכנים (multi-agent systems) זקוקות ליותר מסתם קובצי לוגים

תרגיל תגובה לאירועים מונע-AI טיפוסי משתמש בסוכן מפקד (commander agent) המנהל מספר סוכני מומחה: אחד מנתח לוגים, אחר מזהה חריגות במדדים (metrics), שלישי מתאים תסמינים ל-runbooks, ונתב (router) בוחר את מודל השפה הטוב ביותר עבור כל תת-משימה. כל מומחה עשוי לקרוא למודל שונה — למשל, גרסה של "gpt-5-mini" — ולהפעיל כלים משלו. כשמשהו משתבש, מהנדסים נאלצים להתבונן בלוגים מבודדים המראים מה כל רכיב עשה, אך ללא תצוגה של האופן שבו החלקים מתחברים זה לזה.

ללא מעקב (trace) מאוחד, סיבת השורש מתחבאת במעבר (hand-off) בין הסוכנים. המפקד עשוי לשלוח בקשה שקורא הלוגים מטפל בה כראוי, אך מומחה המדדים מפרש לא נכון את הנתונים ומציע את ה-runbook הלא נכון. ניפוי שגיאות (debugging) של השרשרת הזו באופן ידני גוזל זמן וחשוף לטעויות.

כיצד OpenTelemetry מחבר את זרימת העבודה יחד

OpenTelemetry מגדיר שני מושגי ליבה: traces ו-spans. trace הוא מזהה ייחודי שעוקב אחר בקשה מהכניסה ועד לתגובה הסופית. span מתעד פעולה בודדת — כגון קריאה למודל שפה או הפעלת כלי — בתוך אותו trace.

כאשר סוכן מקבל בקשה, הוא שואב את ה-Trace ID הנכנס מתוך ה-metadata של הבקשה ויוצר child span היורש את אותו מזהה. ה-child span מתעד את זמן ההתחלה שלו, משך הזמן, מאפיינים (שם המודל, הכלי ששימש) וכל שגיאה. התהליך חוזר על עצמו עבור כל סוכן בהמשך השרשרת (downstream), ובכך בונה עץ המשקף את הזרימה הלוגית של המשימה הכוללת.

OpenTelemetry תומך גם ב-Baggage, נשא (carrier) קל משקל עבור זוגות מפתח-ערך מותאמים אישית. על ידי הצמדת "drill-id" או הקשר עסקי אחר ל-baggage בראש ה-trace, כל span בהמשך השרשרת יורש באופן אוטומטי את המזהה הזה. מעבד spans (span processor) מקדם לאחר מכן את ה-baggage למאפיינים (attributes) רגילים, מה שמקל על שאילתה של כל ה-spans השייכים לתרגיל אירוע מסוים.

איך נראית ממשק המעקב החדש

עם ה-instrumentation שהוטמע, Azure Monitor (או כל backend תואם OpenTelemetry) מציג היררכיה ויזואלית:

  • Agent name / ID – מראה איזה רכיב ביצע את הפעולה.
  • Tool usage – מתעד איזה שירות חיצוני או פונקציה נקראו.
  • Model version – מתעד את ה-LLM המדויק ששימש, דבר שימושי למעקב אחר רגרסיות לאחר שדרוג מודל.
  • Token consumption – קולט כמה טוקנים נשלחו ונתקבלו מהמודל, מה שעוזר לצוותים לנהל עלויות.
  • Latency / duration – מדגיש היכן מופיעים צווארי בקבוק, בין אם בהסקה (inference) של המודל ובין אם ב-I/O של הכלים.

בדוגמת תרגיל האירוע, ה-root span של המפקד מוליד child spans עבור כל מומחה, וכל מומחה מוליד ילדים נוספים עבור קריאות המודל שלו. לחיצה על כל צומת (node) חושפת את סט המאפיינים המלא, כך שמהנדס יכול לראות באופן מיידי את הפרטים של כל פעולה.

החשיבות עבור פעולות ממוקדות-AI

  • מהירות ניתוח סיבת השורש – צוותים יכולים לעקוב אחר כשל עד ל-span המדויק שזרק שגיאה, מה שמקצר את זמן הפתרון הממוצע (MTTR).
  • נראות עלויות – ספירת הטוקנים מוצגת לצד ה-latency, מה שמאפשר למחלקת הכספים לזהות שימוש חריג לפני שחשבונות הענן מתנפחים.
  • כוונון ביצועים (Performance tuning) – spans בעלי latency גבוה לאורך הסוכנים מצביעים על המקומות שבהם caching, בחירת מודל או עיצוב מחדש של כלים עשויים לשפר את התפוקה (throughput).

מה כדאי לעקוב אחריו בהמשך

פרויקטים הבנויים על LangChain, ה-OpenAI SDK או שכבות תזמור (orchestration) אחרות יכולים לאמץ את אותן מוסכמות סמנטיות עבור GenAI, ובכך לסלול את הדרך ל-traces שזורמים בין ספקי ענן ופריסות on-premise.

ארגונים פשוט צריכים להפעיל את ה-OpenTelemetry SDK בסוכנים שלהם ולשלוח נתונים ל-Azure Monitor או ל-collector בקוד פתוח.

שורה תחתונה

OpenTelemetry מספק למערכות AI מרובות-סוכנים את ה"דבק" החסר שהופך פיזור של לוגים לנרטיב קוהרנטי. על ידי הפצת Trace ID יחיד לאורך LLMs הטרוגניים, נתבים וקריאות לכלים, מפתחים יכולים לאתר כשלים, לנטר עלויות ולבצע אופטימיזציה לביצועים מבלי להמציא מחדש תשתית מעקב.