Друзья, добрый день! Рады приветствовать вас на нашем сегодняшнем заключительном вебинаре нашей AI Studio
Series. У нас сегодня суперинтересная тема, как создавать мультиагентные системы для
end-to-end автоматизации процессов. Сегодня с вами я, Женя Барановский и Даня. Даня,
представься, пожалуйста. Привет, Женя, привет, зрители. Я разработчик Яндекс.Клауд,
собственно, я разрабатываю сервис Workflows. Во, по всем вопросам, связанных с Workflows,
мы теперь знаем, к кому идти и спрашивать. Верно. Окей. Давайте тогда определимся,
о чем мы сегодня поговорим. В части основной программы у нас первая, это небольшая вводная
и экскурс, да, Дань, что такое Workflows, как он создавался и почему он сейчас существует,
для каких сценариев. Дальше мы с вами посмотрим на создание линейных мультиагентных пайплайнов,
то, что мы называем, ну, простыми какими-то сценариями для Workflows, да. Дальше в следующем
шагу у нас будет сложная бизнес-логика, когда необходимы какие-то там ветвления и прочее,
и прочее, прочее. После этого мы с вами углубимся в то, что называется сочетание агентов и какого-то кодового подхода, да, в рамках этих мультиагентских сценариев, и на закуску оставим вот, собственно, point, который называется Workflows как MCP для агента. Мне кажется, это очень интересная история, которая будет полезна для понимания в целом, как это все работает. Едем дальше? Да. Давай тогда про краткую историю, Дань, потому что ты, как никто, владеешь этой информацией.
Верно. Собственно, у нас изначально сервис Workflows, он создавался как инструмент для автоматизации процессов для девопсов и разработчиков. То есть мы в целом предполагали, что у нас пользователи будут использовать такие механизмы, как ретрали, таймауты, и в целом предполагали, что пользователи будут писать какие-то GQ-скрипты для передачи контекста из кубика в кубик. Но мы на самом деле, в самом начале понимали, что у нас будет
вектор развития на low-code в сторону low-cod'изации workflows, и мы сейчас это усиленно делаем с акцентом на
пользовательский интерфейс, но при этом мы сохраняем старую гибкость и расширяемость, которую мы закладывали в самом начале.
Да, я правильно понимаю, что ключевой пользователь был DevOps-инженер, ну или какой-то технический специалист,
который мог бы это использовать. Окей, да, собственно говоря, теперь к сегодняшнему времени, сейчас workflows — это часть Яндекса iStudio.
Собственно говоря, поэтому, как Даня и сказал, что у нас есть трек большой на упрощение этого интерфейса для того, чтобы в нем могли работать, ну, фактически, бизнес-пользователи, которые с помощью простых понятных шагов будут достигать своего результата.
Вот, здесь что важно отметить, workflows — это конструктор для автоматизации рутинных бизнес-процессов с помощью агентских пайплайнов, сценариев и всего остального.
Здесь не меняется в целом позиционирование, просто добавляется именно мультиагентная составляющая для ваших бизнес-процессов, для их автоматизации.
Мы здесь не рекомендуем строить каких-то чат-ботных сценариев или что-то около того, мы говорим про end-to-end автоматизацию процесса, когда у вас есть что-то на вход, дальше есть набор каких-то шагов, которые необходимо выполнить, в том числе и с AI-агентами, и дальше есть что-то на выход.
Все, процесс завершился, пайплайн закончился.
Тогда едем дальше про автоматизацию линейных процессов, то, что мы, собственно, в самом начале назвали легким простым сценарием, когда есть какой-то, ну, заранее, наверное, понятный флоу для того, чтобы это нужно было реализовать.
Из чего состоит тот самый простой линейный сценарий.
В первую очередь у нас существуют триггеры, да, Витя?
Они запускают workflow.
Они помогают нам запускать workflow.
Те, кто работали с BPMN-нотациями, прекрасно представляют, что там есть как раз flow, есть триггерка, входящая в действие, чтобы этот процесс начинал работу.
Так как мы говорим в рамках этого вебинара про мультиагентные сценарии, то у нас существуют интерграционные шаги, которые называются агент Яндекс.ИАИ Студио.
Вот. Ну и еще у нас есть, наверное, суперважный компонент, который позволяет связать все это между собой, да?
Это называется саджест.
Ага.
Давай тогда сюда.
Из чего состоит тот самый простой сценарий.
Вот. Первый триггер, про который мы говорили, есть у нас триггер Telegram.
Здесь вроде все очевидно, да?
Есть какое-то сообщение, которое начинает запускать наш workflow.
При этом этот workflow имеет контекст того, что пришло в этом сообщении.
Ну, фактически какой-то входящий контекст для агента.
Следующий шаг, следующий триггер, который у нас есть, это вебхук.
Ну, здесь что-то интересное.
Дань, расскажись подробнее про него.
Да, вебхук — это скорее такой более обобщенный вебинар, обобщенный механизм.
Механика такая же, как у Телеграма, то есть если мы хотим интегрировать наш
workflow с какой-то внешней системой, мы говорим «workflow, дай нам публичный
вебхук», и мы берем этот вебхук и встраиваем во внешнюю систему,
чтобы она по возникновению какого-то события дернула этот
URL по HTTP и передала как раз какой-то контекст на
вход, а в «workflow» уже, собственно, сам разберется,
что делать.
То есть в системе генерируется событие, «workflow» запускается.
Я правильно понимаю, давай немножко упростим.
Вот у нас есть какая-то CRM, куда менеджер по продажам
ввел своего лида, клиента, кого угодно, и дальше вот
по этому событию, что этот клиент появился в этой
системе, может стартануть наш «workflow».
Да, если CRM поддерживает поход по HTTP.
Ну, это какой-то стандартный протокол.
Да, популярный.
Окей, да.
Следующий триггер, который есть, это триггер-таймер.
Ну, как будто бы здесь тоже в целом понятно, и он
сам за себя говорит, но достаточно часто встречаются
сценарии у наших клиентов, когда они ставят запуск
какого-то исследования с помощью мультиагентского
сценария по расписанию, чтобы он там каждую неделю
прислал какие-то новости на почту, ну, либо в какой-то
другой канал, который для этого существует.
Про кубик-агент Яндекса iStudio, мне кажется, мы достаточно
часто на разных вебинарах об этом говорим, ну и в интерфейсе
вы это можете увидеть, попробовать в рамках Agent
Atelier, который существует у нас интерфейс для создания
этих агентов.
Здесь на чем хочется сконцентрировать свое внимание, опять же,
это умный кубик, который позволяет сконфигурировать
вам какую-то модель, какой-то системный пром, как она
должна работать, и подключить в рамках этого кубика набор
инструментов, которые есть в рамках Яндекса и Студио.
Да, Юльдан?
Верно.
Еще могу тут подсветить про я агента.
У него можно выставить выходную схему данных.
Там есть три варианта.
Первое – текстовое.
Это значит, что мы, по сути, ограничения не накладываем.
Можем выбрать JSON, тогда агент ответит в формате
JSON обязательно, но мы не знаем, с какой структурой.
Или прям там strict.json-схема, когда мы можем прям детально
описать все поля, типы этих полей, и агент ответит
нам ровно в этом формате, и это нам поможет в будущем.
Ты расскажешь дальше.
Ну ладно, не будешь спойлерить.
Окей, да, следующий у нас компонент, про который
мы говорили, для связанности в рамках наших шагов, это
фактически Suggest.
Он реализован для того, чтобы бизнес-пользователям
было достаточно просто и понятно использовать
какие-то переменные, ну, несложные, я имею в виду,
без различных языков программирования и тому подобное, для
того, чтобы передавать контекст из одного кубика в другой.
Ну, и таким образом построить этот вот флоу.
Есть что добавить к тебе?
Да, я могу объяснить, что мы как раз выбирали GQ изначально
для того, чтобы иметь максимальную гибкость, чтобы максимально
детально можно было описать, как данные должны из одного
кубика перейти в другой.
Но, признаюсь честно, это было сложно даже для самих
разработчиков Workflows, поэтому мы особое внимание
уделяли упрощению этого места.
Простили мы сейчас это с помощью UI, то есть под капотом
саджисты на самом деле просто точно так же пишут
GQ выражение, оно исполняется точно так же, просто мы
на UI генерируем его правильным образом.
На самом деле там 90% кейсов, когда используется
GQ, это просто правильно переложить JSON из одного места
в другое, когда надо обратиться к какому-то, может быть,
вложенному полю.
И вот, собственно, кликаем на саджист, выбираем там
нужное поле, может быть, с учетом вложенных, и готово.
У нас генерируется правильное GQ выражение, которое будет дальше работать.
Я правильно слышу, что, ну, условно, для бизнес-пользователей
у нас есть саджист, который позволяет накликать то же самое GQ выражение,
но если я технический специалист, то я фактически могу сам написать
GQ выражение, если нужно расширить каким-то образом логику,
и это исполнится.
Да, верно, упрощение, оно просто помогает написать
GQ автоматически, но если вы и так знаете, что такое GQ,
как его писать, то да, конечно, можно его написать вручную.
Скипнуть этот саджист и написать самому.
Да, на самом деле у нас с следующим слайдом есть демо конструирования того самого суперпростого пайплайна из нескольких агентов.
У нас есть запуск по расписанию, здесь почти все рабочие дни.
Дальше у нас есть возможность вставить агенты, которые будут заниматься исследованием,
то есть поиск в интернете информации на заданную тему, которую вы конфигурируете как текстовое сообщение.
При этом, я отмечу еще раз, когда мы создавали этого агента, здесь важно подключить ему тул веб-сердж,
для того, чтобы он имел доступ во внешний мир.
После того, как мы сконфигурировали, добавили этот кубик, дали ему какое-то задание,
мы следующим шагом хотим добавить еще одного агента, который будет заниматься версткой того самого исследования
в том формате, который нам нужен.
Ну и, соответственно, здесь достаточно простой пример, когда из предыдущего шага мы выбираем suggest
в виде результ, общий ответ этого агента, ну и дальше наш второй агент, который писатель будет на основании этого результата подготавливать какую-то статью.
Да, здесь не хватает как будто бы следующего шага, ну он как будто бы зависит от пользователя, куда эту информацию хочется передать, да, условно отправить там в Telegram, положить в какое-то хранилище, не знаю, там в Яндекс.Диске, например, да, создать файлик, почему бы и нет, да, ну либо там на почту отправить какую-то верстку в формате HTML.
Так, здесь, мне кажется, хорошо, едем дальше. Про сценарии со сложной бизнес-логикой, ну у нас и название. Давай, наверное, немножко поговорим про проблемы, которые существуют в рамках работы мультиагентских систем. Разведи нам, пожалуйста, вот есть два термина, есть детерминированный пайплайн, есть недетерминированный. В чем сущность этого слова, зачем мы его вообще вводим, почему мы говорим об этом в контексте workflow?
Да, у нас в AI-агентах, которые можно накликать в Agent Atelier, у нас там, естественно, в центре стоит LLM, и она чаще всего с температурой выше нуля.
Это значит, что даже один тот же вопрос LLM, то есть агент может отвечать немного по-разному.
И вот это как раз вероятностное исполнение, такое недетерминированное, иногда может мешать, если нам, например, нужно выполнить какой-то пайплайн
со строгой структурой, с определенным порядком, нам нужен какой-то оркестратор, и вот как раз
Workflow сможет быть таким оркестратором, то есть с локализованными, недетерминированными шагами
у нас, в общем и целом, Workflow оркестрируется со строгой структурой.
То есть Workflow нам, по сути, помогает этот пайплайн как-то стандартизировать, да, и с его работой…
Да, задать рамки структуры выполнения.
Окей, ну то есть это нам фактически дает какую-то воспроизводимость сценария,
который мы можем из раза в раз получать примерно одинакового характера, ну результат, правильно?
Да, что нам, собственно говоря, в рамках инструмента Workflow позволяет это делать, можешь рассказать?
Да, значит, воспроизводимость опирается, в первую очередь, конечно, на управляющие шаги.
Это шаги, которые как раз определяют, в каком порядке нужно выполнять действия внутри Workflows.
И это на самом деле является как бы таким отражением того, что мы знаем об Control Flow в языках программирования.
То есть у нас там есть и Fails, For Loop, While, и очень схожие конструкции, у нас есть и Workflows.
То есть мы тоже можем с помощью них определять порядок выполнения действий Workflows.
Ты в следующий раз, когда будешь так показывать, можно рэп наложить на тебя, чтобы было органично это выглядело.
Про Workflows.
Про Workflows, да.
Расскажи, пожалуйста, про режим отладки. Это же тоже фактически что-то про воспроизводимость сценария.
Да, это в целом инструмент, когда мы можем, во-первых, локализовать какую-то проблему или просто детально посмотреть на какой-то кубик, посмотреть, а правильно он работает, если мы ему, например, передаем какой-нибудь input.
Окей. Наверное, мы сейчас подробнее, да, посмотрим про управляющие шаги. Давай тогда с этого демо начнем.
Давайте посмотрим детально на управляющий шаг Switch. Такая конструкция есть в языках программирования, и у нас она тоже устроена, например, схожим образом. В Switch есть набор веток, и на каждой ветке есть условия. И, в общем, мы просто по порядку смотрим, а истинно ли это условие. И вот первое условие, которое выполнилось, оно и передает управление ветке дальше.
То есть мы просто хотим в зависимости от чего-то передать управление в разные шаги в workflow, чтобы просто сделать разные действия. На нашем кейсе, который у нас на экране, у нас есть AI-агент, который берет текст и смотрит на его тональность, эмоциональность с разными вердиктами. Негативная, позитивная, нейтральная.
И как раз в зависимости от того, что нам там пришло, switch разносит управление на разные части. Давайте посмотрим, как это у нас выглядит в интерфейсе.
Вот у нас есть, собственно, switch, вот у нас есть вердикт негативный, нейтральный, и хотим добавить третью ветку, позитивную.
Вот как раз берем наш suggest, смотрим на поле вердикт, который нам прислал до этого AI-агент, и смотрим, а равно ли оно значению позитивно.
И если равно, тогда у нас вот есть ветка, которая будет исполняться в этом случае, мы туда добавляем какой-нибудь следующий шаг, вот, например, AI-агента.
Слушай, правильно ли я здесь понимаю, что это, например, кейс какого-нибудь сайта по сбору отзывов, и условно, если попало сообщение, и агент определял на него тональность, то мы по разным веткам можем положить, типа, вот здесь ругаются, здесь не ругаются, и разные спам, или что-нибудь, что там разные классификации могут быть.
— Ага, понятно. Хорошо. А еще напомни, пожалуйста, про вердикт. Я правильно же понимаю, что это какая-то строгая заданная схема для агента?
— Верно, да. Это хорошее напоминание. Я у этого AI-агента как раз выставил strict JSON-схему и сказал ему, что ответ нужно вернуть в формате, когда у нас есть поле вердикт текстового, и как раз оно может принимать значение там positive, neutral и negative, чтобы потом сравнить.
И это ты сделал в интерфейсе iStudio, когда конфигурировал агента в расширенных параметрах.
Окей, хорошо, давай тогда пойдем дальше, поговорим про режим отладки, немножко детальнее его посмотрим.
Да, давайте посмотрим, как это выглядит в интерфейсе.
Как я уже говорил, с помощью режима отладки можно посмотреть более детально на какой-то кубик.
Это особенно полезно, если у вас, например, есть большой workflow, и вы не хотите ждать весь префикс исполнения.
Вам нужно только этот кубик посмотреть.
Может быть, там подозрение, что что-то не так.
Очень хорошо, мы берем в режиме дебага, запускаем ровно с этого кубика,
поставляем наш input, который нас интересует, и смотрим, правильно ли там что-то выдается.
А потом у нас есть такие же возможности, как в целом мы привыкли в дебаге.
Можно сделать следующий шаг или сделать общий континью, чтобы workflows исполнился до конца.
У нас тут кейс, где есть три агента, как раз они, каждый выполняется примерно по минуте, и мы не хотим ждать.
У нас есть Researcher, Analyzer и Samarizer.
Хотим посмотреть на то, как работает Analyzer.
Давайте посмотрим, как это выглядит в интерфейсе.
Вот у нас три агента, Researcher, Analyzer, Samarizer.
Мы знаем, что Analyzer принимает список топиков, которые мы хотим посмотреть.
Вот переходим в режим дебага, тыкаем на наш агент Analyzer,
передаем ему какие-то топики, которые мы хотим пресерчить.
Вот, начинаем дебаг.
Видно, что у нас кубик сейчас, он как бы на паузе,
и чтобы он начал уже прямо исполняться, нужно нажать кнопочку «Следующий шаг».
Вот сейчас он уже прямо исполняется, агент пошел что-то делать.
Да, синий цвет нам подсказывает, что кубик еще не выполнился,
он в процессе выполнения.
Когда выполнится, он станет зеленым, и мы можем как раз,
во-первых, увидеть этот момент, во-вторых,
ткнуть на него и посмотреть на аутпут,
и в целом посмотреть, а все ли у нас тут, как мы ожидаем.
То есть, релевантен ли выдача этого ответа тому,
что мы дальше планируем в наших...
Правильный ли там аутпут.
И если неправильный, например, мы знаем, что здесь проблема,
может, надо что-то менять, или, если у нас все хорошо,
просто останавливать режим дебага, все.
И в продакшн.
Хорошо.
Хоп-хоп и в продакшн.
Окей.
Так, тогда у нас есть интересная демка, которую мы показывали не так давно в рамках нашего вебинара тоже.
И здесь, что хочется отметить, это фактически такое достаточно продакшн-рэди решение для того,
чтобы можно было подготовить какой-то продуктовый артефакт,
который будет создан из абсолютно разного количества агентов, достаточно большого,
и каждый этот агент какую-то свою очевидную роль выполняет.
В интерфейсе вы его сейчас увидели, но фактически вот как раз у нас здесь есть демонстрация того,
как работает не только управляющий шаг свитч, но как еще работает управляющий шаг параллел.
Фактически, как вы можете по своему опыту понимать, агенты могут иметь долгий цикл работы.
Для того, чтобы нам не ждать какого-то агента и вот этот строго структурированный пайплайн выполнять,
мы можем некоторые агенты, которые разделены друг от друга, я сейчас тоже пошел, вот этот вот заразил меня,
да, выполнять параллельно, что фактически нам ускоряет процесс работы этого пайплайна,
ну и, конечно же, имеет дополнительную ценность в части того, что вы можете примерно прогнозировать какое-то время этого запуска,
да, ведь если несколько раз запустил, примерно ты будешь понимать, сколько он будет отрабатывать.
Да, ну, по итогу вот этот мультиагентский пайплайн сгенерировал там документ, который положил файл в рамках AI-студия,
и с которым можно будет дальше уже каким-то образом работать и что-то делать, анализировать.
Так, следующий у нас слайд очень важный. На самом деле, workflow — это не только про агентский сценарий, хотя у нас в рамках нашего вебинара мы говорим про мультиагентные системы, но очень важно подсветить, что не всегда, абсолютно не всегда нужно использовать именно шаги, только состоящие из агентов, потому что у нас бывают задачи, где нужен, ну, понятный, предсказуемый исход, и там в целом вообще-то как будто бы не нужна языковая модель, да, например, дернуть какую-то опишку, сходить куда-нибудь посмотреть, получить какие-то данные, и в этом...
и в этом разном направлении. Вот, поэтому, собственно, у нас есть и шаги специальные, да, о которых ты сейчас расскажешь.
Верно. Собственно, мы обсуждали уже управляющие шаги, и они определяют порядок выполнения чего? Вот как раз интеграционных шагов, потому что именно они ходят во внешние системы и выполняют какие-то действия.
У нас Workflows изначально зарождался в контексте клауда, поэтому у нас уже есть изначально какой-то список интеграции с Яндекс.Облаком, то есть у нас есть запись чтения из S3, сходить в MQ, в IDS, положить сообщения, сходить в базу данных.
Также у нас недавно начали появляться AI-кубики, вызовы AI-агента, вызвать LLM, OCR, speech-to-text, но понятно, что это не все объемлющий список интеграций, которые вообще можно себе представить, и поэтому мы в самом начале еще закладывали некоторые инструменты для расширения.
Давайте посмотрим на них по очереди. Вот у нас, собственно, уже виден на экране первый возможный способ для расширения интеграции — это, собственно, просто HTTP-запрос.
Указываем URL, header, body и так далее, в общем, все, что мы привыкли видеть в HTTP.
Он выполняется, результат возвращается в workflow, можно ретравить, например, или хендлить ошибки на основании того, какой код ответа у HTTP.
Дальше расширение, как бы тоже близкое по духу, так сказать, к HTTP, это gRPC, можем сходить в gRPC сервер, если он поддерживает gRPC reflection, например, можем сходить в то же самое Яндекс.Облак, потому что вот у нас не ко всем сервисам пока есть нативные интеграции, а мы можем взять и вручную выставить endpoint, метод проставить использование сервиса на аккаунте workflows, и отлично, мы сходим, например, и вот как на этом примере,
по листам функций, у нас такого нативного кубика нет, а мы это возьмем и используем, и еще один кейс, наверное, самый интересный, это Cloud Functions, это кейс, когда вы хотите не просто сделать какой-нибудь один запрос, а может быть делать целую серию запросов, какую-нибудь интерактивную сессию запросов, или использовать ваш любимый пакет в языке программирования, или ваш любимый бинарник, например, ffimpeg, ну и давайте в целом посмотрим на
что вообще такое Cloud Functions. Это, в общем, отдельный сервис, когда вы можете взять и принести кусочек своей бизнес-лойки в Яндекс.Клауд и сделать из этого прям отдельный облачный ресурс. И мы прямо из коробки получаем инструменты observability, можем версионировать функцию, нам не нужно заниматься частью опса, которую мы можем сделать за вас. В контексте workflows это как раз как такая самая кастомная интеграция, вы можете
принести свою достаточно кастомную бизнес-логику. Можно писать на где-то 10 языков программирования, популярных мы поддерживаем, а если не поддерживаем, то есть еще сервис-контейнер, можно принести свою бизнес-логику в формате докер-файла.
Паскаль заработает. Паскаль можно через сервис-контейнер. Ну давайте посмотрим, как это выглядит в интерфейсе. Да, давайте рассмотрим функцию, которая обрезает видео и оставляет у нее только аудио.
Ну вот в интерфейсе выглядит следующим образом. Есть URL, есть какие-то настройки, там тайм-аут, количество памяти,
которое мы выделяем, рантайм. Вот есть даже logbox-секрет с каким-то токеном. Давайте посмотрим на код функции.
Ну видно по коду функции, что мы тут что-то скачиваем с пользованием, собственно, нашего токена из Яндекс.Форм. Ну мы скачиваем как раз видео. Потом после того,
мы скачиваем видео, отдельно под процессом запускаем как раз ffmpeg, убираем видео,
оставляем только аудио и записываем это дело на наш object storage. То есть вот такого как бы
нативного кубика у нас не было, а мы взяли его и сами написали, как бы расширили то, что мы можем.
Да. И вот можно посмотреть на логи того, как работают функции, только они в обратном порядке.
Короче, да, мы сначала записали, потом преобразовали, потом скачали.
Ну вот, тут видно: успешно отработала функция.
Ну и давайте посмотрим на какой-нибудь сложный кейс с использованием этой функции.
Кейс будет такой: мы берем видео, которое к нам прислал юзер через Яндекс.Формы.
Как раз Яндекс.Формы можно интегрировать с Workflows через Webhook.
Webhook присылает нам URL для скачивания видео.
Функция уже с этим разбирается, мы только что обсуждали, как это происходит.
Потом у нас есть аудио уже на нашем Object Storage.
Туда идет спичный текст, преобразует аудио в текст, более технический, развернутый.
Нам надо скорее саморизацию почитать, поэтому мы используем AI-агент для саморизации.
А потом, да, и выставим, кстати, у него схему, скажем, выдай нам title и description.
Description еще в формате HTML, чтобы мы могли отправить, например, куда-нибудь на почту.
И вот, собственно, потом куда-нибудь используем этот контент.
То есть, тут пример - это отправка через PostBox и запись в S3 просто для истории текста.
Давайте посмотрим, как это выглядит в интерфейсе.
Вот у нас как раз есть триггер випхук.
Нам Workflow сдает URL.
Мы его как раз должны вставить во внешнюю систему.
У нас внешняя система - это Яндекс.Форма.
То есть мы вставляем сюда URL, говорим: сделай пост-запрос с вот таким параметром.
Верни нам URL как раз, куда ты загрузишь видос юзера, который юзер, собственно, принес.
Вот.
Дальше это передается в Cloud функцию.
Она уже знает, как с этим разбираться.
Аудио она записывает в Object Storage.
Поэтому мы указываем, что speech-to-text нужно распознать речь на русском языке, взять с конкретного bucket и файл с конкретным именем, который как раз тоже выдает функции.
Потом этот более технически развернутый текст придется в AI-агента.
Мы как раз прокидываем все параметры, весь текст, который нам нужен, и агент нам выдает как раз благодаря схеме title, description и description в формате HTML, и мы как раз в postbox его и указываем.
Ну и потом просто для истории в object storage записываем.
Я взял, кстати, кейс, когда видео, где Женя рассказывает про интеграцию Яндекс.Агентов с OpenWeb.UI.
Да, я рекомендую всем посмотреть.
Вот как раз такое письмо получилось после суммаризации, то есть мы взяли видео, только аудиотекст, суммаризировали и вот отправили такое письмо.
Давайте посмотрим теперь на историю исполнения этого workflow.
Давайте посмотрим, что нам вообще прислала Яндекс.Формы.
Вот как раз мы видим тот самый видеоурл, с которого нам надо будет скачивать видео из Яндекс.Форм.
Собственно, дальше Cloud Functions скачивает это видео, записывает потом уже только аудио на S3.
Видим потом, как у нас speech-to-text выдало такую портянку технического текста.
Ну, как обычно бывает.
Есть разметка всякая с таймингами.
Агент уже выдает такой человекочистаемый текст и еще HTML сверху, чтобы письмо отправить.
Ну и потом просто видим, что у нас постбоксы, записи в Object Storage прошли успешно.
В общем, все хорошо.
Давай попробуем приземлить этот сценарий на какой-то бизнесовый.
Но в этом случае я так понимаю, что какой-то клиент-пользователь заполнил форму, указал туда какое-то видео,
и это видео уже разложилось на весь этот pipeline.
Я понимаю, что в рамках Яндекс.Форум можно будет собрать в рамках отдела закупок, логистики, сбор заявок, потребностей.
Дальше, когда эта форма заполняется, передать этот вход в контекст агенту,
у которого будет тул, который помогает в интернете, MCP, который помогает оценить компанию по риску его.
Соответственно, этот агент даст какой-то результат, и этот результат можно уже отправить в человек, принимающий решение.
Да, на спорте мы в целом достаточно гибкие, можно принимать… у меня, например, где-то только видео, но вообще там достаточно сложные…
Да, ну и я к тому, что дальше агент, либо мультиагентская система, она может уже это дело и соркестрировать, когда мы говорили про свитч, если это что-то там позитивное, то поощрение у нас негативное, соответственно, что-то другое.
Ну окей, хорошо, тогда едем дальше. Да, кажется, в хорошем темпе двигаемся. Следующий у нас блок, который называется Workflows как MCP Tool для агента. Вот, это на самом деле интересная история, почему? Потому что, а, небольшой дисклеймер, да, для того, чтобы мы говорили про этот сценарий, важно понимать, что в целом такое MCP, мы, кажется, уже тоже, да, упоминали это, но я призываю вас, если вы пропустили вот который вебинар у нас по QR-коду, автоматизация рутинных операций,
то есть задача с помощью агентов и MCP, посмотреть там достаточно подробно, мне кажется, раскрывалась вся суть того, что это за протокол и как он работает, чем он полезен.
Вот, давай посмотрим в контексте нашего вебинара, чем полезен в целом MCP для агента, у которого этот workflow обернут как этот протокол, как этот инструмент.
Да, я, наверное, такой банальный вопрос тебе задам, вообще зачем это нужно и чем это может быть полезно в рамках работы с агентами, ну и в рамках работы с агентами,
но мы уже говорили, что MCP у нас, то есть LM, это у нас источник недетерминированного исполнения, когда мы хотим выполнить что-то со строгой структурой, со строгим порядком, мы как раз это можем обернуть в workflows, и в MCP просто отдать это как тул, чтобы там агент не думал о том, в каком порядке нужно выполнять шаги, то есть просто говорю MCP, вызови вот этот workflow, он разберется, и все будет хорошо, и у него там,
там не будет протечки вот этих лишних деталей в контексте.
Это звучит так, что, например, я как человек, который общаюсь с агентом, условно, даю ему какую-то информацию,
ну, например, там, бриф по написанию статьи, нужно на эту тему написать статью, и вот какое-то еще подмножество дополнительных тем.
Дальше агент может взять это как входящие параметры для workflow, да, и запустить уже реально вот этот большой мультиагентский pipeline,
тогда фактически у нас вот этот агент, который коммуницирует с пользователем, не будет условно выполнять миллион вот этих действий,
они будут в рамках workflow детерминированно выполняться.
То есть это опять же про управляемость, наверное, да, и про какую-то предсказуемость работы агента.
Да, у нас есть небольшая демо тоже, как обернуть, собственно говоря, workflow в MCP,
есть у нас MCP-хаб, в нем есть замечательная вот эта функция, которая позволяет нам создать MCP из workflow.
Вот, мы здесь называем каким-то образом этот тул для агента, у нас сейчас создается этот MCP-сервер,
вот, после этого нам необходимо выполнить несколько действий.
Первое — это указать сервисный аккаут, от которого будет исполняться этот тул и создаваться workflow.
Здесь ты можешь пояснить, какие необходимые роли навесить на это?
Нужно, чтобы была роль workflows-executor.
Дальше мы указываем имя этого агента, и здесь нужно вставить достаточно понятную инструкцию для агента, что это за workflow, чтобы он понимал, в какой эпизод его нужно вызвать, во-первых, а во-вторых, чтобы он понимал, какие необходимы параметры принести, как входящий input в этот workflow.
Соответственно, вы здесь эти параметры тоже можете указать, как я показывал. Дальше, собственно говоря, у нас процесс оборачивания workflow вот этого детерминированного процесса в MCP закончен. Мы идем в наше агентское ателье, выбираем инструмент MCP и выбираем то название, которое мы только что указали. Проверяем, что у нас там approve на все действия есть, ну и фактически таким образом у нас закончена вот эта вот логика. Правда?
Да, давайте, наверное, будем подводить краткие итоги по сегодняшнему нашему вебинару. Первое, мы, когда говорим про мультиагентскую систему, мы говорим в части нашего инструмента Workflows. Здесь важно понимать, что это автоматизация, еще раз, end-to-end процессов, которые есть как раз эти умные агенты. Мы говорим про какие-то, собственно, где есть вход, выход, между ними что-то существует.
Все тривиально и просто. Если у нас есть простая логика, простой пайплайн, то он как будто бы линейный, не нужно нам использовать никаких ветвей, никаких клауд-функций, ничего, в общем-то, сложного, да? Но наш инструмент Workflow, опять же, он достаточно сильно расширяемый, в части того, что и говорил. Ну, конечно, какую-то фантастику там рассказывал. Надеюсь, наши зрители поняли, потому что для меня было тяжело осознать это, но ладно. Дальше. Что еще здесь важно добавить? Что агенты, они существуют не вместо
процесса, а внутри него. Опять же, про то, что мы с вами достаточно много проговаривали. Если нужна
детерминированная логика, то, пожалуйста, ее структурируйте и настраивайте. Так, кажется,
по основной части мы прошлись. Да, спасибо вам большое за внимание. Спасибо. Да, давайте, у нас есть
небольшая вот такая просьба к вам пройти тест для закрепления знаний. Мы оставим здесь QR-код, его, собственно,
будем убирать. У нас есть вопросы, на которые мы в целом видим их. Да, мы их видим, можем на них
поотвечать. Есть у нас первый вопрос от Дмитрия. У него есть цепочка агентов. Workflow,
сорсер информации, исследователь, валидатор итогового результата. Это вполне мультиагентский
пайплайн. Да, вопрос по упаковке этого результата. Классно, куда его дальше и отправлять в комп-формате.
Да, агент без код-интерпретатора не сможет врастать файлы в PDF, PPTX и других офисных форматах.
Да, это утверждение верное. Тул у агента-интерпретатора кода как раз нужен для этого.
У нас был достаточно большой вебинар на эту тему, можно там чуть-чуть подробнее посмотреть и обратить внимание.
Нужно ли дописать код для того, чтобы в конце всего флоу агент мог верстать файл на выход для пользователя?
Здесь, наверное, хотелось бы понять, куда он этот файл должен складывать, кажется.
Ну, у тебя есть возможность прокомментировать про вот этот вот сценарий?
Ну, насколько я помню, да, без кода интерпретатора такое сделать сейчас нельзя.
Нет, это точно факт.
Вопрос в том, что нам по исполнению этого воркфлоу нужно дальше этот файл куда-то отправить, положить.
Ну, сейчас мы поддерживаем передачу вот именно для такого сценария.
Мы можем использовать это в Postbox.
То есть туда мы можем положить вот результат работы этого файла.
И сейчас, короче, можно положить в Postbox все файлы, там без какой-то фильтрации,
просто все файлы перекинуть, и они отправятся в письме.
Если есть запрос на то, чтобы сделать это более гибко, там, в других шагах,
то пишите в поддержку.
Да, ну, в целом и в комьюнити, да, мы точно придем туда после этого вебинара и почитаем.
Если, Дмитрий, чуть-чуть подробнее расскажете именно, куда хочется этот результат дальше передавать,
я не знаю, ну, положить в Яндекс.Диск, например, для менеджера этого, либо что-то еще,
то было бы классно пообсуждать и, ну, собрать от вас ту потребность,
которую мы бы взяли в бэклог и подумали бы, как реализовывать.
Дальше. Вопрос от Андрея. Это про дебаг, мне кажется.
Остановить и прекратить, в чем разница, нет ли у нас там опечатки остановить и приостановить.
И пауза.
Так, ну, я помню такие операции. Есть следующий шаг, есть как бы continue.
И прямо вот посередине приостановить. Нет, у нас такого нет.
Я думаю, там либо опечатка UI, потому что у нас кнопки на самом деле могут быть в двух местах, там, типа, справа и чуть внизу.
Прекратить, это полностью остановить дебаг.
Да, еще есть вопрос от Александра по поводу саджистов, которые у нас не так давно появились.
Где прочитать на это? У нас вышла документация, которая говорит о саджистах.
И как с ними работать, но, наверное, самый простой пайплайн — это прийти в интерфейс, создать несколько агентов, нажать на кнопку, которая была на скриншотах, и вывелиться этот список, в рамках которого можно будет с этим делом поработать.
Так, сейчас показать, наверное, мы не можем, потому что у нас тут не наш рабочий ноутбук.
Да, сори, я не зачитал вопрос. Можете сейчас показать просто пример саджеста внутри схемы, как именно перекинуть.
Ну, написать кастомный саджест мы сейчас не можем, но для начала, ну, вообще, можно почитать про то, как работает state workflow.
Это в документации написано. Но если там, как бы, очень упрощенно рассказывать, то мы у каждого кубика знаем примерно…
Его формат. Во-первых, потому что мы часть кубиков написали, как бы, сами. Во-вторых, в части кубиков формат может выставить пользователь. Это как раз тот самый, та самая JSON-схема у AI-агента. И точно так же можно в Foundation Models запрос тоже сделать strict схему. И это, как бы, такое дополнение сверху. И на основании этого мы будем генерировать саджисты.
То есть, на самом деле, самое главное, вот, фундаментальное правило саджиста, типа, он должен работать. То есть, не только во время, как бы, дизайн-тайм генерировать красивые джеки-выражения, но еще и работать в реальности.
Слушай, да, мне кажется, про саджисты прямо достаточно много вопросов, но видно, что эта тема, так сказать, зашла, и в части понимания тоже нам нужно будет, наверное, доработать. Мне кажется, что первое, где источник истины и правды, это условно в документации есть информация, которую можно будет прочитать про саджисты, но и в целом, как запрос, наверное, к нам я считываю, что нам нужно чуть больше давать информации для того, чтобы пояснить, как работают саджисты.
И, ну, видимо, какие-то сценарии, наверное. Мы возьмем это себе в домашнюю работу, и как раз в рамках комьюнити, наверное, надо будет запланировать нам несколько постов, где мы будем пояснять, что это саджисты и как они работают в каких-то конкретных сценариях. Было бы классно, на самом деле, если бы мы могли собрать от вас, вот как нам коллеги рассказывали свои пайплайны, workflow, да, вот такие вот сценарии, мы могли бы на них конкретно показать, как работают саджисты, было бы здорово.
Так, у нас есть еще вопрос от Олега, я вижу, подходит ли механизм workflow для использования с голосовыми агентами, ну, у нас сейчас краткий ответ, нет, не подходит, у нас workflow работает сейчас только с текстовыми агентами, вот, как и будет ли интегрировано с голосовыми агентами, здесь пока, наверное, вопрос, ну, потому что все-таки голосовые агенты, они предполагают реал-тайм сценарий, там нет какой-то прям долгой обработки,
и это значительно могло бы ухудшить именно пользовательское восприятие работы с голосовым агентом, потому что workflow все-таки он про долгие циклы, которые могут обрабатываться, вот, но на самом деле я бы хотел тоже здесь понять какой-то бизнесовый кейс и применение, может быть, вам в целом и не нужен в этой части workflow, а подойдет просто MCP-тул, который будет голосовой агент вызывать, ну, в общем, нужно чуть-чуть больше деталей.
Есть вопрос от Максима, можно ли интегрировать с Google Doc, чтобы оттуда брать данные и туда же сохранять?
Мне кажется, это у нас расширенный кубик какой-то, ну, то есть, давайте так, да, у нас текущей базовой простой интеграции нет, есть только с Яндекс.Диском, но с Google Workspace мы не брали во внимание этот кейс, сценарий, но запрос в целом, мне кажется, понятен, да, но в целом вот эту структуру работы с Google Doc, наверное, можно реализовать через какие-то...
через какие-то вот эти кубики, которые ты рассказывал.
Да, я не помню сходу, как Google Doc устроен, скорее всего, там есть поход по HTTP, поэтому можно прямо HTTP, если нет, то можно прямо написать функцию на условном питоне, может быть, у них даже есть SDK, короче, через функцию 100% можно, через HTTP тоже, наверное, да.
Ну, давай так, первое, наверное, лоукодного сценария такого, чтобы...
Прямо нативного, да, нативной поддержки Google Doc у нас сейчас нет.
Да, ну, как будто как такой запрос тоже можно забрать, пообрабатывать, посмотреть просто, насколько это частотный сценарий, потому что мы понимаем в рамках интерфейса инструмента Яндекс.360, да, в рамках России, это достаточно частотный сценарий, мы его дальше будем здесь с уверенностью, говорю, развивать и упрощать для того, чтобы можно было лоукод пользователям этот сценарий в рамках таких же, как Google Doc, реализовывать.
Вот, ну, с Google посмотрим.
Да, дальше вопрос от Романа.
Да давай прочитай ты, мне кажется, это ближе к тебе.
Вопрос от Романа.
Правильно понимаю, что через request данные берутся, URL через другой модуль берем, JSON или XML данные присылаются друг от друга, и это ваш интерфейс.
Я очень рад, что у Романа возник такой вопрос. Спасибо большое. Я его не до конца понял, мне кажется.
Ну ты очень рад.
Нет, ну да, может быть есть какая-то расширенная, здесь не очень понятно в каком контексте. Через request данные берутся, URL через другую модуль берем.
Можно уточнение от Романа, если там…
Ну или слушай, давай у нас хороший…
Это кейс, который я рассказывал, большой, или вообще в целом?
То есть у нас есть, да, возможность и через URL, через JSON и через XML скачать…
Давай, у меня есть классное предложение. На самом деле это вопросы, понятно, где приходят. Мы можем сейчас после вебинара прийти.
Да, можно просто прийти и ответить.
Уточняющий вопрос Романа, наверное, мы так и сделаем. В целом, для того, чтобы эту коммуникацию чуть-чуть расширить и продолжить.
Так, вопросов пока больше мы не видим. Это значит, собственно говоря, что мы в рамках вебинара можем завершить нашу активность, ну и взять на себя задачку прийти в чат и доуточнять какие-то вопросы и ответить, может быть, более расширенно, если мы сейчас не смогли дать ответ.
Так, есть еще один вопрос, да, вот прилетел, вижу. Есть какой-то способ посмотреть количество запусков workflow по дням или неделям?
Вот есть вкладка «Мониторинг», да, есть ли у нас там фильтрация на текущий момент?
По дням или неделям?
Я сходу не помню, я думаю, что да. Давайте тоже этот кейс разберем.
Да, если я правильно его понимаю, то фактически вы хотите зайти в вкладку «Мониторинг» и выставить дату, на которую хочется посмотреть.
Количество запусков в workflow. Если это так, то мне кажется, в интерфейсе сейчас такого инструмента нет, но кажется, довольно тоже понятный запрос, почему это необходимо сделать.
Не, но там же есть мониторинг. В мониторинге есть какая-то степень гибкости, точно. Вот я говорю, что деталей сходу не помню, но в целом я не вижу тут преград. Я думаю, что там гибкости хватит, чтобы построить такой график.
Так, окей, тогда на сегодня завершаем. Да, с нас прийти в чат, поотвечать коллегам на то, что мы не смогли, ну да уточнять вопрос. Если, коллеги, вы немножечко расширите свой контекст этого вопроса, ну чтобы мы в него провалились, то будет очень здорово. Да, собственно, спасибо за внимание. Было сегодня, мне кажется, круто.