מערכת AI עם סוכן יחיד באמצעות ADK ו-Cloud Run

Last reviewed 2025-12-09 UTC

במסמך הזה מוצגת ארכיטקטורה לדוגמה, שתעזור לכם לתכנן מערכת AI עם סוכן יחיד ב- Google Cloud. המערכת עם הסוכן היחיד בארכיטקטורה הזו נוצרת באמצעות הערכה לפיתוח סוכנים (ADK) ונפרסת ב-Cloud Run. אפשר גם לפרוס את הסוכן ב-Agent Runtime ב-Gemini Enterprise Agent Platform או ב-Google Kubernetes Engine ‏ (GKE). הארכיטקטורה משתמשת ב-Model Context Protocol‏ (MCP), שמאפשר לסוכן לגשת למידע ממקורות מרובים ולעבד אותו כדי לספק תובנות עם הקשר עשיר.

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

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

ארכיטקטורה

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

ארכיטקטורה של סוכן יחיד שנפרסת ב-Cloud Run. ארכיטקטורה של מערכת AI אקטיבי מרובת סוכנים ב- Google Cloud.

רכיבי ארכיטקטורה

הארכיטקטורה לדוגמה מורכבת מהרכיבים הבאים:

רכיב תיאור
קצה קדמי המשתמשים יוצרים אינטראקציה עם הנציג דרך ממשק קצה (frontend), כמו ממשק צ'אט, שפועל כשירות Cloud Run ללא שרת (serverless).
סוכן הנציג מקבל בקשות מהמשתמשים, מפרש את כוונת המשתמש, בוחר את הכלים המתאימים ואז מסנתז מידע כדי לענות על שאילתות.
Agent Runtime הסוכן נוצר באמצעות ADK ונפרס בתור שירות Cloud Run בלי שרת (serverless). אתם יכולים גם לפרוס את הסוכן ב-Agent Runtime ב-Gemini Enterprise Agent Platform או כאפליקציה בקונטיינר ב-GKE. מידע על בחירת Agent Runtime זמין במאמר בחירת רכיבי ארכיטקטורת ה-AI האקטיבי.
ADK ערכת ה-ADK מספקת כלים ומסגרת לפיתוח, לבדיקה ולפריסה של סוכנים. ה-ADK מפשט את המורכבות של יצירת סוכנים ומאפשר למפתחי AI להתמקד בלוגיקה וביכולות של הסוכן. כשאתם מפתחים סוכנים באמצעות ADK, אתם יכולים להגדיר אותם כך שיוכלו לגשת לכלים מובנים כמו חיפוש Google ולהשתמש בהם.
מודל AI וזמן ריצה של המודל כדי להציג את ההסקה, הסוכן בארכיטקטורה לדוגמה משתמש במודל Gemini AI ב-Gemini Enterprise Agent Platform.
ארגז הכלים של MCP ‫MCP Toolbox for Databases מספק כלים ספציפיים למסדי נתונים בשביל הסוכן. הוא יכול לטפל במשימות מורכבות כמו איחוד חיבורים ואימות.
לקוחות, שרתים וכלים של MCP ‫MCP מאפשר גישה לכלים על ידי סטנדרטיזציה של האינטראקציה בין הסוכנים לכלים. לכל צמד של סוכן וכלי, לקוח MCP שולח בקשות לשרת MCP שדרכו הסוכן ניגש לכלי, כמו מערכת קבצים או API. לדוגמה, כלים חיצוניים כמו StackOverflow LangChain וכלי חיפוש Google יכולים לספק נתונים ומידע לביסוס.
ניראות (observability) הסוכן מנוטר באמצעות Google Cloud Observability לצורך רישום ביומן, מעקב ויומני מעקב.

תהליך עבודה של סוכן

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

  1. המשתמש מזין הנחיה דרך ממשק קצה (frontend), כמו ממשק צ'אט, שפועל כשירות Cloud Run בלי שרת (serverless).
  2. ה-frontend מעביר את ההנחיה לסוכן.
  3. הנציג משתמש במודל ה-AI כדי להבין את ההנחיה של המשתמש וליצור תשובה:
    • מודל ה-AI קובע באילו כלים להשתמש כדי לאסוף מידע לפי הקשר או כדי לבצע משימה.
    • הסוכן מפעיל את הכלים ומוסיף את התשובה להקשר שלו.
    • הנציג מבצע אימות ביניים ואימות מול מקורות מידע.

