Agent Discovery: איך Agents מוצאים זה את זה ואת היכולות הרלוונטיות בזמן ריצה

מאת צוות מדיה דיל · 09.08.2026 · Enterprise AI · 7 דק׳

מדריך טכני ל-Agent Discovery: מ-hardcoded routing לגילוי דינמי, Agent Cards ופרוטוקול A2A, שרשראות אמון, וסיכוני Discovery Spoofing.

הבעיה: agent שצריך עזרה מ-agent אחר, אבל לא יודע שהוא קיים

בדור הראשון של מערכות multi-agent, החיבור בין agents היה hardcoded בקוד: agent A קורא ישירות ל-endpoint הידוע של agent B, כי מפתח כתב את זה כך. זה עובד כשיש שני-שלושה agents ידועים מראש, אבל נשבר ברגע שהמערכת גדלה - ארגון עם עשרות agents מומחים לתחומים שונים לא יכול לתחזק מטריצת חיבורים hardcoded בין כולם, ובטח שלא כשagents חדשים נוספים באופן שוטף. Agent Discovery הוא הפתרון: מנגנון שמאפשר ל-agent "לשאול" בזמן ריצה "מי יכול לעזור לי במשימה הזו", ולקבל תשובה דינמית במקום להסתמך על רשימת חיבורים קבועה מראש.

מ-Service Discovery קלאסי ל-Agent Discovery

הרעיון הבסיסי לא חדש - הוא מזכיר מאוד service discovery בעולם המיקרו-שירותים (Consul, etcd, Kubernetes DNS): שירות נרשם במרכז עם היכולות שלו, ושירותים אחרים שואלים את המרכז כדי למצוא מי מספק פונקציונליות מסוימת. ה-agent discovery מוסיף על זה שכבה: לא מספיק לדעת "מי חי ובאיזו כתובת" - צריך לדעת "מה ה-agent הזה יכול לעשות בפועל, באילו תנאים, ומה עלות הפנייה אליו" - כי agent, בניגוד לשירות REST פשוט, יכול לשנות התנהגות בין גרסאות, לדרוש הקשר מסוים כדי לפעול נכון, ולעלות כסף בכל קריאה.

Agent Cards ופרוטוקול A2A - הסטנדרט המתגבש

אחת ההתפתחויות המרכזיות בתחום היא פרוטוקול Agent-to-Agent (A2A), שמגדיר "Agent Card" - מסמך מובנה שכל agent חושף על עצמו, ומתאר את היכולות שלו, את הפורמט שהוא מצפה לקבל בקשות בו, ואת תנאי האימות הנדרשים כדי לפנות אליו. זה דומה במידה רבה למה ש-OpenAPI/Swagger עושה עבור REST APIs - חוזה מתועד וניתן לקריאה מכונה, שמאפשר ל-agent אחר (או ל-orchestrator שמתאם ביניהם) להבין באופן אוטומטי איך לתקשר עם agent שהוא לא מכיר מראש, בלי אינטגרציה ידנית מותאמת אישית לכל צמד.

{
  "agent_card": {
    "name": "invoice-reconciliation-agent",
    "capabilities": ["match_invoice_to_po", "flag_discrepancy"],
    "input_schema": "https://agents.internal/schemas/invoice-v2.json",
    "auth_required": "mTLS + agent-token",
    "cost_per_call_estimate": "0.02 credits",
    "trust_tier": "internal-verified"
  }
}

שלושה דפוסי שימוש נפוצים ב-Discovery

בפועל, discovery בין agents משמש בשלושה הקשרים שונים, וכדאי להכיר את ההבדל ביניהם כי כל אחד דורש רמת בקרה שונה. הראשון, Task Delegation - agent מתאם (orchestrator) מפרק משימה מורכבת לתת-משימות ומחפש דרך discovery איזה agent מומחה מתאים לכל תת-משימה; כאן הסיכון מוגבל יחסית כי ה-orchestrator שולט בזרימה הכוללת. השני, Peer Consultation - agent "שואל" agent אחר שאלה נקודתית תוך כדי ביצוע המשימה שלו עצמו, בלי מתאם מרכזי; כאן הסיכון גבוה יותר כי אין נקודת בקרה יחידה שרואה את כל התמונה. השלישי, Capability Advertisement - agent חדש שנכנס למערכת "מכריז" על עצמו כדי שאחרים יוכלו למצוא אותו בעתיד; זהו למעשה שלב הרישום עצמו, וההגנה עליו (מי בכלל רשאי להכריז) היא קו ההגנה הראשון מפני spoofing.

ארכיטקטורת Discovery: Registry-Based מול Broadcast

Registry-Based Discovery

agent חדש נרשם ב-Agent Registry (ראו המאמר הייעודי) ברגע ה-deploy, וכל agent שמחפש יכולת מסוימת שואל את ה-registry - בדיוק כמו DNS lookup. זו הגישה הנפוצה והבטוחה יותר, כי היא נותנת נקודת בקרה מרכזית: אפשר לחסום agent לא מאושר מלהופיע ב-discovery, ואפשר לעקוב אחרי כל שאילתת גילוי כאירוע מבוקר.

