מערכת AI עם כמה סוכנים ב-Google Cloud

Last reviewed 2026-10-09 UTC

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

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

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

ארכיטקטורה

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

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

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

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

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

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

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

Agent Runtime

אפשר לפרוס סוכני AI כשירותי Cloud Run ללא שרת (serverless), כאפליקציות בקונטיינרים ב-Google Kubernetes Engine ‏(GKE) או ב-Agent Runtime ב-Gemini Enterprise Agent Platform.

ADK

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

מודל ה-AI וזמני הריצה של המודל

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

Model Armor

התכונה "הגנה מוגברת על המודל" מאפשרת לבדוק את הקלט והתגובות של מודלים שנפרסו ב-Agent Platform וב-GKE, ולהסיר מהם תוכן זדוני או רגיש. אפשר להשתמש ב-Model Armor גם לתנועה של סוכנים וכלים שמנותבת דרך Agent Gateway. מידע נוסף זמין במאמר שילוב של Model Armor עם שירותי Google Cloud .

לקוחות, שרתים וכלים של MCP

‫Model Context Protocol (MCP) מאפשר גישה לכלים באמצעות סטנדרטיזציה של האינטראקציה בין הסוכנים לכלים. לכל זוג של נציג וכלי, לקוח MCP שולח בקשות לשרת MCP שדרכו הנציג ניגש לכלי כמו מסד נתונים, מערכת קבצים או API.

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

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

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

  3. הסוכן המתאם מפעיל את אחד מהתהליכים הבאים של הסוכנים, בהתאם לכוונה שמובעת בהנחיה.

    • רציף:
      1. סוכן המשנה של משימה א' מבצע משימה.
      2. סוכן המשנה של משימה א' מפעיל את סוכן המשנה של משימה א'.1.

    • שיפור איטרטיבי:

      1. הסוכן המשני של משימה ב' מבצע משימה.
      2. סוכן המשנה להערכת איכות בודק את הפלט של סוכן המשנה למשימה ב'.
      3. אם הפלט לא מספק, סוכן המשנה להערכת איכות מפעיל את סוכן המשנה לשיפור ההנחיות כדי לשפר את ההנחיה.
      4. הסוכן המשני של משימה ב' מבצע את המשימה שלו שוב באמצעות ההנחיה המשופרת.

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

    הארכיטקטורה לדוגמה כוללת נתיב של human-in-the-loop כדי לאפשר למשתמשים אנושיים להתערב בתהליך של הסוכן במקרה הצורך.

  4. סוכן המשנה task-A.1 וסוכן המשנה להערכת איכות מפעילים באופן עצמאי את סוכן המשנה ליצירת תשובות.

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

המוצרים והכלים שבהם נעשה שימוש

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

  • ‫ Cloud Run: פלטפורמת מחשוב בלי שרת (serverless computing) שמאפשרת להריץ קונטיינרים ישירות בתשתית של Google, שניתנת להתאמה לעומס.
  • ‫ Gemini Enterprise Agent Platform: פלטפורמה מקיפה שמאפשרת ליצור, לנהל, לבצע אופטימיזציה ולהתאים לעומס (scale) סוכני AI ברמה שמתאימה לארגונים.
  • ‫ Google Kubernetes Engine (GKE): שירות Kubernetes שמאפשר לפרוס ולהפעיל אפליקציות בקונטיינרים בקנה מידה נרחב באמצעות התשתית של Google.
  • ‫ Model Armor: שירות שמגן על משאבי ה-AI הגנרטיבי וה-AI האקטיבי מפני החדרת פרומפטים, דליפות של מידע אישי רגיש ותוכן פוגעני.
  • ‫Agent Development Kit (ADK): ערכה של כלים וספריות לפיתוח, לבדיקה ולפריסה של סוכני AI.
  • ‫ פרוטוקול Agent2Agent‏ (A2A): פרוטוקול פתוח שמאפשר תקשורת ואינטראופרביליות בין סוכנים, בלי קשר לשפת התכנות ולסביבת זמן הריצה שלהם.
  • ‫ Model Context Protocol‏ (MCP): תקן קוד פתוח לחיבור אפליקציות AI למערכות חיצוניות.

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

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

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

יועצים פיננסיים

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

תרחיש לדוגמה של מערכת מרובת סוכנים שמשמשת כיועץ פיננסי.

בתרשים מוצג התהליך הבא:

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

עוזר מחקר

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

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

בתרשים מוצג התהליך הבא:

  1. סוכן תכנון יוצר תוכנית מחקר מפורטת.

  2. סוכן מחקר מבצע את המשימות הבאות:

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

    סוכן המחקר חוזר על המשימות האלה עד שסוכן ההערכה מאשר את המחקר.

  3. סוכן ליצירת דוחות יוצר את דוח המחקר הסופי.

אופטימיזציה של שרשרת האספקה

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

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

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

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

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

  3. סוכן תקשורת עם ספקים מתקשר עם ספקים חיצוניים בשם הסוכנים האחרים במערכת.

חלופות עיצוב

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

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

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

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

עיצוב המערכת

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

