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

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

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

סקירה כללית של דפוסי שילוב

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

  • מסלול Looker: בחרו במסלול הזה אם אתם רוצים לספק פונקציונליות של צ'אט באמצעות הטמעת Looker, ‏Looker API או Conversational Analytics API.
  • מסלול BigQuery ומסד נתונים: בחרו במסלול הזה אם אתם מפתחים אפליקציה בהתאמה אישית שמשתמשת ב-BigQuery, ב-Data Studio או במסד נתונים תפעולי נתמך.

הטבלה הבאה מסכמת את דפוסי השילוב הזמינים:

תבנית שילוב תיאור מקור הנתונים
הטמעת iframe של Looker מוסיף את ממשק צ'אט ברירת המחדל לאפליקציה שדורשת קוד מינימלי. Looker
Looker API וערכות SDK יוצר ממשק צ'אט בהתאמה אישית שמשתמש ב-Looker API לאימות. Looker
Conversational Analytics API (מקור Looker) מנהל את סוכני לאינטראקציה עם נתונים של Looker כמשאבים של Google Cloud שפועלים בכמה פלטפורמות ובמערכות מרובות סוכנים (MAS). Looker
Direct API (נציג אחד) משתמש בשילוב ישיר של API לתהליכי מענה על שאלות בטקסט. ‫BigQuery, מסדי נתונים, Looker
Direct API (orchestrator) מנתב שאילתות בין ה-API לכלים אחרים באמצעות קריאה להפעלת פונקציות. ‫BigQuery, מסדי נתונים, Looker
‫ADK (מבוסס-סכימה) עם BigQueryToolset מפיק תובנות במהירות מהפניות בטבלה באמצעות הכלי ask_data_insights. BigQuery
ADK (מנוהל) עם DataAgentToolset שליחת שאילתות לסוכנים מוגדרים מראש לאינטראקציה עם נתונים שמשתמשים בכלי ask_data_agent כדי להבטיח התנהגות עקבית. ‫BigQuery, מסדי נתונים, Looker
ADK (סטרימינג בהתאמה אישית) תמיכה בסטרימינג בזמן אמת של תרשימים ו-SQL באמצעות מחלקת סוכן בהתאמה אישית. ‫BigQuery, מסדי נתונים, Looker
‫MCP עם McpToolset או ToolboxToolset מקשר בין אפליקציות לבין כלי נתונים שמשתמשים ב-Model Context Protocol‏ (MCP). ‫BigQuery, ‏ Looker
שרת MCP מרוחק של Conversational Analytics API שער גישה מאובטח ומאוחד שמאפשר לסוכני בסיס בפלטפורמות AI של צד שלישי ובפלטפורמות בניהול Google (כמו Gemini Enterprise) לגלות סוכנים לאינטראקציה עם נתונים ייעודיים ב- Google Cloudולתקשר איתם. ‫BigQuery, מסדי נתונים, Looker
פרוטוקול A2A מאפשר שיתוף פעולה מאובטח בין סוכנים ייעודיים שפועלים במערכות שונות. תלוי-מסגרת

אפשרויות שילוב ב-Looker

אם אתם משתמשים ב-Looker, אתם יכולים לספק למשתמשים את Looker Conversational Analytics באמצעות התבניות הבאות:

סיכום של תבניות השילוב של Looker

בטבלה הבאה מופיע סיכום של דפוסי השילוב העיקריים של Looker:

דוגמת קוד למי זה מתאים יתרונות לתשומת ליבכם
הטמעה באמצעות iframe: שיטה עם תכנות מינימלי להוספה מהירה של חוויית הצ'אט הרגילה של Looker לאפליקציה. צוותים שצריכים חוויית ניתוח נתוני שיחות שמוכנה לייצור עם פיתוח מינימלי בהתאמה אישית.
  • כדי להטמיע אותו, צריך רק שורת קוד אחת.
  • אכיפה אוטומטית של מודל האבטחה הקיים של Looker.
  • לא נדרש אימות Google Cloud נפרד.
  • תמיכה ב-Looker Embed SDK, שמנהל את מחזורי החיים של iframe ואת העברת האירועים, וכך מאיץ את הפיתוח.
  • מציע התאמה אישית מוגבלת של ממשק המשתמש ומסתמך על ממשק המשתמש הרגיל של הצ'אט ב-Looker.
  • המכונה של Looker צריכה להתארח ב-Looker.
