Anthropics Agent-Harness-Design hat mein Denken ueber KI-Systeme veraendert

Ich hatte vier Stunden lang einer KI dabei zugesehen, wie sie eine digitale Audio-Workstation baute. Keine Spielerei-Demo -- eine browserbasierte DAW mit der Web Audio API, Multitrack-Editing und einem Waveform-Visualizer. Der Agent lief die ganze Zeit autonom. Kein Haendchenhalten. Keine Korrekturen zwischendurch. Einfach eine KI, die sich Feature fuer Feature durcharbeitete, Code committete, ihre eigene Arbeit testete und weitermachte.

Dann stoppte sie.

Nicht weil sie abgestuerzt war. Nicht weil der Kontext erschoepft war. Sie stoppte, weil eine separate KI -- der Evaluator -- feststellte, dass das Audio-Playback-Timing um 12 Millisekunden daneben lag und das Waveform-Rendering nicht mit den tatsaechlichen Frequenzdaten uebereinstimmte. Der Generator-Agent ging zurueck, behob beide Probleme und reichte erneut ein. Der Evaluator testete ein zweites Mal, bestaetigte die Fixes und gab den Sprint frei.

Diese Interaktion -- zwei KI-Agenten, die ueber Qualitaet diskutieren wie ein Entwickler und ein QA-Engineer -- ist der Kern dessen, was Anthropic in ihrem Harness-Design fuer langlebige Anwendungsentwicklung veroeffentlicht hat. Und es hat komplett umgekrempelt, wie ich ueber den Bau autonomer Systeme nachdenke.

Das Modell ist nicht das Produkt. Das Harness ist es.

Warum Ihr KI-Agent bei komplexen Aufgaben immer wieder scheitert

Hier ist ein Muster, das ich dutzende Male selbst erlebt habe. Man gibt einem KI-Agenten ein komplexes Projekt -- eine Full-Stack-App bauen, eine grosse Codebase refactoren, ein mehrseitiges Design-System erstellen. Der Agent startet stark. Die ersten 20 Minuten sehen vielversprechend aus. Dann, irgendwo um die 45-Minuten-Marke, laeuft es aus dem Ruder. Schritte werden uebersprungen. Die Qualitaet sinkt. Der Agent erklaert das Projekt fuer "fertig", obwohl es vielleicht zu 60 % erledigt ist.

Frueher gab ich dem Modell die Schuld. "Sonnet ist nicht schlau genug dafuer." "Ich brauche bessere Prompts." "Das Context Window ist zu klein."

Anthropics Forschung hat diese Diagnose komplett auf den Kopf gestellt. Das Modell war selten der Engpass. Das Harness war es.

Ein Agent-Harness ist das Software-Framework, das ein KI-Modell umhuellt -- es verwaltet Prompts, orchestriert Tools, setzt Constraints durch, handhabt Feedback-Schleifen und validiert Ausgaben. Stellen Sie sich das so vor: Das KI-Modell ist ein Motor. Rohe Pferdstaerken. Das Harness ist das Auto. Lenkrad, Bremsen, Getriebe, GPS. Ohne das Auto steht der Motor einfach auf einer Werkbank und macht Laerm.

Diese Unterscheidung ist wichtiger, als den meisten KI-Engineers bewusst ist. Man kann einen V6 gegen einen V8 tauschen (Sonnet gegen Opus) und bekommt inkrementelle Verbesserungen. Aber wenn man das Auto neu designt -- aendert, wie der Motor mit den Raedern verbunden ist, ein Navigationssystem hinzufuegt, bessere Bremsen einbaut -- dann transformiert sich das gesamte Fahrerlebnis.

Genau das hat Anthropic demonstriert. Kein besseres Modell. Ein besseres System um das Modell herum. Und die Ergebnisse waren so dramatisch, dass ich innerhalb einer Woche nach der Lektuere ihres Papers meine eigenen Agent-Workflows neu aufgebaut habe.

Aber bevor ich darauf eingehe, was sie gebaut haben, muessen Sie verstehen, was ueberhaupt immer wieder schieflaeuft -- denn diese Fehlermodi verstecken sich in jedem langlebigen Agent-System, das ich gesehen habe, einschliesslich derer, die ich selbst gebaut habe.

Die zwei Fehlermodi, ueber die niemand ehrlich spricht

Anthropic identifizierte zwei kritische Fehlermodi bei langlebigen Agenten. Ich habe beide so oft erlebt, dass sich das Lesen ihrer Analyse anfuehlte, als haette jemand Kameras in meiner Entwicklungsumgebung installiert.

Context Anxiety: Wenn Ihr Agent in Panik geraet

Context Anxiety ist das, was passiert, wenn ein KI-Modell spuert, dass es sich den Grenzen seines Context Windows naehert. Das Verhalten ist subtil und tueckisch. Der Agent stuerzt nicht ab. Er wirft keinen Fehler. Stattdessen faengt er an zu hetzen. Schritte werden komprimiert. Erklaerungen werden knapp. Komplexe Teilaufgaben, die sorgfaeltige Planung erfordern wuerden, werden weggewunken. Der Agent beginnt vorzeitig abzuschliessen -- er erklaert den Sieg ueber ein halbfertiges Projekt, weil irgendein internes Signal schreit: "Dir geht der Platz aus."

