Warum KI-Agenten in der Produktion versagen: Erklärung des Harness-Engineerings

Stellen Sie sich einen Entwickler um 2 Uhr morgens vor, der drei Wochen damit verbracht hat, Anfragen neu zu formulieren, das neueste Flaggschiff-Modell auszuprobieren und an den RAG-Chunk-Größen herumzufummeln. In einer Sandbox funktioniert der Agent hervorragend. In der Produktion bricht er jedoch zusammen: Er vergisst eine zuvor getroffene Entscheidung, gibt kurz vor der Übergabe eines fehlerhaften Ergebnisses Erfolg an, und seine Erfolgsrate bei Aufgaben liegt unabhängig vom verwendeten Modell bei 68 %. Eine Steigerung auf über 70 % scheint unmöglich.

Viele Teams erkennen diese Situation. Die übliche Diagnose lautet, das Modell sei nicht gut genug. Eine bessere Diagnose ist, dass das Problem im um das Modell gebauten System liegt – und solange das nicht anerkannt wird, wird kein Modellwechsel viel ändern.

Drei Phasen der Arbeit mit LLMs

Die Betrachtung von LLM-Anwendungen hat drei Phasen durchlaufen, und viele Teams stecken immer noch in einer oder zwei davon fest, während sie auf Probleme der dritten Phase stoßen.

Phase eins: Prompt-Engineering

Jeder beginnt hier damit, zu prüfen, ob das Modell die Anfrage verstanden hat. Large Language Models sind äußerst empfindlich gegenüber der Art und Weise, wie sie geführt werden. Eine gut gewählte Rolle, einige Beispiele sowie ein festgelegtes Ausgabeformat können die Ergebnisse verändern, und für begrenzte, einstufige Aufgaben ist gutes Prompting unverzichtbar.

Doch es gibt auch Grenzen. Egal wie elegant die Anweisungen formuliert sind, sie können dem Modell keine Fakten liefern, die es nicht besitzt, es nicht daran erinnern, was vor drei Tool-Aufrufen geschah, oder verhindern, dass es Daten erfindet, wenn die Realität enttäuschend ist. Die häufige Falle besteht darin, zu glauben, ein präziserer Prompt könne fehlende Grundlagen oder aktuellen Kontext ersetzen. Das ist jedoch nicht möglich.

Phase zwei: Kontext-Engineering

Die nächste Frage ist, ob das Modell über die notwendigen Fakten verfügt. Teams fügen RAG-Pipelines, dynamische Abrufmechanismen sowie die Rückgabe von Tool-Ergebnissen ein und integrieren sorgfältig das Gesprächsverlauf, wobei sie darauf achten, was das Modell bei seiner Entscheidungsfindung sehen kann. Dies ist ein echter Fortschritt – Agenten werden deutlich intelligenter, wenn die richtigen Informationen zur richtigen Zeit vorliegen.

Was das Kontextmanagement nicht behebt, ist der Ausführungsabweichung. Der Agent entwirft einen hervorragenden Plan, führt den ersten Schritt korrekt aus, interpretiert den Rückgabewert eines Tools im zweiten Schritt falsch und gerät für weitere ein Dutzend Schritte vom Kurs ab. Nichts im System bemerkt das. Es setzt weiterhin einen Plan um, der bereits vor langer Zeit falsch geworden ist.

Ein häufiger Fehler besteht darin, Kontextengineering mit RAG in Vektordatenbanken gleichzusetzen. Eine echte Kontextverwaltung umfasst außerdem die dynamische Eingabe von Zuständen, das Zusammenfassen der Antworten von Tools sowie gezieltes Abschneiden der Historie. RAG ist erst der Anfang.

Phase drei: Harness Engineering

Die Frage ist nun, ob das Modell im Laufe der Zeit weiterhin korrekt funktionieren kann – und die Antwort ist für alle, die sich eine bessere Leistung des Modells erhofft hatten, etwas enttäuschend. Harness Engineering bezeichnet die Praxis, ein „Gerüst“ um ein Modell zu bauen: deterministische Systeme, die beobachten, was das Modell tut, seine Fehler erkennen, Grenzen setzen und es zurückholen, wenn es vom Kurs abkommt. Der Begriff stammt von Zügeln und Sicherheitsleinen, also Ausrüstung zum Steuern.