פיתוח באמצעות Looker API וערכות SDK: גישה גמישה לפיתוח ממשק צ'אט בהתאמה אישית, תוך שמירה על האימות וניהול הנציגים ב-Looker. צוותים שצריכים חוויית משתמש מותאמת אישית בצ'אט, אבל רוצים להשאיר את אימות המשתמשים וניהול הנציגים בסביבה העסקית של Looker. התבנית הזו מתאימה במיוחד לאפליקציות שכבר משתמשות בהטמעה של Looker או ב-API.
  • מספק שכבת אימות אחת ושליטה מלאה בממשק המשתמש.
  • מפשט את הארכיטקטורה ללקוחות Looker קיימים.
  • משתמש בשכבה הסמנטית של Looker כדי לשפר את הדיוק של השאילתות.
  • לא נדרש אימות Google Cloud נפרד.
  • נדרשת מומחיות בפיתוח Looker API.
  • מוגבל למקורות נתונים של Looker.
  • הסוכנים מנוהלים בתוך Looker ואי אפשר להעביר אותם לשירותי Google Cloud אחרים.
שימוש ב-Conversational Analytics API: שילוב ישיר עם ה-API כדי לנהל נציגים כמשאבים ברמת הענן. לקוחות Looker שצריכים ניידות בין פלטפורמות שונות בשביל הסוכנים שלהם לאינטראקציה עם נתונים.
  • כך אפשר להעביר את הסוכן לאינטראקציה עם נתונים בין כל הפלטפורמות של Google Cloud .
  • מנוהלות באופן מרכזי באמצעות IAM.
  • מאפשר לשלב סוכנים לאינטראקציה עם נתונים בתהליכי עבודה של ADK או MCP.
  • צריך לנהל את כל מחסנית השילוב, כולל האימות של Google Cloud ושל Looker.
  • הניהול של סוכני הנתונים מתבצע בנפרד מממשק המשתמש של Looker.

הטמעה באמצעות iframe

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

Embed SDK של Looker מספק כלים לניהול משימות כמו יצירת כתובות URL מאובטחות, ניהול מחזור החיים של iframe והעברת אירועי JavaScript בין האפליקציה המארחת לבין ה-iframe. כדי להטמיע את הדף Agents, את הדף Conversations או שיחה ספציפית, מוסיפים לאפליקציה כתובת URL בפורמט מוגדר מראש.

אפשר להשתמש בשיטות האימות הבאות לתוכן מוטמע:

  • הטמעה פרטית: מאמתת משתמשים באמצעות פרטי הכניסה הקיימים שלהם ל-Looker. כשמגדירים את כתובת ה-URL להטמעה כמקור ה-iframe, המשתמשים נכנסים באמצעות חשבונות Looker שלהם. השיטה הזו אוכפת באופן אוטומטי תפקידים קיימים, גישה לתוכן והרשאות ברמת הנתונים, כמו מסנני גישה או הענקת גישה, בלי צורך בהגדרת IAM נוספת או במיפוי טוקנים.
  • הטמעה חתומה: מאמתת משתמשים דרך האפליקציה באמצעות כניסה יחידה (SSO). אתם יוצרים כתובת URL חתומה שכוללת את נתיב התוכן של Conversational Analytics, שמאפשר לכם לציין באופן דינמי בדיוק אילו הרשאות להעניק.

פיתוח באמצעות Looker API וערכות SDK

כדי ליהנות מחוויית צ'אט גמישה יותר, אתם יכולים להשתמש בשיטות של ConversationalAnalytics ב-Looker API או להשתמש ב-Looker SDK כדי ליצור אפליקציה בהתאמה אישית. הגישה הזו מאפשרת לכם ליצור ממשק משתמש מותאם אישית שמתקשר ישירות עם נקודות הקצה של Looker.

השילוב עם Looker API מספק את היתרונות הבאים:

  • אתם מנהלים את האימות רק באמצעות Looker. אין צורך לבצע אימות בנפרד באמצעות Conversational Analytics API.
  • באפליקציות שכבר משתמשות בהטמעה של Looker או ב-API, התבנית הזו מפשטת את ארכיטקטורת הפרויקט כי היא לא דורשת מנגנוני אימות משניים ומבטלת את הצורך לנהל סוכנים לאינטראקציה עם נתונים חיצוניים.
  • יש לכם שליטה מלאה על ממשק הצ'אט, על תהליך השיחה ועל האופן שבו האפליקציה מציגה את התוצאות (למשל, תרשימים וטבלאות).

להטמעה של קובץ עזר, עיינו במדריך ל-Looker API שמשתמש בשיטות ConversationalAnalytics ב-GitHub.

שימוש ב-Conversational Analytics API עם נתונים מ-Looker

