Was ist ein Agent Harness? Wie KI-Agenten Tools, Speicher und Kontrolle erhalten

Die Idee ist nicht brandneu. Entwicklerinnen und Entwickler bauen seit Jahren Wrapper, Gerüste und Ausführungsumgebungen rund um Modelle. Der Begriff verbreitete sich, nachdem Mitchell Hashimoto, Mitgründer von HashiCorp, in einem Blogpost im Februar 2026 seinen KI-Workflow als "Harness Engineering" bezeichnete. Seine Botschaft war simpel: Wenn ein Agent einen Fehler macht, verändere die Umgebung so, dass dieser Fehler nicht noch einmal passieren kann. OpenAI griff den Begriff in derselben Woche für die Arbeit an Codex auf, und LangChain folgte mit derselben Einordnung.

In diesem Artikel erkläre ich, was ein Agent Harness ist, warum KI-Agenten eines brauchen, wie es sich von Frameworks und Runtimes unterscheidet und mit welchen Tools Entwicklerinnen und Entwickler harness-ähnliche Systeme bauen.

Was ist ein Agent Harness?

Eine Definition kommt von LangChain: "If you're not the model, you're the harness." In der Praxis ist ein Agent Harness die Software rund um ein Sprachmodell: Tools, Speicher, Status, Ausführung, Guardrails und Observability.

Agent = Modell + Harness

Das Modell schlussfolgert. Das Harness gibt diesen Schlussfolgerungen einen Ort zum Handeln, zum Erinnern, zum Prüfen von Ergebnissen und zum Einhalten von Regeln.

Modell in seinem arbeitenden Agent Harness. Abbildung: Autor.

Die Formel ist nützlich, aber sie ist ein Denkmodell, kein Industriestandard. Einige Anbieter verwenden weiterhin "Harness", "Framework" und "Scaffold" weitgehend synonym.

Warum KI-Agenten ein Harness brauchen

Ein nacktes Sprachmodell stößt bei Aufgaben mit vielen Schritten an Grenzen. Es hält keinen dauerhaften Zustand, führt nicht selbstständig Tools aus, verwaltet kein wachsendes Kontextfenster und erholt sich nicht ohne Hilfe von fehlgeschlagenen Tool-Aufrufen. 

Stell dir einen Agenten vor, der einen fehlschlagenden Test in einem Python-Projekt beheben soll. Ohne Harness kann das Modell zwar einen vermeintlichen Fix schreiben, aber es kann nicht die tatsächliche Testdatei lesen, pytest ausführen, den echten Fehler sehen, die fehlerhafte Funktion bearbeiten oder bestätigen, dass der Fix greift. Mit Harness wird dieser gesamte Zyklus zu ein paar Minuten Arbeit, die der Agent eigenständig erledigt – jeder Schritt an einem Ort protokolliert, den ein Mensch einsehen kann.

Anthropics Leitlinie gilt dennoch: Starte so einfach wie möglich und füge nur dann bewegliche Teile hinzu, wenn die Aufgabe sie wirklich braucht.

Woraus ein Agent Harness besteht

Die Teile variieren, aber die meisten teilen sich einige Bausteine. Denk daran als Checkliste, nicht als strenge Produktspezifikation. Ein kleiner Agent braucht vielleicht nur wenige dieser Bausteine, ein produktiver Agent deutlich mehr.

Systemprompts und Verhaltensregeln

Das Harness steuert in der Regel die grundlegenden Anweisungen für das Modell. Dazu gehört der Systemprompt, aber auch Projektrichtlinien, Codestandards, Rollenbeschränkungen und Sicherheitsregeln. In LangChains Deep Agents kann zum Beispiel eine AGENTS.md-Datei die Spielregeln festlegen, bevor eine Aufgabe startet.

