16 августа 2026, 11:00

Сегодня homelab получил не еще одного отдельного AI-агента, а общий рабочий контур для нескольких агентов.

Я развернул собственный сервер Buzz, подключил к нему Hermes Agent, Codex и OpenCode, создал закрытый канал для инфраструктуры и разделил работу на два режима: безопасную диагностику и явно подтверждаемые изменения.

Теперь это выглядит так:

пользователь
    |
    v
приватный канал #homelab в Buzz
    |
    +--> Hermes       — собирает факты
    |
    +--> OpenCode     — анализирует риски и варианты
    |
    +--> Codex        — готовит и применяет изменения
    |
    +--> Canvas       — хранит правила команды

Главная идея — не дать нескольким агентам бесконтрольно выполнять команды друг за другом. Они могут обмениваться результатами, но право на изменение инфраструктуры остается у владельца.

Зачем здесь Buzz

До этого Hermes уже работал в отдельной VM и использовал локальный OpenAI-compatible endpoint с моделью DeepSeek Search.

Но одного агента недостаточно, если хочется разделить роли:

  • один собирает состояние инфраструктуры
  • другой независимо анализирует результат
  • третий пишет код и выполняет согласованные изменения
  • вся переписка и история решений остаются в одном месте

Buzz стал для этого общей шиной и рабочим интерфейсом.

Это не просто чат с несколькими ботами. У каждого агента есть собственная Nostr-идентичность, набор разрешенных собеседников, модель, системные инструкции и способ запуска.

Развертывание Buzz

Для Buzz была подготовлена отдельная VM в Proxmox:

  • Ubuntu Server 24.04 LTS
  • 4 vCPU
  • 8 ГБ RAM
  • 80 ГБ NVMe-диск
  • Docker Engine и Docker Compose
  • QEMU Guest Agent
  • SSH только по ключам
  • fail2ban
  • автоматический запуск VM

Сам Buzz работает в Docker Compose. В составе контура используются:

  • Buzz relay
  • PostgreSQL
  • Redis
  • MinIO

Снаружи relay опубликован через отдельный nginx reverse proxy:

Buzz Desktop / агенты
          |
          v
wss://buzz.example.ru
          |
          v
      nginx + TLS
          |
          v
     Buzz relay VM

Для домена настроена DNS A-запись, а nginx получил сертификат Let's Encrypt. Отдельно проверялись обычный HTTPS и WebSocket upgrade с ответом 101 Switching Protocols.

Публичный белый адрес не требуется непосредственно на VM Buzz. Достаточно, чтобы внешний адрес маршрутизатора или reverse proxy принимал подключения на 443/tcp и передавал их во внутреннюю сеть.

Почему WebSocket важен

Обычной проверки главной страницы недостаточно.

Buzz relay использует WebSocket, поэтому рабочая цепочка требует:

  • корректного DNS
  • действующего TLS-сертификата
  • передачи заголовков Upgrade и Connection
  • достаточных таймаутов на nginx
  • доступности relay из разных подсетей

Если HTTPS открывается, но WebSocket не обновляется до 101, Desktop может выглядеть исправным, а агенты будут молчать или периодически переподключаться.

В нашем случае в логах действительно встречался сетевой timeout, но buzz-acp автоматически восстановил соединение и повторно подписался на каналы.

Подключение Hermes

Hermes работает постоянно на отдельной VM внутри homelab.

Для интеграции были собраны и установлены:

  • buzz-acp — мост между Buzz и Agent Client Protocol
  • buzz — CLI для чтения и публикации сообщений
  • buzz-dev-mcp — MCP-инструмент, через который агент отвечает в Buzz

Hermes запускается отдельным systemd-сервисом и подключается к relay по wss://.

Важные свойства сервиса:

  • автоматический перезапуск
  • собственная Nostr-идентичность агента
  • проверка владельца
  • разрешенный список авторов
  • автоматическое присутствие online/offline
  • публикация подписанного ответа обратно в канал

Полный тест выглядел просто:

@Hermes ответь одним сообщением:
подключение к Buzz работает

