Один coding-агент в терминале ещё похож на обычный инструмент разработчика. Пять агентов, работающих над одним репозиторием, превращаются в операционную систему из веток, worktree, терминалов, pull request, CI-проверок и незакрытых review comments. Проблема уже не в том, умеет ли модель писать код. Проблема в управлении параллельной работой.
Agent Orchestrator — open-source desktop-приложение, которое пытается стать такой диспетчерской. Оно не заменяет Codex, Claude Code, Cursor или другой terminal agent. Оно создаёт вокруг них общий контур: изолированные рабочие каталоги, состояние сессий, живые терминалы, связь с pull request и циклы обратной связи от CI и ревью.
Это обзор по README, архитектурной документации и STATUS.md актуальной ветки main на 2 августа 2026 года. Я не проводил собственный нагрузочный тест, поэтому ниже отдельно отмечаю документированные возможности, ограничения и выводы из архитектуры.
Официальный скриншот: проекты слева, параллельные сессии в центре, состояние выбранной работы справа.
Какой именно слой добавляет оркестратор
Базовый цикл выглядит так:
- пользователь добавляет локальный репозиторий;
- создаёт одну или несколько agent sessions;
- для каждой сессии AO поднимает отдельный git worktree;
- выбранный agent CLI запускается в своём terminal runtime;
- локальный daemon наблюдает за сессией, pull request, CI и review feedback;
- desktop UI позволяет подключиться к терминалу и отправить follow-up нужному агенту.
Ключевая граница ответственности здравая: агент продолжает писать код, а оркестратор управляет окружением и маршрутизацией событий. Это снижает зависимость от конкретной модели. В документации заявлены адаптеры для 23 worker agent harnesses, среди них Codex, Claude Code, aider, opencode, Cursor, Copilot, Kimi и другие. Reviewer-контур уже: отдельно перечислены Codex, Claude Code и opencode.
Worktree — простая, но важная изоляция
Если два агента редактируют один checkout, конфликт возникает раньше Git: один процесс видит незавершённые файлы другого, formatter меняет общий diff, dev server запускается из неожиданного состояния. AO создаёт отдельный worktree и ветку для каждой сессии. В результате файловая система, terminal state и commit history разделены, хотя объекты Git остаются общими.
Это не решает семантические конфликты. Два агента всё ещё могут независимо изменить один API-контракт. Но конфликт становится обычной интеграционной проблемой, которую можно увидеть в pull request, а не случайной гонкой за рабочий каталог.
Хорошая постановка задачи для такого режима должна содержать границы файлов или интерфейсов, acceptance criteria и проверку. Оркестратор даёт изоляцию исполнения, но не придумывает безопасное разбиение работы.
Терминал остаётся главным источником правды
Desktop UI не скрывает worker за абстрактной карточкой. По документации к выбранной сессии можно подключиться через live terminal и увидеть фактический процесс вместе с кратким состоянием pull request.
Официальный скриншот: терминал агента встроен в инспектор выбранной сессии.
Это важно для доверия к системе. Статус working не объясняет, застрял ли агент на тесте, ждёт ли input или печатает большой diff. Возможность войти в терминал сохраняет путь ручного вмешательства и не заставляет диагностировать всё через производные статусы.
Под капотом daemon предоставляет terminal mux по WebSocket. На macOS и Linux он использует PTY с tmux attach, на Windows — loopback pty-host с ConPTY. События состояния идут отдельным потоком SSE. Такое разделение разумно: интерактивный terminal traffic не смешивается с долговечными событиями жизненного цикла.
Самая интересная функция — feedback loop
Запустить много агентов нетрудно. Трудно вернуть каждому правильную обратную связь. CI упал после push, ревьюер оставил замечание, ветка получила merge conflict — без оркестратора человек ищет нужный терминал и вручную пересказывает событие.
В STATUS.md сказано, что SCM observer уже опрашивает GitHub, использует ETag и семантическое сравнение, а lifecycle отправляет агенту nudges по CI failures, review feedback и merge conflicts. Это ближе к реальной оркестрации, чем простая сетка терминалов: внешнее событие замыкает следующий цикл работы.
Официальный скриншот: отдельный контур reviewer runs и возврата замечаний worker-сессии.
При этом документация проводит полезную границу. Desktop V1 показывает краткое состояние PR, названия упавших checks, ссылки и число незакрытых review comments. Полные логи CI и тексты комментариев не входят в этот API/UI-контракт. Значит, перед внедрением стоит проверить, достаточно ли summary вашему процессу и как агент получает подробности.
Browser preview для UI-задач
Для frontend-работы AO умеет закрепить preview target за конкретной сессией и открыть локальное приложение рядом с терминалом. У разных worker изолированы cookies и web storage; вкладки одного worker используют общий временный Electron profile.
Официальный скриншот: локальный preview находится в том же инспекторе, что и агентная сессия.
Документация перечисляет browser-команды для snapshot accessibility tree, click, fill, keyboard input, screenshot, console messages и page errors. Network capture выключен по умолчанию, ограничен по времени и не сохраняет body или чувствительные значения. Это сильная идея для target isolation: агент должен управлять браузером своей сессии, а не последним случайно активным окном разработчика.
Но browser automation увеличивает поверхность риска. Локальный preview может содержать тестовые credentials или быть подключён к внешнему backend. Перед включением стоит зафиксировать разрешённые домены, тестовые аккаунты и запрет на production mutations.
Что реально shipped, а что ещё нет
STATUS.md называет рабочим single-user local loop: Go daemon и Electron/React frontend соединены через HTTP, SSE и WebSocket; поток add project → spawn session → attach terminal → observe PR → merge работает end-to-end.
Среди подтверждённых частей:
- локальный loopback-only daemon;
- SQLite с миграциями и change-data-capture через
change_log; - lifecycle сессий: spawn, kill, restore, rollback, cleanup;
- GitHub PR observer и действия merge/resolve comments;
- notifications для
needs_input,ready_to_mergeи финальных состояний PR; - 23 agent adapters;
- сгенерированный OpenAPI-контракт и drift-check типов frontend.
Есть и явные незавершённые участки. Tracker adapter существует, но observer loop и синхронизация issue с agent lifecycle ещё не работают в runtime. Полные raw PR/tracker facts также не отданы live consumers и команде session get. Это хороший знак документации: roadmap не выдан за готовую функцию.
Установка и телеметрия
Проект рекомендует desktop build для macOS, Windows и Linux. Старый npm-пакет @aoagents/ao заморожен на версии 0.10.0 и оставлен для существующих пользователей; новый setup предлагается начинать с desktop-приложения.
AO отправляет анонимные usage events в PostHog. Session recording по умолчанию выключен; при временном включении локальные пути и URL редактируются. Чтобы полностью отключить передачу в собственной сборке, документация предлагает оставить VITE_AO_POSTHOG_KEY пустым. Для команды с закрытыми репозиториями это нужно решить до пилота, а не после первого запуска.
Код распространяется по Apache License 2.0. Локальная архитектура удобна для внутреннего эксперимента: репозиторий и терминалы не обязаны переезжать в отдельный SaaS-контур. Но интеграция с GitHub, agent CLI и их собственная телеметрия остаются отдельными вопросами безопасности.
Кому инструмент уже полезен
AO выглядит уместно, если команда одновременно выполняет несколько независимых задач в одном репозитории и уже использует pull request как интеграционную границу. Наибольшую ценность дадут:
- регулярные параллельные agent sessions, которые трудно отслеживать по терминалам;
- длинные задачи с CI/review feedback после первого ответа агента;
- UI-разработка, где preview должен быть связан с конкретным worktree;
- эксперименты с несколькими agent CLI без создания отдельной платформы под каждый.
Для одного разработчика с одной короткой задачей новый daemon, desktop UI и lifecycle могут быть лишним слоем. Не стоит вводить оркестратор только ради красивой доски. Его польза появляется там, где уже есть очередь, параллелизм и возврат внешних событий.
Чего не хватает для командного production-контура
Заявленный shipped loop — single-user и local. Из этого нельзя автоматически вывести multi-user tenancy, RBAC, централизованный audit log, квоты, approval policy или защищённый remote execution. Для организации эти требования остаются отдельным слоем.
Перед серьёзным внедрением я бы провёл ограниченный пилот на одном непроизводственном репозитории и проверил:
- восстановление daemon и сессий после перезапуска;
- корректность worktree cleanup без потери незакоммиченных изменений;
- маршрутизацию CI failure и review comment именно нужному worker;
- поведение при неизвестном результате merge или сетевом timeout;
- отсутствие секретов в telemetry, logs и browser capture;
- управляемость конфликтов, когда задачи затрагивают один контракт.
Agent Orchestrator интересен не количеством поддерживаемых моделей, а выбранной единицей управления: session связывает worktree, terminal, PR, review и browser target. Это уже не «запусти пять агентов», а попытка дать параллельной агентной разработке наблюдаемое состояние и замкнутый feedback loop. Пока контур локальный и однопользовательский, но именно поэтому его можно рассматривать как понятный пилот, а не как обещание готовой корпоративной платформы.