Ich habe das zum ersten Mal bei Sonnet 4.5 waehrend eines Refactoring-Projekts bemerkt. Etwa bei der 80K-Token-Marke wechselte der Agent von sorgfaeltiger, methodischer Arbeit zu etwas, das ich nur als aengstliches Speed-Running beschreiben kann. Er hoerte auf, Dateien zu lesen, bevor er sie bearbeitete. Er uebersprang Test-Laeufe. Er begann, Kommentare auszugeben wie "die verbleibenden Punkte sind unkompliziert und folgen dem gleichen Muster" -- was in Agent-Sprache heisst: "Ich gebe auf und hoffe, dass es niemandem auffaellt."

Anthropics Loesung umfasst zwei komplementaere Techniken.

Context Compaction fasst die Konversationshistorie zusammen und verdichtet sie, wobei die wesentlichen Informationen erhalten bleiben und Token-Platz freigegeben wird. Die KI schreibt sich im Grunde selbst ein komprimiertes Briefing ueber alles, was bisher passiert ist, und arbeitet dann von diesem Briefing aus statt von der rohen Historie. Es ist verlustbehaftet -- einige Details gehen verloren -- aber eine gute Compaction-Strategie bewahrt die kritischen Entscheidungen und den aktuellen Zustand.

Context Resets gehen weiter. Anstatt den bestehenden Kontext zu komprimieren, gibt man dem Agenten ein komplett frisches Context Window fuer jeden Sprint oder jede Teilaufgabe. Der Agent startet sauber, nur mit den Informationen, die er fuer das aktuelle Arbeitsstueck benoetigt. Fortschritt lebt nicht im Gedaechtnis des Modells -- er lebt in Dateien, Git-Commits und strukturierten Artefakten auf der Festplatte.

Hier ist der Durchbruch, der fuer Entwickler zaehlt: Opus 4.6 mit seinem 1-Million-Token-Context-Window hat Context Anxiety als praktisches Problem weitgehend eliminiert. Das Fenster ist so enorm, dass die meisten mehrstuendigen autonomen Sitzungen nicht einmal annaehernd an die Grenze kommen. Anthropic stellte fest, dass sie Context Resets bei Opus 4.6 komplett weglassen und sich allein auf Compaction verlassen konnten. Was frueher ein komplexes Multi-Session-Handoff-System erforderte, laeuft jetzt als eine einzige durchgehende Sitzung.

Das heisst nicht, dass Context Management fuer immer geloest ist. Fordert man Opus 4.6 hart genug -- eine ganztaegige autonome Sitzung mit umfangreichem Dateilesen -- wird man an Grenzen stossen. Aber die Schwelle hat sich verschoben von "ein ernstes Problem nach 45 Minuten" zu "ein Randfall nach 6+ Stunden." Fuer die meisten realen Aufgaben ist das der Unterschied zwischen "Harness-Workaround noetig" und "kein Workaround noetig."

Self-Evaluation-Fehler: Der Agent, der alles toll findet, was er produziert

Der zweite Fehlermodus ist gefaehrlicher, weil er schwerer zu erkennen ist.

Wenn man einen KI-Agenten bittet, seine eigene Arbeit zu bewerten, luegt er. Nicht absichtlich -- aber konsistent. Das Muster ist vorhersehbar: Der Agent generiert Output, ueberpreuft ihn und kommt zu dem Schluss, dass der Output gut ist. Selbst wenn die Qualitaet fuer einen menschlichen Beobachter offensichtlich mittelmaessig ist.

Ich habe das in Echtzeit beobachtet. Ein Agent baut eine Landing Page mit falsch ausgerichteten Elementen, inkonsistenten Abstaenden und einem Farbschema, das aussieht, als waere es per Zufallsgenerator gewaehlt worden. Man bittet den Agenten, das Ergebnis zu bewerten. "Das Design ist sauber und professionell, mit guter visueller Hierarchie und konsistenten Abstaenden." Er beschreibt das Design, das er beabsichtigt hat zu bauen, nicht das, das er tatsaechlich gebaut hat.

Das ist kein Prompting-Problem. Man kann "sei kritisch" und "suche nach Fehlern" zum System-Prompt hinzufuegen, und der Agent wird nicken, so tun als waere er kritisch, und dann seine eigene Arbeit mit ein paar alibimaessigen Einschraenkungen genehmigen. "Obwohl es Verbesserungspotenzial bei der Farbpalette gibt, kommuniziert das Gesamtdesign die Markenbotschaft effektiv." Uebersetzung: "Ich tue so, als waere ich kritisch, aendere aber nichts."

Anthropics Diagnose ist unverbleumt und, nach meiner Erfahrung, zutreffend: Einen Generator selbstkritisch zu machen, ist ein fundamental schwierigeres Problem als einen separaten, dedizierten Kritiker zu bauen. Die architektonische Loesung besteht nicht darin, den Generator besser in der Selbstbewertung zu machen. Sie besteht darin, die Rollen vollstaendig zu trennen.

Was uns zur Architektur bringt, die tatsaechlich funktioniert.

Die Drei-Agenten-Architektur: Planner, Generator, Evaluator