Сообщение дошло до Hermes, модель сформировала ответ, а relay принял событие, подписанное ключом именно этого агента.

Подключение Codex

Codex запускается локально на Mac через Buzz Desktop и адаптер codex-acp.

В конфигурации выбрана модель семейства GPT-5, включен пул параллельных ACP-процессов и добавлен MCP-инструмент Buzz.

Такой агент подходит для задач, где нужны:

  • работа с локальными репозиториями
  • изменение файлов
  • запуск тестов
  • подготовка конфигураций
  • реализация согласованных инфраструктурных изменений

Есть важное ограничение: локальный Codex доступен в Buzz, только пока Mac и Buzz Desktop запущены.

Hermes, наоборот, живет в homelab постоянно и не зависит от рабочего компьютера.

Подключение OpenCode и FreeDeepSeek

OpenCode тоже запускается через Buzz Desktop, но использует модель:

freedeepseek/deepseek-chat-search

Получилось полезное разделение стоимости и обязанностей:

  • FreeDeepSeek выполняет предварительный анализ и поиск
  • Codex занимается сложной реализацией
  • Hermes собирает состояние инфраструктуры

OpenCode стал вторым техническим мнением. Он не должен менять инфраструктуру, зато может проверить вывод Hermes, найти противоречия, оценить риски и передать Codex уже структурированный план.

Закрытая mesh-схема агентов

Сначала агенты были настроены в режиме owner-only.

Это безопасно, но мешает совместной работе: агент принимает задания только от владельца и игнорирует сообщения других агентов.

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

Поэтому была настроена закрытая mesh-схема через allowlist:

владелец <--> Hermes
    ^           |
    |           v
  Codex <--> OpenCode

В разрешенный список каждого агента входят только:

  • владелец
  • Hermes
  • Codex
  • OpenCode
  • служебный агент оформления, где это необходимо

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

Канал #homelab

Существующий приватный канал был превращен в постоянный рабочий канал #homelab.

В него добавлены:

  • владелец с ролью owner
  • Hermes с ролью bot
  • OpenCode с ролью bot
  • Codex с ролью bot

В теме канала зафиксирован рабочий процесс:

Hermes собирает факты
          |
          v
OpenCode анализирует
          |
          v
Codex готовит план
          |
          v
владелец подтверждает изменение

Подробные правила сохранены в Canvas канала. Благодаря этому они не теряются в истории сообщений и доступны всей команде как постоянная инструкция.

Диагностика и изменения — разные режимы

Самая важная часть настройки — разделение полномочий.

По умолчанию действует DIAGNOSTIC MODE:

  • читать состояние
  • собирать факты
  • анализировать логи
  • сравнивать варианты
  • готовить команды и план
  • ничего не менять

CHANGE MODE включается только сообщением владельца, которое начинается с:

ПРИМЕНИ: <конкретная цель и действие>

Перед изменением Codex должен указать:

  • точный объект изменения
  • ожидаемое влияние
  • способ отката
  • способ проверки результата

Сообщение Hermes или OpenCode никогда не считается разрешением на выполнение.

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

Безопасный SSH для Hermes

Просто выдать агенту обычный SSH-ключ от root было бы слишком опасно.

Вместо этого для Hermes создан отдельный ключ, а на принимающих узлах ключ записан в authorized_keys с принудительной командой и ограничением restrict.

Схема выглядит так:

Hermes
  |
  | отдельный SSH-ключ
  v
forced command wrapper
  |
  +--> summary
  +--> vms
  +--> storage
  +--> cluster
  +--> failed-units
  +--> buzz-status

Даже если Hermes попробует выполнить:

ssh node reboot

сервер не передаст reboot оболочке. Forced-command wrapper увидит неизвестное действие и завершится с отказом.

Разрешены только заранее определенные диагностические операции.

Команда homelab-diag

На VM Hermes появился единый интерфейс:

homelab-diag <target> <action>

Для Proxmox-узлов доступны:

