WEBVTT

00:00:00.160 --> 00:00:01.860
Вітаємо на черговій порції знань.

00:00:01.980 --> 00:00:04.860
Уявіть, що ви керуєте компанією і найняли команду геніальних фахівців,

00:00:04.960 --> 00:00:08.760
першокласного плановальника подорожей, експерта з адаптації персоналу та спеціаліста з іТ-підтримки.

00:00:08.880 --> 00:00:10.760
Але ніхто з них не спілкується один з одним.

00:00:11.000 --> 00:00:15.500
Щоразу, коли завдання потребує участі двох із них, вам доводиться ходити між столами і самому передавати інформацію.

00:00:15.680 --> 00:00:17.800
Саме так зараз працює більшість AI-агентів.

00:00:17.980 --> 00:00:21.320
Вони діють ізольовано, навіть коли для вирішення проблеми явно потрібна командна робота.

00:00:21.320 --> 00:00:25.740
Тож сьогодні ми поговоримо про те, як агенти можуть спілкуватися, передавати роботу та діяти як справжні команди.

00:00:25.880 --> 00:00:28.760
Я – Мірко Петерс. Це не якась футуристична концепція.

00:00:29.080 --> 00:00:30.980
Мультиагентна оркестрація вже відбувається.

00:00:31.120 --> 00:00:33.680
І вона працює завдяки протоколу під назвою A2AI.

00:00:33.840 --> 00:00:36.820
Ми почнемо з проблеми, розберемо цей протокол по частинах і подивимося,

00:00:36.920 --> 00:00:39.760
як Майкрософт використовує його в Coopilot Studio та Azure AI.

00:00:39.940 --> 00:00:41.180
Беріть каву і погнали.

00:00:41.380 --> 00:00:42.980
Отже, у чому справжня проблема?

00:00:43.320 --> 00:00:46.140
Сьогоднішні AI-агенти – це точно такі ж ізольовані фахівці.

00:00:46.140 --> 00:00:48.600
Кожен має власні знання, інструменти та цілі.

00:00:48.720 --> 00:00:50.460
Агент прогнозу погоди знає прогноз.

00:00:50.600 --> 00:00:53.460
Агент готелів знає про наявність місць, але вони нічим не діляться.

00:00:53.620 --> 00:00:57.880
Тепер уявіть користувача, який планує поїздку до Сіятла наступного тижня і шукає готель біля офісу.

00:00:58.040 --> 00:01:02.180
Єдиний агент мав би одночасно бути експертом з погоди, подорожей і місцевого бізнесу.

00:01:02.300 --> 00:01:08.120
Це означає величезні роздуті запити, які намагаються втиснути всі можливості в одну систему, і такі запити постійно ламаються.

00:01:08.120 --> 00:01:10.500
Старим рішенням був спеціальний програмний код.

00:01:10.640 --> 00:01:17.180
Ви писали міст між агентом погоди та агентом готелів, потім ще один між готельним і авіаційним агентами, і ще один для агента календаря.

00:01:17.340 --> 00:01:21.440
Спочатку це працює, але щоразу, коли ви додаєте нового агента, ви будуєте ще одну інтеграцію.

00:01:21.640 --> 00:01:25.320
Дуже скоро ви отримуєте спагеті-кошмар із прямих з'єднань, де одна зміна ламає все.

00:01:25.500 --> 00:01:29.500
Зростання продуктивності, яке мав забезпечити AI, з'їдається роботою з обслуговування системи.

00:01:29.500 --> 00:01:31.460
Давайте подивимося на реальний бізнес-біль.

00:01:31.600 --> 00:01:34.200
У вашій організації вже є процеси з передачею завдань.

00:01:34.360 --> 00:01:38.960
Створюється тікет, хтось його сортує, хтось вирішує, хтось реєструє, і кожен крок є етапом передачі.

00:01:39.080 --> 00:01:43.860
У старому світі ви автоматизуєте кожен крок окремим агентом, а потім тижнями витрачаєте час, щоб з'єднати їх між собою.

00:01:44.000 --> 00:01:48.980
Але що, якби існував протокол, який дозволяв би агентам знаходити один одного та співпрацювати без жодних спеціальних мостів?

00:01:49.100 --> 00:01:50.800
Це саме те, що робить A2A.

00:01:50.800 --> 00:01:56.440
Простою мовою, A2A – це стандартний спосіб для агентів спілкуватися, передавати роботу та досягати цілий як одна команда.

00:01:56.620 --> 00:01:57.720
Що таке A2A?

00:01:57.840 --> 00:01:58.940
Просте визначення.

00:01:59.100 --> 00:02:01.040
A2A означає агент-агенту.

00:02:01.180 --> 00:02:05.460
Це відкритий протокол, що дозволяєши агентам спілкуватися безпосередньо між собою, незалежно від того, хто їх створив.

00:02:05.600 --> 00:02:07.860
Ви можете сприймати це як HTTP для агентів.

00:02:07.960 --> 00:02:12.840
HTTP – це мова, якою спілкуються веб-браузери та сервери, а A2A робить те саме для агентів.

00:02:12.840 --> 00:02:20.940
Агент, створений вашою ІТ-командою в Microsoft Co-Pilot Studio, може спілкуватися з агентом іншої компанії в Google Cloud, якщо обидва підтримують A2A.

00:02:21.100 --> 00:02:22.660
Це також немаленький проєкт.

00:02:22.820 --> 00:02:31.080
A2A спонсорується вісьмома великими компаніями, включаючи Google, Microsoft, Cisco, Salesforce, SAP та інші, і розміщується Linux Foundation.

00:02:31.320 --> 00:02:37.100
Версія 1.0 є стабільною та готовою до реального використання, що означає, що жоден окремий вендор не контролює протокол.

00:02:37.220 --> 00:02:38.880
Це не розробка Google чи Microsoft.

00:02:39.180 --> 00:02:40.540
Це індустріальний стандарт.

00:02:40.540 --> 00:02:42.360
Дизайн свідомо зроблений простим.

00:02:42.360 --> 00:02:47.860
A2A базується на існуючих веб-стандартах, таких як HTTP та JSON-RPC, які вже знає кожен розробник.

00:02:47.940 --> 00:02:50.080
Тут немає нічого екзотичного чи закритого.

00:02:50.280 --> 00:02:54.500
Це дозволяє підприємствам легко впроваджувати його без заміни існуючої інфраструктури.

00:02:54.640 --> 00:02:58.720
Можливо, ви чули про інший протокол під назвою MCP або Model Context Protocol.

00:02:58.960 --> 00:03:00.060
Ось у чому різниця.

00:03:00.200 --> 00:03:04.540
MCP – це зв'язок-агент-інструмент, тобто він підключає агента до зовнішніх джерел, даних та ARRI.

00:03:04.680 --> 00:03:08.240
A2A – це зв'язок-агент-агент, що з'єднує агентів безпосередньо один з одним.

00:03:12.360 --> 00:03:17.980
Мирикальне з'єднання агента з його інструментами, а A2A – як горизонтальний зв'язок між агентами.

00:03:18.160 --> 00:03:19.840
Ще одне конструктивне рішення.

00:03:20.000 --> 00:03:22.360
A2A розглядає агентів як чорні скриньки.

00:03:22.500 --> 00:03:27.200
Тому, коли один агент спілкується з іншим, він не бачить внутрішніх міркувань, інструментів чи приватних даних іншого агента.

00:03:27.380 --> 00:03:30.280
Він бачить лише надіслане завдання та результат, який отримує у відповідь.

00:03:30.360 --> 00:03:32.820
Це зберігає конфіденційність та інтелектуальну власність.

00:03:32.820 --> 00:03:37.620
Агенту погоди не потрібно знати, як готельний агент бронює номери, йому потрібно лише передати прогноз.

00:03:37.740 --> 00:03:40.880
Тепер розглянемо перший елемент пазла – картку агента.

00:03:41.100 --> 00:03:42.900
Картка агента – це його резюме.

00:03:43.060 --> 00:03:47.240
Кожен сумісний Z2A-агент публікує документ, що називається карткою агента.

00:03:47.420 --> 00:03:52.740
Ця картка є машиносчитованим документом, який розміщується за стандартною URL-адресою на домені агента,

00:03:52.880 --> 00:03:55.480
зокрема за шляхом Well-known agent CAD.JSON.

00:03:55.480 --> 00:04:00.300
Якщо ви знаєте, де знаходиться агент, ви можете отримати його картку і дізнатися все необхідне для роботи з ним.

00:04:00.460 --> 00:04:03.140
Сприймайте картку агента як резюме або візитну картку.

00:04:03.340 --> 00:04:06.340
Вона повідомляє іншим агентам, хто ви і що ви можете робити.

00:04:06.520 --> 00:04:12.580
Картка містить ім'я агента, текстовий опис його можливостей та теги навичок, що допомагають у пошуку.

00:04:12.940 --> 00:04:19.920
Тут також вказано URL-адресу кінцевої точки для запитів, вимоги до автентифікації, а також формати вхідних і вихідних даних.

00:04:19.920 --> 00:04:21.200
Ось конкретний приклад.

00:04:21.200 --> 00:04:27.960
Припустімо, у вас є агент-фахівець із погоди. У його картці агента сказано, я можу надати поточну погоду та прогноз на 5 днів для будь-якого міста.

00:04:28.160 --> 00:04:34.000
Він перелічує своє Ari Endpoint, приймає назву міста і повертає температуру та погодні умови у форматі JSON.

00:04:34.220 --> 00:04:39.460
Це все. Це просто чітка декларація можливостей без розкриття секретів чи внутрішньої логіки.

00:04:39.700 --> 00:04:40.980
Виявлення працює так.

00:04:40.980 --> 00:04:45.840
Агент-оркестратор має список відомих URL-адрес агентів або ви можете налаштувати їх самостійно.

00:04:45.840 --> 00:04:51.540
Коли надходить завдання, оркестратор отримує картки агентів, читає описи та вирішує, який агент підходить найкраще.

00:04:51.700 --> 00:04:54.660
Картка погоди вказує на погоду, тому туди спрямовуються погодні завдання.

00:04:54.820 --> 00:04:57.840
Картка готелів вказує на готелі, тому туди спрямовуються завдання щодо готелів.

00:04:57.980 --> 00:05:00.140
Зверніть увагу, центральний реєстр не потрібен.

00:05:00.280 --> 00:05:02.700
Агентам не потрібно реєструватися в глобальному каталозі.

00:05:02.700 --> 00:05:07.580
Вони просто публікують свою картку за відомою адресою і будь-який інший агент, що знає URL, може їх знайти.

00:05:07.580 --> 00:05:11.200
Це свідоме дизайнерське рішення, яке робить систему децентралізованою та гнучкою.

00:05:11.340 --> 00:05:16.060
Ви можете додати нового фахівця до мережі, просто надавши оркестратору його URL, і виявлення відбудеться автоматично.

00:05:16.220 --> 00:05:18.180
Отже, оркестратор знає, хто доступний.

00:05:18.300 --> 00:05:20.220
Але як вони насправді передають роботу?

00:05:20.400 --> 00:05:22.320
Як працює комунікація A2A?

00:05:22.320 --> 00:05:26.020
Отже, оркестратор знає, які агенти доступні за допомогою картки агента.

00:05:26.180 --> 00:05:28.900
Але як саме ці агенти передають роботу один одному?

00:05:29.100 --> 00:05:30.000
Відповідь проста.

00:05:30.000 --> 00:05:36.720
Уся комунікація відбувається через HTTP з використанням повідомлень JSONRPC, протоколу, що лежить в основі більшості сучасних веб-сервісів.

00:05:36.900 --> 00:05:40.540
Нічого специфічного чи складного, просто стандартний веб-трафік між двома агентами.

00:05:40.700 --> 00:05:41.740
Ось у чому справа.

00:05:41.860 --> 00:05:43.240
Не всі завдання однакові.

00:05:43.240 --> 00:05:46.660
A2A підтримує три різні моделі взаємодії, залежно від ваших потреб.

00:05:46.840 --> 00:05:50.700
Миттєва відповідь обробляє швидкі запити, на які віддалений агент може відповісти негайно.

00:05:50.840 --> 00:05:53.840
Ви надсилаєте запит, отримуєте відповідь одразу, і справу зроблено.

00:05:53.840 --> 00:05:58.660
Запит до агента погоди щодо сьогоднішнього прогнозу працює саме так, а синхронна відповідь швидко і просто.

00:05:58.840 --> 00:06:01.000
Потокова передача обробляє довші завдання.

00:06:01.200 --> 00:06:05.440
Можливо, агенту-фахівцю потрібно шукати в кількох базах даних або виконувати складний аналіз.

00:06:05.440 --> 00:06:10.540
Замість того, щоб змушувати вас чекати однієї відповіді, агент надсилає оновлення статусу в процесі роботи через серверні події.

00:06:10.700 --> 00:06:13.980
Ви отримуєте звіти про прогрес протягом виконання, а наприкінці – остаточний результат.

00:06:14.180 --> 00:06:16.260
Відстеження доставки посилки працює так само.

00:06:16.260 --> 00:06:18.300
Ви бачите кожен крок у реальному часі.

00:06:18.440 --> 00:06:23.500
Асинхронне сповіщення обробляє тривалі завдання, виконання яких може зайняти в агента хвилини, години або навіть дні.

00:06:23.620 --> 00:06:25.680
Онбординг співробітників – вдалий приклад.

00:06:25.680 --> 00:06:30.540
Один фахівець створює IT-облікові записи, а інший займається оформленням пільг протягом кількох днів.

00:06:30.680 --> 00:06:34.580
Агент-клієнт подає запит, отримує ID-завдання та продовжує свою роботу.

00:06:34.800 --> 00:06:37.500
Згодом віддалений агент надсилає результат через WebHub.

00:06:37.500 --> 00:06:40.920
Клієнт також може будь-коли перевірити прогрес, опитуючи цей ID-завдання.

00:06:41.060 --> 00:06:44.240
Кожна взаємодія має однакову структуру, де все організовано як завдання.

00:06:44.240 --> 00:06:48.400
Коли клієнт надсилає запит, віддалений агент створює завдання та повертає ID-завдання.

00:06:48.560 --> 00:06:52.020
Цей ID стає ідентифікатором для відстеження всього подальшого процесу.

00:06:52.140 --> 00:06:56.400
Повідомлення всередині завдання мають роль, яка вказує відправника, та частини,

00:06:56.520 --> 00:07:00.840
що можуть бути звичайним текстом, бінарними даними, як от зображення чи документи,

00:07:00.840 --> 00:07:03.740
JSON-пакетами або посиланнями на файли.

00:07:04.820 --> 00:07:09.300
Автентифікація відповідає стандартним веб-конвенціям, от, арі-ключі, токени доступу.

00:07:09.480 --> 00:07:11.920
Звичні методи, нічого нового вивчати не потрібно.

00:07:12.040 --> 00:07:14.940
Картка агента вказує клієнту, який метод автентифікації використовувати,

00:07:15.040 --> 00:07:17.720
і клієнт обробляє це так само, як і для будь-якого іншого арі-виклику.

00:07:17.860 --> 00:07:19.360
Ось як це виглядає на практиці.

00:07:19.500 --> 00:07:22.080
Припустімо, оркестратору потрібні дані про погоду для поїздки.

00:07:22.240 --> 00:07:24.120
Він надсилає завдання фахівцю з погоди.

00:07:24.120 --> 00:07:28.520
Фахівець з погоди підтверджує запит, починає обробку та надсилає оновлення статусу.

00:07:28.640 --> 00:07:29.760
Отримання даних.

00:07:29.840 --> 00:07:31.000
Аналіз результатів.

00:07:31.180 --> 00:07:31.700
Готово.

00:07:31.840 --> 00:07:33.860
Потім він надсилає фінальний прогноз.

00:07:34.000 --> 00:07:37.120
Оркестратор ніколи не бачить внутрішніх інструментів погодного агента,

00:07:37.280 --> 00:07:39.060
його арі-ключів чи процесу міркування.

00:07:39.260 --> 00:07:40.500
Він бачить лише результат.

00:07:40.740 --> 00:07:43.160
Це ключовий принцип дизайну, чіткі межі між агентами

00:07:43.160 --> 00:07:45.040
та відсутність витоку внутрішнього стану.

00:07:45.160 --> 00:07:47.040
Але самого лише A2A і недостатньо.

00:07:47.040 --> 00:07:49.840
Вам потрібен розумний керівник для координації всіх цих фахівців.

00:07:49.960 --> 00:07:52.460
Це підводить нас до патерну «Оркестратор-фахівець».

00:07:52.460 --> 00:07:54.360
Патерн «Оркестратор-фахівець».

00:07:54.360 --> 00:07:55.900
Саме тут усе поєднується.

00:07:56.060 --> 00:07:58.940
Патерн «Оркестратор-фахівець» є найпоширенішою архітектурою

00:07:58.940 --> 00:08:00.600
в сучасних багатоагентних системах.

00:08:00.740 --> 00:08:03.700
Уявіть це як компанію з відділами IT, HR, фінанси,

00:08:03.780 --> 00:08:05.340
де кожен займається своєю сферою.

00:08:05.500 --> 00:08:07.180
У вас є центральний орган прийняття рішень,

00:08:07.180 --> 00:08:09.160
який спрямовує роботу до спеціалізованих команд,

00:08:09.160 --> 00:08:11.560
і кожна команда фокусується на тому, що вміє найкраще.

00:08:11.720 --> 00:08:13.480
«Оркестратор» бачить загальну картину.

00:08:13.700 --> 00:08:16.360
Він отримує запит користувача, визначає, що потрібно зробити,

00:08:16.420 --> 00:08:18.740
і вирішує, який фахівець може виконати кожну частину.

00:08:18.900 --> 00:08:22.200
Якщо користувач запитує «Сплануй поїздку до Сіетла наступного тижня».

00:08:22.200 --> 00:08:24.880
«Оркестратор» не бронює квитки чи готелі самостійно.

00:08:25.020 --> 00:08:26.920
Він знає, що є фахівець з авіаквитків,

00:08:26.920 --> 00:08:28.860
фахівець з готелів та фахівець з погоди.

00:08:28.860 --> 00:08:31.720
Він розбиває запит на ці частини та делегує кожну з них.

00:08:31.860 --> 00:08:33.960
Кожен фахівець має вузьку спеціалізацію.

00:08:34.100 --> 00:08:35.600
Один агент займається бронюванням квитків,

00:08:35.700 --> 00:08:38.000
інший – пошуком готелів, а третій – сортуванням інцидентів.

00:08:38.160 --> 00:08:40.380
Їм не потрібно знати про сфери відповідальності одне одного.

00:08:40.620 --> 00:08:43.340
Спеціаліст з авіаперельотів знає авіакомпанії, маршрути та ціни.

00:08:43.540 --> 00:08:45.680
Йому не потрібно знати нічого про типи номерів у готелях

00:08:45.680 --> 00:08:47.000
чи правила скасування бронювання.

00:08:47.000 --> 00:08:49.640
Така вузька спеціалізація робить кожного агента простим,

00:08:49.760 --> 00:08:51.300
легким в обслуговуванні та тестуванні.

00:08:51.420 --> 00:08:52.620
Ось важлива частина.

00:08:52.800 --> 00:08:54.420
Оркестратор не виконує завдання.

00:08:54.620 --> 00:08:56.700
Він спрямовує роботу та об'єднує результати.

00:08:56.840 --> 00:08:58.040
Це його єдина робота.

00:08:58.260 --> 00:09:00.040
Роль оркестратора – бути розумним диспетчером,

00:09:00.160 --> 00:09:02.140
а не суперагентом, який намагається зробити все.

00:09:02.320 --> 00:09:04.700
Коли ви дозволяєте оркестратору виконувати роботу спеціалістів,

00:09:04.780 --> 00:09:06.300
ви втрачаєте всі переваги цього підходу.

00:09:06.400 --> 00:09:08.220
Це знову перетворюється на монолітний безлад.

00:09:08.220 --> 00:09:09.880
Остерігайтеся поширеної помилки.

00:09:09.880 --> 00:09:12.780
Деякі команди створюють зони відповідальності спеціалістів, що перетинаються.

00:09:12.920 --> 00:09:15.460
Два агенти стверджують, що можуть займатися підтримкою клієнтів

00:09:15.460 --> 00:09:17.880
або пошуком даних, що створює плутанину при маршрутизації.

00:09:18.040 --> 00:09:19.680
Оркестратор не знає, кого обрати,

00:09:19.780 --> 00:09:21.960
і користувачі отримують суперечливі результати.

