WEBVTT

00:00:00.000 --> 00:00:03.600
Добро пожаловать в очередную порцию знаний. Представьте, что вы управляете компанией и

00:00:03.600 --> 00:00:06.680
нанимаете команду блестящих специалистов, первоклассного эксперта по планированию поездок,

00:00:06.820 --> 00:00:10.360
специалиста по адаптации сотрудников и сотрудника техподдержки. Но никто из них не общается друг

00:00:10.360 --> 00:00:14.420
с другом. Каждый раз, когда задача требует участия двоих, вам приходится ходить между столами и

00:00:14.420 --> 00:00:18.400
передавать информацию самому. Именно так сейчас работает большинство и агентов. Они действуют

00:00:18.400 --> 00:00:22.020
изолированно, даже когда для решения проблемы явно требуется командная работа. Поэтому сегодня

00:00:22.020 --> 00:00:25.740
мы поговорим о том, как агенты могут общаться, передавать задачи и работать как настоящие команды.

00:00:25.740 --> 00:00:30.040
Меня зовут Мирку Питерс. Это не какая-то концепция будущего. Мультиагентная оркестрация

00:00:30.040 --> 00:00:34.460
происходит уже сейчас. И работает она на базе протокола под названием А2А. Мы начнем с самой

00:00:34.460 --> 00:00:38.260
проблемы. Разберем этот протокол по частям и посмотрим, как Майкрософт использует его в

00:00:38.260 --> 00:00:43.100
Копайлот Студия и Азурай. Берите кофе и давайте погрузимся в тему. Итак, в чем же реальная проблема?

00:00:43.340 --> 00:00:47.580
Современные и агенты – точь в точь как те изолированные специалисты. У каждого есть свои знания,

00:00:47.780 --> 00:00:52.300
инструменты и цели. Агент погоды знает прогноз. Агент отелей знает о наличии свободных номеров,

00:00:52.300 --> 00:00:55.420
но они ничем не делятся. Теперь представьте, что пользователь просит организовать

00:00:55.420 --> 00:00:59.160
поездку в Сиэтл на следующей неделе и найти отель рядом с офисом. Одиночному агенту пришлось бы

00:00:59.160 --> 00:01:02.940
одновременно быть экспертом по погоде, путешествиям и местной инфраструктуре. Это означает

00:01:02.940 --> 00:01:07.300
огромные перегруженные промпты, втискивающие все возможные функции в одну систему, и такие промпты

00:01:07.300 --> 00:01:11.980
постоянно ломаются. Старым решением был написанный вручную код. Вы создаете мост между агентом

00:01:11.980 --> 00:01:16.580
погоды и агентом отеля, затем еще один между агентом отеля и агентом авиабилетов, и еще один для

00:01:16.580 --> 00:01:20.580
агента календаря. Сначала это работает, но с добавлением каждого нового агента приходится создавать

00:01:20.580 --> 00:01:24.620
новую интеграцию. Очень скоро вы получаете спагетти-кошмар из точечных соединений, где одно

00:01:24.620 --> 00:01:28.680
изменение ломает все. Прирост продуктивности, который должен был обеспечить ИИ, съедается работой

00:01:28.680 --> 00:01:32.920
по поддержке системы. Давайте посмотрим на реальную боль бизнеса. В вашей организации уже есть

00:01:32.920 --> 00:01:37.660
процессы с передачей задач. Создается тикет, кто-то его сортирует, кто-то решает, кто-то логирует,

00:01:37.760 --> 00:01:42.020
каждый этап является передачей. В старой модели вы автоматизируете каждый этап отдельным агентом,

00:01:42.020 --> 00:01:46.780
а затем неделями связываете их между собой. Но что, если бы существовал протокол, позволяющий агентам

00:01:46.780 --> 00:01:51.520
находить друг друга и сотрудничать без кастомных мостов. Именно это и делает А2А. Простыми словами,

00:01:51.640 --> 00:01:55.720
А2А — это стандартный способ для агентов общаться друг с другом, передавать работу и выполнять

00:01:55.720 --> 00:02:00.620
задачи сообща. Что такое А2А? Простое определение. А2А расшифровывается как агент-то агент,

00:02:00.700 --> 00:02:04.240
от агента к агенту. Это открытый протокол, позволяющий и агентам общаться напрямую друг с другом,

00:02:04.340 --> 00:02:09.600
независимо от того, кто их создал. Можно представить его как HTTP для агентов. HTTP — это язык общения

