מערכת 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), כמו ממשק צ'אט, שפועל כשירות Cloud Run ללא שרת (serverless).
סוכנים

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

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

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

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

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

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

שיקולי אבטחה ב-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

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

אמינות

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

שיקולי אמינות של סוכנים

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

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

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

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

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

העמידות של 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 לממשקי API של Google Cloud למדיה גנרטיבית.
  • מוצרי אבטחה וכלים של Google: כדי לאפשר לסוכני ה-AI לגשת למוצרי אבטחה וכלים של Google כמו Google Security Operations,‏ Google Threat Intelligence ו-Security Command Center, משתמשים בשרתי MCP למוצרי אבטחה של Google.

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

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

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

הוזלת עלויות

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

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