Einige Harnesses in 2026 nutzen zudem progressive Offenlegung von Anweisungen. Statt beim Start alle Tool-Beschreibungen in den Kontext zu laden, fügt das Harness nur eine Zusammenfassung der verfügbaren Tools hinzu. Vollständige Anweisungen werden erst dann geladen, wenn das Modell das jeweilige Tool wirklich braucht.

Tools: wie Agenten mit der Welt interagieren

Tools ermöglichen dem Agenten mehr als nur Text zu generieren. Häufige Beispiele sind Websuche, Datei lesen und schreiben, Datenbankabfragen, API-Aufrufe, Browseraktionen, Codeausführung und Terminalbefehle. Das Harness steuert, welche Tools verfügbar sind, wann das Modell sie aufrufen darf und wie Ergebnisse formatiert und in den Kontext des Agenten zurückgegeben werden.

Model Context Protocol (MCP) hat sich 2026 als Standardschnittstelle dafür etabliert. Viele Harnesses, darunter das Anthropic Agent SDK, LangChain Deep Agents und das OpenAI Agents SDK, nutzen MCP, um externe Tool-Server anzubinden, ohne für jedes Tool eigene Integrationslogik schreiben zu müssen.

Speicher und Zustand

Agenten müssen wissen, was zuvor in einer Aufgabe passiert ist. Ein Harness kann kurzfristigen Zustand in der aktiven Unterhaltung und längerfristigen Zustand in Dateien, Logs, Zusammenfassungen oder gespeicherten Präferenzen halten. Manche Harnesses verdichten lange Verlaufsdaten zu kürzeren Summaries, damit das Modell nicht jedes Detail im Kontext mittragen muss.

Ausführungsumgebung: wo der Agent läuft und handelt

Viele nützliche Agenten brauchen einen Ort, an dem sie tatsächlich arbeiten. Das kann ein Dateisystem, ein Container, ein abgeschottetes Terminal, eine Browserinstanz oder eine Cloud-Runtime sein. Ohne eine vom Harness verwaltete Ausführungsumgebung haben Tool-Aufrufe keinen Zielort.

Viele Harnesses setzen inzwischen auf isolierte Sandbox-Container: kurzlebige Umgebungen für eine einzelne Session, die nach Abschluss bereinigt werden, damit Dateiänderungen, installierte Pakete und Netzwerkaufrufe einer Aufgabe nicht in eine andere hinüberlaufen.

Orchestrierung und Planung

Manche Aufgaben folgen keinem geraden Ablauf. Das Harness kann ein Planungstool bereitstellen, das ein Ziel in Teilaufgaben bricht und deren Status verfolgt. Es kann auch Subagenten starten, die jeweils einen Teil erledigen und nur eine Zusammenfassung an den Hauptagenten zurückgeben.

LangChain Deep Agents protokolliert zum Beispiel die Planungsschritte in einer Datei im Dateisystem und aktualisiert die Schritte von "ausstehend" zu "abgeschlossen", während die Aufgabe läuft.

Guardrails und Berechtigungen

Im Harness legst du Regeln fest: menschliche Freigaben, blockierte Tool-Aufrufe, rollenbasierte Berechtigungen und Output-Prüfungen. OpenAI Agents SDK, LangChain Deep Agents und Microsoft Agent Framework unterstützen diese Art von Kontrolle. Das sicherere Muster ist, Eingaben, Ausgaben und Tool-Berechtigungen getrennt zu prüfen.

Observability und Tracing

Wenn eine Fünfzig-Schritte-Aufgabe bei Schritt siebenunddreißig scheitert, zeigt ein Trace, was passiert ist. Tracing zeichnet Modellaufrufe, Tool-Aufrufe, Handoffs, Fehler, Latenz und Kosten über einen gesamten Lauf auf. Das OpenAI Agents SDK aktiviert Tracing standardmäßig. LangSmith ergänzt Debugging- und Evaluations-Dashboards. OpenTelemetry hat sich als Standard etabliert, um Traces in einem anbieterneutralen Format zu exportieren – so bist du nicht an ein einzelnes Observability-Tool gebunden.

