במאמר הזה מוסבר איך לבחור רכיבים ארכיטקטוניים לאפליקציות מבוססות-AI גנרטיבי ב- Google Cloud. במאמר הזה מוסבר איך להעריך את המאפיינים של האפליקציה ועומס העבודה כדי לבחור מוצר או שירות מתאימים שיענו על הצרכים שלכם בצורה הטובה ביותר. תהליך התכנון של ארכיטקטורת AI אקטיבי הוא איטרטיבי. כדאי להעריך מחדש את הארכיטקטורה שלכם מדי פעם, ככל שמאפייני עומס העבודה משתנים, ככל שהדרישות מתפתחות או ככל שמוצרים ותכונות חדשים של Google Cloud הופכים לזמינים.
סוכני AI יעילים לאפליקציות שפותרות בעיות פתוחות, שעשויות לדרוש קבלת החלטות אוטונומית וניהול של תהליכי עבודה מורכבים מרובי-שלבים. סוכנים מצטיינים בפתרון בעיות בזמן אמת באמצעות נתונים חיצוניים, והם מצטיינים באוטומציה של משימות שדורשות ידע רב. היכולות האלה מאפשרות לסוכנים לספק ערך עסקי רב יותר מאשר היכולות של מודל AI לסיוע ולגנרציה.
אפשר להשתמש בסוכני AI לבעיות דטרמיניסטיות עם שלבים מוגדרים מראש. עם זאת, יש גישות אחרות שיכולות להיות יעילות ומשתלמות יותר. לדוגמה, לא צריך תהליך עבודה מבוסס-סוכן בשביל משימות כמו סיכום מסמך, תרגום טקסט או סיווג משוב מלקוחות.
למידע על פתרונות חלופיים של AI לא מבוסס-סוכן, אפשר לעיין במקורות המידע הבאים:
סקירה כללית של ארכיטקטורת הסוכן
סוכן הוא אפליקציה שמשיגה מטרה על ידי עיבוד קלט, ביצוע חשיבה רציונלית באמצעות כלים זמינים וביצוע פעולות על סמך ההחלטות שלה. סוכן משתמש במודל AI כמנוע הליבה שלו להסקת מסקנות, כדי לבצע משימות מורכבות באופן אוטומטי. הסוכן משתמש בקבוצת כלים שמאפשרים למודל ה-AI ליצור אינטראקציה עם מערכות חיצוניות ומקורות נתונים. סוכן יכול להשתמש במערכת זיכרון כדי לשמור על ההקשר וללמוד מאינטראקציות. המטרה של ארכיטקטורה מבוססת-סוכנים היא ליצור מערכת אוטונומית שיכולה להבין את הכוונה של המשתמש, ליצור תוכנית רב-שלבית ולבצע את התוכנית באמצעות הכלים הזמינים.
התרשים הבא מציג סקירה כללית של רכיבי הארכיטקטורה של מערכת מבוססת-סוכנים:
ארכיטקטורת המערכת מבוססת-הסוכנים כוללת את הרכיבים הבאים:
- מסגרת Frontend: אוסף של רכיבים, ספריות וכלים מוכנים מראש שמשמשים לבניית ממשק המשתמש של האפליקציה.
- מסגרת לפיתוח סוכנים: המסגרות והספריות שבהן אתם משתמשים כדי לבנות את הלוגיקה של הסוכן ולתת לה מבנה.
- כלים של סוכנים: אוסף של כלים, כמו ממשקי API, שירותים ופונקציות, שמחלצים נתונים ומבצעים פעולות או עסקאות.
- זיכרון של סוכן: המערכת שבה הסוכן משתמש כדי לאחסן מידע ולשלוף אותו.
- דפוסי עיצוב של סוכנים: גישות ארכיטקטוניות נפוצות לבניית אפליקציות מבוססות סוכנים.
- זמן ריצה של סוכן: סביבת המחשוב שבה פועל הלוגיקה של האפליקציה של הסוכן.
- מודלים של AI: מנוע הליבה של החשיבה הרציונלית שמפעיל את יכולות קבלת ההחלטות של הסוכן.
- זמן הריצה של המודל: התשתית שמארחת את מודל ה-AI ומספקת אותו.
בקטעים הבאים מופיע ניתוח מפורט של הרכיבים, שיעזור לכם לקבל החלטות לגבי האופן שבו כדאי לבנות את הארכיטקטורה. הבחירה שלכם ברכיבים תשפיע על הביצועים, יכולת ההתאמה, העלות והאבטחה של הסוכן. המסמך הזה מתמקד ברכיבים הארכיטקטוניים החיוניים שבהם משתמשים כדי ליצור ולפרוס את הליבה של ההיגיון והלוגיקה של הביצוע של סוכן. נושאים כמו מסגרות בטיחות של אתיקה של בינה מלאכותית וניהול זהויות של סוכנים לא נכללים במסגרת המסמך הזה.
Frontend framework
מסגרת ה-frontend היא אוסף של רכיבים, ספריות וכלים מוכנים מראש שמשמשים לבניית ממשק המשתמש של האפליקציה מבוססת הסוכן. הדרישות של ה-backend מוגדרות על ידי מסגרת ה-frontend שבוחרים. ממשק פשוט להדגמה פנימית עשוי לדרוש רק API סינכרוני של HTTP, בעוד שאפליקציה ברמת ייצור דורשת קצה עורפי שתומך בפרוטוקולים של סטרימינג ובניהול מצב חזק.
כדאי להביא בחשבון את הקטגוריות הבאות של מסגרות:
- מסגרות ליצירת אב טיפוס וכלים פנימיים: כדי לפתח במהירות, ליצור הדגמות פנימיות ואפליקציות להוכחת היתכנות, כדאי לבחור מסגרות שמתמקדות בחוויית המפתחים ובמהירות הפיתוח. בדרך כלל, המסגרות האלה מעדיפות מודל פשוט וסינכרוני שנקרא מודל בקשה-תגובה. מודל של בקשה ותגובה מאפשר לכם ליצור ממשק משתמש פונקציונלי עם מינימום קוד ועם קצה עורפי פשוט יותר בהשוואה למסגרת ייצור. הגישה הזו אידיאלית לבדיקה מהירה של הלוגיקה של הסוכן ושילובי הכלים, אבל היא לא מתאימה לאפליקציות ציבוריות שניתנות להרחבה גבוהה ודורשות אינטראקציות בזמן אמת. מסגרות נפוצות בקטגוריה הזו כוללות את Mesop ו-Gradio.
- מסגרות ייצור: כדי ליצור אפליקציות עשירות בתכונות, שניתנות להתאמה, מגיבות ומתאימות למשתמשים חיצוניים, כדאי לבחור מסגרת שמאפשרת ליצור רכיבים בהתאמה אישית. המסגרות האלה דורשות ארכיטקטורת קצה עורפי שיכולה לתמוך בחוויית משתמש מודרנית. מסגרת ייצור צריכה לכלול תמיכה בפרוטוקולים של סטרימינג, עיצוב API בלי שמירת מצב ומערכת זיכרון חיצונית חזקה לניהול מצב השיחה בכמה סשנים של משתמשים. מסגרות נפוצות לאפליקציות ייצור כוללות את Streamlit, React וFlutter AI Toolkit.
כדי לנהל את התקשורת בין המסגרות האלה לבין סוכן ה-AI, אפשר להשתמש בפרוטוקול Agent–User Interaction (AG-UI). AG-UI הוא פרוטוקול פתוח שמאפשר לסוכני AI בבק-אנד לקיים אינטראקציה עם מסגרת הפרונט-אנד שלכם. ה-AG-UI אומר ל-framework של הקצה הקדמי מתי לרנדר את התשובה של הסוכן, לעדכן את ערך דינמי של האפליקציה או להפעיל טריגר בצד הלקוח. כדי ליצור אפליקציות אינטראקטיביות מבוססות-AI, אפשר לשלב בין AG-UI לבין Agent Development Kit (ADK). מידע על ADK מופיע בקטע הבא, 'מסגרות לפיתוח סוכנים'.
מסגרות לפיתוח סוכנים
מסגרות לפיתוח סוכנים הן ספריות שמפשטות את התהליך של בנייה, בדיקה ופריסה של אפליקציות AI אקטיבי. כלי הפיתוח האלה מספקים רכיבים מובנים והפשטות ליכולות הליבה של הסוכן, כולל לולאות נימוקים, זיכרון ושילוב כלים.
כדי לפתח סוכנים מהר יותר ב- Google Cloud, מומלץ להשתמש ב-ADK. ADK הוא פריימוורק מודולרי, מבוסס-דעות וקוד פתוח, שמספק רמה גבוהה של הפשטה לבנייה ולתזמור של תהליכי עבודה, ממשימות פשוטות ועד למערכות מורכבות עם כמה סוכנים.
ה-ADK מותאם למודלים של Gemini ו- Google Cloud, אבל הוא תוכנן כך שיהיה תואם למסגרות אחרות. ADK תומך במודלים אחרים של AI ובזמני ריצה, כך שאפשר להשתמש בו עם כל מודל או שיטת פריסה. במערכות מרובות סוכנים, ADK תומך באינטראקציה באמצעות מצבי סשן משותפים, בהעברת הרשאות מבוססת-מודל לניתוב משימות בין סוכנים ובהפעלה מפורשת שמאפשרת לסוכן אחד לקרוא לסוכן אחר כפונקציה או ככלי.
כדי לעזור לכם להתחיל במהירות, ב-ADK יש דוגמאות קוד ב-Python, ב-Java וב-Go שמדגימות מגוון תרחישי שימוש בתחומים שונים. למרות שרבים מהדוגמאות האלה מדגישות זרימות שיחה, ערכת ה-ADK מתאימה גם ליצירת סוכנים אוטונומיים שמבצעים משימות בקצה העורפי. לתרחישי השימוש הלא אינטראקטיביים האלה, כדאי לבחור דפוס עיצוב של סוכן שמצטיין בעיבוד של בקשה אחת עצמאית, ומיישם טיפול חזק בשגיאות.
כדי ליצור ארכיטקטורה של סוכן בהתאמה אישית, אפשר גם להשתמש במסגרת AI למטרות כלליות כמו Genkit. Genkit מספק פרימיטיבים שמאפשרים לכם לשלוט במדויק בלוגיקה של הסוכן בלי ההפשטה ברמה גבוהה ש-ADK מציע. עם זאת, פלטפורמה ייעודית לסוכנים כמו ADK מספקת כלים מיוחדים לפיתוח אפליקציות עם סוכנים.
כלים לסוכנים
היכולת של סוכן ליצור אינטראקציה עם מערכות חיצוניות באמצעות כלים מגדירה את היעילות שלו. כלים של סוכנים הם פונקציות או ממשקי API שזמינים למודל ה-AI והסוכן משתמש בהם כדי לשפר את הפלט ולאפשר אוטומציה של משימות. כשמחברים סוכן AI למערכות חיצוניות, כלים הופכים את הסוכן מכלי ליצירת טקסט למערכת שיכולה לבצע אוטומטית משימות מורכבות שכוללות כמה שלבים.
כדי להפעיל אינטראקציות עם כלי, בוחרים אחת מהאפשרויות הבאות לשימוש בכלי:
| תרחיש שימוש | דפוס השימוש בכלי |
|---|---|
| אתם צריכים לבצע משימה נפוצה כמו השלמת חיפוש באינטרנט, ביצוע חישוב או הפעלת קוד, ואתם רוצים להאיץ את הפיתוח הראשוני. | כלים מובנים |
| אתם רוצים לבנות מערכת מודולרית או מערכת מרובת סוכנים (MAS) שדורשת כלים שניתנים להפעלה הדדית ולשימוש חוזר. | Model Context Protocol (MCP) |
| אתם צריכים לנהל, לאבטח ולנטר מספר גדול של כלים מבוססי API בקנה מידה ארגוני. | פלטפורמה לניהול API |
| אתם צריכים לבצע שילוב עם API פנימי או של צד שלישי שאין לו שרת MCP. | כלים לפונקציות מותאמות אישית |
כשבוחרים כלים לסוכן, חשוב להעריך את היכולות הפונקציונליות שלהם ואת המהימנות התפעולית שלהם. כדאי לתת עדיפות לכלים שניתן לצפות בהם, שקל לבצע בהם ניפוי באגים ושכוללים טיפול חזק בשגיאות. היכולות האלה עוזרות לכם לעקוב אחרי פעולות ולפתור בעיות במהירות. בנוסף, כדאי להעריך את היכולת של הסוכן לבחור את הכלי הנכון כדי להשלים בהצלחה את המשימות שהוקצו לו.
כלים מובנים
ADK מספק כמה כלים מובנים שמשולבים ישירות בזמן הריצה של הסוכן. אתם יכולים להשתמש בכלים האלה כפונקציות בלי להגדיר פרוטוקולי תקשורת חיצוניים. הכלים האלה מספקים פונקציות נפוצות, כולל גישה למידע בזמן אמת מהאינטרנט, הפעלת קוד באופן פרוגרמטי בסביבה מאובטחת, אחזור מידע מנתונים פרטיים של ארגונים כדי להטמיע RAG ואינטראקציה עם נתונים מובנים במסדי נתונים בענן. הכלים המובנים פועלים לצד כלים בהתאמה אישית שאתם יוצרים.
MCP
כדי לאפשר לרכיבים של המערכת האגנטית שלכם ליצור אינטראקציה, אתם צריכים להגדיר פרוטוקולי תקשורת ברורים. MCP הוא פרוטוקול פתוח שמספק ממשק סטנדרטי לסוכנים כדי לגשת לכלים, לנתונים ולשירותים אחרים שדרושים להם ולהשתמש בהם.
MCP מפריד את לוגיקת הליבה של הסוכן מההטמעה הספציפית של הכלים שלו, בדומה לאופן שבו יציאת חומרה רגילה מאפשרת לציוד היקפי שונה להתחבר למכשיר.
היתרונות של MCP:
- השילוב של כלים פשוט יותר כי יש מחברים מוכנים מראש. כשמוסיפים עוד כלים לשרת MCP, הסוכן מגלה את הכלים בלי צורך בהגדרה נוספת.
- הוא מספק דרך עקבית ליצירת שילובים בהתאמה אישית.
- הוא מספק גמישות ומקדם יכולת פעולה הדדית בין מודלים וכלים שונים.
אפשר להטמיע שרתי MCP במערכת ה-AI האגנטית באמצעות השיטות הבאות:
- השרתים של Google Cloud MCP: כדי להתחבר לשירותים של Google ו- Google Cloud , מתחברים לשרתי MCP מרוחקים שמנוהלים באופן מלא על ידי Google. השרתים האלה משפרים את התשתית הקיימת שלכם על ידי יצירת שכבה מאוחדת בכל שירותי Google ו- Google Cloud שירותים אחרים שבהם אתם משתמשים. השרתים האלה מספקים קנה מידה ללא מצב (stateless) ושילוב עם ניהול זהויות והרשאות גישה (IAM) ועם יומני ביקורת של Cloud. במאמר מוצרים נתמכים מופיעה רשימה של שרתי Google Cloud MCP.
- שרתי MCP מרוחקים: כדי להתחבר לממשקי API חיצוניים, צריך להתחבר לשרת MCP מרוחק שמארח ומנוהל על ידי צד שלישי.
- שרתי MCP באירוח עצמי: כדי להטמיע לוגיקה משלכם לסוכנים וכלים בהתאמה אישית, אתם יכולים לארח שרת MCP משלכם. יש לכם שליטה מלאה על האופן שבו אתם חושפים ממשקי API קנייניים או של צד שלישי לסוכנים שלכם. כדי לארח שרת MCP מותאם אישית משלכם, אתם יכולים לפרוס אותו כאפליקציה בקונטיינר ב-Cloud Run או ב-Google Kubernetes Engine (GKE).
פלטפורמה לניהול API
פלטפורמה לניהול ממשקי API היא מערכת מרכזית שמאפשרת לאבטח, לנטר ולשלוט בשירותים פנימיים או חיצוניים באמצעות ממשקי API. פלטפורמה לניהול ממשקי API מספקת מיקום מרכזי לקטלוג של כל ממשקי ה-API בארגון, מפשטת את האופן שבו חושפים נתונים ומספקת יכולת צפייה באמצעות מעקב אחר השימוש.
כדי לנהל את הכלים מבוססי ה-API של הסוכן בקנה מידה ארגוני ב- Google Cloud, מומלץ להשתמש ב-Apigee API hub. מרכז ה-API מאפשר לסוכנים להתחבר לנתונים באופן מיידי באמצעות קריאות HTTP ישירות, מחברים מוכנים מראש, ממשקי API מותאמים אישית שרשומים במרכז או גישה ישירה למקורות נתונים. Google Cloud הגישה הזו מאפשרת לנציגים שלכם לקבל גישה מיידית למידע שהם צריכים, בלי הצורך לבנות צינורות מורכבים לטעינה ולשילוב של נתונים בהתאמה אישית.
פלטפורמה לניהול API ופרוטוקול תקשורת כמו MCP פותרים בעיות ארכיטקטוניות שונות. פרוטוקול תקשורת קובע את הפורמט של האינטראקציה בין הסוכן לבין הכלי, וכך מבטיח שאפשר לעשות שימוש חוזר ברכיבים ולהחליף אותם. לעומת זאת, פלטפורמה לניהול ממשקי API שולטת במחזור החיים ובאבטחה של נקודת קצה ל-API, ומטפלת במשימות כמו אימות, הגבלת קצב יצירת הבקשות ומעקב. הדפוסים האלה משלימים זה את זה. לדוגמה, סוכן יכול להשתמש ב-MCP כדי לתקשר עם כלי, והכלי הזה יכול להיות נקודת קצה ל-API מאובטחת שמנוהלת ומוגנת על ידי API Hub.
כלי פונקציה מותאמת אישית
כלי פונקציות מעניק לנציג יכולות חדשות. אתם יכולים לכתוב כלי פונקציה בהתאמה אישית כדי להעניק לסוכן יכולות מיוחדות, כמו שילוב עם API חיצוני או עם מערכת עסקית קניינית. הדפוס הנפוץ ביותר להרחבת היכולות של סוכן מעבר למה שכלי מובנים יכולים להציע הוא כתיבה של כלי פונקציה בהתאמה אישית.
כדי ליצור כלי פונקציה בהתאמה אישית, כותבים פונקציה בשפת התכנות המועדפת, ואז מספקים תיאור ברור בשפה טבעית של המטרה, הפרמטרים וערכי ההחזרה שלה. המודל של הסוכן משתמש בתיאור הזה כדי להבין מתי צריך את הכלי, אילו קלטים צריך לספק ואיך לפרש את הפלט כדי להשלים את הבקשה של המשתמש.
אפשר גם ליצור כלי פונקציה בהתאמה אישית שמטמיע פונקציה של סוכן ככלי. פונקציית agent-as-a-tool חושפת סוכן אחד כפונקציה שאפשר להפעיל, וסוכן אחר יכול להפעיל אותה. הטכניקה הזו מאפשרת לכם לבנות מערכות מורכבות של כמה סוכנים, שבהן סוכן אחד יכול לתאם ולהעביר משימות מיוחדות לסוכנים מיוחדים אחרים. מידע נוסף על דפוסי עיצוב של סוכנים ועל תיאום של תזמור מרובה סוכנים זמין בהמשך המאמר בקטע בנושא דפוסי עיצוב של סוכנים.
ריבוי טכנולוגיה
ניפוח של כלי קורה כשמספקים יותר מדי הגדרות של כלים בהנחיית המערכת של מודל AI. יכול להיות שהמודל יתקשה להתמודד עם מספר גדול מדי של כלים, פרמטרים מורכבים או תיאורים מפורטים בחלון ההקשר של המודל.
אם סוכן AI עמוס מדי בגלל כמות גדולה של כלים, יכולות לקרות הבעיות הבאות:
- ירידה ברמת הדיוק: טוקנים לא רלוונטיים מדללים את תשומת הלב של המודל בחלון ההקשר. כשמידת תשומת הלב של המודל נחלשת, קשה לו להבחין בין הכלי הנכון לבין רעשי רקע.
- עלויות גבוהות יותר וחביון: בקשת משתמש אחת יכולה להפעיל כמה לולאות הסקה וביצועים של כלים שמוסתרים מהמשתמש. עלייה במספר הלולאות וההפעלות גורמת לעלייה מקבילה בעלות ובזמני התגובה של הכלי.
כדי לצמצם את הניפוח של הכלים, אפשר להטמיע את האסטרטגיות הבאות:
- הגבלת המורכבות של הכלי: הנה כמה המלצות לכתיבת הגדרות תמציתיות של כלים:
- במקום אובייקטים מורכבים עם קינון, כדאי להשתמש בסוגי נתונים פרימיטיביים.
- הגבלת הכלים כך שיכללו פחות מחמישה פרמטרים.
- כדי להגביל את נתיב ההחלטה של המודל, משתמשים ב-
enumsבמקום במחרוזות של טקסט חופשי.
- אספקת ערכות כלים מפורטות: פירוק שרתים מונוליטיים לערכות כלים מפורטות וממוקדות שמבוססות על מסלולים ספציפיים להמרת הלקוח. לדוגמה, אפשר להפריד בין שרת Cloud SQL גדול לבין ערכת כלים לאדמינים של סוכני DevOps וערכת כלים לנתונים של סוכני אפליקציות.
- הטמעה של גילוי נאות הדרגתי: עיצוב מערכות לפתיחה דינמית של הקשרים והיכולות הרלוונטיים רק כשצריך, במקום לטעון הכול מראש. כדי להטמיע גישה של חשיפה הדרגתית, אפשר להשתמש באסטרטגיות הבאות:
- תבנית של כלי חיפוש: כדי לצמצם את צריכת הטוקנים, כדאי להטמיע סוכן שמשתמש בכלי חיפוש יחיד כדי לטעון באופן דינמי רק את סכימת הכלי הרלוונטית.
- מיומנויות של סוכן: מיומנויות של סוכן הן פורמט סטנדרטי שמאפשר גילוי הדרגתי של הוראות, סקריפטים ומשאבים אחרים. כדי לצמצם את נפח ההקשר, מגדירים מיומנות של סוכן שמנחה את הסוכן לאחזר הקשר נוסף רק כשצריך.
- העברת משימות לכמה סוכנים: כדי לצמצם את חלון ההקשר של סוכן, אפשר להטמיע מערכת מרובת סוכנים שמשתמשת בסוכן מתאם כדי להעביר משימה ספציפית לסוכן משנה ייעודי. הגישה הזו מבטיחה שרק כלים רלוונטיים ייטענו, ושחלון ההקשר של סוכן המתאם יישאר תמציתי.
האסטרטגיות האלה לא סותרות זו את זו, ומומלץ לשלב ביניהן בהתאם לארכיטקטורה ולדרישות של עומס העבודה.
הזיכרון של הסוכן
היכולת של סוכן לזכור אינטראקציות קודמות היא חיונית כדי לספק חוויית שיחה עקבית ומועילה. כדי ליצור סוכנים עם מצב ועם מודעות להקשר, צריך להטמיע מנגנונים לזיכרון לטווח קצר ולזיכרון לטווח ארוך. בקטעים הבאים נסביר על אפשרויות העיצוב והשירותים של Google Cloudשבהם אפשר להשתמש כדי להטמיע זיכרון לטווח קצר ולטווח ארוך בסוכן.
זיכרון לטווח קצר
הזיכרון לטווח קצר מאפשר לסוכן לשמור על ההקשר בשיחה אחת מתמשכת. כדי להטמיע זיכרון לטווח קצר, צריך לנהל גם את הסשן וגם את המצב שמשויך אליו.
- Session: סשן הוא רצף השיחה בין משתמש לבין הנציג, מהאינטראקציה הראשונית ועד לסיום הדיאלוג.
- מצב: מצב הוא הנתונים שהסוכן משתמש בהם ואוסף אותם במהלך סשן ספציפי. נתוני המצב שנאספים כוללים את היסטוריית ההודעות שהמשתמש והסוכן החליפו ביניהם, את התוצאות של כל קריאות הכלים ומשתנים אחרים שהסוכן צריך כדי להבין את ההקשר של השיחה.
אלו אפשרויות להטמעת זיכרון לטווח קצר באמצעות ADK:
- אחסון בזיכרון: לצורך פיתוח, בדיקה או אפליקציות פשוטות שפועלות במופע יחיד, אפשר לאחסן את מצב הסשן ישירות בזיכרון של האפליקציה. הסוכן משתמש במבנה נתונים, כמו מילון או אובייקט, כדי לאחסן רשימה של צמדי מפתח-ערך, והוא מעדכן את הערכים האלה במהלך הסשן. עם זאת, כשמשתמשים באחסון בזיכרון, מצב הסשן לא נשמר. אם האפליקציה תופעל מחדש, כל היסטוריית השיחות תימחק.
ניהול מצב חיצוני: לאפליקציות בייצור שנדרשת בהן מדרגיות ומהימנות, מומלץ ליצור אפליקציית סוכן בלי שמירת מצב ולנהל את מצב הסשן בשירות אחסון חיצוני. בארכיטקטורה הזו, בכל פעם שאפליקציית הסוכן מקבלת בקשה, היא מאחזרת את מצב השיחה הנוכחי מהמאגר החיצוני, מעבדת את התור החדש ואז שומרת את המצב המעודכן בחזרה במאגר. העיצוב הזה מאפשר לכם להרחיב את האפליקציה באופן אופקי, כי כל מופע יכול לטפל בבקשה של כל משתמש. אפשרויות נפוצות לניהול מצב חיצוני כוללות את Memorystore for Redis, Firestore או סשנים של Gemini Enterprise Agent Platform.
אם משתמשים ב-ADK,
DatabaseSessionServiceדורש מסד נתונים רלציוני, כמו Cloud SQL.
זיכרון לטווח ארוך
זיכרון לטווח ארוך מספק לסוכן מאגר ידע קבוע שקיים בכל השיחות של משתמשים ספציפיים. הזיכרון לטווח ארוך מאפשר לסוכן לאחזר מידע חיצוני ולהשתמש בו, ללמוד מאינטראקציות קודמות ולספק תשובות מדויקות ורלוונטיות יותר.
אלה האפשרויות להטמעת זיכרון לטווח ארוך באמצעות ADK:
- אחסון בזיכרון: לצורך פיתוח ובדיקה, אפשר לאחסן את מצב הסשן ישירות בזיכרון של האפליקציה. הגישה הזו פשוטה להטמעה, אבל היא לא קבועה. אם האפליקציה מופעלת מחדש, היסטוריית השיחות נמחקת. בדרך כלל מטמיעים את התבנית הזו באמצעות ספק בזיכרון במסגרת פיתוח, כמו
InMemoryMemoryServiceשכלול ב-ADK לצורך בדיקה. - אחסון חיצוני: באפליקציות בסביבת הייצור, מומלץ לנהל את מאגר הידע של הסוכן בשירות אחסון מתמיד חיצוני. שירות אחסון חיצוני מבטיח שהידע של הסוכן יהיה עמיד, ניתן להרחבה ונגיש בכמה מופעים של האפליקציה. אפשר להשתמש בMemory Bank לאחסון לטווח ארוך עם כל זמן ריצה של סוכן ב- Google Cloud.
תבניות עיצוב של סוכנים
תבניות עיצוב של סוכנים הן גישות אדריכליות נפוצות לבניית אפליקציות מבוססות סוכנים. הדפוסים האלה מציעים מסגרת ייחודית לארגון הרכיבים של מערכת, לשילוב מודל ה-AI ולתיאום של סוכן יחיד או של כמה סוכנים כדי להשלים תהליך עבודה. כדי להבין איזו גישה הכי מתאימה לתהליך העבודה שלכם, צריך לקחת בחשבון את המורכבות של המשימות, את תהליך העבודה, את זמן האחזור, את הביצועים ואת דרישות העלות.
מערכת עם סוכן יחיד מסתמכת על יכולות החשיבה הרציונלית של מודל אחד כדי לפרש את בקשת המשתמש, לתכנן רצף של שלבים ולהחליט באילו כלים להשתמש. הגישה הזו היא נקודת התחלה יעילה שמאפשרת לכם להתמקד בשיפור הלוגיקה הבסיסית, בהנחיות ובהגדרות הכלים לפני שאתם מוסיפים מורכבות ארכיטקטונית. עם זאת, הביצועים של סוכן יחיד עלולים להידרדר ככל שהמשימות והמספר של הכלים גדלים במורכבות.
בבעיות מורכבות, מערכת מרובת סוכנים מתזמרת כמה סוכנים מומחים כדי להשיג יעד שסוכן יחיד לא יכול לנהל בקלות. העיצוב המודולרי הזה יכול לשפר את יכולת ההתאמה, את המהימנות ואת יכולת התחזוקה של המערכת. עם זאת, בהשוואה למערכת עם סוכן יחיד, היא גם מחייבת שיקולים נוספים לגבי הערכה, אבטחה ועלויות.
כשמפתחים מערכת מרובת סוכנים, צריך להטמיע אמצעי בקרה מדויקים לגישה לכל סוכן מומחה, לתכנן מערכת תזמור חזקה כדי להבטיח תקשורת מהימנה בין הסוכנים ולנהל את העלויות התפעוליות המוגדלות שנובעות מהתקורה החישובית של הפעלת כמה סוכנים. כדי לאפשר תקשורת בין סוכנים, משתמשים בפרוטוקול Agent2Agent (A2A) עם ADK. A2A הוא פרוטוקול פתוח סטנדרטי שמאפשר לסוכני AI לתקשר ולשתף פעולה בין פלטפורמות ומסגרות שונות, ללא קשר לטכנולוגיות הבסיסיות שלהם.
מידע נוסף על דפוסי עיצוב נפוצים של סוכנים ועל אופן הבחירה של דפוס בהתאם לדרישות של עומס העבודה זמין במאמר בחירת דפוס עיצוב למערכת AI אקטיבי.
מודלים של AI
אפליקציות מבוססות-סוכן מסתמכות על יכולות ההסקה וההבנה של מודל כדי לפעול כמתזמן המשימות הראשי. לתפקיד הליבה הזה של הסוכן, מומלץ להשתמש ב-Gemini Pro.
מודלים של Google, כמו Gemini, מספקים גישה למודלים הקנייניים הכי מתקדמים באמצעות API מנוהל. הגישה הזו מתאימה במיוחד לצמצום התקורה התפעולית. לעומת זאת, מודל פתוח שמתארח באופן עצמאי מספק את השליטה המעמיקה שנדרשת כשמבצעים כוונון עדין של נתונים קנייניים. עומסי עבודה עם דרישות מחמירות בנושא אבטחה ומיקום אחסון הנתונים גם דורשים מודל באירוח עצמי, כי הוא מאפשר להריץ את המודל ברשת שלכם.
כדי לשפר את הביצועים של הסוכן, אפשר לשנות את יכולות ההסקה של המודל. מודלים כמו Gemini Pro ו-Flash העדכניים כוללים תהליך חשיבה מובנה שמשפר את החשיבה הרציונלית ואת התכנון הרב-שלבי. לצורך ניפוי באגים ושיפורים, אתם יכולים לעיין בסיכומי המחשבות של המודל, או בגרסאות מסונתזות של המחשבות הפנימיות שלו, כדי להבין את תהליך החשיבה שלו. אתם יכולים לשלוט ביכולות החשיבה הרציונלית של המודל על ידי שינוי תקציב החשיבה, או מספר טוקנים של חשיבה, בהתאם למורכבות המשימה. תקציב חשיבה גבוה יותר מאפשר למודל לבצע תהליכי חשיבה רציונלית ותכנון מפורטים יותר לפני שהוא מספק תשובה. תקציב חשיבה גבוה יותר יכול לשפר את איכות התשובות, אבל הוא גם עלול להגדיל את זמן האחזור ואת העלות.
כדי לבצע אופטימיזציה של הביצועים והעלויות, כדאי להטמיע ניתוב מודלים כדי לבחור באופן דינמי את המודל המתאים ביותר לכל משימה על סמך המורכבות, העלות או דרישות זמן האחזור של המשימה. לדוגמה, אפשר להפנות בקשות פשוטות למודל שפה קטן (SLM) למשימות מובנות כמו יצירת קוד או סיווג טקסט, ולשמור מודל חזק ויקר יותר להסקת מסקנות מורכבת. אם מטמיעים ניתוב מודלים באפליקציה מבוססת-סוכנים, אפשר ליצור מערכת חסכונית שמספקת ביצועים גבוהים.
Google Cloud מאפשר גישה למבחר רחב של מודלים של Google, מודלים של שותפים ומודלים פתוחים שאפשר להשתמש בהם בארכיטקטורה של AI אקטיבי. מידע נוסף על המודלים שזמינים ועל אופן הבחירה של מודל שמתאים לצרכים שלכם זמין במאמר Model Garden ב-Gemini Enterprise Agent Platform.
זמן הריצה של המודל
זמן ריצה של מודל הוא הסביבה שמארחת את מודל ה-AI ומספקת אותו, ושמאפשרת לסוכן להשתמש ביכולות החשיבה הרציונלית שלו.
בחירת זמן ריצה של מודל
כדי לבחור את זמן הריצה הטוב ביותר כשמארחים מודלים של AI, אפשר להיעזר בהנחיות הבאות:
| תרחיש שימוש | זמן הריצה של המודל |
|---|---|
| אתם צריכים ממשק API מנוהל כדי להשתמש במודלים של Gemini, במודלים של שותפים, במודלים פתוחים או במודלים בהתאמה אישית עם אבטחה, יכולת הרחבה וכלים של AI גנרטיבי ברמה שמתאימה לארגונים. | Agent Platform |
| צריך לפרוס מודל פתוח או מותאם אישית שמבוסס על קונטיינר, ולתת עדיפות לפשטות ולחסכוניות של שרתים ללא ניהול, כדי להתמודד עם תנועה משתנה. | Cloud Run |
| אתם צריכים שליטה מקסימלית בתשתית כדי להפעיל מודל פתוח או מותאם אישית של קונטיינר על חומרה ייעודית, או כדי לעמוד בדרישות מורכבות של אבטחה ורשת. | GKE |
בקטעים הבאים מופיעה סקירה כללית של זמני הריצה של המודלים הקודמים, כולל תכונות עיקריות ושיקולי עיצוב. המאמר הזה מתמקד ב-Agent Platform, ב-Cloud Run וב-Google Kubernetes Engine (GKE). עם זאת, Google Cloud מציעה שירותים אחרים שאולי תרצו להשתמש בהם בזמן הריצה של המודל:
- Gemini API: Gemini API מיועד למפתחים שזקוקים לגישה מהירה וישירה למודלים של Gemini, בלי תכונות השליטה הארגוניות שמערכות מורכבות מבוססות-סוכנים דורשות בדרך כלל.
- Compute Engine: Compute Engine הוא מוצר של תשתית כשירות (IaaS) שמתאים לאפליקציות מדור קודם. היא מוסיפה תקורה תפעולית משמעותית בהשוואה לסביבות זמן ריצה מודרניות שמבוססות על קונטיינרים.
מידע נוסף על התכונות שמבדילות בין כל האפשרויות של שירותי זמן ריצה של מודלים זמין במאמר תשתית לאירוח מודלים.
Agent Platform
Agent Platform מספקת סביבה מנוהלת ללא שרת (serverless) שבה מתארחים מודלים של AI. אתם יכולים להכניס לשימוש בסביבת הייצור ולכוונן מודלים של Google, מודלים של שותפים ומודלים פתוחים באמצעות API מאובטח וניתן להרחבה. הגישה הזו מאפשרת לכם להתמקד בשילוב של אינטליגנציית מודלים באפליקציות שלכם, בלי שתצטרכו לדאוג לניהול התשתית.
כשמשתמשים ב-Agent Platform כזמן ריצה של מודל, התכונות העיקריות והשיקולים כוללים את הדברים הבאים:
- שליטה בתשתית: ממשק API מנוהל מלא למודלים שלכם. Google מנהלת את התשתית הבסיסית.
- אבטחה: הגדרות ברירת מחדל מנוהלות של אבטחה ותקנים של אישורי תאימות מספיקים לצרכים שלכם. כדי לספק הגנה על פרומפטים ותשובות וכדי להבטיח שיטות לפיתוח אחראי של AI, אפשר לשלב את הגנה מוגברת על המודל ב-Agent Platform.
- זמינות המודלים: גישה למבחר רחב של מודלים, כולל מודלי Gemini העדכניים ביותר, דרך API מנוהל.
- עלות: מודל תמחור של תשלום לפי שימוש, שמתרחב בהתאם לתנועה באפליקציה. מידע נוסף זמין במאמר בנושא עלות הפיתוח והפריסה של מודלים של AI בפלטפורמת הסוכנים.
Cloud Run
Cloud Run מספק סביבת ריצה ללא שרת שמארחת את המודלים שלכם בתוך קונטיינרים בהתאמה אישית. Cloud Run מציע איזון בין הפשטות המנוהלת באופן מלא של Agent Platform לבין השליטה המעמיקה בתשתית של GKE. הגישה הזו מתאימה במיוחד כשצריך גמישות כדי להריץ את המודל בסביבה מבוססת-קונטיינרים בלי לנהל שרתים או אשכולות.
כשמשתמשים ב-Cloud Run כזמן ריצה של מודל, התכונות והשיקולים העיקריים כוללים את הדברים הבאים:
- שליטה בתשתית: אפשר להריץ כל מודל בקונטיינר בהתאמה אישית, שמספק שליטה מלאה בסביבת התוכנה, בזמן שהפלטפורמה מנהלת את התשתית הבסיסית ללא שרת (serverless).
- אבטחה: מספקת אבטחה באמצעות מופעי מחשוב זמניים ומבודדים, ומאפשרת חיבורים מאובטחים למשאבים פרטיים באמצעות תעבורת נתונים יוצאת (egress) ישירה של VPC או מחבר של חיבור לרשת (VPC) מאפליקציית serverless. מידע נוסף זמין במאמר רשת פרטית ו-Cloud Run.
- זמינות המודל: אפשר להכניס לשימוש בסביבת הייצור מודלים פתוחים כמו Gemma או להכניס לשימוש בסביבת הייצור מודלים מותאמים אישית משלכם. אי אפשר לארח או להכניס לשימוש בסביבת הייצור מודלים של Gemini ב-Cloud Run.
- Cost: מודל תמחור לפי שימוש, לפי בקשה, שמתרחב עד לאפס, מה שהופך אותו לחסכוני מאוד למודלים עם תנועה לא סדירה או משתנה. מידע נוסף זמין במאמר בנושא תמחור של Cloud Run.
GKE
GKE מספק את השליטה והגמישות הכי גדולות לאירוח מודלים של AI. כדי להשתמש בגישה הזו, מריצים את המודלים בקונטיינרים באשכול GKE שמגדירים ומנהלים. GKE היא הבחירה האידיאלית כשצריך להריץ מודלים על חומרה ייעודית, למקם אותם יחד עם האפליקציות כדי להשיג זמן אחזור מינימלי או כשנדרש ניהול גרנולרי של כל היבט בסביבת ההגשה.
כשמשתמשים ב-GKE כזמן ריצה של מודל, התכונות העיקריות והשיקולים כוללים את הדברים הבאים:
- שליטה בתשתית: מאפשרת שליטה מקסימלית ומפורטת בסביבת ההגשה כולה, כולל הגדרות של צמתים, מאיצי מכונה מיוחדים ותוכנת פרסום המודל הספציפית.
- אבטחה: מאפשרת את הרמה הגבוהה ביותר של אבטחה ובידוד נתונים, כי אפשר להריץ מודלים באופן מלא בתוך הרשת ולהחיל מדיניות אבטחה מפורטת של Kubernetes. כדי לסנן תעבורת נתונים אל אשכול GKE וממנו ולהגן על כל האינטראקציות עם מודלים של AI, אפשר לשלב את הגנה מוגברת על המודל עם GKE .
- זמינות המודל: אפשר להפעיל מודלים פתוחים כמו Gemma, או להפעיל מודלים מותאמים אישית משלכם. אי אפשר לארח או להכניס לשימוש בסביבת הייצור מודלים של Gemini ב-GKE.
- Cost: כולל מודל עלויות שמבוסס על משאבי מחשוב ומשאבי אשכולות בסיסיים שאתם צורכים, ולכן הוא מותאם במיוחד לעומסי עבודה צפויים בנפח גבוה כשמשתמשים בהנחות תמורת התחייבות לשימוש (CUD). מידע נוסף זמין במאמר בנושא תמחור של Google Kubernetes Engine.
זמן הריצה של הסוכן
כדי לארח ולפרוס את האפליקציה מבוססת הסוכן, צריך לבחור זמן ריצה של סוכן. השירות הזה מריץ את קוד האפליקציה שלכם – הלוגיקה העסקית והתיאום שאתם כותבים כשאתם משתמשים במסגרת לפיתוח סוכנים. מסביבת זמן הריצה הזו, האפליקציה שלכם מבצעת קריאות API למודלים שמתארחים ומנוהלים על ידי סביבת זמן הריצה של המודל שבחרתם.
בחירת זמן ריצה של סוכן
כדי לבחור את זמן הריצה כשמארחים סוכני AI, צריך לפעול לפי ההנחיות הבאות:
| תרחיש שימוש | זמן הריצה של הסוכן |
|---|---|
| האפליקציה שלכם היא סוכן Python ונדרשת חוויה מנוהלת מלאה עם תקורה תפעולית מינימלית. | Agent Runtime on Gemini Enterprise Agent Platform |
| האפליקציה שלך מופעלת בתוך קונטיינר, ונדרשת לה יכולת שינוי גודל מבוססת-אירועים בלי שרתים, עם גמישות בשפה. | Cloud Run |
| האפליקציה שלכם מופעלת בתוך קונטיינר, יש לה דרישות מורכבות של מצב (stateful) והיא צריכה הגדרה מדויקת של התשתית. | GKE |
אם אתם כבר מנהלים אפליקציות ב-Cloud Run או ב-GKE, אתם יכולים להשתמש באותה פלטפורמה לעומס העבודה של הסוכן כדי להאיץ את הפיתוח ולפשט את הפעולות לטווח הארוך.
בקטעים הבאים מופיעה סקירה כללית של כל זמן ריצה של סוכן, כולל תכונות מרכזיות ושיקולי תכנון.
Agent Runtime
Agent Runtime הוא זמן ריצה מנוהל לחלוטין שניתן להשתמש בו כדי לפרוס, להפעיל ולשנות את גודלן של אפליקציות מבוססות-סוכנים. Agent Runtime מבצע הפשטה של התשתית הבסיסית, מה שמאפשר לכם להתמקד בלוגיקה של הסוכן במקום בפעולות.
התכונות ושיקולים לגבי Agent Runtime:
- גמישות בשפת התכנות ובמסגרת העבודה: אפשר לפתח סוכנים ב-Python עם כל מסגרות העבודה הנתמכות.
- פרוטוקולי תקשורת: ניהול של סוכנים וכלים שמשתמשים ב-MCP וב-A2A. Agent Runtime מנהל ביעילות את זמן הריצה של הרכיבים האלה, אבל הוא לא תומך באירוח של שרתי MCP בהתאמה אישית.
- זיכרון: מספק יכולות זיכרון מובנות ומנוהלות, כך שלא צריך להגדיר מסדי נתונים חיצוניים לזיכרון הליבה של הסוכן.
דרישה אפשרויות זמינות זיכרון לטווח קצר סשנים ב-Agent Platform זיכרון לטווח ארוך Memory Bank חיפוש ואחזור של מסד נתונים - יכולת הרחבה: המערכת מתרחבת אוטומטית כדי לעמוד בדרישות של עומס העבודה של הסוכן, כך שלא צריך לבצע הגדרה ידנית.
- ניראות (observability): מספקת רישום ביומן, מעקב וגישוש משולבים באמצעות שירותי Google Cloud Observability.
- אבטחה: מספקת את האמינות, יכולת ההתאמה לעומס והתאימות הבאות ברמת הארגון:
- זהות שירות מובנית לקריאות מאובטחות ומאומתות ל-Google Cloud APIs.
- להריץ קוד בארגז חול מאובטח, מבודד ומנוהל באמצעות הפעלת קוד בפלטפורמת Gemini Enterprise Agent.
- הגנה על הנתונים באמצעות מפתח הצפנה בניהול הלקוח (CMEK) משלכם ב-Secret Manager.
- כדי למנוע קריאות לא רצויות לרשת, צריך להגביל את הרשאות IAM ולהשתמש בכללי חומת אש של VPC.
מידע על תכונות האבטחה של Agent Runtime זמין במאמר בנושא אבטחה ב-Enterprise.
הסביבה Agent Runtime מקצרת את הדרך להפקה כי היא מספקת סביבה מנוהלת שנוצרה במיוחד לטיפול בהרבה היבטים מורכבים כשמפעילים סוכנים, כמו ניהול מחזור החיים וההקשר. Agent Runtime פחות מתאים לתרחישי שימוש שבהם נדרש התאמה אישית נרחבת של סביבת המחשוב או שנדרשות שפות תכנות שאינן Python. עבור עומסי עבודה עם דרישות אבטחה מחמירות לניהול תלויות פרטי, Cloud Run ו-GKE מציעים נתיב הגדרה ישיר יותר שמבוסס על IAM.
Cloud Run
Cloud Run היא פלטפורמה מנוהלת ללא שרת (serverless) שמאפשרת להריץ את קוד האפליקציה של הסוכן בקונטיינר ללא שמירת מצב. Cloud Run הוא פתרון אידיאלי אם רוצים לפרוס את כל אפליקציית הסוכן, רכיבים נפרדים או כלים בהתאמה אישית כנקודות קצה של HTTP שאפשר להתאים לעומס, בלי לנהל את התשתית הבסיסית.
אלה תכונות ושיקולים לגבי Cloud Run:
- גמישות בשפת התכנות ובמסגרת העבודה: כשיוצרים חבילה של האפליקציה במאגר, אפשר לפתח סוכנים בכל שפת תכנות ובכל מסגרת עבודה.
- פרוטוקולי תקשורת: תיאום בין סוכנים וכלים שמשתמשים ב-MCP וב-A2A. אירוח של לקוחות ושרתים של MCP עם תעבורת HTTP שניתנת להזרמה ב-Cloud Run.
- זיכרון: מכונות Cloud Run הן חסרות מצב (stateless),
כלומר מכונה מאבדת את כל הנתונים בזיכרון אחרי שהיא מסיימת את הפעולה. כדי להטמיע זיכרון קבוע, צריך לקשר את השירות לשירות אחסון מנוהל שלGoogle Cloud :
דרישה אפשרויות זמינות זיכרון לטווח קצר זיכרון לטווח ארוך - Firestore
- Memory Bank עם Cloud Run
חיפוש ואחזור של מסד נתונים - Cloud SQL
- AlloyDB ל-PostgreSQL
- יכולת הרחבה: התאמה אוטומטית של מספר המכונות בהתאם לתעבורת הנתונים הנכנסת, וגם הקטנה של מספר המכונות עד לאפס. התכונה הזו עוזרת להפוך את Cloud Run לחסכוני עבור אפליקציות עם עומסי עבודה משתנים.
- ניראות (observability): מספקת רישום ביומן, מעקב וניתוח משולבים באמצעות שירותי Google Cloud Observability. מידע נוסף מופיע במאמר סקירה כללית על מעקב ורישום ביומן.
- אבטחה: מספקת את אמצעי האבטחה הבאים לסוכנים שלכם:
- שירות זהות מובנה לביצוע קריאות מאובטחות ומאומתות ל-Google Cloud APIs.
- הפעלת קוד שלא נבדק בסביבה מאובטחת באמצעות סביבת ארגז החול של Cloud Run או באמצעות Agent Platform Code Execution.
- כדי לאחסן מידע רגיש שמשמש את Cloud Run, צריך להגדיר סודות ב-Secret Manager.
- כדי למנוע שיחות לא רצויות ברשת, מגבילים את הרשאות IAM ומשתמשים בכללי חומת אש של VPC.
Cloud Run מציע פשטות תפעולית משמעותית וחסכוניות כי הוא מבטל את הצורך בניהול תשתית. עם זאת, בגלל האופי חסר המצב של Cloud Run, צריך להשתמש בשירות אחסון כדי לנהל את ההקשר בתהליך עבודה רב-שלבי. בנוסף, הזמן הקצוב לתפוגה של בקשות בשירותי Cloud Run הוא עד שעה אחת, מה שעשוי להגביל משימות ארוכות של סוכנים.
GKE
Google Kubernetes Engine הוא שירות מנוהל של תזמור קונטיינרים, שמאפשר שליטה גרנולרית בארכיטקטורה ובתשתית של אפליקציות מבוססות-סוכנים. GKE מתאים למערכות מורכבות שמבוססות על סוכנים ודורשות יכולות חזקות ברמת הייצור, או אם אתם כבר לקוחות של GKE ואתם רוצים להטמיע תהליך עבודה שמבוסס על סוכנים בנוסף לאפליקציה הקיימת.
אלה תכונות ושיקולים שזמינים ב-GKE:
- גמישות בשפת התכנות ובמסגרת העבודה: כשיוצרים חבילה של האפליקציה במאגר, אפשר לפתח סוכנים בכל שפת תכנות ובכל מסגרת עבודה.
- פרוטוקולי תקשורת: ניהול של סוכנים וכלים שמשתמשים ב-MCP וב-A2A. אירוח של לקוחות ושרתים של MCP ב-GKE כשמארזים אותם כקונטיינרים.
- זיכרון: פודים של GKE הם זמניים.
עם זאת, אתם יכולים ליצור סוכנים עם מצב (stateful) וזיכרון מתמשך באמצעות משאבים בתוך האשכול או באמצעות חיבור לשירותים חיצוניים:
דרישה אפשרויות זמינות זיכרון לטווח קצר זיכרון לטווח ארוך - Firestore
- Memory Bank with GKE
חיפוש ואחזור של מסד נתונים - StatefulSets וPersistent Volumes לאחסון עמיד באשכול.
- Cloud SQL
- AlloyDB ל-PostgreSQL
- יכולת מדרגיות: אשכולות GKE מספקים באופן אוטומטי ומתאימים את גודל מאגרי הצמתים לצרכים של עומס העבודה.
- Observability: רישום ביומן, מעקב וניתוח משולבים ברמת האשכול, הצומת וה-Pod באמצעות Google Cloud Observability. כדי לאסוף מדדים מוגדרים של צד שלישי ומדדים שהוגדרו על ידי המשתמש ואז לשלוח אותם ל-Cloud Monitoring, אפשר גם להשתמש בשירות מנוהל של Google Cloud ל-Prometheus. מידע נוסף זמין במאמר סקירה כללית על יכולות התצפית ב-GKE.
- אבטחה: מספקת אמצעי בקרה מדויקים לאבטחת הסוכנים.
- משתמשים באיחוד שירותי אימות הזהות של עומסי עבודה ל-GKE כדי לבצע אימות מאובטח ל-Google Cloud APIs.
- בידוד קוד לא מהימן באמצעות GKE Sandbox.
- אחסון נתונים רגישים שמשמשים את אשכולות GKE ב-Secret Manager.
- כדי למנוע קריאות לא רצויות לרשת, צריך להגביל את הרשאות IAM ולהשתמש בכללי חומת אש של VPC ובמדיניות רשת.
GKE מספק שליטה וגמישות מקסימליות, שמאפשרות לכם להפעיל סוכנים מורכבים עם שמירת מצב. עם זאת, אמצעי הבקרה הזה מוסיף מורכבות והוצאות תקורה משמעותיות. אתם צריכים להגדיר ולנהל את אשכול Kubernetes, כולל מאגרי צמתים, רישות ומדיניות התאמה לעומס. זה דורש יותר מומחיות ומאמץ פיתוח מאשר פלטפורמה בלי שרת.
המאמרים הבאים
- כלים לסוכנים:
- הזיכרון של הסוכן:
- דפוסי עיצוב של סוכנים:
- זמן ריצה של הסוכן:
- מקורות מידע נוספים על AI אקטיבי ב Google Cloud:
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: סמנתה הי | כותבת טכנית
תורמי תוכן אחרים:
- אמינה מנסור | ראש צוות הערכות של Cloud Platform
- Amit Maraj | Developer Relations Engineer
- Casey West | Architecture Advocate, Google Cloud
- Jack Wotherspoon | אחראי קשרי מפתחים
- ג'ו פרננדז | כותב טכני
- Joe Shirey | Cloud Developer Relations Manager
- קרל ויינמייסטר | Director of Cloud Product Developer Relations
- קומאר דהנגופאל | מפתח פתרונות חוצי-מוצרים
- קורטיס ואן גנט | מהנדס תוכנה בכיר
- Lisa Shen | Senior Outbound Product Manager, Google Cloud
- מנדי גרובר | ראש תחום מרכז הארכיטקטורה
- מייגן או'קיף | אחראית קשרי מפתחים
- אוליבייה בורז'ואה | מהנדס קשרי מפתחים
- Polong Lin | Developer Relations Engineering Manager
- ריאן פיי | מנהל מוצר, Google Cloud
- שיר מאיר לדור | מנהלת הנדסה של קשרי מפתחים
- Vlad Kolesnikov | Developer Relations Engineer