Как устроен ClawAI

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

Последняя проверка 2026-07-25

Как устроен ClawAI

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

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

18: Независимо разворачиваемых сервисов
По одной на сервис: Никогда никакой общей базы данных
HTTP + события: Синхронные вызовы плюс асинхронная шина событий
Одна точка входа: Единый обратный прокси перед всей системой

Сервисы

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

АутентификацияPostgreSQL: Аккаунты, сессии, выпуск токенов и их ротация при обновлении, роли и наборы разрешений.
ЧатPostgreSQL: Беседы и сообщения, сборка контекста, потоковое выполнение и мультимодельная оркестрация.
МаршрутизацияPostgreSQL: Классифицирует каждое сообщение, применяет активный режим и действующие политики и фиксирует решение вместе с цепочкой резервных вариантов.
КоннекторыPostgreSQL: Учётные данные провайдеров, каталоги моделей, флаги возможностей и непрерывные проверки работоспособности.
Память и контекстPostgreSQL + pgvector: Записи памяти, очередь предложений, пакеты контекста и их версии, а также семантический поиск.
ФайлыPostgreSQL: Загрузка, проверка безопасности, извлечение текста, OCR, разбиение на фрагменты и хранение.
ИсследованияPostgreSQL: Поиск в интернете, загрузка страниц и сборка доказательной базы для ответов со ссылками на источники.
Рабочее пространствоPostgreSQL: OAuth-подключения к двенадцати сторонним инструментам, вебхуки, синхронизация по расписанию и сквозной поиск.
Генерация изображенийPostgreSQL: Запросы на изображения, адаптеры провайдеров и пошаговый прогресс во время отрисовки.
Генерация документовPostgreSQL: Преобразование ответов в PDF, DOCX, CSV, HTML, Markdown, TXT и JSON.
ОплатаPostgreSQL: Тарифы, подписки, версионированные цены, счета и контроль лимитов.
АудитMongoDB: Неизменяемая запись того, кто и что сделал, плюс журнал использования, из которого выводится каждый показатель лимита.
ЖурналированиеMongoDB: Структурированные журналы всех сервисов и браузера, хранимые в скользящем окне.

Каждый сервис указывает базу данных, которой владеет. Больше к ней никто не подключается: сервис, которому нужны чужие данные, запрашивает их по HTTP или реагирует на событие.

Одна база данных на сервис

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

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

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

Жизнь одного запроса

Что происходит между нажатием «отправить» и чтением ответа.

Запрос проходит аутентификацию
обратный прокси передаёт его сервису чата, который проверяет ваш токен доступа и разрешения, привязанные к вашей роли.
Проверяется лимит
сервис оплаты подтверждает, что ваш тариф допускает запрошенную модель и что в дневном и месячном лимите ещё есть запас.
Сообщение сохраняется и публикуется
чат записывает сообщение в свою базу данных и публикует событие. Маршрутизация его слушает.
Маршрутизация выбирает модель
сообщение классифицируется, применяются активный режим и политики, учитывается работоспособность коннекторов, и решение с цепочкой резервных вариантов фиксируется.
Собирается контекст
чат запрашивает у памяти релевантные записи и элементы пакетов, а у файлов — релевантные фрагменты, после чего объединяет их в промпт в рамках бюджета токенов.
Модель вызывается и стримится
чат вызывает провайдера и передаёт этапы, текст, рассуждения и метрики в ваш браузер через Server-Sent Events по мере их поступления.
Результат сохраняется
ответ, решение о маршрутизации, счётчики токенов и квитанция контекста записываются вместе.
Фиксируются использование и аудит
сервис оплаты списывает стоимость с вашего лимита, а аудит записывает событие. Здесь же выполняется извлечение памяти.

Шаги с 1 по 7 синхронны — вы их ждёте. Шаг 8 и извлечение памяти происходят уже после того, как ответ появился на экране, поэтому они не добавляют задержки к тому, что вы видите.

