דלג לתוכן הראשי
מדריכים A2A Protocol
מעודכן ליולי 2026 15 דקות קריאה מתקדם

A2A — הפרוטוקול
שמחבר סוכן לסוכן

MCP חיבר סוכני AI לכלים ולנתונים. A2A (Agent-to-Agent) עושה את הצעד הבא: הוא מאפשר לסוכנים לדבר זה עם זה — להאציל משימות, לתאם ולעבוד כצוות, גם כשהם נבנו על ידי חברות שונות. במדריך: ההבדל מ-MCP, Agent Cards, שכבת הפרוטוקולים המלאה של 2026, ומי כבר מאמץ אותה.

v1.0
יציב, מרץ 2026
150+
ארגונים תומכים
Linux
Foundation
JSON-RPC
מעל HTTP

מה זה A2A

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

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

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

בשורה אחת

MCP נותן לסוכן גישה לכלים. A2A נותן לסוכן גישה לסוכן אחר — כזה שמחליט בעצמו, ולא רק מבצע.

כנראה עוד לא צריך את זה — וכדאי לדעת למה

זה הסעיף שחסר כמעט מכל מה שנכתב על הנושא, והוא החשוב ביותר למי שקורא היום. הרוב המכריע של מי שבונה עם AI לא זקוק ל-A2A, ולא ייזקק לו בשנה הקרובה.

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

שלושה סימנים שאתם באמת במצב שבו זה רלוונטי:

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

A2A מול MCP — לא מתחרים

הבלבול הזה חוזר, וההבחנה ביניהם חדה: MCP מחבר סוכן לכלים; A2A מחבר סוכן לסוכן.

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

ההבדל הזה אינו סמנטי, כי הוא משנה את מה שצריך בפרוטוקול:

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

איך זה עובד

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

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

איך נראית משימה בפועל

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

# 1. שליחת משימה. חוזר מזהה, לא תוצאה.
task = a2a.send(
    to="https://partner.example.com/agents/returns",
    message="לקוח מבקש החזר על הזמנה 88213",
    on_behalf_of=user.id,        # בשם מי — לא בשם הסוכן
    scope=["returns:read", "returns:create"],   # מה מותר, לא הכול
    trace_id=trace_id,           # אותו מזהה בכל השרשרת
)

# 2. מעקב. משימה יכולה לרוץ דקות.
while task.state in ("submitted", "working"):
    if elapsed() > TASK_TIMEOUT:          # תקרת זמן, חובה
        a2a.cancel(task.id)
        return {"ok": False, "reason": "timeout"}

    task = a2a.get(task.id)

    # 3. המצב שמייחד סוכן מכלי:
    if task.state == "input-required":
        return ask_human(task.question)   # לא להמציא תשובה

# 4. תוצאה — וכל מה שחזר הוא קלט לא מהימן
log(trace_id, task.id, task.result)
return validate(task.result)

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

Agent Card — מה הסוכן מצהיר על עצמו

כדי שסוכן אחד ימצא אחר ויידע איך לפנות אליו, צריך תיאור מוסכם. זה ה-Agent Card: מסמך שהסוכן מפרסם ובו מה הוא יודע לעשות, איך פונים אליו, ואיך מזדהים מולו.

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

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

מה עובר בין הסוכנים, ומה לא צריך לעבור

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

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

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

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

החלק הקשה: מי אישר, ומי אחראי

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

שלוש שאלות שאין להן תשובה טכנית בפרוטוקול, וצריך לענות עליהן במערכת שלכם:

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

גילוי: איך סוכן מוצא סוכן

שאלה שנשמעת פשוטה ומסתירה החלטה ארכיטקטונית. יש שלוש גישות, ולכל אחת מחיר:

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

מה נשבר כששני סוכנים מדברים

מערכת שבה סוכן קורא לסוכן מכפילה לא את המורכבות אלא את מספר הדרכים להיכשל — ובשקט.

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

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

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

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

מצב הבשלות, בכנות

שווה לכייל ציפיות, כי הפער בין הכרזות למציאות בקטגוריה הזו גדול במיוחד.

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

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

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

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

המקרה המעשי: בתוך ארגון אחד

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

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

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

ובעסק קטן? כמעט תמיד לא. אם אותו אדם אחראי על שני הסוכנים, הפרוטוקול מוסיף שכבה ולא פותר בעיה.

איך בודקים מערכת כזו

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

מה שעובד בפועל:

מה משתנה בעברית

הדפוס שכדאי לאמץ גם בלי הפרוטוקול

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

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

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

כלומר גם מי שמסיק מהדף הזה "עוד לא צריך" — יכול לקחת ממנו את החלק שכן שווה היום.

אז מתי כן

לסיכום, בלי סייגים:

שלוש שאלות שכדאי לשאול לפני שמחברים

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

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

טעויות שחוזרות