Was ist ein Agent-Harness? Forschung, Open-Source-Projekte und Branchenpraxis

Zwei agents können exakt dasselbe Modell verwenden und bei demselben Benchmark sehr unterschiedliche Ergebnisse erzielen. OpenAI hat dies direkt gemessen: Auf SWE-bench Lite erreichte GPT-4 mit einem Harness 2,7 % und mit einem anderen 28,3 % – ein zehnfacher Unterschied, der vollständig durch das Harness entstand. Als sich der Fokus der Branche von „Welches Modell ist am klügsten?“ zu „Welcher agent erledigt die Aufgabe tatsächlich?“ verlagerte, wurde das Agent-Harness zur Ebene, auf der sich Zuverlässigkeit entscheidet. Lies weiter, um zu erfahren, was ein Agent-Harness ist, was die neuesten Arbeiten und Benchmarks zum Harness-Design sagen, welche Open-Source-Harnesses deine Zeit wert sind und wie die großen KI-Labore ihre eigenen entwickeln – einschließlich Kimi K3.1 Pro, dem Modell mit offenen Gewichten, das Moonshot AI mit seinen eigenen Harnesses kombiniert.

Ein Agent-Harness ist die umgebende Infrastruktur, die es einem großen Sprachmodell ermöglicht, innerhalb einer realen Umgebung als agent zu arbeiten. Während das Modell token erzeugt, übernimmt das Harness alles andere: Es erstellt bei jedem Schritt den prompt, legt fest, welche Tools verfügbar sind und wie sie aufgerufen werden, führt Aktionen in einer Sandbox oder einem Terminal aus, gibt Beobachtungen an das Modell zurück, setzt Schritt- und Kostenlimits durch und protokolliert die vollständige Trajektorie für die Auswertung oder Fehlersuche.

Der Begriff stammt aus der Evaluierungswelt – ein „Test-Harness“ ist die Umgebung, in der ein System unter kontrollierten Bedingungen ausgeführt wird. In der agentischen KI wurde dieselbe Idee auf den Produktiveinsatz übertragen: Ein Harness ist sowohl die Umgebung zur Messung eines agent (wie bei SWE-bench oder Terminal-Bench) als auch die Umgebung für seinen Betrieb (wie bei SWE-agent, OpenHands oder Claude Code).

Die eigene SWE-bench-Forschung von Anthropic formuliert es klar: Der Benchmark „evaluiert nicht nur das KI-Modell isoliert, sondern ein gesamtes ,agent'-System“, wobei der agent „die Kombination aus einem KI-Modell und dem darum liegenden Softwaregerüst“ ist. Das aktualisierte Claude 3.5 Sonnet erreichte auf SWE-bench Verified 49 % – nicht mit einem komplexen Framework, sondern mit einem minimalen Harness aus einem prompt und zwei universell einsetzbaren Tools (einem Bash-Tool und einem Edit-Tool).

Jahrelang wurden Verbesserungen in Bestenlisten der Modellgröße zugeschrieben. Neuere Forschung stellte diese Annahme von zwei Seiten infrage.

Erstens das Ergebnis „Weniger ist mehr“: Im Juli 2025 veröffentlichte das SWE-bench-Team mini-SWE-agent, ein Harness aus rund 100 Zeilen Python ohne andere Tools als bash, mit einem vollständig linearen Nachrichtenverlauf und jeder Aktion als unabhängigem subprocess.run-Aufruf. Es erreichte Benchmark-Ergebnisse, die mit deutlich komplexeren Frameworks konkurrieren konnten (mehr dazu im Forschungsabschnitt unten). Die Erkenntnis war provokant: Ist das Modell stark genug, kann ein extrem einfaches, vorhersehbares Harness ein schwergewichtiges übertreffen. Es wird bereits von Meta, NVIDIA, IBM, Princeton und Stanford als Referenzwert verwendet.

Zweitens das Ergebnis „Mehr ist weniger“: Ein schlechtes Harness – verrauschte Tool-Ausgaben, unbegrenzte Schleifen, mangelhafte Fehlerbehandlung – kann ein Spitzenmodell mittelmäßig aussehen lassen. OpenAI stellte fest, dass die Bereinigung fehlerhafter Aufgaben in SWE-bench (Einzelheiten im OpenAI-Abschnitt weiter unten) die gemessene Modellleistung mehr als verdoppelte.

Deshalb ist Harness Engineering zu einer eigenen Disziplin geworden. Das Harness bestimmt:

