ChatManager: как AI-боту дать контроль над своими чатами

От хаоса к порядку: как мы научили AI-бота управлять собственными чатами

Столкнулись с интересной проблемой в проекте voice-agent — нашему AI-боту нужно было получить контроль над тем, в каких чатах он работает. Представь: бот может оказаться в сотнях групп, но обслуживать он должен только те, которые явно добавил владелец. И вот здесь начинается магия архитектуры.

Задача была классической, но хитрой

Нужно было реализовать систему управления чатами — что-то вроде белого списка. Бот должен был: - Помнить, какие чаты он курирует - Проверять права пользователя перед каждой командой - Добавлять/удалять чаты через понятные команды - Хранить всё это в надежной базе данных

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

Как мы это делали

Первым делом создали класс ChatManager — специалист по управлению чатами. Он бы жил в src/auth/ и работал с SQLite через aiosqlite (асинхронный драйвер, чтобы не блокировать главный цикл обработки сообщений). Важный момент: использовали уже имеющийся в проекте structlog для логирования — не захотелось добавлять ещё одну зависимость в requirements.txt.

Затем создали миграцию БД — новую таблицу managed_chats с полями для типа чата (приватный, группа, супергруппа, канал), ID владельца и временной метки. Ничего сложного, но по-человечески: индексы на часто используемых полях, CHECK-констрейнты для валидности типов.

Дальше идет классический паттерн — middleware для проверки прав. Перед каждой командой система проверяет: а имеет ли этот пользователь доступ к этому чату? Если нет — бот скромно молчит или вежливо отказывает. Это файл src/telegram/middleware/permission_check.py, который встраивается в pipeline обработки сообщений.

И, конечно, handlers — набор команд /manage add, /manage remove, /manage list. Пользователь пишет в личку боту /manage add, и чат добавляется в управляемые. Просто и понятно.

Маленький инсайт про асинхронные БД

Знаешь, почему aiosqlite так хороша? SQLite по умолчанию работает синхронно, но в асинхронном приложении это становится узким местом. aiosqlite оборачивает операции в asyncio, и вот уже БД не блокирует весь бот. Минимум кода, максимум производительности. Многие разработчики об этом не думают, пока не столкнутся с тем, что бот «зависает» при запросе к БД.

Итог: от плана к тестам

Весь процесс разбили на логические шаги с контрольными точками — каждый шаг можно было проверить отдельно. После создания ChatManager идёт миграция БД, потом интеграция в основной бот, затем handlers для команд управления, и наконец — unit-тесты в pytest.

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

Дальше план — запустить интеграционные тесты и загнать в production. Но это уже другая история.

😄 Совет дня: всегда создавай миграции БД отдельно от логики — так проще откатывать и тестировать.