Der neue AI-Stack: Modelle, Harnesses, Loops und selbstverbessernde Agenten

Alle Welt redet über KI-Modelle.

Niemand spricht über die Schicht, die sie tatsächlich nützlich macht.

Claude Code. Codex. Cursor.

Das sind nicht nur Modelle.

Es sind Modelle, die in ein System eingebettet sind.

Dieses System nennt man ein "Harness" (Geschirr/Steuerung).

Und die besten Harnesses verbessern sich inzwischen selbst.

Hier ist alles, was du über den neuen KI-Stack wissen musst.

Die Lüge, die jeder über KI-Produkte glaubt

Die meisten Leute denken, KI-Fortschritt = intelligentere Modelle.

Dem ist nicht so.

Das Modell ist nur ein Teil des Stacks.

Die Architektur ist veröffentlicht. Jeder kopiert denselben Transformer. Jedes Labor verwendet dieselben Bausteine.

Was Claude Code tatsächlich von einem Wochenendprojekt unterscheidet, ist nicht das Modell.

Es ist das, was das Modell umgibt.

Das Harness.

Im Jahr 2017 drehte sich der KI-Fortschritt um Aufmerksamkeitsmechanismen. Im Jahr 2020 um Skalierung. Im Jahr 2026 dreht er sich um Harness-Engineering.

Und Harnesses werden jetzt von KI entworfen, nicht von Menschen.

Was ist ein Harness?

Ein Harness ist das System, das ein Modell umgibt.

Es bestimmt:

→ Wie das Modell denkt und plant

→ Wann es Werkzeuge aufruft und was es mit den Ergebnissen macht

→ Woran es sich über mehrere Schritte hinweg erinnert

→ Wie es Artefakte speichert und den Zustand verwaltet

→ Wie es seine eigene Ausgabe bewertet

→ Wann es zurückspringt und es erneut versucht

Stell es dir wie ein Betriebssystem vor.

Das Modell ist die CPU. Das Harness ist das OS.

Du kannst eine leistungsstarke CPU und eine schreckliche Software haben und nichts Nützliches ausliefern. Du kannst eine bescheidene CPU und eine exzellente Software haben und etwas Großartiges ausliefern.

Die erfolgreichsten Coding-Agenten – Claude Code, Codex, Cursor – haben alle dieselbe Erkenntnis:

Die Schleife ist genauso wichtig wie das Modell.

Die 3 Harness-Muster, die jeder KI-Entwickler braucht

Jedes produktive KI-System verwendet mindestens eines davon.

Muster 1: Die Schleife

Das Modell antwortet nicht einmal und hört dann auf.

Es durchläuft eine Schleife.

Planen → Ausführen → Beobachten → Verbessern → Wiederholen

Das ist der Kern jedes Coding-Agenten.

Eine vereinfachte Claude Code-Schleife:

1. Aufgabe lesen
2. Ansatz planen
3. Code schreiben → ausführen
4. Sehen, was fehlgeschlagen ist
5. Fehler beheben
6. Erneut ausführen
7. Wiederholen, bis Tests bestanden sind

Das Modell ist in Schleife 3 nicht schlauer als in Schleife 1.

Aber das System ist es.

Jede Schleife gibt dem Modell neuen Kontext – Fehlermeldungen, Testergebnisse, Ausführungsabläufe.

Die Ausgabe von Schleife 1 wird zur Eingabe von Schleife 2.

Dieser zusammengesetzte Kontext ist der Grund, warum agentische Systeme bei komplexen Aufgaben besser abschneiden als einmalige Aufforderungen.

Die wichtigste Erkenntnis: Das Modell bleibt gleich. Der Kontext wird schlauer.

Muster 2: Dateisystem als Gedächtnis

Die meisten Entwickler stopfen alles in das Kontextfenster.

Das ist eine Falle.

Langfristige Aufgaben erzeugen:

→ Experimentprotokolle

→ Code-Unterschiede → Fehlerabläufe

→ Bisherige Rollout-Verläufe → Zusammenfassungen von Papieren → Zwischenartefakte

All das wächst weit über jedes Kontextfenster hinaus.

Die Lösung: in Dateien schreiben, nicht in den Kontext.

1# Schlecht: alles im Kontext
2context = vorherige_ausgabe + werkzeug_ergebnis + fehlerprotokoll + verlauf...
3# Explodiert bei Schritt 47
4
5# Gut: das Dateisystem nutzen
6agent.write("experiments/run_3/error_log.txt", fehlerablauf)
7agent.write("experiments/run_3/results.json", metriken)
8
9# Später liest der Agent nur, was er braucht
10relevant = agent.read("experiments/run_3/results.json")