homelab-diag pve summary
homelab-diag pve vms
homelab-diag pve storage
homelab-diag pve cluster
homelab-diag pve failed-units

Для VM с Buzz:

homelab-diag buzz01 summary
homelab-diag buzz01 buzz-status

Скрипт не принимает произвольную команду. Он проверяет и имя узла, и действие, после чего обращается к серверу с отдельным ключом и строгой проверкой host key.

На стороне Proxmox разрешенные действия преобразуются в фиксированные команды pvesh, pvesm, pvecm и systemctl --failed.

На VM Buzz разрешено посмотреть общую сводку системы и состояние Docker Compose, но нельзя перезапускать контейнеры или менять конфигурацию.

Как проверялась защита

Проверка состояла из двух частей.

Сначала разрешенные операции:

homelab-diag pve vms
homelab-diag pve2 storage
homelab-diag buzz01 buzz-status

Они успешно вернули список VM, состояние хранилищ и контейнеров Buzz.

Затем через тот же ключ была отправлена запрещенная команда.

Вместо выполнения сервер ответил:

Denied. Allowed diagnostics: ...
exit code: 126

Это важнее любого текста в system prompt. Инструкции модели полезны, но реальная граница безопасности должна находиться на стороне операционной системы.

Сквозной тест

После настройки в #homelab была отправлена задача:

@Hermes DIAGNOSTIC TEST:
проверь failed units на двух узлах Proxmox.
Ничего не изменяй.

Hermes:

  • получил упоминание через Buzz relay
  • вызвал homelab-diag
  • подключился к обоим узлам отдельным ключом
  • выполнил только разрешенную команду
  • опубликовал подписанный ответ в тот же канал

Результат:

На обоих узлах failed units не обнаружено.

На этом замкнулась вся цепочка от сообщения пользователя до реальной проверки инфраструктуры и ответа агента.

Как этим пользоваться

Обычная проверка:

@Hermes проверь состояние pve, pve2 и Buzz

Анализ результата:

@Макс_OpenCode проанализируй отчет Hermes
и перечисли риски по приоритету

Подготовка плана:

@Антоха_Codex подготовь план исправления,
но пока ничего не меняй

Применение:

ПРИМЕНИ: выполни согласованный план
только для указанного сервиса на указанном узле

Можно передать работу и по цепочке:

@Hermes собери факты и передай @Макс_OpenCode.
@Макс_OpenCode проверь риски и передай план @Антоха_Codex.

Но даже в этом случае Codex остановится перед изменением и будет ждать явного сообщения владельца.

Что получилось

Сейчас в homelab работает следующий контур:

  • собственный Buzz relay
  • TLS и WebSocket через reverse proxy
  • приватный канал #homelab
  • постоянный Hermes Agent
  • локальный Codex
  • локальный OpenCode с FreeDeepSeek
  • закрытые allowlist между агентами
  • роли и регламент в Canvas
  • отдельный read-only SSH-ключ Hermes
  • forced-command ограничения на серверах
  • явное подтверждение перед изменениями
  • автозапуск агентов вместе с Buzz Desktop

Это уже не набор разрозненных чат-ботов.

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

Что дальше

Следующий логичный этап:

  • добавить read-only проверки сетевого оборудования
  • оформить инвентаризацию VM и сервисов в Canvas или knowledge base
  • добавить проверку срока TLS-сертификатов
  • собирать краткий ежедневный health-report
  • подключить уведомления только при изменении состояния
  • хранить планы изменений и результаты проверок в отдельных threads
  • добавить резервное копирование конфигурации Buzz

Но даже в текущем виде система уже полезна: написать агенту в канал проще, чем каждый раз вспоминать адрес узла, нужную команду и расположение compose-проекта.

При этом агент не получает универсальный root shell и не может сам решить, что пришло время что-нибудь перезапустить.

Итог

Главный результат сегодняшней работы — не установка Buzz сама по себе.

Главный результат — управляемая граница между разговором и действием.

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

Для homelab это выглядит правильным компромиссом: AI помогает обслуживать систему, но не становится бесконтрольным администратором.