Workflow vs Agent: как выбрать архитектуру AI-продукта?

У нас есть два способа, как мы проектируем AI продукты или AI процессы.

Каждый раз, когда выходит новая модель, вы практически ничего не делаете, а весь ваш продукт становится, ну, или агент, а, становится лучше, умнее. Агенты, реализованные на модельке 3.5, они показывают результаты лучше, гораздо лучше, чем не просто модель такая же, но и модель следующего поколения.

Сегодня у нас стартует курс по AI Product Engineering, уже третья когорта. И мы сегодня поговорим про два, наверное, подхода, которые есть в проектировании агентов. Я хотел бы их объяснить и потом, а, мы, соответственно, сначала попробуем. Обычно у нас подход какой, что мы где-то, наверное, 30-45 минут — это такая теория, а потом мы посмотрим на практике, как раз эти два подхода и чем они отличаются, в чём плюсы и минусы каждого подхода.

Если посмотреть на структуру, а, то у нас по сути пять таких глобальных тем. Первое, вот сегодня будет, это AI Workflows versus AI agent, когда какой лучше применять. Потом мы поговорим с вами про LLM powered Product Management и как проектировать системы, которые, а, позволяют, скажем так, эмулировать поведение пользователей и, а, делать реч, связанный с продуктом. Дальше, как проектировать мультиагентные системы, как тестировать AI продукты и набор специальных топиков, которые касаются того, как проектировать voice агентов, кодинг агентов, а GPT апы и cl skills.

Вообще, смотрите на курс, что 80% тем, они, а, скажем так, жёстко утверждены, а 20% — это то, что может меняться. Поэтому, если вдруг у вас есть потребность в какой-то теме, которой сейчас нет, а, то не стесняйтесь, говорите, и если это будет, а, там, популярная и востребованная задача, то мы обязательно это включим. Вот в прошлом, например, потоке так мы стали говорить про контекст инжиниринг, потому что мы, ну, там увидели, что это достаточно актуальная тема, и её надо разобрать, и мы будем разбирать её, а, в третьей, а, ну, на третьей встрече, когда будем говорить про мультиагентные системы. Поэтому, если видите какие-то задачи и темы, которые актуальны, то говорите мне, и мы, если они востребованы многими, то мы будем добавлять и формировать там или изменять немножко курс по мере того, как в этом, ну, скажем так, есть потребность. Ну и, э, конечно же, сама область меняется достаточно быстро. И какие-то темы могут появиться, потому что мы, ну, я вижу, что это происходит, что эта потребность в этой задаче возникает, и поэтому я понимаю, что это нам обязательно нужно добавить. Вот примерно так такой план на структуру курса.

И последний, наверное, из такой вводной штуки, это у нас будет сквозной проект, проект, который мы будем на каждой встрече реализовывать. И тут, э, вы должны к нему относиться следующим образом. Если у вас есть рабочий проект или свой какой-то проект, который вы хотите реализовывать, вы можете взять его. А, но если вдруг у вас нет, то вы можете делать проект, который, собственно, я предлагаю. Это будет проект системы, а, который, да, мы делаем в продакшене, как продукт и продаём. Ну, скажем так, это будет небольшая копия, скажем так, того, что мы делаем. Но а тем не менее на каждой встрече мы будем потихонечку строить систему, которая, а, позволяет автоматизировать реч. Outrch — это процедура поиска и контактирования с потенциальными клиентами в продажах, да. Поэтому, а, мы сначала вот там сегодня, допустим, мы научимся делать простейших агентов, потом мы сделаем research та, потом мы сделаем мультиагентную систему, потом научимся тестировать этих мультиагентную систему. И а мы научимся давать возможность агентам воспринимать и воспроизводить голос, писать код и так далее. То есть они станут мультимодальными. Поэтому на каждой встрече мы будем потихонечку строить часть этого проекта, чтобы в итоге у нас получилась мультиагентная система для автоматизации sales outча. Ещё раз, если вдруг у вас свой проект, то, конечно же, используйте свой. Нету никаких требований, чтобы это было именно этот. Это даётся для тех, а, для кого, скажем так, нету своего проекта или не можете придумать или не хотите придумывать, и вы можете использовать это.

Ну и, наверное, последнее из такой вводной, наверное, штуки, это что, а, мне очень понравилась статья, э, которую Тиму Рейли выпустил, ну, наверное, где-то полгода, год назад. Про то, что с AI меняется программирование. Я думаю, что даже в представлениях многие из вас про это говорили. Эм, что с AI, конечно, а, очень сильно меняется то, как мы программируем. И наша задача, собственно, понять, а, каким образом оно меняется, что именно меняется, как это может быть, как это, какие плюсы и минусы у этого есть.

