Cross-Language Agents — חיבור סוכן Python לסוכן TypeScript או Go
מאת צוות מדיה דיל · 12.08.2026 · Agent Protocols · 5 דק׳
מדריך מעשי לחיבור סוכני AI שנכתבו בשפות שונות: איך A2A ו-MCP פותרים את בעיית האינטרופרביליות בלי לכפות שפה או framework אחיד על כל הצוותים.
ארגון עם צוות data science שכותב ב-Python, צוות פרונט-אנד שכותב ב-TypeScript, וצוות תשתיות שכותב ב-Go, ניסה לבנות מערכת סוכנים משותפת — וגילה שהניסיון לאחד הכול ל-framework אחד ושפה אחת פשוט לא ריאלי. כל צוות משקיע שנים בכלים, ספריות וידע מצטבר בשפה שלו, ודרישה "תעברו כולם ל-Python כי שם יש הכי הרבה SDKs לסוכנים" נתקלת בהתנגדות מוצדקת. הפתרון האמיתי הוא לא לאחד שפות — הוא לתקשר בין הסוכנים דרך פרוטוקול שלא מתעניין בשפת המימוש בכלל. זו בדיוק הסיבה ש-A2A ו-MCP תוכננו כפרוטוקולים מבוססי HTTP/JSON, לא כספריות שפה ספציפית.
למה JSON-RPC הוא הבחירה הנכונה לגישור בין שפות
הבחירה הזו נשמעת מובנת מאליה בדיעבד, אבל היא תוצאה של לקח כואב מדורות קודמים של פרוטוקולי RPC: כל פורמט בינארי קנייני, כמה שיהיה יעיל, יוצר תלות בכלי generation ספציפיים שלא תמיד קיימים או מתוחזקים היטב בכל שפה. JSON כפורמט טקסטואלי קריא הוא איטי יותר בביצועים גולמיים, אבל הוא זמין בכל שפה בעולם בלי שום תלות חיצונית, וזה בדיוק מה שקובע בפועל את קצב האימוץ של פרוטוקול חוצה ארגונים.
ההחלטה העיצובית המרכזית שהופכת A2A לבר-מימוש בכל שפה היא שהוא בנוי מעל HTTP סטנדרטי עם גוף הודעות ב-JSON-RPC 2.0. כל שפת תכנות מודרנית — Python, TypeScript, Go, Java, Rust — יודעת לשלוח בקשת HTTP ולפרש JSON בלי ספרייה מיוחדת. זה שונה מפרוטוקולים ישנים יותר שדרשו stub generation ספציפי לשפה (כמו gRPC עם קבצי proto מיוחדים לכל שפה), ומקטין דרמטית את החיכוך בחיבור צוותים שכותבים בשפות שונות. סוכן Python יכול לקרוא ל-Task API של סוכן Go פשוט על ידי בניית בקשת HTTP רגילה, בלי לדעת דבר על המימוש הפנימי בצד השני.
אותו עיקרון חל על MCP: פרוטוקול ה-transport (בדרך כלל stdio לתהליכים מקומיים, או HTTP+SSE ל-remote servers) לא תלוי בשפה שבה השרת נכתב. שרת MCP שנכתב ב-TypeScript יכול לשרת client שנכתב ב-Python בלי שום שכבת תרגום נוספת, כל עוד שניהם עומדים בסכימת ה-JSON המוגדרת במפרט. הרחבה על מבנה ה-transport הזה נמצאת במדריך ארכיטקטורת MCP.
מה כן שונה בין שפות — SDK quality ולא הפרוטוקול עצמו
פער בשלות ה-SDK בין שפות הוא לא רק עניין נוחות פיתוח — הוא משפיע ישירות על סיכוני אבטחה ותחזוקה. SDK צעיר פחות בשל עלול לפספס עדכוני אבטחה במפרט, או לממש רק חלק מהמצבים הנדרשים ב-Task lifecycle, מה שיוצר פערי התנהגות עדינים שקשה לאתר בבדיקות רגילות. צוותים שבוחרים לכתוב שרת קריטי בשפה עם SDK צעיר צריכים לקחת בחשבון תקורת תחזוקה גבוהה יותר, ולעיתים כדאי יותר להשקיע בכתיבת שכבת wrapper דקה שממפה בין הקוד העסקי לבין SDK בוגר בשפה אחרת, ולשמור את המורכבות הפרוטוקולרית שם.
למרות שהפרוטוקול עצמו agnostic לשפה, איכות ה-SDK הרשמי משתנה בין שפות בפועל, ולזה יש השלכות אמיתיות. SDK ה-Python ל-MCP, למשל, לרוב הבשל ביותר כי הוא הראשון שפורסם, בעוד SDKs ל-Go או ל-Rust עשויים לפגר בתמיכה בפיצ'רים חדשים במפרט. צוות שבוחר שפה לכתיבת שרת MCP חדש צריך לשקול לא רק את שפת הבחירה הרגילה שלו, אלא גם את בשלות ה-SDK הרלוונטי — לפעמים עדיף לכתוב wrapper דק בשפה עם SDK בשל, ולעטוף אותו סביב הלוגיקה העסקית שנכתבת בשפה המועדפת.
- בדקו את גרסת ה-SDK הרשמית לשפה שלכם מול המפרט העדכני ביותר
- העדיפו transport מבוסס HTTP על פני mechanisms ספציפיים לשפה כשמחברים בין צוותים
- הריצו conformance tests מול המפרט הרשמי, לא רק מול SDK אחד
Type Safety חוצה שפות — אתגר אמיתי שנפתר בסכימה
אתגר מעשי שצוותים נתקלים בו הוא type safety: TypeScript עם type checking חזק בזמן קומפילציה, מול Python עם typing דינמי, מול Go עם structs נוקשים. הפתרון שהתייצב כסטנדרט הוא הגדרת סכימת JSON Schema משותפת לכל skill ו-tool, שממנה כל שפה מייצרת את הטיפוסים המקומיים שלה — TypeScript מייצר interfaces, Python מייצר Pydantic models, Go מייצר structs — אבל כולם נגזרים מאותו מקור אמת יחיד. זה מונע דריפט הדרגתי שבו שני צוותים מגדירים "אותו" אובייקט קצת אחרת, ומגלים את הפער רק כשקריאה אמיתית נכשלת בפרודקשן בגלל שדה חסר או טיפוס שגוי.
גישה זו דומה מאוד לאיך שצוותים מנהלים סכימות API משותפות באמצעות OpenAPI, רק שכאן היעד הוא סכימת ה-Task וה-AgentCard במקום endpoint רגיל. הרחבה על בניית סכימה תקנית ל-Agent Card נמצאת במדריך בניית Agent Card.
דוגמה מעשית: זרימת עבודה משולבת שפות
מערכת טיפוסית עם סוכן Python לניתוח נתונים, סוכן TypeScript לממשק משתמש וסוכן Go לעיבוד קבצים בקנה מידה גדול, מתחברת כך: סוכן ה-UI ב-TypeScript פותח Task דרך A2A מול סוכן ה-Python כשמשתמש מבקש ניתוח, סוכן ה-Python מזהה שהוא צריך לעבד קובץ גדול ומאציל תת-משימה לסוכן ה-Go דרך A2A נוסף, וכל אחד מהסוכנים משתמש ב-MCP לגישה לכלים הפנימיים שלו — למשל, לוגיקת ה-Python ניגשת למסד הנתונים דרך MCP server ייעודי. אף אחד מהצוותים לא צריך לדעת איך הצוותים האחרים כתבו את הקוד שלהם, כי כל התקשורת ביניהם עוברת דרך פרוטוקולים סטנדרטיים, לא דרך קריאת פונקציה ישירה או שיתוף ספריות פנימיות.
דיבוג חוצה שפות — האתגר שמתגלה רק בפרודקשן
הקושי המעשי הכי גדול בעבודה חוצת שפות הוא לא כתיבת הקוד אלא הדיבוג כשמשהו נשבר. כשקריאת A2A מסוכן Python לסוכן Go נכשלת, הדיבוג המסורתי — לעבור עם stack trace אחד מקצה לקצה — פשוט לא עובד, כי אין stack trace משותף בין שתי שפות שרצות בתהליכים נפרדים. הפתרון הוא לאמץ trace ID אחיד שמועבר בכל הודעה, לרוב דרך header סטנדרטי בהשראת OpenTelemetry, כך שכל שפה, גם אם היא לא חולקת שום קוד עם השפה השנייה, יכולה לרשום לוג עם אותו מזהה. כשמשהו נשבר, אפשר לחפש את ה-trace ID באמצעות כלי ניטור מרכזי ולראות את כל השרשרת המלאה, גם אם היא עברה בין שלוש שפות שונות ושלושה תהליכים נפרדים לגמרי.
בפועל, השקעה מוקדמת בתשתית tracing חוצת שפות משתלמת הרבה יותר מאשר ניסיון לתקן בעיה כזו אחרי שהיא כבר מתרחשת בפרודקשן. ארגונים שמזניחים את זה מגלים שדיבוג תקלה חוצת-שפות יכול לקחת ימים, כי כל צוות בודק רק את הלוגים שלו ואין דרך לקשר בין השברים.
תגיות: cross-language agents · A2A · MCP · JSON-RPC · interoperability · multi-language systems