Agent Harness vs. Framework vs. Runtime: Wo liegen die Unterschiede?

Diese Frage taucht oft auf, und die Antwort ist komplexer, als viele Erklärtexte vermuten lassen. Die Einordnung ist hilfreich, aber nicht in Stein gemeißelt.

Drei Schichten, mit zunehmender Abstraktion von unten. Abbildung: Autor.

Ich beginne mit dem Framework, denn viele Entwickler haben bereits eines genutzt.

Was ist ein Agent Framework?

Ein Agent Framework liefert Bausteine zum Erstellen von Agenten. Es deckt Modellaufrufe, Tool-Definitionen, Speichermuster und die Agent-Loop-Struktur ab. Beispiele sind frühes LangChain, CrewAI und Google ADK. Ein Framework sagt dir, wie du einen Agenten strukturierst – aber nicht zwingend, wie du ihn zuverlässig in Produktion betreibst.

Was ist eine Agent Runtime?

Eine Agent Runtime ist die Schicht, die hilft, einen Agenten über die Zeit verlässlich laufen zu lassen. Sie kümmert sich um langlebige Ausführung, Zustandsspeicherung, Retries, Human-in-the-Loop-Schritte und Streaming. LangGraph, Temporal und Inngest sind Beispiele. Harrison Chase brachte diesen Vergleich: Wenn Node.js die Runtime ist und Express das Framework, dann ist ein Harness wie Next.js.

Was macht ein Harness anders?

Ein Harness ist höher angesiedelt als ein Framework. Während ein Framework Komponenten liefert, kommt ein Harness meist mit mehr vorab getroffenen Entscheidungen: Tools, Planung, Dateisystemzugriff und Kontextmanagement.

Einsatzfälle für Agent Harnesses: Coding, Research, Data und Enterprise

Dieselben Bausteine tauchen in sehr unterschiedlichen Jobs auf, aber die Mischung variiert. Ein Coding-Agent und ein Enterprise-Workflow-Agent brauchen beide ein Harness, belasten aber unterschiedliche Teile davon. Diese Kategorien sind keine formalen Standards, sondern pragmatische Sichtweisen darauf, wie sich dieselbe Idee an die jeweilige Arbeit anpasst.

Coding-Agent-Harnesses

Coding-Agenten sind aktuell ein gutes Beispiel, weil das Harness hier sichtbar ist. Für nützliche Entwicklungsarbeit braucht ein Agent Dateizugriff, Git-Kontext, Terminalausführung, Testruns, Dependency-Installation und Projektrichtlinien. Claude Code und Codex folgen diesem Muster: Beide laufen auf viel Harness-Code, nicht auf einer nackten Modell-API.

Der Unterschied zwischen einem guten und einem mittelmäßigen Coding-Harness zeigt sich oft in Details: wie es sich von einem fehlgeschlagenen Test erholt, ob es einen schlechten Edit rückgängig machen kann und wie sauber es die Git-Historie dem Modell zugänglich macht. Genau in diese Details fließt der Großteil der Ingenieursarbeit.

Research-Agent-Harnesses

Research-Agenten brauchen eine andere Toolkette: Websuche, Quellenverfolgung, Notizen, Zitationsmanagement und Zusammenfassungen. Das Harness steuert, wie Suchergebnisse gespeichert werden, wie Quellen zugeordnet werden und wie lange Dokumente segmentiert und ausgelagert werden, um nicht das gesamte Kontextfenster auf einmal zu verbrauchen.

Datenanalyse-Agent-Harnesses

Datenagenten brauchen Zugriff auf Datensätze, SQL-Datenbanken, Python-Ausführungsumgebungen und Schema-Kontext, damit sie vor dem Schreiben von Abfragen wissen, welche Tabellen und Spalten verfügbar sind. Das Harness erzwingt außerdem Berechtigungsgrenzen – besonders wichtig, wenn der Agent Produktionsdaten berühren kann.