00:02:09.600 --> 00:02:14.980
веб-браузеров и серверов. А А2А делает то же самое для агентов. Агент, созданный вашей ИТ-командой

00:02:14.980 --> 00:02:19.320
в Microsoft Copilot Studio, может общаться с агентом другой компании в Google Cloud,

00:02:19.480 --> 00:02:24.640
если оба используют А2А. И это вовсе не маленький проект. А2А поддерживается восемью крупными

00:02:24.640 --> 00:02:30.320
компаниями, включая Google, Microsoft, Cisco, Salesforce, SAP и другими, а размещается под эгидой

00:02:30.320 --> 00:02:34.920
Linux Foundation. Версия 1.0 стабильна и готова к реальному использованию. А это значит,

00:02:35.140 --> 00:02:39.960
что протокол не контролируется одним поставщиком. Это не проект Google или Microsoft. Это отраслевой

00:02:39.960 --> 00:02:44.460
стандарт. Его дизайн намеренно сделан простым. А2А опирается на существующие веб-стандарты,

00:02:44.460 --> 00:02:49.360
такие как HTTP и JSON-RPC, которые известны каждому разработчику. Ничего экзотического или

00:02:49.360 --> 00:02:53.180
проприетарного. Это упрощает внедрение для предприятия без необходимости менять

00:02:53.180 --> 00:02:57.060
существующую инфраструктуру. Возможно, вы слышали о другом протоколе под названием

00:02:57.060 --> 00:03:01.680
MCP или Model Context Protocol. Вот в чем разница. MCP — это связь-агент-инструмент,

00:03:02.040 --> 00:03:06.480
то есть он подключает агента к внешним источникам данных и API. А2А — это связь-агент-агент,

00:03:06.660 --> 00:03:10.580
соединяющая агентов напрямую друг с другом. Они не конкуренты, а дополняют друг друга.

00:03:10.580 --> 00:03:15.820
Представьте MCP как вертикальное соединение агента с его инструментами, а А2А — как

00:03:15.820 --> 00:03:20.980
горизонтальное соединение между агентами. Еще одно дизайнерское решение. А2А рассматривает

00:03:20.980 --> 00:03:25.200
агентов как черные ящики. Поэтому, когда один агент общается с другим, он не видит внутреннюю

00:03:25.200 --> 00:03:29.640
логику, инструменты или личные данные другого агента. Он видит только отправленную задачу и полученный

00:03:29.640 --> 00:03:34.000
результат. Это сохраняет конфиденциальность и интеллектуальную собственность. Агенту погоды не нужно

00:03:34.000 --> 00:03:37.560
знать, как агент отеля бронирует номера. Ему нужно просто передать прогноз.

00:03:37.560 --> 00:03:41.120
Теперь давайте рассмотрим первую часть пазла — агентскую карту.

00:03:41.300 --> 00:03:46.760
Агентская карта или резюме. Каждый А2А совместимый агент публикует так называемую агентскую

00:03:46.760 --> 00:03:52.000
карту. Эта карта представляет собой машиночитаемый документ, расположенный по стандартному URL в

00:03:52.000 --> 00:03:57.360
домене агента, конкретно по пути уэлэльнаунагенткарт.json. Если вы знаете, где находится агент,

00:03:57.500 --> 00:04:01.740
вы можете получить его карту и узнать все необходимое для работы с ним. Представьте агентскую карту как

00:04:01.740 --> 00:04:06.140
резюме или визитную карточку. Она сообщает другим агентам, кто вы и что умеете делать.

00:04:06.140 --> 00:04:11.240
Карта содержит имя агента, текстовое описание его возможностей и теги навыков,

00:04:11.420 --> 00:04:16.320
которые помогают в поиске. Там также указан URL-адрес конечной точки для приема запросов,

00:04:16.440 --> 00:04:20.000
требования к аутентификации, а также форматы входных и выходных данных.

00:04:20.180 --> 00:04:24.440
Вот конкретный пример. Допустим, у вас есть агент-специалист по погоде. В его карте агента

00:04:24.440 --> 00:04:28.500
написано «Я могу предоставить текущую погоду и прогноз на 5 дней для любого города». В списке

00:04:28.500 --> 00:04:33.420
указаны его API-инпоинты, он принимает название города и возвращает температуру и условия в формате

00:04:33.420 --> 00:04:38.800
JSON. Вот и все. Это просто четкое описание возможностей без раскрытия секретов или внутренней