• Was das Modell sieht: Prompt-Struktur, Tool-Schemata und wie viel vom Zustand der Umgebung und vom Verlauf im Kontextfenster enthalten ist.

• Was das Modell tun kann: welche Tools verfügbar sind (Shell, Dateieditor, Browser, Suche) und wie Aktionen vor der Ausführung analysiert und validiert werden.

• Wie mit Fehlern umgegangen wird: Wiederholungen, Zeitüberschreitungen, Kontextverdichtung bei vollem Fenster und geordnetes Beenden.

• Wie Arbeit gemessen wird: Trajektorienprotokollierung, Bewertung und Kostenabrechnung – ohne sie gibt es weder eine Evaluierung noch einen Verbesserungszyklus.

Ob Forschungs-Benchmark-Umgebung oder Coding-Assistent für den Produktiveinsatz: Fast jedes Agent-Harness implementiert dieselbe Kernschleife:

1. Aufgabenaufnahme: Lies das Issue, die Anweisung oder das Ziel und starte eine isolierte Umgebung (in der Regel einen Docker-Container oder einen VM-Snapshot).

2. Prompt-Erstellung: Kombiniere den System-prompt, Tool-Definitionen, Aufgabenbeschreibung sowie den fortlaufenden Verlauf von Aktionen und Beobachtungen.

3. Aktionsanalyse: die Modellausgabe in einen konkreten Tool-Aufruf übersetzen — einen bash-Befehl, eine Dateibearbeitung, eine API-Anfrage — und fehlerhafte Aktionen zurückweisen.

4. Ausführung und Beobachtung: die Aktion in der Umgebung ausführen, stdout/stderr oder den UI-Zustand erfassen und auf das Kontextbudget kürzen.

5. Ablaufsteuerung: Schritt- und Kostenlimits sowie Abbruchbedingungen durchsetzen; entscheiden, wann ein Mensch gefragt oder die Episode beendet wird.

6. Aufzeichnung und Bewertung: die vollständige Trajektorie speichern und den Endzustand bewerten — beispielsweise durch Ausführen der Test-Suite des Repositorys in SWE-bench.

Entscheidungen bei jedem Schritt summieren sich. Allein die Kürzungsstrategie kann bei Aufgaben mit langem Horizont die Ergebnisse merklich verändern. Deshalb behandeln ernsthafte Teams das Harness als versionierte, testbare Software und nicht als Glue Code.

Die wissenschaftliche Literatur zu Agent Harnesses ist zu einer kleinen Zahl mühsam gewonnener Erkenntnisse gelangt. Statt jeden Benchmark aufzulisten, zeichnet dieser Abschnitt die Forschungsfragen nach, die das Feld dazu zwangen, das Harness ernst zu nehmen.

Vor den Arbeiten ein kurzer Überblick. Ein Benchmark ist eine feste Aufgabensammlung mit einer Bewertungsregel, damit verschiedene Systeme unter identischen Bedingungen verglichen werden können. Bei der Bewertung von agent besteht ein Benchmark aus drei beweglichen Teilen: einer Aufgabensammlung (echte GitHub-Issues, Terminalbefehle, Webaufgaben), einer Ausführungsumgebung (einem Docker-Container, einem Browser, einem Terminal) und einer Bewertung (einer Test-Suite, einer Zustandsprüfung, einer menschlichen Prüfung). Das Harness sitzt zwischen dem Modell und allen drei — es entscheidet, ob sich die Fähigkeiten des Modells in der Punktzahl zeigen.

Wie Ergebnisse tatsächlich gemessen werden, ist wichtiger als die Schlagzeilenzahl. In SWE-bench erzeugt ein agent einen Code-Patch; der Benchmark führt dann zwei Test-Suites aus: FAIL_TO_PASS (Tests, die vor der Korrektur fehlschlugen und nun bestehen müssen) und PASS_TO_PASS (Tests, die zuvor funktionierten und nicht kaputtgehen dürfen). Eine Aufgabe gilt nur dann als gelöst, wenn beide bestehen. Deshalb sind Harness-Funktionen wie Testausführung und Diff-Erstellung keine optionalen Extras — hier werden Punkte gewonnen oder verloren.

Drei Regeln zum Lesen jeder Benchmark-Punktzahl:

