Воякс — аналитик ИИ-автоматизации

Woyax AI Process Auditor — ИИ-агент для автоматического аудита бизнес-процессов. Бот проводит серию интервью с сотрудниками компании через мессенджер, выявляет рутину и узкие места, извлекает структурированные инсайты и формирует отчёт с рекомендациями по ИИ-автоматизации. No-code AI-агент на базе n8n, RAG, Qdrant и нескольких LLM-провайдеров — построенный на одном VPS в Docker Compose.

Об этом проекте — две статьи. Эта, техническая — про архитектуру, стек, workflow и процесс разработки. Вторая, на vc_ru — про бизнес-задачу, результаты и практическое применение: Воякс — аналитик ИИ-автоматизации ^[1]. Читать можно в любом порядке, статьи дополняют друг друга.

0. Минутка философии

Совсем недавно я писал код интеграции ERP-системы MS Dynamics AX (D365FO) с маркетплейсами (OZON и WB), в котором разбирал JSON и решил попросить помощи у DeepSeek — он конечно же легко справился с JSON. Далее я стал просить его разбирать технические задания и писать код, узнал про лоу-код платформы, развернул n8n на своём хостинге в Docker и связал ERP MS Dynamics AX (D365FO), маркетплейсы, мессенджеры, все LLM и ИИ-сервисы. Стало появляться ощущение, что я всё могу.

Погружаясь в тему, я видел множество обучающих курсов по различным лоу-код платформам, чаты, где проходят обучение ^[2] сотни людей и по платным программам делают свои интеграции, сервисы и ИИ-агентов. Узнал про MCP-серверы и думал, что это главный тренд будущего 2026 года. Тогда казалось, что события как-то очень быстро развиваются.

А в 2026 году события стали развиваться в разы быстрее. На одной неделе я ещё учусь руками создавать workflow в n8n, на следующей неделе подключаю MCP-сервер и делаю ИИ-агента, который уже сам создаёт эти workflow по моим текстовым описаниям, а ещё через неделю я голосом рассказываю LLM свои пожелания, которые она через несколько workflow за часы превращает в полноценный работающий ИИ-продукт. MCP уже создаются автоматически на основе API-документации.

На одной неделе меня спрашивают на собеседовании про опыт ^[3] работы с RAG и отказывают в проекте по причине отсутствия практических задач с его применением, а уже через неделю я тестирую RAG, который был создан голосом, и тестирую я его тоже голосовыми командами без строчки кода, причём командами типа «давай потестируем RAG».

Кто-то сейчас ещё разбирает JSON, кто-то начинает четвёртый интересный шаг по созданию бота в Telegram в 18-этапной программе обучения, кто-то словами просит LLM создать второй 18-этапный план, кто-то обучает свою вялую локальную модель для транскрибации, кто-то ещё анализирует навыки в резюме кандидата, кто-то ещё сам сочиняет и руками печатает этот текст…

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

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

Но всё это не повод ничего не делать и уж тем более не повод не пытаться продать то, что сделано — поэтому знакомьтесь: Воякс — аналитик ИИ-автоматизации (он же Woyax AI Process Auditor).

1. Суть проекта

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

Я решил заменить этот ручной аудит бизнес-процессов ИИ-агентом. Бот сам проводит серию интервью через мессенджер, выявляет рутину и боли ^[4], извлекает структурированные инсайты, формирует отчёт с рекомендациями. Никаких агентов на рабочих компьютерах — сотрудник отвечает в привычном мессенджере, когда удобно, текстом или голосовым сообщением.

Технически это не чат-бот с готовыми вопросами. Это AI-агент для бизнеса с памятью ^[5], контекстом и подготовкой. С каждым сотрудником проводится три сессии, и к каждой агент готовится: формирует цель разговора, составляет план тем с приоритетами, подбирает контекст. Это не импровизация — у каждой сессии есть структура, адаптированная под конкретного человека, его роль и отдел.

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

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

