Harness Engineering 101: Wie Coding-Agenten wirklich arbeiten

Von Ariful Islam Datum: 24. September 2026 Typ: Artikel Kategorie: KI Tags: ai-agents, harness-engineering, context-engineering, claude-code, codex, coding-agents, linux

Was ist ein Agent-Harness?

Ein Agent-Harness ist die gesamte Software rund um ein Sprachmodell, die aus dem Modell einen arbeitsfähigen Agenten macht. Birgitta Böckeler von Thoughtworks hat das in einem Artikel auf der Website von Martin Fowler in vier Wörtern zusammengefasst: Agent = Modell + Harness.

Das Modell mieten Sie. Alles andere ist Harness: die Schleife, die es am Laufen hält, die Tools, die es aufrufen kann, was in sein Kontextfenster kommt, was es tun darf und wie seine Arbeit geprüft wird, bevor jemand sie abnimmt.

Eine Runde pro Schritt. Nur das Modell und die echte Welt liegen außerhalb des Harness: Alles, was das Modell sieht, und alles, was es anfassen darf, läuft durch ein Stück Software, das jemand gebaut hat. Zurück kommt in jeder Runde Feedback, also Ausgabe, ein Exit-Code und was die Hooks melden. Dass die eigentlichen Tests laufen, liegt meist daran, dass das Modell sich dafür entscheidet oder ein Hook es dazu zwingt.

Häufig wird ein Harness mit einem Framework verwechselt. LangChain, Microsoft Agent Framework und das OpenAI Agents SDK sind Frameworks, also Baukästen, aus denen man einen Agenten zusammensetzt. Ein Harness ist die fertige Laufzeitumgebung, die am Ende dabei herauskommt. Claude Code ist ein Harness, Codex CLI ebenso. Ganz scharf ist die Grenze allerdings nicht mehr, denn mehrere Frameworks liefern inzwischen selbst ein fertiges Harness mit.

Warum das Harness zählt

Es gibt ein Experiment, das viel bekannter sein müsste. Man nimmt ein Modell und gibt ihm 169 echte Bugfix-Aufgaben aus SWE-bench Verified. Modellgewichte, Aufgaben und Kontextfenster bleiben exakt gleich, geändert wird nur der Code, der um das Modell herum läuft. Die Zahl der vollständig gelösten Aufgaben steigt von 43 auf 72.

Das Ergebnis stammt aus einem Paper, das im August auf arXiv erschienen ist, und kürzer kann ich nicht sagen, worum es in diesem Beitrag geht. Das Modell war in beiden Durchläufen dasselbe. Das Harness nicht.

Ich verbringe inzwischen den größten Teil meines Arbeitstags mit Agenten, ich baue sie und lasse sie Code schreiben. Gefragt werde ich aber zuerst immer noch, welches Modell man nehmen soll. Diese Frage wird mit jedem Quartal unwichtiger. Die Frontier-Modelle liegen so dicht beieinander, dass die Software um sie herum über den Großteil des Ergebnisses entscheidet: was eine Aufgabe kostet, ob der Agent sie zu Ende bringt und ob Sie dem trauen können, was er abliefert. Diese Software ist das Harness. Sie zu entwerfen, nennt man seit einiger Zeit Harness Engineering.

Prompt, Kontext, Harness

Bis hierher hat die Branche drei Schritte gebraucht, und jeder hat den vorigen umschlossen.

Ersetzt wurde nichts. Prompts und Kontext zählen weiterhin, sie sind jetzt eben zwei Bestandteile des Harness.

Beim Prompt Engineering ging es um die Worte. Beim Context Engineering darum, was außer den Worten noch vor dem Modell landet: abgerufene Dokumente, Memory, eine Zusammenfassung dessen, was zehn Schritte zuvor passiert ist. Harness Engineering übernimmt beides und ergänzt alles, was ein Modell braucht, um zu handeln, statt nur zu reden.

Die ganze Schleife in dreißig Zeilen

