בחירת רכיבי הארכיטקטורה של ה-AI האגנטי

Last reviewed 2026-04-21 UTC

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

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

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

למידע על פתרונות חלופיים שאינם AI אקטיבי, עיינו במקורות המידע הבאים:

סקירה כללית על ארכיטקטורת הנציגים

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

התרשים הבא מציג סקירה כללית ברמה גבוהה של רכיבי הארכיטקטורה של מערכת מבוססת-סוכנים:

רכיבי הארכיטקטורה של מערכת סוכנית.

הארכיטקטורה של מערכת מבוססת-סוכנים כוללת את הרכיבים הבאים:

  • Frontend framework: אוסף של רכיבים, ספריות וכלים מוכנים מראש שמשמשים לבניית ממשק המשתמש (UI) של האפליקציה.
  • סביבת פיתוח לסוכנים: הסביבות והספריות שבהן אתם משתמשים כדי ליצור ולבנות את הלוגיקה של הסוכן.
  • כלים של הנציג: אוסף הכלים, כמו ממשקי API, שירותים ופונקציות, שמאחזרים נתונים ומבצעים פעולות או עסקאות.
  • זיכרון הסוכן: המערכת שבה הסוכן משתמש כדי לאחסן מידע ולשלוף אותו.
  • תבניות עיצוב של סוכנים: גישות ארכיטקטוניות נפוצות לבניית אפליקציות מבוססות-סוכנים.
  • Agent runtime: סביבת המחשוב שבה פועלת הלוגיקה של האפליקציה של ה-Agent.
  • מודלי AI: מנוע החשיבה הרציונלית העיקרי שמפעיל את יכולות קבלת ההחלטות של הסוכן.
  • סביבת זמן ריצה של המודל: התשתית שמארחת את מודל ה-AI ומספקת אותו.

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

Frontend framework

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

כדאי להביא בחשבון את הקטגוריות הבאות של מסגרות:

  • סביבות פיתוח ליצירת אב טיפוס וכלים פנימיים: לפיתוח מהיר, הדגמות פנימיות ואפליקציות להוכחת היתכנות, כדאי לבחור סביבות פיתוח שמתמקדות בחוויית המפתחים ובמהירות. בדרך כלל, המסגרות האלה מעדיפות מודל פשוט וסינכרוני שנקרא מודל בקשה-תגובה. מודל של בקשה-תגובה מאפשר לכם ליצור ממשק משתמש פונקציונלי עם מינימום קוד וקצה עורפי פשוט יותר בהשוואה לסביבת ייצור. הגישה הזו אידיאלית לבדיקה מהירה של הלוגיקה של הנציג ושילובי הכלים, אבל יכול להיות שהיא לא תתאים לאפליקציות שפונות לציבור ודורשות אינטראקציות בזמן אמת ורמה גבוהה של התאמה לעומס. מסגרות נפוצות בקטגוריה הזו כוללות את Mesop ו-Gradio.
  • סביבות פיתוח לייצור: לאפליקציות שניתנות להתאמה, רספונסיביות ועשירות בתכונות למשתמשים חיצוניים, בחרו סביבת פיתוח שמאפשרת רכיבים בהתאמה אישית. המסגרות האלה דורשות ארכיטקטורת קצה עורפי שיכולה לתמוך בחוויית משתמש מודרנית. מסגרת לסביבת ייצור צריכה לכלול תמיכה בפרוטוקולים של סטרימינג, עיצוב API בלי שמירת מצב ומערכת זיכרון חיצונית חזקה לניהול מצב השיחה בכמה סשנים של משתמשים. מסגרות נפוצות לאפליקציות בסביבת ייצור כוללות את Streamlit,‏ React ו-Flutter AI Toolkit.

כדי לנהל את התקשורת בין המסגרות האלה לבין סוכן ה-AI, אתם יכולים להשתמש בפרוטוקול Agent–User Interaction‏ (AG-UI). ‫AG-UI הוא פרוטוקול פתוח שמאפשר לסוכני AI בקצה העורפי (backend) לתקשר עם מסגרת הקצה הקדמי (frontend). ‫AG-UI אומר ל-frontend framework מתי לעבד את התשובה של הסוכן, לעדכן את מצב האפליקציה או להפעיל פעולה בצד הלקוח. כדי ליצור אפליקציות AI אינטראקטיביות, שלבו את AG-UI עם הערכה לפיתוח סוכנים (ADK). מידע נוסף על ADK מופיע בקטע הבא, "מסגרות לפיתוח סוכנים".