Broadcast / Peer Discovery

agents "מכריזים" את עצמם ברשת מקומית או mesh, ו-agents אחרים "מאזינים" ומגלים אותם ישירות בלי מתווך מרכזי. זה גמיש יותר ועמיד לכשל של רכיב מרכזי, אבל הרבה יותר קשה לאבטח - כל agent ברשת יכול, תיאורטית, "להכריז" על עצמו כבעל יכולות שהוא לא באמת מספק, בלי בקרה מרכזית שתתפוס את זה.

סיכון קריטי: Discovery Spoofing ושרשראות אמון

הסיכון המרכזי ב-agent discovery הוא לא טכני-תפעולי אלא אבטחתי: אם agent יכול לשכנע agents אחרים שהוא מספק יכולת מסוימת - בלי אימות אמיתי - הוא יכול להתחזות ל-agent לגיטימי ולקבל בקשות שלא מיועדות לו, כולל נתונים רגישים שמצורפים לבקשה. זה למעשה גרסה של DNS spoofing, מותאמת לעולם ה-agents. ההגנה הנכונה דורשת שרשרת אמון (trust chain) מפורשת: כל agent card חייב להיות חתום קריפטוגרפית על ידי הרשות שאישרה אותו (למשל, ה-Agent Registry הארגוני), ו-agent שקורא ל-agent אחר צריך לאמת את החתימה הזו לפני שהוא סומך על היכולות המוצהרות - לא להסתמך רק על התיאור החופשי שה-agent הזר מספק על עצמו. בלי שרשרת אמון כזו, discovery דינמי הופך למשטח תקיפה נוח במיוחד, כי הוא מעודד בעצם agents לסמוך זה בזה על סמך תיאור-עצמי בלבד.

Trade-offs: גמישות מול בקרה, ו-Static מול Dynamic

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

טעויות נפוצות בפרודקשן

הטעות הראשונה: להטמיע discovery בלי שרשרת אמון קריפטוגרפית, ולסמוך על agent card לא חתום - חשיפה ישירה ל-spoofing. הטעות השנייה: לאפשר discovery פתוח לחלוטין בלי גבולות מדיניות, מה שיוצר מרחב אינסופי של שרשראות קריאה אפשריות שאי אפשר לבדוק או לחזות מראש. הטעות השלישית: להתייחס ל-agent card כתיעוד סטטי שנכתב פעם אחת, בלי לוודא שהוא מתעדכן אוטומטית כשהיכולות בפועל של ה-agent משתנות - בדיוק אותה בעיה שתוארה במאמר על ה-capability manifest ב-Agent Registry.

גרסאות ב-Discovery: מה קורה כשיש כמה גרסאות פעילות של אותו Agent

בעולם ריאלי, לעיתים קרובות רצות בו-זמנית כמה גרסאות של אותו agent - גרסה יציבה שמשרתת את רוב התעבורה, וגרסה חדשה שנמצאת ב-canary rollout (ראו המאמר על Agent Lifecycle Management). מנגנון discovery צריך לדעת להבדיל בין השתיים, ולא סתם להחזיר "agent X קיים" בלי לציין איזו גרסה. ברירת מחדל בטוחה היא ש-discovery מחזיר את הגרסה היציבה, אלא אם הקורא מבקש במפורש להשתתף בבדיקת canary - כך שגרסה ניסיונית לא "נדלפת" בטעות לתעבורת ייצור רגילה רק כי היא נמצאה ראשונה בתהליך החיפוש. ארגונים שמתעלמים מההבחנה הזו מגלים תקלות קשות לניתוח, כי אותה קריאה בדיוק ל-agent "אותו שם" יכולה להתנהג אחרת בהתאם לאיזו גרסה נבחרה ברגע הספציפי הזה, בלי שום דבר גלוי שמסביר את חוסר העקביות.

Health Checks: agent שהתגלה לא בהכרח agent שזמין

discovery מוצלח - agent שנמצא ברישום עם היכולת המתאימה - הוא לא ערובה לכך שהוא באמת יגיב. agents, כמו כל שירות, יכולים להיות עמוסים, לא זמינים זמנית, או פשוט איטיים מדי עבור ה-SLA של הקורא. פרוטוקול discovery בשל משלב health check קליל לפני קריאה בפועל - בדיקה מהירה שה-agent המועמד אכן חי ומגיב בזמן סביר, ולא רק שהוא רשום כתיאורטית קיים. בהיעדר health check, מערכת ה-discovery עלולה להפנות שוב ושוב לאותו agent "תיאורטי" שכבר לא זמין, מה שיוצר עיכובים או כשלים שאין להם הסבר ברור אלא אם בודקים את הזמינות בפועל ברגע הקריאה, לא רק את הרישום הסטטי.

Capability Negotiation: מה קורה כשגילוי לא מספיק