Но статья не только про продукт. Сам проект — это ещё и полигон, где сошлись сразу несколько интересных технологий: RAG-пайплайн с векторным поиском, эмбеддинги через Mistral, оркестрация workflow в n8n, интеграция с мессенджерами, распознавание голосовых сообщений через SaluteSpeech, работа с несколькими LLM-провайдерами через единый роутер, PostgreSQL, Qdrant — и всё это на одном VPS в Docker Compose. А ещё примерно 70% этого проекта создано с помощью ИИ — Claude Sonnet 4.6. И что, пожалуй, ещё интереснее: многопользовательское тестирование всей системы тоже провёл Sonnet — имитируя параллельно нескольких сотрудников с разными ролями.

2. Технологический стек

Отдельно стоит сказать про работу с LLM. Разные функции системы предъявляют разные требования: подготовка сессии — это одна задача, диалог с сотрудником — другая, извлечение структурированных инсайтов — третья, генерация аналитического отчёта — четвёртая. Гонять всё через одну модель было бы расточительно или неточно. Поэтому в системе есть таблица llm_config: каждая функция — отдельная строка с провайдером, моделью и параметрами. Диалог идёт через DeepSeek (быстро, дёшево), подготовка сессий — через Claude Sonnet 4.6, генерация отчёта — через Claude Opus 4.6 (качество текста на порядок выше для аналитики). Чтобы поменять модель для любой функции, достаточно обновить одну строку в БД — ни один workflow при этом не меняется.

Сейчас работает Telegram — потому что это самый низкий порог входа: у большинства сотрудников он уже установлен. Но архитектура предполагает добавление новых каналов без затрагивания бизнес-логики. Каждый канал — отдельный транспортный workflow. Dialog Engine не знает, откуда пришло сообщение: из Telegram, Teams, MAX или корпоративной почты. Причём в рамках одного аудита у каждого сотрудника может быть свой канал связи — тот, который ему удобен.

Похожим образом устроена и работа с голосом. SaluteSpeech конвертирует аудио в текст — и дальше сообщение ничем не отличается от текстового. Подключить другой STT-сервис или добавить обработку в другом формате — изменения только в одном месте.

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

Вся бизнес-логика живёт в n8n и разбита на специализированные workflow. Вот как они взаимодействуют:

3.1. Загрузка оргструктуры

Способов завести компанию в систему и подключить сотрудников может быть много: интеграция с корпоративной HR-системой, ручной ввод через интерфейс, импорт из Active Directory. В MVP мы сделали простую, но рабочую реализацию: веб-форма с загрузкой Excel-файла.

Администратор аудита заполняет шаблон: сотрудники, отделы, должности, кто кому подчиняется. Загружает в форму — дальше workflow Audit_Start делает всё сам. Создаёт в PostgreSQL компанию, аудит, отделы и сотрудников. Для каждого генерирует уникальный инвайт-токен.

На выходе администратор получает тот же Excel, но с дополнительной колонкой: персональная ссылка вида t.me/woyax_auditor_bot?start=TOKEN для каждого участника. Упрощенная структура БД здесь выглядит так:

Одна компания может проходить аудит повторно — поэтому audits отдельная сущность, а не атрибут компании. Масштаб аудита тоже настраивается: можно запустить пилот на один отдел, а потом расширить на всю компанию.

3.2. Раздача ссылок и первый контакт

Сотрудник переходит по своей ссылке, Telegram-бот (Transport_Telegram) извлекает токен из параметра /start, находит сотрудника в БД и привязывает telegram_chat_id к его записи. Дальше — сразу вызов Session_Prepare для первой сессии, и сотрудник получает персонализированное приветствие в течение секунды. Первый контакт мгновенный, потому что первое впечатление ^[7] важно: если бот молчит, сотрудник закрывает и не возвращаетс��.

Сейчас единственный рабочий канал — Telegram: самый низкий порог входа, у большинства уже установлен. Архитектура предполагает добавление других каналов (MAX, Teams, email и др.) поверх той же бизнес-логики.

3.3. Подготовка сессии (Session_Prepare)