00:09:22.140 --> 00:09:23.020
Рішення просте.

00:09:23.200 --> 00:09:26.380
Кожен спеціаліст має чітко окреслену сферу діяльності без перетинів.

00:09:26.520 --> 00:09:28.120
Якщо два агенти можуть робити одне й те саме,

00:09:28.120 --> 00:09:30.340
об'єднайте їх або чіткіше розділіть сфери їхньої роботи.

00:09:30.460 --> 00:09:33.380
Microsoft Coopilot Studio використовує цей шаблон як рідний.

00:09:33.540 --> 00:09:35.400
Ваш головний Coopilot діє як оркестратор,

00:09:35.480 --> 00:09:38.000
а дочірні та підключені агенти виступають як спеціалісти.

00:09:38.160 --> 00:09:40.740
Коли користувач запитує щось, що охоплює кілька сфер,

00:09:40.840 --> 00:09:44.240
головний Coopilot делегує завдання потрібним спеціалістам через A2A.

00:09:44.400 --> 00:09:48.200
Це вбудовано в платформу, тому вам не потрібно писати логіку оркестрації з нуля.

00:09:48.380 --> 00:09:50.160
Головна перевага тут – модульність.

00:09:50.160 --> 00:09:52.740
Потрібно замінити постачальника послуг з бронювання готелів.

00:09:52.840 --> 00:09:56.180
Замініть спеціаліста з готелів, не чіпаючи оркестратор чи будь-якого іншого агента.

00:09:56.380 --> 00:09:57.640
Додаєте нові можливості.

00:09:57.840 --> 00:10:01.040
Створіть нового спеціаліста, зареєструйте його в оркестраторі і готово.

00:10:01.160 --> 00:10:04.480
Кожен агент залишається невеликим, керованим і незалежним у розгортанні.

00:10:04.640 --> 00:10:08.120
Це і є головна мета переходу від монолітних агентів до мультиагентної системи.

00:10:08.240 --> 00:10:10.640
Отже, у нас є протокол, картки агентів і шаблон.

00:10:10.820 --> 00:10:13.120
Давайте побачимо це в дії на реальних сценаріях.

00:10:20.160 --> 00:10:29.800
За старого підходу цей єдиний асистент мав би знати все, погоду, перельоти, готелі, ресторани, все одразу.

00:10:30.000 --> 00:10:31.740
Це забагато для одного запиту.

00:10:31.960 --> 00:10:34.260
ZE2I-оркестратор розбиває це завдання.

00:10:34.440 --> 00:10:38.360
Він надсилає завдання спеціалісту з погоди з проханням надати прогноз на ці конкретні дні.

00:10:38.540 --> 00:10:43.920
Водночас він просить фахівця з авіаперельотів знайти рейси з прибуттям у вівторок вранці та вилютом у четвер ввечері,

00:10:44.000 --> 00:10:47.540
а фахівця з готелів підібрати житло поблизу центру Сіетла на три ночі.

00:10:47.540 --> 00:10:51.860
Кожен фахівець працює незалежно і їм не потрібно спілкуватися з іншими агентами,

00:10:52.000 --> 00:10:55.160
адже кожен має власні джерела даних, інструменти та експертизу.

00:10:55.360 --> 00:10:58.840
Оркестратор збирає всі результати і об'єднує їх в одну відповідь.

00:10:58.980 --> 00:11:00.960
Користувач бачить єдину відповідь.

00:11:01.040 --> 00:11:02.180
Ось прогноз погоди.

00:11:02.300 --> 00:11:05.340
Це ваші варіанти перельотів, а ось три готелі неподалік офісу.

00:11:05.500 --> 00:11:09.860
За лаштунками три окремі агенти працювали разом без будь-якого спеціального інтеграційного коду.

00:11:10.040 --> 00:11:11.700
Тепер розглянемо бізнес-сценарій.

00:11:11.700 --> 00:11:15.160
Припустимо, надходить запит «Мій ноутбук не підключається до VPN».

00:11:15.160 --> 00:11:17.620
Оркестратор визначає, що це проблема з мережею.

00:11:17.780 --> 00:11:21.600
Він передає тікет фахівцю з інструкцій, який знає стандартні кроки вирішення.

00:11:21.720 --> 00:11:26.280
Перевірити статус VPN клієнта, підтвердити мережеві облікові дані, перезапустити службу.

00:11:26.440 --> 00:11:28.400
Цей фахівець повертає перелік кроків.

00:11:28.540 --> 00:11:33.280
Потім оркестратор передає результат фахівцю з реєстрації тікетів, який записує вирішення в систему.

00:11:33.460 --> 00:11:35.740
Усе це відбувається за секунди без участі людини,

00:11:35.740 --> 00:11:39.900
і IT-команда залучається лише тоді, коли автоматизовані кроки не вирішують проблему.

00:11:40.060 --> 00:11:43.900
Онбординг співробітників – ще один приклад, але він триває днями, а не секундами.

00:11:44.060 --> 00:11:46.080
Новий працівник приєднується до компанії.

00:11:46.260 --> 00:11:50.200
Оркестратор запускає IT-фахівця для створення облікових записів та призначення техніки,

00:11:50.320 --> 00:11:51.580
що може зайняти кілька годин.

00:11:51.740 --> 00:11:54.520
Водночас він залучає фахівця з HR-пільг для заповнення форм,

