WEBVTT

00:00:00.000 --> 00:00:01.880
ברוכים הבאים לעוד פיסת ידע

00:00:01.880 --> 00:00:05.120
דמיינו שאתם מנהלים חברה וסוחרים צוות של מומחים מבריקים

00:00:05.120 --> 00:00:08.720
מתכנן נסיעות ברמה עולמית, מומחה לקליטת עובדים ואיש תמיכת אי

00:00:08.720 --> 00:00:10.700
אבל אף אחד מהם לא מדבר עם השני

00:00:10.700 --> 00:00:12.640
בכל פעם שמשימה דורשת את שניים מהם

00:00:12.640 --> 00:00:15.440
אתם צריכים ללכת בין השולחנות ולהעביר את המידע בעצמכם

00:00:15.440 --> 00:00:18.080
כך בדיוק עובדים רוב סוכני הבינה המלאכותית כרגע

00:00:18.080 --> 00:00:21.220
הם פועלים בוידוד גם כשהבעיה דורשת בבירור עבודת צוות

00:00:21.220 --> 00:00:23.860
אז היום נדבר על האופן שבו סוכנים יכולים לתקשר

00:00:23.860 --> 00:00:26.020
להעביר עבודה ולפעול קצוותים של ממש

00:00:26.020 --> 00:00:28.440
אני מרקו פיטרז, זה לא מושג עתידני

00:00:28.440 --> 00:00:30.900
תזמור סוכנים מרובים כבר קורה כאן ועכשיו

00:00:30.900 --> 00:00:33.480
והוא מונה על ידי פרוטוקול שנקרא A2A

00:00:33.480 --> 00:00:36.060
נתחיל בבעיה, נפרק את הפרוטוקול הזה לחלקים

00:00:36.060 --> 00:00:39.560
ונראה איך מייקרוסופט משתמשת בו בתוך Copilot Studio וAzure AI

00:00:39.560 --> 00:00:41.580
קחו את הקפה ובואו נצלול פנימה

00:00:41.580 --> 00:00:42.980
אז מהי הבעיה האמיתית?

00:00:42.980 --> 00:00:46.220
סוכני בינה מלאכותית כיום דומים בדיוק לאותם מומחים מבודדים

00:00:46.220 --> 00:00:48.580
לכל אחד יש ידע, כלים ומטרות משלו

00:00:48.580 --> 00:00:50.540
סוכן מזג אוויר יודע את התחזית

00:00:50.540 --> 00:00:52.300
סוכן מלונות יודע על זמינות חדרים

00:00:52.300 --> 00:00:53.500
אבל הם לא משתפים דבר

00:00:53.500 --> 00:00:57.660
כעת, דמיינו משתמש שמבקש נסיעה לסיאטל בשבוע הבא עם מלון קרוב למשרד

00:00:57.660 --> 00:01:02.360
סוכן בודד יצטרך להיות מומחי מזג אוויר, מומחי נסיעות ומומחי עסקים מקומיים בבת אחת

00:01:02.360 --> 00:01:06.240
זה אומר פרומפטים ענקיים ומנופחים שדוחסים כל יכולת אפשרית למערכת אחת

00:01:06.240 --> 00:01:08.080
והפרומפטים האלה נשברים כל הזמן

00:01:08.080 --> 00:01:10.540
הפתרון הישן היה כתיבת קוד מותאם אישית

00:01:10.540 --> 00:01:13.440
אתם כותבים גשר בין סוכן מזג האוויר לסוכן המלונות

00:01:13.440 --> 00:01:17.340
אחר כך עוד אחד בין סוכן המלונות לסוכן הטיסות ועוד אחד לסוכן היומן

00:01:17.340 --> 00:01:21.360
זה עובד בהתחלה, אבל בכל פעם שמוסיפים סוכן חדש בונים אינטגרציה נוספת

00:01:21.360 --> 00:01:25.380
מהר מאוד יש לכם סיוט של חיבורים נקודתיים שבו שינוי אחד שובר את הכל

00:01:25.380 --> 00:01:29.560
הרווחים בפריון שהבינה המלאכותית שלכם הייתה אמורה לספק נאכלים על ידי עבודה תחזוקה

00:01:29.560 --> 00:01:31.420
בואו נסתכל על הכאב העסקי האמיתי

00:01:31.420 --> 00:01:34.260
בארגון שלכם כבר יש תהליכים עם העברות משימות

00:01:34.260 --> 00:01:38.080
נוצרת פנייה, מי שהוא מתעדף אותה, מי שהוא פותר אותה, מי שהוא מתעד אותה

00:01:38.080 --> 00:01:39.120
וכל שלב הוא העברה

00:01:39.120 --> 00:01:43.860
בעולם הישן אתם ממקנים כל שלב עם סוכן נפרד ואז מבלים שבועות בחיבור ביניהם

00:01:43.860 --> 00:01:49.020
אבל מה אם היה פרוטוקול שמאפשר לסוכנים לגלות זה את זה ולשתף פעולה ללא שום גשרים מותאמים אישית

00:01:49.020 --> 00:01:50.760
זה בדיוק מה ש-A2A עושה

00:01:50.760 --> 00:01:56.480
במילים פשוטות, A2A היא דרך סטנדרטית עבור סוכנים לדבר זה עם זה, להעביר עבודה ולבצע דברים כצוות

00:01:56.480 --> 00:01:57.580
מה זה A2A?

00:01:57.740 --> 00:01:58.700
ההגדרה הפשוטה

00:01:58.700 --> 00:02:01.280
A2A מייצג סוכן לסוכן, agent to agent

00:02:01.280 --> 00:02:05.460
זהו פרוטוקול פתוח המאפשר לסוכני בינה מלאכותית לתקשר ישירות זה עם זה, ללא קשר למי שבנה אותם

00:02:05.460 --> 00:02:07.720
אפשר לחשוב על זה כעל HTTP עבור סוכנים

00:02:07.720 --> 00:02:12.940
HTTP היא השפה שדפדפני אינטרנט ושרתים משתמשים בה כדי לתקשר ו-A2A עושה את אותו הדבר עבור סוכנים

00:02:12.940 --> 00:02:19.480
סוכן שנבנה על ידי צוות ה-C שלכם במיקרוסופט קופיילוט סטודיו יכול לדבר עם סוכן שנבנה על ידי חברה אחרת בגוגל קלאוד