Шина событий

Работа, которая не обязана завершиться до того, как вы увидите ответ, публикуется как событие в топик-обменнике RabbitMQ и обрабатывается теми сервисами, которым она нужна. Так работают учёт использования, записи аудита и извлечение памяти.

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

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

Потоковая передача

Ответы приходят через Server-Sent Events, а не опросом. Соединение открывается, когда вы отправляете сообщение, и передаёт всё, пока ответ не завершён или не отменён.

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

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

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

Что и где хранится

Четыре вида хранилищ, каждое используется по своему назначению.

PostgreSQL: Система записи для аккаунтов, бесед, решений о маршрутизации, памяти, файлов, подключений и оплаты — по одной базе данных на сервис.
pgvector: Поиск по векторному сходству внутри PostgreSQL, применяется для извлечения релевантных единиц памяти и элементов пакетов контекста без отдельной векторной базы данных.
MongoDB: События аудита, журнал использования и структурированные логи: большой объём данных, только добавляемых, со скользящим окном хранения.
Redis: Кеширование, счётчики ограничения частоты и недолговечное состояние координации. Ничего важного здесь не хранится в единственном экземпляре.

Механизмы безопасности

Конкретные меры, которые есть в продукте. Никаких заявлений о сертификации — см. примечание в конце.

Токены доступа и обновления: Недолговечные токены доступа с ротацией при обновлении. Повторное использование уже заменённого токена аннулирует сессию.
Хеширование паролей: Argon2 с индивидуальной солью для каждого пользователя. Пароли никогда не хранятся и не пишутся в журналы в восстановимом виде.
Ролевое управление доступом: Роли несут конкретные наборы разрешений, которые проверяются гардами на каждом эндпоинте каждого сервиса, а не только в интерфейсе.
Шифрование учётных данных: Секреты провайдеров и коннекторов шифруются в состоянии покоя по AES-256-GCM и никогда не возвращаются через API.
Валидация схем: Каждое тело запроса проверяется по схеме Zod с явными ограничениями длины и размера, прежде чем попасть в какую-либо логику.
Ограничение частоты запросов: Ограничение по каждому аккаунту на каждом сервисе, чтобы один клиент не мог исчерпать ёмкость для всех остальных.
Заголовки безопасности: Строгая политика безопасности контента с одноразовыми nonce для каждого запроса, HSTS и стандартные защитные заголовки в каждом ответе.
TLS повсюду: TLS от браузера до периметра и снова на каждом внутреннем переходе, с проверкой сертификатов между сервисами.
Очистка журналов: Токены, пароли, ключи API и заголовки авторизации удаляются до того, как что-либо попадёт в журнал.

Сегодня у ClawAI нет сторонних сертификатов по безопасности — ни SOC 2, ни ISO 27001, ни HIPAA. Мы описываем перечисленные выше механизмы, а не намекаем на гарантии, которых у нас нет. Организациям с формальными требованиями стоит сообщить о них, чтобы их можно было учесть в рамках отдельного проекта.

Наблюдаемость

Каждый сервис отдаёт одни и те же сигналы в одном и том же формате, и все они попадают туда, где их можно запросить. Инженер, отвечающий на вопрос «что случилось с этим запросом», не должен открывать восемнадцать файлов журналов.

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

Когда что-то ломается

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

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

Та же архитектура, но внутри вашей сети

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

В такой конфигурации внешние провайдеры моделей заменяются моделями с открытыми весами на ваших собственных GPU, поэтому ни один запрос, документ или беседа не покидают вашу инфраструктуру. Это индивидуальный проект, а не тариф, который можно купить, — объём мы определяем вместе с вашей командой.

Обсудить частное развёртывание

Посмотрите, как это работает

Быстрее всего судить об архитектуре по тому, что она производит. Настройка бесплатного тарифа занимает минуту.

Создать аккаунт Обсудить частное развёртывание