00:04:38.800 --> 00:04:43.880
логики. Обнаружение работает следующим образом. У агента-оркестратора есть список известных URL-адресов

00:04:43.880 --> 00:04:47.960
агентов, либо вы можете настроить их вручную. Когда поступает задача, оркестратор считывает

00:04:47.960 --> 00:04:51.600
карты агентов, анализирует описание и решает, какой агент подходит лучше всего.

00:04:51.740 --> 00:04:54.740
Карта погоды говорит «погода», поэтому задачи по погоде направляются туда.

00:04:54.740 --> 00:04:57.840
Карта отелей говорит «отели», поэтому задачи по отелям направляются туда.

00:04:58.000 --> 00:05:02.660
Заметьте, централизованный реестр не требуется. Агентам не нужно регистрироваться в глобальном каталоге.

00:05:02.660 --> 00:05:06.720
Они просто публикуют свою карту по известному адресу, и любой другой агент, знающий этот URL,

00:05:06.960 --> 00:05:11.160
может их найти. Это осознанный выбор архитектуры, который делает систему децентрализованной и гибкой.

00:05:11.300 --> 00:05:14.540
Вы можете добавить нового специалиста в свою сеть, просто предоставив оркестратору его URL,

00:05:14.740 --> 00:05:18.160
и обнаружение произойдет автоматически. Итак, оркестратор знает, кто доступен.

00:05:18.260 --> 00:05:22.580
Но как именно они передают работу друг другу? Как работает взаимодействие между агентами А2А?

00:05:22.740 --> 00:05:27.540
Оркестратор знает, какие агенты доступны благодаря карте агента. Но как эти агенты на самом деле

00:05:27.540 --> 00:05:32.640
передают друг другу рабочие задачи? Ответ прост. Все общение происходит по протоколу HTTP с использованием

00:05:32.640 --> 00:05:36.700
сообщений JSON-RPC. Это тот же стандарт, что питает большинство современных веб-сервисов.

00:05:36.820 --> 00:05:40.580
Ничего специфического или сложного, просто стандартный веб-трафик между двумя агентами.

00:05:40.700 --> 00:05:45.480
Тут есть важный нюанс. Все задачи разные. А2А поддерживает три различных шаблона взаимодействия

00:05:45.480 --> 00:05:49.020
в зависимости от ваших потребностей. Мгновенный ответ подходит для быстрых запросов,

00:05:49.160 --> 00:05:53.860
когда удаленный агент может ответить сразу. Вы отправляете запрос, получаете ответ, и на этом все.

00:05:53.860 --> 00:05:58.500
Запрос прогноза погоды работает именно так. Быстрый обмен, запрос и ответ.

00:05:58.500 --> 00:06:02.520
Стриминг используется для более длительных задач. Возможно, агенту-специалисту нужно

00:06:02.520 --> 00:06:06.100
выполнить поиск по нескольким базам данных или провести сложный анализ. Вместо того,

00:06:06.200 --> 00:06:09.520
чтобы заставлять вас ждать единого ответа, агент отправляет обновление статуса в процессе

00:06:09.520 --> 00:06:13.580
работы через серверные события. Вы получаете отчеты о ходе выполнения, а в конце – окончательный

00:06:13.580 --> 00:06:17.800
результат. Отслеживание доставки посылки работает точно так же. Вы видите каждый этап по мере его

00:06:17.800 --> 00:06:21.560
выполнения. Асинхронное уведомление обрабатывает долгосрочные задачи, на выполнение которых

00:06:21.560 --> 00:06:25.680
у агента могут уйти минуты, часы или даже дни. Прием новых сотрудников – хороший тому пример.

00:06:25.680 --> 00:06:29.920
Один специалист создает IT-учетные записи, а другой занимается оформлением льгот в течение

00:06:29.920 --> 00:06:34.700
нескольких дней. Клиентский агент отправляет запрос, получает ID-задачи и продолжает работу.

00:06:34.860 --> 00:06:39.180
Позже удаленный агент присылает результат через випху. Клиент также может проверить прогресс в

00:06:39.180 --> 00:06:43.160
любое время, опросив этот ID-задачи. Каждое взаимодействие имеет одну и ту же структуру,

00:06:43.300 --> 00:06:47.900
организованную как задача. Когда клиент отправляет запрос, удаленный агент создает задачу и возвращает

00:06:47.900 --> 00:06:52.560
ID-задачи. Этот ID становится идентификатором отслеживания для всего последующего. Сообщения