Anthropics finales Harness-Design verwendet drei spezialisierte Agenten, die zusammenarbeiten. Wenn Sie jemals in einem Team mit einem Product Manager, einem Entwickler und einem QA-Engineer gearbeitet haben -- wird Ihnen das vertraut vorkommen. Denn genau diese Dynamik haben sie repliziert.

Der Planner

Der Planner nimmt einen einfachen Prompt -- "baue eine Projektmanagement-App mit einem Kanban-Board" -- und erweitert ihn zu einer detaillierten Produktspezifikation. Feature-Listen. User Stories. Technische Anforderungen. Visuelle Designrichtung.

Der Planner ist bewusst ambitioniert. Anthropic stellte fest, dass konservative Planung zu enttaeuschenden Ergebnissen fuehrte. Wenn der Planner hoch zielte, produzierte der Generator kreativere, vollstaendigere Anwendungen -- selbst wenn nicht jedes Ziel erreicht wurde. Eine Spezifikation, die ein "wunderschoenes, museumsreifes Interface mit 3D-Elementen" verlangt, liefert bessere Ergebnisse als eine, die ein "sauberes, funktionales UI" verlangt. Die hohe Messlatte zieht den Output nach oben.

Eine Sache, die Anthropic auf die harte Tour lernte: Der Planner sollte sich auf was und warum konzentrieren, nicht auf wie. Wenn der Planner granulare technische Implementierungsdetails einschloss, kaskedierten diese Details Fehler durch die Arbeit des Generators. Ein Planner, der sagt "implementiere Echtzeit-Kollaboration", ist besser als einer, der sagt "verwende WebSockets mit einem Pub/Sub-Pattern auf Redis" -- weil der Generator moeglicherweise einen besseren Ansatz findet, den die voreilige Spezifizitaet des Planners verhindert haette.

Der Generator

Der Generator arbeitet in Sprints und implementiert jeweils ein Feature. Jeder Sprint hat einen klaren Scope, der aus der Spezifikation des Planners abgeleitet ist, und der Generator committet Code inkrementell -- das heisst, Fortschritt wird in Git gesichert, unabhaengig davon, was mit dem Kontext des Agenten passiert.

Dieser Sprint-basierte Ansatz ist die staerkste Parallele zu meiner bisherigen Nutzung von Claude Code. Wenn ich mit Claude Codes Agent-Swarm-Architektur arbeite, gilt das gleiche Prinzip: Komplexe Arbeit in diskrete Stuecke aufteilen, Fortschritt durch Artefakte sichtbar machen (Dateien, Commits, Task-Graphen) und sich nie auf das Gedaechtnis des Modells als Quelle der Wahrheit verlassen.

Der Generator enthaelt auch einen eingebauten Self-Evaluation-Schritt, bevor er an den Evaluator uebergibt -- eine schnelle Plausibilitaetspruefung. Diese faengt die offensichtlichen Probleme ab (Syntaxfehler, fehlende Imports, kaputte Builds), ohne sich beim Evaluator auf Dinge zu verlassen, die der Generator selbst erkennen sollte. Stellen Sie sich das vor wie einen Entwickler, der seine eigenen Tests ausfuehrt, bevor er einen PR oeffnet. Man braucht trotzdem Code Review, aber man sollte nicht die Zeit des Reviewers mit Problemen verschwenden, die der Linter gefunden haette.

Der Evaluator: Wo die eigentliche Innovation steckt

Der Evaluator ist das, was diese Architektur wirklich anders macht als alles, was ich zuvor gebaut habe.

Die meisten KI-Evaluierungssysteme pruefen Code statisch -- sie lesen die Quelldateien, analysieren die Struktur und geben Feedback. Anthropics Evaluator liest nicht nur Code. Er benutzt die Anwendung. Ueber Playwright-Browserautomatisierung navigiert der Evaluator durch die laufende Anwendung, klickt Buttons, fuellt Formulare aus, macht Screenshots, testet API-Endpoints und prueft Datenbankzustaende. Er interagiert mit dem Live-Produkt so, wie es ein menschlicher QA-Engineer tun wuerde.

Die Bewertungskriterien sind auch nicht vage. Anthropic definierte vier spezifische Dimensionen:

Design-Qualitaet -- Entspricht der visuelle Output professionellen Standards? Layout, Typografie, Farbe, Abstaende -- gemessen an der Spezifikation des Planners, nicht an abstrakten Idealen.

Originalitaet -- Sieht der Output nach generischem KI-Einheitsbrei aus, oder hat er eine echte kreative Identitaet? Dieses Kriterium existiert speziell, um das Problem "alles, was KI baut, sieht gleich aus" zu bekaempfen. Als ich das las, dachte ich sofort an den Leitfaden fuer KI-Design-Systeme, den ich geschrieben habe -- das Problem, dass KI-generierte Interfaces alle auf die gleiche Aesthetik konvergieren, ist real, und Anthropic bewertet explizit dagegen.

Handwerk -- Technische Ausfuehrungsqualitaet. Sauberer Code, ordentliche Fehlerbehandlung, responsive Layouts, Performance. Die Dinge, die ein Senior Engineer beim Code Review bemerken wuerde.

Funktionalitaet -- Funktioniert das Feature tatsaechlich? Nicht "sieht der Code korrekt aus" -- tut der Button das, was er tun soll, wenn man ihn klickt?