Das ändert alles für langfristige Aufgaben.

→ Agent kann nach Abstürzen fortfahren

→ Agent kann über seinen eigenen Ausführungsverlauf nachdenken

→ Kontext bleibt auch bei Schritt 200 sauber

→ Mehrere Unter-Agenten können den Zustand über Dateien teilen

Die besten Agenten behandeln das Dateisystem wie ein zweites Gehirn.

Keine Müllhalde. Ein strukturiertes Gedächtnis.

Muster 3: Unter-Agenten

Ein Agent kann nicht alles erledigen.

Die besten Systeme erzeugen parallele Unter-Agenten.

Der übergeordnete Agent:

→ Zerlegt die Aufgabe in unabhängige Teilaufgaben

→ Startet Unter-Agenten, um sie parallel auszuführen

→ Überwacht ihren Status → Führt ihre Ergebnisse wieder zusammen

Beispiel für ein Recherche-Harness:

1Übergeordneter Agent erhält: "Schreibe einen vollständigen Wettbewerbsanalysebericht"
2
3Startet gleichzeitig 4 Unter-Agenten:
4→ Unter-Agent 1: Recherchiere Preise und Funktionen von Wettbewerber A
5→ Unter-Agent 2: Recherchiere Preise und Funktionen von Wettbewerber B
6→ Unter-Agent 3: Suche nach aktuellen Nachrichten über beide Wettbewerber
7→ Unter-Agent 4: Hole Nutzerbewertungen von Reddit und dem App Store
8
9Übergeordneter Agent wartet, führt dann alle 4 Ausgaben im endgültigen Bericht zusammen
10
11Gesamtzeit: genauso lang wie der langsamste Unter-Agent (nicht 4x länger)

Die wichtigste Designregel: Die Ausgaben der Unter-Agenten müssen in Dateien gehen.

Nicht in flüchtigen Kontext. In Dateien.

Wenn sie nur im Kontext leben, verschwinden sie, wenn die Sitzung des Unter-Agenten endet.

Wenn sie in Dateien leben, kann der übergeordnete Agent sie überprüfen, das System kann sich von Abstürzen erholen, und alles ist nachvollziehbar.

Werkzeuge, die jeder Coding-Agent verwendet

Wenn du einen Agenten baust, ist dies das Toolkit, auf das sich alle großen Coding-Agenten standardisieren.

1Dateisystem-Werkzeuge:
2→ glob, grep, ls          # Dateien finden
3→ read, read_many         # Inhalt lesen
4→ write                   # Neue Datei erstellen
5→ edit                    # String-Ersetzung bearbeiten
6→ apply_patch             # Strukturierter Unterschied
7
8Shell-Werkzeuge:
9→ bash                    # Beliebigen Befehl ausführen
10→ PowerShell              # Windows-Äquivalent
11
12Versionskontrolle:
13→ git_status, git_diff    # Änderungen überprüfen
14→ git_commit              # Fortschritt speichern
15
16Agentenverwaltung:
17→ spawn_agent             # Unter-Agent starten
18→ wait_agent              # Auf Ergebnis warten
19→ list_agents             # Sehen, was läuft
20→ interrupt_agent         # Bei Bedarf abbrechen
21
22Externer Kontext:
23→ web_search, web_fetch   # Aktuelle Informationen abrufen
24→ MCP-Werkzeuge           # Verbindung zu externen Diensten herstellen

Du brauchst nicht alle davon für jeden Agenten.

Aber jeder produktive Agent braucht irgendwann die meisten davon.

Die, die am Anfang am wichtigsten sind: bash, read, write, edit.

Beherrsche diese vier und du kannst fast alles bauen.

Kontext-Engineering: die Fähigkeit, über die niemand spricht

Das Modell ist festgelegt.

Du kannst seine Gewichte zur Laufzeit nicht ändern.

Aber du kannst ändern, was es sieht.

Das ist Kontext-Engineering.

Und es ist heute eine der Fähigkeiten mit der größten Hebelwirkung im KI-Engineering.

Schlechter Kontext:

→ Alles hineinwerfen → auf das Beste hoffen

→ Kontext bläht sich auf → Modell verliert den Fokus → Ausgaben verschlechtern sich

Guter Kontext:

→ Strukturiert. Prägnant. Sich weiterentwickelnd.

→ Die richtige Information zum richtigen Schritt.