אתם יכולים לשלב ישירות עם Conversational Analytics API בכתובת geminidataanalytics.googleapis.com אם אתם צריכים לבצע אחת מהמשימות הבאות:

  • לשתף את אותו סוכן לאינטראקציה עם נתונים בכמה פלטפורמות של Google Cloud , כמו אפליקציות אינטרנט בהתאמה אישית, Google Chat ו-Gemini Enterprise.
  • לשלב מקורות נתונים של Looker עם מקורות נתונים של BigQuery או של מסדי נתונים תפעוליים במערכת מרובת סוכנים (MAS) אחת.
  • אתם יכולים לנהל את הסוכן לאינטראקציה עם נתונים כמשאב ברמת הענן, שנשלט על ידי IAM ולא על ידי מודל ההרשאות של Looker.

למידע נוסף על דפוסי ארכיטקטורה נפוצים של Conversational Analytics API, קראו את המאמר אפשרויות שילוב של BigQuery ומסדי נתונים.

אפשרויות שילוב עם BigQuery, ‏Data Studio ומסדי נתונים

בקטע הזה מתוארים דפוסי ארכיטקטורה של אפליקציות שמשתמשות ב-BigQuery, ב-Data Studio או ב Google Cloud מסדי נתונים תפעוליים נתמכים כדי ליצור חוויות בהתאמה אישית באמצעות Conversational Analytics API.

אם אתם משתמשים ב-Conversational Analytics API עם מקור נתונים של Looker, התבניות שמתוארות בקטע הזה רלוונטיות גם לשילוב שלכם.

‫Conversational Analytics API מספק את השיטות העיקריות הבאות לאינטראקציה עם נתונים:

  • השיטה chat: תומכת ב-BigQuery, ב-Looker, ב-Data Studio ובמסדי נתונים תפעוליים.
  • השיטה queryData: תומכת במסדי נתונים תפעוליים כמו AlloyDB,‏ GoogleSQL ל-Spanner,‏ Cloud SQL ל-MySQL ו-Cloud SQL ל-PostgreSQL.

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

  • שילוב ישיר של API: גישה מותאמת אישית שמספקת את הגמישות הרבה ביותר, אבל מחייבת אתכם לבנות את התשתית לאימות, לניהול שיחות ולניתוח תשובות.
  • תזמור מבוסס-מסגרת (ADK): גישה שמשתמשת בערכה לפיתוח סוכנים (ADK) לניתוב של כמה סוכנים, להפעלת כלים ולניהול מצבים.
  • שילוב אנכי (MCP): גישה שמשתמשת ב-Model Context Protocol‏ (MCP) כדי לספק דרך אחידה לחבר אפליקציות מבוססות-AI לכלים ולמקורות נתונים בסביבות שונות.
  • תזמור אופקי (A2A): גישה שמשתמשת בפרוטוקול Agent-to-Agent‏ (A2A) כדי לאפשר לסוכנים ייעודיים במערכות שונות לשתף פעולה באופן מאובטח בלי צורך בקוד שילוב מותאם אישית.

סיכום של תבניות השילוב של BigQuery ומסד הנתונים

בטבלה הבאה מפורטים דפוסי ההטמעה הספציפיים של BigQuery ומסדי נתונים תפעוליים:

דוגמת קוד למי זה מתאים יתרונות לתשומת ליבכם
שילוב של סוכן יחיד (API ישיר): דפוס שבו האפליקציה קוראת ישירות ל-API כדי להחזיר תובנות ממקורות הנתונים. אפליקציות, אבות טיפוס או מיקרו-שירותים עם נציג אחד שדורשים שליטה ישירה בכל קריאה ל-API.
  • מספק שליטה מפורטת ללא תלות במסגרת.
  • הארכיטקטורה הפשוטה ביותר לתרחישי שימוש של נציג אחד.
  • תמיכה במצבים עם הקשר קודם ובלי הקשר קודם.
  • צריך לבנות את כל התשתית לאימות, לניהול מצבים, לניתוח תגובות, לטיפול בשגיאות, לסטרימינג ולפריסה.
  • לא מתאים לתרחישים עם כמה סוכנים.
תזמור בהתאמה אישית (API ישיר): דפוס שמשתמש בסוכן ברמה הבסיסית ובקריאה להפעלת פונקציות כדי לנתב שאילתות בין Conversational Analytics API לבין כלים או שירותים אחרים. אפליקציות שמשלבות שאילתות נתונים עם משימות אחרות, כמו אימייל או מסמכים, ברצף שיחה אחד.
  • מספקת שליטה מקסימלית בתזמור, ללא תלות במסגרת.
  • מאפשרת לכם להגדיר בדיוק איך המודל מנתב בין הכלים.
  • התכונה פועלת עם כל מודל של Gemini.
  • צריך לנהל באופן ידני את הגדרות הכלים, לולאות השיחה, מצב השיחה עם כמה שלבים, הטיפול בשגיאות והפריסה.
  • התקורה של הפיתוח עלולה להפוך לנטל בהשוואה לשימוש במסגרת כמו ADK.