המוצרים שהשתמשו בהם

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

תרחישים לדוגמה

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

מיון אוטומטי של דוחות על באגים

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

בתרחיש לדוגמה הזה, הארכיטקטורה מספקת את היתרונות הבאים:

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

הארכיטקטורה הזו מתאימה לכל ארגון שמפתח תוכנה ורוצה לשפר את היעילות והאפקטיביות של תהליך פתרון הבאגים. מידע נוסף ואפשרויות פריסה זמינים במאמרים Software Bug Assistant - ADK Python Sample Agent ו-Tools Make an Agent: From Zero to Assistant with ADK.

שירות לקוחות

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

במקרה השימוש הזה, הארכיטקטורה מספקת את היתרונות הבאים:

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

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

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

הארכיטקטורה הזו מתאימה במיוחד לארגונים קמעונאיים שרוצים לשפר את חוויית הלקוח, להגדיל את נפח המכירות ולפשט את ניהול ההזמנות והתזמון. למידע נוסף ולאפשרויות פריסה, ראו נציג שירות הלקוחות של Cymbal Home & Garden.

חיזוי של סדרות זמן

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

תרחיש השימוש הזה יכול להועיל לארגונים במקרים רבים, כמו:

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

הארכיטקטורה הזו אידיאלית לכל ארגון שצריך להסתגל לדפוסים משתנים על סמך מגמות קיימות. הוא גם אידיאלי לארגונים שהלקוחות שלהם יכולים להפיק תועלת מתובנות פרואקטיביות שיעזרו להם לתכנן את העתיד. מידע נוסף ואפשרויות פריסה זמינים במאמר Time Series Forecasting Agent with Google's ADK and MCP Toolbox.

אחזור מסמכים

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

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

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

חלופות עיצוב

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

Agent runtime

בארכיטקטורה שמתוארת במסמך הזה, הנציג והכלים שלו נפרסים ב-Cloud Run. אפשר גם להשתמש ב-GKE או ב-Agent Runtime כסביבת זמן ריצה חלופית. במאמר "בחירת רכיבי הארכיטקטורה של ה-AI האקטיבי", בקטע Agent Runtime מוסבר איך בוחרים Agent Runtime.

זמן הריצה של מודל AI

בארכיטקטורה שמתוארת במסמך הזה, זמן הריצה של מודל ה-AI הוא Agent Platform. אפשר גם להשתמש ב-Cloud Run או ב-GKE כסביבת זמן ריצה חלופית. במאמר "בחירת רכיבי הארכיטקטורה של ה-AI האקטיבי", בקטע סביבת זמן ריצה של מודל, מוסבר איך בוחרים סביבת זמן ריצה של מודל.

שיקולים בתכנון

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

עיצוב המערכת

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

בחירת אזור

כשבוחרים אזורים ב- Google Cloud לאפליקציות מבוססות-AI, כדאי להביא בחשבון את הגורמים הבאים:

כדי לבחור מיקומים Google Cloud מתאימים לאפליקציות, אפשר להשתמש בכלים הבאים:

  • Google Cloud כלי לבחירת אזור: כלי אינטראקטיבי מבוסס-אינטרנט לבחירת האזור האופטימלי של Google Cloudלאפליקציות ולנתונים שלכם, על סמך גורמים כמו טביעת רגל פחמנית, עלות וזמן אחזור.
  • ‫Cloud Location Finder API: ממשק API ציבורי שמאפשר למצוא באופן פרוגרמטי מיקומי פריסה ב- Google Cloud, ב-Google Distributed Cloud ובספקי ענן אחרים.

תכנון סוכנים

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

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

זיכרון ואחסון הסשן

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

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

‫ADK יכול לעקוב אחרי סשנים בזיכרון לטווח קצר באמצעות האובייקט Session והמאפיינים state. ‫ADK תומך גם בזיכרון לטווח ארוך בסשנים עם אותו משתמש, כולל באמצעות Memory Bank. כדי לאחסן את מצב הסשן, אפשר גם להשתמש בשירותים כמו Memorystore for Redis.