А сегодня у нас ключевая тема — это transition, который я замечаю, происходит в нашей индустрии последние, наверное, ну, активно я это замечаю вот в этом году, в двадцать пятом, а, но какие-то элементы transition, э, там признаки этих изменений, они, наверное, появились ещё в конце двадцать третьего, начале двадцать четвёртого года. Просто тогда технология ещё была не настолько готова, а, чтобы это делать, а сейчас уже явно это видно, особенно, конечно, с появлением агентов таких как CLD код, а, или курсор, которые, а, мне кажется, кардинально не просто поменяли, а доказали нам, что некоторые вещи возможны и возможны. И именно так надо делать. Вот, собственно, об этом мы поговорим.

И, скажем так, заголовком для этой для этого разговора будет, что у нас есть два способа, как мы проектируем а AI продукты или AI процессы. Один — это так называемый workflow, когда мы, например, у нас есть какой-то детерминированный порядок исполнения какой-то задачи. А, допустим, если бы мы писали письмо потенциальному клиенту, то это было бы, э, там код, который берёт, а, допустим, информацию про клиента, а, скачивает её, а, из LinkedIn, а, соответственно, трансформирует её там каким-то образом и потом подаёт в LLMки и получает от LLMки сообщения, которые мы должны были или написать. А, и это всё, вот этот, вот эта последовательность действий, она пишется в коде. Соответственно, эту последовательность действий мы выполняем и в итоге получаем результат. Это мы будем называть workflow.

А второй же вариант — это так называемый agentic вариант. И как раз мы его разберём сегодня, а, чуть более подробно. Давайте, чтобы была, скажем так, иллюстрация в голове и некоторая метафора про вот эти два варианта реализации задачи, а, я скажу, что на самом деле эти два варианта похожи на два типа сотрудников, которые бывают в компании.

И первый тип сотрудников — это такой скрипт фолловер, то есть это сотрудник, который по заданной инструкции делает задачу, и он суперэффективен, а, он хорошо следует инструкции, он не делает ненужные шаги вправо-влево, но при этом а есть одна только проблема, что если а меняется окружающая среда. Если что-то идёт не так, то этот сотрудник попадает в такой ступор, потому что он не знает, что делать. И он приходит и спрашивает у начальника, что делать. Вот был такой тест, когда я ещё был студентом. Мы у там руководителя одного из крупнейших аэропортов Москвы, э, он сделал такое такое э такой тест. В общем, а, у него были консультанты, они хотели внедрять риск-менеджмент. Э, и они сделали такой эксперимент, что он собрал своих всех замов, а, и, а, там, посадил их за стол и, э, сказал им: "Ребят, у нас вот там мы проиграем сегодня следующую ситуацию. Представьте, что у нас внештатная ситуация. Самолёт при посадке вышел за пределы посадочной полосы и загорелся. А что вы будете делать? Напишите первые три действия, которые вы сделаете." И как вы думаете, а, какое было самое популярное действие, которое сделает каждый из сотрудников вот в этой внештатной ситуации?

>> Вызвать службу спасения?

>> А, хорошо. А ещё, да, на самом деле вот Алекс прав, что самое вот это было в топ-два. У у многих это было первое, а, но у некоторых это было второе. Это сообщить начальству, спросить у начальства, что делать. И вот этот тест, мне кажется, хорошо иллюстрирует ситуацию, когда, а, с первым типом сотрудников, когда вы как бы у вас есть инструкции, как себя вести, а, и в обычных ситуациях всё хорошо, а, вы делаете то, как нужно, да, но если ситуация становится внештатная, что-то идёт не так, вы не знаете, что делать, и вы спрашиваете у начальства. И, собственно, вот это первый тип сотрудника. И это очень похоже, как мы сейчас увидим с вами на workflow, когда мы должны, а, чётко, ну, на AI workflow, когда мы чётко детерминированно решаем какую-то задачу, а, последовательностью действий и LLM, а, всего лишь участвует как шаг вот в этом в этой последовательности, чтобы решить какой-то, ну, например, последовательности в бизнес-процессе написать письмо потенциальному клиенту. LLM занимается только шагом, допустим, три, где мы просим её составить текст, который мы должны отправить.

