Symphony от OpenAI: открытый оркестратор ИИ‑агентов поверх таск‑трекера — VogueTech

Что нового

OpenAI открыла исходники Symphony — минималистичного оркестратора ИИ‑агентов для разработки, который превращает таск‑трекер (в примере — Linear) в «панель управления» кодящими агентами Codex.

Ключевые факты:

Symphony — это в первую очередь SPEC.md: текстовая спецификация, по которой любой кодовый агент может сам собрать реализацию.
OpenAI использует Symphony внутри компании и зафиксировала рост числа смёрженных pull request на отдельных командах до 500% за первые три недели.
Оркестратор раздаёт каждому открытому таску отдельного агента, который:
- анализирует кодовую базу, Slack, Notion;
- строит план реализации и дерево подзадач с зависимостями (DAG);
- пишет код, создаёт PR, следит за CI, делает ребейзы, чинит конфликты и flaky‑тесты;
- может сам создавать новые задачи, если видит улучшения.
Референсная реализация написана на Elixir и использует Codex в headless‑режиме Codex App Server через JSON‑RPC.
Спецификация проверена реализациями на TypeScript, Go, Rust, Java, Python, Elixir — Codex смог собрать рабочие версии на всех языках.
Symphony не зависит от внутренних репозиториев OpenAI и от конкретного MCP‑адаптера Linear: ядро — это SPEC.md + WORKFLOW.md с описанием процесса разработки.

OpenAI прямо говорит: Symphony — не продукт «как есть» с поддержкой, а референсный шаблон, который компании могут адаптировать под свои стеки, таск‑трекеры и агентные системы.

Как это работает

Смена единицы работы: не сессия, а задача

До Symphony инженеры OpenAI вручную управляли несколькими сессиями Codex: ставили задачи, проверяли ответы, перенаправляли агента. На человека комфортно приходилось 3–5 активных сессий, дальше контекст‑свитчинг убивал продуктивность.

Symphony меняет точку фокуса: вместо «сессий» и отдельных PR система работает вокруг тасков в issue‑трекере:

каждый открытый таск в Linear получает собственного агента;
сам Linear становится «control plane» — единственным интерфейсом управления работой агентов;
агент живёт столько, сколько живёт задача, и постоянно синхронизируется с репозиторием и CI.

DAG задач и параллельное исполнение

Типичный сценарий:

Человек создаёт задачу в Linear: «Проанализируй кодовую базу, Slack, Notion и предложи план реализации фичи/миграции».
Агент строит план и генерирует дерево задач с зависимостями (DAG).
Symphony запускает агентов только на тех задачах, которые не заблокированы зависимостями.
Работа идёт параллельно, но строго уважает зависимости.

Пример из OpenAI: апгрейд React был помечен как заблокированный миграцией на Vite. Агенты начали обновлять React только после завершения миграции.

Агенты как «сотрудники» с целями, а не как жёсткий стейт‑машин

Первая версия подхода в OpenAI ограничивала Codex задачей «просто реализуй тикет». Это оказалось слишком узким использованием:

Codex умеет создавать несколько PR, читать ревью и дорабатывать код.
Агенты могут закрывать старые PR, собирать отчёты по выполненной/брошенной работе.

В итоге OpenAI перешла к модели «объективов»:

агенту дают цель уровня «доведи эту задачу до состояния Merged по нашему workflow»;
Symphony даёт инструменты: gh CLI, доступ к логам CI, функции для работы с Linear, DevTools, тестами;
агент сам решает, какие шаги сделать, чтобы прийти к цели.

SPEC.md и WORKFLOW.md вместо сложной надстройки

В открытом репозитории Symphony главное — это не код, а документы:

SPEC.md описывает саму идею оркестрации: как агенты выбирают задачи, как взаимодействуют с таск‑трекером и репозиторием, какие статусы задач и событий существуют.
WORKFLOW.md фиксирует процесс разработки в конкретной команде:
- как брать задачу в работу;
- как оформлять PR и связывать его с задачей;
- когда переводить тикет в «Review», «Merging» и т.д.;
- какие артефакты прикладывать (например, видео‑демо, self‑reflection).

Раньше этот процесс существовал неявно в головах разработчиков. Теперь он формализован, и Symphony гарантирует, что агенты его соблюдают. Изменили процесс — обновили WORKFLOW.md, агенты подстроились.

Elixir‑реализация и Codex App Server

Референсный код Symphony написан на Elixir. OpenAI выбрала его именно из‑за сильных примитивов для конкуренции и супервизии процессов — когда «код за тебя пишет ИИ», можно позволить себе язык, который оптимален под оркестрацию.

Codex запускается в режиме App Server:

это headless‑режим Codex с JSON‑RPC API;
можно программно создавать сессии, отправлять сообщения, реагировать на ответы;
не нужно городить обвязку вокруг CLI или tmux.

Пример использования в Symphony:

основной агент общается с Codex App Server;
при необходимости создаёт субагентов под отдельные задачи;
через dynamic tool calls даёт им доступ к функции linear_graphql, которая ходит в Linear API;
при этом токен Linear не утекает в контейнеры субагентов и не требует MCP.

