Capability Negotiation — כיצד שני סוכנים מסכימים על כלים, הרשאות ופורמט עבודה
מאת צוות מדיה דיל · 12.08.2026 · Agent Protocols · 5 דק׳
מדריך טכני למנגנון משא ומתן על יכולות בין סוכני AI: איך שני צדדים שלא בנו את המערכת של זה מסכימים בזמן ריצה על מה שכל אחד יודע ומורשה לעשות.
סוכן תזמון פגישות של חברה אחת ניסה לתאם עם סוכן היומן של חברה שותפה, וגילה שהוא תומך בפורמט תאריכים ISO 8601 בעוד הצד השני מצפה לפורמט RFC 2822 ישן יותר. שני הצדדים "מדברים" A2A תקני, אבל בלי הסכמה מפורשת על פורמט הנתונים בפועל, כל קריאה נכשלת בשקט — לא שגיאת פרוטוקול, אלא כישלון סמנטי שקשה לאבחן. Capability Negotiation הוא השלב שקורה אחרי גילוי (מציאת AgentCard) ולפני ביצוע בפועל: תהליך שבו שני סוכנים מסכימים במפורש על אילו כלים, פורמטים והרשאות בדיוק יחולו על האינטראקציה הספציפית ביניהם, כדי שאף אחד מהצדדים לא "ינחש" ויגלה את הפער רק אחרי כישלון.
למה גילוי לבדו לא מספיק
AgentCard, כפי שמתואר במדריך בניית Agent Card, פותר את שאלת "מה הסוכן יודע לעשות באופן כללי". אבל בפועל, כל אינטראקציה ספציפית דורשת הסכמה עדינה יותר: אילו גרסאות של אותו skill נתמכות, איזה subset של פרמטרים אופציונליים בפועל ייתמך במימוש הזה, ואיזו רמת פירוט בתשובה מצופה. שני סוכנים יכולים לתמוך שניהם ב-skill בשם schedule-meeting, אבל אחד מצפה ל-timezone מפורש בכל בקשה והשני מניח UTC כברירת מחדל — פער כזה לא מופיע בגילוי הראשוני, רק בביצוע בפועל, ואז כבר מאוחר מדי.
Capability Negotiation סוגר את הפער הזה על ידי הוספת שלב ביניים מפורש: לפני שהצד היוזם שולח את הבקשה המלאה, הוא שולח capability-check קטן שמתאר בדיוק את הפרמטרים שהוא מתכנן לשלוח, והצד הנענה מאשר או מתקן. זה דומה מאוד לשלב ה-handshake ב-TLS, רק ברמה סמנטית ולא קריפטוגרפית.
מבנה המשא ומתן בפועל
חשוב להדגיש שהמשא ומתן הזה קורה ברמת מכונה למכונה, בלי מעורבות אנושית, ולכן הוא חייב להיות דטרמיניסטי וקצר — לא סבב שיחה חופשי בין שני מודלים שמנסים "להבין אחד את השני" בכל פעם מחדש. ככל שהמבנה נוקשה וברור יותר, כך פחות סיכוי לפרשנות שגויה שגורמת לכישלון שקט באמצע תהליך עסקי.
תהליך טיפוסי כולל שלוש בקשות: discover (מה יש), propose (הצד היוזם מציע תצורת עבודה ספציפית — פורמט, גרסה, פרמטרים), ו-ack/reject (הצד הנענה מאשר, מתקן, או דוחה). כשהתשובה היא תיקון, היא כוללת בדרך כלל diff מפורש — לא רק "לא מתאים" אלא "אני תומך בגרסה 2 של הפורמט הזה, לא בגרסה 3 שהצעת". זה מאפשר לצד היוזם להתאים את עצמו בלי סבב תקשורת נוסף מלא, ולפעמים אפילו לבחור פרוטוקול fallback אם ההתאמה לא אפשרית בכלל.
discover— שליפת AgentCard וזיהוי skills רלוונטייםpropose— הצעת תצורה קונקרטית: גרסה, פורמט, פרמטרים נדרשיםack— אישור מלא, אפשר להתחיל לעבודnegotiate— הצעה נגדית עם התאמות ספציפיות
המנגנון הזה נשען ישירות על מבני ה-Task וה-Message שכבר קיימים ב-A2A, כפי שמפורט במדריך A2A 1.0 — Capability Negotiation לא פרוטוקול נפרד, אלא דפוס שימוש שנבנה מעל היסודות הקיימים.
הרשאות: לא רק יכולת טכנית אלא רשות שימוש
ההפרדה הזו נהיית קריטית ככל שמספר השותפים החיצוניים גדל. בעוד תאימות טכנית היא שאלה סטטית יחסית — או שהפורמטים תואמים או שלא — שאלת ההרשאה דינמית ותלוית הקשר: אותו סוכן שותף עשוי לקבל הרשאה רחבה יותר בשעות עבודה רגילות ומצומצמת יותר בסוף שבוע, או הרשאה שמשתנה לפי רמת התיוג של הנתונים המבוקשים. תכנון נכון מפריד בבירור בין שתי הבדיקות בקוד, כדי שכל שינוי במדיניות ההרשאות לא ידרוש נגיעה בלוגיקת תאימות הפורמטים, ולהפך.
מעבר לתאימות טכנית, המשא ומתן צריך לכסות גם הרשאה: סוכן יכול לתמוך טכנית ב-skill מסוים, אבל לא להיות מוכן לחשוף אותו לצד הספציפי הזה ללא רמת אמון מתאימה. כאן Capability Negotiation נפגש עם שכבת האמון שמתוארת במדריך Trust Handshake בין סוכנים: לעיתים קרובות שני התהליכים רצים במקביל — קודם קובעים כמה סומכים, ובמקביל מסכימים על הפורמט הטכני, ורק כששניהם עוברים, מתחילה העבודה בפועל. הפרדה בין השאלות "האם מותר" ו"האם תואם טכנית" מונעת מצב מבלבל שבו סירוב מטעמי הרשאה מתפרש בטעות כאי-תאימות פורמט.
מימושים בשלים גם שומרים cache של תוצאות המשא ומתן לפי זוג סוכנים, כדי לא לחזור על אותו תהליך בכל קריאה. cache כזה חייב להיות מוגבל בזמן ולהתאפס אוטומטית כשאחד הצדדים מפרסם גרסה חדשה של ה-AgentCard שלו, אחרת סוכנים ימשיכו לפעול לפי הסכמה שכבר לא תקפה.
מה קורה כשאין הסכמה
לא כל משא ומתן מסתיים בהצלחה, ומערכת בשלה צריכה טיפול מפורש בכישלון. כשאין חפיפה בין הפורמטים או הגרסאות הנתמכות, הצד היוזם צריך לקבל שגיאה ברורה שמסבירה בדיוק מה חסר — לא רק "capability mismatch" גנרי, אלא "נדרשת גרסה 3 ומעלה של skill X, הצד השני תומך רק בגרסה 2". השגיאה המפורטת הזו מאפשרת פתרון אוטומטי: מערכת אורקסטרציה יכולה לחפש סוכן חלופי שתומך בגרסה הנדרשת, או לדווח לצוות הפיתוח על הפער כדי לתקן אותו בגרסה הבאה. בלי הפירוט הזה, כל כישלון משא ומתן הופך לחקירה ידנית שגוזלת זמן יקר.
Negotiation כתהליך חוזר, לא חד-פעמי
כדי לתת מושג לגודל הבעיה: ארגון עם עשרות חיבורי A2A חיצוניים, שכל אחד מהם משדרג את ה-AgentCard שלו בממוצע פעם בחודשיים, צריך תשתית שמזהה ומטפלת בעשרות שינויים כאלה בשנה, בלי שאף אחד מהם יגרום לתקלה בפרודקשן. זו בדיוק הסיבה שרוב הארגונים הבשלים מנהלים לא רק את הפרוטוקול עצמו אלא גם תהליך ביקורת תקופתי, שבו בודקים באופן יזום שכל חיבור חיצוני עדיין תקף, במקום לחכות לגילוי תקלה בזמן אמת.
טעות נפוצה היא לחשוב על Capability Negotiation כשלב חד-פעמי שקורה פעם אחת ונשמר לתמיד. בפועל, יכולות משתנות: סוכן משדרג גרסת skill, מוסיף פרמטר חדש, או משנה פורמט תשובה. מערכת ייצור בשלה מריצה משא ומתן מחדש בתדירות מוגדרת, או מיד כשהיא מזהה שינוי בגרסת ה-AgentCard של הצד השני. הדרך הנפוצה לזהות שינוי היא לעקוב אחרי hash של ה-AgentCard כולו — ברגע שה-hash משתנה, המערכת יודעת שיש לרענן את הסכמת היכולות במקום להמשיך לפעול לפי הנחות שכבר לא תקפות. גישה זו מונעת את הכישלון הכי מתסכל בסוג הזה של מערכות: קריאה שעבדה מצוין שבוע שלם, ואז נשברת בשקט בגלל עדכון בצד השני שאף אחד לא ידע עליו.
המסקנה המעשית היא לתכנן את שכבת ה-negotiation כרכיב חי במערכת, לא כשלב אתחול. ארגונים שמנהלים חיבורים רבים לסוכנים חיצוניים מרוויחים מבניית dashboard שמראה את מצב ההסכמה הנוכחי מול כל שותף, ומתריע כשמשא ומתן נכשל או כשגרסה חדשה דורשת בדיקה מחדש לפני שהיא משפיעה על תעבורה חיה.
תגיות: Capability Negotiation · A2A · protocol handshake · agent interoperability · versioning · trust handshake