In der KI-Engineering-Community setzt sich gerade ein Begriff durch, und er benennt etwas, das es schon viel länger gibt als das Wort dafür. Der Begriff lautet Harness. Er bedeutet: alles an einem KI-Agenten, was nicht das Modell selbst ist. Vivek Trivedy von LangChain hat es am klarsten formuliert: „Was nicht das Modell ist, ist der Harness.“ Die Claude-Code-Dokumentation von Anthropic nennt das eigene SDK „den Agenten-Harness, auf dem Claude Code läuft“. Birgitta Böckeler von Thoughtworks schrieb auf Martin Fowlers Blog ein ganzes Framework für Harness Engineering. Anthropic verwendete das Wort schon Ende 2025. Anfang 2026, nachdem OpenAI einen eigenen Leitfaden zum Harness Engineering veröffentlicht hatte, war es zum Standardbegriff der Branche geworden. Das, was es beschreibt, hat sich über zwei Jahre angesammelt.
Modellgröße, Trainingsdaten, Benchmark-Werte: All das ist wichtig, doch wie sich zeigt, entscheidet das umgebende System oft stärker über die Leistung eines Agenten in der Praxis als das Modell darin. LangChain hat das direkt vorgeführt: dasselbe Modell, dieselben Gewichte, ein anderer Harness, und der eigene Coding-Agent sprang auf TerminalBench 2.0 von außerhalb der Top 30 in die Top 5. Laut der Analyse von LangChain erreichte ein separates Forschungsprojekt eine Erfolgsquote von 76,4 %, indem es ein LLM die Harness-Infrastruktur selbst optimieren ließ, und übertraf damit von Hand entworfene Systeme.
Das Modell ist das Gehirn. Der Harness ist der Körper. Und der Körper zählt, wie sich zeigt, enorm.
Was ein Harness tatsächlich tut
Ein rohes LLM nimmt Text entgegen und gibt Text aus. Mehr tut es wirklich nicht. Es kann sich nicht erinnern, was vor fünf Minuten war. Es kann keinen Befehl ausführen. Es kann keine Datei lesen. Es kann nicht prüfen, ob seine eigene Ausgabe stimmt. Jede dieser Fähigkeiten (Gedächtnis, Tool-Ausführung, Dateizugriff, Selbstprüfung) ist eine Funktion des Harness.
Beren Millidge hat die Analogie in einem Essay von 2023 systematisch durchgespielt: Das LLM ist die CPU, das Kontextfenster der RAM (schnell, aber begrenzt), externe Datenbanken sind die Festplatte (groß, aber langsam), Tool-Integrationen die Gerätetreiber. Der Harness ist in diesem Bild das Betriebssystem.
Der einfachste denkbare Harness ist eine Chat-Oberfläche. Sie tippen etwas, das Modell antwortet, der Harness hängt beide Nachrichten an eine Liste an und schickt beim nächsten Mal die ganze Liste zurück. Diese While-Schleife (Eingabe lesen, Modell aufrufen, Ausgabe anhängen, wiederholen) ist ein Harness. Wer ChatGPT benutzt hat, hat einen benutzt.
Interessant werden die Harnesses, die weiter gehen. Ein Agenten-Harness im Produktivbetrieb kümmert sich typischerweise um den Aufbau des Prompts (in jedem Schritt den richtigen Kontext für das Modell zusammenstellen), die Tool-Ausführung (die Tool-Aufrufe des Modells abfangen, ausführen und die Ergebnisse zurückspielen), die Speicherverwaltung (Informationen über Kontextfenster hinweg verdichten, zusammenfassen oder dauerhaft ablegen), die Verifikation (Tests laufen lassen, Ausgaben prüfen, bei Fehlern neu versuchen) und die Zustandssicherung (dafür sorgen, dass das Projekt ein Gedächtnis hat, auch wenn das Modell keines hat). Das Modell denkt, der Harness lenkt.
Warum es Harnesses gibt
Harnesses sind entstanden, weil LLMs an praktische Grenzen stießen, sobald jemand sie für echte Arbeit einsetzen wollte.
Die erste Grenze ist das Gedächtnis. Ein Standard-LLM beginnt jede Sitzung ohne Wissen über frühere Interaktionen. Das Engineering-Team von Anthropic hat das Problem präzise beschrieben: Stellen Sie sich ein Softwareprojekt vor, an dem Entwickler in Schichten arbeiten, und jeder neue Entwickler kommt mit vollständiger Amnesie über die vorherige Schicht. Genau das macht ein rohes LLM über Kontextfenster hinweg. Harnesses lösen das mit Fortschrittsdateien, Git-Historien und strukturierten Logs, die zwischen den Sitzungen bestehen bleiben, und geben so dem Projekt ein Gedächtnis, auch wenn das Modell keines hat.
Die zweite Grenze ist das Handeln. LLMs produzieren Text. Aufgaben verlangen Handlungen: Code ausführen, Datenbanken abfragen, im Web surfen, Dateien schreiben. Der Harness schlägt die Brücke, indem er die Ausgabe des Modells auf Tool-Aufrufe überwacht, sie in einer Sandbox ausführt und die Ergebnisse wieder in den Kontext des Modells einspeist. Der Harness gibt dem Modell Hände.
Die dritte Grenze ist die Disziplin. Ohne Struktur von außen versuchen Agenten, alles auf einmal zu lösen, erklären sich vorschnell zum Sieger oder liefern Ergebnisse, die plausibel aussehen und bei genauerem Hinsehen auseinanderfallen. Anthropic hat das gemerkt, als Claude eine vollständige Webanwendung bauen sollte: Das Modell versuchte, die ganze App in einem Anlauf zu bauen, ihm ging mitten in der Implementierung der Kontext aus, und die nächste Sitzung musste mit halbfertigem, undokumentiertem Code beginnen. Die Lösung war struktureller Art: ein Initialisierungs-Agent, der eine Feature-Liste und eine Fortschrittsdatei anlegt, gefolgt von Coding-Agenten mit der Anweisung, jeweils an einem Feature zu arbeiten und nach jedem zu committen. Diese Lösung ist ein Harness.
Die vierte Grenze ist der Kontextverfall. Selbst innerhalb einer einzigen Sitzung lässt die Leistung des Modells nach, wenn sich das Kontextfenster mit irrelevanten oder widersprüchlichen Informationen füllt, ein Phänomen, das inzwischen Context Rot heißt. Harnesses steuern dagegen mit Compaction (ältere Gesprächsabschnitte zusammenfassen) und gezielter Kontextinjektion (dem Modell nur geben, was es für den aktuellen Schritt braucht, nicht alles, was je passiert ist).
Das sind alles keine Modellprobleme. Es sind Systemprobleme. Den Harness gibt es, weil die Lücke zwischen „kann Text erzeugen“ und „kann nützliche Arbeit leisten“ ein Problem des Systems Engineering ist und keines des maschinellen Lernens.
Zwei Bedeutungen, eine Abstammung
Das Wort „Harness“ taucht im KI-Engineering in zwei verschiedenen, aber verwandten Zusammenhängen auf, und der Unterschied ist wichtig.
Das erste ist der Agenten-Harness: die Laufzeit-Infrastruktur rund um einen LLM-gestützten Agenten, die ihm erlaubt zu planen, zu handeln, sich zu erinnern und sich selbst zu korrigieren. Daran bauen Anthropic, LangChain und die breitere Community für Agenten-Infrastruktur. Claude Code, DeepAgents, Codex: Das sind Agenten-Harnesses.
Das zweite ist der Evaluation-Harness: ein Framework, das Modelle standardisierte Aufgaben durchlaufen lässt, damit die Ergebnisse reproduzierbar und vergleichbar sind. Das klassische Beispiel ist der LM Evaluation Harness von EleutherAI, inzwischen das Standardwerkzeug für Benchmarks von Open-Source-Sprachmodellen. Wenn ein Paper Werte für MMLU oder HellaSwag meldet, laufen sie mit ziemlicher Sicherheit über den Harness von EleutherAI.
Die Abstammung ist dieselbe. Beides sind Softwaresysteme, die ein Modell umhüllen, seine Ein- und Ausgaben verwalten und dem, was sonst ungebremste Texterzeugung wäre, eine Struktur geben. Der Agenten-Harness gibt Struktur, um das Modell nützlich zu machen. Der Evaluation-Harness gibt Struktur, um es messbar zu machen. Verschiedene Zwecke, identisches Architekturprinzip: Das Modell arbeitet nicht allein.
Wer das gebaut hat
Das Konzept kam nicht aus einer einzigen Quelle. Es ist zusammengewachsen.
Anthropic veröffentlichte im November 2025 „Effective Harnesses for Long-Running Agents“ und stellte darin das Muster aus Initialisierungs-Agenten und Coding-Agenten sowie das Claude Agent SDK als Allzweck-Harness vor. In den allgemeinen Sprachgebrauch schoss der Begriff im Februar 2026, als OpenAI einen Leitfaden zum Harness Engineering von Ryan Lopopolo veröffentlichte. Er beschreibt, wie das dortige Team mit Codex-Agenten rund eine Million Zeilen Produktionscode baute, ohne dass Menschen eine einzige Zeile schrieben. Mitchell Hashimoto, der Schöpfer von Terraform, brachte die Kernaussage auf eine Formel, die Praktiker sofort übernahmen: Agent = Modell + Harness. LangChain formalisierte diese Gleichung Anfang 2026 in einer Reihe von Beiträgen, die im Projekt DeepAgents gipfelte: ein Open-Source-Harness, bei dem alles schon dabei ist und der ausdrücklich dem nachempfunden ist, was Claude Code so wirksam gemacht hat. Birgitta Böckeler von Thoughtworks veröffentlichte im April 2026 auf martinfowler.com ein Framework für Harness Engineering und führte darin die Unterscheidung zwischen Feedforward und Feedback ein (Guides, die den Agenten steuern, bevor er handelt, Sensoren, die danach prüfen) sowie die Achse rechnerisch/inferenziell (deterministische Prüfungen gegenüber dem LLM als Richter).
Die Linie des Evaluation-Harness ist älter. Der LM Evaluation Harness von EleutherAI ist seit 2023 das Standardwerkzeug für Benchmarks, und das Konzept des Test-Harness in der Softwareentwicklung ist Jahrzehnte älter als LLMs. Neu ist, dass die Agenten-Community das Wort übernommen und vom Testen auf die Laufzeit-Infrastruktur im Produktivbetrieb ausgedehnt hat.
Es gibt keinen einzelnen Erfinder. Es gibt einen Punkt, an dem alles zusammenlief: den Moment, in dem genug Leute Agenten für den Produktivbetrieb bauen wollten und feststellten, dass das Modell der einfache Teil war.
Beispiele in freier Wildbahn
Claude Code gehört zu den bekanntesten Agenten-Harnesses, die heute im Produktivbetrieb laufen. Es umgibt die Modelle von Anthropic mit einer terminalbasierten Ausführungsschleife, Dateisystemzugriff, Git-Integration, Compaction des Kontexts und einem System-Prompt, der einen beträchtlichen Teil des tatsächlichen Verhaltens des Agenten ausmacht. Wenn Anthropic sagt, das Claude Agent SDK sei „der Agenten-Harness, auf dem Claude Code läuft“, ist das eine präzise Aussage: Das SDK ist nicht das Modell. Es ist alles andere.
DeepAgents von LangChain ist ein Open-Source-Harness auf Basis der LangGraph-Runtime. Er bringt ein Planungstool, Dateisystemzugriff, das Starten von Sub-Agenten, Middleware-Hooks und Kontextverwaltung mit, und das Team nennt das Ganze „eine Allzweckversion von Claude Code“. Besonders interessant ist die Middleware-Architektur: Hooks, die vor und nach jedem Modellaufruf auslösen und so Schleifenerkennung, Kontextinjektion und Checklisten vor dem Abschluss ermöglichen, ohne die zentrale Agentenschleife anzutasten.
Der Ralph Loop ist ein Harness-Muster, kein Produkt. Der Entwickler Geoffrey Huntley hat ihn erfunden, und er packt jeden beliebigen Coding-Agenten in eine Bash-Schleife: Agent starten, fertig werden lassen, mit frischem Kontext neu starten. Maßgeblich ist das Dateisystem (das PRD, die Fortschrittsdatei, die Git-Historie), nicht der interne Zustand des Agenten. Ein Team bei einem YC-Hackathon erzeugte damit über Nacht mehr als 1.100 Commits in sechs Repositories, für etwa 10,50 Dollar pro Stunde und Agent. Das Muster ist einfach, das Prinzip aber wichtig: Der Harness steuert den Lebenszyklus des Agenten, nicht umgekehrt.
clive bezieht eine andere architektonische Position. Statt Tools in Schemas und APIs zu verpacken, gibt es dem Agenten ein Terminal und eine Tastatur. Der Harness ist tmux, ein gemultiplexter Terminalemulator, der Tool-Panes voneinander isoliert, Verbindungsabbrüche übersteht und atomare Bildschirmaufnahmen liefert. Der Agent liest den Bildschirm, entscheidet, was er tippt, sendet Tastenanschläge, sieht sich das Ergebnis an und wiederholt das Ganze. Das Terminal ist der Harness. Jedes existierende CLI-Tool wird für den Agenten nutzbar, ohne dass es einen MCP-Server, einen REST-Wrapper oder eine Schema-Definition braucht.
Jeder dieser Ansätze wettet anders darauf, was der Harness verwalten und was das Modell übernehmen soll. Einig sind sie sich im Prinzip: Das Modell allein ist nicht der Agent.
Wie man einen baut
Der minimal brauchbare Harness ist überraschend klein. Er ist eine While-Schleife.
while true:
context = assemble_context(history, tools, task)
response = call_model(context)
if response.has_tool_calls():
results = execute_tools(response.tool_calls)
history.append(response, results)
else:
return response.text
Das ist der Kern jedes Agenten-Harness. Anthropics Ansatz wurde als „dumme Schleife“ beschrieben: Die ganze Intelligenz steckt im Modell, der Harness verwaltet nur die Züge. Die Komplexität steckt nicht in der Schleife, sondern in allem, was die Schleife verwaltet.
Auf diesem Kern schichten Sie die Funktionen auf, die die Aufgabe verlangt.
Kontextverwaltung kommt zuerst. Das Modell hat ein festes Kontextfenster. Ihr Harness entscheidet, was hineinkommt. Als Minimum brauchen Sie den System-Prompt, die aktuelle Aufgabe und die jüngsten Tool-Ergebnisse. Werden die Sitzungen länger, brauchen Sie Compaction: ältere Gesprächsabschnitte zusammenfassen, um Platz für neue zu schaffen. Claude Code nutzt Git-Commits als Checkpoints und Fortschrittsdateien als strukturierte Notizzettel. DeepAgents verwendet ein Dateisystem-Backend. Der Ralph Loop löst es, indem er den Agenten beendet, frisch startet und das Dateisystem den Zustand tragen lässt.
Verifikation kommt an dritter Stelle und wird am häufigsten weggelassen. Ein Harness im Produktivbetrieb übernimmt die erste Ausgabe des Modells nicht blind. Er lässt Tests laufen, prüft die Formatierung, gleicht mit Akzeptanzkriterien ab und spielt Fehler für einen neuen Versuch zurück. Böckelers Framework unterscheidet rechnerische Sensoren (Linter, Testsuiten, Type Checker: deterministisch und schnell) von inferenziellen Sensoren (LLM als Richter, Review-Agenten: langsamer, aber semantisch reicher). Die Kombination ist stark: die schnellen Prüfungen bei jeder Änderung, die teuren vor der Integration.
Gedächtnis und Persistenz kommen an vierter Stelle. Erstreckt sich die Aufgabe über mehrere Sitzungen, muss der Harness einen Zustand sichern, der die Grenzen des Kontextfensters überlebt. Die Optionen reichen von einfach (eine Datei progress.txt, die der Agent zu Beginn jeder Sitzung liest) bis aufwendig (Vektorspeicher, strukturierte Datenbanken, sitzungsübergreifende Gedächtnissysteme). Die zentrale Erkenntnis aus Anthropics Arbeit an lange laufenden Agenten: Geben Sie dem Projekt ein Gedächtnis, nicht dem Modell. Dateien, Commits und Logs bleiben bestehen. Der interne Zustand des Modells nicht.
Steuerung hört nie auf. Böckeler nennt das die Aufgabe des Menschen: am Harness weiterarbeiten. Tritt ein Problem mehrfach auf, verbessern Sie die Feedforward-Steuerung (Regeln, Anweisungen, Referenzdokumente) und die Feedback-Sensoren (Linter, Review-Agenten, Strukturtests), damit es nicht wieder vorkommt. Der Harness ist kein einmaliges Bauwerk, sondern ein System, das mit der Zeit besser wird, während Sie herausfinden, was das Modell falsch macht.
Der eigentliche Punkt
Das Konzept Harness ist die Erkenntnis, dass Modellintelligenz und Systemfähigkeit zwei verschiedene Dinge sind und dass in der Lücke dazwischen der größte Teil des Engineering-Werts liegt.
Das ist kein Übergangszustand, der verschwindet, sobald die Modelle klüger werden. LangChains Einordnung ist aufschlussreich: Mit besseren Modellen wird manches, was heute im Harness lebt (Planung, Selbstprüfung, Kohärenz über lange Zeiträume), ins Modell wandern. Das schafft den Harness aber nicht ab. Es verschiebt, was er tut. So wie Prompt Engineering nicht verschwand, als Modelle Anweisungen besser befolgten, wird auch Harness Engineering nicht verschwinden, wenn Modelle ihren eigenen Kontext besser verwalten. Die Schnittstelle zwischen Modell und Welt braucht immer ein System, das sie verwaltet.
Die Formel sollten Sie sich einprägen: Agent = Modell + Harness. Wenn jemand sagt: „Ich habe einen Agenten gebaut“, meint er, dass er einen Harness gebaut und auf ein Modell gerichtet hat. Das Modell steht allen zur Verfügung. Im Harness liegt der Unterschied.
Aus dem Englischen übersetzt: zum Originalbeitrag