Am schnellsten versteht man ein Harness, wenn man selbst eins schreibt. Unten steht der Kern eines Coding-Agenten als Pseudocode. Das ist vereinfacht, aber jedes echte Harness, dessen Code ich gelesen habe, ist genau so aufgebaut.

def run_agent(task, model, tools, limits):
    context = [system_prompt(), project_memory(), task]

    for step in range(limits.max_steps):
        if count_tokens(context) > limits.window * 0.8:
            context = compact(context)          # summarize old turns

        reply = model.generate(context, tools=tools.schemas())

        if reply.is_done:
            report = verify(reply)              # run tests, linters, a reviewer
            if report.passed:
                return reply
            context.append(report.as_feedback())
            continue

        for call in reply.tool_calls:
            if not policy.allows(call):
                result = ask_human(call) or "denied by policy"
            else:
                result = tools.run(call)        # most of the time: a shell command
            context.append(trim(result))        # keep the lines that matter

        if same_command_failed(context, times=3):
            context.append("That failed three times. Try a different approach.")

    return stop_and_report(context)

Zählen Sie die Zeilen, in denen das Modell vorkommt. Es gibt genau eine: model.generate. Der Rest ist Harness, und hinter jeder dieser Zeilen steckt eine Entscheidung, die jemand treffen musste. Wann wird verdichtet? Wie viel von einem 4.000 Zeilen langen Testlog bekommt das Modell zu sehen? Was sagt policy.allows zu git push --force? Ändern Sie nur eine dieser Antworten, und dasselbe Modell benimmt sich wie ein anderer Agent.

Die Bausteine im Einzelnen

Die Schleife

Planen, handeln, beobachten, wiederholen. Der Kern ist tatsächlich so klein: Mario Zechners Agent Pi kommt mit System-Prompt und sämtlichen Tool-Definitionen auf weniger als 1.000 Tokens. Schwierig wird es rund um die Schleife. Wann hört der Agent auf? Wann fragt er einen Menschen? Und was passiert, wenn er denselben fehlschlagenden Befehl zum fünften Mal ausführt? Für genau diesen Fall gibt es oben die Zeile mit same_command_failed.

Tools

Ohne Tools kann der Agent nichts anfassen. Bei einem Coding-Agenten heißt das: Dateien lesen und bearbeiten, Befehle ausführen, das Repo durchsuchen. Bei einem Support-Agenten sind es das Ticketsystem und die Wissensdatenbank.

Wie ein Tool gebaut ist, macht mehr aus, als die meisten erwarten. Ein Tool, das 10.000 Zeilen Log ausspuckt, flutet den Kontext. Liefert es dagegen nur die 20 Zeilen rund um den Fehler, bleibt dem Modell Raum zum Nachdenken. MCP hat es leicht gemacht, Tools anzuschließen. Die Arbeit besteht jetzt darin, weniger davon auszuwählen und gezielt zu gestalten, was sie zurückgeben. Bei Coding-Agenten erledigt in der Praxis ein einziges Tool das meiste, und es bekommt weiter unten einen eigenen Abschnitt.

Kontext

Das ist die am meisten unterschätzte Schicht. Jede lange Aufgabe stößt irgendwann an die Grenze des Kontextfensters, und was das Harness in diesem Moment tut, entscheidet darüber, ob der Agent fertig wird.

Jeder Tool-Aufruf fügt einen Block hinzu. An der 80-%-Linie muss das Harness Platz schaffen, indem es alte Ausgaben kürzt oder alte Schritte zu einer Zusammenfassung verdichtet. Tut es keins von beiden, endet die Aufgabe zusammen mit dem Fenster, ob sie fertig ist oder nicht.

Das oben erwähnte Paper aus dem August, „Same Model, Different Harness“, ist der sauberste Beleg dafür, den ich kenne. Beide Durchläufe nutzten dieselben Modellgewichte, dieselben 169 Aufgaben aus SWE-bench Verified, dieselbe Kontextkapazität und dasselbe Versuchsprotokoll. Das neue Harness machte genau zwei Dinge anders. Es kürzte ältere Tool-Ergebnisse stufenweise, je voller das Fenster wurde. Und wenn es merkte, dass der Agent fehlgeschlagene Befehle wiederholte, forderte es ihn auf, etwas anderes zu versuchen.

