OpenAI setzt sich energisch zur Wehr: Die "Gehirne" von Codex werden erstmals enthüllt, und die Architektur für bis zu 800 Millionen Nutzer setzt sich konfrontativ mit Claude auseinander.

Neuerdings hat Claude Code von Anthropic die Welt der KI-Programmierung auf den Kopf gestellt!

Der KI-Assistent, der in der Kommandozeile selbständig Code lesen, ändern und Tests ausführen kann, lässt viele Entwickler den Satz „Das ist die Zukunft“ fallen.

Plötzlich waren die sozialen Medien voller Kommentare wie „Claude Code schlägt Cursor, Codex und Antigravity“.

Während alle dachten, OpenAI würde noch den Trumpf GPT - 5.3 aufbahren, haben heute seine offizielle Twitter - Seite und Altman auf X zwei Bomben geworfen:

1. Enthüllung der Agent Loop - Architektur: Erstmalige Offenlegung, wie das „Gehirn“ von Codex funktioniert

2. PostgreSQL - Grenzarbeit: Ein einzelner Master - Server bewältigt die wilden Operationen von 800 Millionen Benutzern

Dieser Kombinationseinschlag war wirklich beeindruckend.

Heute wollen wir herausfinden, welche Trumpfkarten OpenAI eigentlich aufbahren wird.

Agent Loop

Wie funktioniert das „Gehirn“ von Codex?

Was ist die Agent Loop?

Wenn Sie Codex CLI, Claude Code oder andere CLI - Tools verwendet haben, fragen Sie sich vielleicht:

Wie weiß dieses Ding, was ich will? Wie kann es selbständig Dateien lesen, Code schreiben und Befehle ausführen?

Die Antwort verbirgt sich in etwas, das Agent Loop (Intelligent - Agenten - Schleife) genannt wird.

Einfach ausgedrückt, fungiert die Agent Loop wie ein „Generalstabchef“, der „Benutzerabsicht“, „Modellgehirn“ und „Ausführungswerkzeuge“ zu einer perfekten Schleife verbindet.

Dies ist kein gewöhnliches „Frage - Antwort“ - Verfahren, sondern ein funktionsfähiges System, das „Beobachten - Denken - Handeln - Feedback“ umfasst.

Wir öffnen jetzt diese schwarze Kiste und schauen uns an, wie ein echter KI - Agent funktioniert.

Wie funktioniert eine vollständige Agent Loop?

Wir erklären dies anhand eines konkreten Beispiels.

Nehmen wir an, Sie geben in der Kommandozeile ein: Füge der README.md - Datei des Projekts ein Architekturdiagramm hinzu.

Schritt 1: Erstellen des Prompts

Dies ist wie das Versenden eines Arbeitsauftrags an das Gehirn.

Codex gibt Ihre Worte nicht direkt an das Modell weiter, sondern erstellt zunächst einen sorgfältig entworfenen „Prompt“:

• Wer bin ich: (System): Teilt dem Modell mit, wer es ist und was es kann
• Welche Werkzeuge habe ich (Tools): Welche Werkzeuge aufgerufen werden können (z. B. Shell - Befehle, Dateioperationen)
• Umgebungskontext (Context): In welchem Verzeichnis sich der Benutzer befindet und welche Shell verwendet wird
• Benutzeranweisung: Füge der README.md - Datei ein Architekturdiagramm hinzu.

Dies ist wie das Versenden einer detaillierten Arbeitsmail an das Modell, anstatt nur zu sagen: „Hilf mir bei der Arbeit.“

Schritt 2: Modellinferenz (Inference)

In diesem Schritt beginnt das Gehirn zu arbeiten.

Codex sendet diesen Prompt an die ResponsesAPI, und das Modell beginnt zu überlegen:

„Der Benutzer möchte ein Architekturdiagramm hinzufügen. Ich muss zunächst sehen, wie die aktuelle README.md aussieht …“

Dann trifft das Modell die Entscheidung: Rufe das Shell - Werkzeug auf und führe cat README.md aus.

Schritt 3: Werkzeugaufruf (ToolCall)

Codex erhält die Anfrage des Modells und führt den Befehl lokal aus, um den Inhalt der README.md - Datei auszulesen.

Das ist wie das Bewegen von Händen und Füßen.

Schritt 4: Ergebnisrückmeldung

In diesem Schritt gibt die Kommandozeile den Inhalt der README.md - Datei aus.

An diesem Punkt ist der Prozess noch nicht abgeschlossen. Codex fügt die Ausgabe des Befehls an den Prompt an und sendet ihn erneut an das Modell.

Schritt 5: Schleife

Das Modell sieht den Inhalt der README.md - Datei und führt erneut eine Inferenz durch:

Vielleicht generiert es ein Mermaid - Diagramm, vielleicht schreibt es direkt einen ASCII - Grafikcode … und ruft dann das Werkzeug auf, um die Datei zu schreiben.

Diese Schleife dauert an, bis das Modell denkt, dass die Aufgabe abgeschlossen ist, und eine Nachricht „Ich habe es geschafft“ ausgibt.

Es löst Probleme, anstatt nur auf Fragen zu antworten.

Warum ist das wichtig?