Но есть другой тип сотрудников. Сотрудники, которые скорее работают по следующему принципу: а, есть задача, есть у них, а, навыки, которые а у них есть, и инструменты, которые им доступны, и они сами решают без заранее прописанного последовательность действий. Они, а, сами решают в зависимости от задачи, какими инструментами воспользоваться, чтобы решить эту эту задачу. То есть они скорее не следуют жёсткой инструкции, а они, зная проблему или задачу, подбирают и составляют сами план решения этой проблемы, исходя из э доступных ей инструментов и, соответственно, исходя из своего понимания, как такие задачи и опыта, как такие задачи решаются. И вот это как раз и есть по сути agentic workflow, когда мы вместо того, чтобы заранее придумать и прописать в коде последовательность действий для выполнения задачи, мы передаём задачу планирования действий на сторону LLM. То есть LLM становится у нас некоторым менеджером процесса, менеджером, а, и планировщиком подхода, как решить ту или иную задачу, а, чтобы добиться той цели, которую перед нами, а, поставили, может быть, не всегда самым эффективным способом, но точно добиться её с точки зрения цели, которая есть, и исходя из инструментов, которые, а, нам доступны.

И вот как по вашему, какой из какой из этих двух типов сотрудников или, как мы уже понимаем, типов организации AI-систем. И мы сейчас посмотрим детально, какой из них лучше. А, конечно, зависит от задач, зависит от, во-первых, окружающей среды, да, что если окружающая среда не так, а, сильно меняется и вариабельность ввода, ну, инпута бизнес-процесс не так сильно меняется, то есть она более-менее стабильная, то, а, м, сотрудники, которые чётко выполняют по а по процессу, это, во-первых, более эффективные сотрудники, потому что они всегда сделают то, как в той последовательности, которые а надо. При этом, конечно же, вот как бы вы, наверное, перед тем, как мы посмотрим конкретный пример, как бы вы, наверное, посоветовали в чём, а, или предположили, в чём плюсы, а, или минусы каждого из типов сотрудников из того, что я а рассказал.

Или, ну, агентов, как мы сейчас посмотрим, да? Креативность. Да, у второго. Этот первый точно быстрее. А, во-первых, потому что а человек постоянно делает, делая одну и ту же задачу, он, ну, назовём это так, набивает руку, он более эффективно её реализуется. Вот Инара очень правильно говорит, что гораздо легче тестировать э первый тип, потому что если бизнес-процесс описан, то мы можем проверить, что все шаги бизнес-процесса были выполнены, а значит, ну, лучше протестировать и обеспечить качество или понять, где произошёл разрыв, а, в качестве и, соответственно, сфокусироваться на этом этапе бизнес-процесса. Да, вот Алексей очень правильно говорит, на самом деле иногда слишком креативный сотрудник или про или агент, как мы увидим, он а может выйти за рамки дозволенного, слэш он может быть, назовём этот, слишком умным. Вы увидите прямо сегодня кейс. Может быть слишком умным, что даёт непредвиденные обстоятельства и последствия, которые нам нужно, с которыми нам нужно иметь дело потом. Поэтому, конечно, базово какой-то бизнес-процесс лучше подходит для одних ситуаций, какой-то другой для других, какой-то сотрудник для одних кейсов, а какой-то для других.

И вот, собственно, с такой вводной, а, с тем, что у нас есть два типа сотрудников, которые эффективны в той или иной, а, в том или ином кейсе, мы давайте, а, и рассмотрим то, что у нас есть. Давайте перед перед тем я, а, как я, а, пойду дальше, вы попробуйте ещё для себя ответить на такой вопрос. Смотрите, в первом случае это там детерминированный workflow. Мы закодили набор действий, который нужно делать. И LLMку просто используем для интелидженс, ну, например, для понимания речи или для генерирования текста или речи на каком-то из этапов. Во втором случае мы используем, а, LLM как менеджер процесса, который, а, принимает решение, как и в какой последовательности обеспечить выполнение, а, задач и, соответственно, пользуется инструментами, которые у нас есть. Какой из этих э подходов максимально быстро эволюционирует, по вашему мнению? То есть он, а, скажем так, с, а, имеет возможность улучшаться вместе, допустим, с улучшением, а, технологий и улучшением, а, моделей в нашем, ну, в нашем мире. А мы видим, что там модели улучшаются в среднем. Скачок идёт каждые, наверное, два 2 с половиной месяца.

На самом деле второй гораздо более, вот если там взять метафору такого сёрфера, да, второй подход как раз вот как на волне технологического ну прогресса находится гораздо более, чем первый, потому что каждый раз, когда выходит новая модель, вы практически ничего не делаете, а весь ваш продукт становится, ну, или агент становится лучше, умнее. Конечно, ему нужны инструменты, и мы сейчас увидим, ему нужно инструкции от нас. Но а в целом а что а второй подход он гораздо более как бы а и шагает в ногу со временем, потому что при появлении новых, принципиально новых интеллектуальных возможностей у модели, вам не приходится переписывать вот этот, а бизнес-процесс, и вы, наоборот, вы пользуетесь тем, что модель стала лучше. И в этом, я считаю, один из плюсов. Но мы посмотрим плюсы-минусы ещё более подробно.

