Leakage des Ultraman-Kleinnamens: OpenAI übergibt 100 % der Codearbeiten an Codex. Erst jetzt haben die Ingenieure die Betriebslogik des "Gehirns" von Codex aufgedeckt. Übertrumpft es die Claude-Architektur?

Mit einer PostgreSQL-Hauptdatenbank und 50 schreibgeschützten Replikaten hat man es geschafft, die 800 Millionen Nutzer von ChatGPT zu bewältigen!

In letzter Zeit haben die Ingenieure von OpenAI nicht nur diese erstaunliche Nachricht preisgegeben, sondern auch das "Gehirn" von Codex vollständig enthüllt. Auf der offiziellen Engineering-Blog-Seite von OpenAI hat Michael Bolin, ein Ingenieur und Mitglied des Technical Staff, einen Artikel mit dem Titel "Enthüllung der Codex-Agentenschleife" veröffentlicht. In diesem Artikel wird tiefgehend das Kernframework von Codex CLI, die Agentenschleife (Agent Loop), enthüllt, und es wird ausführlich erklärt, wie Codex den Kontext beim Abfragen des Modells aufbaut und verwaltet, sowie praktische Hinweise und bewährte Verfahren für alle auf der Responses API basierenden Agentenschleifen.

Nach Veröffentlichung dieser Nachrichten hat es in technischen Foren wie Hacker News und auf sozialen Plattformen große Aufmerksamkeit erregt. "Scheinbar einfache Technologien gewinnen am Ende. OpenAI beweist, dass eine gute Architektur weitaus wichtiger ist als aufwendige Tools."

Es ist erwähnenswert, dass ein Netzbürger kürzlich enthüllte, dass ein Ingenieur von Anthropic behauptet habe, "dass die Architektur, die sie für die Claude Code UI verwenden, schlecht und ineffizient sei". Gerade erst ist auf X eine Meldung aufgetaucht: Codex hat die gesamte Codeerstellung bei OpenAI übernommen.

Als auf die Frage "Welchen Prozentsatz Ihrer Codierung basiert auf OpenAI-Modellen?" antwortete roon: "100%. Ich schreibe keinen Code mehr." Früher hatte Sam Altman öffentlich gepostet: "roon ist mein Alias."

Enthüllung des "Gehirns" von Codex

"Der Kern jedes KI-Agents ist die Agentenschleife, die die Interaktion zwischen Nutzer, Modell und Tools zur Ausführung von sinnvollen Softwareaufgaben koordiniert."

Innerhalb von OpenAI umfasst "Codex" eine Reihe von Software-Agentenprodukten, darunter Codex CLI, Codex Cloud und das Codex VS Code-Plugin. Alle basieren auf demselben Framework und denselben Ausführungslogiken.

Vereinfachtes Schema der Agentenschleife

Zunächst empfängt der Agent die Eingabe des Nutzers und fügt sie in die für das Modell vorbereitete Texteinstruktionsmenge ein, die als Prompt bezeichnet wird. Im nächsten Schritt wird das Modell abgefragt, indem die Anweisungen an das Modell gesendet und eine Antwort angefordert werden. Dieser Prozess wird als Inferenz bezeichnet. Bei der Inferenz wird der Textprompt zunächst in eine Reihe von Eingabetoken umgewandelt, die dann zur Sampling des Modells verwendet werden, um eine neue Sequenz von Ausgabetoken zu generieren. Die Ausgabetoken werden in Text zurückgewandelt und bilden die Antwort des Modells. Da die Token schrittweise generiert werden, kann dieser Rückwandlungsprozess synchron mit der Ausführung des Modells erfolgen. Dies ist auch der Grund, warum viele Anwendungen auf Basis von Large Language Modells einen Stream-Output unterstützen. In der Praxis ist die Inferenzfunktion normalerweise hinter einer Text-API verpackt, um die Details der Tokenisierung zu abstrahieren.

Nach Abschluss des Inferenzschritts erzeugt das Modell zwei Arten von Ergebnissen: (1) Eine endgültige Antwort auf die ursprüngliche Eingabe des Nutzers; (2) Eine Anforderung an den Agenten, einen bestimmten Tool-Aufruf auszuführen. Im zweiten Fall führt der Agent den Tool-Aufruf aus und fügt das Tool-Ausgabeergebnis an den ursprünglichen Prompt an. Dieses Ausgabeergebnis wird zur Generierung neuer Eingabeinhalte verwendet, und das Modell wird erneut abgefragt. Der Agent versucht dann, die Aufgabe erneut abzuschließen, indem er diese neuen Informationen berücksichtigt. Dieser Prozess wird wiederholt, bis das Modell aufhört, Tool-Aufrufanweisungen zu senden und stattdessen eine Nachricht an den Nutzer generiert (in den OpenAI-Modellen wird diese Nachricht als Assistentennachricht bezeichnet). In den meisten Fällen beantwortet diese Nachricht direkt die ursprüngliche Anfrage des Nutzers oder stellt dem Nutzer eine Folgefrage.

