Свой мессенджер с ИИ-агентом в чате: пилот Buzz на собственном реле

Идея пилота

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

Проверить это на чужом сервере нельзя. Нужен мессенджер, который поднимается целиком у себя. Я взял Buzz — открытый проект block/buzz. К 15 августа 2026 пилот дошёл до состояния, когда всё живое, и я зафиксировал, что именно работает.

Что уже стоит

Чекаут block/buzz подтянут до коммита 69107dc3b. Для понимания скорости проекта: за неделю в апстрим прилетело 104 коммита. Перед развёртыванием я разобрал архитектуру и сложил выводы в ИССЛЕДОВАНИЕ.md прямо в чекауте — иначе через месяц забудешь, почему в конфиге стоят именно эти флаги.

Реле поднято в Docker, проект buzz-prod, слушает ws://127.0.0.1:3000, контейнер в статусе healthy.

Режим реле закрытый:

• BUZZ_REQUIRE_RELAY_MEMBERSHIP=true — пускаем только участников сообщества;
• BUZZ_ALLOW_NIP_OA_AUTH=true — авторизация для подключения агента.

Конфиг лежит в relay/.env и добавлен в .gitignore. Сообщество создано: хост 127.0.0.1:3000, id c83b0575-4daf-4aa1-bf89-7fd7d9136425.

Вся инфраструктура вынесена в отдельный приватный репозиторий ragastar/buzz-lab. Там компоуз, конфиги без секретов и журнал пилота. Все коммиты привязаны к issue #1 — это одна сквозная нитка, по которой можно восстановить ход событий.

Агент в чате: ACP-мост поверх Claude Code

Самая ценная часть пилота — способ подключения агента. Он заходит в чат через ACP-мост поверх Claude Code, то есть работает на CLI-подписке, которая у меня уже есть. Агент называется «Клод», 15 августа он вышел в рабочий режим — коммит d738632.

Это заметно отличается от привычного бота на API. У бота свой изолированный контекст и набор функций, которые ему прописали. У агента через мост — тот же харнесс, что и в терминале: файлы, репозитории, скиллы, накопленная память. Он приходит в чат целиком. Формулировка «отвечает на сообщения» тут узкая: он выполняет работу и отчитывается о ней в чат.

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

Грабли, на которых я потоптался

Честный список — самая полезная часть любого пилота.

Docker Desktop не стартовал. Причина оказалась экзотической: осиротевший сокет userAnalyticsOtlpHttp.sock. Лечится переименованием папки %LOCALAPPDATA%\Docker\run — Docker пересоздаёт её при следующем запуске. На поиск ушло прилично времени, а фикс занял десять секунд.

404 при подключении агента к реле. Мост стучался, реле отвечало отказом. Починено в cffa321 — до этого агент в чат просто не заходил.

Смена адреса реле сломала онбординг десктопа. Клиент был привязан к прежнему адресу, пришлось проходить онбординг заново (91b3e41). В том же коммите я записал неприятное: ключ владельца засветился. Записал прямо в журнал пилота, потому что скрывать такое от самого себя — худшая стратегия. Для тестового контура это терпимо, для боевого — повод ротировать ключ до того, как реле выйдет за пределы localhost.

Почему реле закрытое

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

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

Что дальше

Ближайшие шаги простые и по порядку:

1. Вынести реле за пределы localhost — доменное имя, TLS, нормальный адрес для внешних клиентов.
2. Ротировать ключ владельца до этого выхода.
3. Пригласить друга и подключить его агента со своим харнессом.
4. Посмотреть, как два агента с разными базами знаний ведут себя в общем чате: где помогают друг другу, где начинают спорить или дублировать работу.

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