אבטחה

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

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

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

  • פיקוח אנושי: לפעמים מערכת AI אקטיבי עלולה להיכשל או לא לפעול כמו שצריך. לדוגמה, המודל עלול ליצור תוכן לא מדויק או שהסוכן עלול לבחור כלים לא מתאימים. במערכות AI אקטיביות שקריטיות לעסק, כדאי לשלב תהליך עבודה שכולל האדם שבתהליך כדי לאפשר למפקחים אנושיים לעקוב אחרי הסוכנים, לשנות את הפעולות שלהם ולהשהות אותם. לדוגמה, משתמשים אנושיים יכולים לבדוק את הפלט של הנציגים, לאשר או לדחות את הפלט ולתת הנחיות נוספות כדי לתקן שגיאות או לקבל החלטות אסטרטגיות. הגישה הזו משלבת את היעילות של מערכות AI אקטיבי עם החשיבה הביקורתית והמומחיות בתחום של משתמשים אנושיים.
  • זהות הסוכן וגישה עם הרשאות מינימליות:
  • ניהול תעבורת הנתונים הנכנסת והיוצאת: אתם יכולים להפנות את תעבורת הנתונים של הנציג דרך Agent Gateway כדי לאכוף כללי מדיניות אבטחה בזמן הריצה, גם בגבולות של תעבורת הנתונים הנכנסת וגם בגבולות של תעבורת הנתונים היוצאת. במאמר סביבות זמן ריצה נתמכות של סוכנים מפורטות סביבות זמן הריצה שתומכות ב-Agent Gateway.
    • ‫Client-to-Agent (ingress)‎: פורסים את 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.
  • אמצעי בקרה לאבטחה: פלטפורמת Agent תומכת Google Cloud באמצעי בקרה לאבטחה שבהם אתם יכולים להשתמש כדי לעמוד בדרישות שלכם לגבי מיקום אחסון הנתונים, מפתחות הצפנה בניהול הלקוח (CMEK), אבטחת רשת באמצעות VPC Service Controls ו-Access Transparency. מידע נוסף זמין במשאבי העזרה הבאים:
  • בטיחות: מודלי AI עלולים ליצור תגובות פוגעניות, לפעמים בתגובה להנחיות זדוניות.
    • כדי לשפר את הבטיחות ולצמצם את הסיכון לשימוש לרעה במערכת ה-AI האקטיבי, אתם יכולים להגדיר מסנני תוכן שישמשו כמחסומים לקלטים ולתשובות שעלולים להזיק. מידע נוסף זמין במאמר מסנני בטיחות ותוכן.
    • כדי לבדוק בקשות להסקת מסקנות, הנחיות לסוכנים, קריאות לכלים ותשובות, ולסנן מהם איומים כמו החדרת הנחיות ותוכן פוגעני, אתם יכולים להשתמש בהגנה מוגברת על המודל לקריאות ישירות ל-API של המודל וגם לבקשות שמועברות דרך Agent Gateway. הגנה מוגברת על המודל עוזרת למנוע קלט זדוני, לאמת את בטיחות התוכן, להגן על מידע אישי רגיש, לשמור על תאימות ולאכוף מדיניות בטיחות ואבטחה באופן עקבי.
  • גישה למודלים: אתם יכולים להגדיר כללי מדיניות בארגון כדי להגביל את הסוג והגרסאות של מודלי ה-AI שאפשר להשתמש בהם בפרויקט ב- Google Cloud . מידע נוסף מופיע במאמר שליטה בגישה למודלים של Model Garden.
  • הגנה על נתונים: כדי לזהות מידע רגיש בהנחיות, בתשובות ובנתוני היומנים ולהסיר ממנו את פרטי הזיהוי, אתם יכולים להשתמש ב-Cloud Data Loss Prevention API. מידע נוסף זמין במאמר הסרת פרטי הזיהוי מנתונים רגישים.

שיקולי אבטחה של 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 עומדת בדרישות האבטחה, כדאי לפעול לפי ההמלצות הבאות:

  • אבטחת תעבורת נתונים נכנסת (לשירות החזיתי): כדי לשלוט בגישה לאפליקציה, משביתים את כתובת ה-URL שמוגדרת כברירת מחדל ב-run.app של השירות החזיתי ב-Cloud Run ומגדירים מאזן עומסים חיצוני אזורי של אפליקציות. בנוסף לאיזון העומסים של התנועה הנכנסת לאפליקציה, מאזן העומסים מטפל בניהול של אישורי ה-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

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

אמינות

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

שיקולי אמינות של נציגים

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

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

שיקולי אמינות ב-Agent Platform

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

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

העמידות של Cloud Run להפסקות זמניות בשירות באזורים ובתחומים

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

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

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

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

תפעול

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

שיקולים לגבי פעולות ב-Agent Platform

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

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

שיקולים לגבי הפעולות של MCP

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

  • כלים למסדי נתונים: כדי לנהל ביעילות את הכלים למסדי נתונים של סוכני ה-AI, ולוודא שהסוכנים מטפלים בצורה מאובטחת במשימות מורכבות כמו איחוד חיבורים ואימות, השתמשו ב-MCP Toolbox for Databases. הוא מספק מיקום מרכזי לאחסון ולעדכון של כלי מסד נתונים. אתם יכולים לשתף את הכלים בין סוכנים ולעדכן את הכלים בלי לפרוס מחדש את הסוכנים. ארגז הכלים כולל מגוון רחב של כלים למסדי נתונים של Google Cloudכמו AlloyDB ל-PostgreSQL, ולמסדי נתונים של צד שלישי כמו MongoDB.
  • מודלים של AI גנרטיבי: כדי לאפשר לסוכני AI להשתמש במודלים של AI גנרטיבי של Google כמו Imagen ו-Veo, אתם יכולים להשתמש בשרתי MCP ל- Google Cloud generative media APIs.
  • מוצרי אבטחה וכלים של Google: כדי לאפשר לסוכני ה-AI לגשת למוצרי אבטחה וכלים של Google, כמו Google Security Operations, ‏ Google Threat Intelligence ו-Security Command Center, משתמשים בשרתי MCP למוצרי אבטחה של Google.

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

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

כדי לקרוא על עקרונות והמלצות למצוינות תפעולית שספציפיים לעומסי עבודה של 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.

פריסה

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

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

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

מחבר: Kumar Dhanagopal | מפתח פתרונות חוצי-מוצרים

תורמים אחרים: