---
title: "Orca vs Herdr: изолировать задачи или держать сессии живыми"
canonical: https://maxtokens.ai/ru/posts/orca-herdr-agent-worktrees/
date: 2026-07-01
tags: [agents, terminal, infra, local]
description: "Orca изолирует задачи в worktree, Herdr собирает живые терминалы. Эти подходы полезны в разных рабочих режимах."
---
Orca нужен не для запуска ещё одного coding agent. Он нужен, когда несколько агентов работают параллельно, и важно, чтобы они не мешали друг другу: не правили одну рабочую копию, не делили состояние браузера и не смешивали результаты на ревью.

Herdr решает другую задачу: превращает один терминал в пульт управления для множества долгоживущих агентных сессий.

Orca и Herdr легко сравнивать как конкурентов, но это не самый полезный угол. Разница не в том, какой инструмент “лучше”, а в том, где он проводит границу: Orca — вокруг задачи, Herdr — вокруг терминальной сессии.

## Orca сначала изолирует задачи

Формулировка Agent Development Environment у Orca здесь важна. [Orca](https://www.onorca.dev/) — не просто приложение, которое запускает CLI-агентов: это среда для флота параллельных агентов, где агентом может быть любой CLI с вашей подпиской — Claude Code, Codex, OpenCode. Границу [доки](https://www.onorca.dev/docs) формулируют дословно: у каждой задачи — собственный git worktree, собственный терминал агента и собственная вкладка браузера.

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

Но главная причина такой границы — не гигиена, а гонка. README формулирует флагманский сценарий прямо: «Fan one prompt across five agents, each in its own isolated git worktree — compare the results and merge the winner». Один промпт веером на несколько агентов, у каждого свой worktree, затем трёхпанельный diff с флажками по hunks — и в финальную ветку уезжают только куски, пережившие сравнение. Перед мержем победителя стоит снять checkpoint worktree: у Orca это встроенная механика, а откат неудачного мержа — уже нет.

Вживую это выглядит менее академично. Вот сайдбар моей Orca в обычный день: семь проектов, под каждым — worktrees с бейджем primary, под worktree — агенты со статусами. Вкладки агентов Orca подписывает сама, по сути задачи: «Создать команду editsite для бота», «Найденные баги в предыдущей сессии». Непросмотренные результаты подсвечиваются, как непрочитанные сообщения, — привычка из мессенджеров внезапно оказывается правильным интерфейсом для флота.

<figure>
  <img src="/posts/orca-herdr-agent-worktrees/01-fleet-cockpit.png" alt="Окно Orca: слева сайдбар с проектами, worktree и агентами со статусами, в центре терминал агента с диффом и отчётом" width="1172" height="1280" loading="lazy" decoding="async" />
  <figcaption>Диспетчерская флота: проекты → worktrees → агенты. Этот кадр снял агент изнутри Orca — как именно, ниже.</figcaption>
</figure>

Гонку я проверил прямо во время работы над этой статьёй. Задача нарочно крошечная: в футере блога был захардкожен «© 2026» — сделать год автоматическим. Один промпт, два агента: `orca worktree create --agent claude --prompt "…"` и то же самое с `--agent codex`. Claude финишировал за 26 секунд. Codex — за минуту с небольшим, зато перед отчётом сам прогнал `git status` и `rg` по файлу. Диффы совпали до символа: `© {new Date().getFullYear()}`.

<figure>
  <img src="/posts/orca-herdr-agent-worktrees/03-race-working.png" alt="Гонка в Orca: терминал Claude с промптом и готовым диффом, в сайдбаре обе гоночные задачи — claude финишировал, codex ещё работает" width="1400" height="1529" loading="lazy" decoding="async" />
  <figcaption>Гонка в процессе: Claude уже финишировал, Codex ещё крутится — оба гонщика видны в сайдбаре.</figcaption>
</figure>

<figure>
  <img src="/posts/orca-herdr-agent-worktrees/04-race-diff.png" alt="Вкладка Base.astro (diff) в Orca: красно-зелёная строка 179 в worktree гонщика, обе гоночные задачи завершены" width="1400" height="1529" loading="lazy" decoding="async" />
  <figcaption>Финиш: дифф гонщика в его собственном worktree, обе задачи готовы.</figcaption>
</figure>

Ничья — тоже результат. На однострочках гонка вырождается: платишь дважды за одну и ту же строку. Окупается она там, где у решения есть пространство вариантов — UI-варианты, рефакторинги, миграции. Победителя я смержил в main — год в футере этого сайта теперь обновляется сам, — а проигравший worktree удалил, как этот же текст и советует ниже.

## Агент внутри Orca управляет самой Orca

Самое интересное в Orca не нарисовано в интерфейсе. В терминал каждого агента она прокидывает переменные окружения — `ORCA_WORKSPACE_ID`, `ORCA_PANE_KEY`, `ORCA_AGENT_LAUNCH_TOKEN` — и кладёт в PATH бинарник `orca`. Агент знает, что живёт внутри Orca, и может управлять ею теми же командами, что и человек: [CLI](https://www.onorca.dev/docs/cli/overview) описывает себя как «scripting a running Orca editor from any shell».

Несколько команд меняют картину целиком. `orca worktree ps` показывает флот: живые worktree, терминалы в каждом, непросмотренные результаты. `orca worktree create --agent claude --prompt "..."` рождает задачу из шелла — checkout, терминал и агент одной строкой. `orca terminal create`, `send` и `wait` позволяют агенту открыть соседний терминал, запустить тесты и дождаться маркера в выводе — та же идея, что socket API у Herdr, только поверх настольного стека.

Дальше — оркестрация. `orchestration send` и `reply` — межагентская почта. `orchestration task-create` и `dispatch` — раздача задач по терминалам. `orchestration gate-create` — decision gate: агент блокирует задачу до человеческого решения. «Спроси меня перед деплоем» превращается из строчки в промпте в объект с состоянием.

И computer use: `orca computer get-app-state --app <bundle>` возвращает accessibility-дерево окна любого macOS-приложения вместе со скриншотом, а `click`, `type-text` и `hotkey` позволяют агенту водить чужие приложения. Кадр сайдбара выше снят ровно так: агент, редактировавший эту статью, сфотографировал Orca её же командой из её же терминала.

Для UI-задач есть [Design Mode](https://www.onorca.dev/docs/browser/design-mode): тумблер в тулбаре встроенного браузера превращает курсор в пикер, и клик по элементу отправляет агенту сразу четыре контекста — HTML, computed CSS, кадрированный скриншот элемента и, при наличии dev-source-map, файл со строкой исходника. Вкладка браузера у каждой задачи своя, поэтому состояние UI не путается между попытками.

## Herdr держит управление в терминале

[Herdr](https://herdr.dev/) начинает с другой стороны. Это мультиплексор агентов, а не настольный ADE — я разбирал его [отдельно и из первых рук](/ru/posts/herdr-agent-multiplexer/). Его задача прямее: запускать coding agents из одного терминала, на любой машине, в настоящих терминальных сессиях, в том числе по SSH.

[Herdr](https://github.com/ogulcancelik/herdr) не нужно владеть вкладкой браузера, интерфейсом diff или всей доской задач, чтобы быть полезным. Он живёт там, где уже находится shell. Эта небольшая деталь многое говорит об архитектуре: Herdr делает живые терминальные сессии агентов видимыми, адресуемыми и устойчивыми.

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

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

Компромисс тоже понятен. Herdr упрощает управление агентными терминалами, но по умолчанию не выделяет каждой задаче отдельную изолированную копию репозитория. Для терминального контроля это нормально. Для борьбы с merge-путаницей — настоящая разница.

Если несколько агентов могут править пересекающиеся файлы, git-границу всё равно нужно создать отдельно: веткой, worktree или отдельной рабочей копией. Herdr решает другую часть проблемы — удерживает живые терминальные сессии и их состояние.

## Сравнение держится на границах

Полезное сравнение не сводится к «настольное приложение против бинарника». Это упаковка. Важнее другое: где инструмент разделяет состояние.

<img src="/posts/orca-herdr-agent-worktrees/two-boundaries-ru.svg" alt="Orca проводит границу изоляции вокруг каждой задачи; Herdr собирает много терминалов агентов под одним пультом" width="760" height="330" loading="lazy" decoding="async" />

| Вопрос | Orca | Herdr |
|---|---|---|
| Главная граница | задача / worktree | терминальная сессия |
| Сильная сторона | изоляция, гонка вариантов, diff review | живые PTY-сессии, устойчивость |
| Удалёнка | SSH worktrees, Remote Orca Servers (beta) | родная стихия: shell поверх SSH |
| Лучше для | параллельных вариантов, UI-итераций, ревью | долгих удалённых сессий, тестов, логов |
| Основной риск | слишком широкие задачи; аппетит к памяти на большом флоте | пересечение правок в одном репозитории |

Orca разделяет состояние на уровне задачи. У задачи есть worktree, терминал и вкладка браузера. Работу можно ревьюить как diff, потому что рабочее пространство с самого начала устроено под такой вывод.

Поэтому Orca естественнее всего ощущается там, где параллельно проверяются несколько исправлений, UI-вариантов, миграций или рефакторингов, а принять нужно только часть результата.

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

Эта граница хорошо видна в [Herdr compare](https://herdr.dev/compare/): Herdr находится на стороне живых терминалов и состояния агентов, а инструменты вроде Conductor и Emdash — на стороне изолированных worktree и diff review. Orca находится ближе к worktree-стороне этой схемы. Именно выбор между живой сессией и изолированной задачей здесь важнее списка названий.

Я бы выбирал Orca, когда единица ревью должна быть чистой. Я бы выбирал Herdr, когда единица сессии должна жить и оставаться доступной.

## Практические решения для настройки

Для Orca сначала стоит решить, насколько маленькой должна быть задача перед запуском. Orca выделяет каждой задаче worktree, поэтому расплывчатые промпты стоят дорого.

«Улучши настройки» — плохая задача для Orca.

«Добавь валидацию поля API key» — лучше.

«Попробуй компактную версию боковой панели настроек» — тоже лучше, потому что diff можно оценить сам по себе.

Не откладывайте CLI на потом. Наберите `orca --help` в терминале любого агента: если Orca прокинула окружение, агент уже умеет управлять worktree, терминалами и браузером. Команды ставятся и как versioned skills — `npx skills add`: orca-cli, computer-use, orchestration.

Вкладку браузера используйте намеренно. Если задача трогает UI — включайте Design Mode и отдавайте агенту элементы кликом, а не описанием. Если задача чисто backend, вкладка не нужна: worktree всё равно остаётся главной ценностью.

Следите за счётчиками подписок в статус-баре: Orca показывает пятичасовое окно и недельный лимит по каждому подключённому аккаунту, а hot-swap переключает флот на другой аккаунт без перелогина. Звучит мелочью ровно до момента, когда посреди гонки один аккаунт показывает 95% пятичасового окна.

<figure>
  <img src="/posts/orca-herdr-agent-worktrees/02-usage-meters.png" alt="Статус-бар Orca: два аккаунта с лимитами — 8% пятичасового окна у одного, 95% у второго" width="760" height="32" loading="lazy" decoding="async" />
  <figcaption>Два аккаунта в статус-баре. Когда один упирается в 95% окна, hot-swap перестаёт быть теорией.</figcaption>
</figure>

Обратная сторона флота — память. Orca — Electron-приложение, и на большом параллелизме это чувствуется: в трекере была история про [140 ГБ application memory на шести агентах](https://github.com/stablyai/orca/issues/7017) — она закрыта, терминальную производительность чинят почти в каждом релизе, но правило «не жадничай с параллельностью» всё равно дешевле любых фиксов. Сама Orca при этом бесплатна: MIT, [весь код в репозитории](https://github.com/stablyai/orca), подписки на агентов — ваши собственные.

Для Herdr начните в директории проекта и запустите [бинарник](https://herdr.dev/docs/quick-start/). Такая форма первого запуска показывает намерение инструмента: Herdr подключается к репозиторию, в котором вы уже работаете.

Я бы держал отдельную дисциплину веток или worktree вне Herdr, если несколько агентов могут править пересекающиеся файлы. Главное обещание Herdr — мультиплексирование терминалов, а не git-изоляция на задачу.

SSH раньше выглядел простым аргументом за Herdr, но это больше не так: у Orca есть [SSH worktrees](https://www.onorca.dev/docs/ssh) — checkout и агенты на сервере, редактор и diff локально — и бета-версия [Remote Orca Servers](https://www.onorca.dev/docs/remote-servers), где на удалённой машине живёт весь рантайм; облачного релея нет, сервер и клиент связываются через вашу сеть — LAN, Tailscale, SSH-туннель. Поэтому честное правило звучит не про удалёнку: Herdr — когда нужны живые PTY поверх терминальной среды, в которой вы уже живёте; Orca — когда нужна изоляция задач, где бы репозиторий ни находился.

## Рабочий процесс без смешивания слоёв

Мой базовый шаблон простой: Orca — для конкурирующих реализаций, Herdr — для устойчивых удалённых сессий.

В Orca не плодите варианты руками — запускайте гонку: один промпт на несколько агентов, каждому свой worktree, потом diff, флажки по hunks, мерж победителя и удаление проигравших. Перед мержем — checkpoint.

Главная дисциплина в том, чтобы prompt совпадал с границей ревью. Если человек не может просмотреть результат как один связный diff, задача была слишком широкой.

В Herdr называйте терминальные сессии по намерению: test runner, migration agent, refactor agent, investigation agent. Названия важны, потому что интерфейс здесь — терминал. Когда две сессии начинают править одни и те же файлы, остановитесь и создайте git-границу вручную до продолжения.

Оба инструмента могут жить в операционной модели одной команды, но я бы не складывал их друг на друга без причины. Терминальный мультиплексор внутри ADE с изоляцией задач может добавить больше интерфейса и состояния, чем процессу реально нужно.

Выберите владельца для каждого слоя. Orca отвечает за изолированные попытки. Herdr отвечает за координацию живых терминалов.

Практический совет простой: решите, что не должно столкнуться.

<img src="/posts/orca-herdr-agent-worktrees/pick-by-failure-mode-ru.svg" alt="Выбор: репо не должно столкнуться — начните с Orca; сессии не должны исчезнуть — начните с Herdr; оба — Orca, потом Herdr" width="760" height="400" loading="lazy" decoding="async" />

Если не должно сталкиваться состояние репозитория, начинайте с Orca.

Если не должны исчезать сессии, начинайте с Herdr.

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

*Выводы команд и скриншоты в этой статье снял агент, работавший внутри Orca, — включая кадры самой Orca, сделанные через её computer use.*