1. Frag, was die Punktzahl verbirgt. Ein Modell, das mit öffentlichen GitHub-Daten trainiert wurde, könnte genau die Issues bereits gesehen haben, auf denen es getestet wird — Datenkontamination kann Punktzahlen ohne echten Fähigkeitsgewinn erhöhen. Reproduzierbare Umgebungen und zurückgehaltene Aufgabensammlungen sind das Gegenmittel.

2. Vorsicht vor Goodharts Gesetz: Wenn eine Kennzahl zum Ziel wird, taugt sie nicht mehr als Kennzahl. Ein Harness, das auf Spitzenwerte in einem Benchmark abgestimmt ist, lernt möglicherweise benchmarkspezifische Tricks statt allgemeiner Fähigkeiten — deshalb bewerten ernsthafte Teams mit mehr als einem Benchmark.

3. Prüf das Harness, nicht nur das Modell. Wie der Rest dieses Abschnitts zeigt, kann dasselbe Modell je nach Gerüst 2,7 % oder 28,3 % erreichen. Eine Punktzahl ohne benanntes Harness ist eine Anekdote, keine Messung.

Die ursprüngliche SWE-bench-Arbeit ("Can Language Models Resolve Real-World GitHub Issues?") führte die inzwischen kanonische Bewertung ein: Ein Modell erhält ein echtes GitHub-Issue und das vollständige Repository; bewertet wird, ob sein Patch fehlschlagende Tests bestehen lässt. Das meistzitierte Ergebnis wird oft falsch verstanden: Das damals beste Modell, Claude 2, löste nur 1,96 % der Aufgaben. Die Autoren selbst ordneten dies so ein, dass der Benchmark „komplexes Schlussfolgern testete, das weit über die herkömmliche Codegenerierung hinausgeht“ — doch spätere Arbeiten machten deutlich, dass ein großer Teil der Lücke nicht auf Schlussfolgerungsfähigkeit zurückging, sondern auf das Fehlen eines Harnesses, das ein Repository durchsuchen, Tests ausführen und iterieren konnte. Anders gesagt: SWE-bench maß nicht nur Modelle; es zeigte, dass das Harness um sie herum das fehlende Element war.

Die SWE-agent-Arbeit ("Agent-Computer Interfaces Enable Automated Software Engineering") ist das Gründungsdokument des Feldes für Harness-Design. Ihre zentrale Aussage lautet, dass Schnittstellendesign eine Variable erster Ordnung ist: Die Autoren führten den Begriff Agent-Computer Interface (ACI) ein und zeigten, dass eine speziell entwickelte Schnittstelle — ein durch Linter abgesicherter Dateieditor, prägnantes Shell-Feedback, Schutzvorkehrungen gegen fehlerhafte Befehle — pass@1 auf SWE-bench von niedrigen einstelligen Werten auf 12,5 % steigerte, damals der Stand der Technik. Der bleibende Beitrag der Arbeit ist das Argument, dass „LM-Agenten eine neue Kategorie von Endnutzern darstellen“, die Software benötigen, die für sie gebaut wurde, so wie Menschen IDEs benötigen. Jede nachfolgende Arbeit zu Harnesses zitiert dieses Ergebnis.

Zwei Arbeiten aus dem Jahr 2024 erweiterten die Harness-Forschung von Code-Repositorys auf den gesamten Computer. OSWorld schuf die erste skalierbare Umgebung für echte Computer über Ubuntu, Windows und macOS hinweg, mit 369 Aufgaben aus Web- und Desktop-Apps. Seine Schlagzeilenzahl — Menschen erledigen 72,36 % der Aufgaben, das beste Modell 12,24 % — identifizierte GUI Grounding (die Übersetzung der Modellausgabe in korrekte Klicks und Tastatureingaben) als dominierenden Fehlermodus, also als Harness- und nicht als Wissensproblem. WebArena verfolgte einen anderen Ansatz: eine selbstgehostete, vollständig reproduzierbare Webumgebung (E-Commerce, Foren, GitLab, CMS), in der GPT-4 nur 14,41 % End-to-End-Erfolg gegenüber 78,24 % bei Menschen erreichte. Beide Arbeiten zeigten, dass die Bewertung von Harnesses ausführungsbasiert sein muss — also den Endzustand der Umgebung prüft — und nicht auf Musterabgleich von Modellausgaben beruhen darf.