גילוי היכולת של agent אחר הוא רק השלב הראשון - השלב השני, שקל להזניח, הוא ניהול משא ומתן (negotiation) על אופן השימוש בפועל. שני agents יכולים לתמוך שניהם ב"עיבוד חשבוניות", אבל אחד מצפה לקלט בפורמט JSON מובנה והשני מצפה לטקסט חופשי; אחד תומך בקריאה סינכרונית והשני רק ב-webhook אסינכרוני. פרוטוקול discovery בשל לא רק מחזיר "כן, אני יכול" - הוא כולל שלב תיאום סכימה, שבו שני ה-agents (או ה-orchestrator שביניהם) מסכימים על הפורמט המדויק של הבקשה והתשובה לפני שהקריאה בפועל מתבצעת. בלי שלב הזה, כשל בגילוי לא מתבטא בשגיאת "agent לא נמצא" הברורה, אלא בכשל עמום הרבה יותר - agent שמקבל תשובה שהוא לא יודע לפרש, ומגיב אליה בטעות כאילו היא תקינה.

Discovery ותאימות רגולטורית: תיעוד בחירה, לא רק ביצוע

ברגע שיש דרישת תאימות (כמו EU AI Act עבור מערכות בסיכון גבוה), לא מספיק שה-discovery יעבוד נכון - צריך גם להיות מסוגלים להוכיח למה agent מסוים נבחר עבור משימה נתונה, במיוחד כשהיו כמה מועמדים אפשריים. מנגנון discovery בשל שומר לוג מנומק (reasoning log) של כל בחירה: אילו agents עמדו בקריטריון היכולת, איזה מהם נבחר בפועל ולפי איזה שיקול (עלות, זמינות, trust tier), ומה הייתה התוצאה. תיעוד כזה, שנראה כמו overhead מיותר ביום-יום, הופך קריטי ברגע שצריך להסביר למבקר חיצוני או לצוות משפטי מדוע החלטה אוטומטית מסוימת התקבלה - שאלה שבלי לוג מפורש, פשוט אין לה תשובה בדיעבד.

Cost-Aware Discovery: כשלא כל agent שווה לבחור בו

כשיש כמה agents שיכולים תיאורטית לספק אותה יכולת, שיקול שלרוב מוזנח בתכנון ראשוני הוא עלות: agent אחד עשוי לקרוא למודל יקר וגדול לכל בקשה, בעוד agent חלופי מספק אותה תוצאה עם מודל קטן וזול משמעותית. Agent Card בשל, כפי שהודגם בסכימה למעלה, חושף גם הערכת עלות (cost_per_call_estimate), כדי שה-orchestrator שבוחר בין כמה agents מתאימים יוכל לשקלל לא רק יכולת אלא גם עלות ותקציב זמין. בהיעדר שדה כזה, מערכות multi-agent נוטות להתכנס אל agent "בררן" שרץ עם המודל היקר ביותר, פשוט כי הוא נמצא ראשון בתהליך הגילוי, מה שמייצר עלות תפעולית שגדלה בלי בקרה תקציבית מודעת.

מתי כן ומתי לא

מערכת עם שני-שלושה agents שידועים מראש ולא צפויים להתרבות לא צריכה מנגנון discovery מלא - חיבור ישיר פשוט ומספיק. ברגע שיש יותר מכמה agents, כשצפויה תוספת agents חדשים באופן שוטף, או כשיש architecture מבוזרת עם orchestrator שצריך לבחור dynamically את ה-agent המתאים למשימה, discovery מובנה הופך הכרחי - האלטרנטיבה היא מטריצת חיבורים hardcoded שהופכת בלתי ניתנת לתחזוקה תוך חודשים.

איך אנחנו ניגשים לזה

במדיה דיל אנחנו בונים discovery מבוסס registry עם שרשרת אמון חתומה כברירת מחדל בכל מערכת multi-agent, ומגבילים את מרחב הקריאות האפשריות למדיניות מוגדרת מראש - כדי שגמישות הגילוי הדינמי לא תבוא על חשבון יכולת לחזות ולבקר את התנהגות המערכת. אנחנו גם בונים תמיד שלב תיאום סכימה מפורש בין agents, ולא מסתמכים על הנחה שכל agent "יבין" את הפורמט של האחר.

סיכום

Agent Discovery פותר את בעיית קנה המידה של חיבורי multi-agent hardcoded, אבל פותח משטח תקיפה חדש - התחזות דרך discovery spoofing - שדורש שרשרת אמון קריפטוגרפית מפורשת. הארכיטקטורה הנכונה משלבת גילוי דינמי מבוסס Agent Cards עם גבולות מדיניות סטטיים, שלב תיאום סכימה מפורש, ומודעות לעלות - ולא מסתמכת על אמון עיוור בתיאור עצמי של agent זר.

תגיות: Agent Discovery · A2A protocol · Agent Cards · service discovery · trust chain · multi-agent systems · spoofing

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