Мини-отчет мак-чайника: поставил через brew mlx-serve, загрузил пару моделей через UI (text, stt/tts, image, video). Офигел - всё работает и быстро! tps > 100! prefill - 2000!
Pi → непосредственно выполняет задачу
tmux → держит процессы и терминалы живыми
Pi Intercom → Pi-сессии находят друг друга, отправляют сообщения,
задают вопросы и ждут ответы
AgentMux пытается заменить tmux + Pi Intercom одной программой, а Pi оставить внутри.
Что именно он делает вместо них
1. Вместо tmux — собственные окна и запуск процессов
вы создаёте две панели 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 есть настоящий блокирующий протокол:
Вызывающий 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 действительно даёт сверх вашей связки
использовать единый 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)
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.
запусти 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)
Я забыл замерить, но кажется, тут почему-то быстрее нашлось решение. Но не намного. Хотя, по замерам бенчей, этот Призма-квант быстрее всех токены генерит: до 30 в сек доходит.
Запустил модель с порядочным квантом: Qwen/Qwen3.8-27B-FP8, ответ стал нормальным:
Evidence chain:
pstore/ramoops (/var/lib/systemd/pstore/console-ramoops-0) — the crashed boot’s last kernel console ends in an OOM storm at T+9.7h:
pi invoked oom-killer, Out of memory: Kill process 3721 (MainThread) score 510, victims: telegraph-mcp-p, MainThread (1.2GB vms), V8Worker
the memory hogs were the AI agent stack itself: pi sessions + MCP servers + litellm + docker on a 4GB box
В своё оправдание: этот призма-квант мне самый красивый двойной, горизонтальный (и рабочий) тетрис сгенерировал. Как говорится: не тот порядочный квант, что блестит. Хотя… кто его знает - может этот FP8 запуск что-то в прошлой сессиии Sol подглядел. Я, правда, постарался почистить. Но он не признаётся, пишет, что “всё сам!” 😄
Поиграл с “королём” в troubleshooting: микро-PC (типа Расбери) ребутнулся. Я озадачил rdtand/Qwen3.8-27B-PrismaAQUA-5.5bit-vllm (xhigh) и gpt-5.6-sol провести разбор полётов.
“Король” после 40 минут:
Prime suspect (moderate confidence) Kernel-side wedge under full-memory LLM load: 27B-class models (MixedInt4 / NVFP4 evals, PrismaQuant) ran on this 4 GB Nano last 2 days — 5–20 GB of model vs 4 GB DRAM + 2 GB zram swap…
Sol (5 мин):
Jetson перезагрузился из-за исчерпания оперативной памяти. Ядро трижды запустило OOM killer (Out Of Memory killer — механизм Linux, завершающий процессы при нехватке памяти), но Pi и его дочерние роцессы имели oom_score_adj=-1000 и не могли быть выбраны жертвой. Система перестала отвечать, после чего аппаратный watchdog перезапустил плату.
Король, превед! 😂 Но удалять пока не буду… Может пригодится.
Поедем на машине. Мойка — для машины, а не для твоих кроссовок. Пойдёшь пешком — через 50 метров огонит осознание, что рыхлая железная тварь стоит дома и требует, потом ещё 50 метров назад. На авто эти 50 метров — полминуты и одно свободное место у въезда. Сел, завёл, поехал.
Читал ИИ, долго думал…
П.С. Квин - для кода, для “пофилосовствовать” - Гемма-4
Мини-отчет мак-чайника: поставил через brew mlx-serve, загрузил пару моделей через UI (text, stt/tts, image, video). Офигел - всё работает и быстро! tps > 100! prefill - 2000!
🏆 Benchmark Complete
Похоже допилили этот фрейморк. Молодцы.
ГПТ не остановить:
Для AgentMux вашу связку нужно разложить так:
AgentMux пытается заменить
tmux + Pi Intercomодной программой, а Pi оставить внутри.Что именно он делает вместо них
1. Вместо tmux — собственные окна и запуск процессов
Вместо:
вы создаёте две панели AgentMux. Он сам запускает процессы Pi. По умолчанию используется:
AgentMux читает машинный поток Pi и самостоятельно рисует сообщения, вызовы инструментов и изменения файлов. Это не обычный интерактивный интерфейс Pi, показанный внутри терминала. Аналогично он запускает Claude Code, Codex, Gemini и другие CLI. (AgentMux Docs)
То есть здесь:
заменяется на:
2. Вместо Pi Intercom — MuxBus
AgentMux регистрирует агентов по именам и позволяет отправлять им сообщения.
Есть два основных варианта:
— немедленно записать текст в
stdinчужого агента;— оставить сообщение в почтовом ящике, чтобы агент забрал его асинхронно.
MuxBus может связывать разные AgentMux-процессы на одной машине, в локальной сети и через отдельно настроенный WAN-relay. (AgentMux Docs)
Например:
В отличие от Pi Intercom, получателем может быть не только Pi.
3. Добавляет хранилище конфигураций
Для каждого именованного агента AgentMux может хранить:
используемый harness и модель;
инструкции;
MCP-серверы;
skills;
переменные окружения;
привязанные credentials;
историю и собственные memory-файлы.
После этого можно повторно открыть условного
backend-reviewerс теми же настройками. (AgentMux Docs)4. Добавляет очередь и расписание
AgentMux имеет встроенную очередь заданий:
Также есть cron-задачи, которые периодически отправляют prompt определённому агенту. Агент может через API открыть редактор, запустить фоновый shell-процесс или создать новую панель. (AgentMux Docs)
Но AgentMux не придумывает задания для очереди. Кто-то должен их туда положить: пользователь, скрипт или другой агент.
Что ваша связка уже делает лучше
Общение Pi ↔ Pi
У Pi Intercom есть настоящий блокирующий протокол:
Вызывающий 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)Простота
Ваша система:
AgentMux — приложение с launcher, backend-sidecar, Chromium/CEF-интерфейсом, базой данных, собственным RPC, адаптерами harness-программ и MuxBus. Сам проект предупреждает, что находится в ранней alpha-стадии, возможны поломки, потеря состояния и несовместимые изменения. (AgentMux Docs)
Что AgentMux действительно даёт сверх вашей связки
Он имеет смысл при таких требованиях:
И вы хотите:
адресовать их через один канал сообщений;
видеть tool calls и diff в одном GUI;
использовать единый API
open / send / stop / status / output;хранить профили, инструкции, MCP и credentials централизованно;
отправлять сообщения между машинами;
иметь встроенную очередь и cron.
Pi Intercom ограничен Pi-сессиями на одной машине. (GitHub)
Итог
Для вашего случая:
AgentMux не закрывает важную отсутствующую функцию. Он преимущественно заменяет вашу простую терминальную систему более тяжёлым графическим приложением.
Он становится полезным, когда главная задача уже другая:
Поэтому AgentMux можно назвать meta-harness в техническом смысле: он приводит разные CLI к общим операциям
запустить / отправить сообщение / показать вывод / остановить.Но он не является «AI-руководителем»: он не решает самостоятельно, кому поручить задачу, как проверить результат и когда переделывать. Его документация прямо говорит, что панели независимы и контекст между агентами не передаётся, пока вы сами их явно не свяжете. (AgentMux Docs)
ГПТ сравнил:
В вашем сценарии Herdr, скорее всего, не нужен.
Связка уже закрывает основные задачи:
Pi Intercom умеет не просто печатать текст в чужой терминал. У него есть локальный broker, список активных Pi-сессий, их состояния, адресные
send, блокирующиеask/reply, доставка сообщений в контекст получателя и возможность автоматически запустить новый turn. (GitHub)Например:
Это уже гораздо ближе к реальному взаимодействию агентов, чем возможности Herdr.
Что изменится при установке Herdr
Herdr заменит эту часть:
на:
И добавит внешний API:
То есть внешний скрипт сможет сказать:
Также Herdr собирает состояния агентов в одном интерфейсе: какой работает, какой ждёт подтверждения, какой закончил. (Herdr)
Но для общения Pi ↔ Pi вам всё равно полезнее Pi Intercom. Herdr сам по себе не предоставляет такой же нормальный протокол
send / ask / replyс доставкой непосредственно в контекст Pi.Сравнение без абстрактных слов
(ппц, таблицу приходится как скриншот вставлять)
Где Herdr всё же может пригодиться
Допустим, у вас одновременно работают:
Pi Intercom связывает только Pi-сессии. Herdr может показать все эти процессы в одном списке и дать внешнему скрипту одинаковые команды:
То есть его преимущество — унифицированное внешнее управление разными CLI, а не более качественное общение агентов.
Итог
Для вашей конфигурации:
Herdr преимущественно дублирует
tmuxи часть отображения состояний.Он нужен только при конкретной дополнительной потребности:
Без этой потребности переходить с
tmuxна Herdr особого смысла нет. Более того, документация Pi Intercom прямо рассматривает Herdr лишь как опциональный способ открыть новую Pi-панель, когда подходящей сессии ещё нет; сама связь между Pi-сессиями от Herdr не зависит. (GitHub)Было бы интересно, если бы вы сравнили этот “харнес харнесов” Herd со связкой tmux + Pi+pi-intercom
С удовольствием! А какой end-point? )
Вот это меня и останавливает пока от Агента. Чую одним местом в какое “допиливание” это выйдет.
Вообще-то подержанная ультра м3 на 512к уже давно за 20к перевалила. Если найти вообще.
Через 18 часов: https://huggingface.co/Qwen/Qwen3.8-Flash-Next
Харнесы, прости хоспади, для харнеса. И сколько времени понадобилось для вайб-кодинга / вайб-дебагинга? Вы же не ручками писали эти приложения?
Да более-менее бесполезно. В реальной жизни, не на тестах, прибавка - 2-3 т/с. That was a nice try :(
Я забыл замерить, но кажется, тут почему-то быстрее нашлось решение. Но не намного. Хотя, по замерам бенчей, этот Призма-квант быстрее всех токены генерит: до 30 в сек доходит.
Update: приношу королю свои извинения.
— Не виноватая я! Это всё корявый квант!..
Запустил модель с порядочным квантом:
Qwen/Qwen3.8-27B-FP8, ответ стал нормальным:В своё оправдание: этот призма-квант мне самый красивый двойной, горизонтальный (и рабочий) тетрис сгенерировал. Как говорится: не тот порядочный квант, что блестит. Хотя… кто его знает - может этот FP8 запуск что-то в прошлой сессиии Sol подглядел. Я, правда, постарался почистить. Но он не признаётся, пишет, что “всё сам!” 😄
Поиграл с “королём” в troubleshooting: микро-PC (типа Расбери) ребутнулся. Я озадачил
rdtand/Qwen3.8-27B-PrismaAQUA-5.5bit-vllm(xhigh) иgpt-5.6-solпровести разбор полётов.“Король” после 40 минут:
Sol (5 мин):
Король, превед! 😂 Но удалять пока не буду… Может пригодится.
Он нас опередил: сам музон встроил в Тетрис, только я пока не понял откуда звуки берутся :)
А я попросил модельку, как профессионального UI дизайнера и художника, нарисовать качественного Чебурашку (мой любимый ЧебурБЕНЧ).
Результат через полчаса
не за что! Вот, только что тест закончился на 512к:
monitoring 500k prefill
Вот тут обсуждаем потихоньку: https://habr.com/ru/articles/1070694/
А промпт, где нормальный ответ был: Be concise, dude
Да уже все на 3.8 переходят :)
qwen-3.8-27b-unsloth-nvfp4
Рассуждение заняло 52 секунд(ы)
Читал ИИ, долго думал…
П.С. Квин - для кода, для “пофилосовствовать” - Гемма-4
П.П.С. с более адекватным system-prompt:
Рассуждение заняло 32 секунд(ы)
recipe
Log:
VRAM - 35,5Gb на каждой ноде (всего 2).
У меня первое впечатление как раз “вау”. Такого красивого тетриса мне еще ни одна модель локальная не генерила:
скриншот