איך לבנות Agent Gateway ארגוני עבור MCP ו-A2A
מאת צוות מדיה דיל · 12.08.2026 · Agent Protocols · 5 דק׳
מדריך ארכיטקטוני לבניית Agent Gateway מרכזי שמנהל אימות, ניטור, rate limiting ומדיניות גישה עבור כל תעבורת MCP ו-A2A בארגון — במקום חיבורים נקודתיים.
ארגון עם עשרות סוכנים פנימיים, שלושים שרתי MCP, וחיבורי A2A למספר ספקים חיצוניים, גילה שאין לו שום נקודת שליטה מרכזית: כל צוות חיבר את הסוכנים שלו ישירות לשרתים ולשותפים, בלי מדיניות אחידה, בלי לוג מרכזי, ובלי דרך לדעת בזמן אמת אילו קריאות עוברות במערכת. כשספק חיצוני עדכן גרסת API ושבר תאימות, לקח שלושה ימים לגלות אילו סוכנים פנימיים בכלל השתמשו בו. Agent Gateway הוא הפתרון הארכיטקטוני לבעיה הזו: שכבת ביניים מרכזית שדרכה עוברת כל תעבורת MCP ו-A2A בארגון, בדומה לאופן שבו API Gateway מרכז תעבורת REST — אבל עם דרישות ייחודיות לעולם הסוכנים.
למה אי אפשר פשוט להשתמש ב-API Gateway רגיל
הפיתוי להשתמש בכלי Gateway קיים שהארגון כבר מכיר ומתפעל מובן — פחות תשתית חדשה ללמוד, פחות ספקים לנהל. אבל ניסיון לכופף Gateway שנבנה עבור REST כדי שיתמוך בסמנטיקה של MCP ו-A2A בדרך כלל מסתיים בפשרות כואבות: streaming שנתמך רק חלקית, ניהול session שדורש עוקפנות מכוערת, וחוסר יכולת לפרש את תוכן הבקשה ברמה שמאפשרת אכיפת מדיניות עדינה. ההשקעה בפתרון ייעודי, גם אם היא נראית מיותרת בהתחלה כשיש רק כמה סוכנים, משתלמת במהירות ברגע שהמערכת גדלה.
API Gateway מסורתי בנוי סביב מודל בקשה-תשובה קצרה וידועה מראש. תעבורת סוכנים שונה במהותה: קריאות MCP יכולות לכלול streaming ארוך, ותקשורת A2A כוללת Tasks אסינכרוניים שיכולים להימשך שעות עם מספר סבבי דו-שיח. Gateway רגיל שלא בנוי לזה נתקל בבעיות timeout ובניהול session שגוי. מעבר לזה, המדיניות שצריך לאכוף שונה: לא רק "מי מורשה לקרוא ל-endpoint הזה" אלא "אילו tools בתוך שרת MCP ספציפי מורשה סוכן מסוים לקרוא", ו"איזו רמת אמון נדרשת למשימה הזו מול הסוכן החיצוני הזה". אלה שאלות ברמת סמנטיקה של הפרוטוקול, לא רק ברמת routing.
הפתרון הוא Gateway ייעודי שמבין את שני הפרוטוקולים ברמת הפרוטוקול עצמו — מפענח בקשות tools/call של MCP ומזהה בדיוק לאיזה tool הן מכוונות, ומפענח בקשות Task של A2A ומזהה את מצב ה-lifecycle שלהן. הרחבה על עקרונות דומים ברמת שרת MCP בודד נמצאת במדריך ארכיטקטורת MCP.
שכבות אכיפה: אימות, מדיניות ו-rate limiting
Agent Gateway בשל מיישם כמה שכבות אכיפה ברצף. השכבה הראשונה היא אימות זהות — כל סוכן שמתחבר דרך ה-Gateway מזוהה באופן ודאי, בין אם דרך mTLS פנימי או OAuth2 מול שותפים חיצוניים. השכבה השנייה היא Policy Enforcement — כללים מפורשים שקובעים אילו tools ואילו skills מורשה כל סוכן לקרוא, לרוב מוגדרים כ-policy-as-code שניתן לביקורת ולגרסאות, לא כהגדרות ידניות מפוזרות. השכבה השלישית היא rate limiting ו-quota, שמונעים מסוכן בודד (שאולי נתקע בלולאה, או פשוט עמוס) להציף שרת MCP משותף ולפגוע בכל שאר הצוותים שתלויים בו.
- אימות זהות אחיד לכל סוכן שמתחבר, ללא יוצא מן הכלל
- Policy Enforcement ברמת tool/skill ספציפי, לא רק ברמת שרת
- Rate limiting ו-quota למניעת עומס חוצה-צוותים
- לוג מרכזי לכל קריאה, כולל payload מלא לצורכי ביקורת
מנגנון ה-Policy Enforcement קשור ישירות לניהול registry מרכזי של שרתי MCP וסוכני A2A, שמפורט במדריך רישום MCP ארגוני — ה-Gateway והרישום פועלים יחד: הרישום קובע מה קיים ומה מותר עקרונית, וה-Gateway אוכף את זה בזמן ריצה על כל קריאה בפועל.
נראות: מה קורה כשמשהו נשבר
היתרון המעשי הגדול ביותר של Gateway מרכזי הוא נראות. כשספק חיצוני משנה API ושובר תאימות, Gateway מרכזי מזהה תוך דקות אילו סוכנים פנימיים משתמשים בו, כי כל הקריאות עברו דרכו ונרשמו. בלי Gateway, אותו אבחון דורש בדיקה ידנית של כל צוות בנפרד — בדיוק התרחיש שקרה לארגון שתואר בפתיחה. מעבר לאבחון תקלות, נראות מרכזית מאפשרת גם ניתוח שימוש אמיתי: אילו tools בכלל בשימוש, אילו סוכנים חיצוניים הכי פעילים, ואיפה latency גבוה חורג מהמצופה ודורש בדיקה.
מימוש נכון של הנראות הזו כולל גם קורלציה בין קריאות: כשTask ב-A2A מוביל לכמה קריאות MCP פנימיות, ה-Gateway צריך לקשר ביניהן תחת אותו trace ID, כדי שכשמשהו נכשל אפשר יהיה לראות את כל השרשרת המלאה — מהבקשה החיצונית הראשונה ועד הקריאה הפנימית האחרונה שנכשלה, לא רק קטע מבודד ממנה.
מסלול הקמה הדרגתי
הטעות הנפוצה בהקמת Agent Gateway היא ניסיון להעביר את כל התעבורה הקיימת דרכו ביום אחד. הגישה הבטוחה יותר היא להתחיל משרת MCP חדש או חיבור A2A חדש, לחייב אותו לעבור דרך ה-Gateway מהיום הראשון, ולהעביר בהדרגה חיבורים קיימים אחד אחרי השני, תוך ניטור שלא נשבר דבר בכל מעבר. תוך כמה חודשים, כשרוב התעבורה עוברת דרך נקודה מרכזית אחת, הארגון מקבל את מה שחסר לו מלכתחילה: שליטה, נראות, ומדיניות אחידה על כל תעבורת הסוכנים, במקום אוסף חיבורים נקודתיים שאף אחד לא רואה בתמונה המלאה.
עלות ביצועים: הימנעות מ-Gateway כצוואר בקבוק
שיקול שלא תמיד מקבל תשומת לב מספקת הוא ההשפעה של Gateway מרכזי על latency. כל קריאה שעוברת דרך שכבת אכיפה נוספת סופגת עלות זמן, וכשמדובר בסוכנים שמבצעים עשרות קריאות MCP בתוך שנייה — למשל סוכן שסורק כמה כלים ברצף כדי לענות על שאלה — עלות ה-latency המצטברת יכולה להיות משמעותית. הפתרון הוא לתכנן את ה-Gateway מלכתחילה לביצועים גבוהים: cache של תוצאות אימות כדי לא לבצע handshake מלא בכל קריאה, connection pooling לשרתי MCP נפוצים, ומדידת latency שה-Gateway עצמו מוסיף כמדד ניטור קבוע, לא רק כבדיקה חד-פעמית בזמן ההקמה.
ארגונים ששוקלים בין Gateway מרכזי יחיד לבין מודל sidecar מבוזר, שבו כל שירות מריץ instance קטן משלו של לוגיקת ה-Gateway, צריכים לשקול את גודל הארגון: sidecar מפחית latency (הבדיקה מתבצעת מקומית) אבל מסבך את עדכון המדיניות (צריך לפרוס לכל sidecar בנפרד). ברוב הארגונים בגודל בינוני, Gateway מרכזי עם caching אגרסיבי מספיק, ועדיף על המורכבות התפעולית של מודל מבוזר לגמרי, אלא אם קנה המידה כבר מצדיק את זה בבירור.
תגיות: Agent Gateway · MCP Gateway · A2A · policy enforcement · enterprise AI · rate limiting