00:02:19.480 --> 00:02:21.120
כל עוד שניהם דוברים S2A

00:02:21.120 --> 00:02:22.600
זה גם לא פרויקט קטן

00:02:22.600 --> 00:02:29.400
S2A ממומן על ידי שמונה חברות ענק בהן גוגל, מייקרוסופט, סיסקו, סיילספורס, SAP ואחרות

00:02:29.400 --> 00:02:31.260
והוא מאוכסן על ידי קרן לינוקס

00:02:31.260 --> 00:02:34.340
גרסה 1.0 יציבה ומוכנה לשימוש אמיתי

00:02:34.340 --> 00:02:36.940
מה שאומר שאף ספק יחיד לא שולט בפרוטוקול

00:02:36.940 --> 00:02:39.240
זה לא עניין של גוגל או של מייקרוסופט

00:02:39.240 --> 00:02:40.800
זה עניין של התעשייה כולה

00:02:40.800 --> 00:02:42.200
התכנון פשוט במכוון

00:02:42.200 --> 00:02:46.360
S2A מתבסס על תקני אינטרנט קיימים כמו HTTP וGSON RPC

00:02:46.360 --> 00:02:48.040
דברים שכל מפתח כבר מכיר

00:02:48.040 --> 00:02:50.100
שום דבר אקזוטי או קנייני כאן

00:02:50.100 --> 00:02:54.320
זה מקל על ארגונים לאמץ אותו מבלי להחליף את התשתית הקיימת שלהם

00:02:54.320 --> 00:02:58.900
ייתכן ששמעתם על פרוטוקול אחר שנקרא MCP או Model Context Protocol

00:02:58.900 --> 00:02:59.880
הנה ההבדל

00:02:59.880 --> 00:03:01.840
MCP הוא פרוטוקול של סוכן לכלי

00:03:01.840 --> 00:03:04.620
כלומר הוא מחבר סוכן למקורות נתונים חיצוניים ולאס

00:03:04.620 --> 00:03:06.820
S2A הוא פרוטוקול של סוכן לסוכן

00:03:06.820 --> 00:03:08.380
המחבר סוכנים ישירות זה לזה

00:03:08.380 --> 00:03:10.460
הם לא מתחרים, הם משלימים זה את זה

00:03:10.460 --> 00:03:14.800
חישבו על MCP כעל החיבור האנכי מסוכן כלפי מטה לכלים שלו

00:03:14.800 --> 00:03:18.340
ועל S2A כעל החיבור האופקי בין סוכנים זה לצד זה

00:03:18.340 --> 00:03:19.740
עוד בחירת עיצוב אחת

00:03:19.740 --> 00:03:22.440
S2A מתייחס לסוכנים כאל ישויות אטומות

00:03:22.440 --> 00:03:24.140
כך שכאשר סוכן אחד מדבר עם אחר

00:03:24.140 --> 00:03:27.400
הוא לא רואה את תהליכי החשיבה הפנימיים, הכלים או הנתונים הפרטיים של הסוכן השני

00:03:27.400 --> 00:03:30.380
הוא רואה רק את המשימה ששלח ואת התוצאה שהוא מקבל בחזרה

00:03:30.380 --> 00:03:32.520
זה שומר על פרטיות ועל קניין רוחני

00:03:32.520 --> 00:03:35.980
סוכן מזג אוויר לא צריך לדעת איך סוכן המלונות מזמין חדרים

00:03:35.980 --> 00:03:37.560
הוא רק צריך להעביר את התחזית

00:03:37.560 --> 00:03:40.080
כעת בואו נסתכל על החלק הראשון בפאזל

00:03:40.080 --> 00:03:41.060
כרטיס הסוכן

00:03:41.060 --> 00:03:43.200
כרטיס הסוכן קורות החיים

00:03:43.200 --> 00:03:47.120
כל סוכן תואם S2A מפרסם משהו שנקרא כרטיס סוכן

00:03:47.120 --> 00:03:52.660
הכרטיס הזה הוא מסמך קרי למכונה שנמצא בכתובת URL סטנדרטית בדומיין של הסוכן

00:03:52.660 --> 00:03:55.460
ספציפית בנתיב Well-known Agent Card JSON

00:03:55.460 --> 00:03:57.140
אם אתם יודעים היכן סוכן חי

00:03:57.140 --> 00:04:00.360
אתם יכולים למשוך את הכרטיס שלו וללמוד כל מה שצריך כדי לעבוד איתו

00:04:00.360 --> 00:04:03.200
חישבו על כרטיס הסוכן כעל קורות חיים או כרטיס ביקור

00:04:03.200 --> 00:04:06.060
הוא אומר לסוכנים אחרים מי אתם ומה אתם מסוגלים לעשות

00:04:06.060 --> 00:04:07.980
הכרטיס מכיל את שם הסוכן

00:04:07.980 --> 00:04:10.440
תיאור טקסטואלי פשוט של היכולות שלו

00:04:10.440 --> 00:04:12.880
ותגיעות מיומנות שעוזרות בגילוי שלו

00:04:12.880 --> 00:04:16.660
הוא גם מפרט את כתובת ה-URL של נקודת הקצה שבה הוא מקבל בקשות

00:04:16.660 --> 00:04:19.960
את דרישות האימות שלו ואת פורמטי הקלט והפלט שהוא מקבל

00:04:19.960 --> 00:04:21.280
הנה דוגמה קונקרטית

00:04:21.280 --> 00:04:23.480
נניח שיש לך סוכן מומחה למזג אוויר

00:04:23.480 --> 00:04:24.640
כרטיס הסוכן שלו אומר

00:04:24.640 --> 00:04:28.060
אני יכול לספק מזג אוויר נוכחי ותחזית למד מינוס חמישה ימים לכל עיר

00:04:28.060 --> 00:04:30.460
הוא מפרט את נקודות הקצה של ה-API שלו

00:04:30.460 --> 00:04:33.840
כשהוא מקבל שם עיר ומחזיר טמפרטורה ותנאים בפורמט JSON

00:04:33.840 --> 00:04:34.980
זה כל העניין

00:04:34.980 --> 00:04:37.600
זו פשוט הצהרה ברורה של מה הוא יכול לעשות

