Базовый командный runtime для терминальных AI-агентов

Для соло-разработки на ИИ-агентах уже есть много готовых инструментов — не только голый tmux.

Agent Deck, AoE, Vibe Kanban и похожие решения помогают запускать много параллельных агентских сессий локально и удаленно, раскладывать их по проектам, видеть статусы и не теряться между окнами терминала. Сами вендоры тоже идут в эту сторону: например, в Claude Code появился /agent-view.

Но в командных сценариях проблема становится не количественной, а управленческой.

Когда с агентами работают несколько разработчиков, команде важно не «запустить 500 сессий» а иметь управляемость и масштабируемость.
Важно понимать, где и как сессии запускать, с какими правами агенты будут запущены, кто может сессии видеть, кто может подключаться, как дать лидам и сеньорам доступ к сессиям джунов для обучения.
Важно иметь стандартизированную среду выполнения и уметь масштабировать схему через инфру-как-код. 

Сегодня я расскажу как сделать базовый агентный runtime для команд от 2‑х человек:

• runtime (среда выполнения) — где и как запускаются агенты, сервера/права/управление;

• workflow (рабочий процесс) — как используются агенты. Сейчас не про это.

3 уровня зрелости runtime команд с агентами

• 0 — личный локальный режим: агенты на ноутбуке, локальный терминал;

• 0 — личный серверный режим: живучие сессии на удаленных серверах, tmux/zellij, /agent-view, Agent Deck;

• 1 — небольшие команды: разделение прав на уровне ОС, централизованное управление агентами на разных серверах, управляемый attach, базовый аудит;

• 2 — зрелые команды: продвинутая изоляция в контейнерах/VM, воспроизводимое окружение;

• 3 — enterprise: собственные модели/private cloud, PII/PD/DLP, политики, комплаенс, observability, интеграции.

Эта статья про переход с уровня 0 на уровень 1.

Disclaimer

1. Я хочу сделать эту статью полезной для широкой аудитории, поэтому не буду подробно погружаться в контейнеры и enterprise (уровни 2-3).

2. Описанный подход не заменяет sandbox, контейнеры, VM, DLP и корпоративные политики. Цели статьи — дать команде самую базовую гигиену для работы с агентскими сессиями.

3. Эта статья про работу с агентами, а не про защиту от злонамеренного разработчика с доступом к серверу. Поэтому я привожу здесь примеры с «NOPASSWD: ALL», но каждый такой пример сопровождаю комментариями.

TL;DR для небольшой команды

Минимальная рабочая модель:

1. Агенты живут на dev‑серверах, а не на ноутбуках;

2. Долгие сессии держит tmux;

3. Живучее подключение через Eternal Terminal;

4. Ккаждый сотрудник имеет своего linux‑юзера и запускает агентов от другого linux‑юзера;

5. Права агентов ограничиваются до минимально необходимых;

6. Поверх tmux делаем менеджер сессий, позволяющий лидам видеть сессии разных сотрудников на разных серверах и делать attach к ним;

7. Управление правами на видимость чужих сессий и подключение к ним должно быть гибким и очевидным, без раздачи общих ключей и root‑доступа;

8. События логируются и доступны для аудита.

Это не корпоративный уровень.
Там, где есть чувствительная инфраструктура и/или данные, я запускаю агентов как минимум в rootless-контейнерах.

Но сейчас мы про минимальную рабочую схему.

Почему не начать сразу с Docker?

Для команд, переходящих на разработку агентами, первая боль не в sandbox, а в хаосе сессий: непонятно, где и как запускать агентов, как это контролировать, как управлять. Если нет слоя управления сессиями, перенос хаоса внутрь контейнеров не спасет.

Агенты в контейнерах — это не бесплатно. Появляется много нюансов, за которыми кто-то должен следить. UID-маппинг, сетевые namespace (исходящий прокси, DNS, API-эндпоинты, сервисы), дублирование авторизаций, поддержка образов. Всё это решаемо, но это не первый шаг команды в агентский runtime.

1. Сервера

Вариант А. Каждому разработчику отдельный dev-сервер

Если агенты нужны, чтобы работать, а не «попробовать», дефолт — отдельный dev‑сервер или эквивалентно изолированный контур на разработчика.

