Herdr: диспетчерская для агентов в терминале

Herdr легко понять неправильно. По названию и по общему хайпу вокруг AI-инструментов может показаться, что это ещё один локальный раннер моделей или новая оболочка для агента — что-то рядом с Ollama, LM Studio, Claude Code, Codex или OpenCode.

Но нет. Herdr не запускает модели и не заменяет агента. Его задача проще: помочь не потеряться, когда в терминале одновременно запущено несколько агентных процессов. Я держу его открытым именно для этого.

Меня зацепила не только сама утилита, но и история проекта. Автор Herdr, Can Celik, говорит, что почти весь инструмент был собран с помощью кодинговых агентов. По его словам, до этого он не писал на Rust: он задавал архитектуру, описывал спеки и направлял работу, а код писали агенты.

Проверить это я не могу. Но сама идея интересная: инструмент для управления агентами, собранный при помощи агентов.

Дальше — как Herdr ощущается в реальной работе.

Проблема не в терминале. Проблема в количестве процессов

Пока агент один, отдельный инструмент не нужен.

cd ~/project
claude

Дали задачу, дождались ответа, пошли дальше.

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

С одним таким процессом жить можно. С пятью уже приходится постоянно следить, кто что делает и кто чего ждёт.

Один агент чинит баг. Второй гоняет тесты. Третий ждёт approve. Четвёртый смотрит логи. Пятый открыт в соседнем worktree, и вы уже не помните, он закончил или всё ещё ждёт вашего ответа.

Tmux и Zellij частично помогают: они сохраняют panes, позволяют отцепиться, вернуться, держать процессы на сервере. Но для tmux нет разницы между Claude Code, npm test, tail -f app.log и обычным shell. Всё это просто текстовые потоки.

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

Что такое Herdr и где он стоит

Herdr, если коротко, — терминальный мультиплексор для кодинговых агентов.

Он живёт внутри обычного терминала: Ghostty, Kitty, iTerm, WezTerm, Alacritty, SSH-клиент. Не открывает отдельный web dashboard, не тянет Electron и не заставляет переносить работу в новую среду.

Внутри у него знакомая модель:

• workspace — проект или большая задача;
• tab — режим работы;
• pane — конкретный терминальный процесс;
• agent — распознанная сессия pi, Claude Code, Codex или OpenCode внутри pane.

От tmux он берёт идею долгоживущих panes. От агентных инструментов — понимание, что внутри этих panes сидят не просто процессы, а агенты со своим состоянием.

Проще всего представить это как шкалу. С одной стороны — классические мультиплексоры вроде tmux, screen и Zellij. Они видят только терминальные потоки. С другой — десктопные агентные приложения и менеджеры вроде cmux или Warp, которые забирают рабочую среду себе.

Herdr находится посередине: остаётся в shell, но понимает, что в panes работают агенты.

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

Главное отличие от tmux: Herdr видит состояние агента

В Herdr сбоку есть список агентов. Для каждого видно состояние.

Главные состояния такие:

• blocked — агенту нужен ввод или подтверждение;
• working — агент работает;
• done — агент закончил, но вы ещё не посмотрели результат;
• idle — агент закончил, и вы уже посмотрели результат.

Разделение done и idle кажется мелочью, но в работе оно сильно помогает. «Готово, но не просмотрено» — ровно то состояние, которое обычно теряется между вкладками.

Workspace сворачивает состояние агентов до самого срочного. Сначала видно заблокированных, потом готовых, но не просмотренных, потом работающих, потом тех, кто вас не ждёт.

Без этого цикл знакомый: открыть одну вкладку, понять, что агент ждёт разрешения; открыть вторую — там тесты уже закончились; открыть третью — там агент всё ещё пишет; потом забыть, зачем открывали первую.

Herdr даёт общий экран: кто заблокирован, кто закончил, кто ещё работает.

С чего начать

Не с десяти агентов. Не с красивой схемы «planner → coder → reviewer → QA». Не с попытки сразу собрать команду агентов.

Сначала один проект и один агент.

Linux/macOS:

curl -fsSL https://herdr.dev/install.sh | sh
herdr --version
herdr

Если вы на macOS и используете Homebrew:

brew install herdr

Дальше:

cd ~/project
herdr
claude

Потом можно открыть split под тесты или логи:

npm test
# или
just test
# или
tail -f logs/app.log

Первый день нужен не для автоматизации. Он нужен, чтобы привыкнуть к модели.

Workspace — проект или большая задача. Tab — режим работы: agents, server, logs, review. Pane — один реальный терминальный процесс. Agent — конкретный агент внутри pane.

Простая раскладка может выглядеть так:

workspace: api
  tab: agents
    pane: claude
    pane: codex
  tab: server
    pane: just dev
  tab: logs
    pane: tail -f logs/app.log
  tab: review
    pane: git diff

Если всё свалить в одну вкладку, Herdr быстро станет тем же хаосом, только с рамками.

Мышь тут не стыдная