איך בוחרים את רכיבי הארכיטקטורה של ה-AI האקטיבי

אבטחה

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

שיקולי אבטחה לסוכנים

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

  • פיקוח אנושי: לפעמים מערכת AI אקטיבי עלולה להיכשל או לא לפעול כמו שצריך. לדוגמה, המודל עשוי ליצור תוכן לא מדויק או שהסוכן עשוי לבחור כלים לא מתאימים. במערכות AI אקטיביות שקריטיות לעסק, כדאי לשלב תהליך עבודה שכולל האדם שבתהליך כדי לאפשר למפקחים אנושיים לעקוב אחרי הסוכנים, לשנות את הפעולות שלהם ולהשהות אותם. לדוגמה, משתמשים אנושיים יכולים לבדוק את הפלט של הסוכנים, לאשר או לדחות את הפלט ולספק הנחיות נוספות לתיקון שגיאות או לקבלת החלטות אסטרטגיות. הגישה הזו משלבת את היעילות של מערכות AI אקטיבי עם החשיבה הביקורתית והמומחיות בתחום של משתמשים אנושיים.
  • זהות הסוכן וגישה עם הרשאות מינימליות:
  • ניהול תעבורת נתונים נכנסת ויוצאת: הפניית תעבורת הסוכן דרך Agent Gateway כדי לאכוף מדיניות אבטחה בזמן ריצה בגבולות של תעבורת הנתונים הנכנסת והיוצאת. במאמר סביבות זמן ריצה נתמכות של סוכנים מפורטות סביבות זמן הריצה שתומכות ב-Agent Gateway.
    • תקשורת מלקוח לסוכן (תעבורת נתונים נכנסת): הטמעה של Agent Gateway לפני Agent Runtime. השער עוזר לאמת את המתקשרים ולבדוק את ההנחיות הנכנסות בזמן אמת באמצעות הגנה מוגברת על המודל.
    • מסוכן לכל מקום (תעבורת נתונים יוצאת):
      • ניתוב בקשות יוצאות מסוכן לסוכן (A2A) ומסוכן לכלי (MCP) דרך Agent Gateway במצב תעבורת נתונים יוצאת.
      • אכיפה של מדיניות גישה שמוגדרת כדחייה כברירת מחדל, באמצעות מדיניות גישה של IAM ושרת proxy לאימות זהויות (IAP).
      • מוודאים שהסוכנים וכלי היעד רשומים ב-Agent Registry.
      • לבדוק את הקריאות והתשובות של כלים יוצאים באמצעות Model Armor כדי למנוע זליגת נתונים, החדרת פרומפטים עקיפה ושימוש לרעה בכלים.
  • מעקב: מעקב אחרי התנהגות הנציג באמצעות יכולות מעקב מקיפות שמאפשרות לכם לראות כל פעולה שהנציג מבצע, כולל תהליך החשיבה שלו, בחירת הכלים ונתיבי הביצוע. למידע נוסף, אפשר לעיין במאמרים כניסה של סוכן ל-Agent Runtime וכניסה ל-ADK.

מידע נוסף על אבטחת סוכני AI זמין במאמר בטיחות ואבטחה של סוכני AI.

