В добывающей компании ИИ-ботом пользуются до 5000 сотрудников, и по сути это кастомный RAG. Следующий шаг из кейса «Как я сделал OpenClaw (ИИ) на 5000 сотрудников» выглядит так: вместо одного общего бота каждый сотрудник получает персонального ассистента со своей памятью, настройками и общим корпоративным контекстом знаний.
Технически это мультитенантная схема из двух уровней. Один Telegram-роутер принимает запросы и маршрутизирует каждого пользователя в отдельный изолированный инстанс бота. Инстансы работают как systemd-сервисы: роутер потребляет около 15 МБ RAM, каждый nanobot около 250 МБ, а неактивные боты останавливаются и поднимаются за 1-2 секунды при новом сообщении.
Такая связка убирает главную проблему единого инстанса: смешивание контекста и памяти. Заодно она объясняет, где на самом деле живёт сложность таких проектов. Не в промптах и не в выборе модели, а в инфраструктуре: изоляции сессий, экономии RAM, авторизации тысяч людей и эксплуатации парка сервисов.
Задача: персональный ИИ-ассистент для 5000 сотрудников добывающей компании
Исходная точка: в добывающей компании ИИ-ботом пользуются до 5000 сотрудников, и это по сути кастомный RAG. Бот отвечает по базе знаний, но не помнит конкретного человека, не различает его предпочтения и не ведёт персональную историю. Когда понадобились персональные ассистенты, выяснилось, что доработкой промпта задачу не закрыть: менять нужно архитектуру целиком.
Почему один OpenClaw на всех не работает
Если поднять один OpenClaw с одним входом через TG-бота, 5000 пользователей быстро превратят его в кашу информации. Ассистент начнёт путать имена, а вместе с именами и предпочтения, навыки и прочие настройки. Причина в общей памяти: диалоги и профили всех пользователей сваливаются в одно состояние, и надёжного способа разделить, кому что принадлежит, внутри одного процесса нет.
Вторая проблема чисто инженерная. В кейсе отмечены большие сложности с реальной возможностью одного OpenClaw обрабатывать много параллельных сессий изолированно. Аккуратная логическая разметка пользователей внутри одного процесса не даёт гарантий, что сессии не пересекутся, а нагрузка от тысяч одновременных запросов упирается в один инстанс.
Что именно нужно было получить на выходе
Требования к системе в кейсе выглядят так:
- изоляция памяти и контекста на каждого пользователя;
- общий корпоративный контекст знаний, доступный каждому персональному ассистенту;
- лёгкая авторизация на лету, без ручного ведения справочника;
- роутинг каждого user в свой инстанс;
- управляемость на масштабе 5000 пользователей.
Отдельный пункт, который ломает наивные решения: 5000 users меняются и меняют свои TG nicknames. Человек увольняется, переходит в другой отдел, заводит новый аккаунт. Любой жёсткий список пользователей устаревает быстрее, чем его успевают синхронизировать.
Архитектура: один Telegram-роутер и изолированный инстанс на каждого сотрудника
Базовое решение сформулировано коротко: принимать все запросы на один TG-бот, затем роутить каждого user в свой OpenClaw. Один Telegram-роутер держит единственную точку входа, а дальше маршрутизирует пользователя в отдельный изолированный инстанс бота. Смешивание контекста и памяти исчезает по построению: переписка одного сотрудника физически не попадает в процесс, который обслуживает другого.
История изменений в самом OpenClaw важна для тех, кто повторит кейс. На момент марта возможности роутинга пользователей в свои инстансы не было. Позже появилась возможность создавать изолированные hardcoded списки и роутить их на своих sub-agent, со своей памятью и прочим. Платформа двинулась в нужную сторону, но под конкретный сценарий этого не хватило.
Если вы стоите перед выбором между готовой платформой и самописным агентом, пригодится разбор того, как устроены оркестрация вызовов LLM, память и инструменты, когда код пишется с нуля: архитектура AI-агента с нуля, метрики и код на Python.
Почему hardcoded-списки не подошли
Главным ограничением стали организационные условия: 5000 users, которые меняются и меняют свои TG nicknames. Жёсткие списки в такой среде не работают. Нужен был способ лёгкой авторизации на лету и роутинга каждого user в свой OpenClaw. Статический файл ломается на первой же ротации: новый сотрудник не войдёт, пока кто-то не допишет его идентификатор, а ушедший сохранит доступ, пока его не удалят вручную.
Авторизация по ротируемому invite-коду
В кейсе описана авторизация по ротируемому invite-коду. Смысл механизма в том, что доступ выдаётся кодом, который можно обновлять, а не записью в фиксированном списке. Это снимает ручную синхронизацию справочника и позволяет подключать людей пачками. Формат кода, срок его жизни и порядок ротации в источнике не раскрыты, поэтому конкретную схему придётся проектировать под свои требования к безопасности.
Отказ от Docker в пользу systemd-сервисов
Вместо Docker автор перевёл всё на systemd-сервисы. Причина простая: сам OpenClaw требователен к ресурсам и продолжает активно развиваться, обрастая новыми возможностями. Для тысяч инстансов контейнерная обвязка добавляет накладные расходы на каждый экземпляр, а юнит systemd стоит дешевле. После исследования альтернатив был выбран более лёгкий вариант; в описании темы он назван nanobot, хотя в доступном фрагменте источника название аналога не приводится.
Экономика RAM: 15 МБ на роутер и 250 МБ на nanobot
Две цифры из кейса задают всю экономику: роутер потребляет около 15 МБ RAM, каждый nanobot около 250 МБ. Роутер можно держать постоянно, он лёгкий. Основной вес сосредоточен в инстансах ботов, и именно поэтому держать все 5000 активными нереально. Экономия строится на остановке неактивных: память занимают только те боты, с кем прямо сейчас общаются.
Холодный старт за 1-2 секунды
Неактивные боты останавливаются и поднимаются за 1-2 секунды при новом сообщении. Для чат-сценария это приемлемо: пауза сопоставима со временем набора следующего сообщения, и пользователь обычно её не замечает. Плата за экономию RAM - необходимость аккуратно управлять состоянием и запуском сервисов, чтобы остановка процесса не означала потерю данных. Механику запуска источник не раскрывает, поэтому схему хранения состояния придётся проектировать самостоятельно.
Управление тысячами инстансов: автобалансировщик, передача ассистента и UI
Запустить один инстанс и запустить пять тысяч - разные задачи. Операционная часть кейса состоит из трёх механизмов.
Автобалансировщик по свободной памяти
Добавлен автобалансировщик по свободной памяти: он решает, куда поднимать нового бота, ориентируясь на доступный ресурс узла. При тысячах инстансов ручное распределение невозможно, а перекос приводит к тому, что часть ботов на одном сервере начинает вытеснять остальных. Алгоритм, пороги срабатывания и метрики в источнике не раскрыты.
Передача ассистента между сотрудниками
Ассистента можно передать другому сотруднику. Сценарий напрямую связан с текучкой: 5000 users меняются, кто-то уходит, кто-то меняет роль. Без передачи персональный ассистент остался бы привязан к аккаунту уволившегося. Что происходит с памятью и правами при передаче, в источнике не описано.
Смена модели и TG-токена через UI
Смена модели и TG-токена доступна через UI. При парке в тысячи инстансов ручная правка конфигов не масштабируется: одна смена модели превратилась бы в отдельную задачу на весь парк ботов. Интерфейс переносит это в пару действий.
Интеграции: собственный MCP-сервер для Yandex Mail, 1С и amoCRM
Ассистент внутри компании полезен настолько, насколько он видит рабочие системы. В кейсе добавлен собственный MCP-сервер для интеграций с Yandex Mail, 1С и amoCRM. MCP здесь работает как слой интеграций: ассистент обращается к предсказуемому интерфейсу инструментов, а не к самодельным вызовам API внутри каждого сценария.
Практическая ценность такого слоя в том, что корпоративные системы не трогают логику агента. Появилась новая интеграция - её добавляют на стороне MCP-сервера, не переписывая поведение тысяч ботов. Список методов, схемы авторизации и детали протокола в источнике не раскрыты.
Знания ассистента: отказ от классического RAG в пользу markdown + ReAct + grep
Поиск знаний автор решил иначе, чем в исходном боте. От классического RAG отказались в пользу плоских markdown-файлов с ReAct и grep. Логика подхода: файлы легко читать и править, они не требуют пересборки индекса при каждом изменении, а агент с ReAct сам решает, что искать, и делает это через grep по тексту.
Такой вариант хорошо ложится на небольшой и часто меняющийся корпус: документация отдела, регламенты, заметки. У него есть и ограничения. Качество ответа зависит от того, насколько аккуратно разложены файлы и как названы разделы. На больших объёмах знаний поиск по плоским файлам уступает векторному: grep не понимает смысла и находит только буквальные совпадения. Бенчмарков и метрик качества в источнике нет, поэтому сравнивать подходы по точности здесь не на что.
Про то, как строят контекстную инфраструктуру под исследовательские запросы, есть отдельный разбор: кейс аналитического ИИ-агента и инфраструктуры контекста.
Возврат к pgvector-RAG ради скорости ответа
Следующий шаг в кейсе - возврат к pgvector-RAG. Отказ от RAG оказался не окончательным: когда на первый план вышла скорость ответа, векторный поиск вернули, но уже на pgvector в PostgreSQL. Разница в том, что pgvector даёт векторный поиск внутри привычной реляционной базы, без отдельной инфраструктуры под индекс.
Причина разворота понятна: прогон markdown-файлов через ReAct и grep на больших объёмах добавляет лишние шаги, а каждый шаг агента - это дополнительный вызов модели и время. Векторный поиск сокращает путь до релевантных фрагментов. Конкретных цифр задержек и точности в источнике нет, поэтому сравнивать pgvector-RAG и markdown-подход по числам нельзя.
Что стоит учесть, если вы повторяете этот кейс
Когда такая архитектура оправдана
Мультитенантная схема с роутером и изолированными инстансами окупается при определённых условиях: сотни и тысячи пользователей, требование изоляции памяти, ограниченные ресурсы серверов, готовность эксплуатировать множество Unix-сервисов. Для десятков пользователей такая сложность избыточна: один инстанс справится, а роутер, автобалансировщик и invite-коды добавят работы, которая не окупится.
Ограничения и открытые вопросы кейса
Часть решений в источнике описана тезисно. Что осталось за кадром:
- название выбранного аналога после исследования альтернатив: nanobot упоминается только в описании темы, в тексте фрагмента его нет;
- алгоритм и пороги автобалансировщика по свободной памяти;
- формат, срок жизни и ротация invite-кодов;
- механика передачи ассистента между сотрудниками, включая судьбу памяти;
- устройство MCP-сервера: методы, авторизация, покрытие систем;
- сравнение классического RAG, markdown + ReAct + grep и pgvector-RAG по скорости и качеству.
Эти детали не восстановлены по догадке: их в кейсе нет. Практический вывод из описанного опыта такой: мультитенантность через роутер и изолированные инстансы снимает смешивание памяти, systemd вместо Docker даёт лёгкий роутер и управляемые инстансы, а остановка неактивных ботов экономит RAM ценой 1-2 секунд на холодный старт. Автобалансировщик, invite-коды, передача ассистента и UI для смены модели и токена - обязательная часть эксплуатации на таком масштабе, без них система превращается в ручную работу.