בפוסט של AWS שנכתב בשיתוף עם מאורו ראלו (Mauro Rallo) ופטריק ואן דר פלאס (Patrick van der Plas) מרשת הקמעונאות ההולנדית HEMA, מתוארת הדרך שבה בנתה החברה שכבת ידע פנימית על גבי Amazon Bedrock AgentCore ו-Model Context Protocol (MCP). רשת HEMA, הפועלת מזה 100 שנה ומפעילה מעל 750 חנויות במדינות שונות, משרתת את פעילותה באמצעות ארגון טכנולוגי הכולל מהנדסים, מנהלי מוצר ומנתחי מערכות עסקיים. כאשר מהנדסים ב-HEMA נדרשו למענה, הם עברו בין מערכות ויקי מנותקות, קטלוגי שירותים ופורטלי IT כדי למצוא אותו. כדי להפחית את החיכוך הזה, פיתחה הרשת את העוזר הפנימי HAL במטרה לאחד את המידע ולהנגיש אותו ישירות בתוך כלי העבודה הקיימים של הצוותים.
אתגר פיצול הידע והמעבר בין פורטלים שונים
לפי התיאור בפוסט, בעיית הידע בארגון התחלקה לשתי שכבות עיקריות. השכבה הראשונה, שכללה ידע תשתיתי מובנה, הייתה מסודרת היטב: לאורך השנים תחזקה החברה קטלוג שירותים שמיפה אנשים לצוותים, צוותים לשירותים, ואת השירותים לממשקי ה-API שהם חושפים וליכולות העסקיות הנתמכות. נתונים מובנים ממערכות כמו מנוע ניהול מידע המוצר (PIM) וטבלאות ה-Data Mesh יובאו ואורגנו, כך שעבור כל דבר בנוגע למה שקיים ומי מחזיק בו, התשובה הייתה בדרך כלל זמינה למי שידע היכן לחפש.
השכבה השנייה היוותה את הפער המרכזי: הידיעה מה קיים אינה זהה לידיעה כיצד לבצע משימות מסוימות. שאלות פרוצדורליות כגון אופן בקשת גישה ל-API, הקצאת קבוצה חדשה או כללים פנימיים לא רוכזו במיקום אחיד. ככל שארגון ההנדסה גדל וגייס מהנדסים חדשים, המודל הלא-רשמי של פנייה ישירה לעמיתים בחדר הפסיק לתפקד, והתיעוד הכתוב היה מועט. מצב זה הוביל לקליטה איטית של עובדים חדשים, תשובות לא עקביות ומעבר מתמיד בין שלושה או ארבעה פורטלים שונים, תהליך שגזל לעיתים שעות עבודה רבות.
הבחירה ב-MCP וב-Amazon Bedrock AgentCore
הפתרון של HEMA הוגדר סביב שני יעדים משלימים. היעד הראשון, שיועד לעוזר HAL, היה לאחד את הידע המבוזר למקור אמת יחיד ומנוהל. היעד השני, שהוטל על פרוטוקול MCP, היה לספק את הידע הזה ישירות למשתמשים בתוך הכלים שבהם הם כבר עובדים, במקום לחייב כניסה לפורטל נוסף.
השימוש ב-MCP העניק ממשק סטנדרטי בין לקוחות הבינה המלאכותית לבין יכולות ה-Backend, כך שכל מקור ידע נחשף פעם אחת ככלי MCP ומוזן ללקוחות שונים (כגון צ'אט HAL, Kiro, Claude וסוכנים נוספים) ללא צורך בפיתוח אינטגרציות ייעודיות לכל כלי בנפרד. במקביל, הפלטפורמה Amazon Bedrock AgentCore אפשרה לבנות ולחבר את הסוכנים ללא צורך בהקמה ותפעול של תשתית שרתי MCP עצמאית. יכולות הפלטפורמה ששימשו את הפרויקט כללו את Gateway (המרת מפרטי OpenAPI ופונקציות AWS Lambda לכלי MCP באופן ישיר), Identity (ניהול אימות JWT נכנס ו-OAuth2 יוצא לממשקי API פנימיים), Runtime (אירוח הסוכן הבנוי ב-Strands כקונטיינר), וכן רכיבי זיכרון ו-Amazon Bedrock Guardrails לסינון תכנים ולתמיכה בשפה ההולנדית.
שלבי הפיתוח: מעוזר עצמאי לחיבור כלי העבודה
פיתוחו של HAL התבצע בשני שלבים עיקריים:
-
עוזר עצמאי: הגרסה הראשונה כללה ממשק צ'אט מבוסס Next.js המחובר ישירות לסוכן פנימי (סוכן Strands הפועל כקונטיינר Linux/ARM64 על AgentCore Runtime). בשלב זה, הסוכן ניגש לידע בשני נתיבים: חיפוש סמנטי ישיר מעל בסיסי הידע באמצעות כלי Strands מקומיים הקוראים ל-Amazon Bedrock Retrieve API ללא תיווך שער, וחיבור מעל MCP ל-AgentCore Gateway (המאומת באמצעות AWS IAM SigV4) עבור שאילתות של נתונים חיים, מפרטי OpenAPI וקטלוג השירותים. בסיסי הידע שנבנו מעל Amazon Bedrock Knowledge Bases כללו תיעוד IT, מפרטי API, נושאי Kafka וסכמות Avro, ערוצי Data Consolidation Layer (DCL) וקטלוג שירותים. איכות האחזור שופרה באמצעות דירוג מחדש (Reranking) של Bedrock וסינון מטא-דאטה לפי מזהה צוות.
-
פתיחת הגישה לכלים חיצוניים דרך MCP: כדי לאפשר לכלים חיצוניים כמו Kiro ו-Claude לגשת לידע ללא צורך בחלוקת פרטי הזדהות של AWS, הוקם שער AgentCore Gateway נוסף. מאחר ששער תומך בסוג אימות נכנס יחיד, השער השני הוגדר עם אימות Microsoft Entra ID (באמצעות JWT מותאם אישית) עבור הלקוחות החיצוניים, תוך שיתוף בסיסי הידע לקריאה בלבד ללא שיתוף קוד עם השער הפנימי.
מנגנון האימות וההתמודדות עם DCR
כדי לאפשר אימות של לקוחות חיצוניים ללא פרטי גישה של AWS, הוקם MCP Auth Proxy (המבוסס על Amazon API Gateway v2 HTTP API ופונקציית Lambda בודדת) לפני שער ה-Entra. הרכיב מתאים בין מפרט ה-OAuth של MCP לבין הדרישות של Entra ID: הוא מגיש מסמכי גילוי של OAuth, משכתב את ה-Scope המבוקש, מסיר את פרמטר ה-Resource הישן שאינו נתמך ב-Entra v2.0, מוסיף response_mode=query לטובת לכידת קוד האימות ביישומי שולחן עבודה, ומעביר את הפניות לנתיב /mcp יחד עם ה-Bearer Token.
בנוסף, מאחר שלקוחות MCP מצפים לתמיכה ברישום לקוחות דינמי (Dynamic Client Registration - DCR), הפרוקסי מחזיר מזהה לקוח (Client ID) קבוע ומוגדר מראש באמצעות הדמיה של קריאת POST /register, במקום לממש רישום דינמי אמיתי. תצורה זו מאפשרת למשתמשי הקצה להגדיר רק את כתובת הפרוקסי ורשימת Scopes ריקה, לבצע כניסה בדפדפן בחיבור הראשון, וליהנות מרענון אוטומטי של הטוקן.
בדיקות, פריסה ושימוש בקרב תפקידים שונים
תשתית הפרויקט הוגדרה באמצעות AWS Cloud Development Kit (AWS CDK) בריפוזיטורי TypeScript יחיד (Monorepo) עם תצורות הנמשכות מ-AWS Systems Manager (SSM). טרם המעבר לסביבת הייצור, המערכת נפרסה בסביבת Staging ונבדקה במשך חודש ימים על ידי מהנדסים ומשתמשים עסקיים כדי לתקף את איכות התשובות וכיסוי המידע.
כיום HAL משרת מגוון רחב של תפקידים ב-HEMA:
- מהנדסים ומפתחים: עושים שימוש בממשק הטכני הכולל תיעוד, מפרטי API, נושאי Kafka, קטלוג שירותים וערוצי DCL מתוך Kiro וממשק הצ'אט.
- מנהלי מוצר (Product Owners): נעזרים בעוזר לקבלת מידע פרוצדורלי ותיעוד תהליכים שלא היה להם מקור מרכזי בעבר.
- מנתחי מערכות עסקיים (Business Analysts): נעזרים בו לצורך שליפת נתוני תשתית מקטלוג השירותים, כגון שיוך שירותים, ממשקי API ובעלות של צוותים.
הפצת היכולות הפנימיות מתבצעת באמצעות רכיב המוגדר כ-"Everyone Skill" וקבצי הנחיה המתוחזקים במסגרת פורום הפיתוח החודשי לבינה מלאכותית של החברה.
היעד הבא: ממענה לשאלות לביצוע פעולות
בעוד ש-HAL פועל כיום במתכונת קריאה בלבד (Read-only) ומספק מענה לשאלות, השלב הבא המתוכנן הוא הפיכתו לשכבת פעולה (Action Layer). מאחר שהפורטלים הקיימים בארגון כבר תומכים בממשקי API ומחוברים למנגנון Single Sign-On של Microsoft Entra ID, העוזר יוכל לחשוף פעולות אלו ככלי פעולה ב-MCP תחת אותה מערכת הרשאות מבוססת קבוצות Active Directory. הדוגמה המרכזית המוצגת היא הקצאת חשבון AWS חדש: במקום שמהנדס ייכנס לפורטל ייעודי, הבקשה תוכל להתבצע ישירות מתוך ממשק הצ'אט או כלי סוכן תומכי MCP. ומאחר ש-HAL כבר משרת מנהלי מוצר ומנתחי מערכות, אותו דפוס פעולה מתרחב באופן טבעי מעבר לפעולות פיתוח אל הסט הרחב יותר של בקשות תפעוליות שתפקידים אלה מבצעים מדי יום. הלקח הוא שארכיטקטורת הקריאה מכינה את הקרקע לשלב הכתיבה והפעולות.