שיקולי אבטחה ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות האבטחה שלכם, כדאי לפעול לפי ההמלצות הבאות:

  • אחריות משותפת: האבטחה היא באחריות משותפת. פלטפורמת הסוכנים מאבטחת את התשתית הבסיסית ומספקת כלים ואמצעי בקרה לאבטחה שיעזרו לכם להגן על הנתונים, הקוד והמודלים שלכם. אתם אחראים להגדיר נכון את השירותים, לנהל את אמצעי בקרת הגישה ולאבטח את האפליקציות שלכם. מידע נוסף זמין במאמר בנושא אחריות משותפת בפלטפורמת הסוכנים.
  • אמצעי בקרה לאבטחה: Agent Platform תומכת Google Cloud באמצעי בקרה לאבטחה שבהם אפשר להשתמש כדי לעמוד בדרישות שלכם בנוגע למיקום אחסון הנתונים, מפתחות הצפנה בניהול הלקוח (CMEK), אבטחת רשת באמצעות VPC Service Controls, וAccess Transparency. מידע נוסף זמין במשאבי העזרה הבאים:
  • בטיחות: מודלי AI עשויים להפיק תגובות מזיקות, לפעמים בתגובה לפרומפטים זדוניים.
    • כדי לשפר את הבטיחות ולצמצם את הסיכון לשימוש לרעה במערכת ה-AI האקטיבי, אתם יכולים להגדיר מסנני תוכן שישמשו כמחסומים לקלטים ולתשובות שעלולים להזיק. מידע נוסף זמין במאמר מסנני בטיחות ותוכן.
    • כדי לבדוק בקשות להסקת מסקנות, הנחיות לסוכנים, קריאות לכלים ותשובות, ולסנן מהם איומים כמו החדרת הנחיות ותוכן פוגעני, אתם יכולים להשתמש בהגנה מוגברת על המודל לקריאות ישירות ל-API של המודל וגם לבקשות שמועברות דרך Agent Gateway. הגנה מוגברת על המודל עוזרת למנוע קלט זדוני, לאמת את בטיחות התוכן, להגן על מידע אישי רגיש, לשמור על תאימות ולאכוף מדיניות בטיחות ואבטחה באופן עקבי.
  • גישה למודלים: אתם יכולים להגדיר מדיניות ארגונית כדי להגביל את הסוגים והגרסאות של מודלי AI שאפשר להשתמש בהם בפרויקט Google Cloud . מידע נוסף מופיע במאמר שליטה בגישה למודלים של Model Garden.
  • הגנה על נתונים: כדי לזהות מידע רגיש בהנחיות, בתשובות ובנתוני היומנים ולהסיר ממנו את פרטי הזיהוי, אתם יכולים להשתמש ב-Cloud Data Loss Prevention API. מידע נוסף זמין בסרטון הגנה על מידע אישי רגיש באפליקציות AI.

שיקולי אבטחה של MCP

כדי לוודא שההטמעה של MCP עומדת בדרישות האבטחה שלכם, כדאי לפעול לפי ההמלצות הבאות:

  • רישום וגילוי של כלים: רישום שרתי MCP וכלים ב-Agent Registry כדי שהסוכנים יתחברו רק לנקודות קצה (endpoints) של MCP שנמצאות במלאי ומאושרות על ידי האדמין.
  • בקרת גישה ובדיקת תנועה: אתם יכולים לנתב את התנועה מהסוכן ל-MCP דרך Agent Gateway במצב Agent-to-Anywhere (תנועה יוצאת), ולהגן על שרתי MCP (כמו שרתי MCP שמתארחים ב-Cloud Run) באמצעות IAP וכללי מדיניות גישה של IAM. הגדרת Model Armor או מדיניות פיקוח בשפה טבעית ב-Agent Gateway כדי לבדוק את הקלט והפלט של כלי MCP לאיתור חשיפה של מידע אישי רגיש והחדרה עקיפה של פרומפטים.
  • אבטחת MCP כללית: כשמגדירים את הסוכנים לשימוש ב-MCP, חשוב לוודא שהגישה לנתונים ולכלים חיצוניים מורשית, להטמיע אמצעי בקרה לשמירה על הפרטיות כמו הצפנה, להחיל מסננים כדי להגן על נתונים רגישים ולנטר את האינטראקציות עם הסוכן. מידע נוסף זמין במאמר MCP ואבטחה.

שיקולי אבטחה של A2A

כדי לוודא שההטמעה של A2A עומדת בדרישות האבטחה שלכם, כדאי לפעול לפי ההמלצות הבאות:

  • אבטחת תעבורה: פרוטוקול A2A מחייב שימוש ב-HTTPS לכל תקשורת A2A בסביבות ייצור, ומומלץ להשתמש בגרסאות 1.2 ומעלה של Transport Layer Security (‏TLS).
  • אימות: פרוטוקול A2A מעביר את האימות למנגנוני אינטרנט סטנדרטיים כמו כותרות HTTP ולתקנים כמו OAuth2 ו-OpenID Connect. כל נציג מפרסם את דרישות האימות בכרטיס הנציג שלו. מידע נוסף זמין במאמר אימות A2A.
  • פיקוח על סוכנים: רושמים סוכני A2A ב-Agent Registry ומנתבים בקשות בין סוכנים דרך Agent Gateway. באמצעות שילוב של Agent Gateway עם Agent Identity,‏ IAP ומדיניות גישה של IAM, אתם יכולים לאמת באופן קריפטוגרפי את הזהות של הסוכן המתקשר, לאכוף הרשאות מפורטות בין סוכני מתאם וסוכני משנה, ולבדוק את מטען הייעודי (payload) של סוכנים באמצעות Model Armor.

