Harness-Engineering: Der vollständige Leitfaden zum Aufbau von Systemen, mit denen KI-Agenten tatsächlich funktionieren
März 2026 — Wenn 2025 das Jahr war, in dem KI-Agenten bewiesen, dass sie Code schreiben können, dann ist 2026 das Jahr, in dem wir gelernt haben, dass nicht der Agent der schwierige Teil ist – sondern der Harness.
Das Codex-Team von OpenAI hat gerade eine Produktionsanwendung mit über 1 Million Zeilen Code erstellt, bei der keine einzige Zeile von Menschenhand geschrieben wurde. Die Ingenieure schrieben keinen Code. Sie entwarfen das System, das es der KI ermöglichte, Code zuverlässig zu schreiben. Dieses System – die Einschränkungen, Feedbackschleifen, Dokumentationen, Linter und das Lifecycle-Management – ist das, was die Branche heute als Harness bezeichnet.
Harness-Engineering ist die neue Disziplin des Entwerfens dieser Systeme. Und es verändert die Bedeutung dessen, was es heißt, ein Softwareentwickler zu sein.
Was ist Harness-Engineering?
Die Pferde-Metapher
Der Begriff "Harness" (Geschirr) stammt aus dem Reitsport – Zügel, Sattel, Gebiss – die komplette Ausrüstung, um ein kraftvolles, aber unvorhersehbares Tier in die richtige Richtung zu lenken. Die Metapher ist bewusst gewählt:
- Das Pferd ist das KI-Modell – kraftvoll, schnell, aber es weiß von allein nicht, wohin es gehen soll.
- Der Harness ist die Infrastruktur – Einschränkungen, Leitplanken, Feedbackschleifen, die die Kraft des Modells produktiv kanalisieren.
- Der Reiter ist der menschliche Ingenieur – er gibt die Richtung vor, rennt aber nicht selbst.
Ohne einen Harness ist ein KI-Agent wie ein Vollblut auf offenem Feld. Schnell, beeindruckend und völlig nutzlos, um irgendetwas zu erledigen.
Die formale Definition
Harness-Engineering ist das Design und die Implementierung von Systemen, die:
- Beschränken, was ein KI-Agent tun kann (architektonische Grenzen, Abhängigkeitsregeln).
- Den Agenten darüber Informieren, was er tun soll (Context-Engineering, Dokumentation).
- Verifizieren, dass der Agent es korrekt ausgeführt hat (Tests, Linting, CI-Validierung).
- Den Agenten Korrigieren, wenn etwas schiefgeht (Feedbackschleifen, Selbstreparaturmechanismen).
Martin Fowler beschreibt es als "die Werkzeuge und Praktiken, die wir verwenden können, um KI-Agenten unter Kontrolle zu halten" – aber es ist mehr als nur Sicherheit. Ein guter Harness macht Agenten leistungsfähiger, nicht nur kontrollierter.
Warum Harness-Engineering jetzt wichtig ist
Das Modell ist Massenware. Der Harness ist der Wettbewerbsvorteil.
Hier ist die unbequeme Wahrheit, mit der die KI-Branche konfrontiert wird: Das zugrunde liegende Modell ist weniger wichtig als das System darum herum.
LangChain hat dies definitiv bewiesen. Ihr Coding-Agent verbesserte sich bei Terminal Bench 2.0 von 52,8 % auf 66,5 % – ein Sprung von den Top 30 in die Top 5 –, ohne dass am Modell etwas geändert wurde. Sie änderten nur den Harness:
| Änderung | Maßnahme | Auswirkung |
|---|---|---|
| Selbstverifizierungsschleife | Pre-Completion-Checklist-Middleware hinzugefügt | Fehler vor der Übermittlung abgefangen |
| Context-Engineering | Verzeichnisstrukturen beim Start gemappt | Agent verstand die Codebasis von Anfang an |
| Schleifenerkennung | Wiederholte Dateiänderungen verfolgt | "Doom Loops" verhindert |
| Reasoning-Sandwich | Hohes Reasoning für Planung/Verifizierung, mittleres für Implementierung | Bessere Qualität innerhalb des Zeitbudgets |
Gleiches Modell. Unterschiedlicher Harness. Dramatisch bessere Ergebnisse.
OpenAIs 1-Million-Zeilen-Beweis
Das Experiment von OpenAI ist der bisher überzeugendste Beweis:
- 5 Monate Entwicklungszeit
- Über 1 Million Zeilen Code im Endprodukt
- Null manuell geschriebene Zeilen — jede Zeile wurde von Codex-Agenten produziert
- Erstellt in ~1/10 der Zeit, die Menschen benötigt hätten
- Das Produkt hat interne tägliche Nutzer und externe Alpha-Tester
- Es wird ausgeliefert, bereitgestellt, geht kaputt und wird repariert — alles durch Agenten innerhalb des Harness
Der Job der Ingenieure? Den Harness entwerfen. Absichten spezifizieren. Feedback geben. Keinen Code schreiben.
Die drei Säulen des Harness-Engineerings
Das Framework von OpenAI unterteilt Harness-Engineering in drei Kernkategorien:
1. Context-Engineering
Beim Context-Engineering geht es darum, sicherzustellen, dass der Agent zur richtigen Zeit über die richtigen Informationen verfügt.
Statischer Kontext:
- Repository-lokale Dokumentation (Architekturspezifikationen, API-Verträge, Styleguides)
AGENTS.md- oderCLAUDE.md-Dateien, die projektspezifische Regeln kodieren- Querverlinkte Designdokumente, die von Lintern validiert werden
Dynamischer Kontext:
- Observability-Daten (Logs, Metriken, Traces), auf die Agenten zugreifen können
- Mapping der Verzeichnisstruktur beim Start des Agenten
- CI/CD-Pipeline-Status und Testergebnisse
Die entscheidende Regel: Aus der Sicht des Agenten existiert nichts, auf das er nicht im Kontext zugreifen kann. Wissen in Google Docs, Slack-Threads oder in den Köpfen der Leute ist für das System unsichtbar. Das Repository muss die "Single Source of Truth" sein.
2. Architektonische Einschränkungen
Hier unterscheidet sich Harness-Engineering am deutlichsten vom traditionellen KI-Prompting. Anstatt dem Agenten zu sagen "schreibe guten Code", erzwingen Sie mechanisch, wie guter Code aussieht.
Abhängigkeitsschichten:
Types → Config → Repo → Service → Runtime → UI
Jede Schicht darf nur aus Schichten zu ihrer Linken importieren. Dies ist kein Vorschlag – es wird durch Strukturtests und CI-Validierung erzwungen.
Tools zur Durchsetzung von Einschränkungen:
- Deterministische Linter — Benutzerdefinierte Regeln, die Verstöße automatisch markieren
- LLM-basierte Auditoren — Agenten, die den Code anderer Agenten auf architektonische Konformität prüfen
- Strukturtests — Wie ArchUnit, aber für KI-generierten Code
- Pre-commit Hooks — Automatisierte Prüfungen, bevor Code festgeschrieben wird
Warum Einschränkungen die Ergebnisse verbessern: Paradoxerweise macht die Einschränkung des Lösungsraums Agenten produktiver, nicht weniger. Wenn ein Agent alles generieren kann, verschwendet er Token mit dem Erkunden von Sackgassen. Wenn der Harness klare Grenzen definiert, konvergiert der Agent schneller bei korrekten Lösungen.
3. Entropie-Management ("Garbage Collection")
Dies ist die am meisten unterschätzte Komponente. Im Laufe der Zeit sammeln KI-generierte Codebasen Entropie an – Dokumentation weicht von der Realität ab, Namenskonventionen divergieren, toter Code sammelt sich an.
Harness-Engineering adressiert dies mit periodischen Cleanup-Agenten:
- Dokumentations-Konsistenz-Agenten — Überprüfen, ob die Dokumente zum aktuellen Code passen
- Scans auf Verstöße gegen Einschränkungen — Finden von Code, der durch frühere Prüfungen geschlüpft ist
- Pattern-Enforcement-Agenten — Identifizieren und Beheben von Abweichungen von etablierten Mustern
- Abhängigkeits-Auditoren — Verfolgen und Auflösen von zirkulären oder unnötigen Abhängigkeiten
Diese Agenten laufen nach Zeitplan – täglich, wöchentlich oder ausgelöst durch bestimmte Ereignisse – und halten die Codebasis sowohl für menschliche Reviewer als auch für zukünftige KI-Agenten gesund.
Harness-Engineering in der Praxis: Wie Teams es tatsächlich machen
Der OpenAI-Ansatz: Null menschlicher Code
Die Teamstruktur von OpenAI für das Harness-Engineering:
| Rolle | Traditionell | Harness-Engineering |
|---|---|---|
| Code schreiben | Hauptaufgabe | Nie |
| Architektur entwerfen | Teil der Aufgabe | Hauptaufgabe |
| Dokumentation schreiben | Nebensache | Kritische Infrastruktur |
| PRs reviewen | Code-Review | Review des Agenten-Outputs + Harness-Effektivität |
| Debugging | Code lesen | Analyse von Agenten-Verhaltensmustern |
| Testen | Tests schreiben | Entwurf von Teststrategien, die Agenten ausführen |
Der Stripe-Ansatz: Minions in großem Maßstab
Die internen Coding-Agenten von Stripe, genannt Minions, produzieren mittlerweile über 1.000 gemergte Pull Requests pro Woche:
- Entwickler postet eine Aufgabe in Slack
- Minion schreibt den Code
- Minion besteht die CI
- Minion öffnet einen PR
- Mensch reviewt und mergt
Keine Interaktion des Entwicklers zwischen Schritt 1 und Schritt 5. Der Harness erledigt alles – Testausführung, CI-Validierung, Einhaltung des Stils und Aktualisierung der Dokumentation.
Der LangChain-Ansatz: Middleware-First
LangChain strukturiert seinen Harness als zusammensetzbare Middleware-Schichten:
Agent Request
→ LocalContextMiddleware (maps codebase)
→ LoopDetectionMiddleware (prevents repetition)
→ ReasoningSandwichMiddleware (optimizes compute)
→ PreCompletionChecklistMiddleware (enforces verification)
→ Agent Response
Jede Middleware-Schicht fügt eine spezifische Fähigkeit hinzu, ohne die Kernlogik des Agenten zu ändern. Dieser modulare Ansatz macht den Harness testbar und entwicklungsfähig.
Aufbau Ihres ersten Harness: Ein praktisches Framework
Level 1: Basis-Harness (Einzelentwickler)
Wenn Sie Claude Code, Cursor oder Codex für einzelne Projekte verwenden:
Was einzurichten ist:
CLAUDE.md- oder.cursorrules-Datei mit Projektkonventionen- Pre-commit Hooks für Linting und Formatierung
- Eine Testsuite, die der Agent zur Selbstverifizierung ausführen kann
- Klare Verzeichnisstruktur mit konsistenter Benennung
Einrichtungszeit: 1-2 Stunden Auswirkung: Verhindert die häufigsten Fehler von Agenten
Level 2: Team-Harness (Kleines Team)
Für Teams von 3-10 Entwicklern, die sich eine Codebasis teilen:
Zusätzlich zu Level 1:
AGENTS.mdmit teamweiten Konventionen- Architektonische Einschränkungen, die durch CI erzwungen werden
- Gemeinsame Prompt-Vorlagen für Standardaufgaben
- Dokumentation-als-Code, validiert durch Linter
- Checklisten für Code-Reviews speziell für von Agenten generierte PRs
Einrichtungszeit: 1-2 Tage Auswirkung: Konsistentes Agentenverhalten im gesamten Team
Level 3: Produktions-Harness (Engineering-Organisation)
Für Organisationen, die Dutzende von gleichzeitigen Agenten einsetzen:
Zusätzlich zu Level 2:
- Benutzerdefinierte Middleware-Schichten (Schleifenerkennung, Reasoning-Optimierung)
- Observability-Integration (Agenten lesen Logs und Metriken)
- Entropie-Management-Agenten in geplanten Läufen
- Harness-Versionierung und A/B-Tests
- Dashboards zur Überwachung der Agentenleistung
- Eskalationsrichtlinien für den Fall, dass Agenten feststecken
Einrichtungszeit: 1-2 Wochen Auswirkung: Agenten agieren als autonome Mitarbeiter
Häufige Fehler beim Harness-Engineering
1. Über-Engineering des Control-Flows
"Wenn Sie den Control-Flow über-engineeren, wird das nächste Modell-Update Ihr System zerstören."
Modelle verbessern sich rasant. Fähigkeiten, die 2024 komplexe Pipelines erforderten, werden heute durch einen einzigen Prompt im Kontextfenster erledigt. Bauen Sie Ihren Harness so auf, dass er modular ("rippable") ist – Sie sollten in der Lage sein, "smarte" Logik zu entfernen, wenn das Modell intelligent genug wird, um sie nicht mehr zu benötigen.
2. Den Harness als statisch betrachten
Der Harness muss sich mit dem Modell weiterentwickeln. Wenn ein neues Modell-Release das Reasoning verbessert, könnte Ihre Middleware zur Reasoning-Optimierung kontraproduktiv werden. Überprüfen und aktualisieren Sie Harness-Komponenten bei jedem größeren Modell-Update.
3. Ignorieren der Dokumentationsschicht
Die wirkungsvollste Harness-Verbesserung ist oft die einfachste: bessere Dokumentation. Wenn Ihre AGENTS.md vage ist, wird auch der Output Ihres Agenten vage sein. Investieren Sie in präzise, maschinenlesbare Dokumentation, die dem Agenten als "Ground Truth" dient.
4. Fehlende Feedbackschleife
Ein Harness ohne Feedback ist ein Käfig, kein Wegweiser. Der Agent muss wissen, wann er erfolgreich ist und wann er scheitert. Bauen Sie ein:
- Selbstverifizierungsschritte vor dem Abschluss der Aufgabe
- Testausführung als Teil des Agenten-Workflows
- Metriken über die Erfolgsraten der Agenten nach Aufgabentyp
5. Rein menschliche Dokumentation
Wenn Ihre architektonischen Entscheidungen in den Köpfen der Leute oder auf Confluence-Seiten leben, auf die der Agent nicht zugreifen kann, hat der Harness eine Lücke. Alles, was der Agent benötigt, muss sich im Repository befinden.
Harness-Engineering vs. verwandte Konzepte
| Konzept | Umfang | Fokus |
|---|---|---|
| Prompt-Engineering | Einzelne Interaktion | Erstellung effektiver Prompts |
| Context-Engineering | Modell-Kontextfenster | Welche Informationen das Modell sieht |
| Harness-Engineering | Gesamtes Agentensystem | Umgebung, Einschränkungen, Feedback, Lebenszyklus |
| Agent-Engineering | Agenten-Architektur | Internes Agenten-Design und Routing |
| Platform-Engineering | Infrastruktur | Bereitstellung, Skalierung, Betrieb |
Harness-Engineering beinhaltet Context-Engineering und nutzt Erkenntnisse aus dem Prompt-Engineering, operiert aber auf einer höheren Ebene – es geht um das vollständige System, das Agenten zuverlässig macht, nicht nur um die Eingaben für eine einzelne Interaktion.
Was das für Softwareentwickler bedeutet
Das Berufsbild ändert sich
Harness-Engineering stellt eine echte Evolution in der Tätigkeit von Softwareentwicklern dar:
| Vorher | Nachher |
|---|---|
| Code schreiben | Umgebungen entwerfen, in denen KI Code schreibt |
| Code debuggen | Agentenverhalten debuggen |
| Code reviewen | Agenten-Output + Harness-Effektivität reviewen |
| Tests schreiben | Teststrategien entwerfen |
| Dokumentation pflegen | Dokumentation als maschinenlesbare Infrastruktur aufbauen |
Dies bedeutet nicht, dass Ingenieure weniger technisch werden. Im Gegenteil, Harness-Engineering erfordert tieferes architektonisches Denken – Sie entwerfen Systeme, die ohne Ihr ständiges Eingreifen funktionieren müssen.
Die Fähigkeiten, auf die es ankommt
Basierend auf unseren Erfahrungen beim Aufbau von KI-gestützten Produkten bei NxCode:
- Systemdenken — Verstehen, wie Einschränkungen, Feedbackschleifen und Dokumentation interagieren
- Architektur-Design — Definieren von Grenzen, die durchsetzbar und produktiv sind
- Schreiben von Spezifikationen — Absichten so präzise formulieren, dass Agenten sie ausführen können
- Observability — Aufbau von Monitoring, das Agenten-Verhaltensmuster offenbart
- Iterationsgeschwindigkeit — Schnelles Testen und Verfeinern von Harness-Konfigurationen
Unsere Erfahrung: Was in der Praxis funktioniert
Wir haben KI-gestützte Webanwendungen mit verschiedenen Agentensystemen (Claude Code, Codex, Cursor) entwickelt. Die Muster, die für uns den größten Unterschied gemacht haben:
- Repository-First-Dokumentation: Jede architektonische Entscheidung, Namenskonvention und jeder Deployment-Prozess steht im Repo. Nichts lebt in Slack oder Google Docs.
- Inkrementeller Aufbau von Einschränkungen: Beginnen Sie mit einfachem Linting, fügen Sie architektonische Einschränkungen hinzu, wenn sich Muster abzeichnen, und versuchen Sie nicht, den perfekten Harness im Voraus zu entwerfen.
- Agenten-spezifische Review-Checklisten: KI-generierter Code hat andere Fehlermuster als menschlicher Code. Unser Review-Prozess berücksichtigt häufige Agenten-Muster (Überabstraktion, unnötige Fehlerbehandlung, Dokumentations-Drift).
- Multi-Provider-Harness-Design: Unser Harness funktioniert mit Claude-, GPT- und Gemini-Modellen. Provider-agnostisches Design bedeutet, dass wir Modelle wechseln können, ohne das gesamte System neu aufbauen zu müssen.
Wichtigste Erkenntnisse
- Harness-Engineering ist die neue Disziplin des Entwerfens von Systemen, die KI-Agenten zuverlässig machen – Einschränkungen, Feedbackschleifen, Dokumentation und Lebenszyklusmanagement.
- Das Modell ist Massenware; der Harness ist der Wettbewerbsvorteil — LangChain sprang in Benchmarks von den Top 30 in die Top 5, indem nur der Harness geändert wurde.
- OpenAI erstellte über 1 Mio. Zeilen ohne menschlichen Code — ein Beweis dafür, dass Harness-Engineering im Produktionsmaßstab funktioniert.
- Drei Säulen: Context-Engineering, architektonische Einschränkungen und Entropie-Management.
- Einfach anfangen: Eine gute
AGENTS.mdund Pre-commit Hooks sind wirkungsvoller als komplexe Middleware. - Die Rolle des Ingenieurs entwickelt sich weiter — vom Schreiben von Code zum Entwerfen von Umgebungen, in denen KI Code schreibt.
- Modularität bewahren — Über-Engineering rächt sich, wenn Modelle besser werden; halten Sie das System anpassungsfähig.
Verwandte Ressourcen
- Das Agentic Web erklärt: AGENTS.md, MCP vs. A2A — Die Protokollschicht, auf der Harness-Engineering aufbaut
- Cursor Cloud Agents: Autonomes Codieren auf virtuellen Maschinen — Cloud-basierte Agenten-Harnesses in der Praxis
- Claude Code Remote Control: Terminal Handoff Guide — Agenten-Sitzungen remote verwalten
- Erstellen Sie Ihre Website mit NxCode — KI-gestützte Webentwicklung mit Multi-Provider-Harness-Architektur