Ein mentales Modell: Agent gleich Modell plus Harness

Eine von LangChain popularisierte Darstellung formuliert es klar: Ein Agent ist ein Modell plus eine Hilfssysteme. Fast alles in einer Codebasis, was dazu beiträgt, dass ein Agent in der Produktion funktioniert – abgesehen von der Anfrage an die API des Grundmodells – gehört zu diesen Hilfssystemen.

Stellen Sie sich vor, Sie schicken einen jüngeren Kollegen zu einem wichtigen Kundentreffen.

• Prompting ist die Tagesordnung: Begrüßung, Präsentation des Produkts, Abfragen zu den Anforderungen.
• Context sind die Hintergrundinformationen: Kundengeschichte, Preisliste und Ziele des Treffens.
• Die Hilfssysteme umfassen den Rest: die mitzunehmende Checkliste, eine Kontrolle durch Sie nach der Hälfte des Treffens, eine aufgezeichnete Transkription, Möglichkeiten, Korrekturen vorzunehmen, falls sie vom Weg abkommen, sowie klare Kriterien für die Genehmigung des Treffenberichts.

Eine bessere Einweisung kann eine fehlende Verantwortungsstruktur nicht ausgleichen. Die ersten beiden Phasen helfen einem Modell, besser zu denken, und die Steuerungsstruktur sorgt dafür, dass es zuverlässig handelt. Die Erfahrung eines Teams – eine Anekdote und kein Vergleichswert – besagt, dass durch die Überarbeitung der Aufgabenteilung, des Umgangs mit Zuständen, der Überprüfung kritischer Schritte sowie der Fehlerbehebung derselbe Modell mit denselben Anweisungen die Erfolgsrate bei Aufgaben von etwa 70 % auf über 95 % stieg.

Sechs Ebenen einer ausgereiften Steuerungsstruktur

Eine solche Steuerungsstruktur besteht nicht aus einer einzigen Datei oder einem cleveren Wrapper. Sie ist schichtweise aufgebaut, wobei jede Schicht eine andere Art von Fehler abdeckt.

Ebene 1: Informationsgrenzen

Was das Modell in seinem unmittelbaren Kontext wahrnimmt, prägt seine Leistung stärker als fast alles andere. Zusätzliche Daten machen es nicht intelligenter, sondern führen dazu, dass es den Fokus verliert. Die Vermischung von Systemregeln, dem aktuellen Zustand der Aufgabe sowie externen Informationen zu einem unstrukturierten Ganzen ist noch schlimmer, denn das Modell beginnt, Einschränkungen zu ignorieren, und wichtige Regeln werden zum Hintergrundlärm. Das Steuerungssystem sollte ausdrücklich entscheiden und kennzeichnen, was das Modell erhält: seine Rolle, das aktuelle Ziel, die Erfolgskriterien sowie eine klare Trennung zwischen den Informationsarten.

Schicht 2: das Tool-System

Ohne Tools kann ein LLM nur Text vorhersagen. Mit einem guten Tool-System kann es in der realen Welt handeln. Ein typischer früher Fehler besteht darin, ihm zu viele Tools zur Verfügung zu stellen. Fünfzehn gründlich dokumentierte Tools klingen mächtig, doch die Aufmerksamkeit wird dadurch aufgesplittert, und das Modell beginnt, nicht existierende Parameter zu erfinden oder APIs falsch zu verwenden, die es kaum versteht.

Das Framework sollte bestimmen, wann Werkzeuge verwendet werden, und nicht nur, welche vorhanden sind. Es sollte verhindern, dass das Modell selbst entscheidet, wann es suchen soll, und dass es sucht, obwohl es bereits die Antwort kennt. Eine Regel hat keine Ausnahmen: Leiten Sie niemals die rohe Ausgabe von Werkzeugen direkt an das LLM weiter. Eine 50-Einträge umfassende JSON-Antwort einer API verschlechtert den Kontext erheblich. Filtern, analysieren und zusammenfassen Sie die Ergebnisse, bevor das Modell sie sieht.

