Центральный сервис для подключения ИИ-агентов к нашим сайтам. Хранит сайты, агентов и диалоги, обеспечивает общение посетителей с агентом и возможность участия менеджера. Дополнительно принимает сырые события с сайтов для последующего анализа агентами.

Единый сервис ИИ-агентов и диалогов для наших сайтов.

Центр ИИ-агентов

Реализовать базовые сущности и API центрального сервиса: наши сайты, связанные с ними агенты, диалоги и сообщения. Агент сайта должен работать через этот сервис, а не как отдельная независимая система.

Центральное хранение сайтов, агентов, диалогов и сообщений.

Сделать ядро сервиса агентов и диалогов

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

Сделать простой способ подключения наших сайтов к центральному сервису.

Подключить ИИ-агента к сайтам

Сделать интерфейс, где можно видеть активные и прошлые диалоги посетителей с агентом. Менеджер должен иметь возможность остановить автоматические ответы, продолжить разговор самостоятельно и затем вернуть управление агенту.

Личный кабинет для просмотра диалогов и участия человека.

Сделать управление диалогами и перехват менеджером

Хранить список наших подключённых сайтов, их агентов и основной контекст. Нужна возможность центральному агенту понимать, какие сайты и агенты существуют, и обращаться к нужному агенту.

Единый внутренний каталог подключённых сайтов и их агентов.

Добавить каталог сайтов и агентов

Добавить простой API приёма сырых событий с наших сайтов: посещения страниц, сессии, действия пользователя и события диалогов. Данные сохранять для последующего анализа ИИ-агентами; отдельную классическую систему аналитики сейчас не строить.

Принимать события посещений и действий без построения отдельной системы аналитики.

Собирать сырые события с сайтов

# Реализовать собственное ядро ИИ-диалогов с динамическими сценариями

## Контекст
Проект «Центр ИИ-агентов» должен иметь собственную диалоговую часть. Нельзя строить её на n8n, Make, готовых chatbot/workflow-конструкторах или аналогичных системах, где основная логика диалога исполняется внешним движком.

Нужно реализовать своё ядро, которое принимает извне описание комплексного сценария, ведёт пользователя по нему динамически и возвращает результат. Каждый пользовательский диалог должен существовать и рассчитываться как отдельная независимая сущность со своим состоянием, историей и результатом.

## Цель
Создать универсальный сервис исполнения ИИ-диалогов, который можно использовать разными сайтами и агентами, не зашивая конкретный сценарий в код приложения.

Сервис должен уметь:
- принять сценарий диалога извне;
- создать отдельную сессию/диалог для конкретного пользователя;
- на каждом сообщении определить следующий шаг динамически, исходя из сценария, накопленного состояния и ответа пользователя;
- обращаться к LLM там, где это предусмотрено логикой;
- сохранять состояние и историю диалога;
- завершать диалог с формализованным результатом;
- параллельно обслуживать много пользователей и много независимых диалогов.

## Ключевой архитектурный принцип
**Сценарий — это данные, а не код конкретного чата.**

Диалоговый движок должен быть универсальным. Внешняя система передаёт ему декларативное описание сценария, а runtime интерпретирует его и управляет переходами.

Не должно требоваться программировать новый backend-flow под каждый новый сценарий.

## Что реализовать

### 1. Модель сценария
Спроектировать формат сценария, который можно передавать через API и хранить версионно.

Минимально предусмотреть:
- идентификатор и версию сценария;
- стартовую точку;
- шаги/узлы;
- системные инструкции для LLM;
- ожидаемые пользовательские данные;
- условия и ветвления;
- переходы между шагами;
- промежуточные переменные/контекст;
- вычисляемые значения;
- действия до/после шага;
- условия завершения;
- схему итогового результата.

Сценарий должен поддерживать не только линейную цепочку вопросов, но и динамические ветвления.

### 2. Runtime диалога
Реализовать собственную машину исполнения сценария.

На каждом входящем сообщении runtime должен:
1. загрузить состояние конкретного диалога;
2. определить текущий узел сценария;
3. обработать вход пользователя;
4. при необходимости вызвать LLM;
5. валидировать/нормализовать полученные данные;
6. вычислить условия перехода;
7. обновить состояние;
8. сформировать следующий ответ;
9. сохранить историю и новое состояние атомарно;
10. вернуть наружу ответ и техническое состояние выполнения.