Это самый насыщенный workflow — и методологически, и технически. Прежде чем сотрудник напишет первое слово, агент проделывает серьёзную подготовительную работу.

Сначала собирается контекст из PostgreSQL: кто этот человек, в каком отделе, какая должность, кому подчиняется. Для второй и третьей сессий добавляется ещё один запрос — собственные инсайты сотрудника из предыдущих диалогов. Агент должен знать, что уже выяснено, чтобы не переспрашивать.

Затем — RAG-поиск в Qdrant. Запрос формируется по отделу и роли (с учётом scope аудита), и система подтягивает инсайты коллег: что болит у других в том же отделе, какие процессы уже упоминались. Если финансовый аналитик из соседней команды уже рассказал про ручную выгрузку данных из ERP, агент об этом знает — и может спросить напрямую, а не ждать, пока новый собеседник сам до этого дойдёт.

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

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

Всё это — контекст сотрудника, инсайты коллег, role_hints, covered_topics прошлых сессий — складывается в prepared_context и записывается в запись диалога. На основе этих данных LLM формирует session_plan: JSONB-список тем с приоритетами, адаптированный под номер сессии. И наконец — генерирует приветственное сообщение. Не шаблон, а живой текст: зависит от контекста, стиля общения (дружеский или деловой — настраивается на уровне аудита) и номера сессии. Диалог создаётся со статусом waiting_start — сессия подготовлена, но ещё не началась.

3.4. Диалог (Session_Dialog)

Сотрудник читает приветствие и отвечает что-то вроде «готов» или «начнём». Это переводит диалог в статус active — сессия запущена. Дальше каждое сообщение проходит через один и тот же маршрут: текст сотрудника + prepared_context + история диалога → LLM → ответ → сохранить в messages.

Принципиально важная деталь: контекст подготовлен заранее и не меняется внутри сессии. Никаких дополнительных запросов к БД или Qdrant по ходу разговора. Это сознательное решение — предсказуемость и отлаживаемость важнее теоретической гибкости. Если агент ведёт себя неожиданно, всегда можно посмотреть ровно тот prepared_context, который был на входе.

Сессия завершается по одному из двух условий: счётчик вопросов достиг максимума (7) или session_plan показывает, что ключевые темы покрыты. В этот момент LLM ставит в свой ответ маркер [SESSION_END] — это сигнал для следующего workflow.

3.5. Завершение сессии (Session_Close)

Transport_Telegram видит [SESSION_END] в ответе LLM, вызывает Session_Close — и сразу отправляет сотруднику финальное сообщение, не дожидаясь результата. Аналитика работает фоном, человек не ждёт.

Session_Close делает несколько вещей подряд. Сначала — извлечение инсайтов: отдельный LLM-запрос с низким temperature (0.1) и структурированным промптом. На выходе — список объектов: процесс, описание боли, частота, временные затраты, потенциал автоматизации, упомянутые инструменты. Всё это батчем уходит в PostgreSQL.

Параллельно каждый инсайт векторизуется через Mistral Embeddings и записывается в Qdrant с payload-полями: company_id, audit_id, employee_id, department, role, process_name, pain_type, automation_potential. Именно по этим полям будет идти RAG-поиск при подготовке следующих сессий — в том числе у других сотрудников того же отдела.

Важный момент про обезличивание: перед любым вызовом LLM ФИО заменяются на Сотрудник_1, Руководитель_1. В Qdrant и PostgreSQL хранятся ID, не имена. Данные, которые уходят во внешние API, не содержат персональной информации — это важно и с точки зрения ^[8] законодательства о персональных данных (152-ФЗ), и с точки зрения доверия сотрудников к процессу.

После записи инсайтов Session_Close формирует planned_topics для следующей сессии, обновляет covered_topics, переводит диалог в статус completed и обновляет interview_status сотрудника.

3.6. Между сессиями запуски по расписаниям