Der gesamte Gewinn kam daher, wie das Harness mit einem kleinen Kontextfenster umging. Mit reichlich Platz spielt diese Strategie kaum noch eine Rolle. Im Produktivbetrieb ist sie es nicht, denn dort wird jedes Token abgerechnet.

Die gängigen Techniken:

Technik	Was sie tut
Verdichten (Compaction)	Fasst alte Schritte zusammen, sobald die Token-Zahl hoch wird
Kürzen (Truncation)	Stutzt alte Tool-Ausgaben und lässt die jüngsten vollständig
Memory-Dateien	Notizen, die zu Beginn jeder Sitzung geladen werden, etwa CLAUDE.md oder AGENTS.md im Projekt
Subagenten	Bearbeiten eine Nebenaufgabe in einem eigenen, frischen Kontext und liefern nur die Antwort zurück
Kontext-Reset	Leert das Fenster komplett und startet eine neue Sitzung anhand einer schriftlichen Übergabedatei

Die letzte Zeile ist neuer als die anderen, und es gibt sie aus einem Grund, auf den man nicht so leicht käme. Ein Team bei Anthropic, das Agenten ganze Anwendungen in langen Sitzungen bauen lässt, stellte fest, dass „Compaction allein nicht ausreichte“. Je voller das Fenster wurde, desto häufiger zeigten die Modelle, was das Team Context Anxiety nennt: Sie schlossen die Arbeit vorzeitig ab, weil sie spürten, dass die Grenze näher rückte. Ein sauberer Reset mit strukturierter Übergabe funktionierte besser als eine Zusammenfassung, bei der das Modell trotzdem wusste, dass ihm der Platz ausgeht.

Guardrails

Ein Agent, der Befehle ausführen kann, kann auch Dinge löschen. Jedes Harness legt sich dafür irgendwo auf einer Skala fest, und als ich die Varianten nebeneinanderstellte, lagen sie weiter auseinander, als ich erwartet hatte:

• Immer fragen. So ist Cline voreingestellt: Jede Aktion wartet auf Ihre Freigabe.
• Einen Klassifikator entscheiden lassen. Der Auto-Modus von Claude Code (Startmodus in den Plänen Pro, Max und Team) und Auto-review in Cursor lassen beide ein zweites Modell die Aktionen prüfen, statt Sie jedes Mal zu fragen.
• Abschotten. Codex CLI läuft standardmäßig in einer Sandbox auf Betriebssystemebene, beschränkt auf den Workspace und ohne Netzwerk.
• Dem Nutzer vertrauen. Pi hat weder Sandbox noch Rückfragen. Sein Autor spricht vom „vollen YOLO-Modus“ und empfiehlt, Pi in einem Container zu betreiben.

Falsch ist keine dieser Varianten. Welche passt, hängt davon ab, was ein Fehler kosten kann. Und das entscheiden Ihr Rechner und Ihre Daten, nicht das Tool.

Verifikation

Diese Schicht sorgt dafür, dass Sie dem Agenten vertrauen können, ohne jede Zeile zu lesen, die er schreibt. Böckeler unterscheidet hier zwei Arten von Kontrolle. Guides lenken den Agenten, bevor er handelt: Anweisungen, Konventionen, Beispiele. Sensoren prüfen hinterher das Ergebnis und helfen ihm, sich selbst zu korrigieren: Tests, Linter, Type-Checker, Review-Agenten. Im Pseudocode ist project_memory() ein Guide und verify() ein Sensor.

