Der Harness

Kapitel 01 nennt das Wort und lässt es stehen: Das Programm um das Modell herum heißt Harness, und seine Teile verteilen sich über die folgenden Kapitel. Hier kommen sie zusammen, samt der Frage, wie viel dieses Drumherum eigentlich ausmacht.

Alles, was nicht das Modell ist

Die Formel, mit der der Begriff heute erklärt wird, ist denkbar knapp:

Agent = Model + Harness (externe Seite, blog.langchain.com)

Und die Abgrenzung dazu ebenso:

A harness is every piece of code, configuration, and execution logic that isn’t the model itself. (externe Seite, blog.langchain.com)

Das Modell kaufen Sie ein. Den Harness bauen Sie. Er ist der Teil, an dem Sie etwas ändern können, ohne auf die nächste Modellgeneration zu warten.

Woraus er besteht

Eine Arbeit vom Mai 2026 zählt die Bestandteile in einer Reihe auf:

the harness: the system layer that manages context, tools, state, constraints, permissions, tracing, and recovery (externe Seite, arxiv.org)

Übersetzt, und in der Reihenfolge, in der man sie beim Bauen antrifft:

• Was der Agent sieht. Die Anweisungen im Projekt (Vibe-Coding / Agentic Engineering, Kapitel 03), was aus früheren Sitzungen bleibt (Vibe-Coding / Agentic Engineering, Kapitel 05), und was er nachschlagen kann (Kapitel 03, Vibe-Coding / Agentic Engineering, Kapitel 06).
• Was er tun darf. Der Satz an Tools (Grundkurs, Kapitel 09), wie sie angebunden sind (Kapitel 02), und welche Rechte daran hängen.
• Wie die Schleife läuft. Wann sie abbricht, was bei einem Fehlschlag passiert, und ob eine Nebenaufgabe ein eigenes Fenster bekommt (Vibe-Coding / Agentic Engineering, Kapitel 09).
• Was danach geprüft wird. Feste Regeln, die immer laufen (Vibe-Coding / Agentic Engineering, Kapitel 08), die Historie als Rückweg (Vibe-Coding / Agentic Engineering, Kapitel 04), und wer das Ergebnis nachrechnet (Vibe-Coding / Agentic Engineering, Kapitel 07).

Jeder dieser Punkte hat ein eigenes Kapitel. Was hier hinzukommt, ist die Beobachtung, dass sie zusammen eine Stellgröße bilden.

Wie viel das ausmacht

Im Februar 2026 hat LangChain den eigenen Coding-Agenten gemessen, bevor und nachdem das Team an der Umgebung gearbeitet hatte:

We used a simple recipe to iteratively improve deepagents-cli (our coding agent) 13.7 points from 52.8 to 66.5 on Terminal Bench 2.0 (externe Seite, blog.langchain.com)

Entscheidend ist der Satz daneben:

We only tweaked the harness and kept the model fixed (externe Seite, blog.langchain.com)

Punkte wovon? Terminal-Bench ist ein Test für Agenten, die an einer Kommandozeile arbeiten:

From compiling code to training models and setting up servers, Terminal-Bench evaluates how well agents can handle real-world, end-to-end tasks (externe Seite, github.com)

Jede Aufgabe gilt am Ende als gelöst oder nicht, und die Punktzahl ist der Anteil der gelösten. 52,8 heißt also: gut die Hälfte. Nach der Arbeit an der Umgebung waren es zwei von dreien, und das Modell war dasselbe geblieben. In der Rangliste war das der Weg von Platz 30 in die ersten fünf.

seitlich verschiebbar

eigene Darstellung nach LangChain 2026, Stand 29.08.2026

Drei Vorbehalte gehören dazu. Der Anbieter misst sein eigenes Werkzeug. Die Zahl gilt für diesen einen Test. Und sie gilt für dessen Fassung 2.0, denn der Test wird planmäßig überholt:

As model and agent capabilities increase, it is essential that Terminal-Bench remain on the frontier (externe Seite, tbench.ai)

Die Größenordnung ist trotzdem kein Einzelfall. Ein Positionspapier vom Mai 2026 fasst den Stand so zusammen:

performance variance is governed more by harness configuration than by model choice (externe Seite, arxiv.org)

Was eine solche Zahl aussagt und was sie offenlässt, steht in Beurteilen und Einordnen, Kapitel 04.

Das gilt über das Programmieren hinaus

