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

1. מבוא

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

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

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

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

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

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

מה תלמדו

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

מה תצטרכו

גישה ל-Google Cloud Shell

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

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

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

מפעילים את Cloud Shell

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

ב-Google Cloud Console, לוחצים על סמל 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 ותחיל את מטא-נתוני השליטה של Dataplex בדיוק כמו שעשינו בחלק 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 Dataplex Aspects (Governance rules)
cd ..
chmod +x ./generate_payloads.sh ./apply_governance.sh
./generate_payloads.sh
./apply_governance.sh

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

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

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

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

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

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

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

עוברים לספריית השרת ומזריקים את מזהה הפרויקט לקובץ ההגדרות:

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 Dataplex Catalog.

  lookup_entry:
    kind: dataplex-lookup-entry
    source: dataplex
    description: Retrieve a specific entry from Dataplex 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

🔍 ניתוח מעמיק: לולאת ההנמקה של השלטון

בודקים היטב את הקטע tools ב-YAML. אנחנו חושפים במפורש בדיוק שלושה כלים ספציפיים של Dataplex. זה לא אקראי, אלא יוצר לולאת נימוקים קפדנית שמונעת הזיות:

‫dataplex-search-aspect-types (הסבר על הכללים): כשמשתמש מבקש "נתונים שאושרו על ידי הדירקטוריון", מודל ה-LLM לא יודע למה הוא מתכוון. הוא משתמש בכלי הזה כדי לחפש את סוגי ההיבטים שלכם ב-Dataplex. המערכת מזהה שהערך Board Approved תואם להיבט שנקרא official-data-product-spec עם רמת סיווג GOLD_CRITICAL.
‫dataplex-search-entries (Find Candidates): עכשיו, אחרי שמודל ה-LLM יודע מה לחפש, הוא משתמש בכלי הזה כדי לחפש ב-Dataplex Catalog (לדוגמה, חיפוש טבלאות עם מילת המפתח 'הכנסה'). הוא מקבל רשימה של משאבים תואמים.
‫dataplex-lookup-entry (אימות העובדות): לפני כתיבת SQL, מודל ה-LLM משתמש בכלי הזה כדי לבדוק את המטא-נתונים המדויקים של טבלה ספציפית. אם לא מצורף לטבלה ההיבט GOLD_CRITICAL, מודל ה-LLM דוחה אותה וממשיך לחפש.

הגדרת שלושת הכלים האלה מאפשרת לנו להגביל את ה-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. לזהות הזו יהיו רק ההרשאות הנדרשות לקריאת קטלוג Dataplex ולגישה לנתוני BigQuery.

export MCP_SA=mcp-sa
gcloud iam service-accounts create ${MCP_SA} \
    --display-name="Service Account for Dataplex 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 Dataplex 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 מנוהל. במקום לתת לממשק הקצה של ה-GenAI גישה ישירה למסד הנתונים, הוא יתחבר לכתובת ה-URL הזו של Cloud Run. הסוכן יכול לראות רק את מה שכלי הארגז מאפשר לו לראות.

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

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

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

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

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

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

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

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

שילוב של MCPToolset: במקום לכתוב צד לקוח HTTP מותאם אישית כדי ליצור אינטראקציה עם כלי Dataplex, ה-ADK משתמש ב-MCPToolset(server_url=mcp_url). הפונקציה הזו מאחזרת באופן דינמי את ההגדרה של tools.yaml משרת ה-MCP שנפרס ומתרגמת אותה לקריאות פונקציה מקוריות עבור ה-LLM.
הוראות למערכת: הפרמטר instructions מכיל את כללי השליטה המחמירים (אותה לוגיקה שבה השתמשנו בממשק שורת הפקודה GEMINI.md). הוא מורה למודל באופן מפורש לבצע את לולאת הנימוקים משלב 1 (חיפוש מטא-נתונים) לשלב 2 (שאילתת נתונים).
תיאום בין סוכנים: המחלקה 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=dataplex-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 Dataplex Agent "

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

ה-ADK framework מסתמך על משתני סביבה כדי להבין את ההקשר שלו. צריך להגדיר באופן מפורש את מזהה הפרויקט והאזור, ולהפעיל את השימוש ב-Vertex AI. אנחנו מוסיפים אותם לאותו קובץ .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, הוא עדיין צריך הרשאות בסיסיות כדי לפעול. אנחנו מקצים בדיוק שני תפקידים:

משתמש Vertex AI: כדי להפעיל את מודל Gemini ליצירת תשובות בשפה טבעית.
‫Cloud Run Invoker: כדי לשלוח קריאה מאובטחת ל-MCP Server API. אין לו גישה ישירה ל-BigQuery או ל-Dataplex.

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=dataplex-agent \
  --with_ui \
  . \
  -- \
  --service-account=$AGENT_SERVICE_ACCOUNT \
  --allow-unauthenticated

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

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

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

המשתמש שולח הנחיה בסוכן ADK (ממשק משתמש למפתחים).
‫ADK Agent‏ (agent.py) מעבד את הקלט ומפעיל את מודל Gemini.
‫Gemini קובע שהוא צריך הקשר ומבקש משרת ה-MCP להפעיל את כלי Dataplex.
שרת ה-MCP אוכף את כללי הניהול של Dataplex ומחזיר את המטא-נתונים.
‫Gemini מסנתז את התשובה המהימנה על סמך המטא-נתונים ומחזיר אותה למשתמש.

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

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

תזמור: סוכן ה-ADK (שפועל ב-Cloud Run) מקבל את הטקסט.
ניתוב בקשות לכלים: Gemini מזהה שהשאלה שלכם דורשת הקשר של נתונים ומעביר את הבקשה אל שרת ה-MCP.
בדיקת ניהול: שרת ה-MCP (שפועל במופע נפרד של Cloud Run) שולח שאילתות ל-Dataplex לגבי סוגים ספציפיים של מאפיינים.
סינתזה: המטא-נתונים הרלוונטיים מוחזרים ל-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?"

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

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

למה זה חשוב:

בלי מטא-נתונים כאלה של ניהול גישה, סביר להניח שמודל 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 כדי להסיר את הטבלאות, מערכי הנתונים והגדרות ההיבטים של Dataplex ב-BigQuery.

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 dataplex-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 גנרטיבי מאפשרת לכם ליצור שיטה שיטתית למניעת אחזור נתונים לא מאומתים או נתונים שנוצרו על ידי הזיות של המודל.

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

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

מה השלב הבא?

‫Dataplex Foundational Governance Codelab: כדאי ללמוד את היסודות של ניהול נתונים ב-Dataplex לפני שמוסיפים את שכבת ה-AI.
מסמכי התיעוד של כלי Dataplex: אפשר לעיין במסמכי התיעוד הרשמיים של כלי Dataplex והתוספים המוכנים מראש שבהם נעשה שימוש בשיעור ה-Lab הזה.
תחילת העבודה עם תוספים ל-Gemini CLI: במאמר הזה מוסבר איך ליצור תוספים מותאמים אישית כדי להעניק לסוכני ה-AI הגנרטיבי שלכם עוד יותר יכולות.
ניתוח מעמיק של MCP: כדאי לעיין במפרט הרשמי של MCP כדי להבין איך ליצור שרתים בהתאמה אישית עבור ממשקי API פנימיים של הארגון.