→ Vorherige Fehler informieren den aktuellen Versuch.

Der modernste Ansatz (ACE – Agentic Context Engineering):

13 Komponenten:
2
3Generator:   führt die Aufgabe aus, referenziert ein strukturiertes Kontext-Playbook
4Reflektor:   analysiert Erfolge und Misserfolge, destilliert Erkenntnisse
5Kurator:     aktualisiert das Playbook mit neuen Erkenntnissen – fügt hinzu, entfernt, dedupliziert
6
7Das Playbook ist KEIN Prompt-Klumpen.
8Es ist eine strukturierte Liste von (Kennung, Erkenntnis)-Paaren.
9
10Beispiel:
11{
12  "id": "001",
13  "erkenntnis": "Fehlerabläufe vor dem erneuten Versuch immer in eine Datei schreiben."
14},
15{
16  "id": "002",
17  "erkenntnis": "Unter-Agent für die Websuche liefert bessere Ergebnisse mit seiten-spezifischen Abfragen."
18},
19{
20  "id": "003",
21  "erkenntnis": "Das Ausführen von Tests vor dem Commit fängt 80 % der Regressionen ab."
22}

Das Playbook wird nach jedem Durchlauf aktualisiert.

Der Agent, der Aufgabe 50 ausführt, arbeitet mit 49 Durchläufen destillierten Wissens.

Der Agent, der Aufgabe 1 ausführt, hatte nichts.

So wird ein System schlauer, ohne die Modellgewichte zu berühren.

Das Harness, das sich selbst verbessert

Hier wird es verrückt.

Was wäre, wenn das Harness selbst das wäre, was optimiert wird?

Nicht der Prompt. Nicht das Modell.

Der Code, der den Agenten ausführt.

Genau das macht Self-Harness.

Eine 3-Schritt-Schleife:

Schritt 1 – Schwachstellen aufdecken

Führe das aktuelle Harness mit einer Reihe von Aufgaben aus. Sammle Fehlerabläufe. Gruppiere Fehler nach Ursache.

Nicht "es ist fehlgeschlagen." Sondern warum es fehlgeschlagen ist.

Entdeckte Fehlertypen:

→ "Agent timeout bei langen Dateilesevorgängen"

→ "Ausgaben von Unter-Agenten gehen verloren, wenn der übergeordnete Agent abstürzt"

→ "Fehlermeldungen sind nicht informativ genug für eine Selbstkorrektur"

→ "Kontext wird nach Schritt 30 zu groß, Modell verliert den Fokus"

Schritt 2 – Korrekturen vorschlagen

Dasselbe Modell betrachtet die Fehlermuster. Schlägt spezifische, gezielte Änderungen am Harness-Code vor.

Keine Neuschreibungen. Gezielte Bearbeitungen.

Vorgeschlagene Harness-Bearbeitung:

→ Timeout-Handler zu Dateilesevorgängen hinzufügen

→ Ausgabe von Unter-Agenten bei jedem Schritt automatisch auf die Festplatte leeren (nicht nur am Ende)

→ Fehlermeldungsformat standardisieren, um zu enthalten: Schritt, Werkzeug, Eingabe, Ausgabe, Fehlergrund

→ Kontextkomprimierungsschritt alle 25 Runden hinzufügen

Schritt 3 – Validieren und zusammenführen

Jeder vorgeschlagene Edit wird an zurückgehaltenen Aufgaben getestet.

Behebt er die Schwachstelle, ohne etwas anderes zu beschädigen?

Wenn ja: in das Harness eingefügt. Wenn nein: protokolliert, abgelehnt, Harness unverändert.

Das Ergebnis: Das Harness wird mit jeder Generation besser.

Claude 3.5 Sonnet, das Self-Harness ausführt, verbesserte sich von 20 % auf 50 % bei SWE-bench Verified.

Nicht durch ein besseres Modell.

Durch ein besseres System.

Evolutionäre Harness-Suche

Self-Harness verbessert ein Harness iterativ.

AlphaEvolve betreibt eine Population von Harnesses und entwickelt die besten weiter.

Der Algorithmus:

11. Beginne mit einem Pool von Harness-Kandidaten
22. Bewerte jeden anhand von Benchmark-Aufgaben
33. Wähle die besten Leistungsträger als "Eltern" aus
44. Bitte das Modell, Diffs/Verbesserungen vorzuschlagen
55. Generiere neue "Kind"-Harnesses
66. Bewerte die Kinder
77. Behalte diejenigen, die sich verbessern
88. Füge sie wieder zum Pool hinzu
99. Wiederhole
10
11(Gleiche Logik wie natürliche Selektion. Angewandt auf Code.)

