eMarketing AI изнутри: супервайзер и команда агентов-специалистов

В обзорной статье мы уже рассказывали, что умеет eMarketing AI: пишет посты, статьи, письма и лендинги, ведёт кампании, рассылки и аналитику — и всё это в одном окне. Это был взгляд со стороны пользователя. Теперь зайдём со стороны реализации и разберём, как здесь устроен искусственный интеллект.

Маркетинг — это много непохожей работы: написать пост в соцсеть, собрать чек-лист к запуску, провести SEO-аудит, свести отчёт по реальным цифрам. Одна «умная» кнопка на всё сразу обычно получается посредственной в каждом из дел. Поэтому внутри eMarketing AI не один универсальный бот, а команда узких специалистов под управлением супервайзера — и вокруг них та самая инженерная дисциплина, ради которой всё и затевалось: реальные данные проекта вместо выдумок, учёт стоимости на каждый запуск и один аккуратно настроенный под задачу движок.

Одна мысль проходит через весь текст: ценность здесь не в размере модели, а в том, как организована работа вокруг неё. Пройдём по порядку — от общей карты системы до того, какая модель за какую задачу отвечает.

Как устроена система целиком

Прежде чем нырять в детали, полезно увидеть карту. Вся «умная» часть вынесена в отдельный сервис: он живёт рядом с основным приложением, но запускается независимо. Панель маркетолога не дёргает модель напрямую: она создаёт запись о запуске (что нужно сделать и для какого проекта), кладёт задание в очередь — и освобождает пользователя. Дальше задание подхватывает ИИ-сервис.

flowchart TB
  subgraph Client["Как приходит задача"]
    UI["Веб-панель маркетолога"]
    CRON["Расписание (cron)"]
  end
  subgraph App["Основное приложение"]
    API["Сервер (API)<br/>создаёт запись о запуске"]
    Q["Очередь заданий<br/>(на Redis)"]
  end
  subgraph AI["ИИ-сервис (отдельный)"]
    SUP["Супервайзер<br/>(маршрутизатор)"]
    AG["Агенты-специалисты"]
  end
  LLM["OpenAI GPT-4o"]
  DB[("База данных<br/>контент · кампании · метрики")]
  UI --> API
  CRON --> API
  API --> Q
  Q --> SUP
  SUP --> AG
  AG --> LLM
  AG --> DB
  API --> DB

Почему через очередь, а не «в лоб»? Генерация статьи или отчёта занимает десятки секунд — держать всё это время открытое соединение неудобно и ненадёжно. Очередь же даёт три вещи сразу: пользователь не ждёт с крутящимся индикатором, каждый запуск виден и его статус можно отследить, а сами задания легко ставить на повтор и на расписание. К расписанию мы ещё вернёмся.

Супервайзер и команда специалистов

Внутри ИИ-сервиса — не один агент «на все руки». Задачу встречает супервайзер: он смотрит, какого рода работа пришла, и отдаёт её нужному специалисту. Каждый агент — эксперт в одном деле, со своим промптом, своим форматом ответа и своей «температурой» (мерой творческой свободы модели).

flowchart TB
  SUP(["Супервайзер выбирает нужного специалиста"])
  subgraph Team["Команда агентов"]
    direction TB
    C["Контент<br/>посты · статьи · письма · лендинги"]
    CH["Чек-листы<br/>запуск · кампания · SEO"]
    D["Документы<br/>план · отчёт · анализ конкурентов"]
    S["SEO<br/>аудит страницы + разбор выдачи"]
    ST["Стратегия<br/>go-to-market · позиционирование"]
    E["Email<br/>темы · письма · цепочки"]
    A["Аналитика<br/>инсайты по реальным метрикам"]
  end
  CHAT["Чат-ассистент"]
  SUP --> Team
  CHAT -. "поручение" .-> SUP

