Deploy an Enterprise Governance-Aware Agent with MCP and Cloud Run

1. מבוא

ה-Codelab הזה הוא חלק מסדרה בת שני חלקים שבה נסביר איך ליצור סוכן GenAI שמודע לניהול.

(מומלץ לקרוא את החלק הראשון בסדרה הזו, שמתאר איך להקים את בסיס הנתונים על ידי החלת היבטים של קטלוג הידע על טבלאות BigQuery ובדיקת הכללים באופן מקומי באמצעות Gemini CLI. ‫👈 קריאת חלק 1)

עם זאת, בדיקה בממשק שורת פקודה מקומי היא רק ההתחלה. כדי להטמיע את התכונה הזו בכל החברה, צריך אבטחה מרכזית, חיבורים סטנדרטיים לכלי AI ומסגרת אפליקציה מתאימה לניהול הלוגיקה של הסוכן ולספק ממשק צ'אט מוכר.

בחלק השני של המאמר נסביר איך לפתור את האתגרים האלה ולעבור לסביבת הייצור. תפרסו את כללי השליטה בשרת MCP מרכזי שמתארח ב-Cloud Run. לאחר מכן, תשתמשו בערכה לפיתוח סוכנים (ADK) של Google כדי ליצור את אפליקציית הסוכן בפועל ולחבר אותה לכלי ה-MCP שלכם, עם ממשק משתמש מקצועי באינטרנט.

be15d5f41f0d716c.png

דרישות מוקדמות

  • פרויקט ב-Google Cloud שהחיוב בו מופעל.
  • הבנה בסיסית של Cloud Run, חשבונות שירות ב-IAM ו-Python.
  • מערכי הנתונים של BigQuery וההיבטים של Knowledge Catalog שנוצרו בחלק 1. (אל דאגה אם מחקתם אותם, בהמשך מופיע סקריפט שיאפשר לכם ליצור אותם מחדש במהירות).

מה תלמדו

  • איך משתמשים ב-Model Context Protocol‏ (MCP) כדי ליצור סטנדרט לאופן שבו סוכני AI יוצרים אינטראקציה עם נתונים ב-Google Cloud.
  • איך פורסים שרת MCP מאובטח ב-Cloud Run.
  • איך ליצור סוכן AI באמצעות הערכה לפיתוח סוכנים (ADK) ולחבר אותו לחלק האחורי של ה-MCP.
  • איך מפעילים את ממשק המשתמש המובנה למפתחים של ADK כדי ליצור אינטראקציה עם נציג מבוקר.

מה תצטרכו

  • גישה ל-Google Cloud Shell

מושגים מרכזיים

  • Model Context Protocol (MCP): אפשר לחשוב על MCP כעל "כבל USB-C אוניברסלי" לסוכני AI. במקום לכתוב קוד מותאם אישית לשילוב API לכל מודל AI, פלטפורמת MCP מספקת דרך סטנדרטית ל-AI להתחבר בצורה מאובטחת לכלי הנתונים של הארגון (כמו Knowledge Catalog ו-BigQuery).
  • ערכה לפיתוח סוכנים (ADK): מסגרת גמישה בקוד פתוח של Google שנועדה לפשט את הפיתוח מקצה לקצה של סוכני AI. הפלטפורמה מבוססת על עקרונות של הנדסת תוכנה ליצירת סוכנים, ומאפשרת לכם לתזמן כלים מורכבים, לנהל מצבים ולהפעיל בקלות ממשק משתמש מובנה למפתחים לצורך בדיקה ופריסה.

2. הגדרה ודרישות

מפעילים את Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.

ב-מסוף Google Cloud, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

הפעלת Cloud Shell

יחלפו כמה רגעים עד שההקצאה והחיבור לסביבת העבודה יושלמו. בסיום התהליך, יופיע משהו כזה:

צילום מסך של טרמינל Google Cloud Shell שבו מוצג שהסביבה מחוברת

המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות ברשת. אפשר לבצע את כל העבודה ב-codelab הזה בדפדפן. לא צריך להתקין שום דבר.

אתחול הסביבה

