Comments 21
Что за слово такое "сАбагенты"? Есть в русском языке только слово субагенты. Или, если хотите изобрести велик и новый англицизм, то тогда можно использовать что-то вроде "сабэйдженсы". 😆
мне казалось хабр не допускает нейрослопные статьи. длинные тире, неуместные англицизмы посреди предложения, внезапные неподходящие слова (что такое налог у агентов?)
Мне кажется статья вообще переводная, потому что фразы типа "Основной чат поднимает ребенка через..." очень странные )))
Тире всегда длинные. Коротких тире не бывает. Даже во времена FIDO лично я ставил два дефиса друг за другом, чтобы передать тире. И да, англицизмы тоже использую. В конце концов есть такие понятия, как профессиональный диалект и жаргонизмы. Ну а что касается неподходящих слов, так вы ещё с живыми людьми не общались. Слова это такие штуки, для одного они подходящие, для другого неподходящие. Помнится, один профессиональный боксёр называл нижнюю челюсть скулою. А если честно, вот эта вот охота на нейрослоп стала уже поднадоедать. Например, в ответ на мой комментарий, который я написал самолично, своими собственными руками с помощью слепого метода, меня обвинили в нейрослопизме на основании, что «живые люди так не говорят, они бы сказали по другому». И да, идея комментария тоже зародилась в моей собственной голове. БЯМы не подсказывали.
В итоге не понятно как правильно работать то, без субагентов быстрее или экономичнее? Или же даже сидеть на субагентах? Какие параметры брать чтобы было дешевле быстрее или лучше?
Без сабагентов в большинстве случаев
А чем лучше чем через субагенты?
Можно кинуть статью в любого ИИшного помощника и попросить ответтить на вопрос)
А так если вкратце то позволяет удержить сессии и более нативно вести оркестрацию, прям в контекстное окно докидывая вводные
Было бы интересно, если бы вы сравнили этот “харнес харнесов” Herd со связкой tmux + Pi+pi-intercom
ГПТ сравнил:
В вашем сценарии Herdr, скорее всего, не нужен.
Связка уже закрывает основные задачи:
tmux → процессы Pi не умирают, есть окна и панели
Pi Intercom → сессии находят друг друга и обмениваются сообщениями
Pi → выполняет задачи
вы/инструкции → определяете, кто кому что поручает
Pi Intercom умеет не просто печатать текст в чужой терминал. У него есть локальный broker, список активных Pi-сессий, их состояния, адресные send, блокирующие ask/reply, доставка сообщений в контекст получателя и возможность автоматически запустить новый turn. (GitHub)
Например:
Pi-planner:
intercom.ask(worker, "Реализуй retry и сообщи результат")
Pi-worker:
выполняет работу
intercom.reply(planner, "Готово, тесты проходят")
Это уже гораздо ближе к реальному взаимодействию агентов, чем возможности Herdr.
Что изменится при установке Herdr
Herdr заменит эту часть:
tmux
на:
Herdr server
И добавит внешний API:
herdr agent start ...
herdr agent prompt ...
herdr agent wait ...
herdr agent read ...
То есть внешний скрипт сможет сказать:
запусти Pi
отправь ему текст
дождись idle или blocked
прочитай экран
Также Herdr собирает состояния агентов в одном интерфейсе: какой работает, какой ждёт подтверждения, какой закончил. (Herdr)
Но для общения Pi ↔ Pi вам всё равно полезнее Pi Intercom. Herdr сам по себе не предоставляет такой же нормальный протокол send / ask / reply с доставкой непосредственно в контекст Pi.
Сравнение без абстрактных слов
(ппц, таблицу приходится как скриншот вставлять)
Где Herdr всё же может пригодиться
Допустим, у вас одновременно работают:
Pi
Claude Code
Codex
Gemini CLI
OpenCode
Pi Intercom связывает только Pi-сессии. Herdr может показать все эти процессы в одном списке и дать внешнему скрипту одинаковые команды:
запустить
отправить prompt
дождаться остановки
прочитать результат
То есть его преимущество — унифицированное внешнее управление разными CLI, а не более качественное общение агентов.
Итог
Для вашей конфигурации:
несколько Pi + tmux + Pi Intercom
Herdr преимущественно дублирует tmux и часть отображения состояний.
Он нужен только при конкретной дополнительной потребности:
«Я хочу управлять Pi, Claude Code, Codex и другими CLI одним внешним API и видеть их состояния в единой панели».
Без этой потребности переходить с tmux на Herdr особого смысла нет. Более того, документация Pi Intercom прямо рассматривает Herdr лишь как опциональный способ открыть новую Pi-панель, когда подходящей сессии ещё нет; сама связь между Pi-сессиями от Herdr не зависит. (GitHub)
ГПТ не остановить:
Для AgentMux вашу связку нужно разложить так:
Pi → непосредственно выполняет задачу
tmux → держит процессы и терминалы живыми
Pi Intercom → Pi-сессии находят друг друга, отправляют сообщения,
задают вопросы и ждут ответы
AgentMux пытается заменить tmux + Pi Intercom одной программой, а Pi оставить внутри.
Что именно он делает вместо них
1. Вместо tmux — собственные окна и запуск процессов
Вместо:
tmux new-window -n planner 'pi'
tmux new-window -n reviewer 'pi'
вы создаёте две панели AgentMux. Он сам запускает процессы Pi. По умолчанию используется:
pi --json
AgentMux читает машинный поток Pi и самостоятельно рисует сообщения, вызовы инструментов и изменения файлов. Это не обычный интерактивный интерфейс Pi, показанный внутри терминала. Аналогично он запускает Claude Code, Codex, Gemini и другие CLI. (AgentMux Docs)
То есть здесь:
tmux pane + обычный Pi TUI
заменяется на:
AgentMux pane + Pi в машинном режиме + интерфейс AgentMux
2. Вместо Pi Intercom — MuxBus
AgentMux регистрирует агентов по именам и позволяет отправлять им сообщения.
Есть два основных варианта:
inject
— немедленно записать текст в stdin чужого агента;
message
— оставить сообщение в почтовом ящике, чтобы агент забрал его асинхронно.
MuxBus может связывать разные AgentMux-процессы на одной машине, в локальной сети и через отдельно настроенный WAN-relay. (AgentMux Docs)
Например:
Pi-planner
↓ SendMessage
Codex-reviewer
В отличие от Pi Intercom, получателем может быть не только Pi.
3. Добавляет хранилище конфигураций
Для каждого именованного агента AgentMux может хранить:
используемый harness и модель;
инструкции;
MCP-серверы;
skills;
переменные окружения;
привязанные credentials;
историю и собственные memory-файлы.
После этого можно повторно открыть условного backend-reviewer с теми же настройками. (AgentMux Docs)
4. Добавляет очередь и расписание
AgentMux имеет встроенную очередь заданий:
положить задачу в очередь
→ свободный агент забирает её
→ продлевает lease во время работы
→ помечает выполненной
Также есть cron-задачи, которые периодически отправляют prompt определённому агенту. Агент может через API открыть редактор, запустить фоновый shell-процесс или создать новую панель. (AgentMux Docs)
Но AgentMux не придумывает задания для очереди. Кто-то должен их туда положить: пользователь, скрипт или другой агент.
Что ваша связка уже делает лучше
Общение Pi ↔ Pi
У Pi Intercom есть настоящий блокирующий протокол:
intercom({
action: "ask",
to: "reviewer",
message: "Можно менять публичный API?"
})
Вызывающий Pi останавливается, ждёт reply, получает ответ как результат tool call и продолжает текущий turn с этим ответом в контексте. Сообщения сохраняются в истории Pi. (GitHub)
В документированном API AgentMux есть SendMessage и непосредственный inject, но аналогичного встроенного блокирующего ask → reply → результат tool call я не вижу. Для такого поведения придётся самостоятельно договариваться о сообщениях-ответах или писать дополнительную логику.
Поэтому для Pi ↔ Pi Pi Intercom выглядит более специализированным и удобным.
Переживание SSH-разрыва
tmux специально построен как отдельный сервер: клиент отключается, а сессия и процессы продолжают работать; позже к ним можно подключиться снова. (GitHub)
AgentMux документирован как desktop-приложение, запускающее CLI как собственные дочерние процессы. Это не та же архитектура, что отделяемый сервер tmux. Поэтому не следует считать, что закрытие AgentMux эквивалентно tmux detach: гарантии сохранения живого процесса после полного закрытия приложения в документации нет. (AgentMux Docs)
Простота
Ваша система:
tmux
Pi
маленький локальный broker Pi Intercom
AgentMux — приложение с launcher, backend-sidecar, Chromium/CEF-интерфейсом, базой данных, собственным RPC, адаптерами harness-программ и MuxBus. Сам проект предупреждает, что находится в ранней alpha-стадии, возможны поломки, потеря состояния и несовместимые изменения. (AgentMux Docs)
Что AgentMux действительно даёт сверх вашей связки
Он имеет смысл при таких требованиях:
Pi-planner
Claude-implementer
Codex-reviewer
Gemini-researcher
И вы хотите:
адресовать их через один канал сообщений;
видеть tool calls и diff в одном GUI;
использовать единый API
open / send / stop / status / output;хранить профили, инструкции, MCP и credentials централизованно;
отправлять сообщения между машинами;
иметь встроенную очередь и cron.
Pi Intercom ограничен Pi-сессиями на одной машине. (GitHub)
Итог
Для вашего случая:
несколько локальных Pi
+ tmux
+ Pi Intercom
AgentMux не закрывает важную отсутствующую функцию. Он преимущественно заменяет вашу простую терминальную систему более тяжёлым графическим приложением.
Он становится полезным, когда главная задача уже другая:
связать разные CLI-агенты общим интерфейсом, каналом сообщений, конфигурацией, очередью и расписанием.
Поэтому AgentMux можно назвать meta-harness в техническом смысле: он приводит разные CLI к общим операциям запустить / отправить сообщение / показать вывод / остановить.
Но он не является «AI-руководителем»: он не решает самостоятельно, кому поручить задачу, как проверить результат и когда переделывать. Его документация прямо говорит, что панели независимы и контекст между агентами не передаётся, пока вы сами их явно не свяжете. (AgentMux Docs)
Ну это не харнесс. Но я попозже выпущу даже для себя сравнилку herdr<->orca<->superset
Смерть сабагентов в Claude и Codex