Как устроен RemoteHangar

Общая рабочая среда на вашем сервере

RemoteHangar разворачивается на инфраструктуре компании. Команда работает через браузер с общей конфигурацией агентов, подключениями и историей выполнения. Основа сервиса — Node.js под systemd и база SQLite.

Бей (от английского bay, «отсек ангара») — рабочее окружение агента: каталог проекта, домашний каталог, подключённые репозитории и очередь задач. У пользователя может быть несколько беев для разных проектов и процессов.

Для выполнения используются подключённые аккаунты с подписками или coding/token plans. Агент обращается к выбранному провайдеру модели и работает с инструментами через настроенные MCP-серверы. Запрос и необходимый контекст передаются провайдеру: сервер RemoteHangar и место выполнения модели — разные части системы.

Для работы с другими серверами можно установить коннектор на Go с подключением по mTLS. Он даёт файловые и shell-инструменты на выбранном хосте. Разрешённые действия и доступы определяются при настройке вашего процесса.

Один harness — для рабочих сценариев команды

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

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

Для разработки, проектных вопросов и ИТ-поддержки можно подготовить разных агентов и наборы инструментов. Централизованная настройка не означает выдачу всем одинакового доступа ко всем системам.

• Агенты: назначение, инструкции и формат результата
• Навыки и плагины: повторно используемые рабочие практики
• Наборы и MCP-серверы: инструменты для выбранного процесса
• Рабочий контекст: репозитории, документы и задачи

Песочница

Каждый процесс агента запускается внутри bubblewrap — песочницы на пространствах имён ядра Linux.

Внутри песочницы корень файловой системы смонтирован только для чтения. Запись открыта в рабочий и домашний каталог бея, в каталог /home, в кэши вложений и плагинов и в каталог памяти агента. Каталог /tmp у каждого процесса свой.

Повысить права агент не может: юнит systemd запрещает это флагом NoNewPrivileges, sudo нет, системные каталоги защищены флагом ProtectSystem=strict. Сам сервис видит /home только для чтения (ProtectHome=read-only), но песочница агента отдельно открывает /home на запись — это ограничение есть в списке на странице «Безопасность».

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

• Docker внутри бея включается отдельно, флагом --with-docker. Все беи делят один сокет Docker, а он даёт доступ к хосту.
• Терминал администратора работает вне песочницы, от имени сервиса.

Очередь задач

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

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

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

Проверки и человеческое ревью

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

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

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

Где лежат данные

Настройки, история выполнения и рабочие окружения находятся на вашем сервере. Стандартные каталоги приведены ниже; эффективные пути зависят от параметров установки. Рабочие каталоги размещаются в разрешённых корнях, например /opt/repos и /home. Необходимый контекст запросов получает выбранный провайдер модели.

API для ваших продуктов

Через API подготовленный помощник доступен порталу, help desk, боту или другому продукту компании. Backend приложения открывает сессию, передаёт сообщения и получает поток ответа и событий. Секретный токен RemoteHangar хранится на backend приложения. Описание OpenAPI и Swagger открываются по адресу /docs вашей установки при включённом API.

• Сессии: создать, отправить промпт, прервать, закрыть. Ответ приходит потоком SSE.
• Одноразовый запуск POST /v1/oneshot: платформа создаёт временный бей на один ответ.
• Ответ по JSON-схеме: в строгом режиме на /v1/oneshot платформа проверяет ответ по схеме и повторяет запрос до трёх раз.
• Ключи идемпотентности живут 24 часа.
• Токены со скоупами. По умолчанию токен живёт 90 дней, в базе хранится только его хеш SHA-256.
• Лимиты на каждый API-токен и на весь сервер. Три вида тайм-аутов: на весь ход, до первого события и на тишину в ответе.
• Файлы бея можно скачать списком или архивом tar.gz.

curl -N https://hangar.example.ru/v1/oneshot \
  -H "Authorization: Bearer $HANGAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Найди в репозитории неиспользуемые зависимости", "idempotency_key": "deps-2026-09-24"}'

Обновления и откат

Таймер systemd запускает remote-hangar update --if-idle. Обновление устанавливается только в окно обслуживания, которое вы задали, и только когда агенты свободны. Что агенты свободны, сервер проверяет дважды.

Манифест релиза подписан minisign. Ключа подписи нет на сервере, который раздаёт релизы. Перед установкой ваш сервер проверяет подпись и контрольные суммы. Если утилиты проверки на сервере нет, установщик только предупреждает; флаг --require-signature делает проверку обязательной.

Перед обновлением платформа снимает копию базы. Если после обновления сервис не прошёл проверку работоспособности, код и схема базы возвращаются к прежней версии автоматически.

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

Требования

Скрипт установки выдаём участникам пилота.

• Ubuntu 22.04, процессор x64, systemd, права root для установки. На Ubuntu 24.04 песочнице мешают ограничения пространств имён.
• Память и число одновременных задач подбираются по нагрузке, инструментам и числу активных агентов; проверяем в согласованном сценарии пилота.
• Диск: место для репозиториев, истории, инструментов, устанавливаемых версий и резервных копий. Объём зависит от состава вашего окружения.
• Доступ в сеть к провайдеру модели и к серверу обновлений. HTTPS-прокси поддерживается.