00:06:52.560 --> 00:06:57.500
внутри этой задачи имеют роль, указывающую, кто отправил сообщение, и части, которые могут быть

00:06:57.500 --> 00:07:02.640
обычным текстом, бинарными данными вроде изображений или документов, JSON полезной нагрузкой или

00:07:02.640 --> 00:07:06.560
URL с ссылками на файлы. Аутентификация соответствует стандартным

00:07:06.560 --> 00:07:11.980
веб-конвенциям от API-ключи, токены доступа. Привычные инструменты, здесь нечему учиться заново.

00:07:12.080 --> 00:07:15.780
Карточка агента сообщает клиенту, какой метод аутентификации использовать, и клиент

00:07:15.780 --> 00:07:19.320
обрабатывает это так же, как любой другой API-вызов. Вот как это выглядит на практике.

00:07:19.320 --> 00:07:23.740
Допустим, оркестратору нужны данные о погоде для поездки. Он отправляет задачу специалисту по

00:07:23.740 --> 00:07:28.100
погоде. Специалист по погоде подтверждает запрос, начинает обработку и транслирует обновление

00:07:28.100 --> 00:07:33.840
прогресса. Получение данных. Анализ результатов. Готово. Затем он отправляет итоговый прогноз.

00:07:34.020 --> 00:07:38.220
Оркестратор никогда не видит внутренние инструменты погодного агента, его API-ключи или

00:07:38.220 --> 00:07:42.740
процесс рассуждений. Он видит только результат. Это ключевой принцип проектирования, четкие границы

00:07:42.740 --> 00:07:46.520
между агентами и отсутствие утечки внутреннего состояния. Но одного взаимодействия агентов

00:07:46.520 --> 00:07:50.500
недостаточно. Нужен умный руководитель для координации всех этих специалистов. Это подводит

00:07:50.500 --> 00:07:55.480
нас к паттерну «Оркестратор-специалист». Паттерн «Оркестратор-специалист». Вот где все соединяется

00:07:55.480 --> 00:07:59.320
воедино. Паттерн «Оркестратор-специалист» — самая распространенная архитектура в современных

00:07:59.320 --> 00:08:03.940
промышленных мультиагентных системах. Представьте себе компанию с отделами IT, HR, финансы,

00:08:04.060 --> 00:08:08.080
каждый занимается своей областью. У вас есть центральный узел принятия решений, который направляет

00:08:08.080 --> 00:08:11.600
работу специализированным командам, и каждая команда делает то, что умеет лучше всего.

00:08:11.600 --> 00:08:15.420
«Оркестратор» владеет общей картиной. Он получает запрос пользователя, определяет,

00:08:15.560 --> 00:08:19.620
что нужно сделать, и решает, какой специалист может справиться с каждой частью. Если пользователь

00:08:19.620 --> 00:08:24.140
просит, спланируй поездку в Сиэтл на следующей неделе. «Оркестратор» не бронирует авиабилеты и не

00:08:24.140 --> 00:08:28.840
ищет отели сам. Он знает, что есть специалист по рейсам, специалист по отелям и специалист по погоде.

00:08:28.980 --> 00:08:33.940
Он разбивает запрос на эти части и делегирует каждую из них. У каждого специалиста узкая специализация.

00:08:33.940 --> 00:08:37.980
Один агент занимается бронированием рейсов, другой — поиском отелей, а третий — сортировкой

00:08:37.980 --> 00:08:42.260
инцидентов. Им не нужно знать о доменах друг друга. Специалист по авиабилетам знает авиакомпании,

00:08:42.440 --> 00:08:46.420
маршруты и цены. Ему не нужно знать ничего о типах номеров в отелях или правилах отмены

00:08:46.420 --> 00:08:50.960
бронирования. Такая узкая специализация делает каждого агента простым, легким в обслуживании и

00:08:50.960 --> 00:08:56.200
тестировании. Вот важный момент. «Оркестратор» не выполняет задачи. Он распределяет работу и объединяет

00:08:56.200 --> 00:09:00.020
результаты. Это его единственная работа. Роль оркестратора — быть умным диспетчером,

00:09:00.020 --> 00:09:03.940
а не суперагентом, пытающимся делать все. Когда вы позволяете оркестратору выполнять работу

00:09:03.940 --> 00:09:07.940
специалиста, вы теряете все преимущества этого паттерна. Система снова превращается в монолитный

