Narzędzia AI

Symphony OpenAI: otwarta specyfikacja dla agentów kodujących

Symphony OpenAI to otwarta specyfikacja orkiestracji agentów kodujących z 27 kwietnia 2026 r. Jak działa, jakie trackery obsługuje i gdzie są jej granice.

Andrzej Niemiec

18 sierpnia 2026 · 11 min czytania · 1259 słów

Reviewed by Andrzej Niemiec

Czym jest Symphony OpenAI?

Symphony to plik SPEC.md oraz referencyjna implementacja w Elixirze, udostępnione na licencji Apache 2.0 [2][3]. OpenAI opisuje projekt jako otwartą specyfikację do orkiestracji Codexa [1]. To nie platforma SaaS ani funkcja w ramach ChatGPT. Repozytorium nazywa Symphony engineering preview do testów w zaufanych środowiskach, a OpenAI zaznacza, że nie zamierza utrzymywać go jako samodzielnego produktu [1][2].

Publiczne ogłoszenie nastąpiło 27 kwietnia 2026 r. [1]. Pierwotny opis opierał się na Linearze jako trackerze, a nie na Jirze [1]. Nazwa „Symphony” opisuje warstwę sterowania: zadania pozostają w systemie śledzenia, a agenci wykonują pracę w tle.

Jak Symphony zamienia issue tracker w system agentów?

Tracker pozostaje źródłem zadań. Długotrwały serwis odpytuje go o kwalifikujące się zgłoszenia, dla każdego tworzy izolowany workspace i uruchamia sesję agenta kodującego. Wynik pracy wraca do zgłoszenia. Specyfikacja opisuje też ponawianie prób i uzgadnianie stanu po przerwie [3].

Repozytorium ujmuje to krótko: projekt zamienia pracę projektową w izolowane, autonomiczne przebiegi implementacji, tak aby zespół zarządzał pracą, a nie nadzorował agentów [2]. Implementacja referencyjna korzysta z Codex App Server i komunikacji JSON-RPC [1][4]. Sama specyfikacja jest językowo ogólna, ale gotowy runtime OpenAI jest silnie związany z Codexem [1][3].

W praktyce oznacza to zmianę punktu sterowania. Zamiast promptować agenta w terminalu, zespół przenosi sterowanie do trackera, gdzie stan zadania jest jawny i widoczny dla całego zespołu. Kontekst tej zmiany opisujemy też w tekście o tym, czy GPT-5.5 połknął Codex.

Które trackery obsługuje Symphony?

Pierwotna wersja opierała się na Linearze. Adapter Jira Cloud dodano w oficjalnym wydaniu v0.0.2 z 24 lipca 2026 r. [1][5]. Repozytorium ma trzy wydania: v0.0.1 z 18 lipca, v0.0.2 z 24 lipca i v0.0.3 z 15 września 2026 r. [5].

Konfiguracja Jiry wymaga adresu Jira Cloud, e-maila, tokenu API i klucza projektu [4]. Dokumentacja repozytorium potwierdza konfigurację Jira i test end-to-end [4]. Dla zespołów pracujących na Linearze ścieżka wdrożenia jest krótsza, bo ten tracker był punktem wyjścia projektu [1].

Czy OpenAI potwierdziło wzrost produktywności?

OpenAI podało, że w niektórych zespołach liczba scalonych pull requestów wzrosła o 500% w pierwszych trzech tygodniach [1]. To deklaracja producenta. Nie ma przy niej opublikowanego benchmarku, grupy kontrolnej, baseline’u ani niezależnego audytu [1].

OpenAI zaznacza, że eksperyment poprzedziło przygotowanie przyjaznego agentom repozytorium, rozbudowane testy, guardrails i inżynieria harnessu [1][6]. To warunek wstępny, którego nie da się pominąć przy ocenie wyników. Komentatorzy branżowi zwracają uwagę, że Symphony przenosi agenty kodujące z poziomu promptów na poziom orkiestracji, ale nie zastępuje inżynierii wokół repozytorium [7].

Repozytorium nie publikuje danych o defektach, czasie dostarczenia zmian ani kosztach tokenów [2]. Bez tych liczb deklaracja wzrostu pozostaje punktem odniesienia do własnych testów, a nie gwarancją wyniku. Szerszy kontekst wdrożeń w firmach opisujemy w artykule o Codex on-premise i wymogach compliance.

Symphony a inne sposoby uruchamiania agentów

Kryterium	Symphony	ChatGPT agent mode	Codex App Server
Źródło zadania	issue tracker, np. Linear lub Jira Cloud [1][5]	rozmowa w ChatGPT [8]	wywołanie przez warstwę nadrzędną [1]
Sposób pracy	długotrwały serwis, workspace na zgłoszenie [3]	sesja agentowa w produkcie [8]	runtime dla sesji kodujących [1]
Dojrzałość	engineering preview, bez wsparcia produktowego [2]	funkcja produktu ChatGPT [8]	komponent implementacji referencyjnej [1]

