Паттерны проектирования AI-агентов

Всем привет! Мы на канале Nextway снова. Сегодня мы поговорим про проектирование АИ-агентов, про то, какие паттерны есть. И с нами сегодня Сергей Полешов. Я, в общем-то, не буду особо растягивать это, сразу передам микрофон. Расскажи, пожалуйста, как ты здесь оказался? Немножко о себе. Да, привет. Так, давай я начну о себе тогда, чтобы... Да, как ты сказал, меня зовут Сергей Полешов. Я уже более 10 лет занимаюсь поиском, рекомендательными системами. Где-то с 13 года работаю в области AI и машинного обучения. И последние 3 года работаю в Microsoft, где развиваю интеллектуальные решения для поиска, рекомендаций и этого всего. А до этого почти 10 лет провел в Яндексе, где занимался похожими задачами. Приятно познакомиться. Сегодня мы поговорим о паттернах проектирования агентов, о том, как из отдельных модулей, инструментов собрать настоящую интеллектуальную систему. Сами по себе LLM-ки — это просто мощные движки, которые не могут делать по-настоящему сложные задачи, и поэтому, чтобы они могли планировать, рассуждать... Пользовать инструменты нужны некоторые архитектурные принципы, паттерны, которые мы сегодня рассмотрим. Посмотрим, как агенты могут действовать, анализировать, кооперироваться, исправлять свои ошибки. Немножко посмотрим на упрощенные кейсы из индустрии. По сути, это такой конструктор, где из правильных блоков можно собрать агента, который работает, думает, делает какие-то сложные задачи. Это довольно активно развивающаяся область. Пока не все стандартизировано, поэтому это одно из представлений того, что сейчас есть. Итак, что такое агент в целом? Когда мы говорим «я агент», то мы имеем в виду не просто некоторую умную модель, а мы имеем в виду систему, которая умеет действовать, воспринимать окружение, понимать задачу, разбивать ее на шаги и достигать какой-то поставленной цели. Если LLM — это мозг, который отвечает на вопрос этого, то агент — это некий исполнитель, который делает сложные шаги, планирует и учится на своем опыте. Например, можно поручить организовать расписание агенту. Он пойдет, соберет все нужные данные, построит план действий, выполнит, скорректирует результат и выполнит задачу end-to-end. То есть это некий следующий шаг эволюции AI, где от простой генерации текста мы переходим к некоторым активным системам. И сейчас это очень важно, потому что AI-агенты становятся новой инфраструктурой для бизнеса. И сегодня компании внедряют агентов не ради хайпа, а чтобы автоматизировать процессы, масштабировать операции, делать быстрее, чем раньше. То есть как раз очень много оптимизации идет именно за счет агентов. Агенты помогают снижать издержки, ускорять вывод продуктов на рынок, брать на себя рутину, освобождать людей для неких стратегических задач. По сути, мы переходим от автоматизации отдельных функций. к такому управлению трансформацией процессов целиком. То есть перестраиваем, как работает бизнес сейчас. Здесь я показал некую карту паттернов проектирования агентов, где каждый паттерн – это строительный блок. Все вместе они формируют некую архитектуру системы, которая делает агента умным и автономным. Можно по-разному группировать паттерны. Есть очень много разных вариантов в интернете. Здесь я показал один вариант, который я взял из существующей литературы этого года. Мы начнем с базовых паттернов, потом перейдем к когнитивным и так далее. Мы их рассмотрим шаг за шагом. Итак, когда мы начинаем проектировать систему, у нас возникает вопрос, на чем их строить. Какие фреймворки можно использовать? Мы не будем рассматривать фреймворки подробно. Я просто хочу упомянуть, что существует целое огромное множество фреймворков, целая экосистема фреймворков для агентов. Есть всякие лендчейн, лендграф, гугл-эдкей и так далее, и тому подобное. Данный рассказ не фокусируется на коде, поэтому мы рассматривать подробно это все не будем. Просто надо понимать, что их есть довольно много, и они в целом довольно неплохие. Вот, и выбор фреймворка зависит от сценария. Есть простые, вроде ланчейн, и сложнее. То есть есть ланграф, есть Google SDK и так далее, и так далее. Это все обзорно, но от себя могу сказать, что в целом, если нужно делать какую-то сложную систему, то Google SDK покроет, скорее всего, все ваши потребности, и в целом это неплохой выбор именно для сложных систем. Идем дальше. Начнем с базовых паттернов. Это некий фундамент, и они описывают, как агент выполняет задачи. Начнем с промчейнинг или цепочки подсказок. Цепочки подсказок – это способ обучить агента решать сложные задачи шаг за шагом. Вместо того, чтобы пытаться заставить модель ответить на все одним промтом, мы разбиваем задачу на несколько этапов, как в классическом pipeline. И каждый шаг здесь – это отдельный LLM-вызов, который использует результат предыдущего. Все это делает систему не просто точнее, а гораздо более надежнее и управляемее. И это нужно для того, чтобы… Наши системы могли справляться с сложными задачами, потому что простых ответов часто недостаточно. Нам нужен контролируемый ход решения, и промчейнинг, он как раз позволяет задать структуру, что агент делает сначала, что потом, как связываются промежуточные результаты и так далее. Например, из e-commerce можно привести такой пример, что агент может сначала извлекать ключевые факты из отзывов покупателей, потом классифицировать их по категориям. какие положительные, какие отрицательные, какие нейтральные, и в конце генерировать краткий отчет для аналитиков. И такой подход позволяет строить пайплайны, и дальше каждый шаг пайплайна можно масштабировать или выполнять параллельно и так далее. И цель данного паттерна – это как раз снизить стоимость одного промта и повысить эффективность контекста, потому что чем меньше контекст, тем модель лучше справляется с задачей. Если мы разбиваем наши ги, то контекст становится более перевариваемым. Следующий промпт – это рутинг. Он нужен, чтобы понизить связность и повысить пропускную способность системы. Это маршрутизация, и она нужна, когда у нас есть разные типы запросов, и каждый запрос требует своего обработчика. Например, если пользователь задает какой-то запрос, например, в support, то агент может понять, что это за проблема. Это техническая проблема? вопрос о балансе или что-то еще. И рутинг как раз позволяет выбирать правильный путь и передавать запрос на следующую стадию в нужную ветку. То есть, либо обработать техническую проблему, либо ответить на баланс и так далее. И это делает систему более гибкой и умной. Система решает, куда направить задачу, а под капотом уже работают некоторые правила, которые позволяют делать эту маршрутизацию. То есть, это могут быть либо ЛЛМ-ка с промптом, либо какие-то векторные имбеддинги, либо какие-то правила. В общем, здесь можно разные способы использовать, но маршрутизация через ЛЛМ – это самый стандартный способ. Идем дальше. Следующий промпт, следующий паттерн – это парализация. И это помогает улучшить стабильность системы под нагрузкой. Разные шаги параллельно. Вместо того, чтобы их обрабатывать последовательно, мы запускаем несколько шагов сразу и в конце объединяем результат. То есть, если мы посмотрим, например, с Marketplace, например, пользователь ищет ноутбук, и агент может одновременно задать запрос про цену в разные источники, потом получить результат. скомбинировать его и вернуть итоговый ответ. То есть мы не последовательно делаем, а параллельно. Это делает систему более отзывчивой и эффективной. Следующий паттерн помогает нам уменьшить ошибки и улучшить точность. Это рефлексия. Этот паттерн позволяет агенту проверять самого себя. То есть он работает по принципу сначала сделай, потом оцени и потом исправь. И пример. Один агент. назовем продюсер, создает некий черновик, например, какой-то ответ пользователю про юридический документ. Затем второй агент, критик, проверяет этот текст, ищет ошибки, уточняет, отмечает неточности. И после этого третий шаг, refine, который вносит исправление, улучшает финальный результат и уже отдает отчет пользователю. Такой цикл генерации критика исправления, он помогает уменьшить галлюцинации, делает ответы более точными, надежными. Например, пример из практики. Есть такой плагин для написания кода GitHub Copilot, который не просто пишет код, а проверяет написанный код, используя разные тесты, компиляцию, и ищет ошибки. Если он это находит, он перезапускает систему и генерит новый код уже с исправлениями. Иногда такой цикл может повторяться снова и снова, и здесь важно, чтобы было ограничение по количеству повторов, иначе... Можно съесть очень много токенов, это будет очень дорого и бесполезно. Следующий шаг, следующий паттерн – это Tool Use. Он помогает уменьшать ошибки и повышать согласованность. Tool Use – это агент перестает быть просто моделью, а начинает действовать системой. То есть LLM сама по себе не знает каких-то актуальных данных. Поэтому ее нужно подключать к инструментам, используя разные API. Можно подключить к базе данных, CRM, к каким-то плагинам, чтобы LLM получала реальную информацию и выполняла действия. Например, если представить какого-то HR-агента, который что-то делает, он может сходить в LinkedIn, проверить профиль кандидатов и что с ними сделать. Или, например, чат GPT может работать с Booking или, скажем, Wolfram Alpha. чтобы найти гостиницу или рассчитать какую-то формулу. Механика довольно простая. Модель решает, какой инструмент ей нужен, делает вызов, получает ответ, генерирует результат. В общем, все работает таким образом. Здесь важно, чтобы была безопасность этой системы, потому что в последнее время есть способы взламывать промты. И если у системы есть доступ к какой-то суперважной информации, то с помощью взломания промтов эту информацию можно как-то извлекать и куда-то передавать. Поэтому здесь важно иметь guardrails, которые мы рассмотрим далее. Итак, идем дальше. Следующий паттерн – это планирование. И он помогает уменьшать задержку и улучшать адаптивность системы в целом. То есть этот паттерн превращает агента из такого... Когда перед агентом стоит большая цель, он не сразу бросается ее выполнять, а разбивает задачи на шаги и выстраивает четкий порядок действий. Например, вы даете задачу организовать маркетинговую кампанию, агент сам может сформировать план, этапы, делайны каких-то ответственных и пошагово проходит этот маршрут. И это позволяет решать многошаговые задачи, создавать некие структурированные процессы, автоматизировать управление. И это все... улучшает качество в целом идем дальше последний промпт из базовых дальше у нас будут еще другие это мультиагентность это когда несколько агентов работают системе вместе как команда и каждый из них выполняет свою роль обменивать результатами и вместе они добиваются общей цели это все позволяет повысить масштабируемые системы и улучшить специализацию промптов и агентов что в целом приводит к росту качества например Опять же, возьмем маркетинг. Можно создать агента-аналитика, который собирает данные о конкурентах, агента-писателя, который превращает их в статью, агента-редактора, который делает текст более убедительным и готов к публикации. И такая кооперация похожа на команду людей. То есть есть аналитик, опирайтер, редактор. И они все работают синхронно, без задержек и получают лучшее качество. Такой подход нужен там, где одна модель не справится. Он нужен в некоторых сложных многоэтапных задачах, требующих разной компетенции. И все это позволяет, опять же, улучшать контекст, делать более специфичные промпты, более правильный набор инструментов. И это, как я сказал, улучшает качество в целом. Итак, следующий уровень паттернов – это когнитивное расширение. И здесь агент уже не просто выполняет задачи, Он думает, учится, запоминает контекст, адаптируется, ставит цели, отслеживает прогресс и в целом получаем интеллектуальную систему. Итак, начнем с управления памятью, memory management. Это память агента, его способность помнить контекст и некоторый прошлый опыт. Без нее агент каждый раз будет отвечать как будто впервые, это всех раздражает. А с памятью он понимает, о чем шла речь раньше, учится взаимодействовать и становится персонализированным. Память бывает двух типов. Бывает краткосрочная, хранит контекст текущего диалога, и долгосрочная, которая сохраняет ответы в некой внешней базе и потом может делать поиск по этой базе. Например, по вектору, имбеддингу можно находить релевантные ответы и подставлять их в контекст для того, чтобы модель их могла использовать. Все это помогает повышать соответствие требованиям. Но надо учитывать, что нужно заботиться о персональных данных, потому что это супер важная критичная информация, которую нужно хранить очень-очень аккуратно. Это отдельная тема, мы ее рассматривать не будем, но в любой памяти очень важно хранить персональные данные очень-очень безопасно. Пример использования данного паттерна – это... Например, некоторый персональный ассистент, который может запомнить, что пользователь любит итальянскую кухню и в будущем предлагает рестораны этого типа. Ну, такой простой пример. В целом, память делает агента умнее, связнее, ближе к человеку, к некой персональности. Это как второй мозг, где хранится накопленный опыт и строится дальнейшее взаимодействие на основе этого опыта. Идем дальше. Следующий паттерн – это обучение и адаптация. Этот паттерн позволяет делать агента умнее со временем. То есть мы не просто выполняем команды, а агент учится на опыте, анализирует фидбэк и корректирует свое поведение. спрашивать пользователя, понравился ли ему ответ или нет. И когда пользователь отвечает да или нет, он может использовать эту информацию в будущем. То есть это некое обучение на обратной связи. И такая адаптация делает агента более устойчивым, он не ломается в новых условиях, перестраивается, продолжает работать лучше, чем раньше. Это важный шаг от перехода от статической модели к системе, которая может сама совершенствоваться. И агент учится думать о своих ошибках на основе полученного фидбэка. Идем дальше. Следующий паттерн – это суперпопулярный сейчас, скажем так, паттерн MCP. Про него можно делать отдельный рассказ. Мы не будем на нем долго останавливаться. Но это очень важная часть текущих... улучшений агентских систем. MCP – это Model Context Protocol. Это шаг, когда агенты могут использовать инструменты. Ранее мы рассмотрели Tool Use, где Tool Use – это паттерн, который направлен на использование какого-то конкретного API, конкретного инструмента, а MCP – это единый стандарт взаимодействия между LLM и всеми внешними системами, которые можно подключать как плагины. То есть MCP создает общий язык между моделью и сервисами. Например, можно ходить в Jira, Slack, в базу данных. И MCP позволяет подключать много-много разных плагинов со стандартным описанием. И LLM, она, используя это описание, понимает, как вызывать данные инструменты. И благодаря этому агент не просто знает, какие инструменты доступны, а может динамически к ним подключаться, обмениваться контекстом, ну и работать по единому протоколу. Например, можно вызывать API, чтобы получать данные клиента из CRM, используя некий MCP endpoint, который использует реальные данные и возвращает их в ответ пользователю. Как я сказал, MCP построен по стандартной архитектуре клиент-сервер. Через Google EDK или FastMCP можно легко добавлять собственные сервисы. Это очень кастомная штука для одного инструмента. Это MCP, это протокол, который связывает все инструменты между собой. Он дает агентам возможность не просто выполнять действия, а быть частью экосистемы, скажем так. Но, как я опять же упомянул ранее, с этим связаны и минусы. То есть, во-первых, на описание инструментов, если их очень много, может уходить очень много токенов. И это может засорять контекст. Это будет неэффективно и довольно дорого. Поэтому нужно следить, чтобы количество этих инструментов было ограничено, только те, которые нужны. А также это может быть небезопасно, потому что если система имеет доступ к каким-то критическим API-шкам, инструментам, то ее можно взломать и использовать в нехороших целях. Поэтому очень важно ставить разного рода гардрейлы, проверки. чтобы система не делала того, чего мы не хотим. Это сейчас довольно активно развивающаяся область взламывания, когда на основе подключенных MCP-шек можно вытаскивать какие-то данные, которые могут навредить. Итак, идем дальше. Следующий паттерн – это goal setting и monitoring. Это делает агента... более целенаправленным. То есть агент перестает просто выполнять команды, а начинает работать над конкретными целями. То есть мы прям задаем ему конкретную цель, что нужно сделать. Например, увеличить конверсию, сократить время ответа или достичь какого-то прям явного KPI. Это уменьшает число переделок в будущем, которые по ответу модели, и повышает согласованность действий разных шагов. И агент, формулирует себе задачу план отслеживает прогресс корректирует действия и в общем не справляет если что-то идет не так цели должны задаваться как в реальности по smart то есть они должны быть конкретными измеримыми ограниченными по времени и и так далее то есть например можно построить прям и я и проектного менеджера который следит за дедлайнами обновляет статус задач предупреждает о рисках В общем, идея такая. Так, идем дальше. Третий блок – это взаимодействие. Здесь агенты учатся работать с людьми, знаниями, спрашивают человека, обращаются к базам данным. В общем, сейчас это все посмотрим. И первый проект этой группы – это Exceptional Handling и Recovery. Это про надежность и выжимаемость агента в реальном мире. Он помогает улучшить, как я сказал, надежность и уменьшает число отказов системы. То есть в реальном мире все далеко не идеально. API падают, данные недоступны, время отклика часто превышено. И агент должен уметь не просто ломаться, а восстанавливаться и продолжать работать. То есть он должен ожидать эти ошибки в целом. И агента надо учить повторять запрос, переключаться на резервный источник или откатываться к предыдущему состоянию. Например, если какой-то финтех-агент не может получить данные из API, мы можем добавить ретраи, можем залагировать ошибку, можем перейти к запасной базе и как-то вернуть результат, который нас устроит. Ну или не вернуть. В общем, такой подход делает систему устойчивой, надежной. Она не зависает из-за одной ошибки, а работает более стабильно и предсказуемо. Идем дальше. Следующий важный паттерн – это Human in the Loop. Это такой способ встроить человека в процесс работы агента. Он нужен там, где важно качество, безопасность и этик. Агент предлагает варианты, но человек остается в роли контролера, который проверяет, корректирует и утверждает результат. уменьшить ручную нагрузку на человека, потому что агент выполняет действия за него, но также позволяет иметь хорошее качество, потому что финальное решение за человеком. Например, AI-ассистент может формировать оффер кандидату, но финальное решение принимает HR, потому что это критичное решение, и там очень важно, чтобы человек принимал финальное решение. Таким образом, как я сказал, мы сохраняем скорость работы агентов. но при этом избегаем рисков с ошибками и неправильными решениями. Это некий баланс между автономией и ответственностью, где агент сделает все быстро, а человек остается в цикле, чтобы задать финальное направление. Это важно для сложных и чувствительных задач. И если ошибка стоит слишком дорого, то обязательно нужно подтверждение человека. Идем дальше. Следующий тоже суперпопулярный паттерн в индустрии – это RAC. Retrieval Augmented Generation. То есть это способ сделать агента умнее без переобучения модели. Потому что LLM не знает всего, она не знает свежих данных, ее данные ограничены моментом обучения. И RAC решает эту проблему тем, что подключает модель к внешним источникам информации. То есть механика такая. Мы сначала ищем нужные документы, используя доступное API. Например, можно сходить в поиск или сходить в какие-то базы данных. Потом получаем ответ, формируем из этого prompt и дальше используем эти данные для того, чтобы получить финальный ответ. То есть у нас есть шаг Retrieval, получить документы, используя доступное API, а затем, используя полученное, добавить в контекст prompt, это Augmentation, и улучшить качество модели. В результате агент отвечает не по памяти, а на основе актуальных фактов, ссылается на источники, что очень важно. И это позволяет уменьшить задержку, потому что мы сразу даем актуальную информацию из реального мира, LLM не надо ее генерировать. Это улучшает фактическую точность, потому что данные имеют реальные источники, их можно проверить. То есть это очень популярный паттерн, который все используют. Например, можно сделать юридического ассистента, который может искать статьи закона, Но он вначале идет в реальную базу, потом формирует обоснованный ответ с конкретными ссылками. И, в общем, как я сказал, RAC делает ответы точнее, прозрачнее, надежнее. По сути, это такой мост между языковой моделью и миром реальных знаний. И, наконец, последняя часть. Это продвинутые архитектуры. Здесь агенты... Становятся более масштабными, безопасными, исследовательскими, умеют общаться с другими агентами. В общем, сейчас мы это посмотрим. Начнем с Interagent Communication или межагентное взаимодействие. Это то, что позволяет агентам работать как в команде, как команда. Если раньше агент действовал изолированно, то теперь они могут напрямую обмениваться сообщениями, результатами. Это улучшает масштабировость, потому что каждый агент может быть узкоспециализированным, у него узкий набор инструментов, у него лучше понимание контекста, более узкий промпт. Все это улучшает качество каждого отдельного агента, если мы их делаем узкоспециализированными. Например, аналитический агент, как мы рассматривали ранее, может собирать данные, передавать их агенту, который строит прогноз. Другой агент может принимать решение. Это получается такая живая цепочка взаимодействий. И как раз этот A2A взаимодействие, Interagent Communication, это некий протокол, который использует язык обмена данными между разными агентами. То есть агенты могут общаться между собой. Сейчас единого стандарта для такого протокола не существует, как для MCP, например. То есть каждый фреймворк поддерживает свою какую-то собственную реализацию. Например, тот же Google EDK реализует свой стандарт взаимодействия. И его тоже можно как-то использовать. Но, опять же, такого как MCP, когда все поддерживают один стандарт, такого пока нет. И главное отличие от MCP в том, что MCP связывает агентов с внешними системами, а A2A связывает агентов между собой. И все это превращает набор отдельных моделей в некую полноценную экосистему, таких понимающих друг друга умных коллег. Следующий паттерн – это оптимизация ресурсов, ресурсов в Air Optimization. Это про то, про умение агента думать не только о задаче, но и о цене ее выполнения. Этот паттерн помогает балансировать между качеством, скоростью и стоимостью. Это нужно, чтобы улучшить эффективность системы в целом. То есть, когда поступает запрос, агент сам решает отправить ее на более быструю какую-то дешевую модель или на более мощную, дорогую. То есть, опять же, например, тот же Microsoft Copilot, он может выбирать модели для простых запросов, например, что-то вроде GPT-4, для сложных GPT-5 и перенаправлять в зависимости от сложности запроса. То есть, агент действует как умный менеджер ресурсов, он оптимизирует вычисления, прогнозирует нагрузку и при этом не теряет качество результата. Такая архитектура делает систему не просто экономичной, а адаптивной и отзывчивой. Так, идем дальше. Резонинг – это тоже популярная тема последних месяцев, наверное. Это то, что делает клиента не просто исполнительным, а мыслителем, скажем так. То есть, когда задача сложная, и нужно проанализировать симптомы, рассчитать стратегию, доказать гипотезу, агент не выдает ответ сразу, он рассуждает шаг за шагом. Это называется цепочка размышлений. либо chain of thoughts, либо tree of thoughts и так далее. То есть есть разные, скажем так, способы рассуждать. И каждый шаг – это маленький такой вывод, который приближает к решению. И в целом это все очень сильно повышает качество ответа. Но, конечно, увеличивает стоимость. Такие техники позволяют агенту не угадывать, а объяснять логику своих действий. Например, в той же медицине агент может пошагово исключать какие-то диагнозы. Google DeepMite, например. используют для того, чтобы решать олимпиадные задачи и так далее. Это повышает логичность, снижает противоречия. И по факту это такой ризонинг, это такой мозг агента, который делает выводы, проверяет себя, объясняет, почему именно так. И чем лучше агент умеет рассуждать, тем больше ему можно доверять. То есть все современные модели идут именно в эту сторону. Пока. Так, идем дальше. Guardrails. Guardrails – это то, что делает агентов более безопасными для бизнеса и пользователя. Как я сказал ранее, сейчас очень активно развивается область, когда промпты хакают и как-то пытаются использовать встроенные тулзы для того, чтобы взламывать систему. И вот как раз Guardrails позволяет… Ну и вообще, в целом, модели они галлюцинируют, поэтому Guardrails очень важны. Желательно проверять каждый критический шаг. и добавлять отдельные проверки. То есть даже самый умный агент может ошибиться, выдать что-то некорректное, поэтому нужны защитные рамки, фильтры, модерации. Это могут быть простые какие-то правила, или могут быть какие-то также LLM, которые это делают более умно. В общем, Guardrails работает на всех этапах. Они принимают данные, проверяют, ограничат инструменты, фильтруют ответы перед тем, как ответ попадает к пользователю. Это улучшает безопасность, снижает ручную разметку. Ну и все это очень важно, потому что агентов, как я сказал, легко взломать. Например, в соцсетях, это чуть-чуть пример, можно оценивать токсичность текста и пропускать нежелательный контент. Это тоже как пример Гавриила. В общем, без этих рамок система может быть быстрой, но небезопасной. А с Гардарелс она становится надежной и более ответственной, что критично, в том числе... Не только для защиты от атак, но и для репутации и каких-то корпоративных решений и всего такого. Идем дальше. Так, Evolution и Monitoring – это контроль качества агентов. Когда агенты уже работают, нам важно не просто его запускать, а еще и измерять, насколько хорошо он справляется с задачами. И здесь мы оцениваем точность ответов, скорость реакции. Использование токена, следим, не начинается ли дрейв или галлюцинации. И важно, чтобы мы уменьшали число повторов при плохих ответах, улучшали точность системы целиком. В общем, это позволяет наблюдать и улучшать систему. То есть, если мы хотим сравнивать ответы агента с какими-то эталонными ответами и фиксировать, где качество падает, можно устраивать такие проверки. Быстрее находить ошибки и улучшать систему без полного переобучения, переделывать системы. В общем, следить за системами сложно, поэтому каждый шаг нужно мониторить и вставлять какие-то проверочки, которые нам позволяют оценить качество. Мониторинг стандартно, обычно ведется через инструменты вроде графана, можно использовать АБ-тесты и так далее. В общем, это важно, потому что мы должны превращать... систему из черного ящика в некую управляемую измеримую и только то что можно измерить можно улучшить то есть это очень важно так идем дальше осталось два этот паттерн приоритизация он помогает уменьшать затраты соблюдать слои по кратичным задачам то есть это навык агента выбирать что действительно важно прямо сейчас то есть ресурс всегда ограничены время вычисления внимание И если агент пытается делать все подряд, он теряет эффективность. Поэтому приоритизация позволяет расставлять акценты, что нужно делать немедленно, что может подождать. Обычно используется некая матрица важности, срочность, агент пересчитывает приоритеты и адаптируется к изменениям. То есть, например, если в службе поддержки есть срочные тикеты, они должны уходить на обработку первыми. А менее критичные можно поставить в очередь. И важно приоритизировать поток задач. И как раз этот паттерн, он пытается таки приоритетно назначать и приоритетизировать. В итоге система становится быстрее, она становится еще умнее, потому что понимает, что важно, и концентрируется на важных задачах. Последний паттерн – это Exploration и Discovery. Это про агентов, которые не просто отвечают, а ищут что-то новое. Следующий уровень развития агентов – это когда агент способен выдавать некие гипотезы, проверять их и делать выводы как настоящий следователь. Это нужно, чтобы ускорить инновации. Например, в фармацевтике такие агенты могут помогать открывать новые лекарственные соединения, анализировать данные, предлагать, какие комбинации стоит проверить, какие нет. И главная цель данных, скажем так, паттернов агентов – это не заменить человека. а усилить его креативность. То есть агенты берут на себя некую рутину, сбор данных, анализ отчетов, чтобы человек мог сосредоточиться на самом важном, на открытиях и инновациях. Итак, если подвести итог, то сила не в одном паттерне, а в комбинации. То есть работающая система – это как раз комбинация из разных блоков, паттернов, которые формируют уже итоговую систему. И когда мы объединяем несколько подходов, например, planning, tool, use, rack, мультиагентность, reflection, мы делаем из агента настоящую такую агентскую систему, некого ресерч-ассистента, который ищет, анализирует, рассуждает, проверяет. В общем, именно композиция паттернов делает систему умной, устойчивой и полезной в реальной работе. В общем, будущее именно за большей автономностью. Сейчас мы все движемся от парадигмы, когда человек что-то делает в цикле. к тому, что человек на контроле. То есть агенты все делают, а человек проверяет и следит за качеством. Для этого нужно развивать общие стандарты, такие как MCP, нужно делать стандарт межагентного взаимодействия. Также нужны открытые экосистемы, где агенты могут взаимодействовать друг с другом. В общем, главные вызовы сейчас – это безопасность, потому что, как я уже сказал, агентов довольно легко... И сейчас это очень популярно взламывать. Очень важна этика и устойчивость, чтобы агенты генерили одинаковые ответы. Сейчас это тоже далеко не так. И в конечном счете, неважно, насколько умный агент, если он ненадежный, если он нечестный, небезопасный, то это не очень классно. Поэтому нужно следить за этими вещами. Итак, спасибо, что дослушали. Здесь я привел несколько ссылок, куда можно провалиться дальше, поизучать. Тема довольно обширная, пока не стандартизированная. И на этом все. Сергей, спасибо огромное. Прям такое ощущение у меня было, когда я впервые забыл Чен Ричардсона, по-моему, ресурс по микросервисам, по паттернам и всему. Вот примерно такое ощущение, как теперь объять все это разом необъятное. Вот, тут вопросики, прямо в чатике активно. Давай я сейчас немножко попробую порядок выстроить. Вот Вячеслав интересуется, а что такое вообще в этом смысле агент? То есть это как бы некая матрешка? Агент внутри себя может использовать других агентов? Или что мы в данном случае понимаем под агентом? То есть мы его проектируем, агента, или мы их используем, агента, вот в рамках контекста? Хороший вопрос. В общем, в данном случае, да, можно... Стандартного ответа нет, короче, можно понимать все, что угодно. Но в данном случае агенты для меня это некоторая система, которая делает задачу end-to-end. То есть это не просто промт, который мы скормили и ЛЛМки получили ответ. Это именно end-to-end решение задачи, желательно без... То есть, скорее так, с минимальным участием человека или вообще без человека. То есть, агенты, их можно сузить, и тогда агент будет это какая-то единица, которой мы сказали, вот ты отвечаешь за... у тебя вот такая специализация. Можно это назвать агентом, а можно назвать, что вот это вся система, которая содержит много таких агентов. Я согласен, да, что это не очень, скажем так, стандартное определение, но тем не менее... можно по-разному смотреть на эти вещи то есть для меня когда говорю агентизация это скорее решение задачи интуинт но до внутри агента другие агенты это звучит странно согласен насколько правильно такой налоги проводить вот мы там привыкли к микросервисом они взаимодействуют у каждого есть а пишка не друг друга вызывают вот данная аналогия применительно к агентам, когда мы решаем эту задачу, она насколько вообще применима или здесь какие-то более интересные уровни вложенности или чего-то еще? В целом применимо. Просто микросервисы — это такой гвозди, молоток, послал, получил. Агенты, они все-таки более умные, они могут генерировать более умные какие-то ответы, и они нестабильные. То есть если микросервер что-то послал, скорее всего, ты ожидаешь что-то получить вполне конкретно. Агенты не всегда дают такой же ответ. То есть обычно у модели есть некая, скажем так, температура, случайность, и он генерирует разные ответы. То есть система может работать по-разному, и зачастую, это очень плохо, но зачастую системы вот такого рода, они работают очень нестабильно. То есть чтобы их стабилизировать, нужно прямо отдельно заниматься стабилизацией. В развитии этой темы Данила вопрос, а в чем тогда отличие паттерна A2A от Multi-Agent Collaboration? В целом ни в чем, просто A2A это как бы больше протокол, наверное, как-то все стандартизировать. И если мы можем сказать в системе, в одной и той же по факту системе, ты эксперт в этом, ты эксперт в этом, ты эксперт в этом, а можно взять и разнести на, как ты говоришь, микросервис. И каждый агент будет получать запрос, условно там HTTP запрос, обрабатывать и возвращать тебе ответ. Но в данном случае да. У Google, например, вот они недавно закоммитили как раз один из вариантов такого A2A взаимодействия. То есть я могу потом ссылку скинуть, который можно использовать. Пока вот прям нету стандартных протоколов для взаимодействия. То есть каждый фраморк делает это по-разному. А вот MCP можно при этом использовать именно как для A2A взаимодействий или это именно от агента к каким-то там условно обычным тулзам? Не, ну MCP он скорее больше про тулзы, потому что ты описываешь, что у тебя есть конкретная тулза. молоток ты говоришь это молоток он нужен чтобы гвозди и когда модели нужно забивать гвозди она вот их забивает идет в мсп и что-то использует то есть они до каком-то смысле пересекаются но мсп это больше про про тузы и как раз мсп вот как как я говорил он довольно стандартный что привело к его бурному росту что все делают эти плагины и их можно потом подключать а в этой насколько как бы то есть в этой мы как-то еще три места части контекста передаем между агентами в идеале до 10000 надо смотреть реализации конкретных это и то есть тут прям надо разбираться потому что это такая пока развивающаяся область ну да в целом по сути ты должен сказать агенту что у тебя есть такая проблема реши ее пожалуйста и передать все необходимые данные то есть контекст вам всегда нужен то есть в любом пром те пром содержит очень много контекста в себе то есть без контекста она не работает то есть если в mcp тебе контекст передавать не нужно потому что это инструмент ты просто вызываешь его с определенными параметрами и он тебя защищает определенный результат потому что по факту in point некоторые а агент должен решать задачу все-таки более более понимая, что нужно тебе сделать. Поэтому да, тебе контекст нужен. Тут вот еще на тему безопасности вопросы. Какой уровень доступа у агента в LLM-системе? Есть ли какое-то понимание ролей? Я не до конца, честно говоря, понял, но... Про безопасность в этом-то и возникает основная проблема всех тех toolhuse и инструментов, что зачастую... Все вот эти агентские системы, они имеют довольно высокий доступ, то есть у них много прав в системе, может быть. И также к ним могут быть подключены инструменты, которые могут делать разные вещи. То есть очень много всего могут делать, и в этом основная опасность, потому что сейчас это очень многие эксплуатируют. И небольшими изменениями промта можно заставить систему делать очень плохие вещи. Поэтому очень важно как раз ограничивать и инструменты, и доступ к системе. То есть эта часть должна быть очень хорошо продумана. И часто обязательно заставляют вставлять гардрейлы, которые делают минимальные проверки, что система не творит какой-то дичи. То есть это очень важно. Это реально одна из больших проблем безопасности. Как раз вопрос, как я понимаю, это относится к guardrail. То есть где задаются правила безопасности, какую инфу можно отдать, какую нет. Там типа персуха, NDA и прочее. Потому что бывали кейсы, когда что-то такое модель выдавало. Это тоже относится к guardrail. В нем реализуется. Да, все персональные данные, это все очень большая тема. Если про это явно не думать и давать системе доступы и тулзы, то хорошее не очень будет долго работать. Скорее всего, это будет эксплуатироваться, ну, как и любая другая система. Такой вот общий вопрос. А если, как мне ты показал множество паттернов, которые можно использовать, а вот от Влада вопрос, а есть ли какой-то, в принципе, гайд по базу рекомендуемых паттернов под конкретную задачу? То есть, грубо говоря, я знаю, я вижу, что есть куча паттернов, а как можно, как вообще понять, когда, каким мне прибегать, что мне нужно? Очень хороший вопрос. Есть прям дофига разных... разных источников про паттерны но нигде конечно не скажу что вот под твою задачу используя вот этот паттерн то есть ну я попытался когда когда их описывал пытаться я пытался указывать допустим этот партн нужен для оптимизации какой-то эффективности да то есть чтобы что делать с тем более эффективно это там чтобы было ну более логично хорошее качество и и так далее и тому подобное то есть нужно думать это как так же как паттерны проектирования там любых других систем нужно понимать что тебе нужно если и если ты хочешь чтобы система была более эффективная то подумай про то как может быть тебе нужно понять что у тебя есть какие-то более дешевые способы решить задачу, и для более дешевых способов ставь там проверку и перенаправь более дешевые какие-то модели. Если нельзя, то иди в дорогие модели. Ну, то есть вот такого рода только есть рекомендации. Ну, то есть, ну, да, там запараллелить что-то, ну, примерно то же самое, да, что разделить на маленькие шаги и тому подобное. То есть нужно понимать, что тебе нужно достичь. Если ты видишь, что качество системы плохое, тебе нужно подумать, как это качество улучшить. Тогда нужно думать в сторону, разделить на маленькие шаги, то есть промчейнинг, сделать некую маршрутизацию, может быть, надо добавить рефлекшн, чтобы модель думала про результат, который она выдала, и его как-то переделывала. Возможно, не хватает тулзов, потому что нет доступа к реальному миру. Если у тебя суперсложная задача, тебе нужно делать думающие модели про reasoning. Ну, то есть, все зависит от того, что ты хочешь получить. Если ты замеряешь качество и видишь, что оно недостаточное, и ты понимаешь, что все простые способы качества не помогли улучшить, тогда нужно подключать какие-то тяжелые способы типа reasoning. Если ты понимаешь, что есть простые способы улучшить качество, типа разбить на более мелкие шаги, то используешь это. Но вообще правило простое. Если качество ответа плохое, всегда нужно бить на шаги, всегда нужно сужать контекст, как-то более целенаправленно на каждый шаг делать. То есть не просто говорить, решить мне вот эту, пожалуйста, думать или просить модель подумать, на какие аспекты эту задачу можно разбить, каждый аспект решать по отдельности, если он сложный, а потом уже агрегировать результат. То есть это самое первое обычно, что делать. Спасибо. Так, коллеги, нам надо потихоньку сворачиваться. Давайте вот два вопроса и на этом закончим. Если будут еще вопросы, можете там комменты потом закидывать. Мы как-нибудь там письменно попробуем это запостить. Вот вопрос как раз интересный. А как подходить вообще к оценке, к планированию ресурсов для агентов? Ну, именно, я понимаю, речь про железо. Ибо, особенно когда нагрузка в принципе не предсказуема с учетом модели и ее поведения. Есть ли там какие-то рекомендации? Нужно пытаться предсказать. То есть нужно оценивать всегда стоимость и количество токенов. То есть стоимость базируется на токенах. И, соответственно, если используются паттерны, допустим... что-то вроде рефлексии или ухода в цикл, когда мы проверяем результат и хотим его улучшить или что-то доделать, нужно всегда контролировать количество циклов. То есть нужно просто думать про стоимость. Бесконечный цикл приведет, скорее всего, к тому, что стоимость будет очень высокая, это не будет приводить к результату. Нужно всегда добавлять ограничения на стоимость сверху. То есть подумать, какая стоимость для вас приемлема, если под эту стоимость... качество ответа устраивает, тогда отлично. Если качество ответа не устраивает, тогда думать, как это оптимизировать. Как я упоминал ранее, те же MCP-плагины, если их очень много, они очень сильно увеличивают стоимость, потому что каждый MCP-плагин – это добавление в контекст описания этого плагина. И много таких плагинов сильно делает более дорогим. каждый каждый запрос и вам это скорее всего не нужно то есть базово нужно разделить то есть если вам реально нужны эти тузы в промке их нужно разделить на узко специализированный как раз агентов узко специализированные задачки и каждой задачке давать минимальный набор тузов и минимальный собственно пром который удовлетворяет по качеству то есть оценивать по стоимости это как железом то есть нужно прикинуть что вам нужно замерить качество понять что у вас качество с этой стоимостью устраивает потом подумать как-то за оптимизировать если качество или стоимость не устраивает нужно опять же это оптимизировать но вот самые базовые такие ошибки это когда слишком много циклов всегда надо ограничивать когда слишком большой контекст из-за мсп или просто слишком большой контекст это все нужно разбивать на маленькие задачки на специализированные агенты и ограничения циклов и guardrail и добавлять А есть о чем, не знаю, какие-то, может, это максимально абстрактно, какие-нибудь средние показатели, типа, что такое нормально по количеству циклов? Ну, типа, там, 3 или 30-40 – это нормально в среднем, а вот 300-400 или 34 тысяч – это перебор. Не, ну, такого нет, но там зачастую, если модель не справилась, ну, скажем так, за три цикла, то есть с большой долей вероятности она не справится и за 10. Ну, лучше это замерить разово, да, то есть это, скорее всего, какие-то сложные задачи, и такие задачи лучше решать не через увеличение числа циклов, а подумать, как ее сделать так, чтобы с одного цикла задача была решена. То есть, мне кажется, больше трех циклов это точно неправильно поставленная, ну, неправильно поставленная система с точки зрения промптов агентов, либо какая-то задача, которая суперсложная, которую... не так просто решить то есть я бы сказал что больше трех циклов скорее всего нужно менять промпты агентов и вот это все но вообще в целом нужно всегда мониторить количество переделок и стремиться к тому что переделок не было то есть это идеально и сам последний вопрос а используете ли какую-то метрику Возможно ли она вообще, с которой вы можете определить, насколько готов агент к работе в PROD? Есть ли какие-то подходы? Есть разного рода метрики. Есть полуавтоматические, когда сверяют ответ с неким эталонным ответом на некотором gold set задач. Не всегда он хорошо работает. Всегда можно посчитать соответствие между талоном и ответом, но это подходит только до каких-то очень простых задач. Если вы используете какие-то не очень умные модели, то можно прогонять через умные модели и сравнивать ответ. Как другой вариант контроля качества, тоже такой, не самый классный. И часто самый классный прогон... Это через человека, когда человек просто проверяет на каком-то заданном списке задач, специально сделанном, проверяет, что модель справилась хорошо или плохо. Ну, вся система справилась хорошо или плохо. Это, конечно, и самая идеальная, но при этом самая дорогая проверка, которую периодически все равно надо делать. Вот. Просто... Ну, то есть нужно понять, сколько у тебя должно быть задач, их должно быть не так мало, нужно... Прямо на это выделять время, это не очень просто. Но вот такие базовые проверки, когда проверять ответ другой более умной моделью или сравнивать с эталоном, спрашивать, как ты считаешь, это похоже или нет, вот такое можно делать. Но да, системы сложные, поэтому суперсложную систему можно проверить только человеком пока. По-другому никак. Да, огонь. Коллеги, простите, про роль системных аналитиков тут разгонять не будем, потому что у нас немножко другая тема. Сергей, спасибо огромное. Прям было мега интересно. Я думаю, там и по вопросам можно было бы бесконечно обсуждать. На любимый вопрос, будет ли видео, видео будет. Подписывайтесь на канал NextWave в телеге, на канал в YouTube. У вас будут все анонсы, будут все видосы. Ну и лайков поставьте, если понравилось. Спасибо. Спасибо еще раз. Всем спасибо. Встретимся в следующий раз. Пока.

Введение в AI-агентов
— Что такое AI-агенты и их роль в современных системах
— Почему агенты становятся ключевым элементом цифровой трансформации

Карта паттернов проектирования агентов
— Базовые паттерны исполнения: как агент планирует и выполняет задачи
— Когнитивные расширения: механизмы обучения, рассуждений и адаптации
— Паттерны взаимодействия: работа с пользователями, знаниями и другими агентами
— Продвинутые архитектуры: создание масштабируемых, безопасных и исследовательских систем

Спикер: Сергей Поляшов — Principal Engineering Manager в Microsoft, обладает глубоким опытом в проектировании масштабируемых и интеллектуальных систем.