AI-процессы

Как это работает

Простая идея. Представьте секретаря, который сидит у входа: пришла заявка → за пару секунд понял, что это за запрос (RAG? голосовой бот? спам?), → стукнул в Telegram владельцу с пометкой «вот это, кажется, важное», → записал в журнал что и когда было сделано. AI-процесс — и есть такой автоматический секретарь, только живёт он на VPS и работает 24/7.

1. Форма шлёт заявку на бэкенд (POST /api/agents/flow/intake). Если заполнен скрытый honeypot или с этого IP уже было больше 5 заявок за час — заявка тихо отбрасывается.
2. Заявка падает в таблицу flow_jobs (Postgres) со статусом pending — это и есть очередь, без отдельного Redis или BullMQ.
3. Каждые 2 секунды runner просыпается и берёт батч из 3 заявок (FOR UPDATE SKIP LOCKED, чтобы параллельные тики не задвоили работу).
4. Каждая заявка идёт через шаги: classify (LLM в JSON-mode присваивает категорию + важность + флаг спама) → notify (если не спам — Telegram Bot API шлёт владельцу сообщение со всей карточкой).
5. Каждый шаг пишется в flow_runs и в общий audit.jsonl: статус, latency, модель, ошибка если была. Если шаг упал retryable-ошибкой — заявка возвращается в pending до 3 попыток.

Стек и ограничения

• Хранилище: Postgres + те же таблицы рядом с RAG/assistant. Никакого SQLite-native модуля — деплой проще.
• Очередь: своя на одной таблице со статус-машиной. Атомарный pick через FOR UPDATE SKIP LOCKED.
• Классификатор: free-LLM из OpenRouter в JSON-mode, fallback-модель при сбое; категории фиксированные (RAG / голосовой / документы / ассистент / парсер / автоматизация / консультация / другое).
• Уведомление: Telegram Bot API напрямую через fetch, MarkdownV2-карточка с категорией, важностью, контактом и текстом.
• Анти-спам: honeypot-поле + лимит 5 заявок с одного IP за час + IP-хэш вместо raw-IP в БД.
• Что НЕ делает в v1: не отвечает заявителю автоматически, не интегрируется с email (SPF/DKIM-домен — отдельный объём), не дёргает CRM. Только Telegram владельцу.