Der Evaluator bewertet jeden Sprint anhand dieser Kriterien. Wenn die Noten den Schwellenwert nicht erreichen, geht der Generator zurueck und iteriert. Das erzeugt eine Feedback-Schleife, die strukturell identisch ist mit der Funktionsweise von GANs (Generative Adversarial Networks) -- ein Generator, der versucht, Output zu produzieren, der den Diskriminator taeuscht, und ein Diskriminator, der immer besser darin wird, Maengel zu erkennen.

Was mich ueberrascht hat: Den Evaluator richtig hinzubekommen, erforderte mehrere Iterationen. Anthropics erste Claude-basierte Evaluatoren hatten das gleiche Problem wie die Selbstbewertung -- sie waren zu nachsichtig. Sie genehmigten mittelmaessige Arbeit mit ermutigendem Feedback. Es bedurfte gezielten Prompt Engineerings, um den Evaluator wirklich adversarial zu machen. Ein skeptischer System-Prompt. Explizite Anweisungen, nach bestimmten Fehlertypen zu suchen. Die Erlaubnis, Arbeit abzulehnen und Ueberarbeitungen zu fordern.

Das ist die zentrale Erkenntnis, auf die ich immer wieder zurueckkomme: Einen dedizierten Evaluator auf Skepsis zu trimmen, ist ein fundamental besser loesbares Problem als einen Generator selbstkritisch zu machen. Der Evaluator hat eine einzige Aufgabe -- Probleme finden. Der Generator hat einen gegenlaeufigen Anreiz -- er will fertig sein. Diese Rollen zu trennen, ist nicht nur gute Architektur. Es ist notwendig.

Der Sprint-Vertrag: Generator und Evaluator vor Arbeitsbeginn auf eine Linie bringen

Ein Detail aus Anthropics Design, das ich anderswo noch nicht ausreichend diskutiert gesehen habe, ist der Sprint-Vertrag.

Bevor jeder Sprint beginnt, verhandeln Generator und Evaluator einen Vertrag. Der Generator schlaegt vor, was er liefern wird. Der Evaluator bestaetigt, dass er die Abnahmekriterien versteht. Beide Agenten einigen sich darauf, was "fertig" bedeutet, bevor eine einzige Zeile Code geschrieben wird.

Das klingt buerokratisch. Ist es nicht. Es ist der Unterschied zwischen einem PR, der beim ersten Review genehmigt wird, und einem, der fuenfmal hin und her geht, weil Entwickler und Reviewer unterschiedliche Erwartungen hatten.

Ohne den Vertrag habe ich beobachtet, wie Evaluator-Agenten Arbeit ablehnten, weil sie Standards nicht erfuellte, die nie kommuniziert worden waren. Der Generator baut ein Feature auf eine Weise, der Evaluator wollte es anders, und die Iterationsschleife verbrennt Tokens mit Diskussionen ueber Anforderungen, die im Voraus haetten geklaert werden sollen.

Der Vertrag loest das, indem er Erwartungen explizit macht. "Sprint 3 implementiert den Level-Editor mit Drag-and-Drop-Sprite-Platzierung, einer Tile-Palette mit mindestens 20 Elementen und Undo/Redo-Unterstuetzung. Der Evaluator verifiziert die Funktionalitaet, indem er ein Testlevel erstellt, Sprites platziert und bestaetigt, dass Undo fuer mindestens 5 aufeinanderfolgende Operationen funktioniert."

Diese Spezifitaet -- die genaue Benennung von Abnahmetests -- eliminiert eine ganze Klasse verschwendeter Iterationen. Und es ist ein Muster, das ich fuer meine eigenen Agent-Workflows uebernommen habe, auch ausserhalb von Anthropics Harness-Design.

Was die Experimente tatsaechlich gezeigt haben

Theorie ist eine Sache. Anthropic fuehrte drei Experimente durch, die diese Architektur unter realen Druck setzten. Die Ergebnisse erzaehlen unterschiedliche Geschichten, je nachdem, welches man betrachtet.

Experiment 1: Die Website fuer ein niederlaendisches Kunstmuseum

Die Aufgabe: Eine Website fuer ein fiktives niederlaendisches Kunstmuseum designen. Das ist eine subjektive, design-lastige Herausforderung, bei der "gut" schwer zu definieren und noch schwerer zu evaluieren ist.

Das Harness durchlief mehr als 10 Feedback-Iterationen zwischen Generator und Evaluator. Fruehe Versionen waren generisch -- die Art von Template-artigen Seiten, die jede KI produziert. Ab Iteration 7 oder 8 hatte sich das Design zu etwas wirklich Ungewoehnlichem entwickelt: eine 3D-Raumvisualisierung mit einem Schachbrettboden, Kunstwerke an virtuellen Waenden und eine Navigation, die sich anfuehlte, als wuerde man durch eine Galerie laufen.

Der Punkt ist nicht, dass das finale Design perfekt war. Es ist, dass die iterative adversariale Schleife den Output ueber das "gut genug"-Plateau hinausgeschoben hat, das Single-Pass-KI-Generierung immer erreicht. Der Generator suchte immer weiter nach kreativeren Loesungen, weil der Evaluator die sicheren Varianten immer wieder ablehnte. Diese Dynamik -- Druck, Standards zu uebertreffen, nicht nur zu erfuellen -- entsteht nicht, wenn ein Agent sich selbst bewertet.