Логика переходов должна исполняться внутри нашего сервиса, а не внутри внешнего workflow-движка.

### 3. Состояние диалога
Каждый диалог хранить отдельно.

Нужно предусмотреть как минимум:
- `dialogId`;
- tenant/site/agent/user identifiers;
- scenarioId + scenarioVersion;
- текущий узел;
- accumulated state / variables;
- историю сообщений;
- результаты LLM-вызовов, необходимые для воспроизводимости;
- статус: active / completed / failed / cancelled;
- timestamps;
- финальный структурированный result.

Один пользователь может иметь несколько независимых диалогов.

### 4. Мультипользовательский режим
Сервис должен корректно работать при параллельных диалогах разных пользователей и сайтов.

Обязательно предусмотреть:
- изоляцию состояния по диалогам;
- отсутствие глобального mutable state между пользователями;
- защиту от одновременной обработки двух сообщений одного диалога;
- идемпотентность повторной доставки сообщения;
- возможность горизонтального масштабирования нескольких экземпляров runtime;
- tenant/site isolation на уровне API и хранения данных.

### 5. Внешний API
Нужен понятный программный контракт для внешних систем.

Минимальный набор операций:
- зарегистрировать/обновить версию сценария;
- создать диалог по сценарию;
- отправить сообщение в конкретный диалог;
- получить текущее состояние/статус;
- получить историю;
- получить финальный результат;
- отменить/закрыть диалог.

Ответ на `sendMessage` должен содержать не только текст для пользователя, но при необходимости и машинно-читаемую часть:
- статус;
- текущий/следующий шаг;
- extracted values;
- result при завершении;
- технические метаданные выполнения.

### 6. Работа с LLM
LLM является частью runtime, но не должна сама быть единственным источником управления потоком.

Нужно разделить:
- детерминированную логику переходов;
- извлечение/классификацию данных через LLM;
- генерацию текста ответа;
- валидацию структурированных ответов модели.

Для структурированных операций использовать schema-constrained output и обязательную валидацию результата модели.

Предусмотреть обработку:
- timeout;
- malformed output;
- retry;
- fallback;
- rate limits;
- ошибок провайдера.

### 7. Версионирование и воспроизводимость
Запущенный диалог должен продолжать исполняться на той версии сценария, на которой был создан, даже если позже опубликована новая версия.

Нельзя менять семантику уже идущего диалога незаметной правкой сценария.

### 8. Наблюдаемость
Для каждого шага сохранять технический trace:
- вход;
- выбранный узел;
- принятое решение;
- переход;
- вызовы модели;
- latency;
- ошибки;
- token/cost usage, если доступно;
- итог шага.

Это должно позволять расследовать, почему конкретный диалог пошёл по определённой ветке.

### 9. Безопасность выполнения сценариев
Внешний сценарий не должен позволять выполнять произвольный код на сервере.

Условия, expressions и действия должны исполняться через ограниченный DSL/набор разрешённых операций.

Нельзя использовать `eval` или произвольный JavaScript из присланного сценария.

## Что не входит в эту задачу
- визуальный конструктор сценариев;
- UI оператора/менеджера;
- виджет чата на конкретном сайте;
- CRM-интеграции как отдельный большой слой;
- аналитическая BI-панель;
- построение workflow на n8n/Make и подобных продуктах.

Эти части могут использовать диалоговый runtime позже, но не должны определять его архитектуру.

## Минимальный проверочный сценарий
Для приёмки реализовать хотя бы один сценарий, который подтверждает динамическую работу движка:
- несколько вопросов;
- минимум одно условное ветвление;
- извлечение структурированного значения через LLM;
- возврат к уточняющему вопросу при недостаточных данных;
- завершение с машинно-читаемым результатом.

Одновременно запустить несколько диалогов по одному сценарию с разными ответами и подтвердить, что состояния и результаты не смешиваются.

## Критерии готовности
- Диалоговый runtime написан нами и не зависит от внешнего workflow-движка.
- Новый сценарий можно передать через внешний контракт без изменения кода runtime.
- Поддерживаются нелинейные ветвления и динамические переходы.
- Каждый диалог имеет независимое персистентное состояние.
- Один пользователь может иметь несколько диалогов, а сервис — одновременно обслуживать множество пользователей/сайтов.
- Есть защита от race conditions и повторной доставки сообщений.
- Версия сценария фиксируется на время жизни диалога.
- Финальный результат доступен в структурированном виде.
- По trace можно понять, как и почему был выполнен каждый шаг.
- Проверочный сценарий проходит end-to-end и подтверждает изоляцию параллельных диалогов.