Но почему вообще второй а бизнес тип а реализации там LLM AI задач он а важен? Я попробую доказать этот пункт вот через примеры, которые у нас есть. Это потому, что детерминированный workflow, как с кейсом, с там самолётом, вышедшим за пределы посадочной полосы, взлёты посадочной полосы, это что мы, как дизайнеры систем, а, мы не можем обычно заранее предусмотреть всех возможных ситуаций, которые могут быть с тем workflow или бизнес-процессом, которые есть реально. Реальность гораздо сложнее и неоднозначнее, чем код, который мы заранее придумали и написали. Да, можно сказать, что, в принципе, ну, если мы не предусмотрели какого-то кейса в коде, это наши проблемы. А, то есть надо было лучше изучать реальность. Но жизнь показывает, что а очень сложно реальность описать во всём её разнообразии. И а мы делаем некоторую как бы некоторый срез реальности, когда планируем классические софтве продукты и описываем все всю бизнес-логику в коде. А мы отдаём, а ответственность за то, насколько наш продукт соответствует реальности тому, кто проектирует продукт. Мм, например, это продукт-менеджер или разработчик или ещё кто-то. Но а есть другой способ. А, и вот эта сложность реальности, которая существует, она ломает бизнес-процесс. Она, а, приводит к тому, что вот этот детерминированный бизнес-процесс, в нём появляются разрывы.

В чём обычно где вот эти элементы реальности, которые ломают первого первый тип сотрудника или первый тип реализации, а задач? А, ну как, во-первых, там, где участвует человек, например, если это user, то это обычно могут быть ошибки. Ну и мы делаем большую работу, связанную с тем, а, чтобы исправить, ну, предотвратить эти ошибки. Простая валидация инпута юзера — это, по сути, попытка охранять наш детерминированный workflow от того, чтобы в него не вошёл garbage, из-за которого он сломается. Поэтому, но, к сожалению, люди делают ошибки, пишут, взаимодействуют с нашим продуктом с мобильного телефона, там делают опечатки, вводят не то, вводят что-то, что мы даже не планировали, что они введут. И поэтому вот этот инпут, он, а, неверный или, ну, неожиданный, он может сломать наш детерминированный workflow.

Во-вторых, мы зачастую в продукте взаимодействуем для выполнения задачи с внешними системами, как мы сегодня посмотрим. И эти внешние системы могут не работать. На днях было, когда CloudF положил кучу сервисов, а, просто сервисы могут быть недоступны. У вас закончились кредиты на этом API провайдере, и кто-то не пополнил баланс, и из-за этого сломался весь workflow и так далее и тому подобное. Глобально, что когда мы заранее детерминируем workflow, вот эти аспекты могут сломать workflow полностью и из-за этого не работает. Хотя в принципе, допустим, мы могли бы позволить, что какой-то, например, этап бизнес-процесса не работал, но всё равно сделать recover. И поэтому нам приходится писать всякие ифы и трайкетчи, чтобы, а, защищаться от вот этих разрывов в бизнес-процессе.

Иногда данные, которые мы получаем от внешних систем, которые влияют на результат, который мы хотим получить, они могут быть неполные. И из-за этого мы проверяем на null, проверяем на non, проверяем на, а, ну, на полноту. И вот эти проверки иногда нам даются достаточно сложно, когда, допустим, ну вот возьмём простую задачу, задачу там определить, что компания из такой-то индустрии. Если, а, скажем так, вариабельность индустрий конечна, мы прописали какой-нибудь условный if или поиск в разных индустрий, э, проверку на вхождение и всё о'кей. Но если вдруг наш провайдер данных предложил, а, сделал новую индустрию или поменял UI и там сделал возможность юзеру кастомно вести свою индустрию, то у нас начинает ломаться весь бизнес-процесс. И вот эта неполнота данных, на которую мы или изменение данных, на которые мы опираемся, чтобы выполнить бизнес-процесс, оно может сломать весь наш а бизнес-процесс. Ну и особенно когда мы жонглируем разными данными, а, вы увидите, что многие агенты, так же как и люди, оперируют данными из разных источников для выполнения своей задачи, для а, даже для понимания, как правильно выполнить задачу. И данные в разных источниках происходят в разных форматах. Их надо каким-то образом комбинировать друг с другом. И мы пишем сейчас какие-то пайплайны, которые нам позволяют эти проблемы решать. Но в целом мой ключевой поинт, что реальность более сложна, чем тот детерминированный код, который мы написали. И поэтому, может быть, э ситуации, когда эта реальность, скажем так, даёт о себе знать и ломает наш бизнес-процесс, обычно мы это видим в виде новых ифов, новых бранчей, а, новых трайкетчев в нашем коде, коде исполнения той или иной задачи. Вот как раз для для таких кейсов, забегая вперёд, а, агенты и второй тип сотрудников, назовём это так, гораздо лучше подходят, чем а первый. Поэтому, да, традиционные обычно ломаются, а вот как раз agentic workflow, они позволяют этот вопрос решить.