00:04:37.600 --> 00:04:39.720
ללא סודות או לוגיקה פנימית חשופה

00:04:39.720 --> 00:04:40.880
גילוי עובד כך

00:04:40.880 --> 00:04:44.400
לסוכן מתזמר יש רשימה של כתובות URL של סוכנים מוכרים

00:04:44.400 --> 00:04:45.760
או שניתן להגדיר לאותן

00:04:45.760 --> 00:04:48.520
כשמשימה מגיעה המתזמר מושך את כרטיסי הסוכן

00:04:48.520 --> 00:04:51.620
קורא את התיאורים ומחליט איזה סוכן הוא ההתאמה הטובה ביותר

00:04:51.620 --> 00:04:53.360
כרטיס מזג האוויר אומר מזג אוויר

00:04:53.360 --> 00:04:54.960
אז משימות מזג אוויר הולכות לשם

00:04:54.960 --> 00:04:56.460
כרטיס המלונות אומר מלונות

00:04:56.460 --> 00:04:58.040
אז משימות מלונות הולכות לשם

00:04:58.040 --> 00:05:00.060
שימו לב שלא נדרש רישום מרכזי

00:05:00.060 --> 00:05:02.440
סוכנים לא צריכים להירשם במדריך גלובלי

00:05:02.440 --> 00:05:04.860
הם פשוט מפרסמים את הכרטיס שלהם במקום ידוע

00:05:04.860 --> 00:05:07.580
וכל סוכן אחר שמכיר את ה-URL יכול למצוא אותם

00:05:07.580 --> 00:05:11.140
זו בחירה עיצובית מכוונת ששומרת על המערכת מבוזרת וגמישה

00:05:11.140 --> 00:05:14.660
ניתן להוסיף מומחה חדש לרשת שלך על ידי מתן ה-URL שלא למתזמר

00:05:14.660 --> 00:05:16.260
והגילוי מתרחש באופן אוטומטי

00:05:16.260 --> 00:05:18.000
אז המתזמר יודע מי זמין

00:05:18.000 --> 00:05:20.100
אבל איך הם למעשה מעבירים את העבודה

00:05:20.100 --> 00:05:21.480
איך תקשורת סוכן לסוכן

00:05:21.480 --> 00:05:22.640
A2A עובדת

00:05:22.640 --> 00:05:25.960
אז המתזמר יודע אילו סוכנים זמינים דרך כרטיס הסוכן

00:05:25.960 --> 00:05:29.000
אבל איך הסוכנים האלה באמת מעבירים עבודה זה לזה

00:05:29.000 --> 00:05:30.060
התשובה פשוטה

00:05:30.060 --> 00:05:33.900
כל התקשורת מתבצעת על גבי HTTP באמצעות הודעות JSON-RPC

00:05:33.900 --> 00:05:36.500
אותו פרוטוקול שמניע את רוב שירותי האינטרנט כיום

00:05:36.500 --> 00:05:38.200
שום דבר מותאם אישית או מסובך

00:05:38.200 --> 00:05:40.800
רק תעבורת אינטרנט סטנדרטית הזורמת בין שני סוכנים

00:05:40.800 --> 00:05:41.700
הנה העניין

00:05:41.700 --> 00:05:43.040
לא כל המשימות זהות

00:05:43.040 --> 00:05:46.740
A2A תומך בשלושה דפוסי אינטראקציה שונים בהתאם למה שאתה צריך

00:05:46.740 --> 00:05:51.020
תגובה מיידית מטפלת בחיפושים מהירים שבהם הסוכן המרוחק יכול לענות באופן מיידי

00:05:51.020 --> 00:05:53.560
אתה שולח בקשה ומשיב מיד וסיימת

00:05:53.560 --> 00:05:56.960
בקשת תחזית להיום מסוכן מזג אוויר עובדת בדיוק כך

00:05:56.960 --> 00:05:58.860
תשובה הסינכרונית נכנס ויוצא

00:05:58.860 --> 00:06:00.920
סטרימינג מטפל במשימות ארוכות יותר

00:06:00.920 --> 00:06:05.360
אולי סוכן המומחה צריך לחפש במספר מסדי נתונים או להריץ ניתוח מורכב

00:06:05.360 --> 00:06:07.220
במקום לגרום לך לחכות לתגובה בודדת

00:06:07.220 --> 00:06:10.660
הסוכן שולח עדכוני סטטוס בזמן שהוא עובד באמצעות אירועים שנשלחים מהשרת

00:06:10.660 --> 00:06:14.080
אתה מקבל דוחות התקדמות לאורך הדרך ואז התוצאה הסופית מגיעה בסוף

00:06:14.080 --> 00:06:16.400
מעקב אחר משלוח חבילה עובד באותה דרך

00:06:16.400 --> 00:06:18.120
אתה רואה כל שלב כפי שהוא קורה

00:06:18.120 --> 00:06:23.640
התראה הסינכרונית מטפלת במשימות ארוכות טווח שבהן הסוכן המרוחק עשוי לקחת דקות, שעות או אפילו ימים

00:06:23.640 --> 00:06:25.700
קליטת עובד חדש היא דוגמה טובה

00:06:25.700 --> 00:06:27.440
מומחה אחד מקצה חשבונות איט

00:06:27.440 --> 00:06:30.440
בעוד אחר מטפל ברישום להטבות במשך מספר ימים

00:06:30.440 --> 00:06:34.360
סוכן הלקוח מגיש בקשה, מקבל מזהה משימה וממשיך בעבודתו

00:06:34.360 --> 00:06:37.320
מאוחר יותר, הסוכן המרוחק שולח את התוצאה דרך ובהוק

00:06:37.320 --> 00:06:41.120
הלקוח יכול גם לבדוק את ההתקדמות בכל עת על ידי תישול מזהה המשימה

00:06:41.120 --> 00:06:44.320
כל אינטראקציה עוקבת אחר אותו מבנה, הכל מאורגן כמשימה

00:06:44.320 --> 00:06:48.520
כשהלקוח שולח בקשה, הסוכן המרוחק יוצר משימה ומחזיר מזהה משימה

00:06:48.520 --> 00:06:51.760
המזהה הזה הופך לסימן המעקב לכל מה שקורה בהמשך