שיקולי אבטחה ב-Cloud Run

כדי לוודא שההטמעה של Cloud Run עומדת בדרישות האבטחה, כדאי לפעול לפי ההמלצות הבאות:

  • אבטחת Ingress (בשירות הקצה הקדמי): כדי לשלוט בגישה לאפליקציה, משביתים את כתובת ה-URL run.app שמוגדרת כברירת מחדל בשירות הקצה הקדמי של Cloud Run ומגדירים מאזן עומסים חיצוני אזורי של אפליקציות (ALB). בנוסף לאיזון העומסים של התנועה הנכנסת לאפליקציה, מאזן העומסים מטפל בניהול של אישורי ה-SSL. כדי להוסיף עוד שכבת הגנה, אתם יכולים להשתמש במדיניות האבטחה של Google Cloud Armor כדי לסנן בקשות, להגן מפני מתקפות DDoS ולהגביל את קצב יצירת הבקשות לשירות.

  • אימות משתמשים:

    • משתמשים בתוך הארגון: כדי לאמת את הגישה של משתמשים פנימיים לשירות Cloud Run של ממשק הקצה, משתמשים ב-IAP. כשמשתמש מנסה לקבל גישה למשאב שמאובטח באמצעות IAP, האימות ובדיקת ההרשאות מתבצעים על ידי IAP.
    • משתמשים מחוץ לארגון: כדי לאמת את הגישה של משתמשים חיצוניים לשירות החזיתי, משתמשים ב-Identity Platform או באימות ב-Firebase. כדי לנהל את הגישה של משתמשים חיצוניים, צריך להגדיר את האפליקציה כך שתטפל בתהליך הכניסה ותבצע קריאות מאומתות ל-API של שירות Cloud Run.

    מידע נוסף זמין במאמר אימות משתמשים.

  • אבטחת שרת MCP וסוכן: כשמארחים סוכנים או שרתי MCP ב-Cloud Run, מגדירים את התכונות של Agent Platform ל-Cloud Run כדי להקצות זהות מנוהלת של סוכן לשירות, ומשתמשים ב-IAP עם Agent Gateway כדי לאמת ולאשר בקשות נכנסות של סוכנים וכלים.

  • אבטחת קובצי אימג' של קונטיינרים: כדי לוודא שרק קובצי אימג' מורשים של קונטיינרים נפרסים ב-Cloud Run, אפשר להשתמש ב-Binary Authorization. כדי לזהות ולצמצם סיכוני אבטחה בקובצי אימג' של קונטיינרים, אפשר להשתמש ב-Artifact Analysis כדי להריץ באופן אוטומטי בדיקות נקודות חולשה. למידע נוסף, קראו את הסקירה הכללית על סריקת קונטיינרים.

  • מיקום אחסון הנתונים: ב-Cloud Run אפשר לעמוד בדרישות לגבי מיקום אחסון הנתונים. שירותי Cloud Run פועלים באזור שנבחר.

טיפים כלליים לפיתוח ב-Cloud Run

שיקולי אבטחה לכל המוצרים בארכיטקטורה Google Cloud