פותחים את Cloud Shell ומגדירים את משתני הפרויקט כדי לוודא שכל הפקודות מכוונות לתשתית הנכונה.

export PROJECT_ID=$(gcloud config get-value project)
gcloud config set project $PROJECT_ID
export REGION="us-central1"

נקודת ביקורת: להמשיך או לבנות מחדש?

מכיוון שזהו חלק 2, הנציג צריך את הנתונים המפוקחים מחלק 1 כדי לפעול. צריך לבחור את המסלול:

נתיב א': סיימתי עכשיו את חלק 1 והמשאבים שלי עדיין פועלים.

מצוין! עוברים לספריית העבודה ומוכנים להמשיך.

cd ~/devrel-demos/data-analytics/governance-context

נתיב B: דילגתי על חלק 1 או מחקתי את המשאבים שלי (ניקיתי את המשאבים).

אין בעיה. למטה מופיע בלוק פקודות לקיצור דרך. כך ייבנה מחדש אגם הנתונים ב-BigQuery באופן אוטומטי, ומטא-הנתונים של ניהול הגישה ב-Knowledge Catalog יוחלו בדיוק כמו בחלק 1.

# 1. Clone the repo and navigate to the working directory
git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
git sparse-checkout set data-analytics/governance-context
cd data-analytics/governance-context

# 2. Rebuild the messy data lake with Terraform
cd terraform
terraform init
terraform apply -var="project_id=${PROJECT_ID}" -var="region=${REGION}" -auto-approve

# 3. Generate and apply Knowledge Catalog Aspects (Governance rules)
cd ..
chmod +x ./generate_payloads.sh ./apply_governance.sh
./generate_payloads.sh
./apply_governance.sh

3. התאמה לגודל באמצעות MCP: יצירת מישור הבקרה של הנתונים

עד עכשיו, בדקתם בהצלחה את לוגיקת השליטה באמצעות Gemini CLI. זה מצוין ליצירת אב טיפוס מהיר, אבל הפעולה מתבצעת באופן מקומי באמצעות פרטי הכניסה האישיים שלכם.

בסביבה ארגונית אמיתית, צריך מישור בקרה מרכזי של נתונים. כדי לבנות אותו, נשתמש ב-GenAI Toolbox for Databases, פרויקט רשמי של קוד פתוח של Google. ארגז הכלים הזה מספק שרת MCP מוכן מראש שנועד במיוחד לחבר סוכני AI בצורה מאובטחת למסדי נתונים ולשירותי מטא-נתונים של Google Cloud, כמו Knowledge Catalog.

פריסת ערכת הכלים הזו כשרת ה-MCP שלנו ב-Cloud Run מאפשרת לנו:

  1. זהות מרכזית: הסוכן פועל כחשבון שירות מוגבל, ולא כחשבון המשתמש האישי שלכם.
  2. תקנון: כל לקוח (ADK, ‏ Gemini, אפליקציות בהתאמה אישית) יכול להתחבר לשרת הזה באמצעות פרוטוקול ה-MCP הרגיל.
  3. היקף מבוקר (הרשאה מינימלית): אנחנו לא נותנים ל-LLM גישה בלתי מוגבלת ל-BigQuery. אנחנו מכריחים אותו לנווט קודם דרך קטלוג המטא-נתונים של Knowledge Catalog.

הגדרת הגדרת הכלי (tools.yaml)

כדי להשתמש בערכת הכלים של AI גנרטיבי, צריך קובץ תצורה הצהרתי, tools.yaml. בקובץ הזה מוגדרים sources (לאן להתחבר) וtools (מה מותר ל-AI לעשות).

  1. עוברים לספריית השרת ומזריקים את מזהה הפרויקט לקובץ ההגדרות:
cd ~/devrel-demos/data-analytics/governance-context/mcp_server
envsubst < tools.yaml > tools.tmp && mv tools.tmp tools.yaml
cat tools.yaml

הוא צריך להיראות בדיוק כמו הקטע הבא. מוודאים ששדה הפרויקט תואם עכשיו למזהה הפרויקט ב-Google Cloud.

