Harness Engineering: Warum KI-Agenten erst mit dem richtigen Rahmen stundenlang autonom arbeiten

Ein KI-Agent, der sieben Stunden am Stück an einer Codebasis arbeitet — mit 99,9 Prozent Genauigkeit, ohne menschliches Eingreifen. Klingt nach Science-Fiction? Ist es nicht. Anthropic hat genau das Anfang 2026 demonstriert. Der Schlüssel liegt nicht im Modell selbst, sondern in dem, was drumherum passiert: dem Harness.

Willkommen in der Welt des Harness Engineering — einer Disziplin, die gerade entsteht und die Art, wie wir KI-Agenten bauen und einsetzen, grundlegend verändert.

Was ist ein Harness — und warum brauchen KI-Agenten einen?

Der Begriff „Harness” kommt ursprünglich aus dem Software-Testing: Ein Test-Harness ist der Rahmen, der Tests ausführt, Ergebnisse sammelt und die Umgebung kontrolliert. Im Kontext von KI-Agenten bedeutet ein Harness etwas Ähnliches, aber weitreichenderes: Es ist die gesamte Infrastruktur, die einen KI-Agenten in die Lage versetzt, autonom über längere Zeiträume zu arbeiten.

Stell dir vor, du gibst einem brillanten Praktikanten eine komplexe Aufgabe — sagen wir, ein Feature mit Frontend, Backend und Tests zu implementieren. Der Praktikant ist talentiert, aber ohne Struktur passiert Folgendes: Er vergisst nach zwei Stunden, was der ursprüngliche Plan war. Er hält seine eigene Arbeit für großartig, obwohl sie mittelmäßig ist. Er verzettelt sich in Details und verliert das große Ganze aus dem Blick.

Genau das passiert mit KI-Agenten. Ein einzelner LLM-Agent, der eine große Aufgabe bekommt, scheitert nicht an mangelnder Intelligenz — er scheitert an mangelnder Struktur. Und diese Struktur liefert der Harness.

Das Kernproblem: Warum einzelne Agenten bei langen Aufgaben versagen

Wer schon mal versucht hat, einen KI-Agenten an einer mehrstündigen Aufgabe arbeiten zu lassen, kennt die typischen Failure Modes:

Context Overload

Jedes LLM hat ein begrenztes Context Window. Egal ob 128k oder 200k Tokens — bei einer siebenstündigen Coding-Session ist das irgendwann voll. Was dann passiert: Der Agent „vergisst” frühere Entscheidungen, widerspricht sich selbst oder wiederholt bereits erledigte Arbeit. Ich habe das in meiner eigenen Praxis dutzendfach gesehen — nach drei, vier Stunden intensiver Arbeit fängt ein einzelner Agent an, im Kreis zu laufen.

Schlechte Selbstevaluation

Das vielleicht größte Problem: KI-Agenten sind miserabel darin, ihre eigene Arbeit zu bewerten. Anthropic hat das in ihren Tests klar dokumentiert. Ein einzelner Agent, der Code generiert und anschließend selbst reviewt, gibt sich fast immer eine gute Note — selbst wenn das Ergebnis bestenfalls mittelmäßig ist. Das ist kein Zufall, sondern ein systematischer Bias: Das Modell, das den Code geschrieben hat, bewertet ihn mit demselben „Verständnis”, mit dem es ihn generiert hat. Es sieht die eigenen blinden Flecken nicht.

Wer meinen Artikel über KI-Agenten und Code Review gelesen hat, weiß: Selbst bei einfachen Review-Aufgaben ist menschliches Urteilsvermögen schwer zu ersetzen. Bei stundenlangen, autonomen Sessions verschärft sich dieses Problem massiv.

Drifting Goals

Nach genug Iterationen verliert der Agent den Fokus. Er optimiert an Nebenschauplätzen, fügt Features hinzu, die niemand angefordert hat, oder ändert grundlegende Architekturentscheidungen, weil er den ursprünglichen Plan nicht mehr im Kontext hat. Das Ergebnis: viel Aktivität, wenig Fortschritt.

Die Lösung: Planner – Generator – Evaluator