Эволюция Symphony внутри OpenAI

Первая версия — сессия Codex в tmux, которая опрашивала Linear и спаунала субагентов. Работало, но было нестабильно.
Вторая версия — встроена в основной репозиторий, который уже был подготовлен под агентов (harness, тесты, навыки). Symphony просто связала существующие компоненты.
Дальше OpenAI начала использовать Symphony для разработки Symphony:
- базовый функционал реализовали с помощью Codex;
- потом просили Codex реализовать SPEC.md на разных языках (TS, Go, Rust, Java, Python, Elixir), чтобы найти неоднозначности в спецификации;
- по итогам убрали лишние зависимости от конкретных репо и MCP Linear.

Сейчас ядро Symphony — это простой, минимум‑зависимый подход: таск‑трекер + описанный workflow + Codex App Server.

Что это значит для вас

Когда Symphony полезен

Symphony имеет смысл, если вы:

уже используете кодящие агенты (Codex или аналогичные) и хотите масштабировать их без ручного «микроменеджмента»;
живёте в крупном монорепозитории, где:
- CI долгий и хрупкий;
- ребейзы и конфликты — ежедневная рутина;
- доведение PR до merge отнимает больше сил, чем сама реализация;
хотите уменьшить стоимость экспериментов:
- быстро пробовать идеи и архитектурные изменения;
- отбрасывать неудачные ветки без чувства потраченного впустую времени;
готовы формализовать процесс разработки в WORKFLOW.md, чтобы агенты могли в нём ориентироваться.

Практические сценарии:

Спекулятивные фичи и рефакторинг. Создаёте тикет «попробовать оптимизировать X» — агент строит план, пишет код, запускает тесты. Если результат не нравится, вы просто закрываете PR.
Миграции и обновления стеков. Пример OpenAI: миграция на Vite, апгрейд React. Symphony сам раскладывает работу на цепочку задач, следит за зависимостями и CI.
Разгрузка инженеров от рутины вокруг PR:
- перезапуск и ретраи flaky‑тестов;
- ребейзы на свежий main;
- починка конфликтов;
- доведение тикета до статуса Merging и дальше.
Расширение круга людей, которые могут инициировать работу. Продакт‑менеджер или дизайнер создаёт задачу в трекере, описывает фичу словами и получает пакет для ревью, включающий видео‑демо работающей фичи в реальном продукте.

Где Symphony не подойдёт

Symphony не закрывает всё подряд.

Не лучший вариант, если:

у вас нет инфраструктуры для агентов: нет Codex или аналогичного сервера, нет тестов, нет подготовленного репозитория под автоматическую разработку;
команда не готова формализовать процесс в WORKFLOW.md и поддерживать его в актуальном состоянии;
задачи требуют плотной, интерактивной работы инженера:
- очень размытые проблемы без чёткой формулировки;
- исследования, где важна человеческая интуиция и продуктовые решения;
- сложные архитектурные изменения, где цена ошибки высока, а тестового покрытия мало.

OpenAI прямо говорит: такие задачи по‑прежнему лучше решать в ручных сессиях Codex. Обычно это как раз самые интересные для инженеров проблемы.

Symphony эффективен, когда нужно массово выполнять рутинную реализацию и сопровождение PR, а люди сосредотачиваются на сложных, творческих частях.

Доступность и ограничения

Symphony — open source‑спецификация и референсная реализация. Репозиторий доступен публично. Код можно развернуть у себя, адаптировать под Jira, GitHub Issues, Linear или другой таск‑трекер.

При этом Symphony опирается на Codex App Server. Чтобы получить тот же эффект, вам понадобится:

доступ к Codex или другой кодящей модели с похожим API;
возможность запускать её в headless‑режиме и управлять через API;
инфраструктура для запуска агентов (devbox‑ы, контейнеры, CI).

Если ваш доступ к сервисам OpenAI ограничен (например, по геолокации или политике компании), Symphony придётся интегрировать с альтернативными агентами, сохраняя логику SPEC.md и WORKFLOW.md.

Место на рынке

Symphony занимает нишу минимального оркестратора агентной разработки, заточенного под Codex App Server и таск‑трекеры уровня Linear.

Что важно:

OpenAI не позиционирует Symphony как коммерческий продукт с поддержкой. Это референсная архитектура и пример того, как связать Codex с таск‑трекером.
В отличие от тяжёлых платформ для автоматизации разработки, Symphony умышленно держит ядро в виде SPEC.md + WORKFLOW.md и небольшой Elixir‑службы.
OpenAI показывает конкретный эффект: на отдельных командах внутри компании +500% к количеству смёрженных PR за три недели после внедрения Symphony.

Прямых числовых сравнений с другими системами оркестрации агентов OpenAI не приводит. Но по философии подхода Symphony ближе к «текстовой спецификации, которую реализует сам ИИ», чем к монолитному инструменту с жёстко прошитой логикой.

Если вы уже экспериментируете с GPT‑подобными кодовыми агентами и ищете способ превратить их из «чат‑бота для кода» в постоянного участника команды разработки, Symphony даёт рабочий, проверенный в проде шаблон, который можно адаптировать под свой стек, процессы и уровень зрелости тестов.