sources:
  dataplex:
    kind: dataplex
    project: YOUR-PROJECT-ID

tools:
  search_entries:
    kind: dataplex-search-entries
    source: dataplex
    description: Search for entries in Knowledge Catalog.

  lookup_entry:
    kind: dataplex-lookup-entry
    source: dataplex
    description: Retrieve a specific entry from Knowledge Catalog.

  search_aspect_types:
    kind: dataplex-search-aspect-types
    source: dataplex
    description: Find aspect types relevant to a query.

toolsets:
  dataplex-toolset:
    - search_entries
    - lookup_entry
    - search_aspect_types

הגדרת שלושת הכלים האלה מאפשרת לנו לכפות על ה-AI להיות במצב 'קריאה בלבד' ו'ניהול תחילה'.

אבטחת ההגדרה (Secret Manager)

באדריכלות ארגונית, אסור להטמיע קובצי תצורה ישירות בתמונות של מאגרי מידע. אנחנו נאחסן את tools.yaml באופן מאובטח ב-Google Cloud Secret Manager.

gcloud services enable secretmanager.googleapis.com
gcloud secrets create dataplex-tools-config --data-file=tools.yaml

הטמעה של הרשאות מינימליות (IAM)

בשלב הבא, יוצרים חשבון שירות ייעודי לשרת GenAI Toolbox MCP. לזהות הזו יהיו רק ההרשאות הנדרשות לקריאת הקטלוג של Knowledge Catalog ולגישה לנתוני BigQuery.

export MCP_SA=mcp-sa
gcloud iam service-accounts create ${MCP_SA} \
    --display-name="Service Account for Knowledge Catalog MCP"
export MCP_SERVICE_ACCOUNT="${MCP_SA}@${PROJECT_ID}.iam.gserviceaccount.com"

# Allow the server to read its own config from Secret Manager
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$MCP_SERVICE_ACCOUNT" \
  --role="roles/secretmanager.secretAccessor"

# Allow the server to read Knowledge Catalog Metadata and BigQuery Data
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$MCP_SERVICE_ACCOUNT" \
  --role="roles/dataplex.catalogViewer"
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$MCP_SERVICE_ACCOUNT" \
  --role="roles/bigquery.dataViewer"

פריסת שרת ה-MCP ל-Cloud Run

עכשיו פורסים את ערכת הכלים של ה-AI הגנרטיבי. משתמשים בתמונת קונטיינר מוכנה מראש של Google‏ (database-toolbox/toolbox) ומטמיעים את ההגדרה מ-Secret Manager‏ (--set-secrets) בזמן הריצה.

export IMAGE=us-central1-docker.pkg.dev/database-toolbox/toolbox/toolbox:latest

gcloud run deploy governance-mcp \
    --image=$IMAGE \
    --service-account $MCP_SERVICE_ACCOUNT \
    --region=$REGION \
    --no-allow-unauthenticated \
    --set-secrets="/app/tools.yaml=dataplex-tools-config:latest" \
    --args="--tools-file=/app/tools.yaml","--address=0.0.0.0","--port=8080"

עכשיו יש לכם API מנוהל. במקום לתת לחלק הקצה הקדמי של ה-AI הגנרטיבי גישה ישירה למסד הנתונים, הוא יתחבר לכתובת ה-URL הזו של Cloud Run. הסוכן יכול לראות רק את מה שכלי הארגז מאפשר לו לראות.

4. יצירת קצה עורפי של סוכן באמצעות ADK

הקמתם מישור בקרה מאובטח ומנוהל של נתונים (MCP) שפועל ב-Cloud Run. עכשיו, סוכן ה-AI צריך framework שתתזמן את הלוגיקה שלו, כמו עיבוד קלט של משתמשים, החלטה מתי להתקשר עם שרת ה-MCP ועיצוב הפלט.