00:09:07.940 --> 00:09:11.920
беспорядок. Остерегайтесь распространенной ошибки. Некоторые команды создают перекрывающиеся

00:09:11.920 --> 00:09:15.880
домены специалистов. Два агента заявляют, что могут заниматься поддержкой клиентов или поиском

00:09:15.880 --> 00:09:20.480
данных, что вызывает путаницу при маршрутизации. Оркестратор не знает, кого выбрать, и пользователи

00:09:20.480 --> 00:09:25.300
получают противоречивые результаты. Решение простое. Каждый специалист владеет четко ограниченным

00:09:25.300 --> 00:09:29.560
доменом без пересечений. Если два агента могут делать одно и то же, объедините их или разделите

00:09:29.560 --> 00:09:33.900
домен более четко. Microsoft Copilot Studio использует этот паттерн нативно. Ваш основной

00:09:33.940 --> 00:09:38.100
Copilot выступает в роли оркестратора, а дочерние и подключенные агенты – в роли специалистов.

00:09:38.160 --> 00:09:42.380
Когда пользователь спрашивает о чем-то, охватывающем несколько доменов, главный Copilot делегирует

00:09:42.380 --> 00:09:47.300
задачу нужным специалистам через A2A. Это встроено в платформу, поэтому вам не нужно писать логику

00:09:47.300 --> 00:09:51.660
оркестрации с нуля. Главное преимущество здесь – модульность. Нужно заменить провайдера

00:09:51.660 --> 00:09:56.020
бронирования отелей. Замените специалиста по отелям, не затрагивая оркестратор или других агентов.

00:09:56.220 --> 00:10:01.060
Добавляете новую функциональность. Создайте нового специалиста, зарегистрируйте его в оркестраторе и готово.

00:10:01.060 --> 00:10:05.520
Каждый агент остается небольшим, управляемым и независимо развертываемым. В этом и заключается

00:10:05.520 --> 00:10:09.400
суть перехода от монолитных агентов к мультиагентной системе. Итак, у нас есть протокол,

00:10:09.540 --> 00:10:13.320
карточки агентов и подтёрн. Давайте посмотрим на это в действии на реальных сценариях.

00:10:13.520 --> 00:10:19.380
Реальные примеры работы A2A. Итак, как A2A выглядит в реальном мире? Начнем с простого примера.

00:10:19.500 --> 00:10:24.180
Вы говорите своему и помощнику, спланируй поездку в Сиэтл на следующей неделе. По-старому,

00:10:24.420 --> 00:10:29.980
этот единственный помощник должен был бы знать все, погоду, рейсы, отели, рестораны одновременно.

00:10:29.980 --> 00:10:34.920
Это слишком много для одного запроса. С A2A-оркестратор разбивает задачу. Он отправляет

00:10:34.920 --> 00:10:39.340
задание специалисту по погоде, чтобы узнать прогноз на конкретные дни. Одновременно он просит

00:10:39.340 --> 00:10:43.940
специалиста по авиабилетам найти рейсы с прибытием во вторник утром и возвращением в четверг вечером,

00:10:44.100 --> 00:10:48.480
а специалиста по отелям – подобрать варианты рядом с центром Сиэтла на три ночи. Каждый специалист

00:10:48.480 --> 00:10:52.900
работает независимо, и им не нужно общаться с другими агентами, поскольку у каждого из них свои

00:10:52.900 --> 00:10:58.280
источники данных, инструменты и компетенции. Оркестратор собирает все результаты и объединяет их

00:10:58.280 --> 00:11:03.540
в один ответ. Пользователь видит единый ответ. Вот прогноз погоды. Это варианты ваших рейсов.

00:11:03.740 --> 00:11:08.420
А вот три отеля рядом с офисом. За кадром три отдельных агента работали вместе без какого-либо

00:11:08.420 --> 00:11:13.480
специального кода интеграции. Теперь рассмотрим бизнес-сценарий. Допустим, приходит заявка – мой

00:11:13.480 --> 00:11:18.180
ноутбук не подключается к VPN. Оркестратор определяет, что это сетевая проблема. Он передает

00:11:18.180 --> 00:11:22.520
заявку специалисту по инструкциям, который знает стандартный порядок действий. Проверить статус

00:11:22.520 --> 00:11:27.680
VPN клиента, подтвердить сетевые учетные данные, перезапустить службу. Этот специалист возвращает

