Transcription
В основе своей, создание агентов ИИ довольно просто, когда у вас есть большая языковая модель (LLM), которую вы хотите подключить к паре инструментов, особенно с помощью инструментов без кода, таких как N8N и помощники по кодированию ИИ. Но когда вы действительно хотите начать решать более сложные задачи и создавать по-настоящему надежных агентов ИИ, это становится намного сложнее. И меня постоянно спрашивают: как определить, какой агент ИИ нужно построить для той или иной задачи и какие компоненты в него включить? И именно этим я хочу поделиться с вами прямо сейчас. Я хочу погрузиться в свою мощную ментальную модель для построения агентов. Потому что, по сути, за эти годы я создал для себя структуру для решения любой сложной проблемы, связанной с агентами ИИ, и разбиения её на небольшие части, чтобы упростить процесс построения. Позвольте мне показать вам, что я имею в виду. Очевидно, вы видите, что у меня много чего для вас припасено. Я ничего не скрываю, делясь с вами своей полной ментальной моделью. И мы используем визуальность N8N, чтобы сделать это очень легко отслеживаемым, и у меня есть много легко усваиваемых примеров. Поэтому я хочу сделать это максимально простым, охватывая концепции, которые вы можете комбинировать, чтобы создавать более продвинутых агентов ИИ. Итак, ментальную модель, которой я собираюсь с вами поделиться, я называю «чертежом из семи узлов» для агентов ИИ. Потому что любой агент ИИ, о создании которого вы только можете мечтать, может быть разбит на компоненты, которые будут попадать в одну из семи категорий. И на этих семи категориях я хочу сосредоточиться здесь. Потому что, действительно, любая проблема в жизни может быть упрощена, если разбить её на более мелкие компоненты. И именно это даёт нам этот чертёж. Это руководство для построения агентов ИИ. Итак, мы погрузимся в эти семь разных узлов. Но первое, что я хочу обсудить с вами, это основной принцип, который направляет весь этот процесс. Причина, по которой я называю это узлами, «чертёж из семи узлов», заключается именно в этом. Это очень важно понимать, что агенты под капотом — это на самом деле просто графы. Ну хорошо, Коул. Но почему это важно? Что это вообще значит? Ну, позвольте мне потратить пару минут и объяснить вам это, потому что это действительно основа нашей ментальной модели. И я начну здесь с диаграммы из документации LangChain, которая описывает, что такое агент ИИ на высоком уровне. Итак, у нас есть входные данные от пользователя. Они поступают в LLM, которая может выполнять действия от нашего имени с помощью инструментов. А затем мы получаем окончательный вывод после завершения работы агента. И если вы внимательно посмотрите на эту диаграмму, вы увидите, что это действительно граф. У нас есть этот цикл. И это относится к любому агенту ИИ, который вы можете создать, где у вас есть этот цикл LLM, решающей использовать инструмент, получать обратную связь и рассуждать о том, что произошло, когда она использовала этот инструмент, а затем она может вызывать больше инструментов. Этот цикл может повторяться любое количество раз, просто в зависимости от рассуждений LLM. И это очень отличается от традиционных автоматизаций и рабочих процессов, где мы следуем гораздо более линейному и детерминированному пути. У нас всегда есть какой-то вход, который обрабатывается определённым образом каждый раз, а затем у нас есть выход в конце. Но с агентами у нас теперь есть эти циклы рассуждений с использованием инструментов, и у нас могут быть агенты, которые работают друг с другом, и мы не обязательно знаем, будет ли один агент использовать этот инструмент или обращаться к этому агенту для одного выполнения. У нас есть это недетерминистическое поведение, которое обеспечивается циклами, которые у нас есть в графе. И поэтому агенты можно рассматривать как графы. И причина, по которой это так мощно для нас, заключается в том, что когда у нас есть эти разные циклы и эти разные узлы в графе, это позволяет нам рассуждать о том, как разбить агента на меньшие компоненты. И именно в это мы и погрузимся в этом видео — это изучение более сложных агентов ИИ, различных частей, которые входят в него, как мы можем сосредоточиться только на подсекциях графа и разработать их. И также вы можете рассматривать эти графы как просто набор кубиков Lego, которые собраны вместе. Например, у вас есть ограничитель для вашего агента. Мы дойдём до этого. У вас есть ваши инструменты. У вас есть ваши резервные варианты. И вы можете создавать каждый из них индивидуально, комбинировать всё это вместе, чтобы создать по-настоящему надежного агента ИИ. И именно это мы будем делать вместе с нашей структурой. Итак, вот пример агента ИИ, который использует все семь узлов в своем процессе. И это должно выглядеть немного пугающе для вас. В этом суть того, к чему я стремлюсь, — у нас есть эти более надежные агенты, которые могут показаться сложными для понимания. Мы можем разбить их на более мелкие компоненты. И поэтому я буду проводить вас через каждый из этих компонентов, таких как долговременная память, наши резервные варианты и наши ограничители, сосредотачиваясь на них по отдельности. Затем мы вернёмся к этому примеру. Посмотрим, как они все объединяются, чтобы создать этого более надежного агента ИИ. И для каждого из примеров, включая этот, я даже создал диаграмму, чтобы вы действительно могли видеть, что происходит под капотом, на ещё более простом уровне, чем сам рабочий процесс N8N. Итак, то, что вы видите здесь, это по существу то, что у нас есть на этой диаграмме. И здесь много компонентов, но именно поэтому мы будем рассматривать каждый из них по одному. Теперь давайте углубимся в каждый из семи узлов. Затем я также покажу вам пример для всех из них. Итак, первый узел, который у нас есть, — это наш узел LLM. Это мозг агента, который отвечает за все рассуждения и принятие решений. Итак, когда вы взаимодействуете с GPT 4.1 или Gemini 2.5 Pro или Claude 3.7 sonnet, всеми этими LLM, с которыми вы знакомы, они все работают в узле LLM нашего агентированного рабочего процесса. И затем, когда они хотят действовать от нашего имени, именно тогда они используют узел инструмента. Итак, это наш узел, который выполняет веб-поиск, выполнение кода, запросы к базе данных, и решения, принятые LLM, будут вызывать эти узлы инструментов, когда они захотят выполнить действия для нас. А затем третий тип узла — это управляющий узел. И они очень мощные, потому что агенты ИИ довольно непредсказуемы, потому что мы даём им способность рассуждать, чтобы решить, что они хотят сделать. И поэтому управляющие узлы добавляют немного детерминированного поведения в наши агентивные рабочие процессы, потому что вместо того, чтобы использовать агента для выполнения логики здесь, мы просто используем обычные рабочие процессы или код. Таким образом, у нас есть немного более детерминированного поведения, встроенного в наш поток. Итак, это будет обрабатывать такие вещи, как фильтры, условия, маршрутизацию. Итак, если у нас есть вывод от агента, который будет диктовать, по какому пути мы пойдём в графе, управляющий узел будет обрабатывать это. Он будет маршрутизировать на основе того, что выдал агент ИИ, и он будет делать это детерминированным способом. И затем у нас есть узел памяти. Это и для долговременной памяти, и для краткосрочной памяти. Итак, у нас есть векторные базы данных для долговременной памяти, история разговоров для краткосрочной памяти. Как правило, то, что у вас будет в ваших агентивных рабочих процессах, где вы хотите реализовать это, — это узел в начале и в конце для управления долговременной памятью вашего агента по мере того, как он общается с вашими пользователями или вами самими. И затем у нас есть узлы ограничителя, и они имеют решающее значение для того, чтобы сделать наших агентов ИИ намного более надежными. У вас есть как входные ограничители, так и выходные ограничители. Итак, прежде чем вы используете LLM, подключённую к куче инструментов, вы можете захотеть проверить входные данные пользователя или проверить вывод агента на соответствие некоторым определённым вами правилам. И вы можете использовать LLM в качестве этих ограничителей. Вы можете использовать детерминированный код. Мы немного подробнее поговорим об этом позже, но ограничители очень важны для того, чтобы убедиться, что мы фильтруем плохие выводы, что мы проверяем формат ввода и вывода. Очень важно просто убедиться, что наши агенты ИИ не выходят из-под контроля и не галлюцинируют что-то, что приведёт к полному сбою всего агента. И затем у нас есть узлы резервного варианта. Итак, когда что-то идёт не так с нашим агентом ИИ, вместо того, чтобы просто игнорировать ошибку или аварийно завершать работу приложения, в большинстве случаев мы хотим сделать что-то конкретное, например, заставить нашего агента ИИ повторить попытку выполнить то, что он делал, или создать ответ по умолчанию для пользователя, сообщив ему, что произошла ошибка и как он может повторить попытку. Что бы это ни было, мы просто хотим убедиться, что мы изящно обрабатываем ошибки в наших агентивных рабочих процессах. А затем последний тип узла — это узел ввода пользователя. Итак, часто даже в середине работы агента мы хотим получить какую-то обратную связь от пользователя или подтверждение того, что он хочет продолжить с использованием того или иного инструмента, который решил использовать агент. Итак, например, прежде чем мы действительно используем агента для бронирования отеля через Airbnb, может быть, мы хотим отправить эти данные человеку и подтвердить, например: «Вы действительно хотите это сделать? Вам это нравится?» Итак, этот вид прерывания, который у нас есть, называется «человек в цикле», если это прерывание, которое у нас есть в нашем агентивном рабочем процессе, ожидая ввода от человека, прежде чем мы продолжим, и я также покажу вам, как это выглядит. Итак, это все семь узлов, и мы погрузимся в пример для каждого из них, а затем в конце я вернусь к этому более сложному примеру, объединив всё вместе, чтобы вы очень ясно увидели, как мы можем начать с простого, построить, как с кубиками Lego, как я говорил ранее, что-то более надежное.
Итак, этот первый пример должен показаться вам очень знакомым, потому что этот граф, который у нас есть, который представляет этот рабочий процесс NAN, выглядит точно так же, как диаграмма, которую мы видели ранее. У нас есть входные данные, которые поступают в цикл LLM и инструмента, а затем у нас есть выходные данные в конце. И это основа построения любого агента ИИ. Итак, если вы раньше создавали агентов в N8N, это должно показаться вам очень знакомым и простым. И мы отбрасываем первые три из семи узлов с помощью этого единственного рабочего процесса, потому что у нас есть LLM, у нас есть память, по крайней мере, краткосрочная память в этом случае, и затем у нас есть один инструмент, который мы предоставляем нашему агенту. В частности, этот инструмент позволяет ему создавать записи в нашей таблице AirTable, которая у нас есть прямо здесь, где мы просто перечислим множество блюд, которые у нас есть. Итак, я могу вернуться к своему агенту. Теперь я могу попросить его приготовить два новых блюда. И поскольку мы просим его приготовить два блюда, он будет вызывать этот цикл два раза. Итак, мы видим это прямо здесь, что мы использовали наш инструмент air table два разных раза. И теперь у нас есть два новых блюда. По какой-то причине GPT 4.1 Mini просто обожает острое манго. Он много раз повторяет это даже из моих более ранних тестов, что довольно забавно. Но в любом случае, мы приготовили два новых блюда, пять и шесть, и мы дважды использовали этот инструмент, чтобы добиться этого. На самом деле мы дважды использовали каждый из этих узлов. Итак, у нас определённо было много циклов, происходящих здесь в этом графе, управляющем нашими инструментами и памятью.
В последнем примере я показал вам узел памяти с краткосрочной памятью, но обычно, когда я думаю об узлах памяти, это больше для долговременной памяти. Поэтому я хотел привести вам этот пример здесь. Итак, в этом графе, прежде чем входные данные напрямую поступают в LLM, мы фактически добавляем этот шаг извлечения памяти. И в более надежной реализации памяти вы обычно будете иметь это как векторную базу данных. Вы будете извлекать соответствующие воспоминания, чтобы затем подать их в запрос для LLM. А затем у нас есть шаг в конце выполнения графа, чтобы также извлечь соответствующие воспоминания из нашего текущего разговора и сохранить их в конце. И поэтому обычно вы захотите реализовать что-то вроде библиотеки mem zero для долговременной памяти. И вы можете видеть с их функцией добавления, когда вы добавляете воспоминания в векторную базу данных, она сама по себе является графом, что ещё раз доказывает мою точку зрения, что агенты — это просто графы под капотом. Но в любом случае, поэтому вам обычно понадобится более надежная реализация, подобная этой. Для простого примера здесь я просто использую Google Docs для управления всеми нашими долговременными воспоминаниями. Итак, я могу сказать что-то вроде: «Я ненавижу острое манго». Это будет передано в LLM. Он извлечёт эту память. Вот здесь он извлекает память. Пользователь не любит острое манго. Мы делаем это с помощью LLM, которая запускается после нашего основного агента. А затем он сохранит это в нашем документе Google. Итак, конечно, наш документ Google теперь содержит информацию о том, что пользователь не любит острое манго. Итак, теперь я обновлю разговор. Итак, мы не используем краткосрочную память. Это использование долговременной памяти. Я скажу: «Приготовьте мне блюдо на основе того, что я не ненавижу». Просто какой-то действительно глупый пример здесь. Итак, он будет извлекать воспоминания, которые у нас есть из нашего документа Google. Он будет подавать это как часть запроса к LLM. Итак, вот здесь мы добавляем долговременную память, а затем он создаст для нас блюдо. Поскольку вы не любите острое манго, вот ещё одно блюдо, и он даёт нам сладкий куриный салат с манго. Итак, он всё ещё остался с манго, но, по крайней мере, он не острый. Это на самом деле смешно. Но да, вы видите, что он использовал долговременную память. Как правило, мы бы делали что-то вроде хранения воспоминаний в векторной базе данных, а не просто в Google Docs. Но это просто даёт нам очень наглядный пример здесь.
Спонсором сегодняшнего видео является Bright Data и их очень впечатляющий сервер MCP. Это ваше универсальное решение для предоставления вашим агентам ИИ разблокированного доступа к Интернету в режиме реального времени. И это гораздо больше, чем просто веб-поиск. Это даёт вашим агентам возможность использовать Интернет так же, как человек. У них есть целый набор услуг, чтобы убедиться, что вы можете обрабатывать любой тип веб-страницы, автоматически решать CAPTCHA, обрабатывать сложный JavaScript, не блокироваться на сайтах. У них есть всё. И у них даже есть специальные веб-скрейперы, которые созданы для вас, чтобы использовать их прямо из коробки практически для любой платформы, о которой вы только можете мечтать. А звездой шоу, которую я хочу вам показать здесь, является их сервер MCP. Вы можете взять все их скрейперы, прокси и другие сервисы и интегрировать их прямо в ваших агентов ИИ. Итак, в моём случае я использую Pantic AI, мою любимую структуру агентов, чтобы подключить моего агента всего несколькими строками кода к серверу Bright Data MCP. Итак, с помощью этого скрипта, всего менее 100 строк кода, у меня теперь есть агент ИИ, который может использовать Интернет практически любым мыслимым способом. Итак, например, я могу попросить его получить для меня биографии Amazon и OpenAI из LinkedIn. И он будет разумно использовать специальный скрейпер LinkedIn в качестве одного из инструментов, которые предоставляет мне сервер Bright Data MCP. И посмотрите на это. Вот биографии Amazon и OpenAI. Я могу подтвердить, я проверил это вне камеры, это действительно правильные биографии. Это выглядит так хорошо. Это молниеносно. И я могу даже спросить его о чём-то ещё, например: «Покажите мне рейсы из Миннеаполиса в Сан-Франциско сегодня». И он найдёт для меня лучшие рейсы и порекомендует их здесь. Посмотрите на это. Хорошо. Дал мне четыре варианта. Это выглядит так хорошо. И это просто удивительно, как он может разумно выбирать правильный инструмент для использования, так что в основном, независимо от того, что я хочу получить в Интернете. Bright Data может это сделать для меня. Мне это просто нравится. Итак, я оставлю ссылку ниже на Bright Data и их сервер MCP, у них есть бесплатные кредиты, чтобы вы начали. Поэтому обязательно загляните, получите такие возможности в своих собственных агентах ИИ. Это просто так мощно.
Далее у нас есть узлы ввода пользователя и управления. И эти два разных типа узлов часто идут вместе, поэтому я хотел привести вам этот пример. Хотя они не обязательно должны использоваться вместе всё время. Но в этом случае мы добавляем человека в цикл. Итак, у нашего агента есть этот инструмент для отправки сообщения в Slack. Но прежде чем мы действительно продолжим и отправим это сообщение, мы получим одобрение человека. Итак, мы увидим это немного позже. Но когда мы получим запрос на утверждение, он поступит в наши личные сообщения здесь, в Slack. А затем, когда мы утвердим сообщение, оно будет отправлено здесь, в этом канале исследований, с сообщением: «Вот утверждённое сообщение». А затем, просто для демонстрации, если мы отклоним сообщение, например, мы его не утвердим, оно всё равно будет отправлено в Slack, но оно просто скажет, что это было отклоненное сообщение. Итак, возвращаясь к рабочему процессу здесь, путь его работы заключается в том, что у нас есть человек в цикле, который затем подключён к нашему управляющему узлу. Итак, это детерминированная логика маршрутизации. Как я упоминал ранее, управляющие узлы отлично подходят для маршрутизации, потому что мы хотим, чтобы одно и то же происходило каждый раз, когда мы утверждаем сообщение или отклоняем его. Итак, это то, что мы делаем здесь. У нас нет этого агента, который рассуждает о том, что делать на основе утверждения. Это тот же детерминированный код, который будет выполняться каждый раз. Итак, давайте сделаем что-нибудь. Я скажу: «Сделайте новое блюдо и отправьте его в Slack». Итак, теперь он будет использовать этот инструмент вспомогательного рабочего процесса. Но мы увидим через секунду, что он станет фиолетовым, потому что теперь он ждёт нашего одобрения. Это наш сигнал в N8N, что он ждёт, пока мы что-то сделаем, прежде чем он продолжит работу с остальной частью этого рабочего процесса. Итак, я зайду в Slack, войду в свои личные сообщения, и вот оно. Он представляет новое блюдо: цитрусовый жареный цыплёнок с манго и авокадо. Итак, у него всё ещё есть манго в рецепте. Мне это нравится. Хорошо, итак, я собираюсь одобрить это здесь. Мы получаем это всплывающее окно от N8N, сообщая нам, что рабочий процесс завершён. Мы видим это здесь. Теперь всё зелёное в N8N. И затем, если я вернусь в канал исследований, вот оно. Вот утверждённое сообщение. И мы получили наше новое блюдо. Выглядит хорошо. Итак, в этом случае управляющий узел прошёл по этому верхнему пути в нашем графе. Отправляя это сообщение, говоря, что оно было утверждено. А затем я могу просто перезапустить разговор. Отправить то же сообщение сюда. Мы можем посмотреть, что произойдёт, когда мы пойдём по нижнему пути. Итак, он снова попросит нашего одобрения. На этот раз он снова сделал острое манго. Я не знаю, почему он продолжает это делать. Здесь буквально нет истории разговора. Он не знает, что уже делал это много раз. Поэтому я не знаю, почему он продолжает это повторять снова и снова. Но на этот раз я скажу нет. Ты уже сделал это. Я сейчас откажусь. Хорошо. Действие записано, а затем в канал исследований. Вот отклоненное сообщение, потому что я не хочу острое манго в сотый раз. Я понятия не имею, почему 4.1 Mini продолжает это делать. Но да, вот и всё. У нас есть человек в цикле с управляющими узлами вместе, что делает это всё возможным для нас, чтобы утверждать вещи, которые часто могут быть рискованными. Например, если у вас есть агент, который бронирует отель или отправляет электронное письмо вашему боссу, часто он может галлюцинировать таким образом, что вы захотите отклонить и заставить его повторить попытку, что бы это ни было. Мы просто хотим добавить себя в смесь, чтобы убедиться, что у нас есть что-то сказать в том, что делает агент.
Теперь у нас есть очень важные узлы ограничителя. И это то, как вы можете сделать своих агентов более надёжными, проверяя входные и выходные данные вашего агентивного рабочего процесса. Итак, у нас есть как входные ограничители, так и выходные ограничители. Итак, этот граф немного отличается от того, что мы фактически реализовали здесь, потому что у меня есть только выходной ограничитель, чтобы упростить это. Но я хотел показать оба, и я очень быстро приведу пример обоих, а затем мы углубимся в этот пример. Итак, для входного ограничителя, допустим, вы создаёте помощника по планированию поездок. Вы предоставляете агенту свой бюджет, куда вы хотите поехать, на какой срок, и он составит для вас маршрут. В качестве хорошего входного ограничителя вы можете захотеть иметь LLM, которая быстро оценит, является ли бюджет действительно разумным для поездки. А затем, если это не так, у вас будет какой-то резервный вариант, где вы скажете пользователю: «Эй, ваш бюджет неразумен. Вам нужно его скорректировать, прежде чем вы действительно начнёте взаимодействовать с помощником по планированию поездок». Это был бы действительно хороший входной ограничитель, потому что если вы заставите агента попытаться создать маршрут, а бюджет просто смехотворно низкий, то он будет сильно галлюцинировать. Такой входной ограничитель просто предотвращает даже потенциальное возникновение этого с нашим помощником по планированию поездок. А затем в качестве хорошего выходного ограничителя вы можете захотеть убедиться, что маршрут, который создал агент, действительно соответствует количеству дней, на которое пользователь сказал, что он хочет поехать в свою поездку. Поэтому просто очень простая вещь, просто анализ вывода, убеждаясь, что дни совпадают, а затем, если это не так, у вас будет какой-то резервный вариант. В противном случае вы просто выведете окончательный маршрут пользователю. Итак, хорошие примеры входных и выходных ограничителей. В нашем случае мы возвращаемся к созданию блюд. У нас есть этот агент, который будет готовить блюдо на основе нашего запроса. А затем мы передадим его этому выходному ограничителю. Это узел критика, чтобы убедиться, что мы действительно предоставляем необходимую информацию для нашего блюда, включая название и описание. Также происхождение блюда. Этот агент, этот критик, будет выводить true или false. Хорошо ли справился этот агент с подготовкой блюда? И если он хорошо справился, то мы просто выведем это пользователю. Но если нет, то мы повторим попытку. Итак, мы идём по этому нижнему пути в графе. Мы возвращаемся к нашему исходному агенту, который снова создаёт блюдо, но также с обратной связью от нашего узла критика, поэтому он знает, как сделать лучшее блюдо на этот раз. И обычно то, что вы делали бы с этими потоками ограничителей, где вы хотите повторить попытку, — это фактически зацикливание всего пути обратно к исходному агенту. Но тогда вам нужно обрабатывать вещи, убеждаясь, что у вас нет бесконечных циклов и тому подобного. И поэтому я настроил его таким образом, просто чтобы упростить это здесь. Но знайте, что это обычно был бы цикл в графе, где вы бы вернули самооценку или критику обратно к исходному агенту, когда вы захотели бы повторить попытку. Но в любом случае, это наш ограничитель. Итак, теперь я могу сказать: «Давайте начнём новый разговор. Я просто скажу: «Приготовьте мне блюдо, которое не острое манго». Мы рассмотрим это в полном примере позже, убедившись, что мы не повторяем один и тот же рецепт. Но в этом случае мы создали блюдо. Как насчёт классической курицы альфредо? Но мы, очевидно, не предоставили достаточно информации, потому что узел критика здесь сказал, что valid — false. А затем он сказал, что обратная связь — это ответ не включает происхождение блюда. Итак, это одна из вещей, которые мы проверили с помощью этого выходного ограничителя, убедившись, что у нас есть происхождение. Итак, теперь это возвращается к нашему главному агенту, где на этот раз он будет давать нам блюдо и рассказывать нам о его происхождении. Посмотрите на это. Хорошо. Итак, на этот раз мы получили лучший результат. Очевидно, это очень глупый пример, но вы можете подумать о том, как ваш вывод, вам нужны определённые вещи, такие как происхождение блюда, и это ваш способ просто убедиться, что вы можете оценить вывод, чтобы убедиться в этом, а затем повторить попытку, если это не так. Итак, ограничители очень важны, просто уменьшают галлюцинации, убеждаются, что вывод соответствует тому, что вам действительно нужно.
Итак, последний тип узла, который мы должны рассмотреть здесь, — это наши узлы резервного варианта, и они очень важны, чтобы убедиться, что мы изящно обрабатываем ошибки в наших агентивных рабочих процессах. Мы не хотим просто аварийно завершать работу нашего приложения или полностью игнорировать ошибки. И именно это делают узлы резервного варианта...
Всё это взаимосвязано. Поэтому это будет очень похоже на наш пример узла управления из предыдущей части, потому что обычно узлы управления используются с узлами резервного копирования. Итак, у нас есть пример, где мы ждём подтверждения для отправки сообщения в Slack. Если мы одобряем сообщение, то мы отправим его. Но если мы отклоняем его, мы просто выбросим ошибку в рабочем процессе. И вы можете сделать что-то очень похожее в коде Python или любом другом. В N8N мы обрабатываем это с помощью нашего триггера ошибок. Это процесс, который мы будем запускать всякий раз, когда возникает какая-либо ошибка в нашем приложении AENTIC. И вот мощная вещь с резервными копиями: мы можем выбросить эту ошибку в любой части нашего рабочего процесса Aentic, а не только здесь. А затем мы будем обрабатывать эти ошибки все одинаково. В этом случае, просто отправляя сообщение с уведомлением о возникновении ошибки. Это может быть электронное письмо. Это может быть какой-то ответ пользователя по умолчанию, который вы даёте, сообщая им, что им нужно повторить попытку. Что бы это ни было, вы можете обработать это в этой части нашего рабочего процесса резервного копирования.
И так, на этом графике мы видим, как это выглядит. У нас есть типичный LLM в цикле. Это идёт к узлу управления, где мы либо будем предпринимать какие-то действия, а затем выводить результат, либо мы получим какую-то ошибку, а затем пройдём через этот процесс резервного копирования. В этом случае у меня здесь нет агента, потому что я просто хочу сохранить всё очень простым. Но я протестирую этот рабочий процесс. Он затем попросит меня одобрить. Пожалуйста, одобрите или отклоните это сообщение. Я одобряю его на этот раз. И мы увидим, что оно пойдёт по этому пути, без ошибки, как мы только что отправили сообщение. Но если я снова протестирую рабочий процесс, и на этот раз я отклоню его. Тогда мы увидим, что он пойдёт по пути ошибки. И если я перейду к истории выполнения, я могу взглянуть на это. Он выполнил рабочий процесс обработки ошибок. Итак, я должен максимально приблизить. Вернёмся сюда. Теперь он выполнил триггер ошибки здесь. Вы можете видеть, что ошибка — это ошибка произошла, потому что это сообщение, которое я отправил сюда. И это то, что я собираюсь отправить в этом сообщении Slack. Поэтому теперь в Slack я просто отправлю сообщение себе. Поэтому я пишу здесь: произошла ошибка. Поэтому, вместо того чтобы отправлять его в исследовательский канал, я просто оповещаю себя внутренне о том, что есть проблема с этим рабочим процессом Agentic. Вот что мы можем сделать с узлами резервного копирования. Супер мощно.
Теперь вот большая выплата. Мы можем вернуться к нашему полному примеру. Теперь, когда мы рассмотрели каждый из разных узлов, мы можем увидеть, как они объединяются, чтобы создать что-то более сложное, например, этот рабочий процесс Agentic. Поэтому, несмотря на то, что здесь происходит много всего, мы можем разбить его пошагово, чтобы сделать его очень-очень простым. И так, позвольте мне сделать это для вас. Я пройдусь по каждой части этого процесса, и я даже укажу, какой узел используется в каждой части. И так, сразу же, мы получаем доступ к нашей долгосрочной памяти в начале, как мы делали в нашем другом примере долгосрочной памяти. Затем это передаётся этому основному агенту. И это снова сгенерирует для нас блюдо. Но на этот раз у него есть инструмент для просмотра того, что у нас уже есть в меню, чтобы убедиться, что он не генерирует блюдо, которое уже есть здесь, что хорошо, потому что мы не хотим генерировать эту глупую острую манговую курицу в сотый раз. Итак, у нас есть наш LLM, наши узлы инструментов, наши узлы памяти, которые у нас есть для долгосрочной и краткосрочной памяти. И у нас также есть этот защитный барьер. Поэтому мы используем то, что называется парсером выходных данных, чтобы убедиться, что формат, который выводит этот LLM, всегда имеет название блюда и описание блюда. И причина, по которой это защитный барьер, заключается в том, что у нас есть этот парсер выходных данных с автоматическим исправлением. Поэтому, если агент не создаёт нужный формат, он повторит попытку, используя вторичный LLM для помощи в этом. И кстати, если бы мы дали этому LLM защитного барьера какие-то инструменты, это был бы ещё один агент. И так вы реализуете многоагентные рабочие процессы. Вам просто нужно иметь множество этих агентов, связанных вместе, или вы можете использовать агентов как инструменты, как субагенты.
И я знаю, что я не слишком много говорил о многоагентных рабочих процессах в целом, но если у вас просто много узлов LLM собраны вместе, каждый с разными инструментами, так вы создаёте многоагентные рабочие процессы. Но в любом случае, это просто небольшое отступление. Итак, это наш защитный барьер. Затем, после того как мы создадим это блюдо и у нас будет название и описание, гарантированные нашим защитным барьером, мы можем отправить сообщение в Slack, получив это одобрение. И затем у нас есть этот узел управления, который либо достигнет того же рабочего процесса обработки ошибок, который сообщит нам внутренне об ошибке в нашем потоке Agentic, либо мы отправим это блюдо в Slack, а затем добавим это блюдо в Airtable. Поскольку это не агент, выполняющий это действие, это ещё один узел управления, просто вставляющий этот приём пищи здесь в нашу базу Airtable. А затем мы перейдём к следующему узлу долгосрочной памяти. просто используя другой LLM для извлечения этих ключевых воспоминаний. Может быть, мы дали какие-то предпочтения вместе с нашей просьбой создать блюдо. Может быть, мы сказали что-то вроде того, что нам нравится десерт с нашим приёмом пищи, или нам нравятся блюда, которые сочетают в себе сладкое и солёное. Вот что у нас есть в нашей долгосрочной памяти. Это будет продолжать добавляться к этому, и мы вызовем этот узел, чтобы сохранить воспоминания. А затем у нас просто есть цепочка LLM в конце, которая подведёт итог всему и вернёт нам это финальное блюдо.
И так, возвращаясь к началу, у нас есть LLM, у нас есть наши узлы памяти, у нас есть наши инструменты, у нас есть наш защитный барьер, у нас есть человек в цикле. У нас есть этот пользовательский ввод, у нас есть эти узлы управления для управления детерминированным кодом, у нас есть наш резервный вариант, а затем у нас есть долгосрочная память, чтобы завершить всё. Так что все эти семь типов узлов, которые мы реализовали в этом потоке. И поэтому причина, по которой это мощно для нас, чтобы понять эти различные компоненты, заключается в том, что мы можем рассуждать о том, что мы хотим добавить в это, просто думая, например, нужна ли этому агенту долгосрочная память? Какие защитные барьеры я хочу реализовать здесь для входных или выходных защитных барьеров? Что я хочу, что я хочу делать, когда возникает ошибка в моём потоке? Какой резервный вариант я хочу иметь? Мы можем задавать себе эти вопросы по одному, разбивая этот более сложный процесс на то, что начинает казаться намного проще, когда мы думаем об этом таким образом. В этом сила. Мне было не так сложно создать этот полный поток, когда я просто думал о каждом из семи узлов и о том, что я хочу здесь реализовать. Поэтому теперь мы можем просто протестировать это. Я снова открою чат и скажу: приготовьте мне блюдо, которого ещё нет в меню. Просто убеждаюсь, что он использует этот инструмент для проверки меню, чтобы он мог сгенерировать для меня совершенно новое блюдо. Поэтому он сделает это. Он также получит доступ к моей долгосрочной памяти, поэтому он знает, что мне нравятся десерты с моим приёмом пищи. Мне нравятся вещи, которые сладкие и солёные. Поэтому я перейду в Slack сейчас. Посмотрим, что мне нужно одобрить. Кокосовые креветки с лаймом и сладким чили кускусом. Это на самом деле звучит очень-очень хорошо. Мой желудок урчит прямо сейчас. Поэтому я собираюсь одобрить это, потому что это определённо звучит хорошо для меня.
И так, теперь, возвращаясь к потоку, он отправит это сообщение в Slack. И так, я могу увидеть это в моём исследовательском канале. Вот. А затем я также добавил его в своё меню здесь, в Air Table. Посмотрим на это. А затем посмотрим, были ли добавлены какие-либо воспоминания. Я перейду к своей памяти. Посмотрим. Важная деталь заключается в том, что пользователь хочет блюдо, которого нет в меню. Хорошо. Итак, да, теперь он знает, что в целом я не хочу блюда, которые есть в меню. Поэтому это выглядит очень-очень хорошо. Посмотрим на это. И я знаю, что я не показал поток ошибок здесь, но это будет очень похоже на то, что мы видели раньше. Просто полный пример этого потока, создающий очень вкусное блюдо, которое я хотел бы приготовить прямо сейчас. Вот и всё. Это мой план из семи узлов, моя ментальная модель для построения любых агентов ИИ, разбивающая вещи на небольшие кусочки, чтобы сделать создание более robust агентов ИИ супер простым. И я хочу создавать контент о вещах, специфичных для, например, защитных барьеров и резервных копий позже, а также. Поэтому обязательно следите за этим. А затем я буду продолжать фокусироваться на таких фреймворках, как Pantic AI и Langraph, которые буквально фокусируются на агентах как на графах. Это абстракция, которая у них есть. Это просто то, что делает их такими мощными. И так, если вам понравилось это видео и вы с нетерпением ждёте больше вещей о агентах ИИ, я был бы очень признателен за лайк и подписку.