כדי לוודא שהארכיטקטורה עומדת בדרישות האבטחה, כדאי לפעול לפי ההמלצות הכלליות הבאות:

  • הצפנת נתונים: כברירת מחדל, Google Cloud מצפין נתונים במנוחה באמצעות Google-owned and Google-managed encryption keys. כדי להגן על נתוני הנציגים באמצעות מפתחות הצפנה שבשליטתכם, אתם יכולים להשתמש ב-CMEK שאתם יוצרים ומנהלים ב-Cloud KMS. למידע על שירותי Google Cloud שתואמים ל-Cloud KMS, קראו את המאמר שירותים תואמים.
  • צמצום הסיכון לזליגת נתונים: כדי לצמצם את הסיכון לזליגת נתונים, צרו מתחם של VPC Service Controls מסביב לתשתית. ב-VPC Service Controls יש תמיכה בכלGoogle Cloud השירותים שבהם משתמשים בארכיטקטורה לדוגמה.
  • בקרת גישה: כשמגדירים הרשאות למשאבים בטופולוגיה, צריך לפעול לפי העיקרון של הרשאות מינימליות.
  • אבטחת סביבת הענן: משתמשים בכלים של Security Command Center כדי לזהות נקודות חולשה, לזהות איומים ולצמצם אותם, להגדיר ולפרוס מצב אבטחה ולייצא נתונים לניתוח נוסף.
  • אופטימיזציה אחרי הפריסה: אחרי שפורסים את האפליקציה ב-Google Cloud, אפשר לקבל המלצות לשיפור האבטחה באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. מידע נוסף זמין במאמר בנושא איתור המלצות ב-Active Assist.

עוד המלצות בנושא אבטחה

אמינות

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

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

‫סימולציה של כשלים: לפני שפורסים את מערכת ה-AI האקטיבי בסביבת הייצור, מאמתים אותה באמצעות סימולציה של סביבת הייצור. לזהות ולתקן בעיות והתנהגויות לא צפויות.

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

התאוששות מהפסקות חשמל: כדי לוודא שהסוכן יכול לטפל בהפעלות מחדש בצורה חלקה ולשמור על ההקשר, צריך להפריד את המצב מזמן הריצה. כדי להטמיע אפליקציית סוכן כזו בלי שמירת מצב, צריך להשתמש במאגר נתונים חיצוני כמו מסד נתונים או מטמון מבוזר. לדוגמה, אפשר להשתמש ב-Memory Bank, ב-Memorystore for Redis או בשירות מסד נתונים כמו Cloud SQL.

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

Agent Platform

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

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

Cloud Run

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

התאמה אופקית לעומס (Horizontal scaling): שירותי Cloud Run מטפלים בשבילכם בהתאמה אוטומטית לעומס של מכונות. התאמה אוטומטית לעומס עוזרת לוודא שהמכונות יכולות לטפל בכל הבקשות הנכנסות, האירועים וניצול ה-CPU שנדרשים כדי להבטיח זמינות גבוהה.

כל המוצרים בארכיטקטורה

אופטימיזציה אחרי הפריסה: אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור האבטחה באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist?

עקרונות והמלצות בנושא מהימנות שספציפיים לעומסי עבודה של AI ו-ML מפורטים במאמר AI and ML perspective: Reliability (נקודת מבט על AI ו-ML: מהימנות) ב-Well-Architected Framework.

תפעול

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

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

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

Agent Platform

מעקב באמצעות יומני הפעילות של סוכנים: כברירת מחדל, יומני הפעילות של סוכנים שנכתבים לזרמי stdout ו-stderr מנותבים אל Cloud Logging. לרישום מתקדם ביומן, אפשר לשלב את כלי רישום היומן של Python עם Logging. אם אתם צריכים שליטה מלאה ביומנים וביומנים מובנים, אתם יכולים להשתמש בלקוח Logging. מידע נוסף זמין במאמרים רישום ביומן של סוכן ורישום ביומן ב-ADK.

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

Cloud Run

תקינות וביצועים: אפשר לעקוב אחרי שירותי Cloud Run באמצעות Google Cloud Observability. כדאי להגדיר התראות ב-Cloud Monitoring כדי לקבל הודעה על בעיות פוטנציאליות, כמו עלייה בשיעורי השגיאות, חביון גבוה או שימוש לא תקין במשאבים.

מסדי נתונים

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

MCP

כלים למסדי נתונים: כדי לנהל ביעילות את הכלים למסדי נתונים של סוכני ה-AI, ולוודא שהסוכנים מטפלים בצורה מאובטחת במשימות מורכבות כמו איחוד חיבורים ואימות, השתמשו ב-MCP Toolbox for Databases. הוא מספק מיקום מרכזי לאחסון ולעדכון של כלי מסד נתונים. אתם יכולים לשתף את הכלים בין הסוכנים ולעדכן את הכלים בלי לפרוס מחדש את הסוכנים. ארגז הכלים כולל מגוון רחב של כלים למסדי נתונים של Google Cloud , כמו AlloyDB ל-PostgreSQL, ולמסדי נתונים של צד שלישי, כמו MongoDB.