Anthropics Ansatz für Harness Engineering setzt auf eine Drei-Agenten-Architektur, die diese Probleme elegant löst. Die Idee ist inspiriert von GANs (Generative Adversarial Networks) — zwei Netzwerke, die sich gegenseitig herausfordern und dadurch besser werden.

Der Planner

Der Planner ist der Stratege. Er nimmt einen einfachen User-Prompt — „Baue eine Projektmanagement-App” — und verwandelt ihn in Sprints: überschaubare Arbeitspakete mit klaren Anforderungen und Akzeptanzkriterien. Er braucht keine Code-Details, nur das große Bild, den Fortschritt und die nächsten Meilensteine. Das hält seinen Context schlank und fokussiert.

Der Generator

Der Generator setzt die Sprint-Spezifikation um — Code schreiben, Dateien erstellen, Tests ausführen. Er arbeitet nur innerhalb seines aktuellen Sprints und braucht nicht die gesamte Projekthistorie im Context. Nach Abschluss wird ein strukturiertes Übergabe-Artefakt erstellt. Der nächste Sprint startet damit — nicht mit dem gesamten Chatverlauf. Das löst das Context-Overload-Problem elegant, wie ein Schichtwechsel mit strukturiertem Übergabeprotokoll.

Der Evaluator

Der Evaluator ist bewusst adversarial konzipiert. Er bekommt die Sprint-Spezifikation und das Ergebnis, hat aber keinen Zugriff auf den Generierungsprozess. Er testet aktiv — etwa mit Playwright für UI-Tests — und bewertet gegen die Akzeptanzkriterien. Wenn das Ergebnis nicht reicht, geht der Sprint mit konkretem Feedback zurück. Diese adversariale Spannung hält die Qualität hoch.

In Anthropics Demos hat diese Architektur einen 2D-Retro-Spieleentwickler über sechs Stunden und eine Digital Audio Workstation über fast vier Stunden autonom betrieben — komplexe, mehrstufige Softwareprojekte.

Mehr als „nur” Multi-Agent

Der Unterschied zu herkömmlichen Multi-Agent-Systemen liegt im Fokus auf Laufzeit und Autonomie. Die meisten Multi-Agent-Setups arbeiten Minuten — ein Agent recherchiert, einer schreibt, einer formatiert. Harness Engineering zielt auf Agenten, die Tage oder Wochen autonom arbeiten, mit menschlichem Input nur an definierten Checkpoints.

Das verschiebt auch das Berufsbild. Ein Harness Engineer denkt nicht primär über Prompts nach, sondern: Wie zerlege ich Aufgaben in Sprints? Welche Info braucht jeder Agent — und welche nicht? Wie gestalte ich Übergabe-Artefakte? Wo muss ein Mensch eingreifen? Das ist Software-Architektur meets Projektmanagement — verdammt nah an dem, was ich als Webentwickler sowieso mache. Nur dass mein Team jetzt teilweise aus KI-Agenten besteht.

Praxis: Was du heute schon umsetzen kannst

Die vollständige Planner-Generator-Evaluator-Architektur ist kein Hexenwerk. Du brauchst kein spezielles Framework dafür. Hier sind die Prinzipien, die du sofort in deine eigenen KI-Workflows einbauen kannst:

1. Aufgaben in Sprints zerlegen

Statt einem Agenten zu sagen: „Baue mir eine Web-App”, zerlege die Aufgabe vorab in 5–10 klar definierte Sprints. Jeder Sprint hat ein Ziel, Eingaben und Akzeptanzkriterien. Das kannst du manuell machen oder — meta genug — einen separaten KI-Agenten dafür nutzen.

2. Context-Isolation ernst nehmen

Gib deinem Agenten pro Sprint nur die Information, die er braucht. Nicht den gesamten bisherigen Chatverlauf, nicht alle Projektdateien. Je schlanker der Kontext, desto fokussierter die Arbeit. Wer sich für die technischen Hintergründe interessiert, dem empfehle ich meinen Post über Context Engineering für KI-Agenten.

3. Evaluation separat halten

