Спецификация с открытым исходным кодом для оркестрации Codex: Symphony27.04.2026 00:00

Шесть месяцев назад, работая над внутренним инструментом повышения производительности, наша команда приняла спорное (на тот момент) решение: мы будем разрабатывать репозиторий без единой строчки кода, написанной человеком. Каждая строка в репозитории нашего проекта должна была генерироваться Codex.

Чтобы это заработало, мы перепроектировали наш инженерный рабочий процесс с нуля. Мы создали дружественный для агентов репозиторий, вложили значительные средства в автоматические тесты и системы защиты и стали относиться к Codex как к полноценному члену команды. Мы подробно описали этот путь в нашей предыдущей публикации в блоге об инженерном обеспечении агентов⁠.

И это сработало, но затем мы столкнулись со следующим узким местом: переключением контекста.

Чтобы решить эту новую проблему, мы создали систему под названием Symphony. Symphony⁠ — это оркестратор агентов, который превращает систему управления проектами вроде Linear в панель управления для агентов-программистов. Каждая открытая задача получает своего агента, агенты работают непрерывно, а люди проверяют результаты.

В этой статье рассказывается о том, как мы создали Symphony, что привело к увеличению числа принятых запросов на слияние (pull requests) на 500% в некоторых командах, и как использовать ее, чтобы превратить собственный трекер задач в постоянно работающий оркестратор агентов.

Пределы возможностей интерактивных агентов-программистов

Даже по мере того как агенты-программисты становятся проще в использовании (будь то через веб-приложения или CLI), они все равно остаются интерактивными инструментами.

По мере роста масштабов работы агентов в OpenAI мы столкнулись с новым видом нагрузки. Каждый инженер открывал несколько сессий Codex, назначал задачи, проверял результаты, направлял агента и повторял процесс. На практике большинство людей могли с комфортом управлять тремя-пятью сессиями одновременно, прежде чем переключение контекста начинало утомлять. Сверх этого производительность падала. Мы забывали, какая сессия что делает, перепрыгивали между терминалами, чтобы вернуть агентов на правильный путь, и отлаживали долго выполняющиеся задачи, которые зависали на половине пути.

Агенты работали быстро, но у нас было системное узкое место: внимание человека. Мы фактически создали команду чрезвычайно способных младших инженеров, а затем поручили нашим инженерам-людям заниматься их микроменеджментом. Это не могло масштабироваться.

Смена перспективы

Мы поняли, что оптимизируем не то. Мы ориентировали нашу систему вокруг сессий кодирования и объединенных PR, в то время как PR и сессии — это по сути лишь средство достижения цели. Рабочие процессы разработки программного обеспечения в основном организуются вокруг результатов: задач, тикетов, вех.

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

Эта идея легла в основу Symphony — письменной спецификации, которая выполняет роль руководителя для оркестрации работы агентов.

Превращение трекера задач в оркестратор агентов

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

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

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

На практике Symphony отделяет работу от сессий и пулл-реквестов. Некоторые задачи создают несколько PR в разных репозиториях; другие представляют собой чистое исследование или анализ, которые вообще не затрагивают кодовую базу.

Как только работа абстрагируется подобным образом, тикеты могут представлять собой гораздо более крупные объемы задач.

Мы регулярно используем Symphony для оркестрации сложных функций и миграций инфраструктуры. Например, мы можем завести задачу с просьбой к агенту проанализировать кодовую базу, Slack или Notion и составить план реализации. Когда нас устраивает план, агент генерирует дерево задач, разбивая работу на этапы и определяя зависимости между ними.

Агенты начинают работу только над теми задачами, которые не заблокированы, поэтому выполнение разворачивается естественно и оптимально параллельно для этого направленного ациклического графа (DAG — последовательности шагов выполнения). Например, мы отметили обновление React как заблокированное миграцией на Vite. Как и ожидалось, агенты начали обновлять React только после завершения миграции на Vite.

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

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

Поскольку оркестратор работает на devbox’ах и никогда не спит, мы можем добавлять задачи откуда угодно и быть уверенными, что агент их подхватит. Например, один инженер из нашей команды сделал три значительных изменения из приложения Linear на своем телефоне, находясь в уютном домике с плохим Wi-Fi.

Рост числа исследовательских задач благодаря такому подходу

При наблюдении за результатами работы с Symphony самым очевидным изменением стал объем производительности. В некоторых командах OpenAI мы увидели увеличение числа принятых PR на 500% за первые три недели. Вне OpenAI основатель Linear Карри Сааринен отметил всплеск создания рабочих пространств⁠ после выпуска Symphony. Однако более глубокое изменение заключается в том, как команды думают о работе.

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

Это изменило наше поведение. Стало тривиальным запускать спекулятивные задачи в Symphony. Проверить идею, исследовать рефакторинг, протестировать гипотезу и сохранить только те результаты, которые выглядят многообещающе.

Это также расширяет круг лиц, способных инициировать работу. Наш продакт-менеджер и дизайнер теперь могут направлять запросы функций напрямую в Symphony. Им не нужно клонировать репозиторий или управлять сессией Codex. Они описывают функцию и получают обратно пакет для ревью, включающий видеообзор работающей функции внутри реального продукта.

Symphony также отлично проявляет себя в крупных монорепозиториях (вроде того, что у нас в OpenAI), где финальный этап слияния PR идет медленно и хрупко. Система следит за CI, выполняет rebase при необходимости, разрешает конфликты, перезапускает нестабильные тесты и в целом сопровождает изменения через конвейер. К моменту, когда тикет доходит до статуса Merging (Слияние), у нас есть полная уверенность, что изменение попадет в основную ветку без присмотра человека.

После внедрения Symphony мы делегируем агентам больше работы и фокусируемся на более сложных, исследовательских задачах.

Прогресс приносит новые иные проблемы

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

Вместо того чтобы исправлять результат вручную, мы добавили защитные механизмы и навыки, чтобы агенты могли преуспеть в следующий раз. Со временем это привело нас к добавлению новых возможностей в наш harness, таких как запуск сквозных тестов, управление приложением через Chrome DevTools и проведение дымовых QA-тестов. Мы значительно улучшили нашу документацию и прояснили, как выглядит качественный результат.

Не каждая задача подходит под стиль работы Symphony. Некоторые проблемы по-прежнему требуют от инженеров работы напрямую с интерактивными сессиями Codex, особенно неоднозначные задачи или работа, требующая серьезных суждений и экспертизы. На практике это обычно самые интересные и приятные для инженеров задачи, на которые они хотят тратить время.

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

Мы также усвоили, что относиться к агентам как к жестким узлам в машине состояний неэффективно. Модели становятся умнее и могут решать более крупные проблемы, чем те рамки, в которые мы пытаемся их втиснуть. Наши ранние версии агентской работы просили Codex лишь реализовать задачу. Этот подход оказался слишком ограниченным. Codex прекрасно справляется как с созданием нескольких PR, так и с чтением отзывов на ревью и их устранением. Поэтому мы дали ему инструменты — CLI gh, навыки чтения логов CI и т. д. — и теперь мы можем просить Codex делать больше, например закрывать старые PR или собирать отчеты по завершенной и заброшенной работе. Подобные типы задач выходили далеко за рамки первоначальных рамок реализации функций.

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

Использование Symphony для создания Symphony

Когда вы открываете репозиторий Symphony, ⁠ первое, что вы заметите — технически Symphony представляет собой всего лишь файл SPEC.md с определением проблемы и предполагаемого решения. Вместо создания сложной системы надзора мы определили проблему и предполагаемые решения, предоставив агентам высокоуровневое управление.