Harness-Engineering
KI-Modelle können bereits eine Million Codezeilen schreiben. Die eigentliche Herausforderung besteht nicht mehr darin, sie besser schreiben zu lassen, sondernsie so zu steuern, dass sie stabil, zuverlässig und ohne Kontrollverlust arbeiten. Diese Methodik, rund um KI-Agenten Beschränkungsmechanismen, Feedback und Kontrollsysteme aufzubauen, ist das neue Paradigma, das Anfang 2026 die Engineering-Welt schnell erfasste —Harness-Engineering。
1. Was ist Harness Engineering?
Harness Engineeringist die systematische Ingenieurpraxis,Beschränkungsmechanismen, Feedback-Schleifen, Workflow-Steuerung und kontinuierliche Verbesserungszyklenrund um KI-Agenten zu entwerfen und aufzubauen.
Es optimiert nicht das Modell selbst, sondern die Umgebung, in der das Modell arbeitet. Die Kernphilosophie lässt sich in einem Satz zusammenfassen:Mensch steuert, Agent führt aus。
Das Wort „Harness“ stammt aus dem Pferdegeschirr – Zügel, Sattel, Gebiss – einem kompletten Satz Ausrüstung, mit dem man kräftige, aber unberechenbare Tiere lenkt.Harness Engineering bedeutet nicht, die Fähigkeiten der KI zu schwächen, sondern ihr einen goldenen Harness zu schmieden, damit sie schnell und stabil laufen kann.
Dieses Konzept wurde erstmals am 5. Februar 2026 von HashiCorp-Mitbegründer Mitchell Hashimoto vorgeschlagen. Sechs Tage später übernahm OpenAI den Begriff offiziell in seinem Bericht zum Experiment mit einer Million Codezeilen, und Martin Fowler veröffentlichte anschließend eine ausführliche Analyse. Innerhalb eines Monats wurde er in der Entwickler-Community zum Schlagwort.
Harness Engineering ist die Idee, dass man jedes Mal, wenn man feststellt, dass ein Agent einen Fehler macht, sich die Zeit nimmt, eine Lösung zu entwickeln, sodass der Agent diesen Fehler in Zukunft nicht erneut macht.
—— Mitchell Hashimoto
Der Unterton dieser Aussage ist:Jedes Scheitern eines Agenten ist ein Signal dafür, dass das Umgebungsdesign unvollständig ist.Die richtige Reaktion ist nicht, zu einem leistungsfähigeren Modell zu wechseln, sondern die Umgebung neu zu gestalten, in der er operiert.
2. Warum brauchen wir Harness Engineering? Echte Daten sprechen
Der LangChain-Fall ist besonders überzeugend: Kein einziger Parameter des zugrunde liegenden Modells wurde geändert;allein durch die Optimierung der externen Steuerungsumgebung(Dokumentationsstruktur, Verifikationsschleifen, Tracking-System) stieg die Punktzahl des Coding-Agenten auf Terminal Bench 2.0 von 52.8% auf 66.5%, und sein globales Ranking sprang von Platz 30 auf Platz 5.
Fünf unabhängige Teams kamen zum selben Schluss:Der Engpass ist nicht die Intelligenz des Modells, sondern die Infrastruktur.
3. Drei Paradigmenwechsel im AI Engineering
Um zu verstehen, warum Steering Engineering wichtig ist, müssen wir zuerst Schritt für Schritt sehen, wie wir hierher gekommen sind.
| Paradigma | Kernproblem | Optimierungsziel | Interaktionsmodus |
|---|---|---|---|
| Prompt-Engineering | Wie man Dinge klar ausdrückt | Prompt-Formulierung, Format, Beispiele | Frage und Antwort |
| Context Engineering | Wie man der KI Informationen zuführt | Dokumente, Codeausschnitte, Gesprächsverlauf | Informationsinjektion → Generierung |
| Steering Engineering | Wie man Agents zuverlässig arbeiten lässt | Einschränkungen, Feedback-Schleifen, Kontrollsysteme | Menschen steuern, Agents führen aus |
Eine einprägsame Analogie:
- Prompt Engineering —— Die Kunst, einem Pferd Befehle zuzurufen
- Context Engineering —— Die Karte, die dem Pferd gezeigt wird
- Harness Engineering —— Der Bau einer Autobahn für das Pferd, komplett mit Leitplanken, Geschwindigkeitsbegrenzungsschildern und Tankstellen
4. Häufige Fehlermodi von Agenten
Durch lang andauernden Agentenbetrieb haben Anthropic-Ingenieure drei typische Fehlermodi zusammengefasst – genau die zentralen Schmerzpunkte, die Harness Engineering lösen muss:
Fehlermodus 1: One-shotting
Agenten neigen dazu, alle Funktionalität in einer einzigen Sitzung zu implementieren. Das Ergebnis ist ein erschöpftes Kontextfenster, ein Haufen undokumentierter, halbfertiger Code, und die nächste Sitzung muss viel Zeit damit verbringen, zu erraten, was zuvor passiert ist.
Fehlermodus 2: Vorschnelles Erklären des Sieges
Spät in einem Projekt, wenn einige Funktionen fertig sind, schaut sich der Agent um und erklärt angesichts des Fortschritts sofort die Aufgabe für abgeschlossen – obwohl viele Funktionen noch nicht implementiert sind.
Fehlermodus 3: Vorschnelles Markieren von Funktionen als abgeschlossen
Ohne explizite Aufforderung markiert der Agent Code direkt nach dem Schreiben als abgeschlossen, ohne End-to-End-Tests. Bestandene Unit-Tests oder curl-Befehle bedeuten nicht, dass die Funktion tatsächlich funktioniert.
Darüber hinaus haben Agenten eine weitere gefährliche Eigenschaft:Sie sind extrem gut im Kopieren von Mustern. Er repliziert und verstärkt getreu alle Muster, die in der Codebasis vorhanden sind – einschließlich schlechter Muster und Architektur-Drift. Das bedeutet, dass ein uneingeschränkter Agent technische Schulden in alarmierendem Tempo anhäuft.
5. Die vier Leitplanken von Harness Engineering
Mit Rückgriff auf die Praktiken von OpenAI, Anthropic, LangChain und Martin Fowler lässt sich Harness in vier Kernkomponenten zusammenfassen – vier „Leitplanken“:
Leitplanke 1: Kontext-Engineering – Das neue Mitarbeiterhandbuch
Genau wie man einem neuen Mitarbeiter ein detailliertes Arbeitshandbuch gibt, istAGENTS.mdder erste Leitfaden, den ein KI-Agent sieht, wenn er in eine Codebasis eintritt. Aber das ist kein statisches 1.000-seitiges Handbuch – Kontext ist eine knappe Ressource, und zu viel Anleitung verdrängt stattdessen den Platz für Aufgaben, Code und zugehörige Dokumentation, sodass daraus ein Friedhof veralteter Regeln wird.
Ein besserer Ansatz ist: einen stabilen, kompakten Einstiegspunkt bereitzustellen und dann den Agenten zu lehren, je nach aktueller Aufgabe weiteren Kontext abzurufen und einzubeziehen. In Mitchell Hashimotos Ghostty-Projekt entspricht jede Zeile in AGENTS.md einem historischen Agenten-Fehlfall – die Dokumentation ist ein lebendiger Feedbackkreislauf, kein statisches Artefakt.
Leitplanke 2: Architektur-Constraints – Die Zügel
Das OpenAI-Team etablierte ein striktes hierarchisches Abhängigkeitsmodell:
Types → Config → Repo → Service → Runtime → UI
Untere Schichten dürfen keine umgekehrten Abhängigkeiten zu oberen Schichten haben. Alle Architekturregeln sind alsbenutzerdefinierte Linter-Regelnkodiert; ein Verstoß dagegen lässt CI den Merge blockieren – egal, ob der Code von Menschen oder KI geschrieben wurde.
Es gibt ein wichtiges Detail: Auch die Fehlermeldungen des Linters sind Kontext-Engineering. Er sagt nicht nur, dass du gegen Regel X verstoßen hast, sondern erklärt, warum die Regel existiert und was der richtige Ansatz ist, damit der Agent beim Lesen des Fehlers verstehen und sich selbst korrigieren kann, ohne menschliches Eingreifen.
Leitplanke 3: Feedback-Schleife – Agenten überprüfen Agenten
In der traditionellen Entwicklung sind menschliche Ingenieure für Code-Reviews verantwortlich. Im agentischen Engineering wird diese Arbeit zu Agent-zu-Agent: Codex überprüft seine eigenen Änderungen lokal, fordert zusätzliche Überprüfung an und wiederholt den Vorgang, bis er besteht.
Hooks in der Feedback-Schleife können vordefinierte Test-Suites ausführen und bei einem Fehlschlag mit Fehlerinformationen zum Modell zurückkehren oder das Modell auffordern, seinen Code unabhängig zu bewerten. Wenn von KI geschriebene Testfälle Code durchlassen, der Fehler enthält, betrachtet das Harness den Test als ungültig und zwingt es, die Testgrenzen zu überdenken.
Leitplanke 4: Entropiemanagement – Garbage Collection
Mit der Zeit werden Softwaresysteme allmählich chaotisch (die Entropie nimmt zu), und technische Schulden sammeln sich an. OpenAI verfolgt eine Strategie fortlaufender kleiner Rückzahlungen, statt zu warten, bis Probleme ernst werden, um sie zentral zu behandeln – sie bezeichnen diesen Ansatz anschaulich alsGarbage recycling, und glaubt, dass technische Schulden wie ein hochverzinslicher Kredit sind.
Konkrete Maßnahmen: regelmäßig Hintergrund-Codex-Aufgaben ausführen, um nach Abweichungen zu suchen, Qualitätsbewertungen zu aktualisieren und gezielte Refactoring-PRs anzustoßen. Darüber hinaus gibt es auch einen dedizierten...Doc-gardening Agent(Document Gardener Agent), der im Hintergrund automatisch nach Inkonsistenzen zwischen Dokumentation und Code sucht und, wenn er veraltete Inhalte findet, automatisch einen PR zur Korrektur einreicht — Agents, die Dokumentation für Agents pflegen.
6. Sechs branchenweite Konsenspunkte
Basierend auf mehreren unabhängigen Informationsquellen, darunter OpenAI, Anthropic, LangChain, Stripe und HashiCorp, hat die Branche einen klaren Konsens zu den folgenden sechs Aspekten gebildet:
| # | Konsens | Kernaussage |
|---|---|---|
| 1 | Der Engpass liegt in der Infrastruktur, nicht in der Intelligenz der Modelle. | Fünf unabhängige Teams kamen zum selben Schluss. Allein die Änderung des Harness-Tool-Formats kann die Punktzahl des Modells von 6.7% auf 68.3% springen lassen |
| 2 | Dokumentation muss ein lebendiger Feedback-Loop sein | Statische Dokumentation ist ein Friedhof; nur dynamische Dokumentation hat Wert. Hintergrund-Agents sollten regelmäßig veraltete Docs bereinigen und PRs einreichen |
| 3 | Trennung von Denken und Ausführung | Komplexe Aufgaben können nicht in einem einzigen Kontextfenster abgeschlossen werden; eine geschichtete Architektur aus Orchestrator + Worker ist nötig, wobei der Zustand in externem Speicher persistiert wird |
| 4 | Mehr Kontext ist nicht immer besser | Kontext ist eine knappe Ressource. Riesige Instruktionsdateien verdrängen den Aufgabenraum; bei Bedarf abrufen und dynamisch injizieren |
| 5 | Constraints müssen automatisiert werden | Manuelle Überprüfung ist der Engpass. Guardrails sollten als Linter, CI und Typsysteme kodiert werden, sodass Maschinen sie durchsetzen statt Menschen |
| 6 | Die Rolle des Engineers wandelt sich | Vom Code-Schreiber zum Umgebungsarchitekten. Die größte technische Herausforderung ist der Entwurf eines Kontrollsystems, das Agents zuverlässig arbeiten lässt |
7. Die Beziehung zwischen Harness und traditionellen Frameworks
Harness ist kein Ersatz für SDKs, Scaffolds oder Agent-Frameworks, sondern vielmehreine Ebene über ihnen：
Traditionelle Frameworks lösenwie man KI-Agents baut, während die Harness-Schicht ein völlig anderes Problem löst:wie man Agents zuverlässig ausführt。
Modelle absorbieren allmählich etwa 80% der Framework-Funktionalität (Agent-Definition, Nachrichtenrouting, Task-Lebenszyklus...), aber die verbleibenden 20% —Persistenz, deterministisches Replay, Kostenkontrolle, Observability, Fehlerwiederherstellung— sind genau der Wert der Harness-Schicht.
Zusammenfassung
Harness Engineering ist kein Experiment eines einzelnen Unternehmens, sondern ein Paradigmenwechsel, den die gesamte Branche durchläuft.
Birgitta Böckelers Zusammenfassung ist am aufschlussreichsten:
Um eine höhere KI-Autonomie zu erreichen, muss die Laufzeitumgebung strengeren Constraints unterliegen. Mehr Vertrauen erfordert nicht mehr Freiheit, sondern mehr Einschränkungen.
Wie Leitplanken auf einer Autobahn — gerade wegen der Leitplanken traut man sich, es auf 120 km/h zu bringen.
| Kernkomponenten | Gelöste Probleme | Beispielhafte Praktiken |
|---|---|---|
| Kontext-Engineering Kontext | Agent weiß nicht, wonach er suchen soll oder wie er es findet. | AGENTS.md: lebendiges Dokument, Abruf bei Bedarf. |
| Architektur-Constraints Constraints | Agent kopiert und verstärkt schlechte Muster. | Geschichtete Abhängigkeiten, eigener Linter, CI-erzwungene Blockierung |
| Feedback-Loop Feedback | Agent weiß nicht, dass er etwas falsch gemacht hat. | Agent-zu-Agent-Review, automatisierte Testsuite |
| Entropiemanagement Entropie | Technische Schulden und Dokumentationsverfall. | Doc-gardening Agent, kontinuierliche Garbage Collection |
Die Zukunft der Softwareentwicklung dreht sich vielleicht nicht mehr darum, wie schnell und gut wir Code schreiben können, sondern vielmehr darum,wie intelligente und robuste Systeme wir entwerfen können, um die immense Kraft von KI-Agenten zu nutzen?。
Der Wert von Ingenieuren verschiebt sich von Ausführenden hin zu Enablern und Systemdenkern — vom Bauen von Produkten zum Bauen von Fabriken, die Produkte bauen können.