Wie weit man damit gehen kann, zeigt OpenAI in „Harness engineering: leveraging Codex in an agent-first world“. Ein Team, das mit drei Entwicklern angefangen hatte, hat nach rund 1.500 gemergten Pull Requests eine interne Beta ausgeliefert, ohne dass eine einzige Zeile Code von Hand geschrieben wurde. Codex schrieb die Anwendung, die Tests, die CI-Konfiguration und die Dokumentation. Die Menschen bauten das Harness: die Prüfungen, die Struktur und die Feedback-Schleifen, die den Agenten auf Kurs hielten.

Der Haken: Über die eigene Arbeit urteilt ein Agent schlecht. Der schon erwähnte Anthropic-Beitrag sagt es ohne Umschweife. Sollen Agenten bewerten, was sie selbst produziert haben, „neigen sie dazu, die Arbeit selbstbewusst zu loben“, auch wenn ein Mensch sofort sieht, dass sie mittelmäßig ist. Das Team hat die Aufgabe deshalb auf drei Agenten verteilt. Ein Planer schreibt die Spezifikation, ein Generator baut, und ein separater Evaluator testet die laufende App mit Playwright gegen Kriterien, die vor der ersten Zeile Code feststanden. Ein einzelner Agent brauchte 20 Minuten und 9 Dollar. Das vollständige Harness brauchte sechs Stunden und 200 Dollar, und das Ergebnis war um Längen besser. Verifikation passiert nicht von allein. Jemand muss sie ins Harness einbauen, manchmal als kompletten zweiten Agenten, der nur dazu da ist, nichts durchgehen zu lassen.

Erweiterbarkeit

Ein gutes Harness lässt sich anpassen, ohne dass man es forken muss. Claude Code bietet über 30 Lifecycle-Events, an die Sie per Hook Skripte hängen können, dazu Skills, Plugins, Subagenten und MCP-Server. An dieser Stelle bringt ein Team seine eigenen Konventionen unter.

Hier ein echter Hook, einer von der Sorte, die ich am ersten Tag einrichten würde. Nach jeder Dateiänderung lässt er den Formatter über die geänderte Datei laufen:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Sehen Sie sich den Befehl genau an. Das Harness übergibt das Event als JSON auf der Standardeingabe, jq holt ein einzelnes Feld heraus, und xargs gibt es an ein anderes Programm weiter. Das ist eine Unix-Pipeline, und das ist kein Zufall.

Warum die Shell die meiste Arbeit erledigt

Angefangen habe ich als Administrator für Linux-Server, und schon damals hat mich fasziniert, wie viel eine einzige Zeile leisten kann. Man verkettet ein paar kleine Programme, und eine Aufgabe, die nach einem ganzen Nachmittag klingt, ist erledigt, bevor man zu Ende getippt hat. Eine der Zeilen, die mich überzeugt haben:

grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

Das Ergebnis: jede IP-Adresse, die per Brute Force in den SSH-Zugang des Servers wollte, gezählt und nach Häufigkeit sortiert. Dafür arbeiten fünf Programme zusammen, die nichts voneinander wissen. Wenn ich einem Coding-Agenten bei der Arbeit zusehe, habe ich dasselbe Gefühl. Er greift zu derselben Sorte Werkzeug, und zwar ungefähr in der Reihenfolge, in der ich es auch täte:

$ rg -n "InvoiceTotal" src/
$ sed -n '118,160p' src/billing/invoice.ts
$ npm test -- invoice
$ git diff --stat

Meiner Ansicht nach bezieht ein Coding-Agent den größten Teil seiner Handlungsfähigkeit genau daher. Geben Sie einem Modell ein einziges Tool, nämlich eine Shell, und es bekommt jedes Programm auf der Maschine gleich mit. Niemand musste ein Tool namens search_code oder run_tests bauen. rg und npm test gab es längst, samt Jahrzehnten an Dokumentation.

Ein Tool, und jedes Programm auf der Maschine kommt mit. Der Funke spielt die vier Befehle von oben der Reihe nach ab. Zurück kommt jedes Mal reiner Text und ein Exit-Code, und beides kann ein Modell ohne Adapter dazwischen lesen.

Aus meiner Sicht gibt es vier Gründe, warum die Shell so gut zu einem Sprachmodell passt.