00:06:51.760 --> 00:06:55.000
להודעות בתוך המשימה יש תפקיד שאומר משלח אותן

00:06:55.000 --> 00:06:59.560
וחלקים שיכולים להיות טקסט פשוט, נתונים בינאריים כמו תמונות או מסמכים

00:06:59.560 --> 00:07:03.940
מתעני ג'ייסן או כתובות URL המצביעות על קבצים המאוכסנים במקום אחר

00:07:03.940 --> 00:07:09.420
אימות עוקב אחר מוסכמות רשת סטנדרטיות, או אוף, מפתחות API, הסימוני נושא, ברר טוקנס

00:07:09.420 --> 00:07:11.980
החשודים הרגילים, שום דבר חדש ללמוד כאן

00:07:11.980 --> 00:07:14.460
כרטיס הסוכן אומר ללקוח באיזו שיטת אימות להשתמש

00:07:18.520 --> 00:07:22.180
נראה בפועל, נניח שהתזמר, אורקסטרייטור, זקוק לנתוני מזג אוויר עבור טיול

00:07:22.180 --> 00:07:24.100
הוא שולח משימה למומחה מזג האוויר

00:07:24.100 --> 00:07:28.620
מומחה מזג האוויר מאשר את הבקשה, מתחיל לאבד ומזרים בחזרה עדכוני התקדמות

00:07:28.620 --> 00:07:33.780
מושך נתונים, מנתח תוצאות, בוצע, ואז הוא שולח את התחזית הסופית

00:07:33.780 --> 00:07:36.640
התזמר לעולם לא רואה את הכלים הפנימיים של סוכן מזג האוויר

00:07:36.640 --> 00:07:39.360
את מפתחות ה-API שלו או את תהליך השקת המסקנות שלו

00:07:39.360 --> 00:07:44.840
הוא רואה רק את הפלט, זהו עקרון התכנון המרכזי, גבולות ברורים בין סוכנים וללא דליפת מצב פנימי

00:07:44.840 --> 00:07:47.600
אבל תקשור את סוכן לסוכן, A2A, לבדאי אינה מספיקה

00:07:47.600 --> 00:07:50.020
צריך בוס חכם שיתאם את כל המומחים האלו

00:07:50.020 --> 00:07:52.280
זה מביא אותנו לדפוס התזמר מומחה

00:07:52.280 --> 00:07:54.180
דפוס התזמר מומחה

00:07:54.180 --> 00:07:55.520
כאן הכל מתחבר

00:07:55.520 --> 00:08:00.400
דפוס התזמר מומחה הוא הארכיטקטורה הנפוצה ביותר במערכות רב סוכניות בייצור כיום

00:08:00.400 --> 00:08:05.660
תחשבו על זה כמו חברה עם מחלקות, אית, משאבי אנוש, כספים, כל אחת מטפלת בתחום שלה

00:08:05.660 --> 00:08:11.560
יש לכם מקבל החלטות מרכזי שמנתב עבודה לצוותים מתמכים וכל צוות מתמקד במה שהוא עושה הכי טוב

00:08:11.560 --> 00:08:13.580
התזמר מחזיק את התמונה הגדולה

00:08:13.580 --> 00:08:18.900
הוא מקבל את בקשת המשתמש, מבין מה צריך לקרות ומחליט איזה מומחה יכול לטפל בכל חלק

00:08:18.900 --> 00:08:22.060
אם משתמש מבקש, תכנן טיול לסיאטל בשבוע הבא

00:08:22.060 --> 00:08:24.880
התזמר לא מזמין טיסות או בודק מלונות בעצמו

00:08:24.880 --> 00:08:28.640
הוא יודע שיש מומחה טיסות, מומחה מלונות ומומחה מזג אוויר

00:08:28.640 --> 00:08:32.000
הוא מפרק את הבקשה לחלקים האלו ומעציל כל אחד מהם

00:08:32.000 --> 00:08:33.680
לכל מומחה יש מיקוד צר

00:08:33.680 --> 00:08:38.100
סוכן אחד מטפל בהזמנת טיסות, אחר בחיפוש מלונות ושלישי במיון אירועים חריגים

00:08:38.100 --> 00:08:40.440
הם לא צריכים לדעת דבר על התחומים זה של זה

00:08:40.440 --> 00:08:43.360
מומחה הטיסות מכיר חברות תעופה, מסלולים ותמחור

00:08:43.360 --> 00:08:47.080
הוא לא צריך לדעת שום דבר על סוגי חדרים במלון או מדיניות ביטולים

00:08:47.080 --> 00:08:51.280
המיקוד הצר הזה שומר על כל סוכן פשוט, קל לתחזוקה וקל לבדיקה

00:08:51.280 --> 00:08:52.620
הנה החלק החשוב

00:08:52.620 --> 00:08:54.620
המתזמר לא מבצע את המשימות

00:08:54.620 --> 00:08:56.600
הוא מנתב עבודה ומאחד תוצאות

00:08:56.600 --> 00:08:58.060
זה התפקיד היחיד שלו

00:08:58.060 --> 00:09:02.240
תפקיד המתזמר הוא להיות דיספאצ'ר חכם, לא סוכן על שמנסה לעשות הכל

00:09:02.240 --> 00:09:04.720
כשנותנים למתזמר להתחיל לבצע עבודת מומחים

00:09:04.720 --> 00:09:06.700
מאבדים את כל היתרון של התבנית

00:09:06.700 --> 00:09:08.380
זה הופך שוב לבלגן מונוליטי

00:09:08.380 --> 00:09:09.860
היזהרו מטעות נפוצה

00:09:09.860 --> 00:09:12.300
יש צוותים שיוצרים תחומי מומחיות חופפים

00:09:12.300 --> 00:09:16.480
שני סוכנים שטוענים שניהם שהם יכולים לטפל בתמיכת לקוחות או בחיפוש נתונים

00:09:16.480 --> 00:09:17.900
מה שיוצר בלבול בניתוב

00:09:17.900 --> 00:09:19.640
המתזמר לא יודע במי לבחור

00:09:19.640 --> 00:09:21.820
והמשתמשים מקבלים תוצאות לא עקביות

00:09:21.820 --> 00:09:23.260
התיקון פשוט למדי

00:09:23.260 --> 00:09:26.220
כל מומחה מחזיק תחום מוגדר בבירור ללא חפיפה

