Symphony: как OpenAI превратила трекер задач в вечно работающий конвейер из AI-агентов

OpenAI открыла исходный код спецификации Symphony — минималистичного слоя оркестрации (orchestration layer) для своего флагманского coding-агента Codex. Идея проста и элегантна: каждая открытая задача в трекере автоматически получает своего агента, который работает независимо до завершения, а человек подключается лишь для финального ревью.

Откуда появилась Symphony

Несмотря на то что coding-агенты становятся всё удобнее, они по-прежнему остаются интерактивными инструментами. По мере роста масштабов агентной работы внутри OpenAI инженеры столкнулись с новой проблемой: каждый из них открывал несколько сессий Codex, раздавал задачи, проверял результат, корректировал агента — и так по кругу.

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

Команда OpenAI осознала, что оптимизирует не то: вся система строилась вокруг сессий и смёрдженных PR (pull request — запрос на слияние кода), тогда как PR — это лишь средство, а не цель. Программные процессы в первую очередь организованы вокруг конкретных результатов: задач, тикетов, вех. Тогда возник вопрос: что будет, если перестать напрямую следить за агентами и вместо этого позволить им самостоятельно брать работу из трекера задач?

Трекер задач — это не просто список дел. Это потенциальная плоскость управления для целого флота AI-агентов.

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

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

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

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

graph TD
    A[Инженер создаёт тикет в Linear] --> B[Symphony обнаруживает задачу]
    B --> C[Создаётся изолированное рабочее пространство]
    C --> D[Запускается Codex-агент]
    D --> E{Задача выполнена?}
    E -- Нет --> F[Агент продолжает работу]
    F --> E
    E -- Да --> G[Создаётся Pull Request]
    G --> H[Инженер делает ревью]
    H --> I[PR смёрджен]
    style A fill:#6366f1,color:#fff
    style I fill:#22c55e,color:#fff
    style H fill:#f59e0b,color:#fff

Архитектура: три ключевых компонента

Система состоит из трёх ролей. Оркестратор — это работающий процесс, который опрашивает трекер, управляет рабочими пространствами, диспетчеризует агентов и отслеживает прогресс. Трекер задач является единственным источником истины (source of truth) — Symphony поддерживает интеграцию с Linear, Jira и аналогичными инструментами. Coding-агент непосредственно выполняет работу; при этом Symphony не привязана к конкретному агенту — можно подключить любой подходящий.

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

Ключевое архитектурное решение Symphony — использование доски Linear как конечного автомата (finite state machine). У каждого тикета есть статус, и оркестратор ориентируется только на него. Поскольку единственным источником истины является доска, агент оказывается stateless между запусками: если оркестратор падает, он может при перезапуске снова прочитать доску и точно восстановить текущее состояние.

Жизненный цикл тикета

Тикеты проходят путь: Todo → In Progress → Review → Merging, и на каждом этапе супервизор перезапускает упавшего агента.

Техническая реализация

Symphony — это спецификация Apache-2.0 (файл SPEC.md) плюс эталонная реализация на Elixir/BEAM. Linear выступает конечным автоматом, Codex — исполнителем, а GitHub PR — итоговым артефактом.

Выпущенная под лицензией Apache License 2.0, спецификация Symphony описывает, как должен работать сервис координации coding-агентов — по роли похожий на GitHub Actions или Jenkins, но созданный для запуска AI-агентов против задач: как читать из трекера, как запускать агентов и как довести каждую задачу до pull request.

Файл SPEC.md определяет протокол: как читать из трекера задач, как управлять жизненным циклом агента, как работают повторные попытки и экспоненциальные задержки (backoff), как назначаются и очищаются рабочие пространства. Спецификация использует язык RFC с ключевыми словами MUST/SHOULD/MAY, что делает её реализуемой на любом языке программирования.

# Упрощённый пример логики оркестратора Symphony
defmodule Symphony.Orchestrator do
  def poll_and_dispatch(tracker, agent) do
    tracker
    |> list_active_issues()         # Получить активные задачи
    |> Enum.each(fn issue ->
      ensure_workspace(issue)       # Создать/найти рабочее пространство
      |> dispatch_agent(agent)      # Запустить Codex-агент
      |> monitor_until_done()       # Следить до завершения
    end)
  end
end

Эталонная реализация написана на Elixir — благодаря его мощной модели конкурентности, — однако Codex успешно реализовал Symphony на нескольких языках: TypeScript, Python и Rust, что демонстрирует универсальность спецификации.

Результаты: +500% к смёрдженным PR

OpenAI сообщает, что у некоторых команд после внедрения Symphony количество принятых pull requests выросло на 500%.

Когда инженеры перестают следить за сессиями Codex, воспринимаемая «стоимость» каждого изменения падает — и экономика разработки меняется кардинально.

Дэн МакАтир, специалист по агентным AI-операциям в AnswerRocket, сообщил о закрытии десятков задач за неделю с помощью Symphony и Codex, хотя и отметил, что система потребляет большое количество токенов.

Ограничения и честность OpenAI

OpenAI не претендует на то, что Symphony — готовое решение для всех.

Подход действительно создаёт новые проблемы. Агенты могут промахиваться мимо цели при работе с задачами уровня тикета, и не каждая задача подходит для оркестрации. Расплывчатые формулировки или работа, требующая глубокого суждения, по-прежнему может потребовать прямого взаимодействия инженера с интерактивными сессиями Codex.

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

Symphony vs. традиционные CI/CD-инструменты

Что это значит для разработчиков

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

Аналитики рассматривают Symphony не как очередной AI-ассистент для кодирования, а как зарождающийся операционный слой для доставки программного обеспечения.

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

OpenAI надеется, что разработчики направят своего любимого coding-агента на спецификацию Symphony и репозиторий, чтобы создать собственные версии, адаптированные под их среды.

Итог

Symphony — это не волшебная кнопка «автоматизировать всё», а хорошо продуманный архитектурный шаблон, выросший из реальных проблем инженеров OpenAI. Главная идея: перестать управлять агентами вручную и начать управлять очередью задач. Трекер задач превращается из пассивного списка дел в активную плоскость управления AI-агентами.

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