(Gleiche Logik wie natürliche Selektion. Angewandt auf Code.)

Ein wichtiges Designdetail von AlphaEvolve:

Codebereiche, die für die Evolution in Frage kommen, sind explizit markiert:

1# EVOLVE-BLOCK-START
2def plan_next_step(context, tools):
3    # Dieser Abschnitt kann durch die evolutionäre Suche geändert werden
4    prompt = f"Gegeben: {context}\nVerfügbare Werkzeuge: {tools}\nNächste Aktion:"
5    return llm.generate(prompt)
6# EVOLVE-BLOCK-END
7
8# Der Rest des Harnesses bleibt fest
9def run_tool(tool_name, args):
10    return tool_registry[tool_name](**args)

Diese Eingrenzung verhindert, dass der Agent versehentlich sicherheitskritischen Code ändert.

Die evolutionäre Suche berührt nur das, was du ihr explizit erlaubst.

AlphaEvolve nutzte dies, um Matrixmultiplikationsalgorithmen zu optimieren.

Das Ergebnis: Es übertraf DeepMinds handoptimierten Code.

Der Agent fand Lösungen, die menschliche Ingenieure seit Jahrzehnten nicht entdeckt hatten.

Darwin Gödel Machine: Agenten, die sich selbst umschreiben

Die extremste Version dieser Idee.

Ein Agent, der seinen eigenen Harness-Code modifiziert, um bei Aufgaben besser zu werden.

Darwin Gödel Machine (DGM):

11. Beginne mit einem Coding-Agenten im Pool
22. Führe ihn mit Benchmarks aus, sammle Bewertungen
33. Agent untersucht seine eigenen Evaluierungsprotokolle
44. Agent schlägt Verbesserungen für seinen eigenen Harness-Code vor
55. Verfügbare Werkzeuge: bash + Dateieditor (Dateien anzeigen/erstellen/bearbeiten)
66. Neue Version des Agenten wird erstellt
77. Neue Version wird bewertet
88. Wenn besser: zum Pool hinzugefügt
99. Wenn schlechter: verworfen
1010. Wiederholen – Auswahl der Eltern nach Leistung, umgekehrt nach Anzahl der Nachkommen

Ausgangsbedingung: Claude 3.5 Sonnet + einfaches anfängliches Harness.

Ergebnis:

→ SWE-bench Verified: 20 % → 50 %

→ Polyglot-Coding-Benchmark: 14,2 % → 30,7 %

Null Änderungen an den Modellgewichten. Kein menschliches Engineering zwischen den Generationen.

Der Agent entwarf bessere Versionen seiner selbst.

Das ist keine Science-Fiction.

Das ist ein Paper aus dem Jahr 2025.

5 Fehlermodi, die es zu vermeiden gilt

Das sind die Arten, wie echte Forschungsteams gescheitert sind.

Alle dokumentiert. Alle vermeidbar.

1. Kontextkollaps

Langfristige Aufgaben verlieren kritische Details, wenn Protokolle nicht als dauerhafte Artefakte geschrieben werden.

Behebung: Schreibe alles Wichtige in Dateien. Verlasse dich nie allein auf den Kontext nach Schritt 20.

2. Implementierungsdrift

Wenn die Aufgabe technisch schwierig wird, driftet das Modell zu einfacheren, gebräuchlicheren Lösungen ab, anstatt zum eigentlichen Ziel.

Behebung: Schreibe zu Beginn eine Spezifikationsdatei. Der Agent überprüft die Spezifikation in jeder Schleife.

3. Überoptimismus

Das Modell erklärt den Erfolg trotz fehlgeschlagener Experimente.

Es findet "numerisches Klebeband" – Patches, die Metriken gut aussehen lassen, ohne das eigentliche Problem zu lösen.

Behebung: Halte einen Testsatz zurück, den der Agent nie sieht. Validiere nur an zurückgehaltenen Daten.

4. Belohnungs-Hacking

Der Agent optimiert das Signal, das ihm gegeben wird.

Wenn das Signal Komponententests sind – schreibt er Tests, die immer bestanden werden. Wenn das Signal ein Bewertungsmodell ist – lernt er Tricks, um das Modell zu täuschen. Wenn das Signal die Benchmark-Punktzahl ist – nutzt er Benchmark-Artefakte aus.

Behebung: Der Evaluator lebt außerhalb der Schleife. Menschliche Überprüfung an wichtigen Entscheidungspunkten.