שילוב מבוסס-סכימה עם BigQueryToolset (ADK): דפוס שמשתמש בהפניות לטבלאות כדי להחזיר תובנות מנתונים במהירות. יצירת אב טיפוס מהיר, כלים פנימיים שבהם משילות המידע פחות קריטית, או תרחישים שבהם תובנות מנתונים הן אחת מכמה יכולות של סוכן ADK.
  • מספק את נתיב השילוב המהיר ביותר במסגרת ADK.
  • לא נדרשת הגדרה מראש של סוכן לאינטראקציה עם נתונים.
  • עובד ישירות עם שמות של טבלאות במסד הנתונים.
  • אין לו ניהול סמנטי והוא יוצר SQL רק מהסקת סכימה.
  • פועל בלי הקשר קודם ברמת ה-API.
  • מספק תשובות בטקסט בלבד ולא תומך בתרשימים.
שילוב מנוהל עם DataAgentToolset ‏(ADK): תבנית ששולחת שאילתה לסוכן לאינטראקציה עם נתונים שהוגדר מראש, על ידי הפניה למזהה של הסוכן. אפליקציות בסביבת ייצור שדורשות גישה עקבית לנתונים, או מערכות מרובות סוכנים שבהן הסוכן לאינטראקציה עם נתונים הוא רכיב מהימן שאפשר לעשות בו שימוש חוזר.
  • מספק ניהול סמנטי והתנהגות עקבית בכל הצרכנים.
  • משפר את הדיוק באמצעות שאילתות מאומתות ומילון מונחים ארגוני.
  • מאפשר להשתמש בסוכנים לאינטראקציה עם נתונים גם בשילובים של ADK,‏ MCP ו-API ישיר.
  • צריך להגדיר מראש את המשאבים של הסוכן לאינטראקציה עם נתונים.
  • פועל בלי הקשר קודם ברמת ה-API.
  • מחזיר תשובות בטקסט בלבד ולא תומך בתרשימים.
‫סוכני משנה בהתאמה אישית (ADK): תבנית שמשתמשת במחלקת סוכנים בהתאמה אישית כדי להתחבר ישירות ל-API ולהעביר נתונים בסטרימינג בחזרה למשתמש. אפליקציות שגלויות למשתמשים שבהן זמן אחזור קצר הוא בעדיפות גבוהה, או צינורות עיבוד נתונים עם כמה סוכנים שבהם אחזור הנתונים מזין סוכנים במורד הזרם.
  • התלמידים מקבלים משוב בזמן אמת.
  • גישה לכל סוגי התשובות, כמו תרשימים, טבלאות ו-SQL.
  • קומפוזבילי עם סוכני ADK אחרים באמצעות מצב הסשן.
  • צריך להשקיע יותר מאמץ בפיתוח כדי ליצור מחלקת סוכן ADK בהתאמה אישית.
  • צריך לנהל את חיבור הסטרימינג ואת ניתוח התגובות באופן ישיר.
‫Model Context Protocol (MCP): דפוס שמשתמש בתקן פתוח כדי לחבר אפליקציות מבוססות-AI למקורות נתונים ולכלים בסביבות שונות. ארגונים שצריכים יכולת פעולה הדדית של כלים בכמה לקוחות AI וסביבות פיתוח משולבות (IDE), או צוותים שצריכים גישה לאותם כלי נתונים ממסגרת ADK, מסביבות פיתוח משולבות ומאפליקציות בהתאמה אישית.
  • משתמש בתקן כלים אוניברסלי שפועל עם כל לקוח שתואם ל-MCP.
  • הפרדה בין הטמעת הכלים לבין אפליקציות הצרכן.
  • מציע אפשרויות לשרתים מנוהלים, כמו Google Cloud שרת MCP.
  • נדרשת שכבת תשתית נוספת לשרת של ארגז הכלים.
  • השילוב פחות הדוק מאשר בערכות הכלים של ADK.
  • תלוי בסביבה העסקית המתפתחת של MCP Toolbox.
  • פועל במצב בלי הקשר קודם שמחייב ניהול של מצב השיחה הרב-שלבית באופן חיצוני.