Команда такая: контент пишет посты, статьи, письма, рассылки, рекламные тексты, лендинги и SEO-статьи; чек-листы собирают подробные списки задач к запуску или кампании; документы готовят маркетинговый план, отчёт, анализ конкурентов или гайдлайны бренда; SEO проводит аудит страницы и разбирает конкурентов в поиске; стратегия отвечает за go-to-market и позиционирование; email — за темы писем с A/B-вариантами и цепочки; аналитика превращает реальные метрики проекта в инсайты.

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

Жизнь одного запуска

Каждая задача в системе — это запуск с понятным жизненным циклом. Сначала запись создаётся в состоянии «ожидает», затем попадает в очередь, оттуда её берёт агент, и в конце результат сохраняется, а запуск помечается как «готово» (или «ошибка», если что-то пошло не так).

stateDiagram-v2
  state "Ожидает" as P
  state "В очереди" as Q
  state "Выполняется" as R
  state "Готово" as D
  state "Ошибка" as F
  [*] --> P: задача создана
  P --> Q: поставлена в очередь
  Q --> R: агент взял в работу
  R --> D: результат сохранён
  R --> F: сбой
  D --> [*]
  F --> [*]
  note right of R
    Замеряются время,
    израсходованные токены
    и стоимость в долларах;
    сохраняется трейс для отладки
  end note

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

Контент-движок: один запрос — три языка

Самый нагруженный специалист — контент-агент. Он умеет девять форматов (от поста в соцсеть до лендинга и SEO-статьи), под выбранную площадку, тон и длину. Но начинает он не с генерации, а с загрузки контекста проекта: голос бренда, аудитория, отрасль. Без этого текст получился бы гладким, но безликим.

flowchart TB
  IN["Запрос: тип · платформа · тема ·<br/>тон · длина · языки"] --> CTX["Загрузить контекст проекта<br/>голос бренда · аудитория · отрасль"]
  CTX --> GEN["Сгенерировать текст<br/>(GPT-4o, температура 0.8)"]
  GEN --> REV["Проверка качества"]
  REV --> SAVE["Сохранить как отдельную запись<br/>с общим ID группы"]
  SAVE --> MORE{"Ещё языки?"}
  MORE -->|да| NEXT["Следующий язык"]
  NEXT --> GEN
  MORE -->|нет| DONE["Готово: по записи на язык,<br/>сгруппированы вместе"]

Отдельного слова заслуживает мультиязычность. Если попросить текст сразу на нескольких языках (например, en, pl, ru), агент не переводит один вариант, а проходит цикл для каждого языка: генерирует, проверяет качество, сохраняет как отдельную запись — и все версии связываются общим идентификатором группы, чтобы в панели они лежали вместе. «Температура» здесь высокая (0.8): контенту нужна доля творчества. Для SEO-статьи агент вдобавок анализирует поисковую выдачу и выдаёт мета-заголовок, описание и slug, а лендинг возвращает уже разложенным на секции.

Ответы на реальных данных, а не на выдуманных цифрах

Тут кроется главное отличие от «умного, но фантазирующего» помощника. Когда речь заходит об отчёте или аналитике, агент опирается не на общие рассуждения, а на реальные данные вашего проекта.

flowchart LR
  Q["Запрос: отчёт<br/>или вопрос по аналитике"] --> AGENT["Агент документов / аналитики"]
  AGENT --> DATA["Только чтение реальных данных проекта<br/>контент · кампании · подписчики ·<br/>соцсети · метрики · чек-листы"]
  DATA --> CHECK{"Данные есть?"}
  CHECK -->|да| ANS["Отчёт и инсайты<br/>на реальных цифрах"]
  CHECK -->|нет| HONEST["«Данных нет» +<br/>что стоит подключить"]

Агент документов для отчёта подгружает фактическое состояние проекта: сколько контента и в каких статусах, какие кампании, сколько подписчиков, какие соцсети подключены, как выполняются чек-листы. И ему прямо предписано пользоваться только реальными данными: если чего-то нет, он так и пишет — «данных нет» — и советует, что стоит подключить, вместо того чтобы дорисовать правдоподобную, но выдуманную метрику. Агент аналитики работает так же: читает метрики и события (только на чтение) и отвечает на свободный вопрос вроде «почему на прошлой неделе просел трафик» человеческим языком.