Почему:

• нагрузка:

  • 4–7 одновременно работающих сессий с агентами на разработчика — нормальная картина, а не исключение;

  • сессии сами по себе могут выедать 12–16 GB RAM и 6–10 vCPU;

  • тяжёлые сборки, тесты и watchers съедают всё остальное;

  • много параллельных потребителей = драка за ресурсы;

• dev/stage стенды, внешние интеграции и сервисы требуют понятной изоляции прав и окружения;

• аккаунты и подписки проще контролировать, меньше рисков попасть под бан.

Вариант B. Общий dev-сервер на несколько человек

Вариант для начала проекта, обучения или лёгкой нагрузки.

Использовать только при выполнении базовых условий:

• минимум 2 linux-юзера на каждого человека: один — самому человеку, другой — его агентам;

• ограничение прав агентских юзеров на уровне ACL;

• auditd, journald, Monit или аналоги;

• лучше поставить лимит ресурсов на уровне systemd на каждого агентского юзера, тяжелые сессии у одного не должны забирать всю машину у остальных;

• если используется несколько учёток одного агента, рекомендуется как минимум иметь разные исходящие IP-адреса для каждой.

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

2. Подключение к серверам

2.1. Ключи

Разработчик Вася генерирует ssh-ключ у себя на ноутбуке:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Копирует публичную часть ключа на свой сервер dev-vasya:

ssh-copy-id -i ~/.ssh/id_ed25519.pub vasya@1.2.3.4

Заводит алиас в ~/.ssh/config:

Host dev-vasya
  HostName 1.2.3.4
  User vasya
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

После этого подключение — ssh dev-vasya.

Когда серверов много, удобно добавить автодополнение и fzf-меню по ~/.ssh/config, чтобы не держать алиасы в голове.

На серверах отключаем парольный вход и логин под root — оставляем только ключи:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Если в команде нет корп. VPN и практикуется прямой доступ к серверам, приватные ключи на личном ноутбуке должны быть защищены 2FA, системно или аппаратно: хотя бы Secure Enclave на macOS, Windows Hello / TPM на Windows.

2.2. et вместо ssh

Обычный ssh, которым разработчик подключается к серверу, отваливается при разрыве сети, уходе ноутбука в сон и так далее.

Когда открыты всегда разные вкладки с разными серверами, проектами и агентами, переподключаться — это боль.

Поэтому я подключаюсь не так: ssh dev-vasya

А так: et dev-vasya

Eternal Terminal (et, github) восстанавливает связь при разрывах соединения, в том числе долгих. Переключил VPN — сессии живы, открыл ноутбук после смены локации или следующим утром — всё продолжает работать.

Более популярный mosh пока плохо подходит для работы с агентами: он «рисует» экран сам и «предсказывает» ввод, а не ведёт себя как обычный ssh. Из-за этого хуже работают скроллинг, полноэкранный режим, терминальные интеграции. Eternal Terminal ближе к обычной SSH/PTY-сессии, поэтому агенты в нем живут комфортнее.

3. Runtime: tmux как база

Удаленный запуск агентских сессий в tmux уже лучше локального запуска: сессия живёт на сервере, не зависит от ноутбука и работает в стандартизированном окружении.

et dev-vasya
tmux new -s claude
claude

Но ручной tmux быстро превращается в хаос.
Через пару дней открываешь список сессий и видишь что-то такое:

tmux ls
claude: 1 windows (created Mon May  4 09:12:43 2026)
test: 1 windows (created Mon May  4 14:55:01 2026) (attached)
new: 2 windows (created Tue May  5 10:03:18 2026)
new2: 1 windows (created Tue May  5 18:41:02 2026)
prod-bug-final: 1 windows (created Wed May  6 23:17:55 2026)
fix-temp: 1 windows (created Thu May  7 08:22:11 2026)

Непонятно: какой проект, чей процесс, какой агент, что активно, что зависло, что можно убить и так далее.

Поэтому, нужен менеджер сессий сверху tmux. Но перед этим про права.

4. Идентичность и права

Базовая схема:

• у каждого человека есть свой Linux-пользователь для входа (human user);

• агенты авторизованы и запускаются под отдельными agent user;

• tmux-сессии живут в сокетах agent user;