У Herdr есть горячие клавиши, и без них далеко не уедешь. Но он не требует сразу заучивать отдельную клавиатурную религию.

Можно кликать panes, tabs и workspaces, тянуть границы split-ов, пользоваться контекстным меню.

Минимальный набор клавиш на первые дни:

ctrl+b, c       новая вкладка
ctrl+b, v       split вправо
ctrl+b, -       split вниз
ctrl+b, h/j/k/l перейти между панелями
ctrl+b, q       detach

Этого достаточно, чтобы понять, нужен вам Herdr или нет.

Если потом захочется ощущения «как в обычном macOS-приложении», вокруг Herdr уже появились надстройки вроде native-shortcuts-herd. Она связывает Ghostty и Herdr, чтобы cmd+t, cmd+w, cmd+1..9, ctrl+tab ощущались привычнее.

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

Интеграции лучше поставить сразу

Herdr может распознавать агентов по процессам и экрану. Но если вы реально собираетесь работать через него, интеграции лучше поставить сразу:

herdr integration install pi
herdr integration install claude
herdr integration install codex
herdr integration install opencode
herdr integration status

Зачем это нужно:

• статусы становятся точнее;
• Herdr лучше понимает, кто working, кто blocked, кто idle;
• восстановление агентных сессий становится менее гадательным;
• сам агент получает контекст, что он запущен внутри Herdr.

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

Список поддерживаемых агентов шире, но именно pi, Claude Code, Codex и OpenCode выглядят как основные сценарии.

Есть неприятная, но полезная деталь: не запускайте tmux внутри Herdr-pane, а уже внутри tmux — агента. Тогда Herdr видит tmux, а не агента.

Если очень хочется оставить tmux, лучше сначала честно ответить, какую задачу он решает поверх Herdr. Часто это просто старая привычка.

Что сохраняется, а что нет

Здесь легко уйти в рекламную чушь, поэтому лучше разделить сценарии.

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

Detach/reattach — самый понятный и надёжный сценарий. Herdr server продолжает работать, panes и процессы остаются живыми, вы возвращаетесь позже.

Snapshot restore — после остановки и запуска сервера можно восстановить layout, cwd, tabs, panes и focus. Но произвольный убитый процесс сам не воскреснет.

Pane history — это история экрана, а не процесс. Она помогает увидеть, что происходило, но не заменяет живую агентную сессию.

Native agent session restore зависит от интеграций и от того, умеет ли конкретный агент сообщать session identity.

Есть ещё live handoff:

herdr update --handoff

Это самая интересная инженерная часть. Herdr пытается передать PTY file descriptors новому серверу, чтобы обновиться без убийства процессов. Старый сервер отдаёт владение живыми terminal panes новому.

Технически это намного интереснее обычного «перезапустите приложение». Но в документации это experimental/opt-in, поэтому строить на этом базовую гарантию не стоит.

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

Архитектура и зачем нужен socket API

Большая часть ощущения надёжности в Herdr идёт из одного решения: по умолчанию он подключается к фоновому серверу, а panes остаются реальными терминальными процессами.

То, на что вы смотрите, — тонкий клиент. Работа живёт в сервере. Live handoff — это передача PTY file descriptors от старого сервера новому.

Тот же сервер даёт socket API и CLI. За счёт этого Herdr становится не только интерфейсом для человека, но и точкой автоматизации. Через API можно создавать panes, запускать команды, читать output и ждать нужного состояния.

Это меняет сценарий.

Вы просите агента проверить проект. В нормальной Herdr-сессии он может открыть отдельную pane для тестов, запустить npm test или just test, открыть pane с логами, прочитать вывод, дождаться конкретного маркера и вернуть результат.

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

Но здесь важно не романтизировать. Статус done не должен становиться единственным источником истины. В одном из агентных навыков вокруг Herdr отдельно критикуют подход «просто жди, пока соседний агент станет done». Лучше ждать конкретный output marker или структурированный ответ.

Иначе multi-agent workflow быстро превращается в красивый polling.

Удалённая работа: сначала SSH

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

Самый простой путь:

ssh you@server
cd ~/project
herdr

Так Herdr запускается там же, где код и процессы.

herdr --remote host можно смотреть позже, когда нужен тонкий локальный клиент. Но начинать лучше с простого и понятного SSH. Меньше магии, меньше ложных ожиданий.

Что Herdr не делает

Он не запускает локальные модели. Для этого есть Ollama, LM Studio и другие инструменты.

Он не заменяет Claude Code, Codex или OpenCode. Он организует их терминальные процессы.

Он не даёт встроенный браузер для визуальной проверки интерфейса. Если агенту надо посмотреть страницу, понадобятся внешние инструменты: Playwright, Chrome DevTools, браузер, скриншоты.

Он не превращает плохой workflow в хороший. Если у вас нет понятной структуры задач, Herdr просто покажет этот хаос в нескольких panes.

Где будут проблемы

Проект молодой. Репозиторий появился в начале 2026 года, релизы идут быстро, preview-версий много. Поведение агентных CLI тоже меняется, поэтому detection и интеграции неизбежно будут ломаться и чиниться.