Sierra's τ-bench ("A Benchmark for Tool-Agent-User Interaction in Real-World Domains") machte einen subtileren Punkt: Im Produktionseinsatz umschließt das Harness nicht nur das Modell und die Umgebung — es vermittelt auch den Nutzer. Der Benchmark simuliert dynamische Gespräche zwischen einem Sprachmodell-Nutzer und einem agent mit domänenspezifischen APIs und Richtlinien und bewertet anschließend den endgültigen Datenbankzustand. Seine zentrale Kennzahl, pass^k (Erfolg über k unabhängige Durchläufe), zeigte, wie inkonsistent agents sind: GPT-4o löste weniger als 50 % der Aufgaben auch nur einmal, und pass^8 fiel im Einzelhandel unter 25 %. Die Lehre für Harness-Entwickler ist, dass Zuverlässigkeit eine Verteilungseigenschaft und keine Eigenschaft eines einzelnen Durchlaufs ist — ein Harness, das einmal funktioniert, ist kein funktionierendes Harness.

METRs "Measuring AI Ability to Complete Long Software Tasks" führte den 50-%-Aufgabenabschluss-Zeithorizont ein: die Länge einer Aufgabe (gemessen an der menschlichen Bearbeitungszeit), die ein Modell mit 50 % Zuverlässigkeit abschließt. Spitzenmodelle stiegen zwischen 2019 und 2025 von Minuten auf ungefähr eine Stunde, mit einer Verdopplung etwa alle sieben Monate. Für die Harness-Entwicklung ist dies die folgenreichste Erkenntnis des Jahrzehnts: Das Harness, das ein Modell von 2024 einschränkt, ist für ein Modell von 2026 Ballast. Anthropic formuliert es so, dass jede Komponente eines Harnesses eine Annahme darüber enthält, was das Modell nicht kann — und diese Annahmen mit besser werdenden Modellen veralten.

Der ursprüngliche Benchmark ist zu einem Ökosystem gewachsen, das diese Erkenntnisse umsetzt:

• SWE-bench Verified (mit OpenAI, 2024): eine von Menschen gefilterte Teilmenge mit 500 Instanzen, aus der unzureichend spezifizierte oder unfair bewertete Aufgaben entfernt wurden — 68,3 % des ursprünglichen Pools wurden herausgefiltert, wodurch sich die gemessenen Punktzahlen mehr als verdoppelten und die Standard-Bestenliste entstand.

• SWE-smith (2025): eine Pipeline zur Generierung synthetischer Trainingsaufgaben, damit Modelle für agentische Harnesses trainiert und nicht nur darauf bewertet werden können.

• mini-SWE-agent (2025): das etwa 100 Zeilen lange Harness, das inzwischen auf SWE-bench Verified über 74 % erreicht. Es zeigt, dass eine minimale, reine bash-Schleife mit linearer Historie ausreicht, sobald das Modell stark genug ist — und wird zum Standard-Baseline der Community.

• Terminal-Bench (Stanford × Laude, 2025): Bewertung von Terminalaufgaben auf Basis des Harbor-Frameworks, die Harnesses über die Codebearbeitung hinaus in die Systemadministration führt.

• CodeClash (2025) und ProgramBench (2026): zielorientierte Softwareerstellung und Softwareentwicklung von Grund auf, die Harnesses von Korrekturen einzelner Issues auf offene Entwicklung erweitern.

Der rote Faden in all diesen Arbeiten ist konsistent: Das Harness ist nicht bloß Infrastruktur, sondern der Forschungsgegenstand. Berichte das Harness zusammen mit der Punktzahl, halte die Umgebung reproduzierbar und begegne jedem Ergebnis mit Skepsis, dessen Harness nicht überprüft werden kann.

Bei Open-Source-Harnesses beginnen die meisten Teams. Die folgenden Projekte verbinden große GitHub-Communities — die führenden mit Zehntausenden von Stars — mit aktiver Wartung:

Bei der Auswahl gilt in der Community als Faustregel: Nutze das minimalste Harness, das deine Aufgabe abbildet (die Philosophie von mini-SWE-agent), und erhöhe die Komplexität nur, wenn ein gemessener Fehler dies erfordert. DeepSeek Harness nimmt das andere Ende des Spektrums ein – eine vollständig Plugin-gesteuerte Plattform für Teams, die jede Ebene austauschbar gestalten wollen. Beide folgen jedoch derselben Disziplin: einem dauerhaften, ausschließlich erweiterbaren Sitzungsprotokoll als einziger verlässlicher Quelle dafür, was das Modell gesehen hat.

Die führenden Forschungslabore betrachten Harness-Engineering als zentrales geistiges Eigentum, und mehrere haben ihre Überlegungen ungewöhnlich detailliert veröffentlicht.