• процессы, токены, конфиги и права не смешиваются;

• доступ лида/синьора к чужим сессиям выдаётся через явные sudo-правила к agent user, а не к human user;

• лиды ходят в сессии на других серверах со своим ssh-ключем, раздача sudo прав выполняется на каждом сервере независимо, но настройки раскатываются централизованно через принятый в команде тулинг (Ansible/Terraform/…).

4.1. Human user и Agent user

Важно не смешивать две роли:

• human user — человек, который подключился к серверу и управляет сессиями;

• agent user — от которого реально запускается агент: его tmux-сессия, процессы, токены и доступы.

Если запускать агента от того же human user, то агент будет обладать теми же правами, особенно если он запущен в permissive-режиме (—dangerously-skip-permissions, yolo). В таком случае радиус потенциального ущерба ограничен только правами human user.

В нормальной схеме это разные пользователи: human user управляет сессией, агент запускается от agent user с ограниченными правами.

sudo useradd -m -s /bin/bash vasya
sudo useradd -m -s /bin/bash vasya-agent
# Даём доверенному пользователю vasya права на работу от vasya-agent
echo "vasya ALL=(vasya-agent) NOPASSWD: ALL" | \
  sudo tee "/etc/sudoers.d/vasya-agent"
sudo chmod 440 "/etc/sudoers.d/vasya-agent"
sudo visudo -c -f "/etc/sudoers.d/vasya-agent" # проверка синтаксиса

На всякий случай, напомню: мы ограничиваем агента, а не пытаемся защититься от действий самого Васи. Поэтому здесь я даю примеры с NOPASSWD: ALL. Вася сможет выполнить любую команду от имени своего агентского пользователя, но не от root и не от других пользователей.

Сотрудник Вася будет запускать агента не прямым claude, а условно так:

sudo -u vasya-agent tmux new -s billing-api-claude
claude

Только это будет делаться одной кнопкой в обёртке над tmux (менеджере сессий, об этом в следующем разделе).

Если нужно, чтобы агент сам пушил в гит — стоит завести отдельный SSH-ключ (или fine-grained PAT) внутри vasya-agent, с минимальными правами под нужные репозитории. Не стоит пробрасывать ssh-agent (ForwardAgent yes или ssh -A) в агентского юзера, иначе vasya-agent потенциально получит лишние привелегии.

4.2. Гостевой доступ к сессиям

Тимлид должен видеть все агентские сессии своей команды и иметь возможность к ним подключаться, синьор — к сессиям джунов под опекой, сотрудники — только к своим сессиям.
Самый простой способ управлять этим — те же sudo-привилегии на уровне пользователей ОС.

# даём лиду Пете возможность видеть и подключаться к своим сессиям, а так же к сессиям Васи и Лены

echo "petya ALL=(petya-agent,vasya-agent,lena-agent) NOPASSWD: ALL" | \
  sudo tee "/etc/sudoers.d/petya-lead"
sudo chmod 440 "/etc/sudoers.d/petya-lead"
sudo visudo -c -f "/etc/sudoers.d/petya-lead" # проверка синтаксиса
Здесь снова NOPASSWD: ALL, это модель доверенного лида/синьора. Такой доступ эквивалентен полному доступу к agent-user сотрудника, а не только к tmux attach.

Получится так:

vasya
└─ sudo → vasya-agent → только свои сессии
lena
└─ sudo → lena-agent  → только свои сессии
petya (lead)
├─ sudo → petya-agent → свои сессии 
├─ sudo → vasya-agent → сессии Васи
└─ sudo → lena-agent  → сессии Лены

Лиду выдаются sudo-права на vasya-agent, а не на самого vasya.
Лид может присоединиться к сессии Васи, убить её, посмотреть процессы агента — но не становится самим Васей. SSH-ключи Васи, секреты и авторизации, личный .gitconfig — остаются у Васи. В логах процессов и git-коммитах действия лида останутся действиями лида. Это не про защиту от злого лида (он доверенный) — это про более чистую атрибуцию действий и про то, чтобы не сделать что-то от чужого имени по ошибке.

Смысл не в том, чтобы сделать «настоящий sandbox», а вот в чем:

• агент не получает те же доступы, что и человек: история команд в шелле, SSH-ключи, личные токены, случайные алиасы, доступы к другим проектам и home directory и т. д.;

• радиус потенциального вреда от агента ограничен правами agent user, а не разработчика;

• ограничения ресурсов и прав настраиваются, не затрагивая сотрудников;

• исходящий маршрут и сетевые доступы агента легче развести отдельно от пользовательских — полезно при региональной недоступности;

• окружение агента воспроизводимо: он не подхватывает случайный alias или rc-файл из личного shell разработчика;

• лид/сеньор получает доступ к сессиям сотрудников, не получая их идентичности;

• в логах действия агента отделены от действий человека.

Ещё лучшая практика — изолировать работу в rootless Docker/Podman или ВМ. Но для быстрого старта, для небольших команд и dev-серверов без чувствительных данных ограничения прав агентов на уровне ОС может быть достаточно.

Это совсем не корпоративный уровень безопасности.
Но это намного лучше, чем один общий пользователь.
Любой dev-сервер быстро становится местом, где есть доступ к репозиториям, персональным данным, секретам, внутренним API и токенам.

5. Слой управления: менеджер tmux-сессий

tmux не знает контекст агентских сессий: какой проект, кто владелец, какой агент и так далее.
Тем более, когда dev-серверов множество, он не помогает свести все сессии из них на один экран.

Поэтому нужен тонкий слой поверх tmux, который добавляет всю эту семантику.

5.1. Готовые решения

Для соло-разработки уже есть множество хороших решений: Agent Deck, AoE, Vibe Kanban, CCManager и другие.
Большинство из них поддерживает разных агентов. Agent Deck и AoE поддерживают запуск сессий в докере. Agent Deck поддерживает работу со своими сессиями на других удалённых серверах.

Сами AI-вендоры тоже работают над инструментами управления сессиями из одного окна. Недавно в Claude Code появился /agent-view, хотя мультиагентность и поддержку нескольких персональных подписок в одном окне вряд ли завезут.

5.2. Командные сценарии

Для командных сценариев важны не красивые списки сессий, а ограничения:

• запуск агентов разными пользователями от правильных учёток с ограниченными правами;

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

• возможность видеть и подключаться к нужным своим и чужим сессиям, запущенным на разных серверах, учитывая права;

• контроль нагрузки на сервера;

• отсутствие необходимости раздавать всем чрезмерный доступ или общие ключи;

• логирование и аудит.

Важно не «как одному человеку запустить 30 агентов», а «как команде дать управляемый runtime».

Для небольших команд я сделал простую TUI-обёртку на Python+Textual (uxon, github). Для более сложных сценариев (контейнеры, enterprise) это всегда кастом.

Вы можете использовать мой скрипт или сделать свой менеджер сессий поверх tmux в Claude за 1-2 вечера, если будете понимать требования, которым он должен соответствовать.

5.3. Что должно быть в менеджере сессий

На мой взгляд, непосредственно в UI (TUI) может быть достаточно следующих колонок:

• Сервер

• Проект/Worktree

• Агент

• От кого запущен (agent user)

• Статус активности (активная / простаивает Х времени)

• Ресурсы (CPU/RAM)

• Действия (присоединиться/убить)

5.4. Как видеть сессии на других серверах?

На каждом сервере, куда лид Петя должен ходить, заводится отдельный linux-пользователь petya, и ему выдаются sudo-права к нужным agent user:

Локальный petya получает SSH-доступ к удалённым petya по ключу:

petya-laptop: et dev-petya # Петя подключается с ноутбука к своему серверу
petya@dev-petya: et dev-vasya # Со своего сервера ему доступен сервер Васи
petya@dev-vasya: sudo -iu vasya-agent tmux ls # Петя видит AI-сессии Васи
petya@dev-vasya: sudo -iu vasya-agent tmux attach -t backend-debug # Петя может подключиться к выбранной сессии

Менеджер сессий должен делать эту работу «на фоне», чтобы Петя в TUI увидел и локальные, и удаленные сессии. В том числе чужие, запущенные в чужих агентских юзерах (vasya-agent, lena-agent) к которым юзер petya на удаленных серверах имеет sudo-доступ.

