Введение в агентов и мультиагентные системы

Здравствуйте, друзья! Меня зовут Дмитрий Сошников, и я рад приветствовать вас на первом вебинаре про введение многоагентной системы и агенты. И мне очень приятно, что мы говорим сегодня на эту тему, потому что я на самом деле начал заниматься искусственным интеллектом еще в 95-м году. Многие из вас, наверное, еще тогда не думали про искусственный интеллект. Искусственный интеллект был совсем другим. Но уже тогда мы предлагали некоторый подход альтернативный многоагентным системам. И, как ни странно, спустя 30 лет тема многоагентных систем по-прежнему очень актуальна. И мне очень приятно, что сегодня, собственно, мы начинаем целую серию таких онлайн-мероприятий, которые называются Яндекс.ИАИ.Студия.Сириес, которая будет посвящена, в общем-то, практически целиком созданию агентов и многоагентных систем в облаке Яндекс.Клауд. Будет практически каждый день какой-то новый вебинар. Я приглашаю вас всех, безусловно, смотреть контент и следить за... Этими событиями. Но что самое интересное, что в результате просмотра этих видео мы будем вам в каждом таком видео давать некоторые дополнительные задания, которые вы сможете поделать, чтобы практически применить те знания, про которые мы рассказываем, какие-то квизы. И по результатам этого самых активных участников этих вебинаров мы пригласим на специальное секретное закрытое мероприятие, которое будет в Москве. О нем я подробно рассказывать не буду, потому что она секретная и закрытая, но вот те из вас, кто будут активно участвовать, соответственно, смогут на нем оказаться и получат возможность пообщаться уже, собственно, с сотрудниками, которые занимаются разработкой, внедрением соответствующих инструментов в облаке Яндекс.Клауд, обсудить какие-то новости, идеи на будущее и так далее. Поэтому будьте активны, а мы начинаем. Итак. Что же такое AI-агенты? Вы все знаете, что такое большая языковая модель, с которой можно разговаривать, но языковая модель, с ней именно можно разговаривать, то есть вы ей что-то пишете, получаете ответы, а агент — это некоторая более автономная сущность, которые могут взаимодействовать с внешней средой, в том числе с пользователем, но, возможно, и с какими-то другими внешними инструментами, и которая способна... в некотором смысле, автономно принимать решения и предпринимать какие-то действия для того, чтобы выполнить определенную поставленную задачу. Ну, задача, как правило, конечно, ставится человеком, ну или какими-то действиями, которые происходят в окружении. И в ходе нашего разговора сегодня и в ходе всего этого мероприятия вы, конечно, сможете самостоятельно попробовать создавать каких-то своих. агентов, и для этого вам потребуется облако Яндекс.Клауд. И если у вас уже есть доступ в Яндекс.Клауд, то вы можете использовать свое облако. Это, как правило, использование языковых моделей в таких учебных целях. Это не очень дорого, не потребует много ресурсов. Но если у вас нет, если вы никогда не пользовались облаком Яндекс.Клауд, то вы можете создать свой доступ к облаку. Здесь на QR-коде есть ссылочка на некоторые пошаговые инструкции, как это сделать. И тем, кто первый раз присоединяется к облаку, дается некий вступительный грант, который вы сможете потратить на учебные задачи. Что же самого интересного есть в облаке? Наверное, в центре всех агентов, как я уже упомянул, лежит большая языковая модель. И в облаке Яндекс.Клауд доступно множество языковых моделей, начиная от моделей, разработанных собственной Яндексом, это Яндекс.ДпТ, и заканчивая моделями опенсорсными, с открытыми весами, такими как Квен 3. Вот Квен 3 это, наверное, самая большая, самая мощная и... способная модель из тех, что есть в облаке, но есть еще и другие. Например, есть модель Gemma 3, которая является мультимодальной, она поддерживает работу одновременно с текстом и с изображениями. Для каких-то задач это может оказаться полезным. Но есть еще модель Яндекс.Арт, которая позволяет создавать изображения по текстовому запросу. Но это, наверное, нам в рамках этого вебинара не так интересно, но главное, что есть этот некий спектр моделей, и для ваших задач вы можете выбирать... модель, в зависимости от того, насколько способные модели вам нужны. Чем модель больше, тем она, в общем-то, отчасти медленнее и дороже, но при этом лучше отрабатывает запросы и вообще является более умной. Но сама по себе модель этого недостаточно. Что делает модель? Ну, агентом, ну, или как минимальный агент, можно назвать ассистент, который общается с пользователем. Для этого нужно еще две вещи. Нужна, во-первых, история переписки, потому что сама по себе большая языковая модель, она, как вы, наверное, знаете, получает на вход некоторую всю историю переписки, контекст переписки и возвращает реплику свою, да. Дальше, когда пользователь продолжает беседу, в следующий раз нужно подать модели снова на вход всю историю переписки. И поэтому эта история переписки должна где-то храниться. И второе, что должно быть у агента, это системный промпт, который задает ему роль, как минимум роль, кем этот агент должен прикидываться, какие задачи он должен решать. И поэтому это минимальный набор, который должен быть у любого агента. Тогда, соответственно, этот агент может быть специализированный для выполнения какой-то задачи и способен поддерживать пользователя. Беседу. Как таких агентов-ассистентов можно создавать в облаке Яндекс.Клауд? Для этого существует два основных подхода. Можно делать это с помощью программирования, написав некий программный код на языке Python. И, собственно, ранее в вебинарах мы уже рассматривали, как делать таких ассистентов, ориентируясь на так называемый Assistant API. Но Assistant API — это в некотором смысле технология, которая немного уже устарела. и она сменяется более продвинутым подходом, о котором мы поговорим сегодня более подробно. И второй подход, как можно делать таких ассистентов, это через веб-интерфейс на основе подхода, который называется no-code, low-code. По сути дела, вам не нужно писать никакой код, вы с помощью кликов мышки создаете такого вот агента и конфигурируете его, задаете ему там все необходимые параметры. Мы в качестве примера будем рассматривать такого агента, который занимается рекомендациями вина к еде. Представьте себе такой сомелье в ресторане, который может делать соответствующие рекомендации. Но если эта тема вдруг как-то вам не очень приятна или вам нету 18 лет, то вы, пожалуйста, немедленно отключитесь, не смотрите запись, потому что мы будем говорить про вино. Окей, то, соответственно, пример, который я буду сегодня рассматривать, он доступен на GitHub, здесь вот есть QR-код со ссылкой, и вне зависимости от того, вы будете рассматривать для себя создание агента с помощью программирования или с помощью no-code подхода, по этой ссылке все равно содержатся некие данные, которые можно использовать для экспериментов по созданию своего агента в облаке. В основном, сегодня на вебинаре я буду вам показывать примеры, как создавать агента с помощью no-code подхода в облаке просто кликами. Если вам интересно более подробно, как создавать агенты и многоагентные системы с помощью... то сегодня также мы выкладываем запись еще одного вебинара, который называется «Создание мультиагентной системы на базе AI Studio», где все примеры будут уже с программированием, и вы можете после этого вебинара, ну или в любое потом свободное время, подробнее посмотреть вот этот вот вебинар, где показано программирование. на языке Python с использованием различных, в том числе, фреймворков для создания многоагентных систем. Но чуть-чуть про код, естественно, мы поговорим с вами в том числе. Итак, давайте посмотрим, как создаются агенты в облаке с помощью подхода low-code, no-code. И для этого основная точка входа — это консоль Яндекс.Клауд. Мы заходим туда, и наше путешествие начинается. Итак, давайте посмотрим, как же создать своего простейшего ассистента через консоль Яндекс.Клауд. Начинаем мы с адреса console.yandex.cloud. Если вы заходите туда первый раз, то вам предложат залогиниться с вашим Яндекс.ИД. А если у вас еще нет своего Яндекс.Облака, то нужно предпринять некоторые действия, чтобы это облако создать, чтобы у вас был платежный аккаунт, и, собственно, вы могли создавать какие-то облачные ресурсы. Но если вы уже пользовались облаком, то вы увидите примерно следующую картинку. Здесь у меня слева находится, собственно, моя организация, мое облако и мой каталог. И в каталоге внутри можно создавать какие-то ресурсы. Я буду пользоваться каталогом по умолчанию под названием Default. И если я пролистаю здесь немножко вниз, то я увижу среди списка все сервисы. сервис под названием AI Studio. Захожу туда, и AI Studio, как вы знаете, это такое место, где сосредоточены все возможности работы с искусственным интеллектом. И первое, что мы здесь видим, это кнопочка создать AI агента. Ну, это, собственно, то, что нам нужно сделать. Мы нажимаем создать AI агента, открывается некий список агентов, которые мы уже когда-то создавали раньше. Либо с помощью программного кода, либо в диалоговом режиме. Все агенты находятся здесь. И нажимаем кнопочку «Создать агента». Попадаем в такой вот достаточно, хотел сказать, простой интерфейс, но в нем на самом деле много разных установок. Но создается агент достаточно легко. Мы задаем имя. Ну, давайте мы назовем нашего агента «Самелье». Это будет агент, который будет советовать нам давать какие-то рекомендации по ВИНам. Выбираем базовую языковую модель Яндекс.GPT, Lite, Яндекс.GPT Pro, QWEN 235B. Это самая мощная модель, которая есть в облаке. В общем, у нас есть выбор моделей. Давайте выберем Яндекс.GPT Pro. Он, собственно, был здесь предложен по умолчанию. Дальше выбираем формат ответа. Если мы хотим, чтобы этот агент был диалоговым. С пользователем, то, естественно, нам нужен формат ответа text. Но обратите внимание, что здесь есть еще разные строгие форматы ответа. Мы можем, например, сделать так, чтобы агент извлекал какие-то данные в структурированном виде, в виде какого-то формата JSON, например. Дальше настраиваем здесь температуру, насколько агент креативен и максимальная длина ответа. И, собственно, самое главное, что у агента есть, это, наверное, prompt. Вот, соответственно, промпт определяет то, как такой агент будет себя вести. Давайте мы напишем, ты опытный сомелье, отвечая на вопросы пользователя по винам и сочетанию с едой. По другим вопросам пиши, что ты не очень компетентен. Вот, говорим создать агента. Наш агент создается очень быстро. И здесь справа у нас, обратите внимание, появляется сразу диалоговое окно. И мы можем нашему агенту что-нибудь написать. Мы можем написать что-то такое. Вот, привет. Вот, или, например, скажем, какие вина лучше пить со стейком. Вот, модель думает чуть-чуть подольше, но выдает нам ответ. Хорошо сочетаются красные вины, Кабернет-Савиньон, Шерас, Мальбек. В принципе, ответ достаточно неплохой, ну, потому что мы дали ему хорошую инструкцию. Дело в том, что если бы мы не написали вот этот факт, что ты опытный семилье, то ответы агента были бы менее... Целенаправленно. Поскольку языковая модель всегда усредняет очень разные источники, то, возможно, ответ был бы менее конкретный. Здесь же пока мы видим, что все хорошо. Но кажется, что ничего такого сильно сложного мы не сделали. Но на самом деле мы создали такого ассистента, которым можно теперь пользоваться. Здесь есть кнопочка «Посмотреть код». И мы видим вот этот вот код, он позволяет нам начать общаться с именно этим ассистентом, с нашим системным промптом из любой программы на языке Python. То есть, грубо говоря, если мы хотим создать какого-то своего Telegram-бота, мы можем вот этими небольшими строчками кода посылать нашему агенту сообщение и получать от него ответы. Более того, в этом агенте, помимо вот этого системного промпта, есть еще... Потому что мы можем продолжить беседу, например, сказать о с рыбой. И агент понимает, что мы имеем в виду, какие вина сочетаются с рыбой. И он нам выдаст соответствующий ответ. То есть он помнит историю переписки. Итак, мы видели, как создать агента с помощью подхода no-code. Как же сделать это с помощью программирования? Как я уже упомянул, самым современным подходом к вызову языковых моделей в облаке является так называемый Responses API. Это API, которое предложила компания OpenAI, и, собственно, для него разработано множество библиотек и инструментов, и Яндекс.Облако поддерживает как раз-таки протокол Responses API, и поэтому вы можете использовать с Яндекс.Облаком совместно различные совершенно инструменты. Ну и самый простой, наверное, инструмент, который есть, это OpenAI. В качестве API-ключа вы передаете API-ключ сервисного аккаунта в Яндекс.Облаке. Вы получаете объект под названием client, с помощью которого вы можете дальше задавать запросы к языковой модели. Ну и, собственно, запрос выглядит так. Мы говорим client.responses.create, передаем название модели, передаем системный prompt в параметры instructions и передаем в качестве input это вот как раз сообщение пользователя. И получаем какой-то ответ в результате. Как же реализуется память, как хранится история диалога? Понятно, что мы можем ее хранить у себя на клиентской стороне и в качестве инпута передавать некий набор сообщений, а можем делать более правильно, наверное, и хранить историю диалога в облаке. Для этого нужно в следующем запросе, если мы хотим сделать уже следующий запрос в Response API, мы должны передать поле «Privious Response ID», то есть это ID последнего. ответа модели, предыдущего ответа модели, и автоматически модель будет учитывать всю историю переписки, которая была до этого. Единственное, что тут нужно указать параметр store равно true, чтобы вся переписка действительно сохранялась в облаке, и обратите внимание, здесь же можно еще управлять разными настройками, например, насколько мы хотим включить или выключить режим рассуждения, reasoning и так далее. Таким образом, поскольку наш агент характеризовался системным промптом и памятью, с помощью кода мы можем работать с памятью и задавать некий начальный системный промпт. Но это был простейший агент, как сделать его каким-то более интересным, добавить к нему некую дополнительную функциональность. Для этого к агенту добавляются так называемые инструменты, tools. И модель, языковая модель, она, как правило, все современные модели поддерживают режим, который называется Tool Calling или Function Calling. Идея состоит в том, что мы модели говорим, какие инструменты ей доступны, и модель в случае необходимости может эти инструменты вызывать и что-то с ними делать. Но какие это могут быть инструменты? Это может быть, например, файловый поиск, поиск в какой-то базе, в текстовой базе знаний. Для того, чтобы добавить... к нашему агенту каких-то предметных знаний, как раз-таки можно использовать этот файловый поиск. Это может быть веб-поиск, это могут быть какие-то локальные разработанные вами инструменты, доступ к какой-то базе данных, которая там есть у компании вашей, в которую агент сможет добавлять, например, какие-то заказы или наоборот смотреть статусы заказов. Вот такого рода функциональность, она как раз-таки добавляется с помощью инструментов. Ну и давайте посмотрим, как мы можем добавить... Например, такой инструмент к нашему винному ассистенту. Давайте вернемся к созданию нашего агента Сомелье и зададим ему какой-нибудь вопрос, например, сколько стоит самое дорогое Мерло. И что мы видим, к сожалению, я не могу точно сказать, сколько стоит самое дорогое Мерло, потому что цены на вины могут сильно варьироваться, в зависимости от года, урожая, места покупки и так далее. Хотя мы же не просим цену на конкретный вид, а просим именно самое дорогое. То есть, казалось бы, ответ на этот вопрос наверняка какой-то есть, но агент, основанный на LLM, сама по себе LLM, ответ на этот вопрос давать не хочет. Она была так научена, чтобы какие-то конкретные такие ответы не давать. Зависит, конечно, от LLM. Какая-то LLM могла бы выдать галлюцинацию, но для того, чтобы действительно получить актуальную... Опять же, мы могли бы попросить сказать его, какие, например, из какого региона Вина были самыми хорошими в 2025 году. И ЛЛМ эту информацию, наверное, не могла бы знать, потому что она обучена на каких-то исторических данных. Для того, чтобы нейросеть могла получить какие-то более актуальные знания, мы можем дать ей возможность подключиться к интернету. Входим в режим редактирования нашего агента и добавляем ему инструмент. Здесь вот в разделе инструмента мы говорим «Добавить» и добавляем инструмент веб-поиска. Самый простой инструмент, который есть, это, собственно, по себе веб-поиск. Можно выбрать регион, в котором мы будем искать, ну а можно оставить регион невыбранным, чтобы поиск осуществлялся глобальный. И кроме того, можно добавить какие-то конкретные домены, если мы хотим ограничить наш поиск каким-то набором. Но в нашем случае мы не хотим. Мы хотим, чтобы поиск производился как можно более широким. Ну и давайте теперь спросим, сколько стоит самый дорогой Merlot. Мы видим, что по-прежнему мы получаем отрицательный ответ на вопрос, наверное, потому что наш пронт является слишком жестким. Поэтому давайте мы добавим в пронт дополнительную фразу. По вопросам, касающимся конкретных вин, обращайся к инструменту интернет-поиска. И снова спросим, сколько стоит самый дорогой Мерло. Обратите внимание, ответ теперь происходит достаточно долго. И мы видим ответ, что одно из самых дорогих Мерло, это вот такое-то конкретное вино, миллион долларов. В общем, очень неплохой результат. Как нам узнать, откуда этот результат взялся? В ответе, во-первых, мы видим вот эту вот иконку веб-поиск. Это значит, что в ответе был задействован инструмент веб-поиска. Ну, а более конкретно мы можем нажать на вот эту вот кнопочку и посмотреть на формат нашего ответа в формате JSON. То есть как выглядит этот ответ более подробно, вся информация, которая возвращается пользователю. И здесь мы можем видеть, что вот раздел output, он самый главный. И здесь первое, что происходило, это вызов инструмента. Мы видим в Type равно WebSearchCall. И мы видим запрос. Самый дорогой Мерло – стоимость. То есть нейросеть, она переформулировала вопрос к интернет-поиску, исходя из нашей просьбы. Сделала из него, из нашей просьбы, такой вот короткий лаконичный вопрос. И вернула, соответственно, модели результаты. А дальше модель, уже перефразировав эти результаты. выдала нам финальный ответ. Вот это финальный output текст мы видим в конце. Вот таким вот образом мы можем видеть все подробности, как выполнялся наш запрос, какие инструменты были задействованы. Это, конечно, нам помогает убедиться в том, что все работает правильно. Итак, мы видим, что, по сути дела, мы сейчас создали такого агента, который мы сконфигурировали в облаке, задали ему какой-то инструмент дополнительный, задали ему системный промпт, и возникает вопрос, а можем ли мы к этому агенту обратиться программно, чтобы он уже просто обработал какое-то входящее сообщение пользователя, и при этом используя все те инструменты, которые мы сконфигурировали в облаке. На самом деле, да, для этого мы можем использовать тот же самый Responses API, но вместо задания системного промпта, вместо задания инструментов в программном коде, мы передаем просто специальный параметр, который называется PromptID. Вот этот параметр PromptID в экране редактирования агента в Яндекс.Клауд вы можете взять, это некоторый набор такой букв и цифр, и передаем его просто в качестве параметра, и при этом обращение происходит к нашему конкретному. Агенту будут использованы все инструменты, в данном случае веб-поиск, для ответа на соответствующий вопрос. Ну и соответствующий системный промт также будет использован. Поэтому один из сценариев — это мы конфигурируем агента целиком в облаке в таком ручном режиме, а дальше передаем просто промт-ид, и дальше из какого-то программного кода делаем пользовательский интерфейс для общения с этим агентом. Соответственно, это как бы один подход, когда мы создаем агента визуально. Второй подход, естественно, все те же операции, которые я проделываю визуально, ну, это добавление инструментов в поиск, добавление других инструментов, можно, конечно, делать и руками из программного кода с помощью Responses API. Мы рассмотрели с вами веб-поиск, давайте перейдем к следующей задаче, это некоторый поиск в локальной базе знаний. Очень часто бывает так, что нам хочется добавить... агенту каких-то предметных знаний. Ну, если этот агент, например, какой-нибудь агент службы поддержки компании, то у нас есть какие-то инструкции, как правило, как нам нужно действовать, документы. Вот этот весь материал, его можно сделать доступным для агента в таком локальном файловом поиске. Но в нашем примере мы хотим улучшить, например, способность такого агента рекомендовать вина к блюдам. Посмотрим. Как можно, собственно, это сделать? Для этого используется подход, который называется Retrieval Augmented Generation. Вы наверняка уже про такой подход слышали, но я коротко напомню. Дело в том, что вот этот вот объем знаний о том, как подбирать блюда к винам, он достаточно большой. Его нельзя закинуть целиком в системный промпт модели, потому что просто не хватит контекста. И нам нужно... выборочно как бы извлекать оттуда ту информацию, которая нам нужна для ответа на запрос пользователя. То есть делать, по сути дела, аналог веб-поиска, но только в нашей базе. А как сделать такой вот простой аналог веб-поиска? Для этого мы разбиваем все материалы на небольшие кусочки, как правило, длиною порядка тысячи-двух тысяч токенов, и каждый из кусочков мы индексируем, создаем некий вектор смысла для этого кусочка и кладем специальную векторную базу данных. Затем, когда пользователь задает какой-то запрос, мы, опять же, считаем такой же вектор смысла для этого запроса и просто ищем ближайшие по расстоянию кусочки. Берем, например, 3-5 самых близких кусочков из большого текста и их уже закидываем в контекст модели, в промт-модели. И таким образом модель берет релевантную информацию из вот этой большой базы знаний и использует ее в ответе. Практики. Продолжим усовершенствовать нашего сомелье и улучшим его возможность рекомендовать блюда к винам и наоборот. И для этого мы добавим к нему знания из некоторой специальной таблички. Табличка, которую я позаимствовал откуда-то из интернета под названием Food Wine Table. Она есть в репозитории на GitHub, если вы захотите повторить это упражнение. И эта табличка, она выглядит следующим образом. Это файл в формате Markdown. Табличка с двумя колонками. Блюдо, к которому надо подобрать вино, и вино, которое подходит к этому блюду. И дальше, ну, эта табличка, она не очень хорошо, наверное, здесь отформатирована, но если вы понимаете формат Markdown, вы, наверное, видите, что каждая строка – это две колонки, и соответствующая информация здесь в файле присутствует. Вот этот файл FoodWineTable как раз добавим к нашему ассистенту. Для этого... Входим опять в режим редактирования и в инструментах хотим добавить инструмент под названием Retrieval. Здесь нам предлагается выбрать поисковый индекс. Но и прежде чем выбрать поисковый индекс, его нужно создать. Давайте создадим поисковый индекс. Я назову его FWMatch от слова FoodWineMatch. Файлы. Файл можно загрузить. Соответственно, я перетаскиваю мой файл foodwine table в интерфейс и говорю добавить один файл. И тип поискового индекса я выбираю гибридный. Есть два варианта – текстовый или векторный. Текстовый использует поиск по совпадению ключевых слов, а векторный использует семантический поиск на основе embedding. Ну и, естественно, гибридный сочетает в себе... Преимущество двух этих видов поиска, потому что он может искать как по точному названию какого-то вина, если нам известно, например, его конкретное точное именование, так и по смыслу. И в расширенных настройках мы можем немного поменять. какие-то тонкости, например, изменить размер чанка, потому что если файл слишком большой, то он будет нарезан на более мелкие кусочки. И на самом деле в нашем случае файл как раз-таки достаточно большой, поэтому чанкование ему будет необходимо. Можно выбрать размер этого самого чанка, можно выбрать размер перекрытия чанков, но давайте сделаем перекрытие поменьше, например, в районе 300, а размер чанка сделаем побольше. Этот размер указывается в токенах. Соответственно, нам размер чанка нужно примерно соотносить с объемом контекста модели. Ну и дальше можно указывать, как конкретно мы будем комбинировать текстовый и семантический индекс. Для начала можно оставить значение по умолчанию и нажать кнопочку «Создать». Индекс создается. Прямо сейчас у нас нарезается файл на кусочки, считаются имбеддинги, и вот это все уже. Но на самом деле наш файл, он не настолько, конечно, гигантский, поэтому все произошло достаточно быстро. Ну и давайте напишем здесь еще инструкции. Отвечая на вопросы пользователей по винам, значит, по вопросам сочетания вина и еды, обращайся к файловому поиску, по вопросам, касающимся конкретных вин, обращайся к интернету, по другим вопросам пиши, что ты не очень компетентен. Вот давайте сохраним. Такой prompt. И спросим, что лучше есть с Merlot. И получается, видите, подробный ответ. Пельмени, манты, хинкали, перец болгарский, шашлык из курицы. Откуда эта информация взялась? На самом деле, нам хорошо бы убедиться, что это действительно из файлового поиска. Для этого мы нажимаем на уже известную нам кнопочку. И смотрим, что же здесь произошло в графе output. Первое, что присутствует, это файл search call, то есть это действительно обращение к файловому поиску. И вопрос сочетания мерло с едой. Дальше, какие были возвращены результаты, мы видим из файла foodwine table с релевантностью 0.32 был возвращен вот такой вот текст. Это как бы первый фрагмент, вот второй фрагмент, третий фрагмент. Четвертый фрагмент и пятый фрагмент, и шестой, даже и седьмой. Но количество фрагментов, оно на самом деле может задаваться параметром файлового поиска. Но в конечном итоге мы видим также здесь конкретные ссылки, аннотации. И из этой всей информации из файлового поиска языковая модель посмотрела на все вот это многообразие текста и сформировала нам уже вот окончательный ответ, который мы видим, собственно, здесь. Таким образом, смотрите, у нас получился агент, который сочетает в себе два инструмента, умеет искать в интернете информацию по конкретным винам, умеет подбирать еду и вино по конкретным инструкциям. Эти инструменты он может вызывать сам в соответствии с инструкцией, которую мы заложили ему в системном промпте. Итак, мы видели, как добавить к агенту файловый поиск с помощью диалогового интерфейса. Как то же самое сделать с помощью программного кода на языке Python? Это тоже достаточно несложно. У нас есть в Responsys API такое понятие VectorStore. Мы можем создать VectorStore, сказать client.vectorstores.create, назвать его каким-то образом. И затем в это векторное хранилище мы добавляем файлы. В два этапа. Мы сначала загружаем файл с помощью clients.files.create. Соответственно, файл загружается в облако и там где-то в хранилище оседает. И дальше добавляем этот файл уже конкретно в векторное хранилище. clients.vectorstores.files.create. И в итоге файл добавился, автоматически проиндексировался. Здесь можно отдельно убедиться, что индексация прошла успешно. И дальше, когда мы делаем запрос к агенту с помощью ClientResponse.Create, мы передаем в качестве списка инструментов вот этот файл Search Tool. FileSearchTool задается простым словариком, видите, Type FileSearch, VectorStoreId — это идентификатор векторного хранилища, и можно задать параметр, например, количество результатов, которые мы будем каждый раз возвращать. Ну вот 5 — это хорошее число. Опять же, мы учитываем, что размер каждого фрагмента в чанках у нас там где-то 1500 с чем-то. Ну, на самом деле, мы это можем тоже задавать в качестве параметров при создании. Из программного кода. Ну и количество результатов подбирается так, чтобы размер контекста модели ни в коем случае не переполнился. Ну и вы видите, что инструменты задаются просто в параметре запроса. В данном случае как бы файловый поиск. Можно точно так же задать веб-поиск и какие-то другие инструменты. А какие, собственно, другие могут быть еще инструменты? Ну, на самом деле... Мы можем разрабатывать свои специальные инструменты, но, предположим, у нас есть какой-то специальный набор вин, который мы готовы пользователю предложить, если это, например, ассистент какого-то винного магазина. В этом случае у нас есть своя база данных, и мы к этой базе данных хотим уметь обращаться из нашего агента. Для этого как раз нам поможет некоторый наш кастомный инструмент. Как работает вызов таких инструментов? Но пользователь, предположим, спрашивает нас, найди вино подешевле из нашей какой-то базы данных. Мы, естественно, передаем этот запрос LLM, но... В LLM мы указываем, какие инструменты ей доступны. Точно так же, как инструмент файлового поиска, мы будем говорить, что вот доступен еще некоторый специальный локальный инструмент с определенными функциями. Например, найти вино в прайс-листе, там, Search Vines Price List, или добавить там вино в корзину, если мы делаем агента, который будет, собственно, помогать продавать эти вина. Мы перечисляем набор инструментов, каждый инструмент описан на естественном языке, для того, чтобы модель могла понять, когда же ей этот инструмент вызывать. И вот модель смотрит на этот список инструментов, смотрит на системный промп, в котором можно также добавить подсказки, когда какие инструменты вызывать, и понимает, что раз речь про Мерло подешевле, надо, наверное, поискать прайс-лист. И вместо того, чтобы вернуть ответ пользователю, модель возвращает некое намерение. Хочу... Вызвать инструмент. Собственно, вот модели специально обучены возвращать такие запросы, если они хотят вызвать инструменты. Дальше наша задача каким-то образом понять, что модель не дала нам финальный ответ, а вот хочет вызвать функцию, пойти в базу данных, вернуть соответствующий список самых дешевых Мерло и отдать это назад языковой модели. Языковая модель посмотрит на ответ и выдаст уже финальный. ответ пользователю. Ну вот, примерно так это работает. Но если мы создаем какие-то свои инструменты, как бы, да, из программного кода, нам уже не удастся создать агент через какой-то диалоговый интерфейс, ну, потому что, как бы, в диалоговом интерфейсе программировать и какие-то сложные функции делать — это не самое благодарное занятие. Поэтому вот такие инструменты, они доступны в том случае, если мы программируем... всего агента целиком, например, на языке Python, и как это делать, вы сможете посмотреть в отдельном видео, ссылку на которое я давал в начале, которая будет доступна вам сразу после этого вебинара. Но в нашем случае давайте рассмотрим такой пример. Предположим, мы хотим дать нашему агенту возможность подбирать блюда и вина из ассортимента какого-то ресторана. Мы уже с помощью файлового поиска дали агенту возможность подбирать в целом блюда к винам, но теперь мы хотим ограничить это все неким ассортиментом. И для этого у нас, предположим, есть вот такое меню ресторана, где перечислены блюда и напитки. Как нам, собственно, эту информацию предоставить агенту? Для этого удобно использовать такой протокол, который называется MCP, Model Context Protocol. Что такое MCP? MCP — это, по сути дела, возможность удаленного вызова функции, когда функция находится не мы, пишем ее каким-то своим программным кодом, а она уже есть где-то реализованная кем-то на каком-то сервере в интернете, и мы просто хотим сказать агенту, вот используй, пожалуйста, вот этот вот сервер. Ну вот в нашем случае предположим, что наш ресторан имеет свой такой MCP-сервер. Но в дополнение к обычному веб-серверу, где меню дается для пользователей, мы делаем MCP-сервер, где меню описано для агентов. И, собственно, для того, чтобы наш агент смог работать с этим MCP-сервером, нам достаточно агенту сказать, пожалуйста, используй MCP-сервер, вот такой-то, rest.mcp.ru, ну это некая, естественно, выдуманная ссылка, ну там будет какая-то реальная ссылка там, да, на какой-то MCP-сервер ресторана. Агент, когда видит... что его просит использовать такой инструмент, что он делает? Он идет к этому MCP-серверу по специальному вот этому MCP-протоколу и спрашивает, а что ты можешь, какие инструменты у тебя есть? И MCP-сервер возвращает ему список функций. Такой же список функций с описаниями, что эти функции делают на естественном языке, с формальным описанием, какие параметры нужны каждой функции на специальном уже языке JSON-схема. И теперь LLM понимает, какие, собственно, инструменты есть в ее распоряжении. И когда пользователь задает какой-то вопрос, например, говорит «хочу Мерло», модель понимает, что «ага, у меня же вот этот MCP-сервер содержит функцию, а какие есть вина», он вызывает эту функцию MCP-сервера, но вызов — это некий такой просто удаленный, по сути дела, remote function call, удаленный вызов функции. MCP-сервер возвращает список соответствующих. Win и LLM выдает ответ пользователю. Вот так это все происходит. Очень похоже на обычный function calling, но основная разница здесь в том, что вот MCP-сервер позволяет нам упаковать функции вместе, как бы в единый такой вот набор функций и описать их, как бы именно автор MCP-сервера их описывает, говорит, какие параметры этим функциям нужны. А агенту мы даем только ссылку на сервер, говорим, вот используя возможности вот этого очень умного MCP-сервера. Конечно, есть детали. Например, MCP-сервер может делать какие-то очень хитрые действия. Например, мы можем подключить MCP-сервер для проведения оплаты, если мы хотим... чтобы агент мог с нас брать деньги. И в этом случае, конечно, нам не хочется, чтобы этот MCP-сервер, ну, чтобы агент просто вот вызывал MCP-сервер без какого-то нашего подтверждения. Поэтому вот в этот протокол взаимодействия с сервером на самом деле... Включены еще дополнительные моменты, например, когда модель решает, что нужно вызвать MCP-сервер, она может запросить пользователя подтверждения, что это нужно сделать. И поэтому пользователю приходит дополнительный ответ, типа, ты подтверждаешь это действие или нет, и если да, то, собственно, происходит тогда уже вызов. Но это на самом деле такие уже тонкости, в которые мы с вами вдаваться не будем. Как сделать MCP-сервер? Это как бы тоже отдельный вопрос, потому что о нем я не говорил. Я говорил, что для того, чтобы подключить инструмент к модели, достаточно просто дать адрес. А чтобы сделать свой MCP-сервер, на самом деле это тоже достаточно несложно, если вы, например, делаете реализацию на языке Python, есть прекрасная библиотека FastMCP. И вы просто говорите, что у меня есть некий набор функций, но в нашем случае мы хотим предоставить доступ к меню ресторана, поэтому у нас будут две функции. Это получить меню еды и получить меню напитков. Я не буду усложнять, можно было бы сделать поиск по названию блюда или по типу, но сделаем просто две функции, которые возвращают меню в таблице в формате Markdown. Они просты очень в реализации. Здесь интересно. Во-первых, я использую библиотеку FastMCP, и для того, чтобы превратить обычную функцию на Python в MCP-функцию, я просто декорирую ее с помощью декоратора MCP-тул. И что еще важно, для этой функции нужно обязательно написать описание, вот это вот description string, потому что именно по этому описанию LLM будет решать, какую функцию вызывать. И дальше библиотека FastMCP берет все... проблемы на себя, она как бы поддерживает протокол MCP и может общаться с нашей языковой моделью. Но как нам сделать все то же самое, но в облаке Яндекс.Клауд? На самом деле облако Яндекс.Клауд содержит специальный такой гейтвей для MCP-серверов, который становится посередине между языковой моделью и какими-то другими сервисами. И он позволяет, например, транслировать в протокол MCP любую функцию, например, доступную в интернете. То есть дело в том, что протокол MCP, естественно, он достаточно новый, и не все там веб-сервера его поддерживают. И есть, например, просто какие-то API в интернете, которые по протоколу REST выполняют какие-то действия. И Яндекс.Облако позволяет нам обернуть произвольный вот такой интернет-запрос в MCP формат. Яндекс.Облако позволяет, вот этот вот gateway позволяет обернуть в MCP вызов любой облачной функции. В облаке Яндекс.Ла есть понятие сервера с вычислений, и можно просто написать кусочек кода на языке Python, например, который будет выполняться при запросе. И вот мы можем сказать, окей, вот этот кусочек кода должен вызываться... В качестве MCP сервера. Можно обернуть любой внешний MCP сервер. Можно, например, есть какие-то уже заранее готовые MCP сервера. Например, есть MCP сервер для работы с Яндекс.Трекером. Вы можете просто его добавить, и ваш агент автоматически сможет работать с Яндекс.Трекером. Вот, это все очень удобно. Вот, давайте посмотрим, как нам реализовать, собственно, наш сценарий с меню ресторана с помощью вот такого подхода. Итак, давайте попробуем добавить к нашему агенту Сомелье MCP-сервер с меню какого-нибудь ресторана. И мы уже видели, что создать MCP-сервер мы можем, написав какой-то код на языке Python, описав там все функции, которые, собственно, делают необходимую функциональность. Но нам нужно просто возвращать данные о еде и напитках. Поэтому мы можем начать не с MCP-сервера, а с обычного размещения меню. на обычном веб-сервере в виде обычного веб-сервера по протоколу HTTP. Сделаем это прямо в Яндекс.Клауд. Для этого перейдем в наш каталог, в раздел Object Storage. Object Storage или хранилище данных позволяет создавать публичные так называемые бакеты. Давайте, скажем, создать бакет и назовем его, например, как-нибудь Good Food. Пускай наш ресторан называется Good Food. Сделаем его публичным, доступ на чтение объектов сделаем публичным, для того, чтобы любой мог обращаться к файлам, которые мы в этом бакете разместим просто указанием некоторого пути. Ну и скажем, создать бакет. Наш бакет создался. И какие же данные я буду там размещать? У меня есть некоторое примерное меню ресторана, состоящее из двух файлов. Это food и drinks. Ну давайте посмотрим, как они выглядят. Это тоже таблички. В формате Markdown. Ну вот примерно такое вот меню для еды. Стейкбук на взводе, 2500 рублей. Ну и некоторое описание. Ну и такое же меню для напитков. Давайте эти два файла возьмем и перетащим в наше объектное хранилище. Загрузим их сюда. И поскольку это хранилище публичное, то мы можем просто взять и скопировать ссылку. Скажем, получить ссылку. И в соседней вкладке эту ссылку можем открыть. Вот такой вот адрес. storage.yandex.cloud.net.goodfood.drinks.md. Когда я эту ссылку выполняю, у меня скачивается файл. Соответственно, я говорю загрузить его. Он загружается, скачивается в папку Downloads. Но на самом деле это не очень важно. Главное, что по этому адресу у меня доступно меню блюд и напитков. Теперь нам предстоит сделать из этого... МСП сервер. Что для этого нужно сделать? Переходим снова обратно в AI Studio и идем в раздел МСП сервера. И здесь говорим, хотим создать новый МСП сервер. И здесь у нас есть множество возможностей. Можем подключить любой внешний МСП сервер. Если мы хотим подключить в Яндекс.Клауд какой-то сервер с известным адресом, то, собственно, мы выбираем вот эту опцию. Можем подключить готовые. Например, Яндекс.Поиск, Яндекс.Трекер для добавления задач. Или, можно сказать, хотим создать новый MCP-сервер. Создать MCP-сервер мы можем из HTTP-запроса. Это как раз наш случай. У нас есть адрес, запрос, который, собственно, возвращает нам меню и напитки. Можно создать сервер из любой клауд-функции, из любой облачной функции. Если мы написали какой-то код... В Яндекс.Клауде мы можем сказать, пожалуйста, вызывай этот код как функцию внутри MCP-сервера. И можно в качестве MCP-сервера использовать некоторые рабочие процессы. О рабочих процессах мы с вами поговорим чуть позже. В нашем случае выбираем HTTP-запрос, и нам нужно описать здесь инструменты. У каждого инструмента есть свой URL, поэтому сюда мы копируем тот самый URL с напитками drinks.md. Ну и давайте, скажем, назовем этот инструмент getDrinks. Инструкция для агента. Напишем, используй эту функцию для получения списка написан ресторана. Дальше, параметры инструмента. На самом деле, очень часто MCP-сервер принимает какие-то значения в качестве параметров. Ну, например. Если мы хотим запрограммировать какой-то сервер, вернее вызвать какой-то сервер, который будет определять погоду, то название города нужно передать в качестве параметра метода get или post. Вот эти параметры можно здесь выбирать и конфигурировать, но в нашем случае у нас, поскольку адрес сразу возвращает меню, никакие параметры нам не нужны. Никакие параметры HTTPS метода нам тоже не нужны, поэтому мы удаляем все эти пункты. И, собственно, добавляем еще один инструмент, еще один HTTPS-запрос для получения списка еды. Давайте я вставлю сюда тот же адрес, только drinks заменю на food. А в инструкции для агента я скопирую для получения списка напитков, заменю для получения списка блюд ресторана. Почему очень важно эти описания сюда добавить? Потому что именно по этим строчкам у нас языковая модель будет понимать, когда этот инструмент нужно вызывать. Мы назовем этот инструмент GetFood. GetDrinks и GetFood. Точно так же убираем все параметры нашего запроса и добавляем имя для всего MCP сервера. GoodFoodRest. Сервер спускай будет публичный, доступен всем. И говорим «сохранить». Видим, что у нас получился публичный MCP-сервер с инструментами GetFood и GetDrinks. Можно здесь посмотреть подробности этих инструментов. Теперь нам осталось подключить этот MCP-сервер к нашему агенту. Выбираем снова наш агент-самелье, говорим «редактировать». И к инструментам добавляем MCP-сервер. Good Food Rest выбрать. И давайте чуть-чуть в инструкцию тоже добавим немножко текста. Скажем, по вопросам сочетания вина и еды обращайся к файловому поиску. По вопросам, касающимся цен на блюда и напитки ресторана, обращайся к MCP-серверу. По поводу конкретных вин обращайся к инструменту интернет. Давайте не конкретных вин, а по поводу информации о разных винах. Напишем так. Давайте также добавим и представим чуть-чуть опытный сомелье. Заменим на опытный официант в ресторане с опытом 10 лет. Отвечай на вопросы пользователя по винам и блюдам. с вопросом сочетания то-то-то, по другим вопросам пиши, что ты не очень компетентен. Ну и давайте на самом деле по интернет-поиску, наверное, вообще уберем описание. Вот сделаем такой промпф. Дальше еще одну вещь, которую нужно сделать. MCP-сервер по умолчанию требует подтверждения. Это сделано для того, чтобы если MCP-сервер, например... Делает какие-то сенситивные вещи, например, хочет какие-то потратить деньги с нашей карточки или создать какую-то запись в базе данных. Нормально, если пользователь получит об этом уведомление и подтвердит это действие. Но в нашем случае MCP-сервер несет только информационную роль, поэтому мы вот это подтверждение уберем, скажем, что подтверждение нам не нужно. Ну и давайте сохраним настройки агента и спросим его, например, какие блюда. Из мяса есть наличие. Ну и обратите внимание, какой ответ. Есть стейкбук на взводе, тот самый легендарный за 2500 рублей. И также другие блюда. И видим, что в ответе у нас есть указание на то, что сработал mcp-сервер goodfoodrest.getfood. Ну и это же мы можем посмотреть в подробном ответе. Видно, что да, вот он вызов веб-сервера. Какой инструмент был вызван? GetDrinks. Ну и так далее. Вот текст, который был возвращен инструментом, и дальше на основе этого текста уже был подготовлен ответ модели. Давайте продолжим диалог и попросим подобрать какое-нибудь недорогое вино. Какое недорогое вино подойдет к стейку бык на взводе? Что в этом случае происходит? Происходит, если мы посмотрим, вызов файлового поиска сочетания вина и рыбай стейка, обращение к нашей табличке и подробное описание, какие вина действительно подходят к стейку. При этом видно, что инструмент-агент не обратился к меню за ценами. На самом деле, ему достаточно сложно обращаться сразу к нескольким инструментам, потому что не очень ясно, в каком порядке это делать. Поэтому часто он обращается к одному, и для того, чтобы продолжить рассуждение, нам нужно его явно спросить. Ну вот нам здесь, например, рекомендовали Ширас или Сира для прожарки Medium и Well Done. Давайте спросим, какое недорогое вино Сира есть в меню. Недорогое, на всякий случай напишу правильно. Вот, и видим, что уже когда мы явно спросили его про меню, происходит вызов GetDrinks, вызов MCP-сервера, и возвращается цена за меню. Ну, а давайте теперь попробуем еще раз дать нашему агенту очень сложную задачу. Мы скажем, подбери на свой вкус какой-то стейк из мяса, к нему самое дешевое подходящее вино, и посчитай общую стоимость ужина. Эта задача, она требует вызова сразу нескольких инструментов. И в принципе, давайте посмотрим, как справится наш агент с этой задачей. Итого, смотрим. Он нам сначала предлагает рекомендации к стейку, что нужно есть, какому какой прожарке. Дальше предлагает стейк нежность разверенной коровы филе миньон и к нему конкретное вино за 2800 рублей за бокал. И в итоге выводит действительно общую табличку со стоимостью ужина 4000. И если посмотреть поподробнее на то, какие инструменты были вызваны, то мы видим, что здесь присутствовал вызов MCP-сервера, good food rest, видя вот эту табличку с блюдами, табличку с напитками. Дальше с помощью файлового поиска были найдены релевантные фрагменты таблицы соответствия. После этого языковая модель посмотрела на все эти фрагменты текста и сделала какой-то уже финальный вывод. То есть на самом деле за один проход модель сначала собрала всю информацию со всех необходимых инструментов, а дальше уже выдала решение задачи. Вот такие достаточно сложные вещи могут делать агенты, снабженные различными инструментами. Так мы видели, как вызвать MCP-сервер с помощью конфигурирования через веб-интерфейс, как же сделать это с помощью кода. Но, естественно, это тоже несложно делается. Мы можем описать MCP-сервер в виде некоторого тоже такого словарного описания, дать ему описание сервера, URL, которое нужно вызывать, правило, нужно ли подтверждение или нет, и дальше просто в списке инструмента для агента мы... Этот MCP-сервер указываем. И если мы хотим, чтобы агент использовал MCP-сервер вместе с какими-то другими инструментами, с тем же самым файловым поиском, мы просто указываем в этом списке инструментов весь список инструментов, которые нам необходим. Следующий вопрос, который нас интересует, вот вы видите, что мы уже с вами сделали агента, который достаточно полезный, он может, в общем-то, консультировать нас по посещению ресторана целиком. как его предоставить пользователю, как дать какой-то пользовательский интерфейс. И здесь, наверное, самый правильный способ, это, как я уже вам приводил пример, есть код на языке Python, который вызывает вот этого нашего сконфигурированного через веб-интерфейс агента. И это, наверное, такой самый правильный способ на языке Python написать обвязку, которая будет связывать агента с Telegram. Ну и в целом подробнее про... то, как создавать агентов и правильно деплоить их, размещать их в облаке, этому будет посвящен следующий вебинар целиком, поэтому, пожалуйста, посмотрите, как это делается по всем правилам. Но можно сделать, если нам нужно сделать какую-то демонстрацию, например, простую. и сделать легкое подключение к Telegram, можно использовать для этого еще один подход на основе NoCode с помощью инструмента, который называется Workflows. Посмотрим, как это делается. Посмотрим на практике, как нам обернуть нашего созданного агента в Telegram с помощью NoCode подхода в Яндекс.Клауд. Итак, первое, что нам нужно сделать, это создать Workflow. Мы переходим прямо в экране редактирования нашего агента в кнопочку «Открыть workflows». И у нас открывается редактор, в котором мы видим три квадратика. Первый – старт. Второй – это наш агент AI Studio, агент Сомелье, которого мы уже с вами сделали. И дальше мы можем добавлять какие-то еще шаги. Но workflow в начальном виде мы создали. Давайте его сохраним. Если ошибка возникает недостаточно прав доступа, укажите сервис аккаунт с необходимым доступом в настройках. Да, здесь вот видите, есть такой открываемый пункт с настройками. Есть имя Workflow. Давайте как-нибудь его назовем Telegram TGVF. И здесь же можно выбрать сервисный аккаунт. Выберем. какой-нибудь сервисный аккаунт с хорошими правами доступа. У меня на этот случай есть вот такой аккаунт под названием admin. Будем считать, что этого достаточно. И создадим workflow. Что такое workflow? Workflow – это некий набор кубиков, некий набор блоков, которые могут последовательно выполняться в ответ на какое-то действие. Нам же хочется, чтобы workflow выполнялся в ответ на какое-то действие в Телеграме. То есть, когда пользователь пишет сообщение в Телеграме, чтобы выполнялся workflow. Для этого нам понадобится еще одна сущность, которая называется API Gateway. Переходим в нашем каталоге. Давайте начнем набирать API Gateway и увидим, что вот есть такой пункт, можно создать шлюз. Создадим наш первый шлюз. Имя ему дадим какой-нибудь TG. gv от слова Telegram Gateway. И смотрите, как выглядит этот шлюз. Он описывается в формате YAML. И по умолчанию он содержит путь вот этот вот корневой. Когда происходит обращение к корневому каталогу по методу get, он возвращает нам hello world с кодом 200, то есть успех. И это plain text. Давайте протестируем, как это работает. Для этого нам нужно сохранить. Этот gateway, скажем, создать. Некоторое время он создается. И потом мы видим, наш шлюз активен. Можем его протестировать. Скопируем его адрес. И, соответственно, если мы этот адрес введем в браузере, то мы получаем ответ Hello World. Собственно, мы видели, что в ответ на обращение к шлюзу у нас выдается Hello World. Но для того, чтобы срабатывало workflow, нам теперь нужно указать это вот в этом YAML файле. Мы можем сделать так, чтобы в ответ на вызов Gateway вызывались либо клауд-функции, либо какие-то еще действия происходили. Но в нашем случае нам интересно workflow. Поэтому мы выбираем вот этот вот значок, который означает интеграция с workflow. Нажимаем его. Нам предлагают выбрать. Ну, метод get или post. В нашем случае Telegram общается по методу post, поэтому выбираем post. Сервисный аккаунт выберем с хорошими правами доступа. И выбираем workflow. У нас Telegram workflow, который мы только что создали. Выбираем его здесь и говорим добавить. Ну, еще мы указываем путь. Ну, пускай это будет путь slash tg. И мы видим, что в описании... Вот этого gateway добавился кусочек текста, что в ответ на обращение по адресу tg необходимо вызвать вот такой вот процесс, передать ему в качестве входа input.json, то есть поле, которое было при вызове запроса, оно уже будет передано в наш рабочий процесс в качестве входа. Ну и, в общем-то, этого достаточно, говорим, сохранить. Получается, мы с вами проложили дорожку. Теперь, когда происходит вызов по такому адресу slash.tg, вызывается наш рабочий процесс. Ему передаются все параметры от Telegram. Теперь необходимо поработать на стороне Telegram, то есть, собственно, создать нашего бота. И для создания бота используется специальный бот в Telegram, который называется BotFuzzr. Я не буду показывать, как создается новый бот, чтобы не тратить времени. Есть боты, в частности, бот под названием SchwarzBot. Я часто для демонстрации использую его. Поэтому я просто возьму отсюда специальный секретный API-ключ. И вот этот вот секретный API-ключ как раз нужен для того, чтобы связать Telegram с нашим API-гейтвэем. Для того, чтобы это сделать, нужно просто сделать запрос по определенному веб-адресу. который имеет вот такой вот вид. API Telegram.org, дальше bot и секретный токен. Сюда мы помещаем наш с вами секретный токен. А в конце помещаем адрес, по которому нужно делать запрос. И этот адрес – это адрес нашего gateway. Давайте я его тоже скопирую. Вот такой вот адрес. И я напомню, мы в конце сказали слэш. Вот делаем такой запрос и получаем результат. OK, true. Result true. Description webhook was set. Это значит, что теперь Telegram действительно будет делать вызов моего API Gateway. Давайте в этом убедимся. Перейдем в моего бота и напишем какое-нибудь сюда сообщение. Привет. Ничего не происходит. Ну, на самом деле, это действительно так. Мы же не сказали, что нужно делать в ответ на сообщение. Давайте посмотрим, на наш API Gateway был ли свершен какой-то вызов. Перейдем внутрь API шлюца, и здесь есть такой раздел логи. Видим в логах, вот оно, сообщение, что пришел запрос по адресу slash.tg. Ну и видны подробности этого запроса. То есть Telegram действительно вызвал наш API Gateway. Давайте теперь посмотрим, был ли вызван наш workflow. Соответственно, перейдем сюда, в ресурсы нашего каталога и, соответственно, в наш рабочий процесс. Telegram workflow. Здесь тоже посмотрим на раздел логи. И вот он, наш вызов workflow. Execution started. Step Started, Step Finished, Execution Finished. Выполнение закончилось, то есть наш агент отработал. Давайте мы можем даже посмотреть на то, как это происходило. Вот первый Step Started – это AI Studio Agent Call. Он был вызван. И Step Finished – это он успешно закончился. А где же нам увидеть те данные, которые получились на входе и на выходе? Можем перейти в раздел запуски. И вот он наш один запуск workflow. Когда мы его открываем, мы видим подробности. Данные на входе. Смотрите, это данные, по сути дела, пришедшие от Telegram. Данные, от кого было получено сообщение. First name, last name, Telegram ID. Чат. И вот оно, наше сообщение и привет, которое мы написали в Telegram. Данные на выходе, соответственно, что получилось, и я из студии Agent Call нам ответил, здравствуйте, чем могу помочь. Видите, внутри поля Result он выдал нам такое сообщение. Соответ получен, нам осталось лишь поместить его в Telegram. И это сделать достаточно несложно, нам достаточно отредактировать наш рабочий процесс, добавить сюда еще один шаг. Дело в том, что внутри... В Workflow есть такой уже готовый кусочек, который называется Telegram. Помещаем его сюда, Telegram Bot. И этот Telegram Bot, это, по сути дела, квадратик, который позволяет постить сообщения в Telegram. Для этого что нам нужно сделать? Нам нужно указать, во-первых, секрет Telegram. Его можно задать через специальный сервис LogBox для хранения секретных ключей, но можно задать его здесь явно текстом. Так делать не нужно, потому что это небезопасно, но мы так сделаем для простоты. Давайте я просто возьму и скопирую сюда вот этот самый Telegram токен. И какое действие мы хотим сделать? Видите, здесь есть разные действия. В нашем случае это просто отправить сообщение. Нужно ввести сюда идентификатор чата. Все значения, которые мы сюда вписываем, они пишутся на специальном языке, который называется jQuery. Ну, в принципе, этот язык достаточно понятный. Это язык запроса к JavaScript. Но этот язык здесь используется для того, чтобы извлекать, простите, язык для запроса к JSON-структурам. И выражения пишутся для того, чтобы извлекать из вот этого сложного JSON-входа необходимые поля. Значит, в нашем случае мы видели, что на вход подается JSON из Telegram, и там есть в частности вот такое вот поле под названием message, внутри него поле chat, внутри него поле ID. Соответственно, мы из идентификатора чата пишем message chat ID. То есть сюда нужно подставить, вот эта вот слэш-скобочка означает подставить вот это вот значение. Текст. Какой текст мы хотим сюда поставить? Текст это… Соответственно, сообщение от нашего агента. То есть мы пишем точка agent и здесь пишем result. Единственное, что для того, чтобы это сработало, нам нужно, чтобы наш агент назывался agent, потому что пока что он называется как-то чуть-чуть по-другому. Давайте не забудем. Здесь он называется AI Studio Agent Call. Давайте я его переименую просто в... Agent для простоты. И здесь, соответственно, Agent Result. И мы можем сюда еще добавить поле «Ответить на сообщение». Реплай-то. Оно не обязательно, но мы можем сказать для того, чтобы Telegram писал нам ответ именно как ответ на сообщение, скажем, используя Message ID. Ну и можем выбрать разметку Telegram, например, Markdown V2. Timeout. Тут повторные попытки. Нам это, в принципе, не очень нужно. Вот все, можем сказать, сохранить наш процесс. Рабочий процесс успешно изменен. И давайте проверим, насколько он теперь работает. Напишем, привет, я хочу съесть стейк из рыбы, что есть в меню. И мы видим, что никакого ответа не поступает, значит, наверное, произошла какая-то ошибка. Давайте посмотрим, как с этим разобраться. Переходим в запуски и видим, что действительно наш процесс завершился с ошибкой. Почему так произошло? Можем перейти сюда, посмотреть на вход, правильно ли был здесь подан вход. Да, вроде бы вход правильный, значит, в чем же может быть проблема? Перейдем в раздел логи. И смотрите, здесь сообщение об ошибке. Execution failed with message code. Message reply to must be an int64. То есть какая-то ошибка в поле reply to. Давайте перейдем назад к нашему рабочему процессу. И мы здесь используем в ответить на сообщение message.id. А давайте посмотрим в запуске подробнее, как это поле называлось. Оно называлось message.id, а не message.id. То есть мы просто чуть-чуть напутали в структуре. Идем снова в редактирование нашего процесса. И исправляем здесь месседж в поле «Ответить на сообщение» message.id на message.message.id. И еще одну вещь на самом деле нам нужно сделать. Мы должны подать сообщение из Telegram на вход нашему агенту. И iStudio. Поскольку здесь есть такое вот поле сообщения, в нем ничего не указано, и агент, он, по сути дела, отвечал бы каждый раз на пустое сообщение, а не на наше сообщение из Telegram. А нам здесь нужно явно написать, что мы хотим передать на вход нашему агенту message.txt, то есть сообщение, пришедшее из Telegram. Вот такие исправления мы внесли в наш процесс. И давайте теперь снова спросим. Ту же самую фразу. Я хочу съесть стейк из рыбы, что есть в меню. И через какое-то время, видите, мы получаем ответ. Несколько вариантов стейков из рыбы. Лосось в мечтах и Норвегии. Ну и все цены. Соответственно, давайте теперь мы дальше спросим, а какое вино лучше с этим пить. И какой ответ мы получим, как вы думаете. Выбор вина зависит от блюда. То есть дело в том, что наш агент в данном случае не сохранил историю переписки. Почему это происходит? Потому что, когда мы используем Workflow, у нас каждый раз запускается как бы новый инстанс нашего агента, и история переписки действительно внутри не сохраняется. Чтобы вот таким вот образом через Workflow сохранять историю переписки, нужно каким-то образом ее сохранять внутри состояния Workflow. Это уже более сложное. Поэтому, в принципе, вот ту демонстрацию, которую я вам сейчас показал, она скорее для того, чтобы познакомить вас с функциональностью workflow и каких-то облачных сервисов Яндекс.Клауд. Но на практике, если вы захотите интегрировать такого вот агента, сделанного в AI Studio с Telegram, то намного лучше, конечно, использовать питоновский интерфейс. Здесь вот, давайте еще раз я покажу, если мы возьмем нашего агента созданного, есть кнопочка «Посмотреть код», и вот с помощью вот этого кода всегда из любого Python приложения можно вызывать агента с памятью диалога, со всеми подключенными сервисами, ну и, собственно, написать небольшой коннектор, который будет соединять нашего агента с Telegram. Это более, наверное, правильный, простой подход. Итак, мы с вами видели, как можно создать своего агента, который решает достаточно сложные задачи. Но иногда может оказаться, что одного агента недостаточно. В каких случаях? Ну, языковая модель, на самом деле, когда вызывает инструменты, ей нужно посмотреть на весь список инструментов и принять решение. И очень часто бывает так, что модель недостаточно... Модель четко делает вызовы инструментов, особенно когда инструментов много. Практика показывает, что если инструментов там уже 5, 10 или не дай бог больше, то модель начинает справляться все хуже и хуже. И в этом случае для решения более сложных задач имеет смысл использовать сочетание нескольких агентов, а несколько агентов это уже мультиагентная система. Но мультиагентные системы вообще были придуманы достаточно давно, еще в 90-е годы, и тогда активно обсуждалось, а как вообще строить такие системы. Было разработано много теории, как агенты взаимодействуют. Основанная теория была на теории коммуникативных актов, на аукционах, как агентам договариваться, если им нужно, например, решить разные задачи. И, в общем-то, теории было много, но... Это не очень тогда взлетело. Почему? Потому что агенты были другими. Агенты были, как правило, рассуждающими на основе каких-то правил. И для того, чтобы им общаться, им нужно было иметь некую общую картину мира, то, что называли тогда антологией, и какие-то языки для общения. Соответственно, были разработаны языки для общения, Knowledge Interchange Format, KIF, или KQML, Knowledge Query and Manipulation Language. и отдельные языки, и специальные логики для представления и работы с онтологиями. Это все казалось очень сложно, потому что для того, чтобы описать предметную область на каком-то формальном языке, нужно было уже потратить много сил. Что же поменялось сейчас? Сейчас мы видим, что агент управляется большой языковой моделью, а у большой языковой модели, во-первых, она может общаться на естественном языке, что делает общение между агентами очень интерпретируемым. И, в общем-то, простым нам не нужно заморачиваться по поводу того, чтобы эту фразу как-то описать, понять конкретно, что она значит. Языковая модель сама это как-то делает. И, во-вторых, антология, некая картина мира, у языковой модели уже есть, у агентов есть какой-то здравый смысл, и, в принципе, этим тоже заморачиваться не нужно, поэтому делать многоагентные системы, мультиагентные системы из взаимодействующих ЛЛМок, в общем-то, проще, чем это было в 90-е годы. Ну вот, давайте рассмотрим, опять же, эту идею с выбором блюда в ресторане. Понятно, что вот наш агент один, в принципе, с этим уже как-то справлялся, но подумаем, как этот процесс делается в реальной жизни. В реальной жизни, когда человек приходит в ресторан, посетитель, да, он, значит, не всегда знает, что он хочет, но у него есть какие-то там примерные ожидания, что он хочет съесть, и он встречается вначале с официантом, официант... В ходе диалога помогает уточнить вот эти вот предпочтения человека, и при этом он обращается еще к агенту Сомелье, который точно знает, как вот подбираются блюда и вина. В нашем случае, когда мы делали одного агента, эти как бы различные аспекты личности, они были представлены инструментами различными, но можно попытаться представить их в виде отдельных агентов. И в реальном мире, наверное, эти агенты как-то будут между собой достаточно хитрым образом общаться, но мы в качестве примера покажем такой более простой пример, когда у нас этот процесс, он достаточно четко регламентирован. Ну вот, например, посетитель приходит, он общается с первым агентом, условно, хостес, который понимает, как... Нужно, что человек хочет примерно съесть и извлекает какую-то структурированную информацию из этого. Дальше сам Илье подбирает блюда, делает так, чтобы блюда были с вином в соответствии. И официант предлагает конкретные позиции из меню и считает общую сумму счета. Соответственно, какие еще есть причины выделять процесс в виде многоагентной системы? процессом решения. Если, например, у нас есть какая-то бизнес-задача, под которую уже опишен бизнес-процесс, то логично использовать для его автоматизации набор взаимодействующих агентов, взаимодействующих по четкому правилу, по некоторому, условно говоря, workflow. И когда мы явно задаем процесс решения, мы себя обезопасиваем от того, что языковая модель будет выдавать какие-то не очень... стабильные результаты. Дело в том, что языковая модель всегда выдает какой-то результат, и это результат вероятности, он может оказаться хорошим или плохим. И вот если мы, чем больше вещей мы контролируем, тем надежнее получится наша система. Ну и, наконец, может быть, просто слишком сложная логика для одного агента. Давайте посмотрим, как нам организовать эту цепочку из агентов с помощью workflow. Для начала превратим нашего агента-сомелье в агента, который может просто делать рекомендацию к блюду или к еде. Для этого давайте удалим лишние инструменты, перейдем в режим редактирования и удалим отсюда веб-поиск, MCP-сервер, оставим только базу данных по подбору соответствий. И давайте изменим системный прункт. Скажем, что ты опытный сомелье в ресторане, на вход приходит пожелание пользователя по вину, по основному блюду или по обоим пунктам, и на основе этого дополни пожелание пользователя своими рекомендациями и выдай ответ вот в таком вот виде. Используй рекомендации из файлового поиска. Давайте сохраним результат и подадим на вход какой-нибудь вариант. Например, первое, не знаю, второе. Вернее, не первое, второе, а скажем, основное блюдо, не знаю, напиток красное вино. И посмотрим на ответ. Видим, получается, основное блюдо стейк говяжий мраморный и какие-то рекомендации по напиткам, и при этом таких вариантов есть несколько. Но попробуем сократить чуть-чуть вывод бота и попросим его выдавать один. Вариант, ну, для упрощения нашего примера. Выдавай, значит, если вариантов несколько, выдавай один из них, самый подходящий. И зададим вопрос, основное блюдо стейк, напиток не знаю. Вот, и получаем основное блюдо стейк, напиток красное вино, например, такой-то, такой-то. Ну, достаточно подробное описание. Это будет наш агент-самелье, который дополняет рекомендации пользователя. И теперь для нашей многоагентной системы нам нужно создать еще несколько агентов. Давайте создадим агента под названием Hostess. Она будет принимать пожелания пользователя и выдавать их в структурированном виде. Ты просто в ресторане. Тебе необходимо принять на вход пожелания пользователя по ужину, включающий информацию об основном блюде и напитке, и выдать его в структурированном виде. Основное блюдо такой-то, напиток такой-то. Если пожеланий нет, пиши «не знаю». Давайте проверим, как это работает. Пользователь пишет «я хочу съесть мясо». И наш ответ «основное блюдо мясо, напиток не знаю». Это можно уже подавать на вход сомелье. Ну и давайте еще. одного агента, это агент-официант, waiter. Официант у нас будет в качестве инструмента принимать MCP-сервер нашего ресторана, с меню нашего ресторана. Выбираем наш MCP-сервер и пишем системный промпт. Напишем такой промпт, что ты опытный официант в ресторане, с опытом работы 10 лет. Тебе на вход приходят пожелания от посетителя по основному блюду и по напитку. Выбери подходящие варианты блюд в меню, напиши на выходе список блюд для ужина, включая их название, стоимость и посчитай общую сумму чека. Ну и давайте это протестируем. Скажем, основное блюдо – стейк, напиток – красное вино – хира. Давайте напишем так, потому что Сомелье же нам рекомендует уже какой-то конкретный сорт вина, скорее всего. Видите, происходит запрос на вызов инструмента. Нам нужно сейчас будет изменить конфигурацию, чтобы нам не нужно было каждый раз нажимать разрешить, разрешить. Давайте даже, наверное, сначала это сделаем, потому что иначе это становится утомительным. Нам нужно сказать, что подтверждение не нужно, чтобы MCP-сервер вызывался автоматически. Вызываем еще раз и получаем вариант S-TakeBook на взводе. Напиток такой, например, заказа. Ну, в общем-то, вполне себе неплохой вариант ответа от официанта. Вот мы таким образом сделали трех агентов, и теперь можно, кажется, их поставить в наш workflow. Давайте перейдем в раздел workflow и отредактируем наш существующий workflow. Скажем, редактировать. И заменим первого агента на агента названием Hostess. Соответственно, первый у нас будет Hostess, который будет извлекать из сообщения пользователя какую-то структурную информацию. Дальше нам нужно добавить следующего агента. Мы в графическом режиме вот так вот добавляем сюда еще один шаг. И наш второй агент – это будет агент Семелье. Давайте я назову его Семелье. И на вход ему будет подаваться выход предыдущего агента хост. То есть мы будем писать .agent. У нас агент назывался agent. И result. Помните, мы раньше это сообщение result подавали на выход в Telegram. Теперь же мы это сообщение подаем на вход нашему агенту Sommelier. И после агента Sommelier у нас будет работать агент-официант. Опять же, графическим образом. Перетаскиваем агента сюда. У нас появляется еще один шаг. И, соответственно, агент Waiter. Назовем этот шаг тоже Waiter. И на вход подадим сообщение от Sammelier Result. Ну и, наконец, выход Telegram-бота будет брать текст из Waiter Result. Вот примерно такой у нас с вами получился. Сохраняем его. И давайте посмотрим, как он работает. Напишем «Хочу съесть что-нибудь из мяса». И теперь по очереди будут вызываться все агенты. Давайте убедимся, что это действительно происходит. Если мы посмотрим в логе, то мы увидим, статус выполняется. И действительно, это достаточно небыстрый. потому что должны сработать три ассистента. Ну вот, мы видим, они закончились, и можно посмотреть на ответ. Да, действительно, получился ответ, несколько вариантов основных блюд, общая сумма чека. Ну, в общем, в принципе, вполне себе нормальный ответ. Итак, мы видели с вами простейшую. Многоагентную систему, которая состояла из нескольких шагов, но, естественно, на практике все будет чуть сложнее. Но даже вот в нашем примере, если пользователь, например, хотел бы съесть какое-нибудь блюдо из краба или из осьминога, которого нет в меню, то, очевидно, официант в какой-то момент должен был бы ответить, такого блюда нет, и нам нужно было бы вернуться к началу, попросить пользователя изменить свой заказ или как-то сделать другую подборку. блюд и вин, если, например, хорошее вино было не найдено под данное блюдо, вот кажется, что в реальной жизни для того, чтобы быть надежной, многоагентная система должна иметь более сложную конфигурацию. И действительно, такие конфигурации, их можно создавать, их можно создавать, в принципе, даже в workflow, но это чуть-чуть сложнее уже будет делать. Их можно создавать программно, с помощью программного кода, с помощью различных библиотек. В целом, вот такие агентные системы, которые собирают из разных агентов рабочие процессы, называются Agent Workflows. Агентик Workflows еще их называют. И есть, например, у компании Anthropic подробный такой гайд, какие существуют варианты архитектуры. На слайде вы видите, примерно они нарисованы. Это может быть один агент-супервизор, который управляет подчиненными. Это может быть иерархическая организация агентов, которая примерно соответствует организации людей. В организации, когда есть начальники разного уровня. Это может быть произвольная конфигурация агентов. Есть здесь много разных вариантов. Но это один подход, когда мы руками с вами прописываем вот такую многоагентную архитектуру. Второй подход — это рассуждающие агенты, reasoning agents, они еще называются react-агентами, от слова reasoning and acting. Здесь... Мы отдаем создание плана по выполнению задачи на откуп языковой модели. То есть, иными словами, когда приходит какая-то задача от пользователя, языковая модель смотрит на нее и строит некоторый план решения задачи. Она говорит, вот первым делом пойдем сюда, пойдем там, например, в MCP сервер получим... список блюд, дальше по списку блюд построим какую-нибудь таблицу соответствий, и вот дальше агент действует внутри себя по шагам, каждый шаг это некий вызов инструмента и получение от него ответа, дальше агент смотрит на этот ответ, успешен ли был этот шаг или нет, пересматривает план, и вот этот вот цикл выполнения, он повторяется много раз, пока не будет получен уже правильный ответ. Вот такой подход, он очень красиво звучит, но, к сожалению, на практике он не всегда работает достаточно надежно. Почему? Потому что LLM, мы знаем, как бы она может накосячить, условно, да, она может сделать что-то чуть-чуть не так. И если LLM... как бы с определенной вероятностью делает там неправильный вызов инструмента или неправильное решение, то когда у нас решение задачи состоит из нескольких шагов, и каждый из шагов может пойти не так, то общая вероятность, что что-то пойдет не так, она сильно возрастает, как вы знаете, наверное, из теории вероятности. Хорошо, конечно, то, что в таких вот React-агентах реагент может сам себя поправлять. Если что-то пошло не так, и мы видим какой-то неправильный вывод инструмента, она скажет, окей, это не сработало, повторим еще раз, или сделаем то же самое с помощью другого инструмента. Например, если используется какой-то веб-поиск, и ничего не нашлось подходящего, можно переформулировать запрос, или, например, поискать какую-то страницу более общую и на основе ответов поискать что-то дальше более детально. Поэтому способность к самоисправлению спасает ситуацию, но опять же спасает в каких-то случаях, в каких-то случаях нет. Поэтому React-агенты, они, конечно, менее в целом надежны, менее предсказуемы. Опять же, непонятно, сколько такой агент потратит средств, потому что он может вызывать языковые модели достаточно долго и много раз. Поэтому то, что мы сейчас наблюдаем, мы наблюдаем некий спектр агентных технологий. На одном конце спектра это явная оркестрация, это workflows, которые я вам показал. И здесь помимо инструмента workflows в Яндекс.Облаке есть, естественно, инструменты программного кода, это библиотеки LangGraph, Lama Index, это отчасти может быть Nathan как инструмент создания вот таких цепочек. И это предсказуемый подход. И бизнес очень часто идет именно по этому пути. Если у нас, например, есть какая-то отработанная цепочка бизнес-процессов, мы просто создаем агенты, которые автоматизируют каждую ее часть, и рисуем эту цепочку в таком вот workflow-инструменте. Это требует менее мощных языковых моделей, потому что мы от них ожидаем меньшей умности, скажем так, в планировании. Мы не ожидаем планирования от агентов, мы планируем возможные... шаги цепочки сами. Мы сами понимаем, когда может случиться проблема, когда нужно какую-то ошибку обработать и так далее. И вторая половина — это более гибкие React-агенты. И здесь есть тоже специальные библиотеки. Есть, например, Small Agents, есть Microsoft Altogen, есть OpenAI-ная библиотека для создания агентов. которая позволяет строить такие системы, в которых цепочки вызовов агентов динамически появляются. И такой подход, наверное, хорош в ситуациях, когда у нас агент не является то, что называется customer facing, когда, например, мы создаем агента для решения какой-то своей задачи или для попытки решения задачи. Ну вот в некотором смысле... Если мы возьмем имеющийся в разных GPT-инструментах подход типа Deep Research, когда мы задаем вопрос, и дальше агенты пытаются найти ответы на эти вопросы, но иногда успешно пытаются, иногда неуспешно, мы можем уже потом это сами посмотреть на результат и решить. Когда нам не нужен 100% гарантированный правильный результат прямо сейчас, мы можем поэкспериментировать, вот тогда такие динамические агенты оказываются более перспективными. Итак, мы подходим к завершению нашего вебинара. Мы видели, что технологии позволяют создавать агентов достаточно просто. Можно в Яндекс.Клауд создавать агентов даже без навыков программирования. И если кто-то из зрителей, кто нас смотрит, никогда этого не делал, то я вас призываю, конечно, это сделать, попробовать сделать какого-то своего агента на тему, которая вам интересна. Вот, и из агентов можно составлять более сложные агентные системы для решения более сложных задач. Это можно делать двумя такими очень разными способами. Ну, на практике, если мы делаем какую-то большую систему, наверное, в ней может быть какая-то жесткая часть, а внутри, как бы, каждый агент может чуть-чуть уже планировать. Мы видели, что даже один сам по себе агент, снабженный инструментами, он внутри себя может планировать, ну не в явном виде планировать, но он как бы принимает решение, какие инструменты ему нужно вызвать для решения задачи. Это может быть задача достаточно сложная, типа вот подбора меню в ресторане. И пока что на практике агентные подходы, они, конечно, очень различаются, разные компании экспериментируют с разными подходами, и, наверное... В ближайший год мы увидим на практике много примеров использования таких систем, получим какой-то дополнительный опыт и сможем больше узнать про разные подходы к агентам архитектуры. В заключение мне хотелось бы еще раз повторить свой призыв. Если вы не пробовали никогда создавать своих таких агентных агентов, пожалуйста, используйте вот этот вебинар как возможность поэкспериментировать. По сути дела, все шаги, которые для этого нужны, я показал в ходе демонстрации. Я вас призываю проделать некоторое самостоятельное упражнение дополнительное, сделать какого-то своего. агента на интересующую вас тему, и если вы это сделали, обязательно поделитесь с нами, по итогам этого вебинара есть такой специальный опросник, который мы сделали, расскажите, что интересного вы сделали, приведите даже в идеале ссылочку на такого агента в Телеграме, чтобы мы могли с ним пообщаться и тоже получить удовольствие, и я напоминаю, что активных участников В конце вот этой большой агентской недели AI Studio Series ждет приглашение на суперпрекрасное секретное мероприятие, где мы сможем уже с вами лично пообщаться, и вы сможете узнать какие-то такие инсайты про направление развития агентской платформы в Яндекс.Клауд. Итак, меня зовут Дмитрий Сошников. Если вам интересны какие-то темы, связанные с искусственным интеллектом, с агентными технологиями, с искусством, с образованием. Вот на все эти темы я пишу у себя в телеграм-канале, телеграм-канал «Облачный адвокат». Буду рад вас там видеть. А пока что я с удовольствием перехожу к вашим вопросам, которые пришли по ходу этого вебинара. И, значит, первый вопрос, который был, это... как подключить базу данных к такому агенту. Ну и я так думаю, что под базы данных здесь имеется в виду какая-то база данных с записями, не текстовая база знаний, как вот в случае с рагом, потому что текстовые базы знаний легко подключить с помощью рага, и они могут быть как бы там модифицируемы по ходу дела, можно добавлять файлы динамически. Но если идет речь про классическую базу данных, то... Мы видели, что есть инструменты, да, можно подключить с помощью инструментов, но тут есть, опять же, два таких подхода. Либо мы подключаем инструменты под конкретные бизнес-задачи, то есть вот есть, например, задача добавить там какую-нибудь заявку. И вот мы говорим, вот инструмент, который добавляет заявку, а дальше уже внутри инструмента мы распихиваем нужные данные по нужным табличкам в нашей базе данных. Это, наверное, более предпочтительный подход, потому что мы фокусируемся не на... как таковой базе данных, а на бизнес-задачах. А бизнес-задачи — это понятная вещь, которую можно объяснить агенту. А второй подход, наверное, более гибкий — сказать, типа, у нас есть универсальная функция, которая позволяет транслировать в SQL любой запрос пользователя, и этот SQL мы сразу передаем в базу данных. Такие варианты как бы тоже... Есть, но вот мне кажется, по моему мнению, они не имеют права на существование, потому что мы слишком рискуем. Языковая модель может все что угодно нагенерить, и как бы мы не контролируем, какой код будет выполняться внутри SQL-базы данных. Это, наверное, не самый лучший подход. Вот, следующий вопрос. Значит, можно ли скормить всю документацию по клауду нейронки, чтобы она по запросу сама предлагала решение? Ну, тут как бы ответ, естественно, да, это можно с помощью рага сделать несложно, мы скармливаем всю документацию, как бы первая часть вопроса ответ да. Вторая часть вопроса, ну, вернее, как она будет, мы можем ей спросить, предложи решение, но тут вот вопрос, а что понимать под решением, как бы, да. Дело в том, что архитектор, когда принимает решение, он много вещей должен учитывать, он должен, наверное, побеседовать с заказчиком много раз, поэтому, чтобы предложить хорошее решение, Нужно действительно учесть много вещей, и в этом смысле агентный подход, когда агент рассуждает, он, наверное, может как-то приблизиться к тому, чтобы сделать хорошее решение. Но на самом деле у нас даже есть такой демонстрационный стенд, который примерно то, что вы говорите, делает, он строит некоторую архитектуру системы в облаке, но, естественно, это не та архитектура, которая окончательная, по которой нужно сразу делать систему. Вот, может ли AI-студия использовать сторонние какие-то модели, которые хостятся, например, через AllLama? Значит, нет. Дело в том, что если мы строим агента внутри облака, то он использует облачные ресурсы. Вы можете, конечно, сделать какой-то свой ресурс, который будет, какую-то кастомную модель в облаке, как бы, инференсить, да, вот. Это такой подход не очень простой, и с ней будут всегда сложности. Кастомную модель сложно хостить, потому что экономика непонятно, как будет сходиться. Всегда лучше использовать готовые модели в облаке. Еще вопрос. Как отслеживать расход токенов на запрос для оптимизации расходов? Хочется иметь возможность разбивать расходы через какие-то задачи по отдельным запросам. Но на самом деле какого-то готового компонента для этого нет. Но если посмотреть на тот JSON, который возвращает запрос к языковой модели, то по нему можно получить количество использованных токенов. И можно, если вы реализуете какую-то свою систему, можно просто все количество использованных токенов самостоятельно логировать в какой-то... базу данных, и потом по ней уже делать все необходимые срезы и оптимизировать расходы. Насколько модели, кроме Яндекс.ДпТ, адаптированы к строгой схеме ответа? По нашему опыту, другие модели отступают от схемы в некоторых случаях. Модели Яндекса обучались специально под строгую схему. Да, адаптированы. Я про это отдельно не рассказывал, но есть у языковых моделей такой режим, который называется Structured Output, когда мы четко задаем модели, что ответ должен быть в каком-то конкретном виде. Кстати, через диалоговое создание агентов, вы видели там JSON и JSON-схема, можно четко задать схему, в которой мы ожидаем от модели ответ. И на самом деле вот эта вот схема, она же инфорсится на этапе, То есть, как бы модель сама по себе, она может разные вероятности токенов выдавать, но когда используется Structured Output, выбираются только те токены, которые укладываются в схему, поэтому мы эту схему достаточно жестко инфорсим, но единственное, что если, например, ответ модель не находит, она все равно возвращает ответ в виде какой-то правильной JSON-схемы, и в этом смысле использование JSON-схемы налагает чуть-чуть... на вас ответственность, что вы должны посмотреть на нее и понять, а может быть модель вообще не хотела отвечать, но ей пришлось. Поэтому да, схема, она достаточно жестко инфорсится, и все модели, это современные модели, это поддерживают. Значит, как узнать, с какого именно веб-сайта агент взял информацию про стоимость Мирло в моем примере с веб-поиском? Но на самом деле вот мы видели полный такой JSON-формат ответа, внутри этого полного JSON-формата ответа содержится информация, какие именно фрагменты текста, из каких сайтов подавались модели на вход. Вот, для каких агентов и целей лучше использовать QN3, а когда будет достаточно Яндекс.GPT 5.1, насколько при этом будет отличаться их стоимость. Ну, стоимость нужно посмотреть на самом деле на сайте, но, как мне помнится, их стоимость, она, ну, примерно одного порядка. То есть, Яндекс.Дж.ПТ может быть чуть-чуть подешевле, но прям буквально совсем чуть-чуть. Когда лучше использовать какой? Ну, Яндекс.Дж.ПТ, он чуть-чуть больше дообучен на русском языке. и при этом он дообучался много под рак задачи, то есть он хорошо умеет работать с инструментами поиска. Квен, он, соответственно, более универсален, он лучше знает целый спектр языков, и он лучше делает, наверное, какие-то сложные инструкции, планирование и тулколинг. И вот, кстати, еще один повод использовать многоагентные системы состоит в том, что вы можете же разные агенты заводить на разных ЛЛМках, да, и использовать, например, для начальной классификации запроса какую-то простую недорогую ЛЛМку, а дальше, в зависимости от запроса, уже использовать разные ЛЛМки. Вот, есть ли какой-то механизм такого гибкого контроля за рагом? Как бы в начале, например, берем 5 чанков, а на каждый следующий запрос берем по 25 чанков. Значит, на самом деле, если вы делаете это через веб-интерфейс, то там все достаточно жестко, вам нужно просто прописать число чанков. Если вы делаете это из своего программного кода, вы же каждый раз, когда вызываете модель, передаете список инструментов. И в этом списке инструментов есть инструмент... файлового поиска, и в нем есть параметр количества чанков. То есть вы, если понимаете вот это правило, по которому вы хотите менять количество чанков от запроса к запросу, то вы можете это руками в своей программной системе предусмотреть, просто как бы поменять, и этот параметр, например, будет увеличиваться или уменьшаться. Единственное, что не очень вот я понимаю, когда это может быть нужно, потому что если мы возвращаем больше чанков, это ну как бы ничем не плохо, кроме того, что запрос становится дороже, и мы рискуем не влезть в контекст. Вот, поэтому, а по смыслу как бы модель, она же все равно из всех щанков извлекает именно ответ на запрос пользователя. Вот, значит, для обращения к условному ресторану, мой агент должен обратиться и должен быть свой MCP-сервер у ресторана. Да, у ресторана должен быть MCP-сервер, но... Вот этот MCP-хаб в Яндекс.Облаке, он позволяет нам любой запрос в интернет обернуть в формат MCP. То есть, если, например, у ресторана есть какой-то API, не MCP-шный, обычный API, в котором есть просто вот там некий метод, верни блюдо там, поищи блюдо или что-то такое, мы можем обернуть это с помощью MCP-хаба просто вот через веб-интерфейс в MCP-сервер, в MCP-формат. Это очень удобно. Следующий вопрос. Диалог может переполнить контекстное окно. Как этим можно управлять? Если окно переполнится, то какая-то часть его будет забыта. Если вы хотите контролировать этот процесс, то встроенного пока что средства нет. Но в этом направлении стоит ждать новостей. Как собирается аналитика по обращению конкретного пользователя? Значит, автоматически это не делается, но если вы, опять же, если вы делаете какой-то свой пользовательский интерфейс, то у вас есть полный контроль вызова агента, и вот на этом этапе вы можете сделать любое свое логирование, писать это в какую-то базу данных, и дальше по ней делать любые срезы и аналитику. Как проверить, что канал связи с MCP-сервером безопасен? Но он как бы настолько же безопасен, насколько любой HTTPS-вызов по интернету, то есть как бы это протокол HTTPS, то есть он использует по умолчанию какое-то шифрование. Если вы хотите сделать его еще более безопасным, ну, как бы вы можете это сделать в рамках доступных средств, там, например, какие-то, какое-то делать шифрование, а уже потом в облаке, как бы близко к LLM, делать расшифровку и подачу текста на вход LLM. В целом, мне кажется, HTTPS для большинства задач достаточно. Дальше вопрос. Если мы создали агента через low-code, no-code, можно ли сделать его бэкап-сервер Яндекса? То есть как вообще писать код, если low-code, no-code, ну, грубо говоря, у нас нет файлов, у нас есть только клики мышкой. Именно поэтому, наверное, low-code, no-code в серьезных проектах не надо все-таки использовать, потому что никакого способа извлечь какой-то условно там, в текстовом описании получить этого агента, некоторое текстовое представление нету, хотя, наверное, это не очень сложная задача, потому что кажется, что можно было бы какой-то формат описания придумать, но все-таки нет такого пока что, и поэтому подход код-фест, когда мы все-таки описываем все в виде кода, он, наверное, для серьезной разработки предпочтительен, потому что мы хотим историю хранить, мы хотим в гитхабе изменения видеть. И дело в том, что подход на основе кода, он в принципе не сильно сложный. Дело в том, что Responsys API же берет на себя всю вот эту вот сложность с вызовом инструментов. Вот, и если мы, агент, делаем просто как вот набор, как цепочку вызова инструментов, то, по сути дела, код — это просто перечисление, описание инструментов в таком вот JSON-формате. Ну, и это, в общем-то, очень похоже на как раз-таки описание, которое... описание структуры самого агента, которое вы получили из веб-интерфейса. Поэтому, да, лучше, конечно, с помощью кода. И как это делать, вот отдельный вебинар сегодня на эту тему вышел. Значит, как подключить таблицу через Google Sheets? Можно подключить табличку из Google Sheets. И напрямую мне, наверное, не очевидно, насколько это можно сделать и как, но, наверное, можно через MCP попробовать, если есть какие-то готовые MCP-сервера, которые это поддерживают. А если нет, то зависит от размера таблички, можно ее экспортировать в Markdown и подгрузить как рак базу данных, но при этом у вас не будет возможности делать запросы, например, какое самое большое значение в столбце, потому что рак извлекает всегда кусочки текста, или какой-то написать свой простой инструмент. Вот, значит, как можно организовать поиск и подбор не просто текстовых и числовых данных, но с изображениями, графиками, инструкциями и так далее. Но дело в том, что если вы используете вот этот встроенный рак в AI-студию, то это очень умный рак, и вы можете загружать в него не только текстовые документы, а документы в каких-то сложных форматах, например, Word, Excel, PDF. И эти документы... по возможности индексируется достаточно умным образом. Например, в PDF-документах учитываются изображения и картинки. Они извлекаются и тоже перерабатываются в некоторый текстовый формат. И поэтому, понятно, что, наверное, это не идеально пока что, но, тем не менее, постоянно эти инструменты совершенствуются и становятся лучше и лучше. Поэтому используйте встроенный механизм файлового поиска. Друзья, спасибо большое за вопросы, я вынужден потихонечку заканчивать, потому что уже скоро начнут меня выгонять отсюда из студии. Большое спасибо вам за участие, я напоминаю, что вы можете заполнить квиз, указать какого-то своего созданного вами агента в этом квизе, и это будет вам считаться как активность в рамках вот этого, этой цепочки мероприятий Я и Студио Сириас. Ну и будем ждать вас на следующем мероприятии iStudio Series уже скоро. А сейчас на этом я с вами прощаюсь. Спасибо за внимание. Всем хорошего дня.

