Was ist Harness Engineering? Die Schicht um das LLM in der KI-Agenten-Ära gestalten

Harness Engineering ist ein Begriff, der sich im Februar 2026 verbreitet hat. Am 5. Februar 2026 nannte Mitchell Hashimoto (Entwickler des Terminals Ghostty und Mitgründer von HashiCorp) damit eine Gewohnheit: Jedes Mal, wenn ein Agent einen Fehler macht, baut man eine Lösung, damit er diesen Fehler nie wieder macht. Sechs Tage später setzte OpenAI den Begriff in den Titel eines Berichts seines Codex-Teams. Anthropic veröffentlichte schon vorher unter dem Namen „Harness“ Entwürfe für die Mechanik rund um lang laufende Agenten. Wenn 2025 galt, dass nach den Prompts Context Engineering kommt, dann behandelt Harness Engineering die Schicht noch weiter außen.

Dieser Artikel erklärt, was Harness Engineering tatsächlich ist, wie es sich von Prompt und Context Engineering unterscheidet, die sechs Komponenten eines Harness, reale Harnesses, die OpenAI und Anthropic veröffentlicht haben, eine praktische Design-Checkliste und einen Vergleich der führenden Tools — das Fundament, das du brauchst, wenn du KI-Agenten ernsthaft nutzen oder bauen willst.

1. Was ist Harness Engineering?

"Harness" bezeichnet ursprünglich das Geschirr und die Ausrüstung eines Pferdes — die Vorrichtung, die die Kraft des Tieres in die gewünschte Richtung lenkt. Der Begriff in der KI funktioniert genau als dieselbe Metapher: die gesamte Ausrüstung, die ein mächtiges, aber unbändiges LLM zu produktiver Arbeit bringt.

Konkret umfasst das:

• Tools: Dateioperationen, Web-Suche, Code-Ausführung — die Mittel, mit denen das LLM handeln kann.
• Kontextmanagement: die Strategie dafür, was in den Prompt kommt und was komprimiert oder verworfen wird.
• Memory-Systeme: dauerhaftes Wissen und Nutzerpräferenzen, die Sessions überdauern.
• Agent-Loop: der Zyklus aus Wahrnehmen → Denken → Handeln → Beobachten.
• Guardrails: Berechtigungen, Sandbox, Hooks, Approval-Flows.
• Output-Format: Markdown, JSON, Quellenangaben, Streaming.

All das gemeinsam zu entwerfen, nennen wir Harness Engineering. Statt das LLM selbst zu trainieren oder zu verbessern, ist es das Handwerk, den realen Nutzwert zu steigern, indem alles um das LLM herum gestaltet wird. Claude Code, Cursor, Devin, Codex CLI — sie alle laufen auf etwa denselben Modellen, doch ihr Verhalten und ihre Performance gehen scharf auseinander, weil sich ihre Harnesses unterscheiden.

Wo das Wort „Harness“ anfängt und aufhört, hat Birgitta Böckeler von Thoughtworks auf martinfowler.com (2. April 2026) gut zusammengefasst: Der Harness ist alles an einem Agenten außer dem Modell, also Agent = Model + Harness. Anthropic verwendet dasselbe Wort für den eigenen Cloud-Dienst: Claude Managed Agents wird als konfigurierbarer Agenten-Harness beschrieben.

2. Harness Engineering vs. Prompt Engineering

Prompt Engineering ist nicht verschwunden — aber der Geltungsbereich ist grundlegend anders.

Wenn Prompt Engineering das Handwerk ist, "was man dem LLM sagt," dann ist Harness Engineering das Handwerk, "was man dem LLM gibt und wie man es betreibt." Die beiden konkurrieren nicht — sie sind geschichtet. Der Prompt ist nur eine Komponente innerhalb des Harness.

Der andere Begriff, der oft verwechselt wird, ist Context Engineering. In einem Beitrag vom 29. September 2025 nannte Anthropic es die natürliche Weiterentwicklung des Prompt Engineering. Böckeler beschreibt den Bau eines Harness für einen Coding-Agenten als eine bestimmte Form von Context Engineering. Zusammen ergeben sie eine Verschachtelung: Prompt (was man sagt) ⊂ Kontext (was das Modell sieht) ⊂ Harness (was es bekommt, wie seine Arbeit geprüft und wie es gestoppt wird). Eigen ist dem Harness der Teil, der Ergebnisse maschinell prüft und Fehler an den Agenten zurückgibt — etwa Linter und Tests.

3. Die 6 Komponenten eines Harness

1. Tool Use

Die Mittel des LLM, auf die Welt einzuwirken: Dateien lesen und schreiben, Code ausführen, das Web durchsuchen, APIs aufrufen. Stimmt die Tool-Schnittstelle nicht — Namen, Argumente, Rückgabewerte —, kann das LLM sie nicht korrekt nutzen. Konkret:

• Verb-basierte, eindeutige Namen (z. B. read_file).
• Pflicht- vs. optionale Argumente klar trennen, mit Defaults.
• Strukturierte Fehlermeldungen bei Fehlschlägen (sag dem Modell, was als Nächstes zu tun ist).
• Explizite Warnungen bei Operationen mit Seiteneffekten (destruktiven Operationen).

2. Kontextmanagement

Die Aufmerksamkeit des LLM ist endlich — was du ihm zeigst, bestimmt, was es sagt. Konkret:

• Relevanzfilterung: nur die für die Aufgabe relevanten Teile einspielen, nicht ganze Dateien.
• Verdichtung: lange Konversationen zusammenfassen, um sie zu erhalten.
• RAG-Integration: Bedarfsgerecht via Vektorsuche abrufen.
• Caching: Kosten bei wiederholten System-Prompts mit Tools wie Anthropics Prompt-Cache senken.

Verwandt: Was ist RAG?

3. Memory-System

Wissen über Sessions hinweg vorhalten. Claude Codes CLAUDE.md, Cursors .cursor/rules und Codex' AGENTS.md sind alles Beispiele für Projekt-Memory. Darüber hinaus:

• Kurzzeit-Memory: jüngste Konversationsverlauf.
• Langzeit-Memory: Nutzerprofil, vergangene Entscheidungen.
• Faktenwissen: domänenspezifische Wissensbasen.

4. Agent-Loop

Der Kern, der einen "KI-Agenten" tatsächlich funktionieren lässt. Die Grundform ist der Zyklus Wahrnehmen → Denken → Handeln → Beobachten:

1. Das Ziel des Nutzers entgegennehmen.
2. Den aktuellen Zustand analysieren (bei Bedarf Informationen mit Tools sammeln).
3. Die nächste Aktion planen.
4. Per Tool handeln.
5. Das Ergebnis beobachten; prüfen, ob das Ziel erreicht ist.
6. Wenn nicht, schleifen; wenn ja, beenden.

Wie schlau dein Agent wird, hängt davon ab, ob du Replanning, Selbstkritik und Subziel-Zerlegung einbaust.

5. Guardrails

Die Mechanismen, die entgleitendes Verhalten verhindern. Wie Warum KI deine .md-Regeln ignoriert erklärt, ist es weit zuverlässiger, Verhalten über die Umgebung zu erzwingen, als in Prosa höflich zu bitten:

• Approval-Modus: Ein Mensch bestätigt, bevor gefährliche Operationen laufen (z. B. die Berechtigungseinstellungen von Claude Code, die Approval-Modi von Codex CLI).
• Sandbox: Dateisystem- und Netzwerkzugriff einschränken.
• Hooks: beliebige Prüfungen vor und nach Tool-Aufrufen.
• Rate Limiting: Schaden minimieren, falls etwas aus dem Ruder läuft.

6. Output-UX

Ergebnisse in einer Form präsentieren, die der Nutzer verstehen und verifizieren kann. Markdown-Rendering, Quellenangaben, syntax-hervorgehobene Code-Blöcke, Streaming-Output, sichtbares Reasoning (Thinking), strukturierter Output (JSON) und so weiter. Die "richtige Antwort" zu produzieren reicht nicht — es ist die Aufgabe des Harness, sie in einer Form zu liefern, der der Nutzer trauen und die er prüfen kann.

4. Warum Harness Engineering, warum jetzt?

Drei Kräfte treiben den schubhaften Anstieg des Interesses an Harness-Arbeit.

1. Es wurde gezeigt, dass dasselbe Modell je nach Umgebung sehr unterschiedliche Ergebnisse liefert. In einem Experiment, das Anthropic am 24. März 2026 veröffentlichte, bekam dasselbe Claude-Opus-Modell in einem einzigen Satz den Auftrag, einen 2D-Retro-Spieleeditor zu bauen. Ein einzelner Agent war nach 20 Minuten für 9 $ fertig, aber das erzeugte Level ließ sich nicht spielen. Ein Harness aus Planer, Generator und Evaluator lief 6 Stunden und kostete 200 $ — und lieferte ein Spiel, in dem man die Figur tatsächlich bewegen konnte (die Physik blieb holprig). Die Kosten lagen über dem 20-Fachen, der Qualitätsunterschied aber auch. Die Wahl zwischen Qualität und Kosten ist heute ebenso eine Harness- wie eine Modellentscheidung.

2. Probleme, die Prompts allein nicht lösen, häufen sich. "Zu viele Tools, das Modell wählt das falsche." "Der Kontext ist so vollgestopft, dass das wichtige Signal untergeht." "Bei langlaufenden Aufgaben verliert der Agent auf halber Strecke den Faden." Das sind keine Probleme, die du mit cleveren Formulierungen in einer einzigen Runde löst — es sind Design-Probleme.