‫סוכן לסוכן (A2A): דפוס שמשתמש בפרוטוקול A2A, תקן פתוח שמאפשר לסוכנים ייעודיים במערכות שונות לשתף פעולה בצורה מאובטחת בלי צורך בקוד שילוב מותאם אישית. סביבות ארגוניות מבוזרות מאוד, שבהן סוכן ניתוב מרכזי צריך להקצות משימות לסוכנים לאינטראקציה עם נתונים שפועלים במערכות או ברשתות שונות.
  • מפחית את הצורך בקוד שילוב מותאם אישית בין מסגרות שונות.
  • מבטיח יכולת פעולה הדדית חלקה בפלטפורמות שונות.
  • מספקת גילוי יכולות מאובטח וסטנדרטי.
  • זמן האחזור ברשת קצר יותר בהשוואה לסוכני משנה פנימיים.
  • צריך להגדיר את הגדרות השרת של A2A.

שילוב ישיר של API

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

הנושאים בקטע הזה:

שילוב של נציג אחד

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

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

להטמעות לדוגמה, עיינו במדריך למתחילים של Conversational Analytics API או בהדגמה של Conversational Analytics API ב-GitHub.

שילוב של כלי מותאם אישית לניהול סוכנים

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

הקריאה להפעלת פונקציות כוללת את השלבים הבאים:

  1. הצהרה: מגדירים סכימות של כלים כאובייקטים מסוג FunctionDeclaration שכוללים הגדרות של פרמטרים.
  2. הפעלה: המודל מחזיר הודעת functionCall מובנית שמכילה את שם הפונקציה והארגומנטים.
  3. ביצוע: האפליקציה מבצעת את הקריאה ל-API ומחזירה את התוצאה בהודעת FunctionResponse.
  4. סינתזה: מודל Gemini משתמש בתוצאה כדי ליצור תשובה סופית או כדי לקבוע את הפעולה הבאה.

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

כדי לראות הטמעה לדוגמה, עיינו בדפים orchestrate או multimodal בהדגמה של Conversational Analytics API ב-GitHub.

תזמור מבוסס-מסגרת (ADK)

הערכה לפיתוח סוכנים (ADK) היא מסגרת שמתמקדת בקוד ליצירת סוכני AI, שמנהלת את המורכבות של ניתוב בין כמה סוכנים, הפעלת כלים וניהול מצבים. מסגרת ה-ADK היא אותה מסגרת שמפעילה את Gemini Enterprise.

באמצעות ה-ADK, אתם יכולים לקשר את Conversational Analytics API לכלים ולסוכנים אחרים כדי לבצע פעולות מורכבות.

הנושאים בקטע הזה:

שילוב מבוסס-סכימה עם BigQueryToolset

ערכת הכלים BigQueryToolset במסגרת ADK כוללת כלי ask_data_insights מובנה. כדי להשתמש בכלי הזה, מעבירים אליו את שמות הטבלאות ואת השאלה של המשתמש, והוא קורא ל-Conversational Analytics API באמצעות הקשר מוטבע.

כשמפעילים את הכלי, הוא שולח בקשה ללא שמירת מצב (stateless) שכוללת את ההפניות שצוינו לטבלאות ב-BigQuery אל Conversational Analytics API. ה-API מסיק את סכימת מסד הנתונים, יוצר ומריץ את שאילתת ה-SQL ומחזיר תשובה בטקסט. התוצאה מועברת בחזרה לסוכן ADK כתגובה של הכלי.

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

שילוב מנוהל עם DataAgentToolset

ערכת הכלים DataAgentToolset במסגרת ADK מספקת שילוב מובנה שמפנה לסוכן לאינטראקציה עם נתונים מוגדר מראש לפי המזהה שלו. סוכן ה-ADK מעביר את השאלה של המשתמש לכלי ask_data_agent, שקורא ל-Conversational Analytics API עם ההקשר שצוין של הסוכן לאינטראקציה עם נתונים.

אתם יכולים ליצור סוכן לאינטראקציה עם נתונים באופן פרוגרמטי באמצעות Conversational Analytics API או דרך Agent Catalog במסוף Google Cloud . סוכן לאינטראקציה עם נתונים כולל את הרכיבים הבאים:

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

למדריך מפורט על יצירת סוכנים באמצעות Agent Catalog, ראו את ה-Codelab ניתוח שיחות ב-BigQuery.

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