Die zitierten Messungen stammen aus der Softwareentwicklung, weil dort am meisten gemessen wird. Die Posten selbst hängen an keinem Fachgebiet.

Ein Sprachagent am Telefon hat dieselben sieben: Er bekommt Anweisungen, darf Tools aufrufen, führt einen Gesprächszustand mit, kennt Grenzen und Rechte, schreibt mit, und muss wissen, was bei einem Fehlschlag passiert. Der Pfad Conversational AI behandelt sie unter anderen Namen, etwa als Conversational AI, Kapitel 07 und als Conversational AI, Kapitel 08. Dasselbe gilt für eine Automatisierung, die nachts Dokumente sichtet.

Wer eine Gesamtlösung baut, entscheidet damit über die sieben Posten, ob ihm das bewusst ist oder nicht. Eine Voreinstellung ist auch eine Entscheidung, und meistens eine, die jemand anders getroffen hat.

Was daraus folgt

Wer die Ergebnisse eines Agenten verbessern will, hat zwei Hebel. Der eine ist das Modell, und darauf wartet man. Der andere liegt im eigenen Haus und lässt sich heute anfassen.

Deshalb heißt der Pfad, in dem dieses Kapitel steht, „Agenten und Harness“. Die Kapitel davor und danach handeln von den einzelnen Teilen. Die Frage, in welcher Reihenfolge man sie anfasst, beantwortet Ebene 2.

Die Aufzählung aus Ebene 1 stammt aus einer Messarbeit, und sie ist genauer, als sie beim ersten Lesen wirkt. Jeder der sieben Posten benennt eine Entscheidung, die jemand treffen muss, bevor ein Agent läuft.

Die sieben Posten

Kontext. Was in der Anfrage steht, bevor die Aufgabe kommt: Systemanweisung, Projektregeln, Verlauf, nachgeschlagene Dokumente. Der Posten mit dem größten Spielraum, weil hier eine harte Obergrenze wirkt. Wie eine Projektdatei dabei aussieht, steht in Vibe-Coding / Agentic Engineering, Kapitel 03, das Nachschlagen in Kapitel 03.

Tools. Welche es gibt, wie sie beschrieben sind, und in welcher Form das Ergebnis zurückkommt. Die Anbindung über einen Standard behandelt Kapitel 02, die Mechanik des Aufrufs Grundkurs, Kapitel 09.

Zustand. Was zwischen zwei Schritten überlebt. Der Arbeitsbereich auf der Platte, offene Dateien, Zwischenergebnisse, das Gedächtnis über Sitzungen hinweg (Vibe-Coding / Agentic Engineering, Kapitel 05).

Grenzen. Wann die Schleife abbricht, wie viele Durchgänge erlaubt sind, wie viel ausgegeben werden darf. Kapitel 01 zitiert den Hersteller, der diese Deckel ausdrücklich empfiehlt.

Rechte. Was der Agent ohne Rückfrage anfassen darf. In einem Gesprächssystem heißt derselbe Posten Guardrails (Conversational AI, Kapitel 07), und die Übergabe an einen Menschen steht in Conversational AI, Kapitel 08.

Protokoll. Was mitgeschrieben wird, damit man hinterher nachsehen kann. Für Gesprächssysteme führt Conversational AI, Kapitel 12 aus, warum ein Transkript dafür wenig hergibt.

Fehlerbehandlung. Was passiert, wenn ein Tool scheitert oder eine Antwort unbrauchbar ist. Der Rückweg über die Versionierung steht in Vibe-Coding / Agentic Engineering, Kapitel 04, die Prüfung davor in Vibe-Coding / Agentic Engineering, Kapitel 07.

Harness Engineering, die Arbeitsweise dazu

Für die Tätigkeit an diesen sieben Posten gibt es seit Anfang 2026 einen Namen. Birgitta Böckeler beschreibt ihn als

as a word to describe the tooling and practices we can use to keep AI agents in check (externe Seite, martinfowler.com)

Ein Team bei OpenAI hatte schon im Februar 2026 (externe Seite, openai.com) beschrieben, wie es den eigenen Aufbau um den Agenten herum gestaltet. Was die Sache von einer Sammlung Einstellungen unterscheidet, sagt LangChain in einem Satz:

The goal of a harness is to mold the inherently spiky intelligence of a model for tasks we care about (externe Seite, blog.langchain.com)

Die Fähigkeiten eines Modells sind ungleichmäßig verteilt. Der Harness formt sie auf die Aufgaben zu, die im eigenen Betrieb anfallen. Welche Stellschrauben das im Einzelnen sind, benennt derselbe Text:

Design decisions include the system prompt, tool choice, and execution flow (externe Seite, blog.langchain.com)

Wie groß der Hebel gemessen ist

Es gibt inzwischen drei unabhängige Messungen dazu, und sie zeigen in dieselbe Richtung.

Am eigenen Werkzeug. LangChain brachte den eigenen Coding-Agenten im Test Terminal-Bench 2.0 von 52,8 auf 66,5 Punkte, also von gut der Hälfte gelöster Aufgaben auf zwei von dreien, ohne das Modell zu wechseln. Eine Eigenmessung, sauber beschrieben.

Am eigenen Modell. OpenAI fuhr den Test ARC-AGI-3 mit demselben Modell zweimal und kam von 13,3 auf 38,3 Prozent (externe Seite, openai.com), weil die Gedankenkette zwischen den Zügen erhalten blieb und der Verlauf zusammengefasst statt abgeschnitten wurde. Der Fall steht im Beitrag Dasselbe Modell, dreifacher Wert.

Über viele Paarungen. Harness-Bench hat 106 abgeschottete Aufgaben über mehrere Umgebungen und mehrere Modelle gefahren:

Across 5,194 execution trajectories, we observe substantial variation in completion, process quality, efficiency, and failure behavior across model-harness pairings (externe Seite, arxiv.org)

Der Schluss daraus ist eine Empfehlung, wie Fähigkeiten überhaupt anzugeben sind:

agent capability should be reported at the model-harness configuration level rather than attributed to the base model alone (externe Seite, arxiv.org)

Die Fehlerart, die dabei sichtbar wurde

Dieselbe Arbeit benennt ein wiederkehrendes Muster, das man ohne den Blick auf die Umgebung leicht dem Modell anlastet:

recurring execution-alignment failures, where plausible reasoning becomes decoupled from tool feedback, workspace state, evidence, or verifiable output contracts (externe Seite, arxiv.org)

Der Agent denkt weiter, als wäre alles gut gegangen, während das Tool etwas anderes gemeldet hat. Die Überlegung liest sich plausibel, die Arbeitsablage sagt etwas anderes, und niemand gleicht beides ab.

Das ist ein Befund über den Harness. Wer die Rückmeldung eines Tools unauffällig einbettet, statt sie hervorzuheben, erzeugt genau dieses Muster. Dieselbe Klasse beschreibt Vibe-Coding / Agentic Engineering, Kapitel 07 aus der anderen Richtung: Ein Agent hört auf, wenn die Arbeit fertig aussieht.

In welcher Reihenfolge man anfasst

Aus den sieben Posten ergibt sich eine brauchbare Reihenfolge, und sie folgt dem Preis. Kontext und Tool-Beschreibungen sind billig zu ändern und wirken sofort. Grenzen und Rechte kosten eine Entscheidung, aber keinen Umbau. Protokoll und Fehlerbehandlung sind Arbeit, und sie zahlen sich erst aus, wenn etwas schiefgeht. Der Zustand ist der teuerste Posten, weil daran meistens die Architektur hängt.

Die stärkste Fassung des Gedankens steht in einem Positionspapier vom Mai 2026. Sie hat einen Namen, eine Begründung und eine unbequeme Folge für jede veröffentlichte Rangliste.

Die bindende Beschränkung

Der Kernsatz benennt zugleich die Bestandteile:

the agent execution harness, namely the infrastructure layer that governs context construction, tool interaction, orchestration, and verification around a language model, is often a stronger determinant of agent performance than the model it wraps (externe Seite, arxiv.org)

Die Verfasser nennen das die Binding Constraint Thesis: In diesem Bereich ist die Umgebung der Engpass, an dem alles hängt. Ausdrücklich gilt die These für Aufgaben über viele Schritte und für Modelle mit vergleichbarem Leistungsstand. Bei einer einzelnen Frage an ein schwaches Modell ändert kein Harness etwas daran, dass das Modell die Antwort nicht kennt.

Die Begründung ist ein Regelkreis. Das Papier behandelt den Harness als Regler eines geschlossenen Kreises und das Modell als das gesteuerte Verhalten darin, und daraus folgt die Beobachtung, dass

small harness changes can produce performance shifts that exceed those obtained by substituting one model for another (externe Seite, arxiv.org)

Wer einen Regelkreis kennt, findet das erwartbar: Ein Regler wirkt in jedem Durchlauf, ein besseres Stellglied nur einmal.

Die Folge für Ranglisten