С нуля реализовать мультипользовательский диалоговый runtime без n8n и подобных workflow-решений, с внешне задаваемыми комплексными сценариями и независимым состоянием каждого диалога.

Реализовать собственное ядро ИИ-диалогов с динамическими сценариями

# Сделать собственный встраиваемый чат-виджет

## Цель
Создать минимальный собственный UI чата, который можно встроить на наши сайты и подключить к уже реализованному серверному HTTP/agent-слою без использования старого интерфейса как постоянного решения.

## Что реализовать
- простой способ подключения виджета к сайту с минимумом ручной настройки;
- отправку пользовательского сообщения в центральный сервис;
- потоковое отображение ответа агента;
- кнопку Stop с реальной отменой текущего выполнения;
- корректное состояние UI для started / streaming / done / error / cancelled;
- базовую передачу идентификатора сайта и контекста страницы;
- определить контракт идентификации посетителя/сессии, не смешивая состояния разных вкладок и пользователей;
- определить CORS и модель доступа к публичному HTTP endpoint для внешнего виджета;
- проверить работу через реальный proxy path, а не только напрямую к приложению.

## Не входит в минимальный этап
- кабинет менеджера;
- полноценная история разговоров в UI;
- сложная аналитика;
- визуальный конструктор агента.

## Критерии готовности
- виджет подключается хотя бы к одному тестовому сайту без использования legacy-чата;
- ответ приходит потоком;
- Stop действительно отменяет серверное выполнение;
- параллельные посетители не смешивают состояние;
- поток и отмена проверены через рабочий Traefik/Varnish/proxy путь;
- контракт подключения документирован так, чтобы следующий сайт можно было добавить без изменения ядра.

Минимальный виджет для подключения к сайтам через центральный агент с потоковым ответом и Stop.

Сделать собственный встраиваемый чат-виджет

# Админка пользователей и управление JWT-токенами

## Контекст
Главная последующая цель — управление JWT-токенами, которые используются для идентификации пользователя, которому адресуется сообщение.

Серверные запросы для работы с пользователями уже существуют. В рамках первого этапа backend пользователей не переделывать.

## Первый этап — выполнить сейчас
Сделать админку управления пользователями:

- список пользователей;
- действие «Добавить пользователя»;
- возможность открыть карточку пользователя;
- редактирование пользователя;
- использовать уже существующие GraphQL-запросы и мутации;
- добавить клиентские GraphQL-операции и перегенерировать типы.

## UI-kit
Попутно начать собственный `ui-kit` поверх уже установленного React Aria:

- React Aria использовать как headless-основу;
- каждый необходимый приложению UI-компонент оформлять отдельным компонентом в `ui-kit`;
- для каждого нового компонента сразу добавлять Storybook story;
- в продуктовых экранах использовать компонент из `ui-kit`, а не React Aria напрямую.

## Следующий этап — JWT-токены
После пользовательской админки добавить управление JWT-токенами, предназначенными для идентификации пользователя, которому отправляется сообщение. Не смешивать эту задачу с уже существующей логикой входа и сессий.

## Технические заметки
- Hot reload уже работает, отдельно настраивать его не нужно.
- React Aria уже установлен.
- Backend CRUD пользователей уже есть.

## Критерий первого этапа
Из интерфейса администратор может увидеть пользователей, добавить пользователя, открыть существующего пользователя и изменить его данные. Клиентские GraphQL-операции добавлены, типы успешно перегенерируются, используемые UI-элементы оформлены через `ui-kit` и имеют Storybook stories.

Сделать админку управления пользователями и заложить UI-основу для последующего управления JWT-токенами идентификации пользователей.

Добавить админку управления пользователями и подготовить управление JWT-токенами

Надо отработать механики управления хотя бы несколькими десятками сайтов с помощью ИИ.

Настроить управление множеством сайтов

Надо со всемх сайтов метрики собирать не в сторонние сервисы типа яндекс.метрики и гугл.аналитики, а в свой собственный сервис, который будет хранить информацию в одном месте.&#x20;

Задачи

Настроить аналитику