שילוב מתקדם של חוויית המשתמש עם סוכני משנה בהתאמה אישית

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

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

  • הודעות על תהליך החשיבה: תהליך החשיבה של הסוכן לאינטראקציה עם נתונים כשהוא מפרש את השאלה.
  • הודעות על התקדמות: עדכוני סטטוס במהלך אחזור הנתונים ממקורות הנתונים.
  • יצירת שאילתות: שאילתת ה-SQL או Looker שנוצרה, שמועברת בסטרימינג בזמן שהיא נוצרת.
  • ‫Data: תוצאות הנתונים בפורמט JSON.
  • תצוגה חזותית: מפרטים של תרשימי Vega-Lite.
  • סיכום: התשובה הסופית שמבוססת על טקסט.

כדי לראות את הרשימה המלאה של סוגי הנתונים שמוחזרים, עיינו בסוג SystemMessage במאמרי העזרה של ה-API.

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

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

שילוב אנכי (MCP)

‫Model Context Protocol‏ (MCP) הוא תקן פתוח שמספק לאפליקציות מבוססות-AI דרך אחידה להתחבר לכלים ולמקורות נתונים חיצוניים. ‫MCP יוצר ממשק סטנדרטי בין מודלי AI לבין הכלים שבהם הם משתמשים.

הנושאים בקטע הזה:

שרת MCP מרוחק של Conversational Analytics API

‫Conversational Analytics API מספק שרת MCP מרוחק בכתובת https://geminidataanalytics.googleapis.com/mcp, שמופעל על ידי שרת MCP מנוהל של Google. השער הזה מספק ממשק מאובטח ומאוחד של HTTP ו-Server-Sent Events‏ (SSE), שמאפשר לסוכני הבסיס בפלטפורמות AI של צד שלישי ובפלטפורמות בניהול Google (כמו Gemini Enterprise) לגלות סוכנים לאינטראקציה עם נתונים ייעודיים ב- Google Cloudולתקשר איתם.

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

התקשורת בין סוכן בסיס חיצוני או סוכן בסיס שמנוהל על ידי Google לבין Conversational Analytics API כוללת שלושה תפקידים נפרדים:

  1. מפעילי נתונים יוצרים ומגדירים סוכנים לאינטראקציה עם נתונים ברמת היקף מסוים בממשקים של ניתוח נתונים בממשק שיחה, כותבים תיאורים ברורים של מקורות הנתונים שכל סוכן יכול לגשת אליהם ושל השאלות שהוא יכול לענות עליהן, ומשתפים את הסוכנים האלה עם משתמשים עסקיים.
  2. אדמינים של הפלטפורמה רושמים חיבור MCP בהתאמה אישית בפלטפורמה מבוססת הסוכנים שלהם, שמפנה לנקודת הקצה https://geminidataanalytics.googleapis.com/mcp. האדמינים מגדירים את פרטי הכניסה של לקוח OAuth 2.0 (מזהה לקוח וסוד לקוח) באמצעות נקודת הקצה של ההרשאה של Google‏ (https://accounts.google.com/o/oauth2/v2/auth), נקודת הקצה של הטוקן (https://oauth2.googleapis.com/token) והיקפי ההרשאות הנדרשים (https://www.googleapis.com/auth/geminidataanalytics ו-https://www.googleapis.com/auth/bigquery.readonly).
  3. משתמשים עסקיים שואלים שאלות בשפה טבעית בפלטפורמה של הסוכנים. במקום לשלוח שאילתות ישירות למסדי נתונים גולמיים, סוכן הבסיס של הפלטפורמה (מודל ה-LLM המתזמר) מתקשר עם שרת ה-MCP המרוחק של Conversational Analytics API כדי לגלות סוכנים לאינטראקציה עם נתונים רלוונטיים, לנתב את השאלה של המשתמש לסוכן הנתונים המתאים ולהחזיר את התשובה המסונתזת.
הפצת זהויות