00:11:54.620 --> 00:11:58.180
а згодом – фахівця з адміністрування для надання доступу до робочого місця та перепустки.

00:11:58.180 --> 00:12:00.920
Кожен фахівець виконує своє довготривале завдання незалежно,

00:12:00.980 --> 00:12:04.960
а оркестратор відстежує прогрес за допомогою тих ID-завдань, про які ми згадували раніше.

00:12:05.120 --> 00:12:07.900
Отже, якщо IT-фахівець завершує роботу, оркестратор знає про це,

00:12:07.980 --> 00:12:10.620
а якщо фахівець з адміністрування затримується, він може нагадати.

00:12:10.740 --> 00:12:13.000
Користувач бачить один злагоджений процес онбордингу,

00:12:13.120 --> 00:12:16.060
але за лаштунками це ціла команда, що працює протягом кількох днів.

00:12:16.200 --> 00:12:17.440
І це не просто теорія.

00:12:17.440 --> 00:12:22.300
Коука Коула Бевара Джаз Ефрика вже використовує агентів Co-Pilot Studios Dynamics 365

00:12:22.300 --> 00:12:24.040
для автоматизації циклів планування.

00:12:24.180 --> 00:12:27.760
Раніше їхні планувальники витрачали до півтори години щодня на рутинні завдання.

00:12:27.940 --> 00:12:31.000
Завдяки мультиагентній оркестрації ці цикли виконуються самостійно.

00:12:31.120 --> 00:12:36.060
Оркестратор делегує завдання фахівцям, які відповідають за різні частини процесу планування ланцюга постачання.

00:12:36.260 --> 00:12:39.300
Результат – економія понад години на людину щодня завдяки тому,

00:12:39.300 --> 00:12:43.060
що агенти взаємодіють між собою, а не люди переносять дані між системами.

00:12:43.200 --> 00:12:46.000
Отже, модель залишається незмінною в усіх цих прикладах.

00:12:46.120 --> 00:12:50.100
Кожен агент – це самодостатній експерт, який знає свою сферу та має власні інструменти,

00:12:50.160 --> 00:12:52.380
і йому не потрібно знати нічого про інших агентів.

00:12:52.540 --> 00:12:57.200
A2A забезпечує простий рівень комунікації, щоб вони могли співпрацювати без написання спеціального коду.

00:12:57.380 --> 00:13:00.580
Ви отримуєте стандартний протокол і розумний оркестратор без мостів,

00:13:00.680 --> 00:13:03.260
прямих інтеграцій та головного болю з обслуговуванням.

00:13:03.260 --> 00:13:05.360
Microsoft повністю підтримує цей підхід.

00:13:05.500 --> 00:13:08.420
Подивімося, яку це вписуються Co-Pilot Studio та Azure AI.

00:13:08.660 --> 00:13:11.580
Екосистема Microsoft – Co-Pilot Studio та Azure AI.

00:13:11.760 --> 00:13:13.960
Отже, яке місце Microsoft займає в усьому цьому?

00:13:14.200 --> 00:13:14.960
Саме в центрі.

00:13:15.100 --> 00:13:17.180
Co-Pilot Studio тепер підтримує A2A і нативно,

00:13:17.260 --> 00:13:20.320
і ця функція стала загальнодоступною з квітня 2026 року-року.

00:13:20.440 --> 00:13:21.960
Це не попередня версія і не бета.

00:13:22.120 --> 00:13:25.160
Це готове до використання рішення, доступне для будь-якого відповідного клієнта вже сьогодні.

00:13:25.160 --> 00:13:26.260
Ось у чому справа.

00:13:26.260 --> 00:13:29.420
Ви можете підключати зовнішні агенти до свого оркестратора Co-Pilot Studio.

00:13:29.740 --> 00:13:32.400
Коли я кажу «зовнішні», я маю на увазі справді зовнішні.

00:13:32.540 --> 00:13:37.400
Агенти, створені на Google Cloud, AWS чи будь-якій іншій платформі, що підпримує протокол A2A.

00:13:37.560 --> 00:13:40.900
Оркестратору байдуже, де розміщений агент, чи на якому фреймворку він був побудований.

00:13:41.080 --> 00:13:43.820
Якщо він розмовляє мовою A2A, він може приєднатися до команди.

00:13:44.080 --> 00:13:44.900
Налаштування просто.

00:13:45.140 --> 00:13:48.080
У Co-Pilot Studio ви створюєте так званий підключений агент.

00:13:48.080 --> 00:13:50.740
Ви вставляєте URL-адресу кінцевої точки агента.

00:13:50.880 --> 00:13:54.260
Co-Pilot Studio автоматично отримує картку агента за цією URL-адресою,

00:13:54.360 --> 00:13:57.100
тобто той самий JSON-файл картки агента, про який ми говорили.

00:13:57.240 --> 00:13:59.920
Він считує можливості агента, вимоги до автентифікації,

00:14:00.040 --> 00:14:01.960
а також формати вхідних і вихідних даних.

00:14:02.080 --> 00:14:04.400
Потім він створює спеціальний коннектор у фоновому режимі,

00:14:04.440 --> 00:14:07.020
і ваш оркестратор може одразу почати делегувати завдання.