00:09:26.220 --> 00:09:27.980
אם שני סוכנים יכולים לעשות את אותו הדבר

00:09:27.980 --> 00:09:30.260
יש למזג אותם או לפצל את התחום בצורה נקייה יותר

00:09:30.260 --> 00:09:33.460
Copilot Studio של מייקרוסופט משתמש בתבנית הזו באופן מובנה

00:09:33.460 --> 00:09:35.500
הקופילות הראשי שלך משמש כמתזמר

00:09:35.500 --> 00:09:38.040
בעוד סוכני משנה וסוכנים מחוברים משמשים כמומחים

00:09:38.040 --> 00:09:40.820
כשמשתמש שואל משהו שמסתרה על פני תחומים מרובים

00:09:40.820 --> 00:09:44.380
הקופילות הראשי מעציל סמכויות למומחים המתאימים דרך A2A

00:09:44.380 --> 00:09:45.580
זה מובנה בפלטפורמה

00:09:45.580 --> 00:09:48.280
כך שלא צריך לתכנת את לוגיקת התזמור מאפס

00:09:48.280 --> 00:09:50.240
היתרון הגדול כאן הוא מודולריות

00:09:50.240 --> 00:09:52.680
צריך להחליף את ספק הזמנת המלונות שלך

00:09:52.680 --> 00:09:56.260
החליפו את מומחי המלונות מבלי לגעת במתזמר או בכל סוכן אחר

00:09:56.260 --> 00:09:57.620
מוסיפים יכולת חדשה

00:09:57.620 --> 00:09:58.720
בנו מומחה חדש

00:09:58.720 --> 00:10:00.160
רשמו אותו אצל המתזמר

00:10:00.160 --> 00:10:00.860
וסיימתם

00:10:00.860 --> 00:10:02.200
כל סוכן נשאר קטן

00:10:02.200 --> 00:10:04.500
ניתן לניהול וניתן לפריסה באופן עצמאי

00:10:04.500 --> 00:10:07.880
זו כל הנקודה במעבר מסוכנים מונוליטיים למערכת מרובת סוכנים

00:10:07.880 --> 00:10:09.360
אז יש לנו את הפרוטוקול

00:10:09.360 --> 00:10:10.840
את כרטיסי הסוכן ואת התבנית

00:10:10.840 --> 00:10:13.100
בואו נראה את זה בפעולה עם תרחישים אמיתיים

00:10:13.100 --> 00:10:15.360
דוגמאות אמיתיות ל-A2A בפעולה

00:10:15.360 --> 00:10:18.000
אז איך A2A באמת נראה בעולם האמיתי

00:10:18.000 --> 00:10:19.520
נתחיל עם דוגמה פשוטה

00:10:19.520 --> 00:10:21.300
אתה אומר לעוזר ה-AI שלך

00:10:21.300 --> 00:10:23.280
תכנן טיול לסיאטל בשבוע הבא

00:10:23.280 --> 00:10:24.760
בדרך הישנה לעשות דברים

00:10:24.760 --> 00:10:26.800
אותו עוזר בודד היה צריך לדעת הכל

00:10:26.800 --> 00:10:29.180
מזג אוויר, טיסות, מלונות, מסעדות

00:10:29.180 --> 00:10:30.060
הכל בבת אחת

00:10:30.060 --> 00:10:31.980
זו בקשה גדולה מדי מהנחיה אחת

00:10:31.980 --> 00:10:34.260
עם A2A המתזמר מפרק את זה

00:10:34.260 --> 00:10:36.120
הוא שולח משימה למומחה מזג אוויר

00:10:36.120 --> 00:10:38.360
ומבקש את התחזית לימים הספציפיים האלו

00:10:38.360 --> 00:10:38.980
במקביל

00:10:38.980 --> 00:10:42.220
הוא מבקש ממומחה טיסות למצוא טיסות המגיעות ביום שלישי בבוקר

00:10:42.220 --> 00:10:43.600
וחוזרות ביום חמישי בערב

00:10:43.600 --> 00:10:45.560
וממומחה מלונות לחפש מקומות לינה

00:10:45.560 --> 00:10:47.700
ליד מרכז סיאטל למד מינוס שלושה לילות

00:10:47.700 --> 00:10:49.480
כל מומחה עובד באופן עצמאי

00:10:49.480 --> 00:10:51.660
והם לא צריכים לדבר עם סוכנים אחרים

00:10:51.660 --> 00:10:53.700
כי לכל אחד יש את מקורות הנתונים

00:10:53.700 --> 00:10:55.220
הכלים והמומחיות שלו

00:10:55.220 --> 00:10:57.260
המתזמר אוסף את כל התוצאות

00:10:57.260 --> 00:10:58.800
ומאחד אותן לתשובה אחת

00:10:58.800 --> 00:11:00.980
המשתמש רואה תשובה אחת בלבד

00:11:00.980 --> 00:11:02.000
הנה התחזית

00:11:02.000 --> 00:11:03.480
אלו אפשרויות הטיסה שלך

00:11:03.480 --> 00:11:05.400
והנה שלושה מלונות ליד המשרד

00:11:05.400 --> 00:11:06.420
מאחורי הקלעים

00:11:06.420 --> 00:11:08.820
שלושה סוכנים נפרדים עבדו יחד ללא צורך

00:11:08.820 --> 00:11:10.280
בקוד אינטגרציה מותאם אישי

00:11:10.280 --> 00:11:11.600
כעת תרחיש עסקי

00:11:11.600 --> 00:11:12.780
נניח שמגיעה פנייה

00:11:12.780 --> 00:11:15.100
המחשב הנייד שלי לא מתחבר לבי פי אנ

00:11:15.100 --> 00:11:17.580
המתזמר מבין שמדובר בבעיית רשת

00:11:17.580 --> 00:11:19.600
הוא מעביר את הפנייה למומחה נהלים

00:11:19.600 --> 00:11:21.480
שמכיר את הצעדים הסטנדרטיים

00:11:21.480 --> 00:11:23.480
בדיקת מצב לכוח הווי פי אנ

00:11:23.480 --> 00:11:24.740
עימות פרטי הרשת

00:11:24.740 --> 00:11:26.260
והפעלה מחדש של השירות