00:11:27.680 --> 00:11:31.720
перечень действий. Затем оркестратор передает результат специалисту по ведению заявок,

00:11:31.720 --> 00:11:35.640
который регистрирует решение в системе. Все это происходит за секунды без участия человека,

00:11:35.900 --> 00:11:40.020
и IT-команда вмешивается только в том случае, если автоматизированные шаги не решают проблему.

00:11:40.180 --> 00:11:45.220
Анбординг сотрудника – еще один пример, но он занимает дни, а не секунды. В компанию приходят

00:11:45.220 --> 00:11:49.640
новые сотрудники. Оркестратор запускает IT-специалиста для создания учетных записей и распределения

00:11:49.640 --> 00:11:53.500
оборудования, что может занять несколько часов. В то же время он активирует специалиста по кадровым

00:11:53.500 --> 00:11:56.800
льготам для оформления документов, а позже – специалиста по хозяйственному обеспечению для

00:11:56.800 --> 00:12:00.460
организации рабочего места и пропуска. Каждый специалист выполняет свою длительную задачу

00:12:00.460 --> 00:12:03.740
независимо, а оркестратор очлеживает прогресс, используя идентификаторы задач,

00:12:03.880 --> 00:12:07.640
о которых мы говорили ранее. Так что, если это специалист закончил работу, оркестратор знает об этом,

00:12:07.760 --> 00:12:10.700
а если специалист по хозяйственным вопросам задерживается, он может напомнить о задаче.

00:12:10.820 --> 00:12:15.000
Пользователь видит один отлаженный процесс анбординга, но за кулисами это скоординированная команда,

00:12:15.000 --> 00:12:19.880
работающая несколько дней. И это не просто теория. Компания Coca-Cola Beaverages Africa уже использует

00:12:19.880 --> 00:12:24.900
агентов Copilot Studios Dynamics 365 для автоматизации циклов планирования. Раньше их специалисты

00:12:24.900 --> 00:12:28.400
по планированию тратили до полутора часов каждый день на повторяющиеся задачи. Благодаря

00:12:28.400 --> 00:12:32.360
мультиагентной оркестрации эти циклы выполняются автоматически. Оркестратор делегирует задачи

00:12:32.360 --> 00:12:36.640
специалистам, которые отвечают за разные этапы процесса планирования цепочки поставок. В результате

00:12:36.640 --> 00:12:40.640
экономится более часа в день на человека, просто за счет того, что агенты общаются друг с другом,

00:12:40.640 --> 00:12:44.980
вместо того, чтобы люди переносили информацию между системами. Таким образом, во всех этих примерах

00:12:44.980 --> 00:12:49.480
шаблон один и тот же. Каждый агент – это автономный эксперт, который знает свою область и имеет

00:12:49.480 --> 00:12:53.780
свои инструменты, и ему не нужно ничего знать о других агентах. A2A предоставляет простой

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

00:12:57.360 --> 00:13:01.280
Вы получаете стандартный протокол и интеллектуальный оркестратор без шлюзов, интеграций,

00:13:01.440 --> 00:13:06.220
точка-точка и проблем с обслуживанием. Microsoft полностью поддержала эту инициативу. Давайте посмотрим,

00:13:06.220 --> 00:13:09.880
какое место здесь занимают Copilot Studio и Azure Eye. Экосистема Microsoft,

00:13:09.880 --> 00:13:14.980
Copilot Studio и Azure Eye. Итак, какую роль во всем этом играет Microsoft? Самую центральную.

00:13:15.160 --> 00:13:20.180
Copilot Studio теперь поддерживает A2A нативно, и это решение общедоступно с апреля 2026 года.

00:13:20.340 --> 00:13:23.440
Это не предварительная или бета-версия. Система готова к промышленному использованию,

00:13:23.580 --> 00:13:27.240
и любой подходящий клиент может начать работу уже сегодня. И вот в чем дело. Вы можете подключать

00:13:27.240 --> 00:13:31.880
внешние агенты к своему оркестратору Copilot Studio. Под «внешними» я подразумеваю по-настоящему

00:13:31.880 --> 00:13:37.060
внешние. Агенты, созданные в Google Cloud, AWS или на любой другой платформе, поддерживающий протокол

00:13:37.060 --> 00:13:41.460
A2A. Оркестратору неважно, где находится агент и на каком фреймворке он построен. Если он

00:13:41.460 --> 00:13:46.460
говорит на языке A2A, он может стать частью команды. Настройка проста. В Copilot Studio вы создаете

