בקצרה
MCP מחבר יישומי AI לכלים ולהקשר. Agent Client Protocol מחבר סביבת עבודה לסוכן קוד. A2A מסדיר עבודה בין מערכות סוכנים. ACP במובן Agent Communication Protocol היה פרויקט נפרד שהתמזג עם A2A.
סוכן שעובד בתוך עורך קוד, קורא מידע ממערכת ארגונית ומוסר משימה לסוכן אחר עשוי להשתמש בשלושה סוגי תקשורת שונים. מבחינת המשתמש הכול נראה כמו ״ה־AI עובד״. מבחינת המערכת, אלה גבולות אחרים לגמרי.
הבלבול מתחיל כשמציגים כל פרוטוקול חדש כתחליף לכל הקודמים. MCP, ACP ו־A2A עוסקים בשאלות שונות: איך יישום מקבל כלים ומידע, איך ממשק עבודה מתקשר עם סוכן, ואיך מערכות סוכנים מחליפות עבודה.
הדרך להבין את המפה היא לשאול מי נמצא בכל צד של החיבור. רק אחר כך כדאי לבדוק הודעות, גרסאות ויכולות.
קודם מסדרים את השם ACP
הקיצור ACP שימש שני פרויקטים שונים, וההבדל אינו סמנטי.
Agent Client Protocol מסדיר תקשורת בין עורכי קוד או סביבות פיתוח לבין סוכני קוד. זהו ה־ACP שבו עוסק עיקר ההשוואה כאן.
Agent Communication Protocol, שקודם במסגרת IBM ו־BeeAI, עסק בתקשורת בין סוכנים. באוגוסט 2025 הודיעה LF AI & Data שהוא מתמזג עם A2A; ההודעה תיארה מעבר של הצוות והטכנולוגיה אל המאמץ המשותף.
לכן כשמוצר מצהיר ״תמיכה ב־ACP״, צריך לבדוק את השם המלא ואת המפרט. אי אפשר להסיק מהקיצור לבדו שמדובר בתקשורת בין סוכנים, או שהמוצר תומך באותו חיבור כמו מוצר אחר.
MCP: החיבור בין יישום AI לכלים ולמידע
Model Context Protocol בנוי סביב Host, Client ו־Server. ה־Host הוא יישום ה־AI שמנהל את החוויה והחיבורים. ה־Client מחזיק את הקשר מול שרת מסוים. ה־Server חושף יכולות והקשר.
בתיעוד הרשמי מופיעים שלושה רכיבים מרכזיים ששרת יכול להציע: Tools, פעולות שניתן להפעיל; Resources, מקורות מידע; ו־Prompts, תבניות לשימוש בשיחה או במשימה.
מכאן נובעת הבחנה חשובה: שרת MCP אינו חייב להיות מודל או סוכן. הוא יכול להיות תוכנה שמחברת למאגר מסמכים או למערכת עסקית. המילה Server מתארת תפקיד בפרוטוקול, לא בהכרח מחשב מרוחק.
MCP אינו מכתיב איזה מודל לבחור או כיצד היישום צריך לחשוב. הוא מסדיר חלק מהאופן שבו היכולות והמידע נחשפים ונצרכים.
בשכבת השירות מעל SaaS החיבור הזה מאפשר להפעיל יכולת עסקית בלי לבנות חיבור ייחודי לכל ממשק AI. אבל ההגדרה העסקית של הפעולה עדיין נשארת באחריות המערכת.
ACP: החיבור בין סביבת העבודה לסוכן הקוד
Agent Client Protocol מנסה לצמצם את התלות ההדדית בין עורך קוד לסוכן מסוים. במקום שכל עורך יבנה שילוב נפרד לכל סוכן, שני הצדדים יכולים לממש ממשק משותף.
החיבור הזה צריך לשרת חוויית עבודה: התחלת משימה, הצגת התקדמות, תקשורת עם המשתמש והצגת שינויים בקוד. לכן הוא אינו רק רשימה של כלים.
לפי התיעוד שנבדק, תרחיש מקומי יכול להשתמש בתהליך משנה וב־JSON-RPC על גבי קלט ופלט סטנדרטיים. התיעוד מתאר גם תרחישים מרוחקים, אך מציין שהתמיכה המלאה בהם עדיין בתהליך עבודה. אין להניח שכל שילוב מקומי נתמך באותה רמה גם מרחוק.
הדמיון ל־LSP מועיל: כמו שפרוטוקול משותף הקל על חיבור שירותי שפה לעורכים, ACP מבקש להפריד בין סביבת העבודה לבין סוכן הקוד. עם זאת, עבודה של סוכן כוללת פעולות והרשאות שאינן זהות להשלמת קוד רגילה.
הדיון על OpenHands בשרת פרטי מדגים מדוע כדאי להפריד בין ממשק המשתמש, סוכן העבודה וסביבת הביצוע.
A2A: למסור עבודה למערכת סוכנים אחרת
Agent2Agent עוסק בתקשורת בין לקוח לבין סוכן או מערכת סוכנים מרוחקת. הצד המקבל יכול להישאר קופסה שחורה: אין צורך לחשוף ללקוח את כל הכלים, הזיכרון או המבנה הפנימי שלו.
בתיעוד A2A, Agent Card מתאר זהות, יכולות, נקודת חיבור ודרישות אימות. Task מייצג יחידת עבודה עם מזהה ומחזור חיים. Artifact הוא תוצר מוחשי שהעבודה מחזירה, כמו מסמך או נתונים מובנים.
ההפרדה בין הודעה לתוצר חשובה. ״אני עובד על זה״ היא הודעת מצב. קובץ שנוצר הוא תוצר. ״המשימה הסתיימה״ הוא מצב שעדיין צריך לבדוק מול תנאי הקבלה של מי שהזמין אותה.
A2A תומך בדפוסי תקשורת שמתאימים גם לעבודה ממושכת, כמו עדכוני מצב וזרימה של תוצאות. בחירת הדפוס תלויה בתמיכה של המימוש ובצרכי המערכת.
ההשוואה הקצרה
| פרוטוקול | החיבור המרכזי | מה הוא מסדיר |
|---|---|---|
| MCP | יישום AI מול שרת כלים והקשר | גילוי ושימוש ביכולות, מידע ותבניות |
| ACP, במובן Agent Client Protocol | סביבת עבודה מול סוכן קוד | חוויית משימה ותקשורת בין עורך לסוכן |
| A2A | לקוח או סוכן מול מערכת סוכנים | מסירת עבודה, מצב ותוצרים |
הטבלה מתארת את מרכז הכובד, לא חומה קשיחה. אפשר לחשוף מערכת מורכבת מאחורי כלי, ואפשר לבנות מתאמים בין שכבות. אבל מתאם אינו מבטל הבדל באחריות או במשמעות של הפעולה.
בחירה נכונה נשענת על הצורך. אם צריך לקרוא קטלוג, אין הכרח למסור משימה לסוכן אחר. אם צריך להפעיל מומחה מרוחק שמנהל עבודה ארוכה, קריאת כלי פשוטה עלולה לא לתאר היטב את מחזור החיים.
שלושתם יכולים לפעול באותה מערכת
נניח שמפתח מבקש שינוי תוכנה מתוך עורך הקוד. העורך מתקשר עם סוכן באמצעות ACP. הסוכן משתמש בשרת MCP כדי לקרוא תיעוד מורשה. חלק מוגדר של הבדיקה נמסר למערכת מומחית דרך A2A.
זהו תרחיש ארכיטקטוני אפשרי, לא טענה שכל מוצר מממש את כל המסלול. היתרון בהפרדה הוא שכל חיבור מקבל תפקיד ברור.
כעת אפשר לשאול שאלות מדויקות: מי שומר את מצב המשימה? מי מבקש אישור? מי מחזיר את התוצר? האם ביטול בעורך מבטל גם עבודה שהועברה למערכת אחרת?
השאלות האחרונות חושפות למה ״יש תקן״ אינו סוף התכנון. צריך להסכים גם על זמן, כשל, ביטול והשלמה.
גילוי יכולת אינו הוכחת אמינות
Agent Card או תיאור כלי עוזרים להבין מה מערכת מצהירה שהיא יודעת לעשות. הם אינם הוכחה שהיא תעשה זאת נכון בכל מצב.
תיאור של ״בדיקת מסמך״ יכול להתכוון לסריקה תחבירית, להשוואה למקור או לביקורת מקצועית. בלי תנאי קבלה, שני צדדים יכולים לדבר בפרוטוקול תואם ולהתכוון לעבודות שונות.
לכן צריך חוזה משימה מעל החיבור: קלט צפוי, תוצר נדרש, גבולות פעולה וראיות. המאמר על ניהול סוכנים עוסק בשכבה הזאת, שבה תאימות טכנית הופכת לעבודה שאפשר לקבל.
אותו דבר נכון לפרוטוקולי כלים. כלי שחוזר עם HTTP תקין לא בהכרח השלים את התוצאה העסקית. צריך להבין את מבנה התשובה ואת משמעות המצב שהיא מדווחת.
הרשאות אינן עוברות אוטומטית יחד עם ההודעה
כאשר מערכת אחת פונה לאחרת, לא בהכרח מותר לה להעביר הלאה את כל הסמכות של המשתמש. צריך להגדיר איזה מידע נמסר, איזו זהות פועלת ומה היקף ההרשאה.
בפרט, תוכן שהוחזר מכלי או מסוכן אחר אינו צריך לקבל מעמד של הוראות מערכת. יש לשמר את ההבחנה בין נתונים לבין סמכות גם כאשר שני הצדדים משתמשים בתקן מוכר.
אבטחת סוכני AI עוסקת באכיפה הזאת. Prompt Injection מסביר מדוע מקור חיצוני אינו הופך לבעל הרשאה רק משום שהגיע דרך חיבור תקין.
התקן עוזר לבנות תקשורת עקבית. הוא אינו מחליף את מדיניות הארגון ואת הבדיקות בשירות שמבצע פעולה.
גרסה ותמיכה חשובות יותר מסמל על דף המוצר
פרוטוקולים מתפתחים. תמיכה בשם הכללי אינה מוכיחה תמיכה בכל גרסה, מנגנון תעבורה או יכולת אופציונלית.
לפני שילוב בודקים באילו גרסאות שני הצדדים תומכים, כיצד הם מגלים יכולות ומה קורה כשיכולת חסרה. חשוב לבדוק גם הודעות ארוכות, ניתוק, ביטול ושגיאות, ולא רק הדגמת ״שלום עולם״.
תאימות צריכה להיבדק מול התצורה שבה עובדים בפועל. שרת מקומי דרך תהליך אינו זהה לשירות מרוחק עם זהויות, זמני המתנה ומגבלות רשת.
אם המימוש דורש הרחבה ייחודית, כדאי לתעד אותה. אחרת אפשר לבנות תלות בספק גם בתוך מערכת שממותגת כפתוחה.
השורה התחתונה
MCP, ACP ו־A2A הם חלק מהמעבר מסוכנים מבודדים למערכות שאפשר לחבר. הם אינם שלושה שמות לאותו דבר, וגם אינם תחליף לתכנון.
MCP מסייע לחבר יכולות והקשר. ACP מחבר סביבת עבודה לסוכן קוד. A2A מסייע למסור עבודה בין מערכות סוכנים. מעל כולם נשארות שאלות של סמכות, מצב ותוצאה.
הערך האמיתי של תקן אינו רק פחות קוד חיבור. הוא היכולת להחליף רכיב בלי לאבד את המשמעות של העבודה.
שאלות נפוצות
האם MCP מחליף API?
לא בהכרח. שרת MCP יכול לעטוף API קיים ולהציג את יכולותיו ליישום AI. המערכת העסקית והממשק שלה עדיין קיימים.
האם ACP הוא פרוטוקול לתקשורת בין סוכנים?
צריך לבדוק את השם המלא. Agent Client Protocol מיועד לחיבור לקוח וסוכן קוד; Agent Communication Protocol היה פרויקט אחר שהתמזג עם A2A.
האם חייבים את שלושת הפרוטוקולים?
לא. משתמשים בחיבור שנדרש לארכיטקטורה. מערכת פשוטה יכולה להסתפק ב־API או בפרוטוקול אחד.
האם תאימות מבטיחה שאפשר להחליף ספק ללא עבודה?
לא. צריך לבדוק גרסאות, יכולות, הרחבות, הרשאות והתנהגות. התקן מצמצם חלק מעבודת החיבור, לא כל הבדל בין מוצרים.