Ну и последнее перед демонстрацией — это что вообще про вот эти workflow начали говорить в конце двадцать третьего, начале двадцать четвёртого года. Элично, ну, видел двух как бы ключевых, скажем так, идеологов а этой задачи. Это Эндрю Ин. Аа, может быть, кто-то из вас учился на его, а, курсах на deeplearning.AI, а, или, э, там, Стенфордский курс по машиннингу. И Карпаты, Андрей, они стали вот в конце двадцать третьего, начале двадцать четвёртого говорить примерно о следующем, что workflows, с которыми мы сегодня познакомимся, они дают возможность э гораздо лучше решать задачи, чем просто модели или LLMки, которые у у нас есть. Ну, например, Эндрю говорил в начале двадцать четвёртого, что надо смотреть и надо проектировать workflows для разных задач, потому что результаты по бенчмаркам, которые показываются благодаря агентским workflow, они убивают просто возможности, ну, обыгрывают возможности LLMок и моделей, а из коробки. А Карпаты говорил ещё в конце двадцать третьего, в начале двадцать четвёртого, что OpenAI, до того, как он ушёл из OpenAI, а, что OpenAI очень много смотрит на Genic Workflows. И вот с тех пор этот процесс пошёл, но мне кажется, в этом году мы прямо заметили вот этот огромный скачок.

И со своей командой, они сделали такой очень простой эксперимент. Они реализовали agentic workflow для кодинг задач, а, и сравнили две вещи. Это zero-shot, э, ответ, ну, решение какое-то, кодинг модель, поэтому здесь достаточно старые модели, а, в этом исследовании zero-shot ответ модели на решение какой-то задачи versus agentic ответ, ну, результат, который они получили по бенчмаркам. А, это и мы видим, что на самом деле агенты, реализованные на а модельки 3.5, они показывают результаты лучше, гораздо лучше, чем не просто модель такая же, но и модель следующего поколения. Вот тут, например, видно, что workflow, агентский workflow, реализованный там с помощью одного из паттернов, мы про паттерны будем на третьей встрече говорить, а, реализованный на GPT 3.5 лучше показывает результаты полтора раза, а, по бенчмарку, чем, а, э, эти же результаты на следующем поколении а моделей тоже в режиме Zero, то есть реализовав workflow, мы можем, грубо говоря, превзойти способности модели, которые даются нам из коробки. И именно поэтому весь разговор у нас.

Давайте от теории сначала в очень простом демо я покажу, ну, как это на практике там на одном из микрокейсов реализуется, а потом а мы перейдём к лайфкодингу и там, собственно, в коде, как это делать. А покажу в режиме одного из продуктов, который позволяет делать no-code бизнес-процессы. Может быть, кто-то из вас знает Nat. А, и покажу как раз вот эту разницу между двумя workflow на простом, а, как бы, no-code примере, а потом мы уже в коде, как это делать более детально уже в нормальном Python и иже с ними.