Enterprise-Workflow-Harnesses

Enterprise-Einsätze bringen zusätzliche Anforderungen: Authentifizierung, Audit-Logs, Freigabe-Workflows, rollenbasierte Zugriffskontrolle und Anbindungen an interne Systeme. AWS AgentCore ist ein gemanagtes Beispiel in dieser Kategorie – inklusive Identity, VPC-Netzwerk und Observability. Microsoft Agent Framework deckt Ähnliches für Teams in Azure- oder .NET-Umgebungen ab.

Tools zum Bauen von Agent-Harness-Systemen in 2026

Mitte 2026 taucht eine Handvoll Produkte am häufigsten auf. Sie liegen an unterschiedlichen Punkten auf dem Spektrum Framework–Runtime–Harness, und die Grenzen verschieben sich weiter.

LangChain Deep Agents

LangChain Deep Agents ist LangChains Open-Source-Harness, aufgebaut auf LangGraph als Runtime. Es wird mit Planungstool, virtuellem Dateisystem, Subagent-Spawning, automatischer Kontextkompaktierung sowie Middleware für Human-in-the-Loop-Freigaben und PII-Erkennung ausgeliefert. Es ist modellagnostisch, unterstützt OpenAI-kompatible Endpunkte und verbindet sich für Codeausführung mit Sandbox-Anbietern wie Modal, Runloop und Daytona.

Anthropic Agent SDK

Das Anthropic Agent SDK (Paketname: claude-agent-sdk) wurde aus Claude Code extrahiert und als eigenständige Option veröffentlicht. Es enthält eine integrierte Agent-Loop, Tools für Bash-Ausführung, Datei lesen/schreiben, Websuche, MCP-Integration und Kontextkompaktierung. Es funktioniert ausschließlich mit Claude-Modellen – über Anthropics API, Amazon Bedrock, Vertex AI und Azure.

OpenAI Agents SDK

Wie bereits erwähnt, ist das OpenAI Agents SDK mit wachsendem Funktionsumfang vom Framework ins Harness-Terrain gewechselt. Das April-2026-Release brachte native Sandbox-Ausführung, Memory-Kompaktierung und Dateisystem-Tools. Verfügbar in Python und TypeScript, unterstützt das SDK Toolnutzung, Agent-Handoffs und Guardrails.

Google Agent Development Kit

Google ADK unterstützt Multi-Agent-Orchestrierung mit eingebauten Klassen für sequentielle, parallele und schleifenbasierte Agent-Strukturen. Es enthält Evaluations-Tools, arbeitet mit Vertex AI für Managed Deployment und unterstützt MCP für Tool-Konnektivität. Verfügbar in Python, Java, TypeScript und Go; optimiert für Gemini-Modelle, aber als modellagnostisch beschrieben.

Microsoft Agent Framework

Microsoft Agent Framework ist Microsofts aktueller Migrationspfad für AutoGen-Projekte. Es unterstützt Python und .NET, arbeitet mit Azure AI Services und bringt MCP-Unterstützung für Tool-Konnektivität mit.

CrewAI

CrewAI verfolgt einen rollenbasierten Ansatz für Multi-Agent-Systeme. Du definierst Agenten mit spezifischen Rollen, weist Aufgaben zu, stellst Crews zusammen und konfigurierst Speicher und Guardrails deklarativ. Das passt zu Problemen, die sich natürlich auf ein Spezialistenteam abbilden lassen.

Temporal und Inngest

Beides sind für sich genommen keine Agent-Harnesses. Es sind Plattformen für langlebige Ausführung, die einspringen, wenn eine Agentenaufgabe stunden- oder tagelang laufen muss, ohne den Zustand zu verlieren. Im Fehlerfall spielt die Engine ab dem letzten erfolgreichen Checkpoint erneut ab, statt ganz von vorn zu beginnen.