Lass nie denselben Agenten seine eigene Arbeit bewerten. Starte eine separate Session, gib ihr die Anforderungen und das Ergebnis, und lass sie unvoreingenommen testen. Das ist der größte Quick Win aus dem Harness-Konzept — und erstaunlich wenige Leute machen das.

4. Strukturierte Übergabe-Artefakte erstellen

Nach jedem Sprint sollte ein kurzes Dokument entstehen, das den aktuellen Stand zusammenfasst: Was wurde implementiert? Welche Entscheidungen wurden getroffen? Was ist noch offen? Das ist der Kontext für den nächsten Sprint — und es muss kein Essay sein. Ein strukturiertes JSON oder Markdown mit den wichtigsten Punkten reicht.

5. Checkpoints definieren

Entscheide vorab, an welchen Punkten du als Mensch drüberschauen willst. Nicht nach jedem Sprint — das wäre ineffizient. Aber nach jedem dritten? Nach jedem architekturrelevanten Sprint? Nach dem ersten und letzten? Finde den Rhythmus, der für dein Risikoprofil passt.

Die Risiken: Wenn der Harness versagt

Natürlich ist das Ganze nicht ohne Risiken. Wenn der Planner eine falsche Architekturentscheidung trifft, baut der Generator über mehrere Sprints pflichtbewusst ein Kartenhaus — der Evaluator testet gegen die Akzeptanzkriterien, aber wenn die Kriterien falsch sind, hilft auch die beste Evaluation nichts. Das erinnert an die Dynamik, die ich in meinem Artikel über KI-generierten Code und Technical Debt beschrieben habe.

Dazu kommt übermäßiges Vertrauen: „Der Agent hat sechs Stunden gearbeitet und alle Tests bestanden” ist kein Qualitätsargument. Die Tests testen nur, was jemand als testbar definiert hat. Und schließlich der Koordinations-Overhead — drei Agenten kosten mehr Tokens, Zeit und Geld. Für eine 20-Minuten-Aufgabe ist das Overkill. Die Kunst liegt darin, zu wissen, wann der Harness sich lohnt.

Wohin geht die Reise?

Harness Engineering steht noch am Anfang. Ich sehe drei Entwicklungen: Erstens werden Harness-Frameworks als Open Source standardisiert — Anthropic hat bereits Code veröffentlicht, in einem Jahr gibt es ein Ökosystem von Templates für verschiedene Aufgabentypen. Zweitens verschiebt sich die Entwicklerrolle weiter Richtung Orchestrierung — wer heute Terraform schreibt statt Server manuell einzurichten, wird morgen Harness-Spezifikationen schreiben. Wie jede Abstraktion verändert das, was Entwickler-Sein bedeutet, ohne Entwickler überflüssig zu machen. Drittens werden die Grenzen organisatorisch, nicht technisch: Autonome Agenten brauchen Audit-Trails, Governance und klare Verantwortlichkeiten.

Fazit: Der Rahmen ist wichtiger als das Modell

Die wichtigste Erkenntnis aus dem Harness-Engineering-Ansatz ist gleichzeitig die kontraintuitivste: Es kommt weniger auf das Modell an als auf den Rahmen, in dem es arbeitet. Ein mittelmäßiges Modell in einem gut designten Harness schlägt ein Spitzenmodell ohne Struktur — zumindest bei komplexen, langlebigen Aufgaben.

Das ist eine gute Nachricht für Entwickler und Unternehmen. Denn während wir auf die Qualität der Foundation Models keinen Einfluss haben, haben wir sehr wohl Einfluss auf den Rahmen. Harness Engineering ist kein Geheimwissen und kein teures Produkt — es ist angewandte Software-Architektur, übertragen auf KI-Systeme.

Und ehrlich gesagt: Wer als Entwickler versteht, wie man Code-Reviews strukturiert, CI/CD-Pipelines baut und Projekte in handhabbare Tickets zerlegt, hat bereits 80 Prozent der Skills, die ein Harness Engineer braucht. Der Rest ist Übung — und davon dürften wir in den nächsten Monaten reichlich Gelegenheit haben.