Ebene 3: Ausführungsorchestrierung

Modelle scheitern oft nicht wegen mangelnder Einzelskills, sondern weil sie diese nicht in der richtigen Reihenfolge miteinander verknüpfen können. Sie arbeiten wie im Fluss des Bewusstseins, springen zwischen Schritten hin und her, überspringen Überprüfungen und erzeugen Ausgaben, bevor sie das benötigte Material haben. Das Framework setzt feste Richtlinien: Ziel verstehen, bewerten, welche Informationen vorhanden sind, das Fehlende abrufen, analysieren, erzeugen, überprüfen und anschließend ausgeben.

Dadurch wird das Projektmanagement von einem probabilistischen Modell in ein deterministisches System überführt. Das Modell sollte nicht die Reihenfolge der Arbeiten bestimmen – diese Struktur gehört in das Steuerungssystem.

Schicht 4: Speicher und Zustand

Ein zustandsloser Agent hat bei jedem Schritt Amnesie, als wäre jeder Schritt einer mehrschrittigen Aufgabe ein neues Gespräch. Ein praktikabler Ansatz hält drei Arten von Speicher strikt voneinander getrennt:

1. Der aktuelle Zustand der Aufgabe, d.h. welcher Schritt gerade läuft, was ausstehend ist und was bereits bestätigt wurde.
2. Zwischenergebnisse dieser Sitzung.
3. Langfristiger Speicher sowie Benutzerprofile, wie Präferenzen und Kontexte, die über mehrere Sitzungen hinweg bestehen bleiben.

Der größte Fehler besteht darin, den Aufgabenzustand mit der Gesprächshistorie zu vermischen. Dadurch entsteht ein ständig wachsendes, formloses Kontextfenster, das das Modell im Laufe der Aufgabe immer schlechter macht.

Schicht 5: Bewertung und Beobachtbarkeit

Primitive Agenten versagen hier. Sie erzeugen Ausgaben, melden Erfolg und haben keine Möglichkeit, herauszufinden, ob dies richtig ist. Ein Agent, der seine eigene Arbeit bewertet, weist einen eingebauten optimistischen Bias auf: Er bezeichnet fehlerhaften Code als funktionsfähig und bewertet eine Antwort als zufriedenstellend, obwohl er die Frage nie beantwortet hat.

Das Framework benötigt unabhängige, automatisierte Überprüfungen. Eine menschliche Überprüfung nachträglich ist zu langsam und skalierbar nicht. Diese Schicht umfasst automatische Validierung der Ausgaben, Testumgebungen, detaillierte Protokollierung, Metriken sowie die Zuordnung von Fehlern. Das System muss ständig nachweisen, dass seine Handlungen richtig sind, und darf dies niemals einfach voraussetzen.

Schicht 6: Einschränkungen, Validierung und Wiederherstellung

Fehler sind im Produktivbetrieb der Normalzustand. APIs laufen ab, JSON-Daten sind fehlerhaft und Suchergebnisse sind ungenau. Ein Agent ohne Wiederherstellungsmechanismus benötigt nach jedem Fehler einen vollständigen manuellen Neustart. Dafür sind drei Elemente erforderlich:

• Beschränkungen: fest codierte Regeln dafür, was der Agent auf keinen Fall tun darf.
• Validierung: Kontrollen vor und nach der Ausgabe, wie z. B. Schema-Validierung, Formatprüfungen sowie Überprüfung der Beschränkungen.
• Erholung: Wiederholungsversuche, Rückfallstrategien sowie Rollback auf den letzten bekannten stabilen Zustand.

Kontextangst

Bei Aufgaben, die viele Dutzend Schritte umfassen, tritt manchmal etwas Ungewöhnliches auf – Forscher bei Anthropic haben diesem Phänomen einen Namen gegeben: Kontextangst. Wenn das Kontextfenster seinem Limit nahekommt, vernachlässigen die Modelle feine Details, verlieren den Überblick über die Kernziele und scheinen es eilig zu haben, fertigzuwerden. Sie erfinden Schlussfolgerungen, zu denen sie nie gelangt sind, und überspringen die Überprüfung; diese Eile macht sie nachlässig.