Давайте возьмём простую задачку, а, которую вот мы в компании решаем, и, возможно, у вас будет задача похожая. У нас есть LinkedIn профиль человека. Собственно, наш сотрудник вводит этот LinkedIn профиль. Это как раз будет шаг номер один. А, он сабмитит формочку с полем LinkedIn профиля. Мы а есть API провайдер, который, ну, предоставляет данные по URL, LinkedIn URL человека. Предоставляет данные о его профиле. То есть мы скачиваем профиль человека. И третий процесс, третий шаг в бизнес-процессе — это мы обращаемся к LLMке и просим её по заданному профилю сгенерировать персонализированное сообщение, которое мы можем написать этому человеку. Вот три шага этого бизнес-процесса. Я не буду сейчас там вдаваться в подробности реализации на N, потому что там мы это в коде сделаем гораздо более эффективно. Но а именно в качестве иллюстрации смотрите на это. Ну, допустим, вот у нас есть некоторый процесс. Запустим его. Вот он хочет от меня адрес LinkedIn человека. Допустим, я введу свой, а, мы засабмитили, видим, ну, что аутпутом этого бизнес-процесса как раз стал, а, адрес, который я ввёл. Ну, и дополнительные действия. Исполняем второй шаг. Второй — это get запрос к провайдеру данных, который, собственно, по LinkedIn адресу даёт нам а профиль человека. Вот я исполнил. Видим, что а я отправил get-запросом по вот этому поинту, а, в этом параметре, собственно, этот адрес и получил, как вы видите, полноценный профиль мой из LinkedIn. Ну, и, собственно, третий шаг в этом бизнес-процессе — это вызов, а, LLMки. А, мы здесь даём промт: "Твоя задача — написать сообщение". Даём набор, а, информации про него и как раз засовываем в LLMку, подаём ей в контекст информацию из вот этого как раз профиля. Ну, и она сгенерировала нам а текст, который мы хотели. Всё супер, всё работает, всё прошло так, как нам надо.

Но если вдруг мы сделаем хоть одну ошибку, ну, например, я уберу последнюю букву, а, в своём инпуте, то, как вы, наверное, а, догадались, первый шаг, конечно же, у нас исполнится, но на втором шаге произойдёт разрыв, потому что, как мы видим, а, провайдер данных ответил 404, а, и по сути сказал, что такого профиля нет, потому что ошибка в вводе. И мы даже не можем исполнить третий шаг, потому что у нас не сработал второй шаг в этом бизнес-процессе. И здесь мы бы писали, а, try-catch, мы бы, может быть, сделали retry какой-то, но в любом случае мы не получили а результата. Бизнес-процесс сломался. Давайте посмотрим.

А второй, а, когда мы на самом деле реализуем эту же задачу, но в агентском workflow, а, э, опять не вдаваясь в особенности реализации, а, я просто скажу, что мы напишем системный промт, очень похожий на тот системный промт, который у нас есть здесь. Но мы скажем ещё, что если вдруг юзер сделал какую-то ошибку, то ты сама попробуй а себя исправить. Попробуй догадаться, где могла быть ошибка во вводе, если вдруг нам поставщик данных ответил, что такого профиля не существует. Ты, собственно, попробуй, а, откорректировать ситуацию и всё-таки добиться того результата, который есть. И то есть мы даём некоторые длинные, если вы видели утекшие системные промты чат GPT, клодкода, курсора, то вы, наверное, если почитаете их, то вы увидите, что там очень много как раз

описания вот таких, а, ну, скажем так, workflows. Пока приходится нам писать это в инструкции. Я думаю, в какой-то момент это даже будет из коробки.

А длинное описание о том, как себя вести в тех или иных ситуациях. И в качестве менеджера или оркестратора этого агента мы подключаем модельку. То есть не просто выполняем её, а для того, чтобы на вход подать текст, получить текст, а используем её как менеджера всего бизнес-процесса.

А, и, соответственно, если мы подадим вот этот сломанный инпут, то смотрите, что происходит. Она, ну, пользуется лмкой. Она дёргает эту опишку, а, пытается получить профиль. Не получается, она дёргает ещё раз. Не получается, она думает и потом дёргает ещё раз. Ээ, и когда это получится, она выдаёт нам результат, который мы попросили.

Причём, если мы посмотрим логи, то смотрите, что происходило. А сначала она попробовала обратиться к вот этому API провайдеру адресом, который получила в инпутемалась. Да, она получила 404. Она подумала про этот бизнес-процесс и что произошло, и она попробовала из-за того, что есть в инструкциях вот части про селф-коррекцию, она попробовала уже вызвать этот л с другим параметром. И смотрите, она добавила эту букву, она там подумала, догадалась, потому что в её, а, базе знаний было когда-то что-то про Байра Монаков, ну, LinkedIn какой у меня. И поэтому она попробовала дописать последнюю букву, ей удалось, и она, соответственно, получила ответ и в итоге выполнила ту задачу, которую мы сказали.

Вот знаете, у меня был сеть. Очень часто бывает так, что документация не соответствует реальности. Ну там, ну она out of date, какие-то параметры не так работают, как надо. Это мне что нравилось в нём, он не останавливался на пункте документация не соответствует реальности. Он начинал просто перебирать параметры, а или там энпоинты у которые вызывает, предполагая, где могла бы быть ошибка или как обычно, а, ну, эти энпоинты называются, как они обычно работают, как могут называться те параметры. И он иногда вскрывал возможности API, которые недоступны, не были в с точки зрения документации даже описаны просто потому, что документация отставала от реальности.