00:14:07.200 --> 00:14:09.680
Вам не потрібна ручна інтеграція чи спеціальний код.

00:14:09.800 --> 00:14:12.060
Просто вставте URL-адресу, і все готово.

00:14:12.060 --> 00:14:15.660
З боку Azure Service Azure AI Foundry Agent також підтримує A2A.

00:14:15.800 --> 00:14:17.820
Він має спеціальну кінцеву точку ARIA 2A,

00:14:17.960 --> 00:14:19.780
яка дозволяє оркестраторам із відкритим кодом,

00:14:19.900 --> 00:14:22.900
як от Autogen, LongChain та Semantic Kernel, викликати агентів Foundry.

00:14:23.020 --> 00:14:25.300
Тож, якщо ви створили агентів за допомогою цих фреймворків,

00:14:25.380 --> 00:14:28.420
ви можете інтегрувати їх в екосистему Microsoft, нічого не переписуючи.

00:14:28.560 --> 00:14:30.100
Це дорога з двостороннім рухом.

00:14:30.240 --> 00:14:31.860
Microsoft дотримується тієї ж моделі

00:14:31.860 --> 00:14:33.860
оркестратор-спеціаліст, яку ми описували.

00:14:33.860 --> 00:14:36.700
Головний агент, у кого Pilot Studio удіє як оркестратор,

00:14:36.760 --> 00:14:39.000
а дочірні та підключені агенти – як спеціалісти.

00:14:39.160 --> 00:14:40.500
Кожен із них обробляє свій домен,

00:14:40.580 --> 00:14:42.660
а оркестратор спрямовує і об'єднує результати.

00:14:42.800 --> 00:14:45.660
Це та сама архітектура, яка просто працює на платформі Microsoft.

00:14:45.900 --> 00:14:48.860
Але є нюанс – існують певні обмеження, про які вам варто знати.

00:14:49.000 --> 00:14:51.860
По-перше, кожен додатковий крок оркестрації додає затримку.

00:14:52.000 --> 00:14:54.220
Якщо ваш головний агент викликає підключеного агента,

00:14:54.220 --> 00:14:55.740
а той викликає іншого спеціаліста,

00:14:55.740 --> 00:14:57.480
кожен такий крок збільшує мережавий час.

00:14:57.640 --> 00:14:59.960
Для розмов у реальному часі занадто велика кількість переходів

00:14:59.960 --> 00:15:01.480
може зробити роботу системи повільною.

00:15:01.580 --> 00:15:04.380
По-друге, надмірне делегування створює хаос у маршрутизації.

00:15:04.600 --> 00:15:06.320
Якщо у вас забагато спеціалістів із доменами,

00:15:06.420 --> 00:15:08.200
що перетинаються, оркестратор починає приймати

00:15:08.200 --> 00:15:09.740
помилкові рішення щодо маршрутизації.

00:15:09.900 --> 00:15:12.240
Отже, тримайте кількість спеціалістів у межах норми,

00:15:12.300 --> 00:15:13.620
а домени чітко розмежуваними.

00:15:13.620 --> 00:15:16.740
По-третє, існує певне обмеження щодо агентів даних Фебрі.

00:15:16.900 --> 00:15:20.680
Вони не працюють, коли головний агент розгорнутий у Microsoft 365 Co-Pilot.

00:15:20.880 --> 00:15:23.100
Якщо ваше розгортання орієнтоване на М365,

00:15:23.200 --> 00:15:24.120
плануйте роботу відповідно.

00:15:24.260 --> 00:15:26.480
Ці обмеження реальні, але з ними можна працювати.

00:15:26.640 --> 00:15:28.860
Платформа достатньо зріла для промислового використання,

00:15:28.980 --> 00:15:31.360
і Microsoft активно працює над усуненням цих прогалин.

00:15:31.500 --> 00:15:34.180
Тепер давайте з'єднаємо крапки та поглянемо на загальну картину.

00:15:34.340 --> 00:15:36.680
Розділ про підключення, як усе це працює разом.

00:15:36.680 --> 00:15:39.240
Зробімо крок назад і подивимося, як ці частини взаємодіють.

00:15:39.360 --> 00:15:42.280
A2A – це телефонна система, яку агенти використовують для виклику один одного.

00:15:42.460 --> 00:15:44.220
Картки агентів – це ваша телефонна книга.

00:15:44.400 --> 00:15:46.700
Вони показують, кому телефонувати та за що відповідає кожен агент.

00:15:46.860 --> 00:15:49.460
Оркестратор – це секретар, який спрямовує кожен дзвінок у потрібний відділ.

00:15:49.600 --> 00:15:51.300
Жоден із цих елементів не працює окремо.

00:15:51.420 --> 00:15:52.380
Вам потрібні всі три.

00:15:52.580 --> 00:15:54.680
Без телефонної книги ви не знаєте, кому телефонувати.

00:15:54.880 --> 00:15:57.100
Без секретаря ніхто не керує потоком запитів.

00:15:57.100 --> 00:15:59.980
А без телефонної системи секретар не може нікого з'єднати.

00:16:00.120 --> 00:16:01.620
Вони працюють лише як команда.

00:16:01.820 --> 00:16:03.600
Саме тут на допомогу приходить модульність.

00:16:03.720 --> 00:16:07.580
Коли ваші спеціалісти модульні, ви можете додавати нові функції, не ламаючи те, що вже працює.