После первой сессии сотрудник уходит — и ничего не происходит, пока не наступит дата открытия следующей. Даты session_2_opens_at и session_3_opens_at задаются в настройках аудита администратором — он решает, сколько времени нужно между сессиями. В назначенный момент Session_Scheduler сам открывает сессию и отправляет сотруднику стартовое сообщение.

Session_Scheduler — крон, который запускается (например) каждый час по рабочим дням с 10:00 до 17:00 МСК. Он делает два параллельных прохода. Первый — открытие новых сессий: ищет сотрудников, у которых interview_status = 'in_progress', нет активного диалога, и дата открытия уже наступила. Для каждого такого сотрудника вызывается Session_Prepare — и человек получает стартовое сообщение следующей сессии.

Второй проход — напоминания. Если диалог завис в статусе active больше 24 часов (поле reminder_sent_at контролирует частоту), сотрудник получает мягкий пинг: «Вы начали сессию, но не завершили — продолжим?»

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

3.7. Три сессии — три фокуса

Три сессии — это не просто «поговорить три раза». У каждой свой методологический фокус, и Session_Prepare получает разный промпт в зависимости от session_number.

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

Вторая — углублённая. Агент уже знает из первой сессии, что человек упоминал ручную сверку отчётов и переписку с подрядчиками. Теперь спрашивает детально: сколько времени, какие инструменты, где узкие места, есть ли смежные отделы, которые страдают от того же. RAG подтягивает инсайты коллег — и агент может сослаться: «Ваши коллеги из бухгалтерии тоже упоминали эту выгрузку — как это выглядит с вашей стороны?»

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

4. Кто это сделал?

Ранее я упомянул, что примерно 70% проекта создано с помощью Claude Sonnet 4.6, и что тестирование тоже провёл он (или она). Пора раскрыть, как это устроено на п��актике — потому что, на мой взгляд, это самое интересное в этой истории.

4.1. Инструменты для разработки и отладки

Два MCP-сервера для работы с n8n. Первый — n8n-control: управление workflow напрямую из чата. create_workflow, update_workflow, activate_workflow, list_workflows, get_execution — Claude видел структуру системы не через мои описания, а вживую. Второй — n8n-docs: документация по нодам и валидация конфигураций, чтобы не изобретать синтаксис на ходу.

Это принципиально меняет характер работы. Я мог написать: «Создай workflow Session_Scheduler: крон каждый час по рабочим дням, два параллельных прохода — открытие сессий и напоминания» — и Claude не просто предлагал схему, а сразу создавал workflow в n8n, активировал его и сообщал ID. Никакого copy-paste между чатом и интерфейсом. Хотя кого я обманываю — я даже такого не писал.

Структура БД — тоже через Claude. Для работы со схемой данных был поднят отдельный вспомогательный workflow ai-tmp-db-query — webhook, принимающий произвольный SQL и выполняющий его в auditor_db. Через него Claude проектировал таблицы, применял миграции, проверял результат. Я объяснял бизнес-логику: «нужна таблица диалогов, у каждого диалога — план тем в виде JSON, статус, история сообщений» — Claude писал SQL, прогонял через ai-tmp-db-query workflow и рапортовал о результате.

Claude в браузере — для отладки. Расширение Claude for Chrome даёт возможность работать непосредственно в браузере. Для активных действий оно подходит ограниченно, но для одной задачи оказалось незаменимым: смотреть логи выполнения (executions) прямо в интерфейсе n8n. Когда workflow падал, Claude мог открыть страницу execution, самостоятельно прочитать трейс ошибки ^[9] и предложить исправление — без моего участия в разборе логов.

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

Что оставалось за мной: архитектурные решения и методология (три сессии, их фокусы, логика аудита), промпты — это ядро продукта и его конкурентное преимущество, финальная проверка результата в n8n и тест на реальном Telegram-боте.

4.2. Ведение проекта в Claude

Инструменты для работы с кодом — это одна сторона. Но не менее важно, как организована сама работа с ИИ на уровне проекта. Вся работа велась внутри одного проекта в Claude. Проект — это общее пространство с файлами, которые автоматически доступны в каждом чате. Никакого ручного копирования контекста.

