Agent Telemetry Standardization — פורמט אחיד למדדי סוכנים בין ספקים

מאת צוות מדיה דיל · 12.08.2026 · Agentic Development · 5 דק׳

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

חברה שמשתמשת בשלושה סוכני קוד שונים — אחד מבוסס Claude, אחד מבוסס מודל פנימי, ואחד כלי SaaS חיצוני — ניסתה לענות על שאלה פשוטה לכאורה: "איזה סוכן הכי אמין למשימות תיקון באגים?" והתברר שאי אפשר לענות עליה, כי כל סוכן מדווח נתונים בפורמט שונה לגמרי. אחד מדווח "success rate", אחר מדווח "tasks completed", השלישי לא מדווח כלום מעבר ליומן טקסט חופשי. בלי פורמט אחיד, כל השוואה היא בעצם ניחוש. Agent Telemetry Standardization הוא המענה לבעיה הזו: הגדרת סכימת מדדים אחידה שכל סוכן, בלי קשר לספק, מדווח לפיה — כך שאפשר להשוות תפוקה, אמינות ועלות על בסיס משותף אמיתי.

למה כל ספק ממציא את הגלגל בעצמו

כל ספק מודל או כלי סוכן בונה את מערכת המדדים שלו סביב מה שהכי קל למדוד מנקודת המבט שלו — ספק מודל מודד טוקנים ו-latency, כלי SaaS מודד "משימות שהושלמו" לפי ההגדרה הפנימית שלו, ומסגרת קוד פתוח מודדת קריאות כלי. אף אחד מהמדדים האלה, בפני עצמו, לא עונה על השאלה שבאמת מעניינת ארגון: האם הסוכן הזה שווה את הכסף שהוא עולה, ביחס לתועלת בפועל שהוא מביא. הפער הזה הוא בדיוק מה ש-Continuous AI תלוי בו — ראו הרחבה על ההשפעה הרחבה יותר במדריך AI-Native SDLC — כי בלי מדידה אחידה, אי אפשר לקבל החלטת ניהול מושכלת על אילו סוכנים להשקיע בהם יותר.

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

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

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

מבנה הסכימה המומלץ

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

• Task Outcome — לא רק success/failure בינארי, אלא סולם: הושלם ללא התערבות, הושלם עם תיקון קל, הושלם עם תיקון משמעותי, נכשל ובוטל.
• Human Touch Points — מספר הפעמים שנדרשה התערבות אנושית, ובאיזה שלב (במהלך הביצוע, בסקירה, אחרי merge).
• Resource Cost — טוקנים, זמן ריצה, ומספר קריאות כלי — מנורמל כך שאפשר להשוות בין ספקים עם תמחור שונה.
• Safety Events — מספר הפעולות שנחסמו על ידי harness, ומספר הפעמים שהסוכן ביקש אישור לפני פעולה בסיכון גבוה.
• Time to Completion — לא רק זמן חישוב, אלא זמן wall-clock מלא כולל המתנה לאישור אנושי.

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

מימוש שכבת ה-Adapter

בפועל, שכבת Adapter היא thin wrapper שרץ סביב כל סוכן ומתרגם את הפלט הגולמי שלו לסכימה המשותפת. לדוגמה, אם סוכן מבוסס Claude Agent SDK מדווח מבנה שונה מכלי SaaS חיצוני, ה-Adapter קורא את הפלט הגולמי משניהם ומייצר אירוע טלמטריה אחיד:

{
  "agent_id": "claude-code-v2",
  "task_outcome": "completed_minor_fix",
  "human_touch_points": 1,
  "tool_calls": 14,
  "tokens_used": 48200,
  "wall_clock_seconds": 340,
  "safety_events": 0
}

פורמט אחיד כזה מאפשר לבנות דשבורד השוואתי אחד שמרכז נתונים מכל הסוכנים בארגון, ולזהות מגמות — למשל שסוכן מסוים מצטיין במשימות תיקון באג אבל נדרש הרבה יותר human touch points במשימות ארכיטקטוניות. פירוט טכני על בניית סוכנים לפי SDK מובנה, כולל שכבות אינסטרומנטציה מובנות, נדון במדריך Claude Agent SDK.

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

קישור לתהליכי הסלמה ולבדיקות רגרסיה

טלמטריה אחידה לא שימושית רק לדוחות רבעוניים — היא הבסיס לשני תהליכים תפעוליים קריטיים. הראשון הוא זיהוי מתי סוכן צריך להעביר משימה לבן אדם: כשה-Safety Events או ה-Human Touch Points על סוג משימה מסוים חוצים סף מוגדר, המערכת יכולה להסיק אוטומטית שרמת האוטונומיה הנוכחית גבוהה מדי, נושא שמפותח לעומק במדריך Agent-to-Human Escalation. השני הוא זיהוי שינוי בין גרסאות מודל, כפי שתואר במדריך Semantic Diffing — בלי מדדים אחידים בין הרצה להרצה, אי אפשר לזהות בביטחון שהשינוי במדד נובע מהמודל ולא מרעש אקראי במדגם.

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

תגיות: agent telemetry · AI observability · vendor-agnostic metrics · AI agent monitoring · multi-model comparison · agent evaluation

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