Дмитрий Сошников рассказал, что такое AI-агенты, и показал, как создать мультиагентную систему на платформе для разработки AI-приложений Yandex AI Studio.


00:00 Приветствие (Дмитрий Сошников)
00:47 Анонс серии вебинаров (Дмитрий Сошников)
02:11 Что такое AI-агент? (Дмитрий Сошников)
02:55 Доступ в Yandex Cloud (Дмитрий Сошников)
03:48 Доступные языковые модели (Дмитрий Сошников)
05:05 Минимальные компоненты агента (Дмитрий Сошников)
06:11 Создание простейшего агента (Дмитрий Сошников)
07:07 Создание агентов через no-code и программный код (Дмитрий Сошников)
08:55 No-code/low-code создание агентов через консоль Yandex Cloud (Дмитрий Сошников)
14:25 Программирование агентов через Response API и OpenAI SDK (Дмитрий Сошников)
15:55 Реализация памяти диалога (Дмитрий Сошников)
17:07 Инструменты (tools) (Дмитрий Сошников)
18:22 Web-поиск для актуальных знаний (Дмитрий Сошников)
24:26 Файловый поиск для локальной базы знаний (Дмитрий Сошников)
34:14 Как работает Function Calling (Дмитрий Сошников)
37:00 Создание и подключение MCP-серверов для доступа к кастомным функциям (Дмитрий Сошников)
43:37 Пример использования MCP-сервера (Дмитрий Сошников)
57:04 Интеграция агента с Telegram через Workflows (Дмитрий Сошников)
01:14:40 Концепция мультиагентных систем и их преимущества (Дмитрий Сошников)
01:19:57 Использование мультиагентной системы (Дмитрий Сошников)
01:27:38 Различные архитектуры мультиагентных систем (Дмитрий Сошников)
01:29:21 Сравнение подходов к созданию мультиагентных систем (Дмитрий Сошников)
01:31:47 Спектр агентных технологий (Дмитрий Сошников)
01:35:35 Заключение (Дмитрий Сошников)
01:37:10 Ответы на вопросы (Дмитрий Сошников)