Die offensichtliche Lösung ist die Kompression: Man fasst die Historie zusammen, injiziert diese Zusammenfassung und setzt fort. Dadurch verringert sich die Anzahl der Tokens, doch der kognitive Zustand des Modells sowie die Aufmerksamkeitsverdünnung werden nicht zurückgesetzt. Erfolgreich ist eine drastischere Methode – das vollständige Neustarten des Agents. Wenn der Kontext zu groß wird, gelangt die komprimierte Zusammenfassung an eine völlig neue Agentinstanz mit einem sauberen Kontext und ohne jegliche angesammelte Verwirrung. Es ist, als würde man einen Speicherdurchfluss durch Neustarten des Prozesses beheben und nicht durch hektische Müllsammlung. Der für diesen Ansatz verwendete Begriff ist „Context Reflect“.

Die Verbesserung der Tool-Zugänglichkeit beruht auf einem ähnlichen Konzept namens progressive Disclosure. Anstatt die gesamte Tool-Bibliothek zu Beginn zu laden, erhält das Modell nur minimale Grundstrukturen. Wenn es anzeigt, dass es eine bestimmte Funktion benötigt, injiziert das System anschließend die detaillierte Dokumentation sowie das Parameter-Schema. Die Optimierung des Kontexts bedeutet nicht, dem Modell mehr zu geben, sondern ihm genau das richtige Material zur richtigen Zeit bereitzustellen, wenn es benötigt wird.

Trennung von Erstellung und Bewertung

Eine der nützlichsten Ideen stammt von der Art und Weise, wie Anthropic autonome Agenten entwickelt, die stundenlang voll funktionsfähige Produkte ohne menschliche Überprüfung erzeugen. Der Kern besteht in einer strengen dreiteiligen Aufteilung:

• Der Planer wandelt unpräzise menschliche Anfragen in genaue ingenieurtechnische Spezifikationen um.
• Der Ersteller setzt diese Spezifikationen Schritt für Schritt um.

Der Evaluator fungiert als unabhängige QA-Funktion, die funktional vom Generator getrennt ist.

Ein Evaluator liest nicht nur den Code des Generators. Er interagiert mit dem Ergebnis. Bei der Arbeit an der Benutzeroberfläche klickt er sich durch die Schnittstelle, prüft das Layout und testet interaktive Zustände. Er überprüft gegen die reale Welt und nicht gegen die Beschreibung der realen Welt durch den Generator.

OpenAI ging noch einen Schritt weiter. Sobald die Agenten Code schneller schrieben, als Menschen Pull Requests prüfen konnten, gaben sie dem Agenten einen eigenen automatisierten CI/CD-Pipeline. Der Agent führt seine Aufgaben in isolierten Sandboxes aus, macht Screenshots mit headless-Browsern, durchsucht seine eigenen Protokolle und wiederholt den Vorgang, bis die Bereitstellung erfolgreich ist – und das wiederum ohne dass jemand zuseht. „Erledigt“ bedeutet nicht mehr nur, dass der Text generiert wurde. Es bedeutet, dass der Code ausgeführt wurde, die Protokolle überprüft wurden, ein Fehler gefunden und behoben wurde sowie die Bereitstellung in der Sandbox verifiziert wurde.

Wo die wirklichen Grenzen liegen

Die Intelligenz eines Grundmodells legt die theoretische Grenze für eine Leistungsübersicht fest. Wie gut das Umfeld des Modells konzipiert ist, bestimmt, ob diese Intelligenz unter unübersichtlichen realen Bedingungen überleben, sich erholen und Wert schaffen kann. Ab einem bestimmten Niveau ist das Modell nicht mehr die Engstelle. Der Unterschied zwischen einer Erfolgsrate von 70 % und 95 % – was auch der Unterschied zwischen einer Demo und einem Produkt darstellt – liegt im Umfeld des Modells.