
MCP שינה את ארכיטקטורת סוכני AI
פרוטוקול MCP של אנתרופיק הפך במהירות לשכבת תשתית חשובה עבור סוכני AI ארגוניים. במקום להטמיע כלים ישירות בתוך כל סוכן, הוא מציע שרת כלים מרכזי, חוזה ברור בין צוותים, ואפשרות טובה יותר לניהול הרשאות, סקייל ואמינות בפרודקשן.
MCP: התשובה לבלגן שנוצר סביב כלי סוכני AI
הדור הראשון של מערכות Agentic AI נבנה לעיתים קרובות בצורה מהירה מדי: כל סוכן קיבל את הגדרות הכלים שלו, כל צוות שכפל מעט לוגיקה, וכל שינוי קטן בסכמה או בהרשאות הפך למשימה רוחבית מסוכנת. במערכות קטנות זה נסבל. בארגון שבו שבעה סוכנים מפעילים כלים חופפים, כותבים למסדי נתונים וממתינים לאישורי אדם, זו כבר בעיית ארכיטקטורה.
רוצה להישאר מעודכן ב-AI?
הירשם לדיוור השבועי שלנו וקבל עדכונים, המלצות על כלים, חדשות ודוחות מיוחדים
חיבור MCP, או Model Context Protocol, מסמן מעבר מתפיסה שבה Tool Calling הוא קוד מקומי בתוך הסוכן, לתפיסה שבה כלים הם שירות עצמאי, ניתן לגילוי, ניתן לגרסאות, וניתן לניהול כמו כל ממשק ארגוני אחר.
למה פרוטוקול עדיף על Registry פנימי
אפשר כמובן לבנות Registry מרכזי לכלים ולהזריק אותו לסוכנים בזמן ריצה. אלא שפתרון כזה נשאר לרוב תלוי בשפה, בפריימוורק ובקוד פנימי של הארגון. MCP מציע גבול תפעולי ברור יותר: שרת כלים אחד יכול להיחשף ללקוחות שונים, בפייתון או TypeScript, ב-LangGraph היום ובתשתית אחרת מחר. זו אינה רק נוחות למפתחים, אלא הפחתת תלות אסטרטגית בספק או בספרייה אחת.
המשמעות העסקית משמעותית במיוחד בארגונים שבהם צוותי למידת מכונה, אפליקציה, דאטה ואבטחה אינם יושבים באותו מחסן קוד. כאשר צוות ML אחראי על הכלים וצוות מוצר אחראי על הגרף, MCP מאפשר חוזה עבודה נקי: הכלי מוגדר, מתועד ונבדק במקום אחד, והסוכן מגלה אותו בזמן ריצה.
Stdio, HTTP ומה שבאמת חשוב בפרודקשן
בפיתוח מקומי, חיבור stdio הוא פתרון מהיר ויעיל: השרת רץ כתהליך משנה והתקשורת מתקיימת דרך קלט ופלט סטנדרטיים. החיסרון הוא רגישות גבוהה לכל הדפסה שגויה ל-stdout, משום שהיא עלולה לשבש את ערוץ הפרוטוקול. בסביבה ארגונית רחבה יותר, Streamable HTTP מתאים יותר: השרת חי כשירות עצמאי, ניתן להרצה בקונטיינר, ניתן לשיתוף בין לקוחות, ומתאים יותר לסקייל אופקי ולפריסות ענן כמו Cloud Run.
הבחירה בין שני המצבים אינה טכנית בלבד. היא משקפת את השאלה האם הכלים הם חלק מהאפליקציה או תשתית ארגונית. ברגע שכלים משרתים כמה סוכנים וכמה מוצרים, HTTP כמעט תמיד יהיה הכיוון הנכון.
Human in the Loop צריך לעבור לשכבת הפרוטוקול
אחת התובנות החשובות ביותר היא שניהול אישורי אדם לא צריך להיות מפוזר בתוך גרף הסוכן. כאשר כל פעולה רגישה, כמו כתיבה למסד נתונים או שליחת התראה, דורשת לוגיקה ייעודית בתוך LangGraph, כל כלי חדש הופך לתיאום בין צוותים. לעומת זאת, שער אישור מרכזי בין מבצע הכלים לבין לקוח MCP מאפשר מדיניות אחידה: כל קריאה לכלי רגיש נעצרת, נרשמת וממתינה לאישור, בלי שהגרף עצמו ידע על כך.
זהו דפוס חשוב במיוחד לעולמות פיננסים, בריאות, ביטוח וסייבר. סוכני AI אינם רק ממשק שיחה, הם שכבת פעולה. לכן נקודת הבקרה צריכה לשבת במקום שבו הפעולה מתרחשת, לא במקום שבו המודל החליט לבקש אותה.
MCP לא פותר הכול, אבל הוא מסדר את הגבולות
חשוב לא להפריז בהבטחה. MCP לא יגרום לכלי לא אמין להפוך לאמין, לא ימנע ממודל לבחור כלי שגוי אם התיאור שלו עמום, ולא יחליף ניטור, Audit Trail ובדיקות הרשאה. תיאורי הכלים עצמם הופכים לחלק מהנדסת הפרומפט: אם שני כלים מתוארים באופן דומה, המודל עשוי לבחור במסלול שגוי גם אם הארכיטקטורה מושלמת.
ועדיין, ככל שסוכני AI עוברים מניסויי מעבדה למערכות עסקיות, MCP מציע את מה שהיה חסר לשכבה הזו: הפרדה בין מודל, גרף וכלים. עבור ארגונים שרוצים לבנות סוכנים ברי תחזוקה, ניתנים לבקרה ומוכנים לסקייל, זהו לא עוד רכיב צדדי, אלא מועמד ברור להפוך לתקן תשתיתי.
