Я устал рулить десятками CLI AI-агентов и терминалов на разных машинах — навайбил Agent-Bridge
Привет. Меня зовут Вадим, в разработке я очень давно — поучаствовал во всём, в чём можно: стартапы, продуктовые команды, инфра и всё такое. Последнее время плотно живу в терминальных AI-агентах: Claude, Codex, и всём, что появляется каждую неделю.
В какой-то момент заметил — инструменты стали умнее, а способ работы с ними остался прежним. Поставил Claude Code — дал полный доступ и молишься, что не сломает систему. Не дал — натыкиваешь права по ходу дела. Хочешь нормальную изоляцию — нужны контейнеры или VM, к ним надо подключаться, пробрасывать порты, SSH-сессии, всё это утомительно.
Параллельно ещё и с самими сессиями бардак. Несколько машин, на каждой крутятся агенты и обычные терминалы с задачами, tui и другим добром. Открыл вкладку, запустил агента, переключился на другую машину, вернулся — вкладка мёртвая, контекст потерян, агент где-то работает (tmux привет).
Когда 4 машины, 12 сессий, и половина из них — AI-агенты, которые что-то пилят в фоне, нет ощущения контроля. Поэтому подумал и решил — нужна штука, которая решает обе проблемы: и изоляцию сред, и визуальное управление всем этим хозяйством — со статусами, переподключением из браузера, и чтобы не надо было жонглировать SSH-сессиями вручную.
В итоге — запилил решение для себя, показал знакомым бойцам — сказали жги в open source.
Кому лень читать, GitHub
Что такое AB
AB (Agent Bridge) — self-hosted визуальный воркспейс для персистентных терминальных сессий и AI-агентов (по версии GPT). Работает через браузер. Целиком. Из любой точки мира.
Задеплоили на сервер, открыли в браузере с ноутбука в кафе — и всё на месте. Открыли с телефона (версия в процессе) в метро — те же сессии, тот же канвас. Это не десктопное приложение, привязанное к одной машине. Это обычный webapp, доступный по URL. Никакого electron-монстра, никакого VPN-костыля для «доступа к рабочему столу». Поставили, получили адрес, работаем откуда угодно.
Немного терминологии, чтобы дальше не путаться:
-
Нода — сервер, VPS, Incus-контейнер, docker-контейнер, VM — любая машина, на которой крутится PTY-демон. Это вычислительный узел в AB.
-
Агент — AI-инструмент, работающий внутри терминала: Claude, Codex, Kilo, Qwen и т.д.
-
Сессия — конкретный терминальный процесс на ноде. На одной ноде может быть десятки сессий.
В перспективе — это история для распределённых команд. Несколько разработчиков, общий сервер с нодами, каждый заходит через браузер и видит свои рабочие среды.
Канвас — управление как в RTS
Это ключевая штука и то, чем AB отличается от всего, что я видел для вайб-разработки.
Бесконечная плоскость (вру, честнее — большая). На ней — окна. Каждое окно — живой терминал, агент, заметка, что угодно, компонентов пока мало, новые в процессе. Можно зумить, панить, двигать. Как в стратегии реального времени — вид сверху на всю инфраструктуру исполнения.
Внутри доски — естественный паттерн островов. Окна группируются по проекту или по задаче. Один остров — бэкенд проекта X: терминал с запущенным сервером, окно с Claude, который рефакторит, заметка с TODO и в том же духе. Другой остров — фронтенд. Третий — инфра. Отзумился — видна вся карта. Приблизился — фокусная работа в одном окне.
Ключевая вещь для повседневной работы: по окну, по иконке, по точке на миникарте — сразу видно, занята сессия или свободна. Не надо открывать каждый терминал и вчитываться в лог. Отзумился на полную — 20 иконок, и по цвету/индикатору понятно: вот эти три сессии ещё работают, эти две закончили, эта упала.
На миникарте то же самое — точки с индикацией состояния. Можно окинуть взглядом все ноды за секунду и понять, где что происходит.
Сейчас это базовый статус: busy / idle / error. В перспективе — более детальная статистика: время работы, прогресс задачи, потребление ресурсов, история состояний.
Не буду углубляться в feature list, всё есть в репозитории (на лендиге), а так, по сути, AB — это браузерный рабочий стол для всего «терминального».
Примеры использования, они же кейсы
Сценарий 1: удалённая машина как нода
Есть сервер. Запускаем SSH-визард деплоя — он спрашивает хост, ставит PTY-демон, возвращает всё, что нужно для подключения. Добавляем ноду через менеджер подключений — и удалённая машина становится управляемым endpoint на канвасе. Без ручной настройки конфигов и сервисов.
Сценарий 2: несколько проектов параллельно
5 репозиториев, 8 терминалов, 3 AI-агента работают в фоне. На канвасе всё видно: что активно, что idle, где какой проект. Тайлинг сеткой для обзора, раскрытие одного окна для фокусной работы.
Сценарий 3: ферма изолированных сред через Incus (LXD)
Помните проблему с изоляцией, упомянутую выше? Вот как она решается на практике.
Один физический сервер. На нём Incus (или LXD). Поднимаем полноценные системные контейнеры — каждый со своим docker, своим окружением, своим стеком. Агент внутри контейнера имеет полный root, но за пределы своей среды не выходит (в идеале). В каждом контейнере можно поставить что угодно — Go, Python, Node, docker-in-docker, что нужно проекту. И никакого жонглирования SSH — каждая нода доступна как отдельная доска в AB, переключение в один клик.
Суть связки: AB стоит на хосте (или в одном выделенном контейнере). В каждом Incus-контейнере крутится PTY-демон — каждый контейнер становится нодой. Общая папка через bind-mount между хостом и контейнерами — для обмена файлами, артефактами, секретами, если нужно.
Что это даёт:
-
Изоляция по проектам. Один контейнер — один проект (или один клиент, или один эксперимент). Что-то сломал — выкинул контейнер, поднял новый. Основная система не тронута.
-
Нормальный docker внутри. Incus системные контейнеры поддерживают вложенный docker. Это не docker-in-docker хак, это реально работающий docker daemon внутри контейнера. docker compose up работает как на обычной машине.
-
Масштаб. 10, 20, 50 контейнеров на одном сервере. Каждый — отдельная нода со своим PTY-демоном. Каждая нода — своя доска в AB. Переключение между ними в один клик.
-
Общая папка. Bind-mount директория видна и хосту, и контейнерам. Удобно для общих артефактов, конфигов, обмена между средами, реально удобно.
Где AB в экосистеме
AB не заменяет существующие инструменты — он закрывает другую нишу.
Tmux, Warp, Wave — отличные инструменты для работы с терминалом. VS Code Remote — отличный инструмент для работы с одной удалённой машиной. AB решает другую задачу: визуальное управление десятками персистентных (постоянных? ) сессий на нескольких машинах одновременно, из браузера, с мониторингом статусов и возможностью переподключения откуда угодно. И не в коем случае не нарушаем требования Антрофиков — не шарим доски друзьям, только для себя.
В общем, это не замена терминалу. Это слой над ним — для тех случаев, когда терминалов стало слишком много.
Что дальше
AB в активной разработке, но то, что есть, уже ипользуется и весьма успешно. Планов много, но если глобально то ближайший роадмеп примерно такой:
-
мобильный интерфейс — мониторинг и управление нодами/сессиями с телефона. На самом деле есть старая версия и она первоначально привела к этому решению, кому интересно пишите — расшарю. В парке повайбить вполне удобно было.
-
интеграция с Incus — управление контейнерами прямо из AB, не только подключение готовых нод
-
proxy-middleware слой — перехват и мониторинг данных из/в агентов, политики, метрики, логирование
Заключение
В общем всем, кто продержался до финиша — спасибо за внимание. Ссылки на репозиторий внизу, ну и если интересно — велкам допиливать, open source всё-таки.
Автор: vchin

