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

Last reviewed 2026-04-21 UTC

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

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

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

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

סקירה כללית של ארכיטקטורת הסוכן

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

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

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

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

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

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

Frontend framework

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

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

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

ריבוי טכנולוגיה

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

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

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

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

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

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

זיכרון הסוכן

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

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

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

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

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

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

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

    אם משתמשים ב-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 Vertex AI מאפשר גישה למגוון רחב של מודלים של Google, מודלים של שותפים ומודלים פתוחים שאפשר להשתמש בהם בארכיטקטורה של AI אקטיבי. מידע נוסף על המודלים שזמינים ועל אופן הבחירה של מודל שמתאים לצרכים שלכם זמין במאמר בנושא Model Garden ב-Gemini Enterprise Agent Platform.

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

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

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

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

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

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

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

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

Agent Runtime

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

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

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

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

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

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

Agent Runtime

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

להלן התכונות והשיקולים עבור Agent Runtime:

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

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

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

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

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

Cloud Run

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

התכונות והשיקולים הבאים רלוונטיים ל-Cloud Run:

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

GKE

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

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

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

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

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

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

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