Da der Agent Tool-Aufrufe ausführen kann, die die lokale Umgebung ändern können, ist seine "Ausgabe" nicht nur auf die Assistentennachricht beschränkt. In vielen Szenarien ist der Kernoutput des Software-Agents der Code, der auf dem Nutzergerät geschrieben oder bearbeitet wird. In jedem Fall endet jede Interaktionsrunde jedoch mit einer Assistentennachricht, die das Signal dafür ist, dass die Agentenschleife in den Endzustand übergeht. Aus Sicht des Agenten ist seine Aufgabe abgeschlossen, und die Steuerung wird an den Nutzer zurückgegeben.

Mehrfache Agentenschleifen

Dies bedeutet, dass je umfangreicher der Dialoginhalt ist, desto länger wird auch der für die Modellabfrage verwendete Prompt. Alle Modelle haben jedoch eine Beschränkung des Kontextfensters, d.h. die maximale Anzahl von Token, die in einem einzelnen Inferenzaufruf verarbeitet werden können. Der Agent kann in einer einzigen Dialogrunde Hunderte von Tool-Aufrufen starten, was möglicherweise die Kapazität des Kontextfensters erschöpft. Daher ist die Verwaltung des Kontextfensters eine der vielen Aufgaben des Agenten.

Wie funktioniert diese Agentenschleife?

Codex nutzt die Responses API, um diese Agentenschleife anzutreiben. Der Blogbeitrag enthüllt viele Details über den tatsächlichen Betrieb, darunter:

Codex gibt die Worte des Nutzers nicht direkt an das Large Language Modell weiter, sondern erstellt aktiv eine sorgfältig gestaltete Prompt-Struktur, die Anweisungen aus mehreren Rollen enthält. Die Eingabe des Nutzers erscheint erst am Ende.

Zwischen der Modellinferenz und den Tool-Aufrufen können mehrere Iterationen stattfinden, und der Inhalt des Prompts wird kontinuierlich erweitert.

Aufbau des initialen Prompts

Als Endnutzer müssen Sie beim Aufruf der Responses API nicht den für die Modellabfrage verwendeten Prompt wortwörtlich angeben. Sie müssen nur die verschiedenen Eingabetypen in der Abfrage angeben, und der Responses API-Server entscheidet, wie diese Informationen in ein für das Modell verarbeitbares Prompt-Format organisiert werden sollen. Im initialen Prompt ist jedem Eintrag in der Liste eine Rolle zugeordnet. Diese Rolle bestimmt den relativen Gewichtungsanteil des entsprechenden Inhalts. Die Priorität ist von hoch nach niedrig in die folgenden Kategorien eingeteilt: System, Entwickler, Nutzer, Assistent.

Die Responses API empfängt eine JSON-Nutzlast mit mehreren Parametern. Drei Kernparameter sind:

• Anweisungen: System- oder Entwicklermeldungen, die in den Modellkontext eingefügt werden
• Tools: Liste der Tools, die das Modell während der Generierung der Antwort aufrufen kann
• Eingabe: Liste von Text-, Bild- oder Dateieingaben, die an das Modell übergeben werden

In Codex wird, wenn konfiguriert, der Inhalt des Anweisungsfelds aus der Modellanweisungsdatei in der ~/.codex/config.toml-Konfigurationsdatei gelesen. Wenn nicht konfiguriert, wird die Basisanweisung, die mit diesem Modell verknüpft ist, verwendet. Die modell-spezifischen Anweisungen werden im Codex-Code-Repository gespeichert und in der Befehlszeilenschnittstelle verpackt. Das Tools-Feld ist eine Liste von Tooldefinitionen, die dem von der Responses API definierten Schema entsprechen. Für Codex umfasst diese Liste drei Teile: Die von der Codex-Befehlszeilenschnittstelle mitgelieferten Tools, die von der Responses API bereitgestellten und an Codex freigegebenen Tools sowie die benutzerdefinierten Tools, die normalerweise vom Nutzer über den MCP-Server bereitgestellt werden. Das Eingabefeld der JSON-Nutzlast ist eine Liste von Einträgen. Bevor die Nutzeranfrage hinzugefügt wird, fügt Codex zunächst die folgenden Einträge in diese Eingabe ein:

Eine Meldung mit der Rolle "Entwickler" (role=developer), um die Sandbox-Umgebung zu beschreiben, die nur für die im Tools-Teil definierten integrierten Codex-Shell-Tools gilt. Das bedeutet, dass andere Tools (z.B. die vom MCP-Server bereitgestellten Tools) nicht von Codex' Sandbox-Beschränkungen betroffen sind und selbst für die Umsetzung ihrer eigenen Schutzregeln verantwortlich sind. Diese Meldung basiert auf einer Vorlage, und der Kerninhalt stammt aus einem Markdown-Codeausschnitt, der in der Codex-Befehlszeilenschnittstelle verpackt ist.

Eine Meldung mit der Rolle "Entwickler", deren Inhalt aus dem developer_instructions-Konfigurationswert in der Nutzerkonfigurationsdatei config.toml gelesen wird.