Центральный артефакт — Master_Doc.md. В нём всё: архитектура, схема БД, список workflow со статусами, все технические решения с датами и причинами принятия, бэклог, credentials, шаблон брифа для рабочих чатов. Это не документация ради документации — это живой рабочий инструмент. Прежде чем открыть новый чат, я обновлял мастер-документ. После закрытия — снова обновлял. Доку��ент рос вместе с проектом и к финалу содержал полную историю всех решений.

Помимо мастер-документа в проекте лежат вспомогательные файлы: схема SQL, шаблон Excel для загрузки оргструктуры, конфигурации. Всё, что нужно Claude для работы — уже в контексте.

Чаты внутри проекта делятся на два типа. Мастер-чат — стратегический: архитектура, продуктовые решения, обсуждение подходов. Сюда не несут технические баги. Рабочие чаты — по одному на каждую задачу, закрываются после её решения. Правило «один чат = одна задача» оказалось критически важным: когда задача сформулирована чётко и контекст передан полностью, Claude работает точно. Когда в одном чате смешаны пять задач разной природы — начинается энтропия.

Каждый рабочий чат открывался с брифа по шаблону из мастер-документа: суть проекта, стек, текущая задача, релевантные ограничения и уже принятые решения. Это занимало пару минут, но экономило часы: Claude не переизобретал колесо и не предлагал решения, которые уже были проверены и отброшены.

4.3. Инструменты для тестирования и многопользовательское тестирование

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

Проблема. AI-агент параллельно ведёт диалоги с десятками сотрудников, у каждого свой контекст, роль, отдел, история сессий. Как это протестировать? Один полный цикл на одного сотрудника — три сессии по 7+ сообщений каждая, плюс проверка извлечённых инсайтов, статусов, данных в Qdrant. Умножить на нескольких параллельных — и тестирование вручную превращается в отдельную работу.

Решение. Я поручил Claude имитировать сотрудников. Не одного — нескольких одновременно, с разными ролями и стилями ответов. Для этого была построена тестовая инфраструктура — набор вспомогательных workflows, которые не являются частью продукта, но без которых разработка была бы вдвое медленнее.

Схема работы выглядела так: Claude получал задачу — «прогони пять сотрудников параллельно, компания в ритейле: генеральный директор, финансовый директор, главный бухгалтер, руководитель отдела продаж, логист». Дальше он сам распределял роли и методично вёл все пять диалогов: через dialog-send отправлял сообщения от каждого персонажа с характерным для должности стилем — генеральный отвечал стратегически и кратко, бухгалтер жаловался на ручную сверку актов, логист — на пересечения с закупками. После каждой сессии проверял через check-state и db-query: правильный ли статус у каждого, те ли инсайты извлечены и записаны в Qdrant, нет ли смешения контекстов между сотрудниками — и попадают ли инсайты в RAG-контекст следующей сессии у коллег из того же отдела. Между итерациями сбрасывал состояние через reset-state — и начинал следующий прогон с чистого листа.

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

После многопользовательского тестирования через Claude система прошла финальный прогон уже с реальным аккаунтом в Telegram — чтобы убедиться, что то, что работает через webhook, работает и через настоящий транспорт.

5. И напоследок «полнейший отвал башки»

Я включил на своём компьютере диктовку и просто говорил вслух: «Какая структура таблиц нам нужна и почему? — Создай её. Какие workflow нам нужны? — Создай их. Что тебе нужно, чтобы провести тестирование самой? Каких инструментов не хватает? — Создай их. Давай запустим тестирование на пять сотрудников — информируй подробно о каждом диалоге и ходе тестирования» Claude отвечал, создавал, запускал, докладывал…

---

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

Если интересно не только как это устроено, но и как работает на практике — результаты тестирования на реальных сценариях, примеры извлечённых инсайтов и разбор бизнес-модели — об этом подробнее в коммерческой статье на vc_ru: Воякс — аналитик ИИ-автоматизации ^[1].

По вопросам сотрудничества – контакты в профиле.