Anthropic hat die umfassendste öffentliche Dokumentation zum Harness-Engineering veröffentlicht. Seine Architektur – beschrieben in Building Effective Agents (2024), dem Beitrag zum SWE-bench-Harness (2024) und Managed Agents (2026) – lässt sich als drei konzentrische Ebenen lesen.

Die Ausführungsebene ist bewusst minimal gehalten: ein Bash-Tool zum Ausführen von Befehlen und ein Edit-Tool zum Anzeigen und Ändern von Dateien. Der Entwicklungsaufwand floss in die Fehlersicherheit dieser Tools – durch die Vorgabe absoluter Pfade, das Kürzen langer Ausgaben und das Anwenden von Änderungen nur bei einem eindeutigen String-Treffer –, damit das Modell sich nur selten von vermeidbaren Tool-Fehlern erholen muss.

Die Sitzungsebene ist ein dauerhaftes, ausschließlich erweiterbares Ereignisprotokoll außerhalb des Kontextfensters des Modells. Jede Aktion und Beobachtung wird dort aufgezeichnet; der Kontext des Modells ist eine Projektion dieses Protokolls, nicht das Protokoll selbst. Diese Trennung ermöglicht es, einen fehlgeschlagenen Harness-Prozess neu zu starten und mitten in der Aufgabe fortzusetzen, und macht das Harness zu einer austauschbaren Ressource statt zu einem individuell gepflegten System.

Die Orchestrierungsebene – von Anthropic als „Meta-Harness“ bezeichnet – entkoppelt über explizite Schnittstellen das „Gehirn“ (das Modell und seine Schleife) von den „Händen“ (Sandboxes und Tools). Da das Gehirn nicht mehr im Ausführungscontainer lebt, können Sandboxes bei Bedarf bereitgestellt und Zugangsdaten in einem Vault verwahrt werden, den die Sandbox nie berührt. Der berichtete Nutzen ist strukturell, nicht kosmetisch: Die p50-Zeit bis zum ersten token sank um rund 60 % und p95 um über 90 %, weil Sitzungen nicht länger auf Container warten, die sie möglicherweise nie verwenden.

Drei Dokumente zeichnen diese Entwicklung nach: Building Effective Agents (2024), der Beitrag zum SWE-bench-Harness (2024) und Managed Agents (2026).

OpenAI arbeitete mit dem SWE-bench-Team zusammen, um den von Menschen validierten Verified-Split zu erstellen, gerade weil Harnesses saubere Aufgaben benötigen: Ihre Annotationkampagne (93 Entwickler, 1.699 Samples) ergab, dass 68,3 % der Aufgaben des ursprünglichen Benchmarks problematisch waren; durch deren Entfernung verdoppelte sich die gemessene Leistung mehr als. Derselbe Beitrag stellt fest, dass allein die Wahl des Harness GPT-4 bei SWE-bench Lite von 2,7 % auf 28,3 % brachte – eine Differenz, mit der sie begründen, dass Evaluierungen Fortschritte bei von der Community entwickelten Harnesses berücksichtigen müssen.

Auf der Open-Source-Seite wird die Codex CLI als vollständiges Referenz-Harness ausgeliefert. Ihre Architektur ist ähnlich geschichtet wie die anderen Systeme in diesem Abschnitt: Eine zentrale agent-Schleife übernimmt Planung und Tool-Aufrufe; eine Sandbox-Ebene isoliert die Ausführung mit konfigurierbaren Richtlinien je Aufgabe; eine Sitzungsebene speichert Gespräche dauerhaft, damit sie fortgesetzt, verzweigt oder kompaktiert werden können; und eine Tool-Ebene bietet sowohl lokalen Shell-Zugriff als auch MCP-basierte externe Tools. Statt eine einzige Schnittstelle fest zu verdrahten, wird dieselbe Engine über drei Oberflächen bereitgestellt – eine Terminal-UI für interaktive Arbeit, einen JSON-RPC-App-Server für umfangreiche Clients wie VS Code und einen Remote-Code-Ausführungsdienst für Cloud-Sandboxes –, sodass das Harness lokal laufen oder programmatisch gesteuert werden kann. Das Design folgt denselben Abwägungen, die die Forschungsliteratur empfiehlt: minimale Schleife, starke Sandbox, explizites Kontextmanagement und eine klare Grenze zwischen dem Modell und der Außenwelt.