Experiment 2: Der 2D-Retro-Game-Maker

Dies war das aufschlussreichste Experiment. Zwei Durchlaeufe derselben Aufgabe: Baue einen 2D-Retro-Game-Maker mit Level-Editor, Sprite-Editor und Verhaltenssystem.

Durchlauf 1 (Solo-Harness -- nur Generator): Der Output sah in Screenshots visuell akzeptabel aus. Aber wenn man tatsaechlich versuchte, ihn zu benutzen, funktionierte das Spiel nicht. Sprites bewegten sich nicht. Der Level-Editor konnte keine Levels speichern. Es war ein Potemkinsches Dorf eines Game Makers -- von aussen vorzeigbar, innen hohl.

Durchlauf 2 (Voll-Harness -- Planner + Generator + Evaluator): Der Planner erstellte detaillierte Spezifikationen mit expliziten "Definition of Done" fuer jeden Sprint. Der Evaluator testete jedes Feature interaktiv mit Playwright und fand funktionale Fehler, die der Generator als "fertig" deklariert haette. Das Ergebnis: ein funktionierender Game Maker. Keine AAA-Qualitaet, aber funktional. Man konnte Sprites erstellen, Levels bauen, Verhaltensweisen zuweisen und das Ergebnis tatsaechlich spielen.

Das Delta zwischen diesen beiden Durchlaeufen ist das gesamte Argument fuer Harness Engineering in einem einzigen Beispiel. Gleiches Modell. Gleiche Aufgabe. Gleiches Compute-Budget. Der einzige Unterschied war das System, das um das Modell herum gebaut war.

Experiment 3: Die Browser-DAW

Der ambitionierteste Test: Eine digitale Audio-Workstation im Browser bauen, mit der Web Audio API, ausgefuehrt auf Opus 4.6.

Dieses Experiment wurde in etwa 4 Stunden abgeschlossen, bei Kosten von rund 125 Dollar an API-Aufrufen. Das Ergebnis war funktional -- Multitrack-Audio, Waveform-Visualisierung, grundlegendes Editing -- aber nicht auf professionellem Niveau. Wichtiger noch: Dieses Experiment demonstrierte, wie Modellverbesserungen die Harness-Anforderungen vereinfachen.

Mit Opus 4.6s Millionen-Token-Context-Window liess Anthropic Sprints komplett fallen. Keine Context Resets. Keine Vertragsverhandlung zwischen Generator und Evaluator. Nur eine durchgehende Sitzung mit automatischer Compaction fuer das Context-Wachstum. Das Harness, das Sonnet 4.5 brauchte -- komplex, multi-session, sorgfaeltig Context-Grenzen verwaltend -- wurde ueberfluessig.

Das ist die wichtigste Erkenntnis fuer Entwickler: Ihre Harness-Annahmen muessen sich mit dem Modell weiterentwickeln. Ein Harness, das fuer die Limitierungen von Sonnet 4.5 designt wurde, wird die Orchestrierungsschicht ueberengineeren, wenn es auf Opus 4.6 laeuft. Und ein Harness, das fuer die Faehigkeiten von Opus 4.6 designt wurde, wird brechen, wenn das naechste Modell neue Verhaltensweisen einfuehrt oder alte eliminiert. Harness Engineering ist kein einmaliges Setup. Es ist eine kontinuierliche Praxis.

Wenn Sie lieber jemanden haetten, der ein solches Multi-Agent-Harness-System fuer Ihren Anwendungsfall baut, uebernehme ich individuelle KI-Agent-Entwicklungsauftraege. Was ich bisher gebaut habe, sehen Sie unter fiverr.com/s/EgxYmWD.

Wie das mit Mustern zusammenhaengt, die Sie bereits kennen

Anthropics Harness-Design existiert nicht im luftleeren Raum. Es steht neben zwei weiteren Mustern, die jeder ernsthafte Agent-Entwickler verstehen sollte -- denn sie loesen angrenzende Teile desselben Puzzles.

Der Ralph-Wiggum-Loop

Erstellt von Geoffrey Huntley und formalisiert von Boris Cherny (Anthropics Head of Claude Code) Ende 2025, ist der Ralph-Wiggum-Loop elegant in seiner Einfachheit. Man fuehrt einen Agenten in einer Bash-Schleife aus. Nach jeder Iteration prueft man den Output gegen etwas, das nicht luegen kann -- einen Linter, einen Type Checker, eine Test Suite. Wenn es durchkommt, stoppt man. Wenn nicht, laeuft die Schleife weiter.

Die zentrale Erkenntnis: Fortschritt lebt in Dateien und der Git-Historie, nicht im Context Window des Modells. Jede Iteration startet mit frischem Kontext. Der Agent liest den aktuellen Zustand der Codebase, arbeitet daran und committet Aenderungen. Wenn die Schleife weiterlaufen muss, liest die naechste Iteration die aktualisierten Dateien mit null angesammelter Kontextschuld.

Dieses Muster ist mittlerweile ein erstklassiges Plugin in Claude Code selbst. Man kann /ralph-loop "Fix all TypeScript errors" --max-iterations 20 --completion-promise "ALL_FIXED" ausfuehren und sich zuruecklehnen.