Vielleicht sagen Sie: „Ist das nicht einfach nur ein häufigerer API - Aufruf?“

Aber es ist nicht so einfach.

Herkömmliche LLM - Anwendungen funktionieren im „Frage - Antwort“ - Modus: Sie fragen, es antwortet, fertig.

Aber die Agent Loop macht aus der KI einen selbständigen Arbeiter.

Es plant seinen eigenen Weg (Chain of Thought).

Es prüft selbst auf Fehler (Self - Correction).

Es validiert die Ergebnisse selbst (Feedback Loop).

Das ist ein echter „KI - Agent“.

Und die Agent Loop ist die Brücke, die es der KI ermöglicht, vom „Unterhaltungskompagnon“ zum „selbständigen Arbeiter“ zu werden.

Leistungsoptimierung

Zwei Schlüsseltechnologien

OpenAI hat in einem Artikel zwei fortschrittliche Optimierungen geteilt, die zwei Hauptprobleme bei der Agent - Entwicklung lösen:

Problem 1: Kostenexplosion

Bei jedem Durchlauf der Agent Loop muss die gesamte vorherige Gesprächsgeschichte (einschließlich langwieriger Fehlermeldungen und Dateiinhalte) erneut an das Modell gesendet werden.

Je länger das Gespräch, desto höher die Kosten. Ohne Optimierung wachsen die Kosten quadratisch.

Lösung: Prompt Caching (Prompt - Caching)

OpenAI verwendet eine Caching - Strategie, die ähnlich wie eine „Präfixübereinstimmung“ funktioniert.

Einfach ausgedrückt: Solange der erste Teil des an das Modell gesendeten Inhalts (Systemanweisungen, Werkzeugdefinitionen, Gesprächsverlauf) unverändert bleibt, muss der Server nicht neu berechnen, sondern kann einfach aus dem Cache laden.

Dieser Trick reduziert die Kosten für lange Gespräche von einer quadratischen auf eine lineare Wachstumsrate.

Aber hier gibt es eine Falle: Jede Änderung des Prompt - Präfixes führt zum ungültig werden des Caches. Beispielsweise:

• Zwischenzeitliche Modelländerung
• Änderung der Berechtigungs - Konfiguration
• Änderung der MCP - Werkzeugliste

Das OpenAI - Team hat sogar in einem Artikel zugeben müssen, dass ihre frühe MCP - Werkzeugintegration fehlerhaft war: Die Reihenfolge der Werkzeugliste war instabil, was dazu führte, dass der Cache häufig ungültig wurde.

Problem 2: Begrenztes Kontextfenster

Selbst das größte Modell hat ein begrenztes Kontextfenster.

Wenn der Agent eine riesige Protokolldatei liest, wird das Kontextfenster sofort voll, und die früheren Informationen werden überschrieben.

Für Programmierer bedeutet dies: „Hast du die von mir definierten Funktionen vergessen?“

Dies ist nicht nur dumm, sondern auch eine Katastrophe.

Lösung: Compaction (Gesprächs - Kompression)

Wenn die Anzahl der Tokens einen Schwellenwert überschreitet, ruft Codex nicht einfach die alten Nachrichten löschen, sondern einen speziellen /responses/compact - API - Aufruf, um die Gesprächsgeschichte in eine kürzere Zusammenfassung zu „komprimieren“.

Eine normale Zusammenfassung (Summary) macht aus einem langen Text einfach einen kurzen Text und verliert dabei viele Details.

Die Compaction von OpenAI gibt stattdessen einen encrypted_content (verschlüsselten Inhalt) zurück, der das „implizite Verständnis“ des Modells für das ursprüngliche Gespräch beibehält.

Das ist wie das Komprimieren eines dicken Buches in eine „Gedächtniskarte“. Das Modell kann sich anhand der Karte an den gesamten Buchinhalt erinnern.

Dies ermöglicht es dem Agenten, auch bei der Bearbeitung von überlangen Aufgaben weiterhin „intelligent“ zu agieren.

Durch die offizielle Enthüllung des „Gehirns“ hinter Codex CLI, der „Agent Loop“, sendet OpenAI ein Signal: Die KI wird tatsächlich die Arbeit erledigen.

Ein einzelner Master - Server für 800 Millionen Benutzer

Extreme Operationen mit PostgreSQL

Während alle über die Leistungen von AI - Modellen sprechen, hat OpenAI still und leise eine noch aufregendere Nachricht preisgegeben:

Der globale Betrieb von 800 Millionen ChatGPT - Benutzern und die Verarbeitung von Millionen von Abfragen pro Sekunde wird nur von einer einzelnen PostgreSQL - Datenbank mit einem Master - Knoten unterstützt!

Es schafft dies mit nur einem PostgreSQL - Master - Knoten + 50 schreibgeschützten Replikaten.

„800 Millionen Benutzer? Das ist doch ein Scherz!“, staunt ein Netizen.

In einer Zeit, in der verteilte Architekturen vorherrschend sind, hört man ständig von „Microservices“, „Sharding“ und „NoSQL“.

Probleme, die mit einem riesigen verteilten Cluster gelöst werden können, werden niemals mit einem einzelnen Server bewältigt.

Aber