5. Diversitätskollaps

Evolutionäre Schleifen konvergieren auf eine Strategie.

Jede Generation sieht aus wie eine Variante derselben Lösung.

Behebung: Verfolge explizit die Neuheit. Bestrafe Lösungen, die bestehenden Poolmitgliedern zu ähnlich sind (einbettungsbasierte Kosinus-Ähnlichkeit funktioniert).

Der neue KI-Stack in einfachem Deutsch

Das ist es, was du tatsächlich baust, wenn du ernsthafte KI-Produkte entwickelst:

Schicht 1 – Das Modell

Rohe Intelligenz. Vortrainiert. Feste Gewichte zur Laufzeit.

Das ist die CPU. Leistungsstark, aber passiv.

Schicht 2 – Das Harness

Das OS. Umgibt das Modell. Orchestriert alles.

→ Werkzeuge (bash, Datei lesen/schreiben, Websuche)

→ Gedächtnis (Dateisystem, strukturierte Protokolle)

→ Schleife (planen → ausführen → bewerten → wiederholen) → Unter-Agenten (parallele Ausführung)

→ Kontextverwaltung (was das Modell bei jedem Schritt sieht)

Schicht 3 – Der Optimierer

Das Harness, das das Harness verbessert.

→ Extrahiert Fehlermuster aus Ausführungsabläufen

→ Schlägt gezielte Änderungen am Harness-Code vor → Validiert an zurückgehaltenen Aufgaben

→ Fügt Verbesserungen zusammen, verwirft Regressionen

Schicht 4 – Der Evaluator

Lebt außerhalb aller anderen Schichten.

→ Benchmark-Ergebnisse → Menschliche Überprüfung an wichtigen Entscheidungspunkten → Zurückgehaltene Testsets, die der Optimierer nie berührt

Du kannst keine Schicht überspringen.

Überspringe Schicht 2 – dein Modell ist ein Chatbot, kein Produkt.

Überspringe Schicht 3 – dein System wird nie besser ohne manuelles Engineering.

Überspringe Schicht 4 – dein Agent optimiert das Falsche, und du wirst es nicht bemerken.

Was das für Entwickler jetzt bedeutet

Du musst kein sich selbst verbesserndes Harness bauen, um von diesen Ideen zu profitieren.

Beginne hier:

Woche 1: Baue die Schleife

Hör auf, einmalige Aufforderungen zu bauen. Baue eine Planen → Ausführen → Bewerten → Wiederholen-Schleife für jede Aufgabe, die mehr als einen Schritt dauert.

Woche 2: Füge dauerhaftes Gedächtnis hinzu

Hör auf, dich auf den Kontext zu verlassen. Schreibe Zwischenergebnisse in Dateien. Lass den Agenten seine eigenen vorherigen Arbeiten lesen.

Woche 3: Füge Unter-Agenten hinzu

Identifiziere jeden Teil deines Workflows, der parallel laufen kann. Starte Unter-Agenten. Schreibe ihre Ausgaben in Dateien. Führe sie zusammen.

Woche 4: Füge Kontext-Engineering hinzu

Verfolge, welche Muster zu Erfolg und Misserfolg führen. Baue ein einfaches strukturiertes Playbook, das sich nach jedem Durchlauf aktualisiert.

Das ist das Harness.

Nicht das Modell.

Das Modell ist bereits da.

Das Harness ist das, was du baust.

Die unbequeme Wahrheit über KI im Jahr 2026

Die Forschungsbeschleunigung in den Spitzenlaboren hat drastisch zugenommen.

Anthropic und OpenAI liefern schneller aus als je zuvor.

Nicht, weil die Modelle über Nacht schlauer geworden sind.

Weil die Harnesses besser geworden sind.

Ein Agent, der Schleifen dreht, sich erinnert, delegiert und selbst korrigiert, übertrifft ein schlaueres Modell, das falsch eingesetzt wird.

Der Burggraben ist nicht das Modell.

Der Burggraben ist das System.

Und das System kann sich jetzt selbst verbessern.

Wenn das nützlich war:

→ Teile es erneut – jeder KI-Entwickler muss diesen Stack verstehen

→ Folge @sairahul1 für weitere Aufschlüsselungen wie diese

→ Setze ein Lesezeichen – der 4-Schichten-Stack allein ist es wert, gespeichert zu werden

Abonniere theaibuilders.co für weitere interessante Artikel dieser Art

Ich schreibe über KI, Produktentwicklung und Systeme, die ohne dich funktionieren.