00:16:07.740 --> 00:16:10.660
Скажімо, ви хочете додати спеціаліста з оренди авто до свого помічника з подорожей,

00:16:10.760 --> 00:16:13.700
ви створюєте його, публікуєте картку агента, надаєте оркестратору його URL.

00:16:13.940 --> 00:16:14.380
Готово.

00:16:14.540 --> 00:16:17.540
Спеціаліст з авіаквитків та спеціаліст з готелів залишаються незмінними.

00:16:17.800 --> 00:16:19.240
Оркестратор також не змінюється.

00:16:19.400 --> 00:16:22.020
Ви просто підключаєте новий елемент, і система адаптується.

00:16:22.180 --> 00:16:25.520
Оскільки протокол відкритий, ви ніколи не будете прив'язані до одного постачальника.

00:16:25.720 --> 00:16:28.040
Ваш оркестратор може працювати в Co-Pilot Studio,

00:16:28.280 --> 00:16:32.840
агент з погоди у Google Cloud, агент з готелів на AWS, а внутрішні системи на Azure.

00:16:33.040 --> 00:16:34.940
Вони всі розмовляють однією мовою.

00:16:35.100 --> 00:16:36.800
У цьому краса відкритого стандарту.

00:16:36.960 --> 00:16:40.360
Це запобігає прив'язки до постачальника і дозволяє обирати найкращий інструмент для кожного завдання.

00:16:40.360 --> 00:16:43.340
A2A – це не створення одного надрозумного агента, який знає все.

00:16:43.500 --> 00:16:47.040
Це створення гнучкої робочої сили зі спеціалістів, яких можна переставляти відповідно до потреб.

00:16:47.220 --> 00:16:49.400
Ви не замінюєте агентів, ви їх перегруповуєте.

00:16:49.580 --> 00:16:50.580
Ви додаєте нових.

00:16:50.740 --> 00:16:51.780
Ви змінюєте старих.

00:16:51.940 --> 00:16:54.560
Система розвивається разом з вами, замість того, щоб ставати вузьким місцем.

00:16:54.700 --> 00:16:56.800
Отже, що ви можете зробити з цими знаннями вже сьогодні?

00:16:57.040 --> 00:16:58.020
Практичні висновки.

00:16:58.220 --> 00:16:59.180
Починайте з малого.

00:16:59.180 --> 00:17:03.060
Оберіть один повторюваний процес у вашій організації, що охоплює кілька систем.

00:17:03.260 --> 00:17:06.860
Наприклад, вирішення тікетів, адаптація співробітників або звіти про витрати.

00:17:07.080 --> 00:17:09.240
Щось із чіткою передачею завдань між етапами.

00:17:09.380 --> 00:17:12.080
Потім створіть прототип з одним оркестратором і двома спеціалістами.

00:17:12.220 --> 00:17:13.860
Вам не потрібна грандіозна архітектура.

00:17:14.040 --> 00:17:16.240
Вам потрібен лише робочий приклад, на якому можна вчитися.

00:17:16.500 --> 00:17:18.560
Використовуйте інструменти, які вже це підтримують.

00:17:18.660 --> 00:17:22.100
Coopilot Studio має вбудовану підтримку A2A, як і Azure AI Foundry.

00:17:22.100 --> 00:17:25.520
Вам не потрібно будувати протокол з нуля чи писати спеціальний код інтеграції.

00:17:25.720 --> 00:17:28.700
Ставте URL, налаштуйте своїх агентів і починайте делегувати.

00:17:29.080 --> 00:17:30.440
Остерігайтеся поширених помилок.

00:17:30.580 --> 00:17:32.900
Стежте, щоб спеціалізовані області агентів не перетиналися.

00:17:33.040 --> 00:17:36.100
Якщо два агенти можуть робити одне й те саме, об'єднайте їх або чіткіше розділіть сфери.

00:17:36.260 --> 00:17:38.740
Нехай оркестратор займається маршрути за цією, а не виконанням.

00:17:38.820 --> 00:17:40.980
І стежте за затримками через переходи в оркестрації.

00:17:40.980 --> 00:17:44.240
Якщо час відповіді зростає, можливо, у вас забагато рівнів делегування.

00:17:44.420 --> 00:17:45.940
Найкращий перший крок – простий.

00:17:46.060 --> 00:17:48.500
Сплануйте передачу завдань у вашому робочому процесі,

00:17:48.640 --> 00:17:51.040
де інформація передається між людьми чи між системами.

00:17:51.200 --> 00:17:53.520
Це саме ті місця, де агенти можуть взяти роботу на себе.

00:17:53.680 --> 00:17:55.260
Кожна передача – це можливість.

00:17:55.400 --> 00:17:57.620
Отже, система A2A у двох словах.

00:17:57.720 --> 00:17:59.720
Три прості елементи, що працюють разом.

00:17:59.860 --> 00:18:02.820
Агенти перестають бути ізольованими і починають діяти як справжня команда.

00:18:02.820 --> 00:18:05.880
Оберіть один робочий процес із чіткою передачею завдань і будуйте від цього.

00:18:05.880 --> 00:18:09.440
Підписуйтесь на прості пояснення і залишайте коментар, якщо все стало зрозуміло.