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

"Prompt Engineering ist tot" — dieser Refrain ging ab 2025 die Runde. An seine Stelle trat das Konzept des "Harness Engineering." Geprägt von Anthropic-Forschern und den Ingenieuren hinter Agenten wie Claude Code und Cursor, hat es sich rasch zu einer der zentralen Engineering-Disziplinen der KI-Agenten-Ära entwickelt.

Dieser Artikel erklärt, was Harness Engineering wirklich ist, wie es sich von Prompt Engineering unterscheidet, welche sechs Komponenten ein Harness ausmachen, eine praktische Design-Checkliste und konkrete Beispiele aus den führenden Tools von heute — die Grundlage, die du brauchst, wenn du es ernst meinst mit dem Einsatz oder Bau von KI-Agenten.

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.

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.

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: gefährliche Operationen erfordern menschliche Bestätigung (z. B. Plan Mode in Claude Code).
• 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. Die Decke der reinen LLM-Fähigkeit ist in Sicht. Mit Modellen der GPT-5-Klasse, Claude Opus 4.7 und Gemini 3.1 Pro im Markt haben Benchmark-Zugewinne begonnen, sich zu verflachen. Die reale Performance eines fixen Modells kann je nach Harness um den Faktor 2 oder mehr schwanken — wir sind also in eine Ära eingetreten, in der der Harness-Wechsel mehr bringt als der Modell-Wechsel.

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. Der Engpass für produktive KI-Agenten hat sich auf den Harness verlagert. 2024 war das Rennen, LLMs schlauer zu machen. 2025 bis 2026 ist das Rennen, Harnesses schlauer zu machen. Jedes große Produkt — Anthropics Claude Code, OpenAIs Codex, Cursor, Devin — konkurriert auf der Ebene des Harness Engineering.

5. Eine praktische Harness-Design-Checkliste

6. 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.

7. Anti-Patterns

1. Zu viele Tools hinzufügen

Sobald du etwa 20 Tools überschreitest, schießt die Wahrscheinlichkeit, dass das LLM das falsche wählt, in die Höhe. Sei rigoros darin, nur die Tools zu behalten, die du wirklich brauchst, und ähnliche zusammenzufassen.

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.

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 seine Konfiguration tweakst. Schreib eine CLAUDE.md / .cursor/rules. Probier Hooks aus. Bau einen Slash Command. Das ist Hands-on-Erfahrung damit, was ein Harness wirklich 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?

Anzeichen sind bereits da. Anthropic, OpenAI, Cursor und andere Agent-Bauer haben begonnen, Rollen wie "Agent Engineer," "Tool Designer" und "Context Engineer" auszuschreiben. Bis 2027 oder 2028 dürfte sich das als eigene, klar abgegrenzte Berufskategorie etablieren.