3. Die Arbeit von Engineers selbst beginnt sich zu verändern. Das Codex-Team von OpenAI berichtete, fünf Monate lang ein internes Produkt ohne eine einzige von Hand geschriebene Codezeile gebaut zu haben — bis zu rund einer Million Zeilen und rund 1.500 Pull Requests (11. Februar 2026). Das Fazit: Die Hauptarbeit hat sich vom Codeschreiben zu Umgebungen entwerfen, Absicht festlegen und Feedback-Schleifen bauen verlagert. Claude Code, Codex, Cursor, Devin und die anderen großen Produkte konkurrieren über das Design außerhalb des Modells.

5. Veröffentlichte Beispiele: drei reale Harnesses

Harness Engineering bleibt leicht abstrakt. Hier sind drei Beispiele, deren Macher die Details veröffentlicht haben — beschrieben auf der Ebene dessen, was sie tatsächlich getan haben.

1. Das Codex-Team von OpenAI: AGENTS.md als Landkarte, Regeln per Linter erzwungen

• Sie hielten AGENTS.md als Inhaltsverzeichnis von etwa 100 Zeilen und machten ein docs/-Verzeichnis im Repository zur maßgeblichen Quelle für Design, Pläne und Qualitätsnotizen. Eine einzige Riesendatei verdrängte die Aufgabe aus dem Kontext, veraltete schnell und ließ sich nicht maschinell prüfen.
• Damit die Doku aktuell bleibt, prüfen Linter und CI Querverweise und Struktur, und ein wiederkehrender Agent sucht nach Beschreibungen, die nicht mehr zum Code passen, und öffnet Korrektur-PRs.
• Schichtung, Abhängigkeitsrichtung, strukturiertes Logging, maximale Dateigröße und mehr werden durch eigene Linter und Strukturtests erzwungen. Die Fehlermeldungen schreiben aus, wie man das Problem behebt, damit der Agent sie liest und die eigene Arbeit repariert.

2. Anthropic: die Übergabe bei lang laufenden Agenten gestalten

Wenn die Entwicklung viele Kontextfenster überspannt, wollten Agenten zu viel auf einmal bauen oder erklärten die Arbeit auf halber Strecke für fertig. Anthropic (26. November 2025) löste das so:

• Nur die erste Session startet einen Initializer-Agenten mit eigenem Prompt. Er legt eine Feature-Liste (feature_list.json), ein Fortschrittsprotokoll (claude-progress.txt), ein init.sh zum Starten des Dev-Servers und einen ersten Git-Commit an.
• Jede spätere Session liest Fortschrittsprotokoll und git log, um sich zu orientieren, setzt nur ein einziges Feature um und endet mit einem Commit und einem Protokoll-Update.
• Die Feature-Liste ist JSON statt Markdown, weil das Modell sie seltener unzulässig umschrieb. Ändern darf es nur das Bestanden/Nicht-bestanden-Feld (passes).
• Ein Feature gilt erst als fertig, wenn es per Browser-Automatisierung durchgängig getestet wurde, so wie ein Nutzer es tun würde.

3. Mitchell Hashimoto: denselben Fehler nie zweimal zulassen

Der Namensgeber arbeitet in kleinerem Maßstab. Macht der Agent einen einfachen Fehler, fügt er eine Zeile in AGENTS.md hinzu; im Projekt seines Terminals Ghostty entspricht jede Zeile dieser Datei einem früheren Fehlverhalten, und damit waren sie fast alle behoben. Reicht Text nicht aus, baut er echte Skripte — für Screenshots, für gefilterte Testläufe — und gibt sie dem Agenten.

Allen drei gemeinsam ist, dass das Gewicht auf Mechanismen liegt, die prüfen und Arbeit zurückgeben, mehr als auf schriftlichen Bitten. Die folgende Checkliste hilft zu entscheiden, wie viel davon man in Mechanik übersetzt.

6. Eine praktische Harness-Design-Checkliste

7. Vergleich der wichtigsten Harnesses

Jeder dieser Harnesses läuft auf mehr oder weniger denselben LLMs (Claude / GPT / Gemini), dennoch divergieren ihre Stärken stark wegen unterschiedlicher Harness-Design-Philosophien. "Welcher Harness?" zählt mehr als "Welches LLM?" — das ist das eigentliche Schlachtfeld der Agenten-Ära.

8. Anti-Patterns

1. Zu viele Tools hinzufügen

