A2A 1.0 — איך סוכני AI מתקשרים ביניהם ללא תלות בשפה או במודל

מאת צוות מדיה דיל · 12.08.2026 · Agent Protocols · 5 דק׳

צלילה טכנית לפרוטוקול Agent2Agent 1.0: AgentCard, Task lifecycle, streaming ו-push notifications, ולמה זה שונה מבקשת API רגילה.

חברת לוגיסטיקה שבנתה סוכן תזמון משלוחים משלה נתקלה בקיר כשניסתה לחבר אותו לסוכן התמחור של ספק חיצוני: לספק היה מודל שונה, שפת תכנות שונה (הסוכן שלהם נכתב ב-Go, שלה ב-Python), ובעיקר — אין שום הבטחה שהוא יבין את אותו פורמט בקשה שהיא רגילה לשלוח פנימית. הפתרון המסורתי היה REST API מותאם אישית מול כל ספק, מה שאומר תחזוקה נצחית של אינטגרציות שבירות שנשברות בכל שינוי גרסה. A2A, פרוטוקול ה-Agent2Agent שגוגל פרסמה ושעבר בתחילת 2026 תחת חסות Linux Foundation כגרסה 1.0 יציבה, נועד בדיוק לבעיה הזו: לאפשר לשני סוכנים עצמאיים לגלות אחד את השני, לתאם משימה ולהחליף תוצאות בלי שאף אחד מהם צריך לדעת מה קורה "בפנים" אצל הצד השני.

AgentCard — כרטיס ביקור מכונה-קריא

כל סוכן ש"מדבר" A2A חושף מסמך JSON בכתובת קבועה (בדרך כלל /.well-known/agent.json) שנקרא AgentCard. המסמך מתאר את שם הסוכן, את היכולות שלו (skills), את פורמטי הקלט והפלט הנתמכים, מנגנוני האימות הנדרשים, ו-endpoint לתקשורת. סוכן קורא שרוצה להשתמש בסוכן אחר לא צריך תיעוד ידני או שיחת אינטגרציה — הוא שולף את ה-AgentCard, בודק אם היכולת שהוא מחפש קיימת ברשימת ה-skills, ובודק אם סכימת ה-input שהוא מתכנן לשלוח תואמת למה שהצד השני מצפה לו. זה בדיוק המנגנון שהופך גילוי סוכנים מתהליך אנושי איטי לתהליך אוטומטי מהיר — הרחבה על העיקרון נמצאת במדריך בניית Agent Card ובמדריך גילוי סוכנים.

חשוב להבין ש-AgentCard הוא לא רק "תיעוד API" — הוא חוזה גילוי דינמי. סוכן יכול לפרסם כמה AgentCards לפי הרשאת הקורא (גרסה ציבורית מצומצמת מול גרסה מורחבת לשותפים מאומתים), וברוב המימושים הוא כולל גם מדיניות אימות מפורשת: OAuth2, API key, או mTLS, כדי שהצד הקורא ידע בדיוק איך להזדהות עוד לפני שליחת הבקשה הראשונה שלו.

מחזור החיים של Task

הליבה של A2A היא אובייקט ה-Task. סוכן קורא פותח Task חדש עם Message ראשוני שמתאר את המשימה, וה-Task עובר בין מצבים מוגדרים: submitted, working, input-required (כשהסוכן המבצע צריך עוד מידע מהמשתמש או מהסוכן הקורא), completed, failed ו-canceled. זה שונה מקריאת REST רגילה שמחזירה תשובה אחת ונגמרת — משימות אג'נטיות יכולות לקחת דקות או שעות, ולעבור כמה סבבי דו-שיח באמצע התהליך. כשה-Task נמצא במצב input-required, הסוכן הקורא שולח Message נוסף לאותו Task ID, בלי לפתוח שיחה חדשה — כך נשמר ההקשר המלא לכל אורך העבודה, כולל כל מה שסוכם בשלבים קודמים.

כל Task גם נושא Artifact — התוצר הסופי, שיכול להיות טקסט, קובץ, או מבנה JSON מובנה. הפרדה בין ה-Message (תקשורת תהליכית) לבין ה-Artifact (תוצר סופי) מאפשרת לצד הקורא להבחין בבירור בין "עדכון סטטוס" לבין "הנה התוצאה שביקשת", מה שמפשט מאוד את הלוגיקה בצד הצרכן ומקטין את הסיכוי לפרש עדכון ביניים כתשובה סופית בטעות.