Tabela pokazuje różnicę w zakresie. Symphony obejmuje pętlę od zgłoszenia do zamknięcia zadania, ChatGPT agent mode działa wewnątrz rozmowy, a Codex App Server jest warstwą wykonawczą, na której Symphony się opiera [1][8].

Jakie są ograniczenia i ryzyka Symphony?

Symphony automatyzuje odpytywanie trackera, tworzenie workspace’ów, sesje, ponawianie prób i uzgadnianie stanu. Człowiek nadal musi zdefiniować workflow, przygotować repozytorium, skonfigurować uprawnienia i przeglądać wynik [3].

Specyfikacja nie narzuca jednego modelu akceptacji ani sandboksowania [3]. To oznacza, że politykę bezpieczeństwa trzeba zaprojektować samodzielnie. OpenAI wskazuje też, że zadania niejednoznaczne i wymagające osądu lepiej wykonywać interaktywnie [1]. Przejście na pracę na poziomie zgłoszeń ogranicza możliwość bieżącego korygowania agenta [1].

Dodatkowym ryzykiem jest przywiązanie do runtime’u. Implementacja referencyjna jest związana z Codexem, mimo że specyfikacja jest ogólna [1][3]. Organizacja, która chciałaby użyć innego modelu, musi sama przygotować warstwę wykonawczą.

Czy Symphony jest częścią ChatGPT?

Nie. Symphony to osobny projekt w repozytorium OpenAI, powiązany z Codexem, a nie funkcja w ramach ChatGPT [1][2]. ChatGPT pozostaje odrębnym produktem z własnymi planami i modelami.

W październiku 2026 r. OpenAI rozpoczęło globalny rollout GPT-6 z Intelligent UI do planów Plus, Pro, Business i Enterprise, a dzień później do Free i Go [9]. Cennik planów OpenAI publikuje na stronie produktu [10]. Symphony nie pojawia się w tej ofercie jako element subskrypcji.

Jak zacząć z Symphony?

Punktem wyjścia jest specyfikacja. Plik SPEC.md opisuje model działania, a repozytorium zawiera implementację referencyjną i dokumentację Jiry [2][3][4]. Przewodniki zewnętrzne opisują ten sam model: tracker jako źródło zadań, izolowane workspace’y i sesje agenta [11][12].

Praktyczna kolejność jest odwrotna do intuicji. Najpierw trzeba przygotować repozytorium i testy, bo bez nich agent nie ma jak weryfikować pracy [1][6]. Dopiero potem ma sens konfiguracja trackera i uprawnień. Repozytorium miało około 27,8 tys. gwiazdek 17 września 2026 r. [2], ale popularność nie jest dowodem jakości kodu.

Warto też czytać wydania, a nie tylko opis ogłoszeniowy. Adapter Jira Cloud pojawił się dopiero w v0.0.2 [5]. Zespoły, które potrzebują innych trackerów, muszą liczyć się z własną pracą integracyjną.

Najczęstsze pytania

Czy Symphony jest darmowe?

Tak, kod jest dostępny na licencji Apache 2.0 [2]. Darmowa jest jednak tylko warstwa oprogramowania. Koszty modeli, infrastruktury i czasu wdrożenia ponosi zespół, a OpenAI nie oferuje wsparcia produktowego dla Symphony [1][2].

Czy Symphony obsługuje Jirę?

Tak, od wydania v0.0.2 z 24 lipca 2026 r. [5]. Wcześniejsza wersja opierała się na Linearze [1]. Konfiguracja wymaga adresu Jira Cloud, e-maila, tokenu API i klucza projektu [4].

Czy Symphony to produkt OpenAI?

Nie. OpenAI nazywa je implementacją referencyjną i engineering preview do testów w zaufanych środowiskach [1][2]. Firma nie planuje utrzymywać Symphony jako samodzielnego produktu [1].

Czy wzrost liczby pull requestów o 500% jest potwierdzony?

To deklaracja OpenAI dotycząca niektórych zespołów w pierwszych trzech tygodniach [1]. Nie ma opublikowanego benchmarku, grupy kontrolnej ani audytu [1]. Wyniku nie należy przenosić na własny zespół bez własnego pomiaru.

Czy trzeba używać Codexa?

Implementacja referencyjna korzysta z Codex App Server i JSON-RPC [1][4]. Specyfikacja jest językowo ogólna, ale gotowy runtime jest związany z Codexem [1][3]. Użycie innego modelu wymaga własnej warstwy wykonawczej.

Źródła

O autorze

Andrzej Niemiec

Fanatyk nowych technologii i specjalista w zakresie sztucznej inteligencji.

→ LinkedIn → www