00:11:26.260 --> 00:11:28.420
אותו מומחה מחזיר את הצעדים לביצוע

00:11:28.420 --> 00:11:30.780
לאחר מכן המתזמר מעביר את התוצאה

00:11:30.780 --> 00:11:31.840
למומחה כתיבת פניות

00:11:31.840 --> 00:11:33.420
שמתעד את הפתרון במערכת

00:11:33.420 --> 00:11:35.920
כל זה קורה בשניות ללא מגע יד אדם

00:11:35.920 --> 00:11:38.840
וצוות האית מתערב רק אם הצעדים האוטומטיים

00:11:38.840 --> 00:11:39.900
לא פטרו את הבעיה

00:11:39.900 --> 00:11:42.020
קליטת עובד חדש היא דוגמה נוספת

00:11:42.020 --> 00:11:44.220
אבל הפעם זה לוקח ימים, לא שניות

00:11:44.220 --> 00:11:46.060
עובד חדש מצטרף לחברה

00:11:46.060 --> 00:11:47.640
המתזמר מפעיל מומחה אית

00:11:47.640 --> 00:11:49.760
ליצירת חשבונות והקצאת חומרה

00:11:49.760 --> 00:11:51.560
מה שעשוי לקחת כמה שעות

00:11:51.560 --> 00:11:54.840
במקביל הוא מפעיל מומחה הטוות כוח אדם לטפסי הרשמה

00:11:54.840 --> 00:11:58.040
ומאוחר יותר מומחה מתקנים לגישה לשולחן ולטג עובד

00:11:58.040 --> 00:12:01.080
כל מומחה מריץ את המשימה הממושכת שלא באופן עצמאי

00:12:01.080 --> 00:12:05.140
והמתזמר עוקב אחר ההתקדמות באמצעות מזהי המשימות שדיברנו עליהם קודם

00:12:05.140 --> 00:12:07.840
כך שאם מומחה האית מסיים, המתזמר יודע זאת

00:12:07.840 --> 00:12:10.680
ואם מומחה המתקנים מתעכב, הוא יכול לבצע מעקב

00:12:10.680 --> 00:12:12.640
המשתמש רואה תהליך קליטה חלק

00:12:12.640 --> 00:12:16.060
אך מאחורי הקלעים מדובר בצוות מתואם שעובד לאורך ימים

00:12:16.060 --> 00:12:17.220
וזו לא רק תיאוריה

00:12:17.220 --> 00:12:18.960
חברת קוקה קולה בבראג'ז אפריקה

00:12:18.960 --> 00:12:22.060
כבר משתמשת בסוכני קופיילוט סטודיו עם דיינמיקס 365

00:12:22.060 --> 00:12:24.100
כדי לבצע אוטומציה למחזורי תכנון

00:12:24.100 --> 00:12:28.000
המתכננים שלהם נהגו להשקיע עד שעה וחצי בכל יום במשימות חוזרות

00:12:28.000 --> 00:12:31.060
אם תזמור רב סוכנים, המחזורים האלו רצים בעצמם

00:12:31.060 --> 00:12:34.240
המתזמר מעציל סמכויות למומחים שמטפלים בחלקים שונים

00:12:34.240 --> 00:12:35.940
בתהליך תכנון שרשרת ההספקה

00:12:35.940 --> 00:12:38.760
התוצאה היא חיסכון של יותר משעה לאדם בכל יום

00:12:38.760 --> 00:12:41.300
רק על ידי מתן אפשרות לסוכנים לדבר זה עם זה

00:12:41.300 --> 00:12:43.420
במקום שאנשים יעבירו מידע בין מערכות

00:12:43.420 --> 00:12:45.940
אם כן, הדפוס זהה בכל הדוגמאות האלו

00:12:45.940 --> 00:12:49.820
כל סוכן הוא מומחה עצמאי שמכיר את התחום שלו ובעל כלים משלו

00:12:49.820 --> 00:12:52.280
והוא לא צריך לדעת דבר על הסוכנים האחרים

00:12:52.280 --> 00:12:54.640
A2M מספקת שכבת תקשורת פשוטה

00:12:54.640 --> 00:12:57.160
המאפשרת להם לשתף פעולה ללא קוד מוטעם אישית

00:12:57.160 --> 00:13:00.400
אתם מקבלים פרוטוקול סטנדרטי ותזמור חכם ללא גישורים

00:13:00.400 --> 00:13:03.360
ללא אינטגרציות נקודתיות וללא כאבי ראש בתחזוקה

00:13:03.360 --> 00:13:05.240
מייקרוסופט מושקעת בזה באופן מלא

00:13:05.240 --> 00:13:08.460
בואו נראה היכן Copilot Studio ו-Azure AI נכנסים לתמונה

00:13:08.460 --> 00:13:11.920
האקו סיסטם של מייקרוסופט, Copilot Studio ו-Azure AI

00:13:11.920 --> 00:13:13.840
אז איפה מייקרוסופט נמצאת בכל זה?

00:13:14.020 --> 00:13:14.900
ממש במרכז

00:13:14.900 --> 00:13:17.500
Copilot Studio תומך כעת ב-A2A באופן טבעי

00:13:17.500 --> 00:13:20.200
וזה זמין לכלל המשתמשים מאז אפריל 2026

00:13:20.200 --> 00:13:22.240
זו לא גרסת תצוגה מקדימה או בתא

00:13:22.240 --> 00:13:25.420
זה מוכן לייצור וכל לקוח זכאי יכול להשתמש בזה היום

00:13:25.420 --> 00:13:26.140
זה העניין

00:13:26.140 --> 00:13:29.560
ניתן לחבר סוכנים חיצוניים לתזמר הקופילות סטודיו שלכם

00:13:29.560 --> 00:13:32.220
כשאני אומר חיצוניים, אני מתכוון חיצוניים באמת

00:13:32.220 --> 00:13:37.660
סוכנים שנבנו בגוגל קלאוד, ב-AWS או בכל פלטפורמה אחרת שתומכת בפרוטוקול A2A

00:13:37.660 --> 00:13:41.060
לתזמר לא אכפת איפה הסוכן נמצא או עם איזו תשתית הוא נבנה

00:13:41.060 --> 00:13:43.780
כל עוד הוא דובר A2A, הוא יכול להצטרף לצוות