Eine Meldung mit der Rolle "Nutzer", deren Inhalt die Nutzeranweisung ist. Dieser Inhalt stammt nicht aus einer einzigen Datei, sondern wird aus mehreren Datenquellen aggregiert. Im Allgemeinen werden Anweisungen, die konkreter formuliert sind, später in der Liste platziert:

Der Inhalt der Dateien AGENTS.override.md und AGENTS.md im Verzeichnis $CODEX_HOME wird geladen.

Innerhalb der standardmäßigen Größe von 32 Kilobyte wird von der Git-/Projektwurzel des aktuellen Arbeitsverzeichnisses (falls vorhanden) bis zum aktuellen Arbeitsverzeichnis selbst nach oben durchsucht, um den Inhalt beliebiger AGENTS.override.md- oder AGENTS.md-Dateien oder den Inhalt beliebiger Dateien zu laden, die im project_doc_fallback_filenames-Parameter der config.toml-Konfigurationsdatei angegeben sind.

Wenn die entsprechenden Fähigkeiten konfiguriert sind, werden die folgenden Inhalte ergänzt: Eine kurze Einführung in die Fähigkeiten, die zugehörigen Fähigkeitsmetadaten und eine Erläuterung zur Verwendung der Fähigkeiten.

Eine Meldung mit der Rolle "Nutzer", um die aktuelle lokale Umgebung des Agenten zu beschreiben. Dabei wird das aktuelle Arbeitsverzeichnis und die vom Nutzer verwendete Terminal-Shell angegeben.

Nachdem Codex alle obigen Berechnungen durchgeführt und die Eingabe initialisiert hat, wird die Nutzeranfrage hinzugefügt, um den Dialog zu starten. Beachten Sie, dass jedes Element in der Eingabe ein JSON-Objekt ist, das die Felder "Typ", "Rolle" und "Inhalt" enthält. Nachdem Codex die vollständige JSON-Nutzlast erstellt hat, die an die Responses API gesendet werden soll, wird eine HTTP POST-Anfrage mit Autorisierungs-Headern (und ggf. zusätzlichen HTTP-Headern und Abfrageparametern) gemäß der Konfiguration des Responses API-Endpunkts in der ~/.codex/config.toml-Datei gesendet. Wenn der OpenAI-Responses API-Server diese Anfrage empfängt, wird die JSON-Daten verwendet, um die Prompt-Informationen für das Modell abzuleiten (es sei darauf hingewiesen, dass benutzerdefinierte Implementierungen der Responses API möglicherweise andere Methoden verwenden).

Wie man sieht, wird die Reihenfolge der ersten drei Elemente im Prompt vom Server und nicht vom Client bestimmt. Das bedeutet, dass nur der Inhalt der Systemmeldung ebenfalls vom Server kontrolliert wird, während Tools und Anweisungen vom Client festgelegt werden. Darauf folgen die Eingabedaten in der JSON-Nutzlast, und so ist der Prompt zusammengebaut.

Modellabfrage

Nachdem der Prompt bereit ist, beginnt das Modell mit der Abfrage.

Erste Interaktion: Diese HTTP-Anfrage an die Responses API startet die erste Runde der Interaktion im Codex-Dialog. Der Server antwortet in Form eines Server-Sent Events (SSE)-Streams. Die Daten jedes Events sind eine JSON-Nutzlast, deren "type"-Feld mit "response" beginnt. Codex empfängt diesen Event-Stream und veröffentlicht ihn erneut als internes Event-Objekt, das vom Client aufgerufen werden kann. Events wie "response.output_text.delta" werden verwendet, um die Stream-Ausgabe-Funktion für die Benutzeroberfläche zu implementieren, während andere Events wie "response.output_item.added" in Objekte umgewandelt werden und an die Eingabe angefügt werden, um für nachfolgende Responses API-Aufrufe verwendet zu werden.

Wenn die erste Anfrage an die Responses API zwei "response.output_item.done"-Events zurückgibt, eines mit dem Typ "Inferenz" (reasoning) und eines mit dem Typ "Funktionsaufruf" (function_call), müssen diese Events bei der erneuten Abfrage des Modells in Kombination mit den Rückgabewerten des Tool-Aufrufs im Eingabefeld der JSON-Nutzlast berücksichtigt werden. Die endgültige Prompt-Struktur für die Modellabfrage in nachfolgenden Abfragen sieht wie folgt aus:

Es ist besonders wichtig zu beachten, dass der alte Prompt ein vollständiges Präfix des neuen Prompts ist. Diese Gestaltung ist beabsichtigt, da es den Nutzern ermöglicht, die Effizienz nachfolgender Anfragen durch die Verwendung von Prompt-Caching zu verbessern.

In der Codex-Befehlszeilenschnittstelle wird die Assistentennachricht dem Nutzer angezeigt, und der Fokus wird auf die Eingabe-Editierzone gelegt, um den Nutzer darauf hinzuweisen, dass es an seiner Zeit ist, den Dialog fortzusetzen. Wenn der Nutzer antwortet, müssen sowohl die Assistentennachricht der letzten Runde als auch die neue Nachricht des