במקום לכתוב את כל קוד ה-boilerplate הזה מאפס, נשתמש בערכה לפיתוח סוכנים (ADK) של Google. ערכת ה-ADK היא מסגרת שמתמקדת בקוד, ועוטפת באופן אוטומטי את הלוגיקה של הסוכן בחלק האחורי של FastAPI. בנוסף, יש לו ממשק משתמש מובנה למפתחים, שמאפשר לכם לראות באופן מיידי את תהליך החשיבה של הסוכן ואת הקריאות לכלים, בלי שתצטרכו ליצור קודם חזית עורפית בהתאמה אישית.

בדיקת הלוגיקה של הסוכן (agent.py)

לפני שמגדירים את התשתית, כדאי לבדוק את ליבת האפליקציה הזו.

עוברים לספרייה ומציגים את התוכן של agent.py. הקובץ הזה הוא ה "מוח" של פריסת ה-ADK.

cd ~/devrel-demos/data-analytics/governance-context/mcp_server
cat agent.py

בודקים את מבנה הקוד. הוא מבצע שלוש פונקציות קריטיות עם מינימום קוד סטנדרטי:

  1. שילוב של MCPToolset: במקום לכתוב צד הלקוח ב-HTTP מותאם אישית כדי ליצור אינטראקציה עם כלי Knowledge Catalog, ה-ADK משתמש ב-MCPToolset(server_url=mcp_url). הפעולה הזו מאחזרת באופן דינמי את ההגדרה של tools.yaml משרת ה-MCP שנפרס ומתרגמת אותן לקריאות פונקציה מקוריות עבור ה-LLM.
  2. הוראות למערכת: הפרמטר instructions מכיל את כללי הממשל המחמירים (אותה לוגיקה שבה השתמשנו בממשק שורת הפקודה GEMINI.md). הוא מורה למודל באופן מפורש לבצע את לולאת הנימוקים של שלב 1 (חיפוש מטא-נתונים) עד שלב 2 (שאילתת נתונים).
  3. תזמור סוכנים: המחלקה Agent(...) קושרת יחד את מודל Gemini, את הנחיית המערכת ואת הכלים של MCP. כשפורסים את האובייקט הזה, ADK ממיר אותו באופן אוטומטי לנקודת קצה של FastAPI שניתנת להרחבה.

הפרדת תפקידים: הגדרת הזהות של הקצה הקדמי

כדי להריץ את הקוד הזה בצורה מאובטחת, צריך להגיד לסוכן איפה נמצא שרת ה-MCP. ניצור את כתובת ה-URL באופן דינמי ונשמור אותה בקובץ .env שה-ADK יקרא בזמן הריצה.

בנוסף, ניצור זהות נפרדת (dataplex-agent-sa) לאפליקציה הזו שפונה למשתמשים. הפרדת תפקידים זו מבטיחה שלסוכן הקצה הקדמי יהיו הרשאות שונות מאלה של שרת השליטה בעורף.

מריצים את הפקודות הבאות כדי להגדיר את הסביבה והזהות:

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
export MCP_SERVER_URL=https://governance-mcp-${PROJECT_NUMBER}.${REGION}.run.app/mcp

export AGENT_SA=knowledge-catalog-agent-sa
export AGENT_SERVICE_ACCOUNT="${AGENT_SA}@${PROJECT_ID}.iam.gserviceaccount.com"

gcloud iam service-accounts create ${AGENT_SA} \
    --display-name="Service Account for Knowledge Catalog Agent "

הגדרת משתני זמן ריצה

המסגרת של ה-ADK מסתמכת על משתני סביבה כדי להבין את ההקשר שלה. אנחנו צריכים להגדיר במפורש את מזהה הפרויקט, האזור ולאפשר שימוש ב-Gemini Enterprise Agent Engine. אנחנו מוסיפים את המשתנים האלה לאותו קובץ .env.

echo MCP_SERVER_URL=$MCP_SERVER_URL > .env
echo GOOGLE_GENAI_USE_VERTEXAI=1 >> .env
echo GOOGLE_CLOUD_PROJECT=$PROJECT_ID >> .env
echo GOOGLE_CLOUD_LOCATION=$REGION >> .env

מתן הרשאות