Windows на момент настройки был preview/beta. Для спокойной работы я бы начинал с macOS/Linux или с SSH на Linux-сервер.

К модели workspaces/tabs/panes нужно привыкнуть. Даже с мышью это новый слой управления, и первые пару дней он может раздражать.

Лицензия тоже может иметь значение для компаний. Herdr под двойной лицензией: AGPL-3.0-or-later либо коммерческая. Для личного использования AGPL чаще всего не блокер, но в корпоративном контексте такие вещи лучше проверять заранее.

Полезные GitHub-репозитории вокруг Herdr

Вокруг Herdr уже появились небольшие инструменты и обвязки. Это хороший сигнал: Herdr начали использовать не только «как написано в документации», а как основу для рабочих привычек.

Я бы разделил эти репозитории на четыре группы.

Комфорт. native-shortcuts-herd связывает Ghostty и Herdr под привычные macOS-шорткаты. herdr.nvim помогает тем, кто живёт в Neovim, ходить между окнами редактора и Herdr panes одним набором клавиш. Оба проекта про то, чтобы Herdr не ощущался отдельным островом рядом с редактором.

Навигация. awesome-herdr — каталог экосистемы: клиенты, MCP-обвязки, session- и worktree-инструменты, редакторские интеграции. Его стоит открыть, когда базовый Herdr уже понятен и хочется посмотреть, что люди прикручивают сверху.

Дисциплина. herdr-pm — более экспериментальный «технический PM» рядом с агентными вкладками. Идея в том, чтобы смотреть на состояние сессии, предлагать следующий шаг и не забывать, зачем агент вообще был запущен. Агентные навыки вокруг Herdr дают полезное предупреждение: не стройте multi-agent workflow на слепом ожидании done; используйте конкретные output markers и структурированные ответы.

Автоматизация. herdr-python-client, herdr-mcp, herdr-mesh и похожие socket/API-обвязки нужны для программного управления Herdr: создавать panes, читать вывод, запускать команды и собирать состояние из Python-скрипта, MCP-клиента или собственного оркестратора.

Эти репозитории интересны не сами по себе, а как направление движения. Herdr постепенно становится не просто терминальным мультиплексором, а локальным слоем, через который могут работать редактор, агенты, worktrees, MCP и собственные скрипты.

Кому Herdr нужен

Если у вас один агент и один проект, скорее всего, Herdr не нужен. Обычный терминал проще.

Если у вас несколько агентов, несколько worktree, сервер, логи и тесты, Herdr начинает иметь смысл.

Если вы часто возвращаетесь к терминалу и не понимаете, кто из агентов чего ждёт, — тоже.

Если вы хотите workflow, где агент сам открывает pane, запускает проверку, читает вывод и докладывает результат, Herdr становится полезнее обычного мультиплексора.

Я бы внедрял его постепенно:

1. Один проект.
2. Один основной агент.
3. Split под тесты или логи.
4. Detach/reattach.
5. Интеграция для агента.
6. Отдельные tabs под server, logs, review.
7. Второй агент только после этого.

Не надо начинать с десяти агентов. Так вы получите не «оркестрацию», а более дорогой хаос.

Почему вокруг него шум

Если убрать демо и красивую упаковку, причина простая: люди обсуждают Herdr не как «ещё один терминальный мультиплексор», а как ответ на новую бытовую проблему.

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

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

Вывод

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

Он остаётся в shell-мире, не уводит работу в hosted dashboard, показывает состояния агентов, держит panes, работает по SSH и даёт API для автоматизации.

Самая честная формула такая: Herdr нужен не всем. Но если вы уже вручную следите за несколькими сессиями pi, Claude Code, Codex или OpenCode, он закрывает очень конкретную дыру.

Не будущее разработки. Не революция. Просто удобная диспетчерская для агентов, которые уже живут в терминале.

Источники

• Репозиторий Herdr (Can Celik / ogulcancelik), вкл. авторскую рамку «built with agents»: github.com/ogulcancelik/herdr
• Herdr docs: herdr.dev/docs
• Herdr blog — coding agents are becoming runtimes: herdr.dev/blog/coding-agents-are-becoming-runtimes
• Herdr blog — live updates without killing your terminal processes: herdr.dev/blog/live-updates-without-killing-your-terminal-processes
• Better Stack Community, Stanley Ulili: betterstack.com/community/guides/ai/herdr-ai-agent
• FOSS Engineer: fossengineer.com/herdr-terminal-agent-multiplexer
• awesome-herdr: github.com/yigitkonur/awesome-herdr
• native-shortcuts-herd: github.com/yigitkonur/native-shortcuts-herd
• herdr.nvim: github.com/devxplay/herdr.nvim
• herdr-pm: github.com/yigitkonur/herdr-pm
• агентные навыки Herdr: github.com/hcaiano/skills, github.com/yigitkonur/herdr-claude-to-codex
• herdr-python-client (54rt1n): github.com/54rt1n/herdr-python-client