dmitry prikotov
Примечание: Изначально опубликовано в BigDataWire.
ИИ-агенты готовы преобразовать корпоративные операции, обеспечивая автономное решение задач, адаптивные рабочие процессы и масштабируемость. Однако главная сложность заключается не в создании более совершенных моделей.
Агенты нуждаются в доступе к данным, инструментам и возможностях обмена информацией между системами, причем их результаты должны быть доступны для использования множеством сервисов, включая других агентов. Это не проблема ИИ — это проблема инфраструктуры и совместимости данных. Здесь недостаточно просто связывать команды в последовательности; необходима событийно-управляемая архитектура (Event-Driven Architecture - EDA), основанная на потоках данных.
Как отметил технический директор HubSpot Дармеш Шах: «Агенты — это новые приложения». Чтобы реализовать этот потенциал, необходимо изначально заложить правильные архитектурные принципы. В этой статье рассматривается, почему EDA является ключом к масштабированию агентов и раскрытию их полного потенциала в современных корпоративных системах.
Чтобы по-настоящему понять, почему EDA необходима для следующего этапа развития ИИ, сначала нужно рассмотреть, как искусственный интеллект эволюционировал до текущего состояния.
Эволюция ИИ
ИИ прошел через два чётко выраженных этапа и сейчас вступает в третий. Первые две волны открыли новые возможности, но также столкнулись с серьёзными ограничениями.
Первая волна ИИ: предсказательные модели
Первая волна ИИ была сосредоточена на традиционном машинном обучении и предсказательных возможностях для узкоопределённых задач.
Традиционный рабочий процесс машинного обучения
Создание таких моделей требовало значительной экспертности, поскольку они разрабатывались специально для конкретных случаев использования. Эти модели были узкоспециализированными, а их привязка к определённой области закладывалась в обучающие данные, что делало их жёсткими и сложными для адаптации. Перенос модели в новую область зачастую означал необходимость начинать разработку с нуля — подход, который не масштабировался и замедлял внедрение.
Вторая волна ИИ: Генеративные модели
Генеративный ИИ, основанный на глубоком обучении, стал переломным моментом.
Вместо того чтобы быть ограниченными одной предметной областью, генеративные модели обучались на огромных и разнообразных наборах данных, что позволило им обобщать знания и применять их в различных контекстах. Они могли генерировать текст, изображения и даже видео, открывая новые, перспективные приложения. Однако у этой волны также были свои вызовы.
Генеративные модели статичны во времени — они не могут интегрировать новую или динамическую информацию — и их сложно адаптировать. Дообучение (fine-tuning) помогает учитывать специфику конкретной области, но этот процесс дорогостоящий и подвержен ошибкам. Он требует огромных объёмов данных, значительных вычислительных ресурсов и глубокой экспертизы в машинном обучении, что делает его непрактичным во многих случаях.
Кроме того, поскольку большие языковые модели (LLM) обучаются на общедоступных данных, у них нет доступа к специализированной информации, что ограничивает их способность точно отвечать на вопросы, требующие контекста.
Например, представьте, что вы просите генеративную модель порекомендовать страховой полис с учётом личной истории здоровья пользователя, его местоположения и финансовых целей.
Простой запрос и ответ с LLM
В этом сценарии вы отправляете запрос (prompt) в LLM, и она генерирует ответ. Очевидно, что модель не может предоставить точные рекомендации, так как у неё нет доступа к соответствующим пользовательским данным. Без этой информации её ответ будет либо слишком обобщённым, либо попросту неверным.
Композитный ИИ устраняет этот разрыв
Чтобы преодолеть эти ограничения, системы композитные ИИ (Compound AI) объединяют генеративные модели с дополнительными компонентами, такими как программная логика, механизмы извлечения данных и уровни валидации. Такая модульная архитектура позволяет ИИ использовать внешние инструменты, запрашивать актуальные данные и адаптировать результаты — то, чего статичные модели делать не могут.
Рассмотрим пример рекомендации страхового полиса:
- Механизм извлечения данных получает информацию о здоровье и финансах пользователя из защищённой базы данных.
- Эти данные добавляются в контекст, передаваемый LLM при формировании запроса.
- LLM использует этот расширенный контекст для генерации точного и персонализированного ответа.
Простая архитектура RAG
Этот процесс, известный как генерация с дополнением извлечённых данных (Retrieval-Augmented Generation, RAG), устраняет разрыв между статичным ИИ и реальными потребностями, динамически интегрируя актуальные данные в рабочий процесс модели.
Хотя RAG эффективно справляется с подобными задачами, он опирается на жёстко заданные рабочие процессы, что означает, что каждый этап взаимодействия и выполнения должен быть заранее определён. Такая предопределённость делает его непригодным для более сложных и динамических задач, где невозможно заранее прописать все возможные сценарии выполнения. Попытка вручную закодировать все возможные пути выполнения требует огромных затрат и в конечном итоге ограничивает гибкость системы.
Ограничения архитектур с фиксированными потоками привели к появлению третьей волны ИИ: агентных систем.
Подъём агентного ИИ
Несмотря на значительный прогресс в развитии ИИ, мы столкнулись с пределами фиксированных систем, включая даже передовые LLM.
Согласно сообщениям, Google Gemini не оправдывает внутренних ожиданий, несмотря на обучение на гораздо большем объёме данных. Подобные проблемы были замечены и у OpenAI с их моделью следующего поколения Orion.
Генеральный директор Salesforce Марк Бениофф недавно заявил в подкасте The Wall Street Journal «Будущее всего» (Future of Everything), что возможности LLM достигли своего предела. По его мнению, будущее — за автономными агентами, системами, которые способны думать, адаптироваться и действовать самостоятельно, а не просто обрабатывать текст, как это делают модели вроде GPT-4.
Ключевое преимущество агентных систем — динамичность. В отличие от фиксированных сценариев, агенты способны самостоятельно определять следующие шаги на лету, адаптируясь к ситуации. Это делает их идеальными для решения сложных, непредсказуемых и взаимосвязанных задач, с которыми ежедневно сталкиваются современные компании.
Логика управления: программный vs. агентный подход
Агенты коренным образом меняют традиционную логику управления.
Вместо жёстко заданных программ, предписывающих каждый шаг, агенты используют LLM для принятия решений. Они способны рассуждать, задействовать инструменты и обращаться к памяти — всё это в динамическом режиме. Такая гибкость позволяет создавать рабочие процессы, которые эволюционируют в реальном времени, делая агентов гораздо более мощными, чем любые системы, основанные на фиксированной логике.
Архитектура агента (вдохновлено arXiv)
Как паттерны проектирования делают агентов умнее
ИИ-агенты получают свою силу не только за счёт базовых возможностей, но и благодаря паттернам проектирования, которые структурируют их рабочие процессы и взаимодействия. Эти паттерны позволяют агентам решать сложные задачи, адаптироваться к изменениям в среде и эффективно взаимодействовать.
Давайте рассмотрим некоторые ключевые паттерны проектирования, которые позволяют агентам работать более эффективно.
Рефлексия: совершенствование через самооценку
Рефлексия позволяет агентам анализировать собственные решения и улучшать их, прежде чем выполнить действие или предоставить окончательный ответ. Эта способность помогает агентам обнаруживать и исправлять ошибки, уточнять логику рассуждений и добиваться более качественных результатов.
Паттерн рефлексии в проектировании агентов
Использование инструментов расширяет возможности агентов
Интеграция с внешними инструментами расширяет функциональность агентов, позволяя им выполнять такие задачи, как извлечение данных, автоматизация процессов и выполнение детерминированных рабочих сценариев. Это особенно важно для операций, требующих строгой точности, таких как математические вычисления или запросы к базам данных, где ошибки недопустимы.
Использование инструментов устраняет разрыв между гибкостью принятия решений и предсказуемым, надёжным выполнением задач.
Паттерн проектирования использования инструментов для агентов
Планирование превращает цели в действия
Агенты с возможностью планирования могут разбивать высокоуровневые цели на конкретные шаги, выстраивая задачи в логически упорядоченную последовательность. Этот паттерн проектирования особенно важен при решении многошаговых задач и управлении рабочими процессами с зависимостями.
Паттерн проектирования планирования для агентов
Многоагентное сотрудничество: модульное мышление
Многоагентные системы применяют модульный подход, разрабатывая решения путем разделения сложных задач на более мелкие, специализированные подзадачи. В таких системах агенты обладают чётко определёнными ролями, что позволяет им эффективно взаимодействовать и адаптироваться к изменяющимся условиям.
Этот подход обеспечивает гибкость: вместо использования одной громоздкой модели можно задействовать малые языковые модели (SLM) для агентов, отвечающих за узкоспециализированные задачи. Это повышает эффективность, снижает нагрузку на вычислительные ресурсы и упрощает управление памятью. Благодаря разделению ролей каждый агент фокусируется только на своей области, а не пытается решать всё сразу.
Схожий принцип применяется в методе смеси экспертов (Mixture-of-Experts, MoE), где задачи распределяются между специализированными подмоделями ("экспертами") внутри одной системы. Как и в многоагентных системах, MoE динамически направляет задачи наиболее подходящему эксперту, оптимизируя вычислительные ресурсы и повышая точность решений.
Как и в традиционном проектировании систем, разбиение сложных задач на модули делает их более управляемыми, масштабируемыми и адаптивными. Многоагентные системы позволяют различным агентам обмениваться знаниями, координировать действия и эффективно решать комплексные задачи.
Паттерн проектирования многоагентного сотрудничества
В кратце, aгенты не просто выполняют рабочие процессы — они меняют сам наш подход к ним. Это следующий шаг в создании масштабируемых и адаптивных ИИ-систем, способных выйти за рамки ограничений традиционных архитектур и современных LLM.
Агентный RAG: адаптивный и контекстно-ориентированный поиск
Агентный RAG (Agentic RAG) развивает концепцию RAG, делая его более динамичным и управляемым контекстом. Вместо того чтобы полагаться на фиксированные рабочие процессы, агенты могут в реальном времени определять, какие данные им нужны, где их найти и как уточнить запросы в зависимости от поставленной задачи.
Эта гибкость делает агентный RAG идеальным решением для сложных многошаговых рабочих процессов, которые требуют отзывчивости и адаптивности.
Например, агент, разрабатывающий маркетинговую стратегию, может:
- Извлекать данные о клиентах из CRM.
- Использовать API для получения актуальных рыночных трендов.
- Корректировать стратегию по мере поступления новой информации.
Благодаря памяти и итеративному уточнению запросов агент формирует более точные и релевантные результаты. Агентный RAG объединяет три ключевых элемента: извлечение данных, рассуждение и действие.
Паттерн проектирования агентного RAG
Проблемы масштабирования интеллектуальных агентов
Масштабирование агентов — будь то отдельный агент или система взаимодействующих агентов — зависит от их способности беспрепятственно получать и обмениваться данными. Для принятия решений и выполнения действий агенты должны собирать информацию из множества источников, включая других агентов, инструменты и внешние системы.
Зависимости одиночного агента
Обеспечение доступа агентов к необходимым инструментам и данным по своей сути является задачей проектирования распределённых систем. Эта сложность напоминает вызовы, возникающие при создании микросервисов, где компоненты должны эффективно взаимодействовать, избегая узких мест и жёстких зависимостей.
Как и микросервисы, агенты должны эффективно обмениваться данными и делать их полезными для всей системы в целом. Однако их вывод не должен замыкаться только на ИИ-приложении — он должен направляться в другие ключевые системы, такие как хранилища данных, CRM, CDP и платформы управления клиентским успехом.
Конечно можно связать агентов и инструменты через RPC или API, но это приведёт к жёстко связанным системам, что усложняет масштабирование, адаптацию и поддержку нескольких потребителей одних и тех же данных.
Агенты требуют гибкости. Их выводы должны бесшовно передаваться другим агентам, сервисам и платформам без создания жёстких зависимостей.
Какое решение?
Слабая связность через событийно-ориентированную архитектуру. Эта архитектура позволяет агентам обмениваться информацией, действовать в реальном времени и интегрироваться с более широкой экосистемой, избегая проблем жёсткой связности.
Основы событийно-управляемых архитектур
Раньше программные системы были монолитными. Весь код находился в единой, жёстко интегрированной кодовой базе. Это упрощало разработку на начальном этапе, но по мере роста монолиты становились всё более сложными в управлении и масштабировании.
Масштабирование таких систем было неэффективным: приходилось увеличивать ресурсы для всей системы, даже если этого требовала лишь одна её часть. Это приводило к раздуванию кода и хрупким архитектурам, неспособным адаптироваться к росту.
Микросервисы решали эту проблему.
Разделяя приложения на мелкие, независимо развертываемые компоненты, команды получили возможность масштабировать и обновлять отдельные части системы, не затрагивая её целиком. Но это привело к новой проблеме: как все эти небольшие сервисы должны эффективно взаимодействовать?
Если соединять микросервисы прямыми RPC- или API-вызовами, создаётся хаос взаимозависимостей. В такой архитектуре отказ одного сервиса может парализовать всю систему.
Жёстко связанные микросервисы
EDA решает проблему.
Вместо жёстко связанных и синхронных взаимодействий событийно-ориентированная архитектура (EDA) позволяет компонентам обмениваться данными асинхронно через события. Сервисы не ожидают выполнения друг друга, а реагируют на события в реальном времени.
Событийно-ориентированная архитектура
Этот подход сделал системы более устойчивыми и адаптивными, позволяя им справляться со сложностью современных рабочих процессов. Это было не просто техническим прорывом — это стало стратегией выживания для систем, работающих под высокой нагрузкой.
Взлёт и падение первых социальных гигантов
История взлёта и падения ранних социальных сетей, таких как Friendster, подчёркивает важность масштабируемой архитектуры. Friendster сумела быстро привлечь огромную аудиторию, но её инфраструктура не выдержала нагрузки. Проблемы с производительностью отпугнули пользователей, и в итоге платформа провалилась.
В то же время Facebook добился успеха не только благодаря своим возможностям, но и потому, что инвестировал в масштабируемую инфраструктуру. Он не рухнул под тяжестью собственного роста — он использовал его как трамплин для доминирования.
Сегодня мы рискуем увидеть повторение этой истории с ИИ-агентами.
Как и ранние социальные сети, агенты столкнутся с быстрым ростом и массовым внедрением. Но просто создать агентов недостаточно. Главный вопрос — сможет ли ваша архитектура справиться со сложностью распределённых данных, интеграцией инструментов и многоагентным взаимодействием.
Без надёжного фундамента экосистема агентов может развалиться так же, как это произошло с первыми социальными платформами, которые не выдержали нагрузки.
Будущее — за событийно-управляемыми агентами
Будущее ИИ — это не просто создание более умных агентов, а разработка систем, способных эволюционировать и масштабироваться по мере развития технологий.
Поскольку ИИ-стек и базовые модели меняются стремительно, жёсткие архитектуры быстро становятся барьером для инноваций.
Чтобы не отставать, нам нужны архитектуры, ориентированные на гибкость, адаптивность и бесшовную интеграцию.
EDA (событийно-ориентированная архитектура) — это основа такого будущего, обеспечивающая агентам возможность развиваться в динамичных средах, оставаясь при этом устойчивыми и масштабируемыми.
Агенты как микросервисы с информационными зависимостями
Агенты похожи на микросервисы: они автономны, слабо связаны и способны выполнять задачи независимо. Но они идут дальше.
Если микросервисы обычно обрабатывают отдельные операции, то агенты используют общий контекст для рассуждений, принятия решений и взаимодействия. Это создаёт уникальные требования к управлению зависимостями и обеспечению непрерывного потока данных в реальном времени.
Например, агент может:
- Извлекать данные о клиентах из CRM,
- Анализировать актуальную аналитику,
- Использовать внешние инструменты,
- Обмениваться обновлениями с другими агентами.
Эти взаимодействия требуют системы, где агенты работают независимо, но при этом беспрепятственно обмениваются критически важной информацией.
EDA решает эту задачу, выступая в роли "центральной нервной системы" для данных. Она позволяет агентам асинхронно передавать события, обеспечивая динамический поток информации без создания жёстких зависимостей.
Такое разделение связей даёт агентам автономность и при этом позволяет органично встраиваться в более крупные рабочие процессы и системы.
Событийно-ориентированная архитектура для ИИ-агентов
Разделение компонентов без потери контекста
Создание гибких систем не означает жертву контекстом. Традиционные жёстко связанные архитектуры часто привязывают рабочие процессы к конкретным конвейерам или технологиям, создавая узкие места и зависимые компоненты. Любое изменение в одной части стека вызывает эффект домино, замедляя инновации и ограничивая масштабируемость.
EDA устраняет эти ограничения. Благодаря разделению рабочих процессов и асинхронному взаимодействию, EDA позволяет различным компонентам стека — агентам, источникам данных, инструментам и прикладным слоям — работать независимо.
Рассмотрим, например, современный ИИ-стек.
- Команды MLOps управляют конвейерами, такими как RAG.
- Дата-сайентисты выбирают модели.
- Разработчики создают пользовательский интерфейс и бэкенд.
Жёстко связанная архитектура заставляет все эти команды зависеть друг от друга, замедляя поставку решений и затрудняя адаптацию к новым инструментам и методам.
В событийно-управляемой системе (EDA) рабочие процессы остаются слабо связанными, что позволяет каждой команде внедрять инновации независимо.
Прикладные слои не обязаны понимать внутреннее устройство ИИ — они просто получают результаты тогда, когда это необходимо. Такое разделение также гарантирует, что инсайты ИИ не остаются изолированными. Выводы агентов легко интегрируются в CRM, CDP, инструменты аналитики и другие системы, создавая единую, адаптивную экосистему.
Масштабирование агентов с событийно-управляемой архитектурой
EDA — это основа перехода к агентным системам.
Её способность разделять рабочие процессы при сохранении коммуникации в реальном времени обеспечивает эффективную работу агентов в масштабируемых системах.
Как обсуждалось ранее, платформы, такие как Kafka, демонстрируют преимущества EDA в агентно-управляемых системах:
- Горизонтальное масштабирование – распределённая архитектура Kafka позволяет добавлять новых агентов и потребителей без узких мест, обеспечивая плавное расширение системы.
- Низкая задержка – обработка событий в реальном времени позволяет агентам моментально реагировать на изменения, создавая быстрые и надёжные рабочие процессы.
- Слабая связность – агенты взаимодействуют через Kafka-топики, а не через прямые зависимости, что делает их автономными и легко масштабируемыми.
- Сохранение событий – надёжное хранилище сообщений гарантирует, что данные не теряются при передаче, что критично для высоконадежных рабочих процессов.
Агенты как производители и потребители событий на платформе потоковой обработки в реальном времени
Потоковая обработка данных обеспечивает непрерывный поток информации внутри компании. Центральная нервная система играет роль единого каркаса для потоков данных в реальном времени, бесшовно связывая разрозненные системы, приложения и источники данных. Это позволяет агентам эффективно взаимодействовать и принимать решения на основе актуальной информации.
Эта архитектура органично сочетается с такими фреймворками, как Model Context Protocol (MCP) от Anthropic.
MCP предоставляет универсальный стандарт для интеграции ИИ-систем с внешними инструментами, источниками данных и приложениями, обеспечивая безопасный и бесшовный доступ к актуальной информации. Упрощая соединение между компонентами, MCP снижает затраты на разработку и повышает эффективность принятия решений, основанных на контексте.
EDA решает многие задачи, на которые ориентирован MCP.
MCP требует гибкого доступа к разнообразным источникам данных, мгновенной реакции в реальном времени и масштабируемости, чтобы поддерживать сложные многоагентные рабочие процессы.
EDA упрощает интеграцию, устраняя жесткие зависимости между системами и обеспечивая асинхронное взаимодействие. Это позволяет агентам генерировать и обрабатывать события без ограничений, вызванных жесткими зависимостями.
Событийно-управляемые агенты определят будущее ИИ
Ландшафт ИИ стремительно развивается, и архитектуры должны эволюционировать вместе с ним.
Бизнес уже готов. Опрос Forum Ventures показал, что 48% ИТ-лидеров готовы внедрять ИИ-агентов в свои бизнес-процессы, а 33% заявили, что уже активно к этому готовятся. Это сигнал о высоком спросе на масштабируемые системы, способные справляться со сложностью ИИ-интеграций.
EDA — ключ к созданию агентных систем, которые будут гибкими, устойчивыми и масштабируемыми.
- Она разделяет компоненты,
- позволяет работать в реальном времени,
- обеспечивает бесшовную интеграцию агентов в экосистему бизнеса.
Те, кто примут EDA, не просто выживут, а получат конкурентное преимущество в новой волне ИИ-инноваций. А остальные? Они рискуют остаться позади, потерпев поражение из-за неспособности масштабироваться.
Этот текст является переводом статьи: The Future of AI Agents is Event-Driven
