OpenAI выложила Symphony в опенсорс для оркестрации агентов. Вот чего сама спецификация честно не решает

Спецификация Symphony от OpenAI точно описывает, как доска задач раздаёт работу кодовым агентам и забирает результат обратно. Она не описывает, кто одобряет то, что эти агенты делают, пока работают, и говорит об этом прямым текстом: политика допуска, песочницы и аудита отдаётся на откуп тому, кто реализует спецификацию.

Что такое Symphony на самом деле

`openai/symphony` это спецификация и референсная реализация, опубликованные в апреле 2026 года Алексом Котляровски, Виктором Чжу и Заком Броком, под лицензией Apache 2.0. SPEC.md описывает контур управления: доска держит задачи, диспетчер следит за ней, агенты забирают работу, выполняют её и репортят статус обратно на ту же доску. Референсная реализация написана на Elixir поверх BEAM, по той же причине, по которой Erlang десятилетиями живёт в телеком-коммутаторах: супервизия тысяч независимо падающих параллельных процессов это именно то, для чего сделан этот рантайм.

Сама спецификация не называет конкретный control plane. Референсная реализация называет: она следит за доской в Linear и запускает агентов на задачи, которые туда попадают. Это различие важно для тех, кто оценивает Symphony. Это не «Linear с прикрученными агентами». Это протокол диспетчеризации по доске, к которому просто приложена Linear как пример.

Пробел словами самой спецификации

SPEC.md говорит об этом прямо: «От реализаций ожидается явное документирование их подхода к доверию и безопасности. Данная спецификация не требует единой политики допуска, песочницы или подтверждения оператором» (в оригинале: "This specification does not require a single approval, sandbox, or operator-confirmation policy").

И дальше, ещё более прямо: «Поведение допуска, песочницы и ввода от пользователя: implementation-defined. Требования к политике: каждая реализация ОБЯЗАНА задокументировать выбранный ею подход к допуску, песочнице и подтверждению оператором».

Поверхность конфигурации отражает то же решение: codex.approval_policy принимает значение из Codex AskForApproval, по умолчанию implementation-defined. Symphony не поставляет готовый ответ на вопрос «можно ли этому агенту выполнить команду без подтверждения». Она поставляет поле, куда конкретная реализация вписывает свой собственный ответ.

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

Что значит «implementation-defined», когда агенты уже работают

Незаданное поле политики не означает отсутствие политики. Оно означает, что реальной политикой по умолчанию становится то, что конкретное развёртывание задало или не задало. Из текста самой спецификации прямо следуют три вещи.

Нет разделения по умолчанию между обратимыми и деструктивными действиями. В спецификации ничто не отличает агента, комментирующего задачу, от агента, делающего force push в общую ветку. Оба варианта это просто действия, которые реализация может обвесить проверками, а может и не обвесить, и у спецификации на этот счёт нет мнения.

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

Сама доска ничего не проверяет. Symphony репортит статус обратно на доску, с которой раздавала работу, ту же самую, что в референсном варианте следит за Linear. Обновление на доске это собственное заявление агента о том, что произошло, а не доказательство, сверенное с PR, прогоном CI или диффом. Это не специфичная для Symphony проблема, это тот же пробел, что есть у любого трекера задач в тот момент, когда кнопку «готово» нажимает агент, а не человек. Подробнее об этом в материале о том, что реально требуется от трекера задач для управляемой автономии.

Что реальному развёртыванию придётся добавить самому

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

• явный уровень риска на каждый тип действия, решённый один раз, а не заново на каждый запуск агента;
• политика, которая переживает падение доски, за которой следит диспетчер, а не живёт только в конфиге рядом с ним;
• идентичность на каждого агента, которую человек может отозвать, не трогая остальных: диспетчер Symphony запускает несколько агентов на одну доску, но ничего не говорит о том, делят ли эти агенты один и тот же credential;
• способ сверить собственное заявление доски о «готово» с чем-то за её пределами.

За какой бы control plane ни следило конкретное развёртывание Symphony, будь то Linear в референсном варианте или что-то ещё, именно этот слой и обеспечивает управляемый, ограниченный доступ к тому, к чему подключается агент: идентичность на каждого агента, ограниченная и отзываемая на уровне протокола, уже работает сегодня, а переходы статуса, привязанные к доказательствам, а не к самоотчёту, выходят поверх того же фундамента. Symphony решает диспетчеризацию. Она никогда не пыталась решить, что происходит после того, как агент забрал работу, и её собственная спецификация честно об этом говорит.