Чат-ассистент как диспетчер

Чат в панели — это не просто «поговорить о маркетинге». Под капотом это агент, который умеет вызывать инструменты: он либо отвечает текстом, либо, если вы просите что-то сделать, поручает задачу нужному специалисту прямо из разговора.

stateDiagram-v2
  state "Чат" as C
  state Decide <<choice>>
  state "Инструмент" as T
  [*] --> C: сообщение пользователя
  C --> Decide: ответ модели
  Decide --> [*]: ответ текстом (без действия)
  Decide --> T: нужно действие
  T --> C: специалист отработал, есть ссылка
  note right of T
    Из разговора можно поручить
    задачу любому специалисту:
    чек-лист, контент, отчёт, SEO…
  end note

Скажешь «собери чек-лист к запуску продукта» — и чат сам поставит задачу агенту чек-листов, а в ответ пришлёт ссылку на готовый результат. Так одно окно связывает всю команду: не нужно помнить, какой агент за что отвечает, — достаточно объяснить, что нужно. Чат знает контекст проекта, помнит историю разговора и отвечает на трёх языках (английский, польский, русский). «Температура» средняя (0.7) — живо, но по делу.

SEO-аудит и работа по расписанию

Ещё один специалист — SEO-агент, и устроен он как маленький автомат из нескольких шагов: загрузить страницу, провести аудит on-page, разобрать конкурентов в выдаче и выдать приоритезированные рекомендации.

stateDiagram-v2
  state "Загрузка" as S1
  state "Аудит" as S2
  state "Выдача" as S3
  state "Рекомендации" as S4
  [*] --> S1: загрузить страницу
  S1 --> S2: аудит on-page
  S2 --> S3: разбор конкурентов
  S3 --> S4: приоритеты правок
  S4 --> [*]
  note right of S2
    Заголовки, мета-теги,
    плотность ключевых слов
  end note
  note right of S4
    Плюс мета-заголовок, описание
    и slug для новой страницы
  end note

Он не ограничен «знаниями из головы»: агент реально загружает страницу и обращается к живому веб-поиску, поэтому рекомендации опираются на актуальную выдачу, а не на память модели.

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

Одна модель, много специалистов

Важная деталь всей архитектуры: за всем этим стоит одна модель — GPT-4o. Никакого «зоопарка» моделей: один провайдер, один ключ, один движок под все задачи. Меняется не модель, а то, как её настраивают под конкретную работу.

Главный «рычаг» здесь — температура, мера свободы модели. Для чек-листов она низкая (0.3): там нужна дисциплина и предсказуемость. Для документов чуть выше (0.4). Для чата — средняя (0.7). Для контента — высокая (0.8): тут как раз нужна доля творчества. Плюс у каждого агента свой потолок по длине ответа. Одна модель, аккуратно настроенная под задачу, — это проще в поддержке и дешевле в отладке, чем набор разных.

Заключение

Если собрать всё вместе, вырисовывается знакомая мысль: пользу приносит не «модель побольше», а аккуратная инженерия вокруг неё. Команда узких специалистов вместо одного универсала. Реальные данные проекта вместо выдуманных метрик. Очередь и понятный жизненный цикл вместо «нажми и жди». Каждый запуск посчитан в токенах и деньгах. И одна модель, настроенная под каждую задачу отдельно.

Именно эта дисциплина превращает разговорчивую модель в рабочий инструмент для маркетинга, которому можно доверить рутину. Попробовать eMarketing AI можно на eMarketingAI.pl или собрать самому из исходников на GitHub. А если вам нужен похожий набор агентов, встроенный в ваш продукт и ваши данные, — напишите нам: [email protected].

Какая модель за что отвечает

Напоследок — сводка: какая модель решает какую задачу. Здесь она одна на все дела, поэтому в таблице по сути видно другое — под какую работу и с какой «температурой» она настроена.