Mit dem Agent Development Kit (ADK) und dem Agent2Agent-(A2A)-Protokoll – die im April 2025 mit mehr als 50 Technologiepartnern, darunter Atlassian, Salesforce, SAP und ServiceNow, eingeführt wurden – macht Google die Harness-Schicht zum Produkt. A2A standardisiert, wie agents Fähigkeiten anbieten (über JSON-„Agent Cards“), lang laufende Aufgaben verwalten, Artefakte austauschen und UI-Formate aushandeln, sodass Harnesses zu interoperabler Infrastruktur statt maßgeschneiderter Verbindungslogik werden. Es ist ausdrücklich als Ergänzung zu Anthropics Model Context Protocol (MCP) konzipiert, das die Tool-Seite des Harness standardisiert.

Microsofts AutoGen und Magentic-One liefern Harnesses, bei denen ein Orchestrator-agent ein Verzeichnis von Fakten und Fortschritten verwaltet – ein veröffentlichtes Design, das die unbeschränkten Schleifen verhindern soll, unter denen naive Harnesses leiden. GAIA von Meta und Hugging Face schuf einen Benchmark für allgemeine Assistenten, dessen Harness praxisnahe Fragen bewertet, die Webnavigation und Dateiverarbeitung erfordern; Hugging Faces Open Agent Leaderboard treibt vergleichbare, Harness-bewusste Rankings weiter voran.

DeepSeek Harness (dsh) greift die Idee des Meta-Harness auf und macht sie kombinierbar. Seine Architektur basiert auf dem Cordis-Framework, und seine zentrale Aussage lautet: Jeder Teil des Harness ist ein austauschbares Plugin – einschließlich Modelladapter, Tool-Registry, Sitzungsprotokoll und agent-Schleife selbst.

Das Design beruht auf drei Grundbausteinen. Erstens ein dauerhaftes Sitzungsprotokoll als einzige verlässliche Quelle dafür, was das Modell gesehen hat; alles, was das Modell erreicht, muss anhand des Protokolls rekonstruierbar sein, erzwungen als Laufzeitinvariante. Zweitens Fähigkeitsschnittstellen: eine austauschbare Provider-Schnittstelle zwischen dem agent und der Außenwelt. Werden die Provider für Dateisystem und Unterprozesse auf eine Remote-Sandbox ausgerichtet, wandern Bash-, Terminal- und Sprachserverzugriff mit, ohne das Harness abzuspalten. Drittens ein expliziter Zug-/Schritt-Lebenszyklus mit benannten Erweiterungsereignissen (agent/pre-step, tools/execute, agent/turn-stopping), über die Plugins die Schleife abfangen oder umschreiben können, ohne den Kerncode zu ändern.

Das Ergebnis kommt Anthropics Meta-Harness unter den Open-Source-Implementierungen am nächsten: ein Harness, dessen Struktur kein festes Framework ist, sondern eine Zusammenstellung von Plugins, die über die Konfiguration ausgetauscht werden können. Mit über 170.000 GitHub-Stars in den ersten Monaten signalisiert es, dass das Agent-Harness zu einer eigenständigen Produktkategorie wird.

Das gemeinsame Muster bei allen: Halte die Schleife einfach, isoliere alles in Sandboxes, protokolliere jeden Schritt und vertraue nie einem Ergebnis ohne das Harness, das es erzeugt hat.

Alles in diesem Abschnitt bisher – die minimalen Schleifen, die dauerhaften Sitzungsprotokolle, die Ausführung in Sandboxes, die Plugin-Architekturen – beruht auf einer Annahme: Die Umgebung des agent ist ein Computer. Ein Terminal, ein Browser, ein Dateisystem, ein Repository. Das Harness existiert, damit der agent diese Maschine zuverlässig bedienen kann.

Doch die oben nachgezeichnete Forschungsentwicklung weist in eine andere Richtung. τ-bench holte den Nutzer in das Harness. METR zeigte, dass agents Arbeiten übernehmen, die Tage statt Minuten dauern. OSWorld und WebArena verlagerten die Umgebung von einem sauberen Repository in die unordentliche reale Welt. Die Richtung ist eindeutig: Wenn agents sich von Coding-Tools zu echten Arbeitsassistenten entwickeln, ist die Umgebung, in der sie navigieren müssen, nicht mehr nur Silizium – sondern Menschen. Nutzer mit Erwartungen, Teams mit Geschichte, Organisationen mit Berechtigungen und institutionellem Wissen.