Je mehr Tools du hinzufügst, desto leichter wählt das LLM das falsche. Die Dokumentation von Anthropic sagt, dass die Tool-Auswahl von Claude ungenauer wird, sobald mehr als 30–50 Tools verfügbar sind, und bietet die Tool-Suche an, um nur die relevanten Tools bei Bedarf zu laden. Auch der Leitfaden zum Schreiben von Tools betont, dass mehr Tools nicht automatisch bessere Ergebnisse bringen: Statt jeden API-Endpunkt einzeln zu verpacken, fasse ähnliche Funktionen zusammen.

2. Alles in den Kontext stopfen

"Zeig ihm sicherheitshalber einfach alles" ist kontraproduktiv. Lass alles durch einen Relevanzfilter laufen und nimm nur Notwendiges auf. Kontext ist ein Werkzeug, das wichtige Signale hervorhebt — kein Lagerraum.

3. Sicherheit allein über Prompts umsetzen

"Bitte führe keine gefährlichen Operationen aus" wird je nach Situation früher oder später ignoriert. Die richtige Antwort ist, es auf Umgebungsebene physisch unmöglich zu machen — Sandbox, Hooks, Berechtigungs-Limits.

4. Hinzugefügtes nie wieder prüfen

Jedes zusätzliche Teil macht einen Harness schwerer, langsamer und teurer. Nach dem oben genannten Experiment hat Anthropic Komponenten einzeln entfernt und die Ergebnisse verglichen und nur behalten, was noch half (Planer und Evaluator). Der Gedanke dahinter: Jede Komponente eines Harness steht für eine Annahme darüber, was das Modell allein nicht kann — und diese Annahmen veralten schnell, wenn Modelle besser werden. Wenn du das Modell wechselst, prüfe einzeln, ob jede hinzugefügte Kontrolle und jede Aufteilung noch etwas bringt.

Zusammenfassung

Harness Engineering ist das Handwerk, die Schicht "außerhalb" des LLM zu gestalten. Prompt Engineering ist nur eine Komponente innerhalb des Harness. Die sechs Elemente bewusst zu behandeln — Tool-Definition, Kontextmanagement, Memory, Loop, Guardrails, Output-UX — kann die reale Performance desselben zugrundeliegenden LLM transformieren.

Stand 2026 hat sich das Hauptschlachtfeld für produktive KI-Agenten klar zum Harness verlagert. "Schlaue Harnesses" zu bauen — nicht nur "schlaue Prompts" zu schreiben — wird der Differenzierer für die nächste Generation von Engineers sein.

FAQ

F1. Brauchen wir Prompt Engineering also gar nicht mehr?

Falsch. Es bleibt essenziell — als eine Komponente innerhalb des Harness. Tool-Beschreibungen, System-Prompts, Fehlermeldungen — all das sind Flächen für Prompt-Design. Veraltet ist die Haltung "Das fixe ich mit einem besseren Prompt."

F2. Was ist der erste Schritt, um Harness Engineering zu lernen?

Nimm Claude Code oder Cursor und nutze es nicht nur — verändere sein Verhalten, indem du die Konfiguration anpasst. In Schritte übersetzt sieht Hashimotos Vorgehen so aus:

1. Notiere jeden Fehler des Agenten (bei welcher Anweisung, was schiefging).
2. Für einfache Fehler füge eine Zeile in CLAUDE.md / AGENTS.md / .cursor/rules ein.
3. Wiederkehrende oder folgenschwere Fehler stoppst du maschinell mit Hooks, Lintern oder Tests — und schreibst die Lösung in die Fehlermeldung.
4. Lass den Agenten dieselbe Aufgabe noch einmal erledigen und prüfe, ob der Fehler verschwunden ist.

F3. Sind Harnesses dasselbe wie Frameworks à la LangChain?

Nahe dran, aber nicht dasselbe. Ein Framework ist ein Implementierungs-Toolkit; ein Harness ist eine Design-Disziplin und Denkweise. LangChain, LlamaIndex, das Claude Agent SDK und Ähnliches sind Werkzeuge zum Bauen von Harnesses.

F4. Eigenes Harness bauen oder ein bestehendes nutzen?

In den meisten Fällen reicht ein bestehendes Harness (Claude Code, Cursor usw.) plus Customizing. Eines von Grund auf zu bauen, ergibt nur Sinn bei Enterprise-Anforderungen, Nischendomänen oder extremer Kostenoptimierung.

F5. Wird "Harness Engineer" eine echte Berufsbezeichnung?

Eine feste Berufsbezeichnung gibt es noch nicht. Hashimoto selbst schrieb, er wisse nicht, ob es bereits einen branchenweit anerkannten Begriff gebe. Das Codex-Team von OpenAI berichtet aber, dass sich die Hauptarbeit von Engineers zu Umgebungen entwerfen, Absicht festlegen und Feedback-Schleifen bauen verschoben hat — der Inhalt der Arbeit ändert sich, bevor sich ein Titel etabliert.