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

Last reviewed 2026-10-20 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. ארכיטקטורה של סוכן יחיד שנפרסת ב-Cloud Run.

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

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

קצה קדמי
המשתמשים יוצרים אינטראקציה עם הסוכן דרך ממשק קצה (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 ולהשתמש בהם.
Model Armor
‫Model Armor בודק ומסנן הנחיות ותשובות כדי להגן על הנציג, על ידי מניעת קלט זדוני, אימות בטיחות התוכן והגנה על מידע אישי רגיש.
מודל AI וזמן ריצה של המודל
כדי להציג את ההסקה, הסוכן בארכיטקטורה לדוגמה משתמש במודל Gemini AI ב-Gemini Enterprise Agent Platform.
ארגז הכלים של MCP
‫
MCP Toolbox for Databases מספק לסוכן כלים ספציפיים למסדי נתונים. הוא יכול לטפל במורכבויות כמו מאגר חיבורים ואימות.
לקוחות, שרתים וכלים של MCP
‫
MCP מאפשר גישה לכלים על ידי סטנדרטיזציה של האינטראקציה בין הסוכנים לכלים. לכל צמד של סוכן וכלי, לקוח MCP שולח בקשות לשרת MCP שדרכו הסוכן ניגש לכלי, כמו מערכת קבצים או API. לדוגמה, כלים חיצוניים וכלי חיפוש Google יכולים לספק נתונים וביסוס.
ניראות (observability)
הסוכן מנוטר באמצעות Google Cloud Observability לצורך רישום ביומן, מעקב ומעקב אחר פעילות.

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

התהליך במערכת עם נציג אחד בדוגמה שלמעלה:

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

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

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

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

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

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

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

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

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

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

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

שירות לקוחות

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

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

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

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

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

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

חיזוי של סדרות זמנים

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

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

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

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

אחזור מסמכים

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

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

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

חלופות עיצוב

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

Agent runtime

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

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

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

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

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

עיצוב המערכת

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

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

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

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

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

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

אבטחה

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

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

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

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

שיקולי אמינות ב-Cloud Run

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

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

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

שיקולים לגבי פעולות ב-Cloud Run

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

שיקולים לגבי פעולות במסד הנתונים

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

שיקולים לגבי הפעולות של 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 בארכיטקטורה

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

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

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