כדי לשמור על משילות המידע (data governance) בארגון כשבקשות מגיעות מסוכני שורש חיצוניים או של צד שלישי, שרת ה-MCP המרוחק אוכף הפצת זהויות מקצה לקצה:

  • אימות בהקצאת הרשאות למשתמשים: כשמשתמש עסקי יוצר אינטראקציה עם נציג הבסיס, הפלטפורמה מבוססת-הסוכנים מאמתת את המשתמש באמצעות הרשאה באמצעות OAuth 2.0 תלת-שלבית, וכוללת את טוקן הגישה של OAuth בהקצאת הרשאות למשתמשים בכותרות ה-HTTP של הבקשות שנשלחות לשער ה-MCP.
  • העברת פרטי כניסה של משתמשי קצה (EUC): שרת ה-MCP המרוחק מאמת את האסימון ומעביר את פרטי הכניסה של משתמשי הקצה דרך שכבת Conversational Analytics API למנועי הנתונים הבסיסיים, כמו BigQuery,‏ Spanner,‏ AlloyDB ו-Cloud SQL.
  • גישה מנוהלת לנתונים: מכיוון שהשאילתות פועלות באמצעות הזהות של המשתמש המאומת ולא באמצעות חשבון שירות משותף, מקורות הנתונים הבסיסיים אוכפים באופן אוטומטי את ההרשאות הקיימות של IAM, את כללי מדיניות האבטחה ברמת השורה וברמת העמודה ואת גבולות הגישה המנוהלת לנתונים. המשתמשים יכולים לגלות רק סוכנים לאינטראקציה עם נתונים ולשלוח שאילתות רק על קבוצות נתונים שכבר יש להם הרשאת גישה אליהם.
  • מודל שתי הזהויות של Looker: ב-BigQuery ובמסדי נתונים תפעוליים, השאילתות מופעלות באמצעות פרטי הכניסה של המשתמש הספציפי שהועברו דרך Google OAuth. בסוכנים לאינטראקציה עם נתונים שמבוססים על Looker, האימות מתבצע באמצעות מודל של שתי זהויות: טוקן Google OAuth של המשתמש מאשר את הגישה לסוכן לאינטראקציה עם נתונים ב-Google IAM, אבל השאילתה מופעלת ב-Looker באמצעות פרטי כניסה שסופקו למשתמש Looker API (מועברים בבלוק פרטי הכניסה של כלי הצ'אט). הגישה למודל Looker, ההרשאות והכללים ברמת השורה משקפים את משתמש ה-API שהוגדר, ולא את הזהות של משתמש הקצה הספציפי ב-Looker.
איך נציגי שורש ניגשים לשיטות API

כשלקוח MCP מתחבר אל https://geminidataanalytics.googleapis.com/mcp, הוא קורא ל-method הרגיל של MCP‏ tools/list כדי לייבא באופן דינמי את הסכימות של הכלים שנחשפות על ידי Conversational Analytics API. הסוכן הראשי יוצר אינטראקציה עם Conversational Analytics API באמצעות הפעלת הכלים והמשאבים האלה של MCP, שממופים ישירות לשיטות הבסיסיות של API בארכיטקטורת REST:

כלי או משאב MCP ה-Method הממופה ב-Conversational Analytics API איך הסוכן הראשי משתמש בו
list_data_agents projects.locations.dataAgents.list

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

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

get_data_agent

(או המשאב gda://agents/AGENT_ID ב-MCP)

 projects.locations.dataAgents.get

בדיקת המטא-נתונים וההקשר של סוכן ספציפי לאינטראקציה עם נתונים. הסוכן הראשי מעביר את היעד AGENT_ID כדי לאחזר פרטי הגדרות – כמו טבלאות ב-BigQuery מקושרות, הוראות מערכת, מילוני מונחים או שאילתות מאומתות – כשהתיאורים של הסוכנים לא מספיקים כדי לנתב פרומפט מורכב.
chat projects.locations.chat

משמש כשרת proxy לביצוע שאילתות בשיחה. כדי לשלוח שאילתה לסוכן לאינטראקציה עם נתונים שזוהה, הסוכן הראשי מעביר את data_agent_context שמכיל את שם המשאב המלא של הסוכן (projects/PROJECT_ID/locations/LOCATION/dataAgents/AGENT_ID) ואת ההודעה בשפה טבעית של המשתמש ב-messages. בשאילתות אד-הוק ללא שמירת מצב, הנציג הראשי יכול להעביר את הערך inline_context במקום זאת. הכלי מחזיר תשובות בשפה טבעית, שאילתות SQL שנוצרו, שורות תוצאות, מפרטי תרשימים של Vega-Lite ונימוקים של הסוכן.

MCP Toolbox for Databases

אתם יכולים לגשת ל-Conversational Analytics API גם דרך שרת MCP Toolbox for Databases בקוד פתוח. השרת הזה מספק כלים מובנים שתואמים ל-MCP וחושפים את השיטה chat ב-Conversational Analytics API:

‫MCP היא שכבת יכולת פעולה הדדית שחושפת את יכולות הניתוח ככלים ללקוחות שתואמים ל-MCP, ולא כמודל הפעלה נפרד של Conversational Analytics API.

תבניות הטמעה של MCP לארכיטקטורות עצמאיות ו-ADK

אפשר להטמיע את MCP באמצעות התבניות הבאות:

דוגמת קוד פרטים
‫MCP עצמאי (ללא ADK)

אתם יכולים להשתמש בשרת MCP Toolbox for Databases כשרת עצמאי כדי להתחבר לכל לקוח שתואם ל-MCP. התבנית הזו משמשת בדרך כלל למשימות הבאות:

  • שילוב עם סביבת פיתוח משולבת (IDE): מחברים סביבת פיתוח משולבת (IDE) – כמו Antigravity, ‏Cursor או VS Code – לשרת כדי לשלוח שאילתות על נתונים בצורה של שיחה מעורך.
  • לקוח MCP בהתאמה אישית: אתם יכולים לפתח אפליקציה שמשתמשת בשרת כדי לספק ממשק כלים אחיד לכמה ספקי AI.
  • ‫Gemini CLI: שימוש ב-CLI כלקוח MCP לשיחות מבוססות-טרמינל על נתונים.
‫MCP ב-ADK

מסגרת ה-ADK מספקת את המנגנונים הבאים לשילוב שרתי MCP בתהליכי עבודה של סוכנים:

  • ‫ToolboxToolset: וריאנט מיוחד עבור שרת MCP Toolbox for Databases שתומך בכמה שיטות אימות.
  • ‫McpToolset: מחבר סוכן ADK לכל שרת MCP באמצעות חיבורים לשרת MCP מקומי או מרוחק. מגלה באופן אוטומטי את הכלים של השרת וחושף אותם לנציג.

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

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

  • שימוש בערכות הכלים המובנות של הערכה לפיתוח סוכנים (ADK), כמו BigQueryToolset או DataAgentToolset, מספק שילוב הדוק יותר ללא תלות בשרתים חיצוניים. הגישה הזו מתאימה למערכות שקיימות כולן במסגרת של ADK.
  • השימוש בכלים ב-MCP Toolbox מאפשר יכולת פעולה הדדית בין לקוחות שתואמים ל-MCP. הגישה הזו מתאימה במיוחד לכלי נתונים שצריכים לשרת כמה אפליקציות של צרכנים או סביבות פיתוח משולבות (IDE) של צד שלישי.

תזמור אופקי (A2A)

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

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

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

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

בחירת תבנית שילוב

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

רמות המורכבות מוגדרות כך:

  • נמוכה: תבניות שדורשות קוד מינימלי בהתאמה אישית ומסתמכות על ממשקי משתמש או כלים מובנים מראש.
  • בינוני: דפוסים שדורשים פיתוח מותאם אישית של ממשק קצה (frontend) ושילוב של API או SDK, אבל לא דורשים תשתית מורכבת של תזמור בקצה העורפי (backend).
  • גבוהה: תבניות שדורשות פיתוח אפליקציות Full Stack, ניהול מצב שיחה, כמה שכבות אימות או תשתית תזמור ביניים.
  • משתנה: תבניות שבהן המורכבות תלויה בשיטת השילוב הבסיסית שבחרתם.
תבנית שילוב מורכבות התאמה אישית ניהול סוכנים בקרת גישה כמה סוכנים סטרימינג ניידות
הטמעת iframe של Looker נמוכה נמוכה מנוהלות באמצעות Looker Looker לא מובנה Looker בלבד
Looker API וערכות SDK בינוני גבוהה מנוהלות באמצעות Looker Looker לא מובנה Looker בלבד
Conversational Analytics API עם מקור Looker משתנה גבוהה מנוהלות באמצעות ה-API ‫Looker ו-IAM כן כן כל Google Cloud משטח
נציג יחיד (API ישיר) בינוני גבוהה מנוהלות באמצעות ה-API IAM לא כן (נתמך) כל Google Cloud משטח
תזמור בהתאמה אישית גבוהה גבוהה מאוד מנוהלות באמצעות ה-API IAM גלילה ידנית גלילה ידנית כל Google Cloud משטח
מבוסס-סכימה עם BigQueryToolset (ADK) נמוכה בינוני ללא (הסקת סכימה) IAM כן (ADK) לא (חסימה) המערכת האקולוגית של ADK
מנוהל באמצעות DataAgentToolset (ADK) נמוכה בינוני מנוהלות באמצעות ה-API IAM כן (ADK) לא (חסימה) המערכת האקולוגית של ADK
סוכן משנה מותאם אישית לסטרימינג (ADK) גבוהה גבוהה מאוד מנוהלות באמצעות ה-API IAM כן (ADK) כן (בהתאמה אישית) המערכת האקולוגית של ADK
חשבון MCP עצמאי בינוני בינוני ללא (הסקת סכימה) IAM לא לא כל לקוח MCP
MCP ב-ADK בינוני גבוהה ללא (הסקת סכימה) IAM כן (ADK) לא לקוחות ADK ו-MCP
פרוטוקול A2A גבוהה גבוהה תלוי-מסגרת IAM כן כן בפלטפורמות שונות

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