Wo sich der Ralph-Wiggum-Loop von Anthropics Drei-Agenten-Harness unterscheidet: Er funktioniert am besten fuer objektiv verifizierbare Aufgaben. "Alle Linting-Fehler beheben" hat eine binaere Grundwahrheit -- der Linter geht durch oder nicht. "Baue einen schoenen, funktionalen Game Maker" hat das nicht. Diese subjektive Luecke ist genau das, was der adversariale Evaluator fuellt.

Spec-Driven Development

Das dritte Puzzlestueck ist die Strukturierung von Anforderungen, bevor der Agent mit dem Coden beginnt. Frameworks wie GitHubs Spec Kit, BMAD-METHOD und OpenSpec loesen alle dasselbe Problem: Agenten, die mit dem Coden beginnen, bevor sie verstehen, was sie bauen.

Das bildet direkt den Planner-Agenten in Anthropics Design ab. Der Planner ist im Grunde ein automatisierter Spec-Schreiber. Aber man braucht keinen dedizierten Planner-Agenten, um den Nutzen zu erhalten. Eine klare Spezifikation zu schreiben -- Features, Abnahmekriterien, Definition of Done -- bevor man Arbeit an einen Agenten uebergibt, liefert dramatisch bessere Ergebnisse, als einen vagen Prompt auf ein Modell zu werfen und auf das Beste zu hoffen.

Der Spec-Driven-Ansatz erklaert auch, warum das Game-Maker-Experiment so unterschiedliche Ergebnisse zwischen Solo- und Voll-Harness-Durchlauf zeigte. Der Solo-Durchlauf hatte keine Spezifikation. Der Agent improvisierte, reduzierte seine Ambitionen mit jedem Schritt, bis "Game Maker" zu "einige UI-Elemente, die spielartig aussehen" wurde. Der Voll-Harness-Durchlauf hatte eine explizite Spezifikation mit Definitions of Done -- und einen Evaluator, der sie durchsetzte.

Ich verwende eine Version davon in meiner eigenen Arbeit, seit ich den Leitfaden zum Anthropic Agent SDK geschrieben habe. Jede komplexe Agent-Aufgabe beginnt jetzt mit einer geschriebenen Spezifikation. Nicht weil der Agent ohne eine nicht arbeiten kann -- sondern weil die Spezifikation der Anker ist, der Scope-Drift, vorzeitigen Abschluss und das langsame Sterben des Anspruchs verhindert, das jede langlebige KI-Sitzung befaellt.

Was das fuer den Bau Ihrer Agenten jetzt bedeutet

Hier moechte ich praktisch werden. Anthropics Forschung basiert auf dem Claude Agent SDK, aber die Prinzipien gelten unabhaengig davon, welches Modell oder Framework Sie verwenden. Wenn Sie irgendetwas bauen, das laenger als 15 Minuten autonom laeuft, wuerde ich Folgendes aus dieser Arbeit mitnehmen.

Generierung und Evaluation trennen. Immer.

Das ist die einzelne Aenderung mit dem groessten Hebel, die Sie an jedem Agent-Workflow vornehmen koennen. Wenn Ihr Agent Output generiert und diesen Output im selben Kontext evaluiert, haben Sie ein Zuverlaessigkeitsproblem. Es zeigt sich vielleicht nicht bei einfachen Aufgaben. Aber sobald die Komplexitaet steigt -- Multi-File-Aenderungen, subjektive Qualitaetsanforderungen, Feature-Abhaengigkeiten -- versagt die Selbstevaluation stillschweigend.

Sie brauchen kein ausgekluegeltes adversariales System, um anzufangen. Ein zweiter Agent mit einem skeptischen System-Prompt, der den Output des ersten Agenten prueft, reicht aus, um die krassesten Selbstgenehmigungs-Fehler abzufangen. Ich betreibe eine Version davon in meiner Content-Pipeline, und der Evaluator lehnt rund 30 % der Erstentwuerfe ab -- Entwuerfe, die ohne Pruefung mit strukturellen Problemen veroeffentlicht worden waeren, die ich bei manueller Kontrolle erkannt haette.

Artefakte statt Gedaechtnis als Quelle der Wahrheit verwenden

Jeder Fortschritt sollte ausserhalb des Context Windows des Modells existieren. Git-Commits. JSON-Task-Dateien. Markdown-Spezifikationen. Strukturierte Logs. Wenn die Sitzung Ihres Agenten abstuerzt und der einzige Beleg ueber das Geschehene in der Konversationshistorie lebt -- haben Sie ein fragiles System gebaut.

Das ist dasselbe Prinzip hinter Claude Codes persistenter Task-Graph-Architektur. Der Task-Graph lebt auf der Festplatte. Agenten lesen ihn, aktualisieren ihn und schreiben zurueck. Context Windows kommen und gehen. Der Task-Graph bleibt bestehen.

Harness-Komplexitaet an die Faehigkeiten des Modells anpassen

Anthropics eigene Entwicklung beweist diesen Punkt. Das Harness, das sie fuer Sonnet 4.5 gebaut haben -- mit Context Resets, Sprint-Grenzen, Vertragsverhandlung -- war notwendig, weil das Modell es brauchte. Das Harness fuer Opus 4.6 liess die Haelfte dieser Komponenten fallen, weil das Millionen-Token-Context und die verbesserte Konsistenz des Modells sie ueberfluessig machten.