00:13:46.460 --> 00:13:50.800
так называемый подключенный агент. Вы просто вставляете URL-адрес конечной точки агента.

00:13:50.940 --> 00:13:55.180
Copilot Studio автоматически извлекает карточку агента, поэтому URL – тот самый стандартный

00:13:55.180 --> 00:14:00.020
JSON-файл, о котором мы говорили. Система считывает возможности агента, требования к аутентификации,

00:14:00.240 --> 00:14:04.080
а также форматы входных и выходных данных. Затем она автоматически создает коннектор,

00:14:04.080 --> 00:14:07.860
и оркестратор может немедленно приступить к делегированию задач. Вам не нужна ручная

00:14:07.860 --> 00:14:12.020
настройка или написание специфического кода. Просто вставьте URL, и все готово.

00:14:12.160 --> 00:14:16.740
Со стороны Azure Service Azure iPhone 3 агент также поддерживает A2A. У него есть выделенная API

00:14:16.740 --> 00:14:21.240
конечная точка A2A, позволяющая оркестраторам с открытым кодом, таким как AutoJAN, LongChain и

00:14:21.240 --> 00:14:25.580
Semantic Kernel, вызывать агенты Phone 3. Поэтому, если вы создали агентов с помощью этих фреймворков,

00:14:25.720 --> 00:14:29.900
вы можете подключить их к экосистеме Microsoft без переписывания кода. Это работает в обе стороны.

00:14:29.900 --> 00:14:34.600
Microsoft следует той же модели – оркестратор, специалист, которую мы описывали. Основной агент

00:14:34.600 --> 00:14:38.960
в Copilot Studio выступает оркестратором, а дочерние и подключенные агенты – специалистами.

00:14:39.100 --> 00:14:42.960
Каждый отвечает за свою область, а оркестратор перенаправляет запросы и объединяет результаты.

00:14:43.020 --> 00:14:47.220
Это та же архитектура, просто работающая на платформе Microsoft. Но важно учитывать

00:14:47.220 --> 00:14:51.840
некоторые ограничения. Во-первых, каждый дополнительный этап оркестрации увеличивает задержку.

00:14:52.020 --> 00:14:55.960
Если ваш главный агент вызывает подключенного агента, а тот обращается к другому специалисту,

00:14:55.960 --> 00:14:59.600
каждый шаг добавляет сетевое время. В диалогах в реальном времени слишком большое количество

00:14:59.600 --> 00:15:03.480
шагов может сделать работу системы медленной. Во-вторых, чрезмерное делегирование создает

00:15:03.480 --> 00:15:07.040
хаос в маршрутизации. Если у вас слишком много специалистов с пересекающимися областями,

00:15:07.260 --> 00:15:10.260
оркестратор начинает принимать неверные решения по маршрутизации. Следите за тем,

00:15:10.420 --> 00:15:13.680
чтобы число специалистов было небольшим, а области их ответственности четко разделены.

00:15:13.820 --> 00:15:17.780
В-третьих, существует специфическое ограничение для агентов данных фабрик. Они не работают,

00:15:17.940 --> 00:15:23.320
если основной агент развернут в Microsoft 365 Copilot. Если вы планируете развертывание в M365,

00:15:23.320 --> 00:15:28.060
учитывайте это. Эти ограничения реальны, но с ними можно работать. Платформа достаточно зрелая

00:15:28.060 --> 00:15:32.940
для эксплуатации, и Microsoft активно устраняет эти пробелы. Теперь давайте свяжем все воедино и

00:15:32.940 --> 00:15:36.740
посмотрим на общую картину. Раздел о взаимодействии, как все части сочетаются друг с другом.

00:15:36.880 --> 00:15:39.340
Давайте отойдем в сторону и посмотрим, как эти элементы соединяются.

00:15:39.520 --> 00:15:43.380
A2A – это телефонная система, через которую агенты вызывают друг друга. Карточки агентов – это

00:15:43.380 --> 00:15:46.700
ваша телефонная книга. Они показывают, кому звонить и за что отвечает каждый агент.

00:15:46.900 --> 00:15:50.140
Оркестратор – это секретарь, который перенаправляет вызов в нужный отдел. Ни один из этих

00:15:50.140 --> 00:15:53.960
компонентов не работает в одиночку. Вам нужны все три. Без телефонной книги вы не знаете,

00:15:53.960 --> 00:15:58.400
кому звонить. Без секретаря никто не будет регулировать поток. А без телефонной системы

