Представьте: заявка с сайта висит в CRM уже несколько часов. Рекламный бюджет за сутки просел сильнее обычного. Конкурент поменял тариф на самой видной странице. Статья, которая долго приносила трафик, за неделю потеряла заметную часть переходов. Ничего из этого не случилось в чате, и никто не задавал нейросети вопрос про эти проблемы: они просто произошли, а заметил их человек — если вообще заметил.
Вот здесь и проходит граница, которую плохо видно за разговорами про умные модели. Чат-бот запускается вопросом. Бизнес состоит из событий, которые происходят сами и обычно в неудобный момент. Следующий практический шаг — не ещё более умный собеседник, а событийный контур: система следит за изменениями, замечает существенное и запускает ограниченную реакцию. Не потому, что её попросили, а потому что сработало условие.
Чат-бот умеет отвечать, но не умеет замечать первым
Разница простая, хотя её постоянно смазывают. Чат-интерфейс реактивен: пользователь пришёл, сформулировал запрос, получил ответ, ушёл. Даже если модель внутри очень сильная, снаружи она неподвижна, пока к ней не обратятся. Событийную систему приводит в движение изменение состояния — новая заявка, загруженный файл, просевшая метрика, ответ другого сервиса, письмо от клиента.
Тут есть деталь, которую легко потерять: замечает событие не интуиция языковой модели, а инфраструктура. API, вебхуки, датчики, расписания, парсеры и обычные детерминированные правила. В типовой схеме есть источник события, маршрутизатор или очередь, которая фильтрует и направляет поток, и обработчик, который что-то делает с сигналом. Модель подключается позже — чтобы понять контекст, собрать разрозненные данные и предложить осмысленный следующий шаг.
И ещё одно различение, без которого всё смешается. Event-driven архитектура отвечает на вопрос, когда и чем запускается процесс. Агентная — на вопрос, как ИИ выбирает шаги и пользуется инструментами. Это не конкуренты и не синонимы: в рабочей системе они соединяются. Событие поднимает агента, агент разбирается в ситуации и либо действует в разрешённых рамках, либо передаёт решение человеку.
Как выглядит рабочий событийный контур
Если убрать маркетинговый туман, цепочка получается приземлённая. Источник фиксирует событие и публикует его. Дешёвый слой правил и маршрутизации отсекает шум: дубли, технические сбои, изменения в пределах нормы. Только значимый сигнал доходит до ИИ-анализа, и вот здесь начинается дорогая часть — сбор контекста, проверка версий, формулировка гипотезы. Дальше система либо выполняет безопасное действие, либо готовит рекомендацию, а необратимые операции — публикация, письмо клиенту, изменение бюджета, удаление данных — проходят через отдельный слой подтверждения, причём до исполнения, а не после. В хорошо спроектированном контуре история должна попадать в журнал: что заметили, что предложили, что подтвердили, что отменили.
Самое неочевидное здесь — экономика. Always-on не означает круглосуточно дёргать большую модель. Событийный push-контур как раз позволяет обойтись без непрерывного опроса всех систем: дешёвый фильтр работает постоянно, дорогой анализ запускается только при превышении порога. Но расходы не исчезают, они меняют форму. Хранение событий, интеграции, повторные попытки, вызовы инструментов, поддержка — всё это стоит денег и растёт вместе с числом событий. OWASP в чек-листе по безопасности агентных систем отдельно советует ограничивать токены, стоимость, количество повторов и длину цепочек инструментов. Это не бюрократия, а способ не обнаружить счёт за месяц сюрпризом.
Где это уже просится в работу
Реклама. Самый честный пример — не футуристический агент, а обычный детектор аномалий в Google Ads. Он сравнивает текущие показатели аккаунта с историей тех же дней недели и присылает предупреждение при существенном отклонении. Запускать его предлагают ежечасно, но в документации прямо оговаривают: если уведомлений слишком много, частоту можно снизить до раза в день. Вот он, будущий контур в зачаточном виде — наблюдение, отклонение, уведомление. Следующий шаг уже архитектурный: отдать событие специализированному агенту, чтобы тот посмотрел разбивку по кампаниям, устройствам и источникам, сформулировал вероятные причины и предложил действие. Менять бюджет автоматически — только в заранее заданных пределах или после подтверждения.
Лиды. Пока проектная схема, а не готовая функция конкретного сервиса. Форма или CRM публикует событие о новой заявке. Правила проверяют дубль, источник, давность и наличие согласия на коммуникацию. Дальше ИИ готовит сводку по клиенту и черновик ответа. Внутренние безопасные операции — сменить статус, поставить напоминание — можно делать автоматически, а отправить сообщение, пообещать скидку или изменить условия должен человек. Разница между «подготовил» и «отправил» здесь стоит дороже, чем кажется.
Контент. Событие: трафик статьи выпал из обычного диапазона, материал устарел, в первичном источнике изменились данные. Система определяет, какие страницы и запросы затронуты, проверяет вероятные причины, готовит редакционный бриф и предлагает обновлённые фрагменты. Публикация и удаление остаются за редактором — особенно если анализ опирается на внешние страницы, качество которых никто не гарантировал.
Конкуренты. На сайте конкурента поменялись тариф или продуктовая страница. Правильная реакция скучная и техническая: сохранить снимок, показать разницу версий, отделить наблюдаемый факт от интерпретации, проверить по дополнительным источникам, отправить уведомление с уровнем уверенности. И не позволять тексту чужой страницы напрямую управлять инструментами агента. Внешний контент следует считать недоверенным, когда он может управлять действиями агента: в нём может лежать аккуратно сформулированная инструкция, рассчитанная на то, что её прочитает модель.
Почему «само реагирует» — не то же самое, что «само решает»
Соблазн продать автономность целиком понятен, но именно здесь начинаются настоящие проблемы. Первая — ложные тревоги. Если система пишет по любому поводу, человек перестаёт читать её сообщения вместе с теми, которые действительно важны. У Google в книге про надёжность систем это сказано прямо: отправлять стоит только срочные и практически применимые оповещения, иначе наступает усталость от алертов. Значит, нужны пороги, историческая база и настройка отношения сигнала к шуму. Не каждое событие заслуживает уведомления, тем более действия.
Вторая — права доступа. Полномочия агента должны быть уже его аналитических способностей, а не шире: минимальные права, разделение чтения и записи, работа в контексте конкретного пользователя, проверка разрешений в целевой системе. Фраза «модель решила, что ей можно» — это не авторизация, а описание инцидента. В реестре рисков OWASP избыточные функции, разрешения и автономность так и называются — excessive agency.
Третья — подтверждение. Оно отделяет решение от исполнения технически, но преувеличивать его надёжность не стоит. Человек может машинально жать «да» на всё подряд или получить неполный, а то и подталкивающий к нужному выводу контекст. Подтверждение снижает риск, а не отменяет его.
Четвёртая — аудит. После запуска надо измерять не красоту модели, а пользу системы: сколько тревог оказалось ложными, как часто человек отменял рекомендацию, где возникли эскалации. NIST в практическом руководстве по управлению рисками ИИ рекомендует вести журналы и фиксировать ошибки, жалобы, эскалации, решения go/no-go и случаи, когда человек отменил рекомендацию модели. Подсчёт действий без подтверждения можно добавить как дополнительную метрику, но это уже выбор команды. Без такой статистики невозможно понять, приносит контур пользу или просто создаёт ощущение контроля.
Что уже работает, а что пока схема на бумаге
Границу стоит держать жёстко. Детектор аномалий в рекламе — подтверждённый работающий предшественник. Сценарии с лидами, контентом и мониторингом конкурентов — нормальные проектные схемы, которые собираются из существующих частей, но в рамках описанного сценария это именно проектные схемы, а не подтверждённые готовые функции конкретного сервиса. Универсальный автономный наблюдатель за бизнесом — архитектурное направление, а не готовая функция с кнопкой «включить».
Отдельно про путаницу в терминах. Скрипт, который раз в час проверяет цену и пишет в чат, — ещё не агент. Периодическая задача, детерминированное правило и агент с выбором инструментов — разные уровни системы, и называть их одним словом значит обманывать себя в оценке сложности. И «реальное время» почти всегда идёт с оговоркой: очереди, задержки источников, пакетная статистика и лимиты API спокойно превращают «мгновенно» в «через полчаса».
Зачем это собирать руками
Событийный контур — редкий случай, когда тема выглядит абстрактной только на слайдах. В работе это набор очень конкретных решений: какие источники событий существуют, что считать значимым изменением, где поставить порог, какие действия разрешить без человека, что писать в журнал, сколько это будет стоить при десятикратном росте событий. Красивые демо ломаются именно на этом, а не на качестве промпта.
Поэтому такие вещи полезнее разбирать и собирать вживую, а не обсуждать в формате прогнозов. Для этого есть GPT-Лаборатория — там как раз про практическую работу с агентными системами, разбор архитектуры и кейсов: https://t.me/jopotology. Если тема цепляет, логичнее продолжить её в практическом разборе, а не только на слайдах.
Рядом стоит упомянуть Market GPT (https://market-gpt.ru/), но с честной оговоркой. На публичной странице заявлены связанный маршрут от анализа аудитории и рекламы до лендинга, заявок, ИИ-продавца, статусов и контроля лидов. Направление развития понятное, и слой постоянного наблюдения выглядит там логичным следующим шагом. Но выдавать его за готовую систему, которая сама следит за всеми бизнес-событиями, не стоит — публично это не подтверждено.
Одним из главных практических сдвигов ближайшего времени может стать не качество диалога с моделью, а момент, когда система научится замечать событие без напоминания и действовать в заранее очерченных рамках. Чем аккуратнее заданы полномочия, пороги и точки подтверждения, тем полезнее окажется такой контур. «Само реагирует» — не синоним «само решает», и вся разница между помощником и источником новых проблем держится именно на этом.