00:13:43.780 --> 00:13:44.880
ההגדרה פשוטה

00:13:50.200 --> 00:13:55.200
קופילות סטודיו מושך אוטומטית את כרטיס הסוכן מאותה כתובת URL

00:13:55.200 --> 00:13:57.420
שהוא קובץ הג'סון המוכר שדיברנו עליו

00:13:57.420 --> 00:14:01.620
הוא קורא את יכולות הסוכן, דרישות האימות ופורמטי הקלט והפלט

00:14:01.620 --> 00:14:04.260
לאחר מכן הוא בונה מחבר מוטעם מאחורי הקלעים

00:14:04.260 --> 00:14:07.020
והתזמר שלכם יכול להתחיל להאציל משימות באופן מיידי

00:14:07.020 --> 00:14:09.880
אתם לא צריכים עבודת אינטגרציה ידנית או קוד מוטעם אישית

00:14:09.880 --> 00:14:12.100
פשוט מדביקים את ה-URL וסיימתם

00:14:12.100 --> 00:14:15.880
בצד של Azure, גם שירות הסוכנים של Azure Eye Foundry תומך ב-A2A

00:14:15.880 --> 00:14:19.720
יש לו נקודת קצה יהודית ל-API של A2A המאפשרת לתזמרים בקוד פתוח

00:14:19.720 --> 00:14:23.020
כמו Autogen, Langchain ו-Semantic Carnal להפעיל סוכני פאונדרי

00:14:23.020 --> 00:14:25.320
אז אם בניתם סוכנים באמצעות התשתיות האלה

00:14:25.320 --> 00:14:28.760
תוכלו לחבר אותם לעקו סיסטם של מייקרוסופט מבלי לשכתב דבר

00:14:28.760 --> 00:14:30.040
זה כביש דו-סיטרי

00:14:30.040 --> 00:14:33.560
מייקרוסופט עוקבת אחר אותו דפוס של תזמר מומחה שתיארנו

00:14:33.560 --> 00:14:36.700
הסוכן הראשי בקופילות סטודיו משמש כתזמר

00:14:36.700 --> 00:14:39.260
בעוד שסוכני משנה וסוכנים מחוברים הם המומחים

00:14:39.260 --> 00:14:42.600
כל אחד מטפל בתחום שלו והתזמר מנתיו וממזג

00:14:42.600 --> 00:14:45.940
זו אותה ארכיטקטורה רק רצה על הפלטפורמה של מייקרוסופט

00:14:45.940 --> 00:14:48.840
אבל הנה העניין, יש כמה מגבלות שצריך להכיר

00:14:48.840 --> 00:14:51.540
ראשית, כל דילוג תזמור נוסף מוסיף השיה

00:14:51.540 --> 00:14:54.100
אם הסוכן הראשי שלכם קורא לסוכן מחובר

00:14:54.100 --> 00:14:56.240
ואותו סוכן מחובר קורא למומחה אחר

00:14:56.240 --> 00:14:57.680
כל דילוג מוסיף זמן רשת

00:14:57.680 --> 00:15:01.620
בשיחות בזמן אמת, יותר מדי דילוגים עלולים להפוך את החוויה לעתית

00:15:01.620 --> 00:15:04.260
שנית, ההצלת יתר יוצרת כאוס ניתוב

00:15:04.260 --> 00:15:07.340
אם יש לכם יותר מדי מומחים עם תחומי אחריות חופפים

00:15:07.340 --> 00:15:09.580
התזמר מתחיל לקבל החלטות ניתוב שגויות

00:15:09.580 --> 00:15:13.500
אז הקפידו על מספר מומחים שניתן לנהל ועל הפרדה ברורה בין התחומים

00:15:13.500 --> 00:15:16.880
שלישית, קיימת מגבלה ספציפית לגבי סוכני נתונים בפבריק

00:15:16.880 --> 00:15:20.780
הם אינם פועלים כאשר הסוכן הראשי מוטמע במיקרוסופט 365 קופיילוט

00:15:20.780 --> 00:15:24.200
אם הפריסה שלכם מכוונת לאם 365, תכננו זאת בהתאם

00:15:24.200 --> 00:15:26.700
המגבלות הללו אמיתיות, אכן ניתנות לניהול

00:15:26.700 --> 00:15:31.340
הפלטפורמה בשלה מספיק לשימוש ייצורי ומייקרוסופט פועלת לסגירת הפערים הללו

00:15:31.340 --> 00:15:34.340
כעת בואו נחבר את הנקודות ונראה את התמונה הגדולה

00:15:34.340 --> 00:15:36.560
סעיף חיבור, איך הכל משתלב יחד

00:15:36.560 --> 00:15:39.140
בואו ניקח צעד אחורה ונראה איך החלקים הללו מתחברים

00:15:39.140 --> 00:15:42.200
A2A היא מערכת הטלפון שסוכנים משתמשים בה כדי להתקשר זה לזה

00:15:42.200 --> 00:15:44.480
כרטיסי הסוכן הם למעשה ספר הטלפונים שלכם

00:15:44.480 --> 00:15:46.740
הם מראים לכם למי להתקשר ומה כל סוכן מבצע

00:15:46.740 --> 00:15:49.360
המתזמר הוא הפקיד שמנתב כל שיחה למחלקה הנכונה

00:15:49.360 --> 00:15:51.260
אף אחד מהחלקים הללו לא עובד לבדו

00:15:51.260 --> 00:15:52.500
אתם צריכים את שלושתם

00:15:52.500 --> 00:15:54.840
בלי ספר טלפונים אינכם יודעים למי להתקשר

00:15:54.840 --> 00:15:57.160
בלי פקיד אף אחד לא מכוון את התנועה

00:15:57.160 --> 00:16:00.160
ובלי מערכת טלפון פקיד לא יכול לחבר אף אחד

00:16:00.160 --> 00:16:01.480
הם עובדים רק כצוות

00:16:01.480 --> 00:16:03.420
זה המקום שבו נכנסת המודולריות

00:16:03.420 --> 00:16:04.880
כשהמומחים שלכם מודולריים

00:16:04.880 --> 00:16:07.520
ניתן להוסיף יכולות חדשות בלי לשבור את מה שכבר עובד

00:16:07.520 --> 00:16:10.320
נניח שאתם רוצים להוסיף מומחי הזכרת רכב לעוזר הנסיעות שלכם