Erstens spricht sie Text. Doug McIlroy hat die Regel 1978 im Bell System Technical Journal festgehalten: „Erwarte, dass die Ausgabe jedes Programms zur Eingabe eines anderen, noch unbekannten Programms wird.“ Bei Bell Labs dachte damals niemand an Sprachmodelle, aber ein unbekanntes Programm, das Ihre Ausgabe liest: Das beschreibt ein Sprachmodell ziemlich genau.

Zweitens kennen Modelle sie bereits. Fünfzig Jahre Manpages, Shell-Skripte, READMEs und Forenantworten stecken in den Trainingsdaten. Zechner hat es ganz nüchtern formuliert, als er erklärte, warum Pi nur vier Tools mitbringt (read, write, edit und bash): „Modelle wissen, wie man bash benutzt.“

Drittens meldet jeder Befehl etwas zurück. Ein Exit-Code, ob 0 oder nicht, ist ein kostenloser Sensor. Der Agent weiß, ob der Test bestanden ist, ohne dass jemand eigens eine Verifikationsschicht dafür geschrieben hätte.

Viertens lassen sich Programme kombinieren. Eine Pipe macht aus zwei kleinen Tools im Handumdrehen ein drittes, das Harness braucht also nicht für jede Aufgabe ein eigenes Tool.

Ein weiteres Stück Unix arbeitet hier unauffällig mit, und LangChain nennt es in seinem Text über die Anatomie eines Harness „den wohl grundlegendsten Harness-Baustein“: das Dateisystem. Ein Modell vergisst alles, sobald sein Kontext endet. Eine Datei nicht. Eine Fortschrittsnotiz, eine Feature-Liste, ein Git-Log: So übersteht eine lange Aufgabe den Sprung von einer Sitzung zur nächsten, und Dateien und git erledigen dabei denselben Job wie seit fünfzig Jahren.

Die Anbieter sind von der anderen Seite her zum selben Schluss gekommen. Anthropic fasst das Designprinzip hinter seinem Claude Agent SDK so zusammen: „Geben Sie Ihren Agenten einen Computer, damit sie arbeiten können wie Menschen.“ Boris Cherny, der Claude Code ins Leben gerufen hat, hat erklärt, dass frühe Versionen RAG mit einer lokalen Vektordatenbank nutzten. Das Team stieg dann auf schlichte agentische Suche um (das Modell ruft grep und Verwandte auf), weil das besser funktionierte. Nach eigener Aussage beruhte das eher auf internem Bauchgefühl als auf einem Benchmark, ausgeliefert wurde es trotzdem. Vercel hat einen internen Daten-Agenten auf kaum mehr als ein einzelnes Bash-Tool zusammengestrichen und berichtet, dass er seitdem 3,5-mal so schnell läuft und 37 % weniger Tokens verbraucht. Getestet wurde das allerdings mit fünf Abfragen, nehmen Sie es also als Tendenz, nicht als Messwert.

Die Shell hat natürlich Grenzen, und die sollte man kennen. Durch eine Web-App klicken kann sie nicht, für GUI-Arbeit braucht es weiterhin Browser- oder Computer-Use-Tools. Ein SaaS-Produkt ohne CLI bindet man über eine API oder einen MCP-Server an. Und dieselbe Shell, die npm test ausführt, führt auch rm -rf aus. Genau deshalb gibt es den Abschnitt über Guardrails überhaupt.

Coding-Agenten im Vergleich

Hier die Harnesses, nach denen ich am häufigsten gefragt werde, Stand September 2026. Voreinstellungen ändern sich schnell, werfen Sie also einen Blick in die Dokumentation, bevor Sie sich auf eine Zelle verlassen.