И вот это примерно а такая же история, что вы используете вот это всё знание, которое есть в тренинге, ну, было в трейнинге лмки, чтобы recoverриться и селф-корректить ситуацию, как, например, а, проблема с недописной бунковой. И заметьте, что я ему не писал, что попробуй добавить последнюю букву. Я не писал какую, потому что если бы я написал, с Байрамом бы это сработало, а с другим нет. Я просто ему сказал, что do your best, чтобы реконструировать, а правильный адрес, если а ты не смог получить профиль.

И попробуйте даже на секундочку просто подумать. Если бы я был продукт-менеджер, а, и вас попросил реализовать этот selfcrection, как бы вы его реализовали в детерминированном виде? То есть как бы вы вообще написали эти ифы, чтобы достигнуть этой задачи? И вот в этом, мне кажется, огромная вот power, но и проблема, как Анна написал. Да, конечно. Во-первых, там иногда они остановятся, когда токен закончатся, но глобально а суть в том, что workflows - это как раз про это. Давайтеж полный, ну, всю, все знания, которые есть LLM, чтобы, а, регулировать бизнес-процесс и выполнение команд кода на выполнение какой-то операции и отдать интерпретацию результатов в этих шагах, а, на сторону LLM и из него, соответственно, а, обеспечить выполнение той цели.

Возвращаемся к метафоре двух сотрудников, которые, которая у нас стоит. То есть здесь сотрудник из-за неверного ввода сломался и не выполнил задачу, то есть пришёл к начальнику и говорит: "Ну ты мне дал неправильный линк". А здесь он решил в итоге конечную задачу. И в этом как раз разница этих двух бизнес-процессов, что действительно а нету однозначно, что это серебряная пуля, что детерминированный workкфлоу - это плохо, давайте всё делать на adentic workкфлове наоборот. Вы заметите и вы увидите, что надо подбирать э ну тул к задачи, как же как и агент наш делает. И на самом деле плюсы одного минус являются минусами другого и наоборот.

Давайте посмотрим. Ну, как вы уже говорили, это быстро и дёшево. Это предсказуемые результаты. Не будет придумывать э случайно чужое имя и скачать профиль по нему. Очень легко аудировать или дебажить такой бизнес-процесс. вы залезли в тот степ, который у вас сломался, и написали if или trй catch, допустим, если а там был разрыв, но а ломается на эксепшенах, нету вот этой а селф-коррекции. А агенты же, ну, по сути, в обратную сторону. Он лучше справляется вот с таким непредвиденным вводом. Он само корректируется. Он самое главное и самое важное, он выполняет задачу. Он выполняет ту цель, которую мы хотим. А, собственно, но а при этом он гораздо дороже, а, и медленней. Иногда, вот, как я сказал, а, бывает, что слишком умный. Ну, и тяжелее аудировать, как вы уже говорили. И, э, поэтому действительно нету, однозначно нельзя сказать, что что-то лучше, что-то нет.

Просто этот и хороший поинт вот про трайкч у Ина, что, ну, мы перенесли if или trйк catch в проomт и да, и нет. А просто подумайте и можете потом написать, как бы вы написали в коде вот эту селф коррекцию, которую я показал. Это первое. А второе, как бы вы, насколько легко было бы subject domain эксперту, то есть это продукт-менеджер или usер, а бы понять что вы написали. Вот из-за этого, на самом деле, во-первых, я там забегая вперёд, скажу, что без ОМ вы бы селфкоррекцию нормально не реализовали, и вы бы всё равно просто на этом шаге, на втором бы написали бы какое-то обращение к М с попыткой селф-коррекции. А второе, конечно, что, ну, subject domain эксперту было бы очень сложно понять, но попробуйте, вы почувствуете вот эту разницу.

Но ещё раз, я не адвокацирую за какой-то кейс. Я просто забегая вперёд, приведу один пример, когда второй, э, э, как бы подход гораздо более, э, эффективен с точки зрения именно выполнения целей, да, не с точки зрения цены и скорости. Это когда вам нужно реализовать, когда ваш агент взаимодействует с очень вариабельной и непредсказуемой внешней средой. Ну, например, на вот на второй встрече мы как раз будем писать реarch агента. И речер он взаимодействует с открытым интернетом, да? То есть он делает запросы, понимает, какие придумывает, какие запросы сделать, делает эти запросы, интерпретирует результаты. В результатах находят, э, по результатам принимает решение, чтобы делать ещё запросы. И вот этот как бы небольшой такой рекурсивный процесс сдой, которая очень вариабельна с точки зрения инпутаных. А вот для таких задач агентский подход гораздо более а powerful.