סביבות פיתוח של סוכנים

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

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

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

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

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

כלים של הסוכן

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

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

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

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

כלים מובנים

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

MCP

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

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

היתרונות של MCP:

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

אתם יכולים להטמיע שרתי MCP במערכת ה-AI האקטיבי שלכם בדרכים הבאות:

  • ‫שרתי Google Cloud MCP: כדי להתחבר לשירותי Google ו- Google Cloud , מתחברים לשרתי MCP מרוחקים שמנוהלים באופן מלא על ידי Google. השרתים האלה משפרים את התשתית הקיימת שלכם, כי הם מספקים שכבה אחידה בכל השירותים של Google ושל Google Cloud שאתם משתמשים בהם. השרתים האלה מספקים התאמה לעומס (scaling) ללא שמירת מצב (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 Hub, הנציגים יכולים להתחבר לנתונים באופן מיידי באמצעות קריאות HTTP ישירות, מחברים מובְנים, ממשקי API בהתאמה אישית שרשומים ב-Hub או גישה ישירה למקורות נתונים ב- Google Cloud . כך הנציגים יכולים לגשת מיד למידע שהם צריכים, בלי להסתבך עם בניית צינורות עיבוד נתונים מותאמים אישית לטעינה ולשילוב של נתונים.

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

כלי לפונקציות בהתאמה אישית

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

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

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

ריבוי כלים

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

כשסוכן AI עמוס בכלים, יכולות להתרחש הבעיות הבאות:

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

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

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

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

הזיכרון של הסוכן

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

זיכרון לטווח קצר

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

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

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

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

  • ניהול מצב חיצוני: באפליקציות בסביבת ייצור שדורשות מדרגיות ואמינות, מומלץ ליצור אפליקציית סוכן בלי שמירת מצב ולנהל את מצב הסשן בשירות אחסון חיצוני. בארכיטקטורה הזו, בכל פעם שאפליקציית הנציג מקבלת בקשה, היא מאחזרת את מצב השיחה הנוכחי מהמאגר החיצוני, מעבדת את התור החדש ואז שומרת את המצב המעודכן בחזרה במאגר. העיצוב הזה מאפשר לשנות את קנה המידה של האפליקציה באופן אופקי, כי כל מכונה יכולה לשרת כל בקשה של משתמש. אפשרויות נפוצות לניהול מצב חיצוני כוללות את Memorystore for Redis,‏ Firestore או סשנים של Gemini Enterprise Agent Platform.

    אם אתם משתמשים ב-ADK, DatabaseSessionService דורש מסד נתונים רלציוני, כמו Cloud SQL.

זיכרון לטווח ארוך

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

אלה האפשרויות להטמעת זיכרון לטווח ארוך באמצעות ADK:

  • אחסון בזיכרון: למטרות פיתוח ובדיקה, אתם יכולים לאחסן את מצב הסשן ישירות בזיכרון של האפליקציה. קל ליישם את הגישה הזו, אבל היא לא עקבית. אם האפליקציה מופעלת מחדש, היסטוריית השיחות נמחקת. בדרך כלל מטמיעים את התבנית הזו באמצעות ספק בזיכרון במסגרת פיתוח, כמו InMemoryMemoryService שכלול ב-ADK לבדיקה.
  • אחסון חיצוני: באפליקציות בסביבת ייצור, כדאי לנהל את מאגר הידע של הנציג בשירות אחסון מתמיד חיצוני. שירות אחסון חיצוני מבטיח שהידע של הנציג יהיה עמיד, ניתן להתאמה ונגיש בכמה מופעים של האפליקציה. אפשר להשתמש ב-Memory Bank לאחסון לטווח ארוך בכל Agent Runtime ב- Google Cloud.

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

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

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

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

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

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

מודלי AI

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

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

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

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

‫Google Cloud מספק גישה למגוון רחב של מודלים של Google, מודלים של שותפים ומודלים פתוחים שאפשר להשתמש בהם בארכיטקטורה של הסוכנים. במאמר Model Garden ב-Gemini Enterprise Agent Platform מוסבר אילו מודלים זמינים ואיך לבחור מודל שמתאים לצרכים שלכם.

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

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

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

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

תרחיש לדוגמה זמן הריצה של המודל
אתם צריכים API מנוהל לחלוטין כדי להכניס לשימוש בסביבת הייצור מודלים של Gemini, מודלים של שותפים, מודלים פתוחים או מודלים בהתאמה אישית עם אבטחה, התאמה לעומס (scaling) וכלי AI גנרטיבי ברמה שמתאימה לארגונים. Agent Platform
אתם צריכים לפרוס מודל פתוח או מודל מותאם אישית בקונטיינר, ולתת עדיפות לפשטות של בלי שרת (serverless) ולחיסכון בעלויות בתנועה משתנה. Cloud Run
אתם צריכים שליטה מקסימלית בתשתית כדי להריץ מודל פתוח או מודל בקונטיינר בהתאמה אישית על חומרה ייעודית, או כדי לעמוד בדרישות אבטחה ורשת מורכבות. GKE

בקטעים הבאים מפורטים זמני הריצה של המודלים הקודמים, כולל תכונות עיקריות ושיקולי תכנון. המאמר הזה מתמקד ב-Agent Platform, ב-Cloud Run וב-Google Kubernetes Engine ‏ (GKE). עם זאת,ב- Google Cloud יש שירותים אחרים שאפשר להשתמש בהם כסביבת זמן ריצה של מודל:

  • ‫Gemini API: מיועד למפתחים שצריכים גישה מהירה וישירה למודלים של Gemini, בלי תכונות הפיקוח הארגוניות שלרוב נדרשות במערכות מורכבות של סוכני AI.
  • ‫Compute Engine: מוצר של תשתית כשירות (IaaS) שמתאים לאפליקציות מדור קודם. היא מוסיפה תקורה תפעולית משמעותית בהשוואה לסביבות הרצה מודרניות שמבוססות על קונטיינרים.

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

Agent Platform

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

כשמשתמשים ב-Agent Platform כסביבת זמן ריצה של מודלים, התכונות העיקריות והשיקולים כוללים את הדברים הבאים:

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

Cloud Run

ב-Cloud Run יש סביבת זמן ריצה ללא שרת (serverless) שמארחת את המודלים בתוך קונטיינרים בהתאמה אישית. ‫Cloud Run מציע איזון בין הפשטות של פלטפורמת Agent Platform שמנוהלת באופן מלא לבין השליטה העמוקה בתשתית של GKE. הגישה הזו מתאימה במיוחד כשצריך את הגמישות להריץ את המודל בסביבה בקונטיינר בלי לנהל שרתים או אשכולות.

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

  • שליטה בתשתית: אתם יכולים להריץ כל מודל בקונטיינר בהתאמה אישית, שנותן לכם שליטה מלאה בסביבת התוכנה, בזמן שהפלטפורמה מנהלת את התשתית הבסיסית ללא שרת (serverless).
  • אבטחה: אבטחה באמצעות מכונות מחשוב זמניות ומבודדות, וחיבורים מאובטחים למשאבים פרטיים באמצעות תעבורת נתונים יוצאת ישירה ל-VPC או מחבר של חיבור לרשת VPC מאפליקציית serverless. למידע נוסף, קראו את המאמר רשתות פרטיות ו-Cloud Run.
  • זמינות המודל: אתם יכולים להשתמש במודלים פתוחים כמו Gemma או במודלים בהתאמה אישית משלכם. אי אפשר לארח או להציג מודלים של Gemini ב-Cloud Run.
  • עלות: מודל תמחור מבוסס-בקשות, שבו משלמים לפי שימוש וצמצום הפעולה לאפס. המודל הזה חסכוני מאוד למודלים עם תנועה משתנה או לא סדירה. למידע נוסף, קראו את המאמר תמחור של Cloud Run.

GKE

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

כשמשתמשים ב-GKE כסביבת זמן ריצה של מודל, אלה התכונות והשיקולים העיקריים:

  • שליטה בתשתית: שליטה מקסימלית ומפורטת בכל סביבת פרסום המודל, כולל הגדרות של צמתים, מאיצי מכונות ייעודיים ותוכנה ספציפית לפרסום מודלים.
  • אבטחה: מאפשרת את הרמה הגבוהה ביותר של אבטחה ובידוד נתונים, כי אפשר להריץ מודלים לגמרי בתוך הרשת ולהחיל מדיניות אבטחה מפורטת של Kubernetes. כדי לסנן את התנועה אל אשכול GKE וממנו, ולהגן על כל האינטראקציות עם מודלי ה-AI, אתם יכולים לשלב את Model Armor עם GKE .
  • זמינות המודל: אתם יכולים להשתמש במודלים פתוחים כמו Gemma, או במודלים בהתאמה אישית משלכם. אי אפשר לארח או להציג מודלים של Gemini ב-GKE.
  • עלות: מודל עלות שמבוסס על משאבי המחשוב והאשכולות שאתם צורכים, ולכן הוא מותאם מאוד לעומסי עבודה צפויים בנפח גבוה כשמשתמשים בהנחות תמורת התחייבות לשימוש (CUD). למידע נוסף, קראו את התמחור של Google Kubernetes Engine.

Agent runtime

כדי לארח ולפרוס את האפליקציה הסוכנית, אתם צריכים לבחור Agent Runtime. השירות הזה מריץ את קוד האפליקציה – הלוגיקה העסקית והתזמור שאתם כותבים כשאתם משתמשים בסביבת פיתוח של נציגים. מסביבת זמן הריצה הזו, האפליקציה מבצעת קריאות ל-API למודלים שסביבת זמן הריצה של המודל שבחרתם מארחת ומנהלת.

בחירת Agent Runtime

כדי לבחור את סביבת זמן הריצה לאירוח של סוכני ה-AI, אתם יכולים להיעזר בהנחיות הבאות:

תרחיש לדוגמה Agent runtime
האפליקציה שלכם היא סוכן Python והיא דורשת חוויה מנוהלת באופן מלא עם מינימום תקורה תפעולית. ‫Agent Runtime ב-Gemini Enterprise Agent Platform
האפליקציה שלכם מבוססת-קונטיינרים ודורשת התאמה לעומס (scaling) מבוססת-אירועים בלי שרת (serverless), עם גמישות בשפות. Cloud Run
האפליקציה שלכם מבוססת-קונטיינרים, יש לה דרישות מורכבות של שמירת מצב (stateful) והיא צריכה הגדרת תשתית מפורטת. GKE

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

בקטעים הבאים מפורטת סקירה כללית של כל Agent Runtime, כולל תכונות עיקריות ושיקולי תכנון.

Agent Runtime

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

אלה התכונות והשיקולים שקשורים ל-Agent Runtime:

  • גמישות בשפת התכנות ובמסגרת: אתם יכולים לפתח סוכנים ב-Python באמצעות כל אחת ממסגרות התכנות הנתמכות.
  • פרוטוקולי תקשורת: תזמור של סוכנים וכלים שמשתמשים ב-MCP וב-A2A. ‫Agent Runtime מנהל ביעילות את סביבת זמן הריצה של הרכיבים האלה, אבל הוא לא תומך באירוח של שרתי MCP בהתאמה אישית.

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

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

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

‫Agent Runtime מאיץ את המעבר לסביבת הייצור כי הוא מספק סביבה מנוהלת ייעודית שמטפלת בהרבה היבטים מורכבים של הפעלת סוכנים, כמו ניהול מחזור החיים וההקשר. ‫Agent Runtime פחות מתאים לתרחישי שימוש שדורשים התאמה אישית נרחבת של סביבת המחשוב או שפות תכנות אחרות מלבד Python. לעומסי עבודה עם דרישות אבטחה מחמירות לניהול של יחסי תלות פרטיים, Cloud Run ו-GKE מציעים נתיב הגדרה ישיר יותר שמבוסס על IAM.

Cloud Run

‫Cloud Run היא פלטפורמה מנוהלת בלי שרת (serverless) שמאפשרת להריץ את קוד האפליקציה של הנציג בקונטיינר ללא שמירת מצב (stateless). השירות Cloud Run מתאים במיוחד כשרוצים לפרוס את כל אפליקציית הנציג, רכיבים ספציפיים או כלים בהתאמה אישית כנקודות קצה (endpoints) של HTTP שניתנות להתאמה לעומס, בלי לנהל את התשתית הבסיסית.

אלה התכונות והשיקולים של Cloud Run:

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

GKE

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

אלה התכונות והשיקולים שזמינים ב-GKE:

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

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

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

מחברת: סמנתה הי | כותבת טכנית

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