מודלים של AI גנרטיבי: כדי לאפשר לסוכני AI להשתמש במודלים של AI גנרטיבי מבית Google, כמו Imagen ו-Veo, אפשר להשתמש בשרתי MCP Google Cloud לממשקי API של מדיה גנרטיבית.

מוצרי אבטחה וכלים של Google: כדי לאפשר לסוכני ה-AI שלכם לגשת למוצרי אבטחה ולכלים של Google כמו Google Security Operations,‏ Google Threat Intelligence ו-Security Command Center, צריך להשתמש בשרתי MCP למוצרי אבטחה של Google.

כל Google Cloud המוצרים בארכיטקטורה

מעקב: איסוף וניתוח של נתוני מעקב באופן רציף באמצעות Trace. נתוני מעקב מאפשרים לזהות ולאבחן במהירות בעיות של זמן אחזור בתהליכי עבודה מורכבים של Agentic Workflows. אתם יכולים לבצע ניתוח מעמיק באמצעות תרשימים בדף Trace explorer במסוף Google Cloud . מידע נוסף זמין במאמר מעקב אחרי נציג.

כדי לקרוא על עקרונות והמלצות למצוינות תפעולית שספציפיים לעומסי עבודה של AI ו-ML, קראו את המאמר נקודת מבט על AI ו-ML: מצוינות תפעולית ב-Well-Architected Framework.

הוזלת עלויות

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

שיקולי עלות ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות העלות, כדאי לפעול לפי ההמלצות הבאות:

  • ניתוח וניהול עלויות: כדי לנתח ולנהל את העלויות של Agent Platform, מומלץ ליצור מדדי בסיס לשאילתות לשנייה (QPS) ולטוקנים לשנייה (TPS). לאחר מכן, עוקבים אחרי המדדים האלה אחרי הפריסה. ערך הבסיס עוזר גם בתכנון הקיבולת. לדוגמה, בעזרת ערך הבסיס תוכלו לקבוע מתי כדאי להשתמש בהקצאת משאבים לפי התפוקה שנקבעה.
  • בחירת מודל: המודל שתבחרו לאפליקציית ה-AI משפיע ישירות על העלויות ועל הביצועים. כדי לזהות את המודל שמספק איזון אופטימלי בין ביצועים לעלות בתרחיש השימוש הספציפי שלכם, כדאי לבדוק מודלים באופן איטרטיבי. מומלץ להתחיל עם המודל הכי חסכוני ולעבור בהדרגה לאפשרויות חזקות יותר.
  • הנדסת פרומפטים חסכונית: האורך של הפרומפטים (קלט) והתגובות שנוצרות (פלט) משפיע ישירות על הביצועים והעלות. כתבו פרומפטים קצרים וישירים עם הקשר מספק. כדאי לנסח את ההנחיות כך שהמודל ייתן תשובות תמציתיות. לדוגמה, אפשר להוסיף ביטויים כמו "סכם ב-2 משפטים" או "ציין 3 נקודות עיקריות". מידע נוסף זמין במאמר בנושא שיטות מומלצות לעיצוב הנחיות.
  • שמירת הקשר במטמון: כדי להפחית את העלות של בקשות שמכילות תוכן חוזר עם מספר גבוה של טוקנים של קלט, אפשר להשתמש בשמירת הקשר במטמון.
  • בקשות Batch: במקרים רלוונטיים, כדאי לשקול חיזוי באצווה. העלות של בקשות Batch נמוכה יותר מהעלות של בקשות רגילות.

שיקולי עלות ב-Cloud Run

כדי לוודא שההטמעה של Cloud Run עומדת בדרישות העלות, כדאי לפעול לפי ההמלצות הבאות:

שיקולי עלות לכל מוצרי Google Cloud בארכיטקטורה

אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור נוסף של העלויות באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist

כדי להעריך את העלות של המשאבים ב- Google Cloud , אתם יכולים להשתמש במחשבון העלויות שלGoogle Cloud .