Петя не получает «магический» общий доступ ко всем агентам на всех машинах.
На каждом сервере доступ задаётся обычными средствами ОС: завели пользователя petya, положили ему SSH-ключ, выдали конкретные sudo-права к нужным agent user. Раскатывается это как обычная инфа-как-код — через Ansible, Terraform/OpenTofu или другой принятый стек.

В предлагаемой схеме, чтобы отозвать у Пети доступ к сессиям Васи, нужно отредактировать sudoers на сервере Васи — больше нигде.
Звучит примитивно, но именно отсутствие центральной точки снимает большинство вопросов про «а как это всё централизованно админить».
Централизованно ведется раскатка конфигов (Ansible/Terraform), а полномочия валидируются локально на каждом сервере обычным sudo.
Менеджер сессий поверх — клиент, который ходит по ключу и спрашивает у каждого хоста, что ему доступно.

6. Как это выглядит в работе

Для рядового разработчика

• Разработчик заходит на сервер: et dev-vasya

• Открывает менеджер сессий: uxon (или ваш вариант)

• Видит свои сессии, в каких папках запущены, статус, нагрузку на сервер.

• Подключается к нужной, или создаёт новую и работает.

• Завершает неактуальные сессии одной кнопкой.

Для лида

Лид/синьор, открывая менеджер сессий, видит:

• свои сессии на этом сервере (как и рядовой разработчик);

• сессии коллег, к агентским юзерам которых у него есть sudo без пароля;

• свои и чужие сессии на серверах, заданных в конфиге, куда у него есть доступ по ssh по ключу;

• может завершать не только свои, но и чужие неактуальные сессии.

Обучение новичков и помощь коллегам

Новичок открывает агента.
Лид/синьор созванивается с новичком без видео и демонстраций экрана.
Подключается к той же сессии и работает в ней одновременно с новичком, показывая лучшие практики и фасилитируя их использование.

Коллега просит: «покажи, как использовать плагин для ревью архитектуры».
Лид открывает сессию, показывает «как надо» и «как не надо».

7. Про «зрелый» и enterprise-уровни

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

Контейнеры — не «зрелый» и не enterprise-уровень сам по себе.

Если внутрь контейнера проброшены SSH-ключи, креды, Docker socket, вся домашняя директория и неограниченная сеть, это не изоляция, а переупаковка старых рисков.

Смысл в том, что сессии агентов запускаются не в общем shell на сервере, а в заранее описанном окружении с понятными границами:

• какой image/template используется;

• от какого runtime user выполняются команды;

• какие команды требуют явного подтверждения;

• какие директории смонтированы внутрь;

• куда агент может ходить по сети;

• какие лимиты CPU/RAM/диска заданы;

• сколько сессия может жить без активности;

• какие логи и артефакты сохраняются;

• что удаляется после завершения.

Лучше дать агенту больше свободы внутри ограниченного runtime, чем запускать его с ограниченными правами в общем окружении dev-сервера.

На enterprise-уровне поверх этого могут появляться кастомные агенты на кастомных моделях, централизованные политики и аудит, контроль чувствительных данных, DLP, observability, квоты, SIEM/SOC, SDLC и так далее.

8. Что дальше

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

Он не делает разработчиков лучше, код качественнее, продукт ценнее, а команду — автоматически AI-native или agent-first.

Ещё нужны или могут быть нужны:

• новые процессы и правила команды разработки, выстроенные вокруг агентов;

• на порядок более строгие требования к архитектуре и коду, чем до использования агентов;

• общие и специализированные наборы правил для агентов, skills/plugins/hooks;

• кастомные MCP для интеграций с внутренними системами и документацией;

• новый git-flow под агентов;

• автоматизированные ревью комитов и PR агентами как часть CI;

• безопасность, меры по защите чувствительных данных;

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

• аудит, логи, мониторинги;

• SSO/RBAC, observability;

• полная смена подхода к разработке продуктов и управлению требованиями, если хочется ускорять не только разработку.

Если тема интересна, следующую часть могу посвятить уровню 2: как запускать агентские сессии в rootless Docker/Podman и какие нюансы нужно предусмотреть. Либо — рассказать про то, как можно менять процессы в командах, чтобы работа с агентами в них адекватно встраивалась.

А пока: надеюсь, было полезно. До новых встреч!