Daraus ziehen die Verfasser einen Vorwurf an die gängige Praxis:

current evaluation protocols therefore systematically misattribute harness-level gains to model improvements (externe Seite, arxiv.org)

Und eine Forderung:

Until harness specifications are disclosed, leaderboard comparisons for long-horizon agents should be treated as incomplete and potentially misleading (externe Seite, arxiv.org)

Damit schließt sich der Kreis zu Beurteilen und Einordnen, Kapitel 04. Dort ist die Umgebung einer von vier Gründen, warum eine Testzahl woanders etwas anderes bedeutet. Hier ist sie der Gegenstand selbst. Wer eine Agenten-Rangliste liest, in der die Umgebung nicht dabeisteht, liest eine Zahl über ein Paar und erfährt nur die Hälfte davon.

Zwei Jahre vor dem Begriff

Die Sache ist älter als ihr Name. 2024 haben Yang und Mitautoren untersucht, wie stark die Schnittstelle zwischen Agent und Rechner die Leistung verändert, und dabei eine Umkehrung vorgenommen, die den Kern trifft:

we posit that LM agents represent a new category of end users with their own needs and abilities, and would benefit from specially-built interfaces to the software they use (externe Seite, arxiv.org)

Ein Agent ist danach eine eigene Nutzergruppe. Die Shell ist für Menschen gebaut, mit unzähligen Optionen und knappen Rückmeldungen. Die Arbeit stellt dem eine kleine Menge einfacher Befehle gegenüber, jeder mit einer ausführlichen Antwort darüber, was er bewirkt hat. Das Vorhaben nennt sie selbst so:

We investigate how interface design affects the performance of language model agents (externe Seite, arxiv.org)

Der Abschluss der Arbeit ist der Satz, den zwei Jahre später das Positionspapier misst:

provide insight on how the design of the ACI can impact agents’ behavior and performance (externe Seite, arxiv.org)

Zwischen dieser Arbeit und dem Wort Harness liegen 21 Monate. Mitchell Hashimoto hat den Ausdruck im Februar 2026 (externe Seite, mitchellh.com) vergeben, weil ihm für einen Arbeitsschritt der Name fehlte. Die Sache dahinter war zu dem Zeitpunkt untersucht, gemessen und veröffentlicht.

Was das für den eigenen Aufbau heißt

Vier Schlüsse, und der letzte ist der unbequemste.

Die Umgebung gehört ins Protokoll. Wenn eine Änderung an der Umgebung mehr bewegt als ein Modellwechsel, ist die Angabe des Modells allein keine Beschreibung eines Aufbaus. Modellfassung, Werkzeugsatz, Systemanweisung und Abbruchbedingungen gehören zusammen notiert.

Tools werden für Agenten gebaut. Eine Schnittstelle, die für Menschen gedacht ist, gibt knappe Rückmeldungen und setzt Vorwissen voraus. Beides schadet einem Agenten. Eine ausführliche Antwort auf jeden Aufruf kostet Token und spart Durchgänge.

Die Rückmeldung muss auffallen. Die häufigste Fehlerart von Harness-Bench liegt genau hier: Die Überlegung des Modells löst sich von dem, was die Tools melden. Eine Fehlermeldung, die zwischen zwei Erfolgsmeldungen steht, wird überlesen.

Der Harness ist teurer als das Modell. Ein Modellwechsel ist eine Zeilenänderung. Die sieben Posten aus Ebene 2 sind Arbeit, die niemand einmal erledigt. Genau deshalb ist der Hebel dort so groß: Es macht sich kaum jemand die Mühe.

Wo die Belege enden

Zwei der drei genannten Messungen stammen von Anbietern, die ihr eigenes Werkzeug messen. Die dritte, Harness-Bench, ist unabhängig und benennt ihre Grenzen selbst: 106 Aufgaben, abgeschottet, aus Mustern der Praxis gebaut und von Hand auf Lösbarkeit geprüft. Das ist eine Stichprobe. Über die Mischung an Aufgaben, die in einem einzelnen Betrieb anfällt, sagt sie nichts.

Was daraus folgt, gilt für die Größenordnung. Der Aufbau um das Modell herum bewegt in diesem Bereich so viel wie die Wahl des Modells; eine einzelne Zahl daraus überträgt sich auf keinen anderen Fall. Wer beziffern will, wie viel bei ihm selbst, misst es an eigenen Fällen, und wie das geht, steht in Beurteilen und Einordnen, Kapitel 04.