Agent	Open Source	Modelle	Standard-Absicherung	Eingebaute Tools
Claude Code	Nein	Nur Claude	Klassifikator bei Pro, Max und Team, sonst Rückfrage	40+, im Kern Read, Edit, Grep, Glob, Bash
Codex CLI	Apache 2.0	Standardmäßig OpenAI, andere per Konfiguration	OS-Sandbox, nur Workspace, kein Netzwerk	Vor allem Shell, dazu apply_patch
Gemini CLI	Apache 2.0	Nur Gemini	Keine Sandbox, bestätigt Shell und Schreibzugriffe	Etwa 20, darunter Shell und grep
Cursor	Nein	Viele Anbieter	Shell in der Sandbox, Klassifikator prüft den Rest	Suchen, Lesen, Bearbeiten, Shell, Browser
OpenHands	MIT	Fast alle, über LiteLLM	Docker-Sandbox in der Web-App, in der CLI erst Rückfrage	Terminal, Dateieditor, Task-Tracker
Aider	Apache 2.0	Fast alle, auch lokal	Keine Sandbox, committet jede Änderung in Git, fragt vor Befehlen	Keine Tool-Schleife: Edit-Formate und eine Repo-Map
Cline	Apache 2.0	Viele, auch lokal	Fragt vor jeder Aktion	7, mit ripgrep für die Suche
Pi	MIT	15+ Anbieter	Keine Sandbox, keine Rückfragen	4: read, write, edit, bash

Lesen Sie die letzte Spalte von oben nach unten. Die Harnesses, die am stärksten auf die Shell setzen, bringen die wenigsten Tools mit, und Codex, unter den großen dreien der shell-lastigste, sperrt die Shell zugleich am strengsten in eine Sandbox. Diese Kombination ist gewollt. Aider tanzt aus der Reihe: Es ist älter als Tool Calling und arbeitet bis heute mit Edit-Formaten und einer Repo-Map. Das erinnert daran, dass die Schleife aus meinem Pseudocode nur eine Bauweise unter mehreren ist.

Jenseits von Code

Am ersten Diagramm ist nichts softwarespezifisch. Microsoft Agent Framework hat im April 2026 Version 1.0 erreicht und auf der Build im Juni ein eingebautes Harness nachgelegt, mit Shell- und Dateizugriff, Freigabe von Tool-Aufrufen, dateibasiertem Memory und automatischer Compaction des Kontexts. LangChain Deep Agents und das OpenAI Agents SDK bieten ähnliche Bausteine.

Verlässt man den Code, ändert sich im Grunde nur eine Zeile:

	Coding-Agent	Allgemeiner Agent
Schleife	dieselbe	dieselbe
Tools	Shell, Git, Dateien	APIs, Browser, E-Mail, CRM
Kontext	Repo, Diffs	Dokumente, Tickets, Chatverlauf
Guardrails	Sandbox	Freigabe für Versand, Zahlungen, Löschungen
Verifikation	Tests, eingebaut	Evals, Bewertungsraster, menschliches Review

Ein Recherche-Agent hat keine Testsuite. Ein Support-Agent kann auf eine Antwort kein npm test loslassen. Den Exit-Code, der Coding-Agenten so leicht überprüfbar macht, gibt es hier nicht, also muss ein allgemeines Harness seine Sensoren selbst bauen: Evaluationssets aus echten früheren Fällen, Review-Agenten mit Bewertungsraster und Stellen, an denen ein Mensch abzeichnet. Wenn Sie einen Agenten außerhalb von Code bauen, gehört Ihre Zeit genau hierhin. Hier scheitern solche Agenten, und zwar meistens leise. Wie diese leisen Fehler im Produktivbetrieb aussehen, habe ich in einem eigenen Beitrag beschrieben.

Woran man ein Harness misst

Ob Sie eines auswählen oder selbst bauen: Bewerten Sie den ganzen Stack, nicht das Modell allein.

1. Kosten pro erledigter Aufgabe, nicht pro Token.
2. Erfolgsquote bei Ihren eigenen Aufgaben, nicht auf einer öffentlichen Rangliste.
3. Lange Aufgaben: Bringt es sie zu Ende, oder bleibt es auf halber Strecke hängen?
4. Sicherheitsmodell: Was kann es kaputtmachen, und wer gibt frei?
5. Passung: Funktioniert es mit Ihren Tools und Ihren Konventionen?