00:16:10.320 --> 00:16:12.320
אתם בונים אותו, מפרסמים את כרטיס הסוכן שלו

00:16:12.320 --> 00:16:13.880
ונותנים למתזמר את ה-URL שלו

00:16:13.880 --> 00:16:14.560
סיימתם

00:16:14.560 --> 00:16:17.600
מומחי הטיסות ומומחי המלונות נשארים בדיוק אותו הדבר

00:16:17.600 --> 00:16:19.080
גם המתזמר לא משתנה

00:16:19.080 --> 00:16:22.100
אתם פשוט מחברים חלק חדש והמערכת מסתגלת

00:16:22.100 --> 00:16:23.580
מכיוון שהפרוטוקול פתוח

00:16:23.580 --> 00:16:25.360
לעולם לא תיתקעו עם ספק יחיד

00:16:25.360 --> 00:16:27.920
המתזמר שלכם יכול לרוץ בקופילות סטודיו

00:16:27.920 --> 00:16:29.880
סוכן מזג האוויר בגוגל קלאוד

00:16:29.880 --> 00:16:31.620
סוכן המלונות ב-AWS

00:16:31.620 --> 00:16:33.340
והמערכות הפנימיות ב-Azure

00:16:33.340 --> 00:16:35.000
כולם מדברים את אותה השפה

00:16:35.000 --> 00:16:36.580
זו היופי בטקן פתוח

00:16:36.580 --> 00:16:40.260
הוא מונה התלות בספק ומאפשר לכם לבחור את הכלי הטוב ביותר לכל עבודה

00:16:40.260 --> 00:16:43.220
A2A אינו עוסק בבניית סוכן על חכם שיודע הכל

00:16:43.220 --> 00:16:46.860
הוא עוסק בבניית כוח עבודה גמיש של מומחים שניתן לארגן מחדש כשהצרכים משתנים

00:16:46.860 --> 00:16:48.360
אתם לא מחליפים את הסוכנים שלכם

00:16:48.360 --> 00:16:49.420
אתם מארגנים אותם מחדש

00:16:49.420 --> 00:16:50.560
אתם מוסיפים חדשים

00:16:50.560 --> 00:16:52.000
אתם מחליפים את הישנים

00:16:52.000 --> 00:16:54.640
המערכת צומחת יחד איתכם במקום להפוך לצוואר בקבוק

00:16:54.640 --> 00:16:56.940
אז מה אתם יכולים לעשות עם הידע הזה היום?

00:16:57.060 --> 00:16:58.040
תובנות מעשיות

00:16:58.040 --> 00:16:59.120
התחילו בקטן

00:16:59.120 --> 00:17:03.140
בחרו תהליך אחד חזרתי בארגון שלכם שכולל מספר מערכות

00:17:03.140 --> 00:17:06.300
פתרון כרטיסים, קליטת עובדים או דיווח הוצאות

00:17:06.300 --> 00:17:06.880
למשל

00:17:06.880 --> 00:17:09.160
משהו אם העברות ברורות בין שלבים

00:17:09.160 --> 00:17:12.120
לאחר מכן בנו אב טיפוס עם מתזמר אחד ושני מומחים

00:17:12.120 --> 00:17:13.940
אתם לא צריכים ארכיטקטורה גרנדיוזית

00:17:13.940 --> 00:17:16.340
אתם רק צריכים דוגמה עובדת שניתן ללמוד ממנה

00:17:16.340 --> 00:17:18.240
משתמש בחלים שכבר תומכים בכך

00:17:18.240 --> 00:17:20.680
לקו-פיילוט סטודיו יש תמיכה מובנית באש טיים-אה

00:17:20.680 --> 00:17:22.120
וגם לאזר אי-פאונדרי יש

00:17:22.120 --> 00:17:25.520
אינך צריך לבנות את הפרוטוקול מאפס או לכתוב קוד אינטגרציה מותאם אישית

00:17:25.520 --> 00:17:26.580
הדבק כתובת URL

00:17:26.580 --> 00:17:28.920
הגדר את הסוכנים שלך והתחל להאציל סמכויות

00:17:28.920 --> 00:17:30.420
שים לב למלכודות נפוצות

00:17:30.420 --> 00:17:32.820
ודש את תחומי המומחיות של הסוכנים שלך לא חופפים

00:17:32.820 --> 00:17:34.500
אם שני סוכנים יכולים לעשות את אותו הדבר

00:17:34.500 --> 00:17:36.360
אמצע אותם או פצל את התחום בצורה ברורה יותר

00:17:36.360 --> 00:17:38.560
תן לה מתזמר לטפל בניתוב לא בביצוע

00:17:38.560 --> 00:17:40.700
ושמור על השעיה הנובעת מניתוב בין סוכנים

00:17:40.700 --> 00:17:42.060
אם זמן התגובה מתחיל לעלות

00:17:42.060 --> 00:17:44.300
ייתכן שיש לך יותר מידי שכבות של ההצלת סמכויות

00:17:44.300 --> 00:17:46.040
הצעד הראשון הטוב ביותר הוא פשוט

00:17:46.040 --> 00:17:48.660
מפה את העברות המידע בזרימת העבודה הקיימת שלך

00:17:48.660 --> 00:17:51.120
איפה עובר מידע בין אנשים או בין מערכות

00:17:51.120 --> 00:17:53.400
אלו המקומות שבהם סוכנים יכולים להשתלט

00:17:53.400 --> 00:17:55.180
כל העברת מידע היא הזדמנות

00:17:55.180 --> 00:17:57.740
אז זהו מערך ה-A2-A על רגל אחת

00:17:57.740 --> 00:17:59.760
שלושה חלקים פשוטים שעובדים יחד

00:17:59.760 --> 00:18:02.860
סוכנים מפסיקים להיות מבודדים ומתחילים לפעול כצוות אמיתי

00:18:02.860 --> 00:18:05.000
מחר זרימת עבודה אחת עם העברות ברורות

00:18:05.000 --> 00:18:05.960
והתחל לבנות משם

00:18:05.960 --> 00:18:07.540
הרשם לעוד הסברים פשוטים

00:18:07.540 --> 00:18:09.480
והשאר תגובה אם משהו התחבר לך