OpenAI Symphony: Der Coding Agent Orchestrator getestet
Als Symphony zum ersten Mal eines meiner Linear-Tickets abholte und eine funktionierende Pull-Anfrage verschickte, ohne dass ich eine Tastatur berührte, saß ich eine ganze Minute da und versuchte herauszufinden, was ich als nächstes tun sollte.
In meinem Ticket stand: * „Ratenbegrenzende Middleware zu den öffentlichen API-Endpunkten hinzufügen, Standard 60 req/min, Überschreibungen pro Route zulassen.“* Ich hatte es aus Gewohnheit in „In Bearbeitung“ verschoben, die Symphony-Devbox gestartet und die Registerkarten gewechselt, um eine Slack-Nachricht zu beantworten. Elf Minuten später lag ein PR-Entwurf vor. Der Agent hatte einen isolierten Arbeitsbereich erstellt, meine Codebasis gelesen, die Middleware geschrieben, Überschreibungen auf Routenebene hinzugefügt, drei Tests geschrieben und einen Zweig gepusht. Der Unterschied war nicht perfekt – ich habe einen Test abgelehnt und einen Kommentar verschärft –, aber die Arbeit war echt. Die Arbeit war erledigt.
Dieses Ticket war der Moment, in dem der OpenAI Symphony Agent Orchestrator für mich aufhörte, eine Demo zu sein, und begann, ein Tool zu sein. Außerdem musste ich mich mit etwas Unangenehmem auseinandersetzen: Die Art und Weise, wie ich Codex und
Ich wünschte, jemand hätte mir diesen Beitrag gegeben, bevor ich zwei Wochenenden damit verbracht habe, meine Einstellung zur Agenteninfrastruktur neu zu definieren. Ich zeige Ihnen, was Symphony eigentlich ist (es ist kleiner und seltsamer, als die Pressemitteilungen vermuten lassen), wie es in das allgemeinere Muster passt, das die Leute „harness engineering“ nennen, was ich kaputt gemacht habe, als ich versuchte, es an meinen eigenen Stapel anzupassen, und die eine mentale Veränderung, die alles zum Klicken gebracht hat.
Eine Warnung, bevor wir weitermachen: Es wird eine Zahl herumgereicht – die Behauptung von OpenAI, dass einige interne Teams innerhalb von drei Wochen nach Einführung von Ich werde später in diesem Beitrag auf diese Zahl zurückkommen, denn die Art und Weise, wie Sie sie lesen, entscheidet darüber, ob Sie das Richtige oder das Falsche bauen.
Was OpenAI Symphony eigentlich ist (und was es nicht ist)
Lassen Sie mich vorab ein Missverständnis ausmerzen: Symphony ist kein Produkt. Es ist kein SaaS. Es ist keine geschlossene Binärdatei. Es gibt kein Dashboard, bei dem Sie sich anmelden.
Symphony ist eine SPEC.md-Datei. Das ist das gesamte Kernartefakt. OpenAI hat es am 5. März 2026 unter Apache 2.0 als Open-Source-Lösung veröffentlicht und bis Ende April 2026 hatte das openai/symphony GitHub Repo 15.000 Sterne überschritten (Help Net Security). Die Spezifikation beschreibt – im Klartext, mit Zustandsdiagrammen –, wie ein langjähriger Orchestrator einen Issue-Tracker in eine Steuerungsebene für autonome Codierungsagenten umwandeln sollte.
Die Referenzimplementierung wird in Elixir geliefert. Ja, Elixier. Unter der Haube verwenden Discord und WhatsApp die gleiche Sprache.
Aber hier ist der Teil, der mich überrascht hat. Das Team von Die Spezifikation ist das Produkt. Der Elixir-Code ist nur das ausgefeilteste Beispiel.
Das ist wichtig, weil es Ihnen sagt, welche Art von Werkzeug Sie wirklich bewerten. Symphony ist nicht „OpenAIs Orchestrator-Framework“. Es handelt sich um ein gemeinsames Vokabular dafür, wie eine gute Orchestrierung von Codierungsagenten aussieht, mit einer Arbeitsreferenz, die Sie entweder unverändert ausführen oder daraus stehlen können.
Die Kernschleife, in einem Absatz
Symphony fragt Linear alle 30 Sekunden ab. Wenn ein Ticket in einen konfigurierten „Bereit“-Status wechselt, beansprucht es dieses Ticket, startet einen isolierten Arbeitsbereich (einen neuen Git-Arbeitsbaum auf einer Devbox), startet einen Codex-Agenten in diesem Arbeitsbereich mit einer strukturierten Eingabeaufforderung, die den Tickettext enthält, lässt den Agenten kontinuierlich laufen, bis er eine PR erzeugt oder fehlschlägt, und markiert dann das Ticket entweder mit einem Grund als „bereit zur Überprüfung“ oder als „blockiert“. Die Standard-Parallelität beträgt 10 Agenten. Der Status befindet sich in einem GenServer im Speicher. Beim Neustart wird es einfach von Linear neu erstellt, sodass keine Datenbank zum Betrieb vorhanden ist (allthings.how).
Das ist es. Das ist die ganze Sache. Lesen Sie diesen Absatz noch einmal, denn es geht um die Einfachheit.
Warum mich der Hype überrascht hat
Ich werde ehrlich sein. Als der Blog-Beitrag OpenAI Anfang März erschien, überflog ich ihn nur halb und fuhr fort. „Ein anderer Agenten-Orchestrator“ war der zynische Gedanke. Ich hatte bereits mit Steve Yegges Gas Town gespielt, ich hatte Archon drei Wochen lang in einem Nebenprojekt betrieben und ich hatte mein eigenes langjähriges Claude Code-Geschirr für einen Kunden gebaut. Keines dieser Werkzeuge brauchte einen vierten Konkurrenten.
Was ich übersehen habe – was die meisten Berichterstattungen übersehen haben – ist, dass Symphony nicht wirklich mit diesen Tools konkurriert. Es konkurriert mit der Version von Ihnen, die ein Terminal öffnet, codex oder claude eingibt und einem Agenten bei der Arbeit an einer Aufgabe zusieht. Es konkurriert mit der manuellen Aufsicht selbst. Als ich das verstand, veränderte sich meine ganze Woche.
Um zu erklären, warum, muss ich einen Abstecher zu dem Begriff machen, der in diesem Jahr still und leise zum wichtigsten Konzept in der AI-unterstützten Softwarebereitstellung geworden ist: harness engineering.
Harness Engineering: Der Wortschatz, der alles zum Klicken brachte
Im April 2026 veröffentlichte Birgitta Böckeler – Thoughtworks‘ Global Lead for Es ist der Artikel, der uns die kanonische Taxonomie lieferte. (In der Videozusammenfassung, nach der ich gearbeitet habe, wurde ihr Name phonetisch als „Vetta Berkeler“ wiedergegeben – dieselbe Person, derselbe Rahmen.)
Der Aufbau ist täuschend einfach:
Agent = Model + Harness
Das Modell ist das LLM. Alles andere – die Eingabeaufforderungen, die Tools, die Sandbox, die Schleife, die Validatoren, der Orchestrator – ist das Geschirr. Und sobald Sie mit der Benennung der Teile des Kabelbaums begonnen haben, können Sie diese bewusst und nicht versehentlich entwerfen.
Böckeler teilt das Geschirr in zwei Schichten und Symphony wohnt genau in einer davon.
Inneres Geschirr – Was im Inneren des Agenten steckt
Der innere Kabelbaum besteht aus dem Code und den Funktionen, die im Agenten selbst enthalten sind. Wenn Sie Claude Code ausführen, erhalten Sie den inneren Rahmen kostenlos: das Tool-Aufrufprotokoll, die Tools zum Lesen von Dateien und Shell-Ausführen, die Planungsaufforderungen, das Spawnen von Subagenten, die Berechtigungstore, das Hooks-System und die Fähigkeiten, die Sie installieren können. Das Gleiche gilt für Codex. Das Gleiche gilt für den Cursor.
Normalerweise schreibt man den inneren Gurt nicht. Sie konfigurieren es. Sie aktivieren Hooks. Sie installieren Fähigkeiten. Sie schreiben einen CLAUDE.md oder AGENTS.md. Sie legen Berechtigungen in settings.json fest. Das innere Geschirr macht ein Modell überhaupt zu einem Codierungsagenten.
Äußeres Geschirr – Was den Agenten umgibt
Der äußere Harness ist alles außerhalb des Agenten, der seinen Lebenszyklus steuert, seinen Kontext verwaltet, entscheidet, wann er ausgeführt wird, worauf er ausgeführt wird, was als „erledigt“ gilt und was passiert, wenn er ausfällt. Hier lebt Symphony. Hier leben auch Gas Town, Archon und Ralph loops.
Der äußere Kabelbaum verwandelt eine Terminalsitzung von Claude Code in eine Flotte von zwanzig parallelen Agenten, denen Sie tatsächlich vertrauen.
Hier ist das mentale Bild, das ich auf ein Whiteboard zeichne, wenn ich es Kunden erkläre:
┌──────────────────────────────────────────┐
│ OUTER HARNESS │
│ Symphony / Gas Town / Archon / Ralph │
│ - lifecycle, queues, isolation, retries │
│ ┌──────────────────────────────────┐ │
│ │ INNER HARNESS │ │
│ │ Claude Code / Codex / Cursor │ │
│ │ - tools, hooks, skills, perms │ │
│ │ ┌────────────────────────┐ │ │
│ │ │ MODEL │ │ │
│ │ │ GPT-5.x / Sonnet / │ │ │
│ │ │ Opus / etc. │ │ │
│ │ └────────────────────────┘ │ │
│ └──────────────────────────────────┘ │
└──────────────────────────────────────────┘
Sobald Sie die Ebenen sehen, rastet jedes „AI Agent-Produkt“ an einer Position auf diesem Bild ein. Und wenn das passiert, lautet die eigentliche Frage nicht mehr: „Welchen Wirkstoff soll ich verwenden?“ und wird zu „Was muss mein äußerer Gurt tun, was niemand anderes kann?“
Das ist die Frage, zu deren Beantwortung Sie Symphony zwingt.
Guides und Sensors – Die zwei Hebel in jedem Geschirr
Innerhalb beider Ebenen führt Böckeler eine weitere Unterscheidung ein, über die ich jetzt jedes Mal nachdenke, wenn ich eine Agentenaufforderung schreibe oder einen CI-Schritt einrichte. Jedes sinnvolle Teil eines Geschirrs erfüllt eine von zwei Aufgaben.
Guides steuert den Agenten, bevor er agiert. Es handelt sich um eine Feedforward-Steuerung. Ihr CLAUDE.md. Die Fähigkeiten, die Sie installieren. Das Playbook, das Sie in die Eingabeaufforderung einfügen. Das Beispiel verpflichtet Sie zur Referenz. Die Architekturentscheidung zeichnet die Lesevorgänge des Agenten auf, bevor Code geschrieben wird. Guides erhöhen die Wahrscheinlichkeit, dass der Agent beim ersten Versuch alles richtig macht.
Sensors Beobachten Sie den Agenten, nachdem er agiert hat, und entscheiden Sie, ob das, was er produziert hat, akzeptabel ist. Sie sind Feedback-Kontrolle. Sensors gibt es in zwei Geschmacksrichtungen:
- Computergestützte Sensoren – deterministisch, schnell, günstig. Linters. Typprüfer. Unit-Tests. Schemavalidatoren. Erstellen Sie Ausgänge. Sie laufen in Millisekunden bis Sekunden und geben Ihnen eine binäre Antwort (Martin Fowler).
- Inferenzsensoren – nicht deterministisch, langsam, teuer. Kodexüberprüfungen für LLM-Richter. Semantische Ähnlichkeitsprüfungen. Stilkritiken. Sie laufen auf einer GPU, dauern Sekunden bis Minuten und liefern probabilistische Antworten.
Hier ist der Teil, dessen Verinnerlichung mir peinlich lange gedauert hat: Die meisten Teams, in denen ich mit zu wenig genutzten Computersensoren gearbeitet habe und zu sehr auf Inferenzsensoren angewiesen bin. Sie richten einen „AI-Prüfer“ ein, bevor sie eslint --max-warnings 0 in einem Pre-Commit-Hook konfiguriert haben. Sie verfügen über eine Abdeckung für den LLM-As-Judge-Test, bevor sie CI einen Abdeckungsschwellenwert hinzugefügt haben.
Computergestützte Sensoren sind grundsätzlich kostenlos. Sie sind bewährt. Sie sind seit fünfzehn Jahren in CI-Pipelines im Einsatz. Der Grund dafür, dass sie in Agenten-Workflows übersprungen werden, liegt darin, dass die Praktiker vergessen, dass der Agent ihre Ausgabe lesen und sich selbst korrigieren kann. In dem Moment, in dem Sie npm test in die Schleife des Agenten einbinden und Fehler als Kontext zurückgeben, sinkt Ihre Fehlerrate um einen Faktor, den ich wirklich nicht einschätzen kann, ohne zu lügen. Es ist eine Menge.
Ich werde darauf zurückkommen, wenn ich Ihnen zeige, wie eine echte Symphony-Workflow-Datei aussieht, denn „Guides-and-Sensors“ ist das gesamte Vokabular, das Sie zum Erstellen einer Datei verwenden. Bleiben Sie vorerst bei Folgendem: Ein Kabelbaum ist ein sorgfältig ausgewählter Satz von Führungen und Sensoren, die um ein Modell herum angeordnet sind. Der Orchestrator ist genau das, was den Kabelbaum in einer Warteschlange betreibt.
Wo Symphony in die äußere Kabelbaumfamilie passt
Symphony ist nicht das einzige Außengeschirr, das es gibt, und es ist nicht immer die richtige Antwort. Lassen Sie mich die vier Elemente durchgehen, die ich dieses Jahr in der Produktion verwendet habe, denn die Kompromisse sind wichtig.
1. Symphony – Issue-Tracker-native Orchestrierung
Die entscheidende Wahl von Symphony ist, dass der Issue-Tracker die Warteschlange ist. Linear-Tickets sind die Arbeitseinheiten. Es gibt keine separate Symphony-Benutzeroberfläche, die verwaltet werden muss. Sie verschieben ein Ticket in den Status „Bereit für Der kognitive Aufwand bei der Einführung ist ungefähr Null, da Sie kein neues Projektmanagement-Tool erlernen.
Der Nachteil besteht darin, dass die Oberfläche von Symphony klein ist. Es macht eines: Eintrittskarten in Läufe umwandeln – und das macht es gut. Wenn Ihre Arbeit nicht in diskrete Tickets passt (langfristige Forschung, mehrwöchige Refaktoren, explorative Spitzen), ist Symphony nicht Ihr Werkzeug.
2. Gas Town – Kolonien mit mehreren Agenten im Stil von Steve Yegge
Gas Town ist Steve Yegges Framework für die Ausführung von 20–30 parallelen Claude Code-Agenten, die in Rollen organisiert sind (Bürgermeister orchestrieren, Polecats ausführen), wobei der Status über den MEOW-Stack (Cloud Native Now) in Git beibehalten wird. Während Symphony „ein Ticket, ein Agent, ein PR“ annimmt, geht Gas Town von koordinierten Schwärmen aus, die an verwandten Arbeiten mit expliziten Übergaben arbeiten.
Ich habe das „Schwarm-Stil“-Muster in meinem Claude Code Agenten-Schwarm-Architektur-Beitrag ausführlicher behandelt – wenn Sie etwas bauen, bei dem sich mehrere Agenten bei der gleichen Aufgabe und nicht bei parallelen Aufgaben koordinieren müssen, ist das der Beitrag, den Sie nach diesem Beitrag lesen sollten.
3. Archon – Deterministische Arbeitsabläufe rund um jeden Codierungsagenten
Archon bezeichnet sich selbst als „der erste Open-Source-Kabelbaumbauer“ – die Beschreibung ist zutreffend. Während Symphony den Workflow fest codiert (Umfrage Linear → Agent ausführen → PR), können Sie mit Archon den Workflow als YAML-Pipeline mit expliziten Phasen, Validierungs-Gates und Artefakten erstellen. Jeder Lauf erhält seinen eigenen Git-Arbeitsbaum. Sie können fünf Fixes ohne Konflikte parallel ausführen (MindStudio).
Ich greife zu Archon, wenn die Arbeit bekannte Phasen hat – „Untersuchen, Planen, Implementieren, Testen, Dokumentieren“ – und ich möchte, dass jede Phase ein separater validierter Schritt ist und nicht ein langer Agentenlauf. Dies ist auch der engste Verwandte von spec-driven-Ansätzen wie dem, über den ich in meinem Traycer BART-Modus spec-driven AI-Teil geschrieben habe.
4. Ralph-Schlaufen – Der minimal lebensfähige Außengurt
Die Ralph Wiggum-Schleife (ja, benannt nach der Simpsons-Figur – „Ich helfe!“) ist der einfachste mögliche äußere Kabelbaum: eine while true-Schleife, die den Agenten erneut aufruft, bis eine deterministische Prüfung erfolgreich ist. Es gibt ein offizielles Anthropic-Plugin im Claude Code-Repository und Vercel Labs liefert Ralph-Loop-Agent für das AI SDK.
Die Ralph-Philosophie: Streben Sie nicht beim ersten Versuch nach Perfektion. Lassen Sie die Schleife verfeinern. Der Agent liest eine Plandatei, macht Fortschritte, die Schleife prüft den Abschluss anhand von Kriterien, und wenn dies nicht der Fall ist, wird der Agent erneut mit dem neuesten Status ausgeführt (beuke.org).
Ralph konkurriert nicht mit Symphony – es ist komplementär. Ein Symphony-Ticket kann eine Ralph-Schleife in seinem Arbeitsbereich ausführen. Symphony kümmert sich um die Warteschlange und die Isolation. Ralph übernimmt die Iteration bis zur Korrektheit. Wenn Sie sie miteinander verbinden, haben Sie etwas wirklich Kraftvolles.
Einrichten von Symphony in einem echten Repo
Genug der Theorie. Lassen Sie mich Ihnen genau zeigen, was ich letzte Woche getan habe, um Symphony in einem Nebenprojekt zum Laufen zu bringen. Das Ganze hat mich von git clone bis zum ersten PR etwa 90 Minuten gekostet, und das meiste davon war die Linear-Konfiguration, nicht Symphony selbst.
Schritt 1: Holen Sie sich den Schlüssel Linear API
Gehen Sie in Linear zu Einstellungen → Sicherheit & Zugriff → Persönliche API-Schlüssel und erstellen Sie einen neuen Schlüssel. Legen Sie es in Ihrer Umgebung als LINEAR_API_KEY fest. Symphony verwendet dieses Token durch sein dynamisches Tool
Schritt 2: Klonen Sie das Repo und wählen Sie eine Implementierung aus
git clone https://github.com/openai/symphony.git
cd symphony
Das Repo hat die Spezifikation unter SPEC.md und die Elixir-Referenz unter elixir/. Wenn Sie Elixir installiert haben (brew install elixir unter macOS), können Sie es in zwei Minuten ausführen. Wenn Sie dies nicht tun, bedeutet die Einfachheit der Spezifikation, dass Sie den Orchestrator in einer Sprache neu schreiben müssen, von der Sie wissen, dass sie wirklich handhabbar ist – das ist der Sinn der Verteilung einer Spezifikation anstelle einer Binärdatei.
Für den Rest dieser exemplarischen Vorgehensweise zeige ich den Elixierpfad, da ich ihn verwendet habe.
cd elixir
mix deps.get
mix compile
Schritt 3: Konfigurieren Sie Ihren Workflow
Kopieren Sie die WORKFLOW.md-Vorlage in das Ziel-Repository (das, an dem Agenten arbeiten sollen, nicht das Symphony-Repository selbst). Hier zahlt sich das Harness-Vokabular aus, denn WORKFLOW.md ist im Wesentlichen Ihre Leitfaden- und Sensorspezifikation für jeden Agentenlauf. Eine gekürzte Version von mir sah so aus:
„Abschlag
Bevor Sie beginnen
- Lesen Sie README.md und ARCHITECTURE.md
– Führen Sie
npm installundnpm testaus, um Baseline-Durchgänge zu bestätigen
Implementierung
- Nehmen Sie die kleinste Änderung vor, die das Ticket erfüllt
- Fügen Sie Tests für jedes neue Verhalten hinzu oder aktualisieren Sie sie
- Führen Sie
npm testundnpm run lintaus, bevor Sie es als erledigt betrachten - Führen Sie
npm run typecheckaus – keine Fehler erforderlich
Definition von erledigt
- Alle Tests bestehen vor Ort
- Flusen- und Typprüfung bestehen ohne Warnungen
- Der PR-Titel stimmt mit dem Tickettitel überein – Die PR-Beschreibung verweist auf die Ticket-ID Linear
That document is doing serious work. The "Before you start" section is a **guide**. The four sensor commands (`npm test`, `npm run lint`, `npm run typecheck`, plus the ticket-link convention) are **computational sensors**. There's not a single LLM-as-judge in there yet, and the system already works. Don't reach for inferential sensors until your computational ones are saturated.
### Step 4: Point Symphony At Linear
In your `.env`:
```bash
LINEAR_API_KEY=lin_api_your_key_here
SYMPHONY_TARGET_REPO=/Users/you/code/your-project
SYMPHONY_LINEAR_TEAM_ID=your_team_id
SYMPHONY_TRIGGER_LABEL=ready-for-codex
SYMPHONY_MAX_CONCURRENT=4
I cap concurrency at 4 on my laptop because Codex sessions are not free and I'd rather watch four serious runs than ten degraded ones. On a devbox you'd raise this.
Step 5: Run It
mix run --no-halt
„
Das ist das vollständige Setup. Symphony fragt jetzt alle 30 Sekunden Linear ab. Kennzeichnen Sie jedes Ticket mit `ready-for-codex` und ein Agent wird es anfordern.
Als ich das zum ersten Mal gemacht habe, habe ich ein bewusst kleines Ticket erstellt – *„Füge einen `/health`-Endpunkt hinzu, der `{ status: 'ok', uptime_seconds: <number> }` zurückgibt“* – und habe zugeschaut. Der Agent nahm es in 31 Sekunden auf. Es hat die Codebasis gelesen. Es hat meine Express-App gefunden. Es schrieb die Route, schrieb einen Test, führte den Test aus (der beim zweiten Versuch bestanden wurde, nachdem ein kleines TypeScript-Inferenzproblem behoben wurde), öffnete eine PR und markierte das Linear-Ticket als „Überprüfung erforderlich“. Gesamtwandzeit: 4 Minuten 18 Sekunden. Ich habe den Unterschied gelesen. Ich habe mich zusammengeschlossen.
Ich saß da und starrte auf den Bildschirm.
## Was ich unterwegs falsch gemacht habe
Ich möchte mich intensiv mit diesem Abschnitt befassen, weil ich dort am meisten gelernt habe und weil jeder „First Look“-Artikel, den ich auf Symphony gelesen habe, ihn beschönigt. Ich habe vier Fehler gemacht, die es wert sind, Ihnen erzählt zu werden.
### Fehler 1: Ich habe Symphony wie Claude Code behandelt
In den ersten beiden Tagen öffnete ich ständig das Devbox-Terminal Symphony in der Erwartung, mit den laufenden Agenten zu *sprechen*. Symphony funktioniert so nicht. Die Agenten sind kopflos. Sie kommunizieren mit ihnen über Tickets. Wenn Sie einem Agenten mehr Kontext geben möchten, bearbeiten Sie die Ticketbeschreibung Linear (oder fügen Sie einen Kommentar hinzu) und lassen Sie die Änderung vom nächsten Abfragezyklus übernehmen. Wenn Sie einen Agenten mitten im Flug umleiten möchten, lautet die Antwort in 90 % der Fälle: „Nicht tun“ – beenden Sie den Lauf, bearbeiten Sie das Ticket und lassen Sie ihn von vorne beginnen.
Das war ein mentaler Wandel. Es dauerte ein paar Tage, bis ich die Agenten nicht mehr als Kollaborateure behandelte, mit denen ich eine Paarprogrammierung durchführte, sondern sie wie Arbeiter behandelte, denen ich Tickets ausstellte. Diese Verschiebung ist übrigens genau das, was das Design von Symphony Ihnen aufzwingen möchte. Gestalten Sie Ihre Tickets wie Produktspezifikationen, nicht wie Slack-Nachrichten.
### Fehler 2: Ich habe vage Tickets geschrieben
Meine ersten Tickets waren die gleichen Einzeiler, die ich einem erfahrenen Teamkollegen geben würde: „Refactoring der Authentifizierungs-Middleware.“ Ein erfahrener Teamkollege füllt die Lücken mit gemeinsamem Kontext. Ein Agent tut das nicht. Als ich schrieb: „Refaktorieren Sie die Authentifizierungs-Middleware, um die JWT-Validierung in eine separate Funktion zu extrahieren, behalten Sie den vorhandenen öffentlichen API von
Das Prinzip: Jede Unklarheit in Ihrem Ticket wird zu einem Münzwurf im Verhalten Ihres Agenten. Tickets sind Reiseführer. Je mehr Sie die Führung von vorne laden, desto weniger müssen die Sensoren schlechte Ergebnisse unterdrücken.
### Fehler 3: Ich habe Computational Sensors übersprungen
Mein Ziel-Repo hatte `npm test` und `npm run lint`, aber ich hatte sie nicht zur `WORKFLOW.md`-Definition von erledigt hinzugefügt. Der Agent führte technisch gesehen Tests durch, wenn ihm danach war. Ungefähr einer von drei PRs hatte bei der Ankunft einen nicht bestandenen Test, den ich wieder aufholen musste. Die Lösung bestand darin, `WORKFLOW.md` dreißig Sekunden lang zu bearbeiten, um Sensorbefehle nicht verhandelbar zu machen. Die Ausfallrate ist auf etwa eins zu fünfzehn gesunken, was dem entspricht, was ich sehe, wenn ich Codex manuell ausführe.
Sie werden nicht glauben, wie oft die Antwort lautet: „Fügen Sie Ihrer Workflow-Datei eine deterministische Prüfung hinzu.“
### Fehler 4: Ich habe versucht, Symphony ohne Worktree-Isolation auszuführen
Aus Faulheit habe ich zwei parallele Läufe auf denselben Checkout desselben Repos verwiesen. Vorhersehbares Gemetzel. Das Design von Symphony geht davon aus – und die Elixir-Referenz erzwingt – Git-Worktree-Isolation pro Ticket. Kämpfe nicht dagegen. Jeder Agent erhält seine eigene Arbeitskopie. So verhindern Sie, dass fünf Agenten, die unterschiedliche Teile Ihrer Codebasis berühren, sich gegenseitig auf dem WIP des anderen herumtrampeln.
An diesem Punkt ähnelt das Design von Die Konvergenz ist kein Zufall. Worktree-per-Run wird zur tragenden Konvention aller seriösen Außengurte.
Wenn Sie diese Art der Einrichtung lieber jemandem überlassen möchten, der es bereits getan hat, erstellt und betreibt [Ramlit Limited](https://www.ramlit.com) genau diese Orchestrierungspipelines für Ingenieurteams, die den Durchsatz ohne die achtwöchige Lernkurve wünschen. Aber der Weg ist wirklich auf eigene Faust begehbar – das ist das meiste, was ich Ihnen hier zeigen möchte.
## Wie sollten Sie die 500 %-Zahl lesen?
Ich habe dir vorhin gesagt, dass ich darauf zurückkommen würde. Die Hauptmetrik von OpenAI lautet, dass einige interne Teams in den ersten drei Wochen nach der Verwendung von
Hier ist die ehrliche Lektüre.
Diese Zahl ist im engeren Sinne real. Der PR-Durchsatz stieg. Das ist messbar, wiederholbar und unbestritten. Aber „gelandete PRs“ sind eine *Generation*-Kennzahl, und wie mehrere Analysten betont haben, lässt sich die **Generation mühelos skalieren. Validierung nicht.** ([opentools.ai](https://opentools.ai/news/openai-symphony-turns-linear-boards-into-autonomous-coding-agent-orchestration)).
In meiner eigenen (kleinen) Stichprobe von dreiwöchiger Nebenprojektarbeit mit Symphony stieg mein PR-Durchsatz bei den Arten von Tickets, in denen Symphony gut ist – um etwa das Drei- bis Vierfache – gut gegliedert, mit nur einem Feature, abdeckbar durch Tests. Bei mehrdeutigen Tickets war die Leistung schlechter als bei mir mit dem Claude-Code, da sich jeder Münzwurf in der Spezifikation verschlimmerte.
Das mentale Modell, für das ich mich entschieden habe: Symphony verschiebt den Engpass vom „Schreiben des Codes“ zum „Schreiben der Spezifikation und Überprüfen der PR“. Das ist ein echter Produktivitätsgewinn, *genau dann, wenn* Ihr Spezifikationserstellungs- und Überprüfungsprozess mithalten kann. Wenn die Überprüfung zum Engpass wird und Sie anfangen, PRs abzusegnen, um die Warteschlange freizumachen, haben Sie einen schnelleren Weg gefunden, technische Schulden zu produzieren.
Wenn Sie also „500 %“ sehen, übersetzen Sie es wie folgt: „Dieses Team verfügte über Spezifikationserstellungs- und Überprüfungsprozesse, die so ausgereift waren, dass tatsächlich fünfmal mehr Code ausgeliefert werden konnte.“ Das ist die Frage, die Sie sich stellen sollten, bevor Sie Symphony einführen – nicht „Kann ich mehr Agenten betreiben?“ aber „Kann ich die Ausgabe weiterer Agenten überprüfen, ohne dass die Qualität einbricht?“
## Was das für die Art und Weise bedeutet, wie ich jetzt baue
In der Woche, nachdem ich Symphony zum Laufen gebracht hatte, habe ich die Art und Weise, wie ich die Arbeit an meinem Hauptkundenprojekt strukturiere, neu geschrieben. Drei konkrete Änderungen.
**Erstens – jede Ausgabe, die ich jetzt öffne, endet mit einem Abschnitt „Definition von erledigt“.** Nicht, weil Symphony es aufgreift (das Kundenprojekt führt Symphony noch nicht aus), sondern weil das Schreiben von Tickets in dieser Form jetzt meine Grundlinie ist. Die Disziplin, die ein Programmieragent verlangt, ist die gleiche Disziplin, von der auch ein junger Ingenieur profitiert.
**Zweitens: Ich habe `npm test`, `npm run lint` und `npm run typecheck` überall als *erforderliche* Schritte in meinen Agenten-Workflowdateien hinzugefügt.** Keine Ausnahmen. Computersensoren sind kostenlos. Benutze sie.
**Dritten – Ich habe aufgehört, zwischen „AI-Tools, die ich verwende“ und „AI-Infrastruktur, die ich betreibe“ zu unterscheiden.** Diese Unterscheidung ist tot. Codex, Claude Code, Cursor – das sind innere Kabelbäume. Sie sitzen in etwas. Die Frage ist, wie *das* etwas aussieht. Meines wird immer mehr wie Symphony aussehen, plus einer inneren Schleife im Ralph-Stil mit rechnerischen Sensoren. Bei Ihnen könnte es anders aussehen. Aber es wird *etwas* sein.
Wenn Sie sich eingehender mit der umfassenderen Verlagerung hin zu Agenten als Infrastruktur befassen möchten, deckt [mein Beitrag über Anthropics langjähriges Agentensystem](/anthropic-long-running-agent-harness/) die Seite des inneren Netzwerks aus der Perspektive von Claude ab, und die [Paperclip-Fallstudie über die Orchestrierung von Null-Menschen-Unternehmen](/paperclip-orchestrating-zero-human-ai-companies/) zeigt, was passiert, wenn Sie auf das Äußere drängen Kabelbaummuster bis zu seinem logischen Abschluss. Was die praktische Codex-Seite angeht, zeigt [mein Vergleich von Codex
## Ein Wort dazu, wie es weitergeht
Drei Vorhersagen, sortiert von „Ich bin zuversichtlich“ bis „Ich wette, einen Kaffee.“
**Zuversichtlich.** Innerhalb von zwölf Monaten wird jede ernsthafte Ingenieursorganisation etwas in der Form von Symphony in Produktion haben. Es könnte Symphony selbst sein, es könnte Gas Town sein, es könnte Archon sein, es könnte ein selbst entwickelter Wrapper sein. Die Form – Issue-Tracker-als-Warteschlange, isolierter Arbeitsbereich pro Aufgabe, deterministische Sensoren in der Schleife, menschliche Überprüfung am Ende – ist die Zukunft. Der Wortschatz konvergiert bereits. Die Umsetzungen folgen.
**Einigermaßen zuversichtlich.** Der Engpass für die meisten Teams wird nicht der Orchestrator sein. Es wird das Geschirr *innerhalb* des Agenten sein – die Eingabeaufforderungen, die Fähigkeiten, die Playbooks, die Sensorbefehle. Teams, die bereits in Disziplin im `CLAUDE.md`-Stil investieren, werden Symphony schneller einführen als Teams, die dies nicht tun, und die Kluft wird größer. (Wenn Sie [Agentenfähigkeiten](/claude-code-agent-skills-guide/) ignoriert haben, ist es jetzt an der Zeit damit aufzuhören.)
**Wetten auf einen Kaffee.** Innerhalb von sechs Monaten wird Linear native Unterstützung im Symphony-Stil liefern und entweder OpenAI oder ein Dritter wird eine gehostete Symphony-Laufzeit veröffentlichen, die den Devbox-Teil abstrahiert. Das derzeitige Muster „Mieten Sie Ihre eigene Devbox“ ist betrieblich zu schwer, um die langfristige Antwort zu sein.
Aber hier ist der tiefere Punkt. Symphony ist nicht wichtig, da es der beste Orchestrator ist. Es ist wichtig, weil es uns eine *gemeinsame Spezifikation* gab – ein Vokabular, das jeder implementieren, forken oder stehlen kann. Das ist der Schritt, der ein Werkzeug in eine Kategorie verwandelt.
Gehen Sie zurück zu dem Moment, den ich in der Eröffnung beschrieben habe – das elfminütige Linear-Ticket, das ohne mich verschickt wurde. Dieser Moment ist aufgrund der Tat eines Agenten nicht beeindruckend. Es ist beeindruckend, weil *eine gemeinsame Spezifikation, die als Außengurt, um jeden Innengurt, um jedes Modell herum läuft*, maßstabsgetreu möglich ist.
Wenn Sie heute nur eines lesen, lesen Sie [Symphony SPEC.md](https://github.com/openai/symphony/blob/main/SPEC.md) von vorn bis hinten. Es sind zwölf Seiten. Wenn Sie damit fertig sind, werden Sie Ihren aktuellen AI-Workflow anders sehen. Und das – nicht die 500 %, nicht die 15.000 Sterne – ist die tatsächliche Verschiebung, für die es sich zu optimieren lohnt.
Weisen Sie sich jetzt ein echtes Ticket zu. Der, den du aufgeschoben hast. Schreiben Sie es wie eine Spezifikation. Fügen Sie eine Definition von „erledigt“ hinzu. Stellen Sie sich vor, ein Agent, den Sie noch nie getroffen haben, würde es lesen.
Dann fragen Sie sich: *Würde die Arbeit erledigt?*
Wenn die Antwort „Nein“ lautet, lag das Problem nie beim Agenten.
## Häufig gestellte Fragen
### Was ist OpenAI Symphony und wie funktioniert es?
Symphony ist eine Open-Source-Spezifikation von OpenAI, die einen Issue-Tracker wie Linear in eine Steuerungsebene für autonome Codierungsagenten verwandelt. Es fragt den Tracker alle 30 Sekunden ab, beansprucht Tickets, die einem Trigger-Label entsprechen, erstellt für jedes Ticket einen isolierten Git-Arbeitsbaum, führt einen Codex- oder Claude Code-Agenten in diesem Arbeitsbereich aus, bis er eine PR erstellt, und verknüpft die PR wieder mit dem Ticket. Die Referenzimplementierung ist in Elixir, aber die Spezifikation ist sprachunabhängig. Die vollständige exemplarische Vorgehensweise finden Sie oben unter [Einrichten von Symphony auf einem echten Repo](#setting-up-symphony-on-a-real-repo).
### Wie unterscheidet sich Symphony von Gas Town, Archon und Ralph loops?
Symphony geht von einem Ticket, einem Agenten, einem PR aus – und der Issue-Tracker ist die Warteschlange. Gas Town betreibt koordinierte Kolonien von 20 bis 30 parallelen Agenten mit klaren Rollen. Archon erstellt deterministische YAML-Workflows rund um jeden Codierungsagenten mit expliziten Phasentoren. Ralph loops sind die minimal lebensfähige innere Schleife – `while not done: run agent again with latest state`. Sie ergänzen sich: Ein Symphony-Ticket kann eine Ralph-Schleife in seinen Arbeitsbereich einschließen.
### Hält der OpenAI Symphony 500 % PR-Erhöhungsanspruch in der Praxis stand?
Diese Behauptung gilt für eng begrenzte Tickets in Teams mit ausgereiften Spezifikationserstellungs- und Überprüfungsprozessen – der Generierungsdurchsatz steigt stark an. Aber „gelandete PRs“ sind eine Generationsmetrik und die Validierung lässt sich nicht auf die gleiche Weise skalieren. Bei meinen eigenen Tests habe ich bei gut abgegrenzten Tickets ein 3- bis 4-faches und bei mehrdeutigen Tickets ein Ergebnis festgestellt, das schlechter als der Ausgangswert war. Die ehrliche Lektüre: Symphony verlagert den Engpass von der Codierung auf das Schreiben und Überprüfen von Spezifikationen.
### Was ist harness engineering und warum ist es für Codierungsagenten wichtig?
Harness Engineering ist die Disziplin, alles rund um das Modell zu entwerfen, was es zu einem zuverlässigen Agenten macht – Leitfäden (Feedforward-Steuerung: Eingabeaufforderungen, Fähigkeiten, Playbooks) und Sensoren (Feedback-Validierung: Linters, Tests, Typprüfer, LLM als Richter). Der [Martin Fowler-Artikel](https://martinfowler.com/articles/harness-engineering.html) von Birgitta Böckeler ist die kanonische Referenz. Das Framework unterscheidet den inneren Kabelbaum (innerhalb des Agenten) vom äußeren Kabelbaum (um den Agenten herum), und Symphony ist im Grunde ein äußerer Kabelbaum.
### Muss ich Elixir kennen, um Symphony verwenden zu können?
Nein. Die Elixir-Implementierung ist eine Referenz, keine Anforderung. Die Spezifikation ist das eigentliche Artefakt, und OpenAI hat gezeigt, dass Codex die Spezifikation in TypeScript, Go, Rust, Java und Python erneut implementieren kann. Wenn Ihr Team bereits eine dieser Sprachen verwendet, ist die Neuimplementierung des Orchestrators ein umsetzbares Wochenendprojekt. Wenn Sie mit Elixir vertraut sind oder bereit sind, die Grundlagen zu erlernen, ist die Referenz sofort einsatzbereit.
## Lasst uns zusammenarbeiten
Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.
* **Fiverr** (benutzerdefinierte Builds und Integrationen): [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portfolio**: [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (Unternehmenslösungen): [ramlit.com](https://www.ramlit.com)
* **ColorPark** (Design & Branding): [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (Sicherheitsdienste): [xcybersecurity.io](https://www.xcybersecurity.io)