Dieser Wandel betrifft vor allem ein Subsystem des Harness: das Kontextmanagement. Eine Terminalsitzung hat einen Bediener und eine begrenzte Historie; eine langfristige Zusammenarbeit hat zehn Beteiligte, Entscheidungen aus Monaten und ein stetig wachsendes Repository. Ein Dateisystem ist passiv; eine Arbeitsbeziehung ist ein Strom impliziter Zusagen, halbfertiger Gedanken und beiläufig getroffener Entscheidungen. All das muss zusammengefasst, verdichtet oder verworfen werden, bevor es das Modell erreicht, und jede dieser Entscheidungen ist eine Stelle, an der der agent etwas verliert, das die Aufgabe benötigte.

Ein Harness kann verdichten, aber nicht beliebig. Deshalb ist die Größe des Kontextfensters nicht länger eine Modellspezifikation, sondern ein Designparameter des Harness.

Das Harness-Portfolio von Moonshot AI überträgt die zuvor in diesem Artikel beschriebene Anatomie auf einen verwalteten Stack. Für das Problem Agent × Computer erweitern seine Harnesses die Standardschleife: Kimi Browser Extension steuert über das Chrome DevTools Protocol eine echte Browsersitzung statt einer sterilen Sandbox, eine Vor-dem-Handeln-nachfragen-Schnittstelle erzwingt Zustimmung auf Dateisystemebene, und ein Agent Swarm skaliert die Orchestrierung für Aufgaben mit langem Horizont auf 300 Sub-agents.

Angetrieben wird diese Schleife von Kimi K3.1 Pro – dem ersten Modell der K3.1-Serie und Moonshot AIs bislang leistungsfähigstem Open-Weight-Modell der 3T-Klasse mit einem Kontextfenster von 1.048.576 token. Drei seiner Eigenschaften betreffen das Harness-Design unmittelbar:

• Ein Fenster, das groß genug ist, um die Verdichtung aufzuschieben. Eine Million token fassen ein Arbeits-Repository, die laufende Trajektorie und die Referenzdokumente gleichzeitig. Das Harness kürzt weiterhin – das muss es immer –, doch die Schwelle, ab der Zusammenfassungen Informationen zerstören, verschiebt sich weit genug nach hinten, sodass Aufgaben mit langem Horizont nicht mehr unbemerkt auf halber Strecke an Qualität verlieren.

• Reasoning-Aufwand als Stellknopf des Harness. K3.1 Pro denkt immer, und reasoning_effort akzeptiert low, high oder max, wobei max der Standardwert ist. Damit werden die Reasoning-Kosten des Modells zu einem aufgabenbezogenen Budget, das das Harness festlegt, statt zu einem festen Eintrittspreis.

• Tools, die mitten in der Ausführung hinzukommen. Durch dynamisches Laden von Tools kann das Harness eine vollständige Tool-Definition in eine Systemnachricht einfügen, sodass ein Tool ab dieser Nachricht verfügbar ist – ohne Neustart und ohne bei jedem Zug eines Gesprächs, das es nie verwendet, für sein Schema zu bezahlen.

Moonshot berichtet über das Harness zusammen mit dem Modell – genau die Praxis, für die der restliche Artikel argumentiert. Bei Terminal-Bench 4.0 – das Coding-agents anhand realistischer, ressourcenbeschränkter Terminalaufgaben unter strengen aufgabenspezifischen Tests bewertet – erreicht K3.1 Pro 65,7 %, vor GPT-6 Astra (58,2 %) und knapp hinter Claude Opus 5.5 (66,4 %). Bei Kimi Code Bench 3.0 Long-horizon, einem internen Benchmark für mehrstufige Ausführung, Tool-Nutzung und End-to-End-Problemlösung, erzielt es 61,2 % gegenüber 55,95 % für K3. Die Dokumentation beschreibt die Kopplung in umgekehrter Richtung ebenso deutlich: Sampling-Parameter wie temperature und top_p sind festgelegt und dürfen in Anfragen nicht enthalten sein, und die vollständige Assistentennachricht muss über mehrere Züge hinweg unverändert zurückgegeben werden – ein Harness, das die Nachricht umschreibt, verliert das Reasoning, von dem der nächste Tool-Aufruf abhängt.