Второе, а я бы сказал, это ещё раз в ДЗ у вас прямо такой вопрос будет. Сказать, какие workflows в вашем, а, бизнесе или в компании, в которой вы работаете, а, более подходят и менее подходят, исходя из понимания. Но а там будет такая ситуация, что а если вдруг получается так, что у вас какой-то workflow - это куча ифов, куча трайкчей, когда вы реализуете этот workflow, то это классный индикатор, признак, что возможно, и вам часто приходится эту бизнес-логику дописывать на основе фидбек ка от юзеров. А я очень с высокой вероятностью говорю, что агентский workflow будет гораздо более эффективен, чем вот этот очень сложный а бранчинг. Э, вот как раз про это, ну, небольшой roll of TP, что если в каком-то бизнес-процессе вы постоянно добавляете ифы и такая ветвящаяся бизнес-логика, а, получается, и постоянно приходится её апдейтить, это прямо классный индикатор, что, возможно, агентский workflow будет гораздо более эффективней.

Итак, давайте перейдём к лайфкодингу. И я покажу вам, собственно, а два, а два кейса, как как раз, которые есть. Это вот как раз детерминированный chain workflow. Итак, это так называемый наш сотрудник, а, первого типа script follower, напомню, вот этот слева. Он у него конкретные действия. И тут мы не используем никакого фреймворка, кроме SDК, который есть у антропика, чтобы дёргать антропик. А, собственно, вы видите, здесь я делаю собственно получаю ключики. А и основное происходит у нас здесь. А, собственно, сначала я, ну, вызываю вот этот get, делаю этот getре request к enри layerру и передаю, который мы получили, а, и, соответственно, жду статус код 200 и ответ Jсоном возвращаю к сюда. Дальше я вытаскиваю из этих данных, из этого ответа нужные мне данные там в промте, а мне нужно его имя, мне нужно, где он сейчас работает, и описание. Ну, понятно, могу. А ещё что-то. И у меня там есть инструкция, что если че из тех индустрии человек, то чтобы результат был рэпом. Вот. То есть в форме рэпа, е, помните, вот здесь, э, если я не знаю, если вы обратили здесь, э, внимание или нет, то видите, он здесь, ну, типа, рэпом написал outach месдж. А это как раз из того, что есть в прямомте пункт про если индустрия тех, то типа делай рэп. А, ну и тут видно очень простое детерминированное определение, что такое индустрия тех. Конечно же, здесь можно было бы как раз дёргать лмку какую-нибудь и проверять, ну, просить её сказать, эта компания является техкомпанией или нет. И, собственно, третий - это простой запрос к лнке с заданным промтом, да? То есть вот здесь мы видим, что мы вызываем как 4, по с промтом. И как раз часть про она вот здесь определяется, если вы вспомните, там, собственно, у нас как раз про это и была, а вот этот флажок как раз тех, которые мы а распределяем. Ну вот очень простой, чёткий бизнес-процесс. Три шага, как я вам показывал в NITN.

И давайте ну, во-первых, там посмотрите в, э, в сетапе или в RIDMI сделайте VF а вот инструкции, если вдруг не знаете, как делать. Ну, не обязательно VN в любую, как бымент виртуальный, с которым вы привыкли, а, работать. Ну вот там, если вдруг нету предпочтений, то как раз VNF, а у меня он уже активирован. А, собственно, а давайте, а, исполним этот бизнес-процесс, э, и, э, посмотрим, а, что у нас получится там просто забегая вперёд, там как бы сначала пробуется, когда всё хорошо, то есть когда а данные подались верно, а потом а, собственно, э делается, ну, без процесс, когда ну есть, скажем, скажем так, проблемы. А, и мы, собственно, здесь видим, когда мы подали верный, то всё хорошо, месседж сгенерировался. Вот мы видим этот месседж. Когда же мы допустили ошибку, ну вот видите, тире добавили, а здесь как бы нету этого тире, ну не должно быть тире, а у нас всё сломалось, как мы с вами и видели в этом. Тут никакого никаких фреймворков, а всё оченьствен, вытаскиваем данные, а вызываем лмку. Всё суперст, чтобы вы понимали, тесткейсы прописаны, э, ну, вот в отдельном, а, файлеce вот здесь хорошие и плохие. И, собственно, поэтому вы можете поправить, если а вдруг вам надо. И поэтому в мейне у нас импортируются, собственно, тесткейсы и прогоняются как раз, а, с workflow эта пара, а, правильный и неправильный. Мы увидели chain outreich. Там ещё раз, ничего сложного.