Pruefen Sie Ihr eigenes Harness. Betreiben Sie komplexes Context Management, weil das Modell es tatsaechlich braucht, oder weil Sie das System vor sechs Monaten designt haben, als das Modell es noch brauchte? Die Orchestrierungsschicht zu ueberengineeren, verschwendet Tokens, fuegt Latenz hinzu und erzeugt Fehlerpunkte, die das aktuelle Modell einfach selbst handhaben koennte.

"Fertig" definieren, bevor Sie anfangen

Das Sprint-Vertrag-Muster -- bei dem Generator und Evaluator Abnahmekriterien vereinbaren, bevor die Arbeit beginnt -- gilt fuer jede Agent-Interaktion, nicht nur fuer Multi-Agent-Systeme. Wenn Sie einen Agenten auffordern, "ein Dashboard zu bauen", definieren Sie, was das Dashboard enthalten muss, wie Sie jedes Feature verifizieren und welche Qualitaetsmesslatte Sie erwarten. Je expliziter Ihre Definition von "fertig", desto weniger Raum hat der Agent, einen vorzeitigen Sieg zu erklaeren.

Die ehrlichen Grenzen: Was Harness-Design nicht loesen kann

Ich wuerde Ihnen einen schlechten Dienst erweisen, wenn ich Sie mit dem Eindruck gehen liesse, Harness Engineering sei ein Allheilmittel. Ist es nicht. Nachdem ich Wochen mit der Implementierung dieser Muster verbracht habe, hier die Waende, an die ich gestossen bin.

Kosten summieren sich schnell. Das Browser-DAW-Experiment kostete 125 Dollar an API-Aufrufen fuer rund 4 Stunden autonomer Arbeit. Ein Drei-Agenten-System verbraucht roughly 3x so viele Tokens wie ein Single-Agent-Ansatz, weil Sie drei Modelle (oder drei Sitzungen desselben Modells) koordiniert betreiben. Fuer Hobby-Projekte und Experimente ist das in Ordnung. Fuer Produktionssysteme, die 24/7 laufen, muessen die Wirtschaftlichkeit sorgfaeltig modelliert werden.

Die Evaluator-Qualitaet ist die Obergrenze. Ihr System kann nur so gut sein, wie Ihr Evaluator Probleme erkennen kann. Wenn der Evaluator eine subtile UI-Fehlausrichtung oder eine Race Condition in asynchronem Code nicht identifizieren kann, gehen diese Probleme in Produktion. Anthropic hat das eingeraeumt -- ihre ersten Evaluatoren ueberseahen subtile Bugs und genehmigten oberflaechliche Implementierungen. Den Evaluator richtig hinzubekommen, erforderte Iteration, nicht nur Prompt-Tweaking.

Subjektive Qualitaet bleibt schwierig. Das Experiment mit dem niederlaendischen Museum zeigte beeindruckende Verbesserung durch adversariale Iteration. Aber "beeindruckend fuer KI" und "beeindruckend im Vergleich zu einem menschlichen Designer mit 10 Jahren Erfahrung" sind unterschiedliche Massstaebe. Harness-Design verkleinert diese Luecke. Es schliesst sie nicht. Fuer subjektive kreative Arbeit -- Design, Texte, Musik -- bleibt menschliche Evaluation in der finalen Phase notwendig.

Harness-Debugging ist eine eigene Faehigkeit. Wenn ein einzelner Agent schlechten Output produziert, ist das Debugging unkompliziert: Konversation lesen, finden wo es schiefging, Prompt anpassen. Wenn ein Drei-Agenten-System schlechten Output produziert, kann der Fehler in der Spezifikation des Planners liegen, in der Implementierung des Generators, in den Kriterien des Evaluators oder in der Interaktion zwischen zweien von ihnen. Ich habe mehr Zeit mit dem Debugging von Harness-Interaktionen verbracht als jemals mit dem Debugging einzelner Agent-Prompts.

Das sind reale Einschraenkungen. Sie entkraeften den Ansatz nicht -- das Game-Maker-Experiment beweist, dass die Drei-Agenten-Architektur dramatisch bessere Ergebnisse produziert als Solo-Generierung. Aber sie bedeuten, dass Harness Engineering eine Praxis ist, die Iteration, Monitoring und kontinuierliche Verfeinerung erfordert. Kein Muster, das man einmal implementiert und vergisst.

Wohin das fuehrt

Anthropic veroeffentlichte zwei Artikel zu diesem Thema -- der erste im November 2025 konzentrierte sich auf das Initializer-und-Coding-Agent-Muster, und das Follow-up vom Maerz 2026 stellte die vollstaendige Drei-Agenten-Architektur mit adversarialer Evaluation vor. Die Entwicklungsrichtung zeigt, wohin das fuehrt.

Modellverbesserungen vereinfachen das Harness-Design. Opus 4.6 eliminierte die Notwendigkeit fuer Context Resets. Die naechste Generation koennte die Notwendigkeit fuer explizite Context Compaction eliminieren. Aber Modellverbesserungen eliminieren nicht die Notwendigkeit fuer Orchestrierung und Evaluation. Selbst ein hypothetisch perfektes Modell -- eines mit unendlichem Kontext, perfektem Gedaechtnis und null Denkfehlern -- wuerde immer noch besseren Output mit einem separaten Evaluator produzieren, der seine Arbeit herausfordert. Das ist keine Modell-Limitierung. Das ist eine fundamentale Erkenntnis darueber, wie Qualitaet aus adversarialem Druck entsteht.