למרות שהסוכן מעביר את בדיקות השליטה לשרת MCP, הוא עדיין צריך הרשאות בסיסיות כדי לפעול. אנחנו מקצים בדיוק שני תפקידים:

  1. משתמש ב-Gemini Enterprise Agent Engine: כדי להפעיל את מודל Gemini ליצירת תשובות בשפה טבעית.
  2. ‫Cloud Run Invoker: כדי לשלוח קריאה מאובטחת ל-API של שרת ה-MCP. אין לו גישה ישירה ל-BigQuery או לקטלוג הידע!
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$AGENT_SERVICE_ACCOUNT" \
  --role="roles/aiplatform.user"

gcloud run services add-iam-policy-binding governance-mcp \
  --region=$REGION \
  --member="serviceAccount:$AGENT_SERVICE_ACCOUNT" \
  --role="roles/run.invoker"

פריסה ב-Cloud Run

לבסוף, פורסים את הפול סטאק ב-Cloud Run.

אנחנו משתמשים ב-uvx כדי להריץ את כלי ה-ADK בלי להתקין ידנית תלויות. הפקודה שלמטה אורזת את הלוגיקה של agent.py, יוצרת קובץ אימג' של קונטיינר, מוסיפה את חשבון השירות ומפעילה שרת FastAPI. אם מוסיפים את הדגל --with_ui, היא גם מאגדת את ADK Web Playground לצורך ניפוי באגים.

הפקודה הזו יוצרת את הקונטיינר ומפריסה אותו. התהליך עשוי להימשך דקה עד 3 דקות.

uvx --from google-adk \
adk deploy cloud_run \
  --project=$PROJECT_ID \
  --region=$REGION \
  --service_name=knowledge-catalog-agent \
  --with_ui \
  . \
  -- \
  --service-account=$AGENT_SERVICE_ACCOUNT \
  --allow-unauthenticated