Dasselbe Modell läuft über die gesamte Oberfläche hinweg. Du kannst die verwaltete Webversion über Kimi Agent ausprobieren, das vollständige lokale Harness mit Kimi Work ausführen, mit Kimi Code im Terminal arbeiten oder kimi-k3.1-pro direkt über die Kimi API aufrufen. Eine Variante namens kimi-k3.1-pro-highspeed tauscht etwa den doppelten token-Preis gegen die zwei- bis dreifache Ausgabegeschwindigkeit.

Ob du Modelle bewertest oder ein Produkt auslieferst, dieselbe Checkliste gilt:

1. Geh von der Aufgabe aus, nicht vom Framework. Wenn deine agents Code bearbeiten, ist ein Bash-plus-Editor-Harness wie SWE-agents ACI erprobt. Wenn sie GUIs oder das Live-Web steuern, brauchst du Beobachtungen aus echten Sitzungen und Aktionen auf Klickebene.

2. Sorge für reproduzierbare Umgebungen. Docker-Images, fixierte Abhängigkeiten und mit Seeds erzeugte Daten machen den Unterschied zwischen einem Benchmark und einer Anekdote aus.

3. Plane das Kontextfenster bewusst ein. Das Kürzen von Beobachtungen, das Zusammenfassen der Historie und die Verdichtung sind Harness-Funktionen, die Ergebnisse und Kosten direkt beeinflussen – und der Grund, warum Modelle mit langem Kontext verringern, wie viel das Harness verwerfen muss.

4. Setze harte Grenzen durch. Schrittlimits, Wall-Clock-Timeouts und Dollarbudgets pro Episode halten agents sicher und Bewertungen vergleichbar.

5. Protokolliere vollständige Trajektorien von Anfang an. Jede ernsthafte Verbesserungsschleife – menschliche Überprüfung, Bündelung von Fehlern, Fine-Tuning – nutzt Trajektoriendaten. Anthropics Managed Agents und DeepSeek Harness gehen noch weiter: Sie halten das Sitzungsprotokoll als reinen Anhang-Ereignisstrom außerhalb der Harness-Schleife, sodass das Harness selbst austauschbar ist und der Kontext des Modells stets rekonstruiert werden kann.

6. Bewerte mit mehr als einem Harness. Wenn dein agent nur innerhalb eines Harness funktioniert, hast du Harness-spezifisches Verhalten gebaut, keine Fähigkeit.

7. Halte Zugangsdaten aus der Sandbox – oder vollständig aus der Cloud. Betrachte die Ausführungsumgebung des agent als nicht vertrauenswürdig; bewahre token in einem Vault auf und speise sie über einen Proxy ein oder führe die gesamte Sitzung lokal aus, damit Zugangsdaten und Seiteninhalte das Gerät nie verlassen – so wie Kimi es mit seinen lokalen Harnesses macht.

Das Agent-Harness ist still und leise zur wichtigsten Schicht des agentischen Stacks geworden. Forschung aus SWE-bench, mini-SWE-agent, Terminal-Bench und METR zeigt, dass das Harness-Design in seiner Wirkung Modell-Upgrades ebenbürtig sein kann; Open-Source-Projekte wie DeepSeek Harness, OpenHands, SWE-agent und Aider machen produktionsreife Harnesses für alle zugänglich; und Anthropic, OpenAI, Google, Microsoft und Moonshot AI behandeln Harness-Engineering inzwischen als Arbeit erster Klasse.

Der tiefere Wandel ist jedoch konzeptionell. Die erste Generation von Harnesses löste Agent × Computer: Sie gab einem Modell zuverlässige Hände für ein Terminal, einen Browser und ein Dateisystem. Die nächste Generation löst das Kontextproblem, das diese Umgebungen schaffen – Arbeit, die sich über Tage, Beteiligte und Repositories erstreckt und die kein Zusammenfasser verlustfrei verdichtet. Das Harness entwickelt sich vom Gerüst zur Betriebsumgebung, und die Grenze zwischen dem, was das Harness verwalten muss, und dem, was das Modell einfach behalten kann, verschiebt sich fortlaufend. Das Kontextfenster von einer Million token bei Kimi K3.1 Pro ist das derzeit deutlichste Beispiel: eine Modelländerung, die Arbeit überflüssig macht, die das Harness früher erledigen musste.

Ob du ein eigenes baust, ein Open-Source-Framework übernimmst oder ein produktives Harness betreibst: Die Teams, die das Harness als technisch entwickeltes, versioniertes und messbares Softwareprodukt behandeln, sind diejenigen, deren agents die Aufgabe tatsächlich abschließen.