Streaming ו-Push Notifications

למשימות ארוכות, A2A תומך בשני מנגנוני עדכון: streaming באמצעות Server-Sent Events, כשהסוכן הקורא נשאר מחובר ומקבל עדכוני סטטוס בזמן אמת, ו-push notifications באמצעות webhook, כשהחיבור לא יכול להישאר פתוח (למשל תהליך שרץ שעות וה-client הקורא הוא עצמו סוכן שרץ בענן וסוגר חיבורים באופן קבוע). הבחירה בין השניים היא החלטת ארכיטקטורה אמיתית: streaming פשוט יותר למימוש אך מחייב חיבור פתוח לאורך כל המשימה, ואילו webhook מחייב את הסוכן הקורא לחשוף endpoint משלו לקבלת עדכונים, אבל שורד ניתוקי רשת וריסטארטים בלי לאבד את התקדמות המשימה.

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

אימות הדדי ואבטחה בפרוטוקול פתוח

מכיוון ש-A2A נועד לתקשורת בין ארגונים שלא סומכים אחד בשני מראש, שכבת האבטחה היא חלק אינטגרלי מהמפרט ולא תוספת מאוחרת. כל בקשת Task נושאת אימות ברמת ה-transport (בדרך כלל OAuth2 client credentials או mTLS), אבל מעבר לזה — סוכנים יכולים לדרוש "trust handshake" נוסף לפני שיתוף פעולה על משימה רגישה, כדי לוודא לא רק מי הצד השני, אלא גם מהי רמת האמון ההדדית הנדרשת למשימה הספציפית הזו. הנושא הזה מורחב לעומק במדריך Trust Handshake בין סוכנים.

ההבדל הגדול בין A2A לבין קריאת API רגילה הוא שהוא לא מניח יחסי לקוח-שרת קבועים — כל סוכן יכול להיות גם קורא וגם נקרא בהתאם להקשר, וזה בדיוק מה שמאפשר רשתות סוכנים דינמיות שמתארגנות מחדש בכל משימה, במקום טופולוגיה קשיחה שמישהו צריך לתחזק ידנית. לצוותים שבונים מערכת multi-agent אמיתית, שילוב נכון של A2A עם MCP ברמת הכלים הוא כיום הדרך הסטנדרטית להשגת גמישות כזו, כפי שמפורט במדריך ארכיטקטורת MCP.

טעויות נפוצות במימוש ראשון

הטעות הראשונה שרוב הצוותים עושים היא לפתוח Task חדש לכל הודעה, במקום להמשיך Task קיים שנמצא במצב input-required. התוצאה היא איבוד הקשר מוחלט בין הודעות שבפועל שייכות לאותו תהליך, מה שגורם לסוכן המבצע "לשכוח" מה כבר סוכם קודם ולבקש את אותו מידע שוב ושוב מהמשתמש. הטעות השנייה היא התעלמות מהבדל בין streaming ל-push: צוותים בונים חיבור SSE למשימות שיכולות לקחת שעות, ואז תוהים למה החיבור נופל אחרי כמה דקות בגלל timeout של load balancer. הפתרון הפשוט הוא לבחור push notifications מראש לכל משימה שצפויה לחרוג מכמה עשרות שניות, ולשמור streaming רק למשימות אינטראקטיביות קצרות.

טעות שלישית, נפוצה במיוחד בארגונים גדולים, היא פרסום AgentCard יחיד וזהה לכל הצדדים, בלי הבחנה בין שותפים מאומתים לגישה ציבורית. זה חושף יכולות רגישות — למשל skill שמאפשר גישה למידע פנימי — לכל מי שמוצא את הכתובת, גם אם בפועל האימות עוצר אותם בשלב הקריאה בפועל. הפרקטיקה הנכונה היא לפרסם AgentCard מצומצם כברירת מחדל, ולחשוף גרסה מורחבת רק לאחר תהליך trust handshake מוצלח, בדיוק כפי שמתואר במדריך משא ומתן על יכולות.

תגיות: A2A · Agent2Agent · AgentCard · Task lifecycle · multi-agent · Linux Foundation

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