Am häufigsten werden die Kosten unterschätzt. Als Artificial Analysis im Mai 2026 seinen Coding Agent Index vorstellte, lagen die Kosten pro Aufgabe über alle getesteten Kombinationen aus Modell und Harness zwischen 0,07 und 2,26 Dollar. Den größten Teil dieser Spanne erklärt das Modell, aber das Harness entscheidet, wie viele Tokens das Modell auf dem Weg verheizt.

Auch die Maschine darunter verschiebt die Zahlen. Das Engineering-Team von Anthropic hat dasselbe Claude-Modell mit demselben Harness auf denselben Aufgaben aus Terminal-Bench 2.0 laufen lassen und zwischen den knappsten und den großzügigsten Container-Ressourcen 6 Prozentpunkte Unterschied gemessen. Vergleichen Sie also auf der Infrastruktur, die Sie tatsächlich einsetzen werden.

Wohin die Reise geht

Über den Harnesses entsteht gerade eine weitere Schicht. Im Juni 2026 hat Databricks Omnigent als Open Source veröffentlicht und nennt es ein „Meta-Harness“: Es sitzt über Claude Code, Codex, Pi oder Ihrem eigenen Agenten und erlaubt es, diese von einer Stelle aus zu kombinieren und zu steuern. Setzt sich die Idee durch, wird das Harness zu einer austauschbaren Komponente, so wie man heute eine Datenbank gegen eine andere tauscht.

Ein Teil des heutigen Harness wird auch ins Modell wandern. Den besten Satz dazu habe ich im erwähnten Anthropic-Beitrag gelesen: „Jede Komponente eines Harness schreibt eine Annahme darüber fest, was das Modell allein nicht kann.“ Die Prüfung same_command_failed in meinem Pseudocode nimmt an, dass das Modell nicht merkt, wenn es sich im Kreis dreht. Compaction nimmt an, dass es eine lange Aufgabe nicht in einem einzigen Fenster halten kann. Mit besseren Modellen treffen manche dieser Annahmen nicht mehr zu, und die Teile, die darauf beruhen, können weg.

Was sich meiner Erwartung nach nicht verschiebt, ist die Berechtigungsgrenze. Ein Modell kann lernen, seine eigenen Fehler zu erkennen. Was es auf Ihrem Produktivserver löschen darf, bleibt aber Ihre Entscheidung. Sie steht in einem Harness, so wie sie lange vor alldem in einer sudoers-Datei stand.

Wenn Sie gerade überlegen, wie so ein Harness für Ihr eigenes Team aussehen sollte: Mein Kalender steht auf der Kontaktseite.

Quellen

• Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com, April 2026
• Sydney Lewis, Same Model, Different Harness: Different Coding-Agent Results, arXiv, August 2026
• OpenAI, Harness engineering: leveraging Codex in an agent-first world
• Anthropic, Building agents with the Claude Agent SDK
• M. D. McIlroy, E. N. Pinson und B. A. Tague, UNIX Time-Sharing System: Foreword, Bell System Technical Journal, 1978
• Mario Zechner, What I learned building an opinionated and minimal coding agent, November 2025
• Boris Cherny darüber, wie agentische Suche in Claude Code RAG ersetzt hat, Februar 2026
• Vercel, We removed 80% of our agent's tools, Dezember 2025
• Artificial Analysis, Coding Agent Index und der Launch-Beitrag vom Mai 2026
• Anthropic, Quantifying infrastructure noise in agentic coding evals
• Anthropic, Harness design for long-running application development, März 2026
• LangChain, The anatomy of an agent harness, März 2026
• Microsoft, Microsoft Agent Framework at BUILD 2026
• Databricks, Introducing Omnigent
• Dokumentation der Tools für die Vergleichstabelle: Claude Code tools, permission modes und hooks; Codex und dessen approvals and security; Gemini CLI tools; Cursor run modes; OpenHands; Aider; Cline tools; Pi