00:15:58.400 --> 00:16:02.760
секретарь никого не сможет соединить. Они работают только в команде. Именно здесь важна

00:16:02.760 --> 00:16:07.080
модульность. Когда ваши специалисты модульны, вы можете добавлять функции, не нарушая работу

00:16:07.080 --> 00:16:10.920
системы. Допустим, вы хотите добавить специалиста по аренде авто к вашему тревел-ассистенту,

00:16:11.040 --> 00:16:16.060
вы создаете его, публикуете карточку и даете оркестратору его URL. Готово. Специалисты по авиабилетам

00:16:16.060 --> 00:16:20.940
и отелям остаются прежними. Оркестратор также не меняется. Вы просто подключаете новый элемент,

00:16:20.940 --> 00:16:25.360
и система адаптируется. Поскольку протокол открыт, вы не привязаны к одному поставщику.

00:16:25.660 --> 00:16:30.880
Оркестратор может работать в Копайлот Студия, погодный агент в Google Клауд, агент по отелям на

00:16:30.880 --> 00:16:36.740
AWS, а внутренние системы в Азу. Все они говорят на одном языке. В этом прелесть открытого стандарта.

00:16:36.840 --> 00:16:40.280
Он предотвращает зависимость от Виндора и позволяет выбирать лучший инструмент для задачи.

00:16:40.380 --> 00:16:44.640
А2А – это не создание одного сверхразумного агента, который знает все. Это создание гибкой команды

00:16:44.640 --> 00:16:48.280
специалистов, которую можно перестраивать по мере изменения задач. Вы не заменяете агентов,

00:16:48.280 --> 00:16:52.980
вы их перегруппироваете, вы добавляете новых, вы меняете старых. Система растет вместе с вами,

00:16:53.160 --> 00:16:56.620
вместо того, чтобы становиться узким местом. Что же можно сделать с этими знаниями сегодня?

00:16:56.920 --> 00:17:01.600
Практические рекомендации. Начните с малого. Выберите один повторяющийся процесс в организации,

00:17:01.800 --> 00:17:06.460
затрагивающий несколько систем. Например, обработку заявок, анбординг сотрудников или отчетность

00:17:06.460 --> 00:17:10.620
по расходам. Что-то с четкой передачей задач между этапами. Затем создайте прототип с одним

00:17:10.620 --> 00:17:14.980
оркестратором и двумя специалистами. Вам не нужна грандиозная архитектура. Вам нужен лишь работающий

00:17:14.980 --> 00:17:18.520
пример, на котором можно учиться. Используйте инструменты, которые это уже поддерживают.

00:17:18.660 --> 00:17:23.540
В CoPilot Studio есть встроенная поддержка A2A, как и в Azure iPhone 3. Вам не нужно создавать протокол

00:17:23.540 --> 00:17:28.260
с нуля или писать собственный код интеграции. Ставьте URL, настройте своих агентов и начинайте

00:17:28.260 --> 00:17:32.800
делегировать. Остерегайтесь типичных ловушек. Следите, чтобы области специализации не пересекались.

00:17:32.980 --> 00:17:36.080
Если два агента могут делать одно и то же, объедините их или разделите задачи четче.

00:17:36.080 --> 00:17:40.020
Пусть оркестратор занимается маршрутизацией, а не исполнением. И следите за задержками из-за

00:17:40.020 --> 00:17:43.760
цепочек оркестрации. Если время отклика начинает расти, возможно, у вас слишком много уровней

00:17:43.760 --> 00:17:47.880
делегирования. Лучший первый шаг, самый простой. Определите точки передачи задач в вашем текущем

00:17:47.880 --> 00:17:51.860
рабочем процессе, где информация передается между людьми или между системами. Это именно те места,

00:17:52.060 --> 00:17:55.260
где агенты могут взять управление на себя. Каждая передача — это новая возможность.

00:17:55.520 --> 00:18:00.580
Итак, это система A2A в двух словах. Три простых компонента, работающих вместе. Агенты перестают

00:18:00.580 --> 00:18:04.060
быть изолированными и начинают действовать как настоящая команда. Выберите один рабочий процесс

00:18:04.060 --> 00:18:07.300
с четкими этапами передачи и начинайте с него. Подписывайтесь, чтобы видеть больше простых

00:18:07.300 --> 00:18:09.460
разборов и пишите в комментариях, если что-то стало понятнее.