Herausforderungen und Trade-offs bei Agent Harnesses

Ein Harness erweitert die Möglichkeiten des Systems, aber jedes zusätzliche Tool, jede Berechtigung und jeder Agent eröffnet neue Fehlerpfade. Je länger Aufgaben dauern, desto unverzichtbarer werden Guardrails, Tracing und ein dauerhafter Zustand – sie sind das, was lange Läufe überhaupt rettbar macht.

Hinzu kommt ein Kopplungsrisiko, das Teams überrascht. LangChain berichtete von einem Sprung um 10 bis 20 Punkte auf einem tau2-bench-Subset nach dem Hinzufügen modellspezifischer Harness-Profile. Artificial Analysis machte in seinem Coding Agent Index einen ähnlichen Punkt: Ergebnisse von Coding-Agenten hängen vom Zusammenspiel aus Modell und Harness ab – mit deutlichen Unterschieden bei Kosten, Tokenverbrauch und Zeit pro Aufgabe. Das Modell blieb gleich. Prompts, Tools und Middleware drumherum änderten sich. Genau dieses Profil ist Harness-Arbeit.

Brauchst du wirklich ein Agent Harness?

Hier ist eine direkte Denkhilfe, ob du eines brauchst.

Du brauchst wahrscheinlich ein Harness, wenn auf dein System eines oder mehrere der folgenden Merkmale zutreffen:

• Es muss externe Tools verwenden
• Es muss Fortschritt über Sessions hinweg behalten
• Es muss Code in einer realen Umgebung ausführen
• Es koordiniert mehr als einen Agenten
• Es muss sich von Teilfehlern erholen, ohne Arbeit zu verlieren
• Es erfordert menschliche Freigabe

Du brauchst wahrscheinlich kein Harness, wenn die Aufgabe ein vorhersehbarer Workflow ist, bei dem jeder Schritt vorab feststeht.

Ein nützlicher Test: Wenn die Aufgabe mit einem einzigen Modellaufruf oder einem kleinen deterministischen Skript mit ein paar If-Abfragen lösbar ist, ist ein Harness vermutlich überdimensioniert. In dem Moment, in dem der Agent Entscheidungen treffen, Tools nutzen und über die Zeit auf Ergebnisse reagieren muss, beginnt das Harness echte Arbeit zu leisten.

Ein Muster, das ich immer wieder sehe: Teams greifen zu früh zum Harness und bauen Tracing und Sandboxing für eigentlich reine One-Shot-Textgenerierung. Der umgekehrte Fehler tut richtig weh: das Modell direkt auszuliefern und dann beim zweiten fehlgeschlagenen Test, dem dritten Tool-Call oder dem fünften Neustart zu merken, dass die nötige Infrastruktur fehlt.

Abschließende Gedanken

Wie gesagt: Anbieter verwenden nicht überall dieselben Begriffe, und die Grenze zwischen Framework, Runtime und Agent Harness verschiebt sich weiter.

Für einmalige Generierung ist ein Wrapper überflüssig. Für Agenten, die über lange Sessions handeln, erinnern und sich erholen müssen, wird das Agent Harness zu einem Hauptteil des Systems. Die Wahl des passenden Harnesses ist zunehmend eine eigene Entscheidung – getrennt von der Modellwahl. Spannend wird sein, wie viel von dieser Schicht die nächste Modellgeneration selbst absorbiert, denn einige Bewegungen bei OpenAI und Anthropic deuten darauf hin, dass sich die Grenze weiter verschiebt. Der Grundgedanke bleibt: Ein Agent ist ein Modell plus ein Agent Harness.

Wenn du mehr über den Bau von Agentensystemen lernen willst, deckt unser Kurs Building Scalable Agentic Systems die Muster hinter Toolnutzung, Orchestrierung und langlebigen Agent-Workflows ab.