אחרי שהפקודה הזו מסתיימת, היא מפיקה כתובת URL של שירות (e.g., https://dataplex-agent-xyz.run.app). לוחצים על הקישור הזה כדי לפתוח את ממשק הצ'אט של ה-GenAI עם כללי הממשל.

12a5fa4c2aaf381f.png

זרימה ארכיטקטונית מקצה לקצה

סיימתם להגדיר את המערכת. כשמשתמש מנהל אינטראקציה עם ממשק המשתמש של ה-ADK, הרצף הבא מתרחש:

  1. המשתמש שולח הנחיה בסוכן ADK (ממשק משתמש למפתחים).
  2. סוכן ה-ADK (agent.py) מעבד את הקלט ומפעיל את מודל Gemini.
  3. ‫Gemini קובע שהוא צריך הקשר ומבקש משרת ה-MCP להפעיל את הכלים של Knowledge Catalog.
  4. שרת ה-MCP אוכף את כללי הניהול של Knowledge Catalog ומחזיר את המטא-נתונים.
  5. ‫Gemini מסכם את התשובה המהימנה על סמך המטא-נתונים ומחזיר אותה למשתמש.

5. בדיקת הסוכן של Enterprise

עכשיו שהסוכן פעיל, נחזור לתרחישי השליטה שנבדקו קודם באמצעות ה-CLI. הלוגיקה נשארת זהה, אבל עכשיו אתם מבצעים אינטראקציה עם ADK Web Playground שנפרס, שמציג באופן חזותי את המצב הפנימי ואת ההפעלות של הכלים.

  1. תזמור: סוכן ADK (שפועל ב-Cloud Run) מקבל את הטקסט.
  2. ניתוב כלי: Gemini מזהה שהשאלה שלכם דורשת הקשר של נתונים ומעביר את הבקשה אל שרת ה-MCP.
  3. בדיקת ניהול: שרת ה-MCP (שפועל במכונת Cloud Run נפרדת) שולח שאילתות ל-Knowledge Catalog לגבי סוגים ספציפיים של היבטים.
  4. סינתזה: המטא-נתונים הרלוונטיים מוחזרים ל-Gemini כדי ליצור את התשובה הסופית.

אימות הלוגיקה של הניהול

פותחים בדפדפן את כתובת ה-URL של השירות שנוצרה בשלב הקודם (e.g., https://dataplex-agent-xyz.run.app). מדביקים את ההנחיה הבאה:

"My dashboard needs to show what's happening right now with our ad spend. I can't wait for the overnight load. What do you recommend?"

אפשר לעקוב אחרי תהליך החשיבה של הסוכן בממשק המשתמש למפתחים:

  1. זיהוי כוונות: הסוכן מנתח את הביטויים "right now" (עכשיו) ו-"can't wait for overnight" (לא יכול לחכות עד הלילה).
  2. חיפוש מטא-נתונים: הוא קורא לכלי ה-MCP‏ search_aspect_types. הוא מחפש נכסי נתונים שבהם update_frequencyההיבט מוגדר כ-REALTIME או כ-STREAMING, ולא כ-DAILY או כ-MONTHLY.
  3. בחירה: המערכת מזהה שהטבלה mkt_realtime_campaign_performance עומדת בקריטריונים האלה, בעוד שהטבלה fin_monthly_closing_internal (למרות שהיא באיכות גבוהה) איטית מדי בשביל הבקשה שלכם.
  4. תשובה: הסוכן ממליץ על הטבלה בזמן אמת.

e0da615724199e.png

למה זה חשוב:

בלי מטא-נתונים של ניהול גישה, סביר להניח שמודל LLM ימליץ על הטבלה fin_monthly_closing_internal רק בגלל שיש בה עמודה בשם ad_spend, בלי להתייחס לעובדה שהנתונים בני 24 שעות. הקשר של המטא-נתונים מנע שגיאה עסקית.

אפשר גם לבדוק את ההנחיה 'ישיבת דירקטוריון' כדי לראות איך הסוכן עובר לטבלאות שונות על סמך ההיבט 'רמת מוצר הנתונים':

"We are preparing the deck for an internal Board of Directors meeting next week. I need the numbers to be absolutely finalized, trustworthy, and kept strictly confidential. Which table is safe to use?"

6. הסרת המשאבים

כדי לא לצבור חיובים לחשבון Google Cloud על המשאבים שבהם השתמשתם ב-codelab הזה, צריך לפעול לפי השלבים הבאים כדי להשמיד את כל התשתית שנוצרה בחלק 1 ובחלק 2.

כיבוי סופי של אגם הנתונים (Terraform)

משתמשים ב-Terraform כדי להסיר את הטבלאות ומערכי הנתונים ב-BigQuery ואת הגדרות ההיבטים ב-Knowledge Catalog.

cd ~/devrel-demos/data-analytics/governance-context/terraform
terraform destroy -var="project_id=${PROJECT_ID}" -var="region=${REGION}" -auto-approve

מחיקת שירותים של Cloud Run

מסירים את משאבי המחשוב כדי להפסיק את החיוב הפעיל על הקונטיינרים הפועלים.

gcloud run services delete governance-mcp --region=$REGION --quiet
gcloud run services delete knowledge-catalog-agent --region=$REGION --quiet

ניקוי של ארטיפקטים של בנייה ואחסון של שלבי ביניים

כשפרסתם את סוכן ה-ADK באמצעות uvx, המערכת יצרה באופן אוטומטי קובץ אימג' של קונטיינר והעלתה את קוד המקור שלכם לקטגוריה של Cloud Storage זמנית. הארטיפקטים האלה נשמרים גם אחרי שמוחקים את שירות Cloud Run, ותידרשו לשלם עלויות אחסון שוטפות.

מסירים את מאגר Artifact Registry ואת קטגוריית הביניים של Cloud Storage:

# Delete the repository used for the agent build
gcloud artifacts repositories delete cloud-run-source-deploy \
    --location=$REGION \
    --quiet

# Delete the staging bucket created by Cloud Run source deploy
gcloud storage rm --recursive gs://run-sources-${PROJECT_ID}-${REGION}

מחיקת זהויות, הרשאות וסודות

כדי למנוע מצבים שבהם רשומות יתומות יישארו בדף ה-IAM של הפרויקט, צריך קודם להסיר את הקישורים למדיניות ה-IAM. לאחר מכן, מוחקים את חשבונות השירות ואת סודות ההגדרה.

# Remove IAM roles granted to the MCP Service Account
gcloud projects remove-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$MCP_SERVICE_ACCOUNT" \
  --role="roles/secretmanager.secretAccessor" --quiet
gcloud projects remove-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$MCP_SERVICE_ACCOUNT" \
  --role="roles/dataplex.catalogViewer" --quiet
gcloud projects remove-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$MCP_SERVICE_ACCOUNT" \
  --role="roles/bigquery.dataViewer" --quiet

# Remove IAM roles granted to the Agent Service Account
gcloud projects remove-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$AGENT_SERVICE_ACCOUNT" \
  --role="roles/aiplatform.user" --quiet

# Delete the Service Accounts
gcloud iam service-accounts delete $MCP_SERVICE_ACCOUNT --quiet
gcloud iam service-accounts delete $AGENT_SERVICE_ACCOUNT --quiet

# Delete the Secret Manager entry
gcloud secrets delete dataplex-tools-config --quiet

הסרת הגדרה מקומית

לבסוף, מנקים את קובצי התצורה המקומיים ואת משתני הסביבה ב-Cloud Shell.

# Uninstall the Gemini CLI extension (installed in Part 1)
gemini extensions uninstall dataplex

# Remove local repository files and unset variables
cd ~
rm -rf ~/devrel-demos
unset MCP_SERVER_URL
unset MCP_SERVICE_ACCOUNT
unset AGENT_SERVICE_ACCOUNT

7. מעולה!

הצלחתם לפרוס סוכן GenAI מקצה לקצה שמודע לניהול.

ב-Codelab הזה, שמחולק לשני חלקים, עברנו מעבר להנדסת הנחיות פשוטה כדי להטמיע ארכיטקטורה חזקה שמוכנה לייצור. הגדרתם את ניהול הנתונים כתנאי מוקדם לשימוש ב-AI גנרטיבי, וכך יצרתם שיטה שיטתית למניעת אחזור נתונים לא מאומתים או הזיות על ידי המודל.

מסקנות עיקריות

  • בינה מלאכותית דטרמיניסטית באמצעות מטא-נתונים: במקום להסתמך על מודל שפה גדול (LLM) כדי לנחש את הטבלה הנכונה על סמך שמות העמודות, השתמשתם ב-GenAI Toolbox for Databases כדי לאכוף לולאת חשיבה רציונלית קפדנית. הצגתם באופן מפורש רק שלושה כלים של Knowledge Catalog‏ (search_aspect_types, search_entries, lookup_entry), וכך אילצתם את המודל לאמת את אישורי הנתונים לפני שהוא מסנתז תשובות.
  • ארכיטקטורה מנותקת (MCP): באמצעות פריסת שרת Model Context Protocol‏ (MCP) ב-Cloud Run, הפשטתם את כללי משילות הנתונים שלכם לממשק API מרכזי וסטנדרטי. הסוכן של ממשק הקצה לא צריך להכיל לוגיקה של מסד נתונים, אלא רק לתקשר באמצעות תקן ה-MCP. כלומר, תוכלו לחבר כל מודל או לקוח AI עתידי לאותו בק-אנד מנוהל.
  • הפרדת תפקידים: יישמתם את העיקרון של הרשאת הגישה המינימלית על ידי בידוד זהויות IAM. לסוכן ADK שפונה למשתמשים יש הרשאות מוגבלות להפעלת מודלים ולניתוב API, בעוד ששרת ה-MCP בעורף המערכת מטפל באופן מאובטח בשאילתות של Knowledge Catalog ובאחזור נתונים מ-BigQuery.
  • תזמור סוכנים עם קוד: השתמשתם בערכה לפיתוח סוכנים (ADK) של Google כדי לעטוף באופן מיידי את לוגיקת הסוכן של Python ב-FastAPI backend שניתן להרחבה, תוך שימוש בממשק המשתמש המובנה למפתחים כדי להמחיש ולנפות באגים בהפעלות של כלי פנימיים של הסוכן.

מה השלב הבא?