Назад к блогу
Опубликовано
REF 10 NODES

Buzz: посади Claude Code и Codex в одну комнату

Твой Claude Code в одном терминале, Codex в другом, а прослойка копипаста между ними — это ты. Buzz от Block: открытый воркспейс, где агенты входят в каналы как участники со своими ключами. Разбираю, как ACP-харнесс их связывает, что это реально дает и что еще не закончено.

Buzz: посади Claude Code и Codex в одну комнату
VISUAL INPUT buzz-claude-code-codex

Buzz: посади Claude Code и Codex в одну комнату

Видео: Claude Code + Codex in One Channel: Buzz Explained

Claude Code работает в одном терминале, Codex в другом. Чтобы передать вывод одного агента второму, приходится выделять текст, переключать окно и вставлять его руками. Иногда это терпимо. Но если агенты должны советоваться постоянно, человек быстро превращается в дорогой буфер обмена.

Buzz собирает людей и агентов в общих каналах. Это рабочее пространство от Block для самостоятельного развертывания под лицензией Apache-2.0. На момент публикации у репозитория было более 26 000 звезд на GitHub. Каждый агент подключается как отдельный участник со своей личностью, доступом к конкретным каналам и записями в журнале аудита.

Как Buzz подключает агентов

За связь с уже настроенными агентами отвечает buzz-acp, харнесс из репозитория:

Buzz Relay ──WS──→ buzz-acp ──stdio──→ твой агент
                                          │
                                       Buzz CLI
                                    (send_message и прочее)

Харнесс слушает упоминания с @ на релее и обращается к агенту по Agent Client Protocol через стандартный ввод-вывод. Ответ агент отправляет через buzz-cli. Этот инструмент принимает и возвращает JSON. Он рассчитан на вызов моделью, а не на ручную работу в терминале.

Подключить можно любую среду с поддержкой ACP поверх stdio. В документации показаны два адаптера и нативная точка входа ACP у Goose:

# Codex
npm install -g @agentclientprotocol/codex-acp
export OPENAI_API_KEY="sk-..."

# Claude Code (обертка над Claude Agent SDK)
npm install -g @agentclientprotocol/claude-agent-acp
export ANTHROPIC_API_KEY="sk-ant-..."
export BUZZ_ACP_AGENT_COMMAND="claude-agent-acp"

# Goose — нативно, без адаптера
export GOOSE_MODE=auto

buzz-acp   # поднимает агента, коннектится к релею, находит каналы, слушает

Есть одна оговорка про Codex. Если при попытке подключения к ChatGPT по WebSocket задокументированная конфигурация codex-acp выводит 426 Upgrade Required, Buzz считает эту ошибку ожидаемой и нефатальной. В качестве запасного пути документация предлагает OPENAI_API_KEY.

Мне в этой схеме нравится отсутствие привязки к одному агенту. Универсальный харнесс можно направить на выбранную среду. Отдельной подписки на платформу Buzz нет, но модель или доступ к API и инфраструктура релея по-прежнему стоят денег. Для описанного в документации подключения Codex нужен OPENAI_API_KEY, а адаптер Claude использует ANTHROPIC_API_KEY.

Как устроен доступ агента

У каждого агента есть собственная пара ключей Nostr. Она определяет его личность, а правила событий и подписей задает NIP-01. Если агентов три, пар ключей тоже три.

Здесь легко перепутать два уровня доступа. Команда buzz-admin add-member регистрирует открытый ключ как участника релея. Когда список меняется, релей публикует подписанный снимок списка участников NIP-43 событием типа 13534. Это список участников релея, а не пара ключей агента и не событие членства в приватном канале.

Доступ к каналам настраивается отдельно. Приватный канал требует явного добавления участника, а харнесс находит только каналы, разрешенные аутентифицированному агенту. При этом у релея пока нет REST или событийного API для управления участниками канала. Документация buzz-acp предлагает создавать канал через CLI: его создатель становится участником автоматически.

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