במאמר נקודת מבט של AI ו-ML: אופטימיזציה של עלויות ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של עלויות שספציפיות לעומסי עבודה של AI ו-ML.

אופטימיזציה של הביצועים

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

שיקולי ביצועים לסוכנים

כדי לוודא שהגדרות הסוכן עומדות בדרישות הביצועים שלכם, כדאי לפעול לפי ההמלצות הבאות:

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

שיקולי ביצועים ב-Agent Platform

כדי לוודא שההגדרות והשימוש ב-Agent Platform עומדים בדרישות הביצועים, כדאי לפעול לפי ההמלצות הבאות:

  • בחירת מודל: המודל שתבחרו לאפליקציית ה-AI ישפיע ישירות על העלויות ועל הביצועים. כדי לזהות את המודל שמספק איזון אופטימלי בין ביצועים לעלות בתרחיש השימוש הספציפי שלכם, כדאי לבדוק מודלים באופן איטרטיבי. מומלץ להתחיל עם המודל הכי חסכוני ולעבור בהדרגה לאפשרויות חזקות יותר.
  • הנדסת פרומפטים: אורך הפרומפטים (קלט) והתשובות שנוצרות (פלט) משפיעים ישירות על הביצועים ועל העלות. כתבו הנחיות קצרות וישירות, וספקו מספיק הקשר. כדאי לעצב את ההנחיות כך שהתשובות מהמודל יהיו תמציתיות. לדוגמה, אפשר להוסיף ביטויים כמו "סכם ב-2 משפטים" או "ציין 3 נקודות עיקריות". מידע נוסף זמין במאמר בנושא שיטות מומלצות לעיצוב הנחיות.
  • שמירת הקשר במטמון: כדי לקצר את זמן האחזור של בקשות שמכילות תוכן חוזר עם מספר גבוה של טוקנים של קלט, כדאי להשתמש בשמירת הקשר במטמון.

שיקולי ביצועים ב-Cloud Run

בהתאם לדרישות הביצועים, מגדירים את הזיכרון ואת המעבד (CPU) שיוקצו לשירות Cloud Run. מידע נוסף זמין במאמרים הגדרת מגבלות זיכרון לשירותים והגדרת מגבלות מעבד (CPU) לשירותים.

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

שיקולי ביצועים לכל המוצרים בארכיטקטורה Google Cloud

אחרי שפורסים את האפליקציה ב- Google Cloud, אפשר לקבל המלצות לשיפור הביצועים באמצעות Active Assist. בודקים את ההמלצות ומיישמים אותן בהתאם לסביבה שלכם. איך מוצאים המלצות ב-Active Assist

במאמר נקודת מבט על AI ו-ML: אופטימיזציה של ביצועים ב-Well-Architected Framework, תוכלו לקרוא על עקרונות והמלצות לאופטימיזציה של ביצועים שספציפיים לעומסי עבודה של AI ו-ML.

פריסה

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

במאמר כלי MCP יש דוגמאות קוד שיעזרו לכם להתחיל להשתמש ב-ADK יחד עם שרתי MCP.

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

  • קניות בהתאמה אישית: המלצות מותאמות אישית על מוצרים של מותג, מוכר או זירת מסחר ספציפיים.
  • ניהול אירועים: אימות של אסימון וזהות משתמש הקצה על בסיס כל בקשה באמצעות העברת זהויות דינמית.
  • עיבוד הזמנות: עיבוד ואחסון של הזמנות, וניהול של אישור באימייל עם בדיקה אנושית מותנית לכמויות הזמנה מסוימות.
  • הנדסת נתונים: פיתוח צינורות עיבוד נתונים ב-Dataform, פתרון בעיות בצינורות עיבוד נתונים וניהול הנדסת נתונים – משאילתות SQL מורכבות ועד לטרנספורמציות של נתונים ותלויות בנתונים.
  • אחזור מסמכים: אתם יכולים להשתמש ב-RAG כדי לשלוח שאילתות למסמכים שאתם מעלים ל-RAG Engine ב-Gemini Enterprise Agent Platform, ולקבל תשובות עם ציטוטים מהמסמכים ומהקוד.

המאמרים הבאים

שותפים ביצירת התוכן