Meine praktische Vorhersage: Innerhalb von 12 Monaten werden Harness-as-a-Service-Plattformen so verbreitet sein wie RAG-as-a-Service-Plattformen es heute sind. Tools wie Vercels Ralph Loop Agent und das wachsende Oekosystem rund um Spec-Driven-Development-Frameworks wie GitHubs Spec Kit sind fruehe Signale. Das Rohmaterial -- Modelle, Tool-Use-Faehigkeiten, Evaluation-APIs -- ist bereits produktionsreif. Was fehlt, ist die paketierte Orchestrierungsschicht, die es fuer Engineers zugaenglich macht, die keine Harness-Infrastruktur von Grund auf bauen wollen.

Fuer Entwickler, die jetzt in diesem Bereich arbeiten, ist die Chance klar. Das Harness ist das Produkt. Das Modell ist eine Commodity. Die Teams und Engineers, die gut im Harness-Design werden -- die lernen, Aufgaben zu zerlegen, zuverlaessige Evaluatoren zu bauen, Kontext effektiv zu verwalten und ihre Orchestrierungsmuster parallel zu Modellverbesserungen weiterzuentwickeln -- werden KI-Systeme bauen, die in Produktion funktionieren, waehrend alle anderen noch mit Single-Agent-Prompts kaempfen, die nach 30 Minuten auseinanderfallen.

Die DAW-Sitzung, die ich beobachtet habe? Vier Stunden autonomes Coding, das eine funktionale Anwendung hervorbrachte. Nicht weil das Modell magisch war. Sondern weil das System drumherum so engineert war, dass es das Modell ehrlich hielt, fokussiert hielt und iterieren liess, bis die Arbeit tatsaechlich erledigt war.

Das ist die Lektion. Nicht bessere KI. Bessere Systeme um KI herum.

Haeufig gestellte Fragen

Was ist ein Agent-Harness in der KI-Entwicklung?

Ein Agent-Harness ist das Software-Framework, das ein KI-Modell umhuellt, um Prompts, Tools, Feedback-Schleifen und Validierung zu verwalten -- und ein rohes Modell in ein zuverlaessiges autonomes System zu verwandeln. Stellen Sie es sich als das Auto vor, das den Motor nuetzlich macht: Lenkung, Bremsen, Navigation und alles andere. Fuer eine tiefergehende Aufschluesselung siehe den Abschnitt "Warum Ihr KI-Agent bei komplexen Aufgaben immer wieder scheitert" weiter oben.

Wie beeinflusst Context Anxiety KI-Agenten?

Context Anxiety tritt auf, wenn KI-Modelle spueren, dass sie sich den Grenzen ihres Context Windows naehern, und beginnen zu hetzen, Schritte zu ueberspringen oder Aufgaben vorzeitig als erledigt zu erklaeren. Sonnet 4.5 zeigte dieses Verhalten bei etwa 80K Tokens. Das Millionen-Token-Window von Opus 4.6 eliminiert das Problem weitgehend fuer Sitzungen unter 6 Stunden. Siehe den Abschnitt zu Fehlermodi fuer Strategien zur Risikominderung.

Was ist der Unterschied zwischen Context Compaction und Context Reset?

Context Compaction fasst die Konversationshistorie zusammen, um Token-Platz freizugeben und dabei Schluesselinformationen zu bewahren -- verlustbehaftet, aber kontinuierlich. Context Reset startet den Agenten mit einem komplett frischen Context Window fuer jede Teilaufgabe, wobei Dateien und Artefakte fuer den Zustand herangezogen werden. Neuere Modelle mit groesseren Context Windows bevorzugen Compaction gegenueber Resets.

Wie verbessert adversariale Evaluation den Output von KI-Agenten?

Adversariale Evaluation trennt Inhaltserstellung von Qualitaetsbewertung durch zwei separate Agenten -- inspiriert von der GAN-Architektur. Der Evaluator-Agent nutzt Tools wie Playwright, um laufende Anwendungen interaktiv zu testen und funktionale Fehler zu erkennen, die ein reines Code Review uebersehen wuerde. Anthropics Experimente zeigten, dass dies funktionierende Anwendungen hervorbringt, waehrend Solo-Generierung visuell aehnliche, aber nicht funktionale Ergebnisse liefert.

Kann ich Agent-Harness-Muster ohne das Claude Agent SDK implementieren?

Ja. Die Prinzipien -- Task-Dekomposition, artefaktbasierter Zustand, getrennte Evaluation, Sprint-Vertraege -- sind modell- und framework-agnostisch. Das Claude Agent SDK bietet komfortable Abstraktionen, aber Sie koennen dieselben Muster mit jeder Modell-API, einer Python-Orchestrierungsschicht und Standard-Tools wie Playwright fuer die Evaluation implementieren.

Lassen Sie uns zusammenarbeiten

Sie moechten KI-Systeme aufbauen, Workflows automatisieren oder Ihre Tech-Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (individuelle Entwicklung & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Loesungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io