Такой подход продолжает мысль из моих статей Graph Engineering for Multi-Agent AI и Agent Harness Architecture. Надежнее ограничение, которое действительно применяет среда. Одной просьбы в промпте для этого мало.

Один лог вместо семи вкладок

Buzz работает поверх релея Nostr. Сообщения, реакции, патчи, результаты CI, шаги воркфлоу и одобрения ревью попадают в общий лог как подписанные события. Для человека и процесса действует одна модель личности и один журнал аудита. Git-активность передается событиями NIP-34, включая патчи, анонсы репозиториев и статусы.

Вопрос к истории проекта

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

Отдельная комната для ветки

Открываешь фича-ветку и получаешь канал. Туда приходят патчи и результаты CI, там же агент делает первый проход ревью, а коллеги реагируют на нужные фрагменты. Решение о слиянии остается рядом с материалами, на которых оно основано. Обычно этот контекст расползается между описанием пул-реквеста и забытым тредом в чате.

Подготовка релиза

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

В том же канале агенты могут проверять работу друг друга. Например, Claude Code предлагает изменение, а Codex его разбирает. Оба видят один тред, и человеку не приходится переносить сообщения между окнами. Это особенно полезно тем, кто каждый день работает с двумя кодовыми агентами.

С чего начать

Быстрее всего взять готовое десктопное приложение на Tauri и React из последнего релиза. Там есть сборки для macOS, Linux и Windows. Приложение по умолчанию подключается к ws://localhost:3000; другой адрес задается через BUZZ_RELAY_URL. Сборка для Windows пока не подписана, поэтому SmartScreen может показать предупреждение.

Для самостоятельного развертывания нужны Docker и Hermit. Вместо Hermit подойдут Rust 1.88+, Node 24+, pnpm 10+ и just:

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup
just build

# запусти в отдельных терминалах
just relay   # релей
just dev     # десктопное приложение

Релей будет доступен на ws://localhost:3000, а десктопное приложение откроется автоматически. Командный релей можно развернуть в Railway одним нажатием. Для VPS в deploy/compose/ лежит производственный Compose-набор с Postgres, Redis, MinIO и необязательным Caddy для TLS. Корневой docker-compose.yml предназначен только для разработки.

Агентам нужно задать BUZZ_PRIVATE_KEY и предоставить доступ к buzz-cli.

Что уже работает

По таблице статуса самого проекта уже работают релей, каналы, треды, личные сообщения, канвасы, медиа, поиск и аудит-лог. Готовы десктопное приложение, buzz-cli, ACP-харнесс для Goose, Codex и Claude Code. YAML-воркфлоу принимают триггеры от сообщений, реакций, расписания и вебхуков. Для Git есть события NIP-34 и серверная часть для размещения репозиториев.

Мобильные клиенты на Flutter для iOS и Android пока подключают. Для обязательного одобрения в воркфлоу инфраструктура уже есть, но связующий код еще не готов. В работе также находятся события жизненного цикла huddle-сессий. Репутация через сеть доверия между релеями и пуш-уведомления пока существуют только как идеи.

Перед переносом команды стоит помнить о двух ограничениях. Приватные каналы требуют явного членства, а REST или событийного API для управления участниками канала у релея пока нет. Задокументированный обходной путь состоит в создании каналов через create_channel в CLI, поскольку создатель автоматически становится участником. Кроме того, секретный ключ нигде не хранится и не восстанавливается. Потеря ключа означает потерю личности.

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

Что я бы сохранил без Buzz

  1. Отдельная личность упрощает проверку членства по сравнению с длинным массивом разрешений. Ключ не попадает в комнату, пока его туда не добавили.
  2. Когда разговор хранится рядом с рабочими материалами, обсуждение не теряет связь с кодом, прогоном CI и одобрением.
  3. Палец вверх может управлять процессом без отдельной инструкции и остается проверяемым, если записан как подписанное событие.

Источники: README block/buzz, документация buzz-acp, заметки Buzz о Nostr, NIP-01 и NIP-34. Статус продукта и число звезд проверены 11 августа 2026 года.