Was ist eigentlich ein Harness in der KI?

Vor kurzem habe ich gesehen, dass OpenClaw als Harness bezeichnet wird. Ich dachte: „Das ist interessant. OpenClaw ist kein Harness. Es ist wie eine Agenten-Runtime – es treibt den Agenten-Loop an.“ Was bedeutet also das Wort „Harness“ überhaupt?

Die bisherige Diskussion

Die strukturelle Basis für das Konzept stammt aus dem Artikel von Birgitta Böckeler vom April 2026, der einen Agenten elegant als Modell + Harness = Agent definiert. Sie hat den Stack in einen Builder Harness (die mit dem Tool ausgelieferte innere Runtime) und einen User Harness (den benutzerdefinierte Kontext des Entwickelnden) aufgeteilt. Diese Definition baut auf einer Diskussionswelle vom Februar 2026 auf. Diese umfasst den pragmatischen Ansatz von Mitchell Hashimoto für das Engineering von AGENTS.md-Kontexten, den Überblick von OpenAI über das interne Harness Engineering für automatisiertes Deployment sowie die ursprüngliche Zusammenfassung von Böckeler.

5 Schichten, von außen nach innen

Ich denke, ein Agent besteht aus mehr als nur Modell und Harness. Für mich beginnt das mit der Beobachtung, dass wir der Agent-Runtime nicht einfach vertrauen können. Um Sicherheit in der Softwarelieferkette des von einer Agenten-Fabrik erzeugten Codes zu gewährleisten, benötigen wir eine separate Sandbox-Schicht. Mit dieser können wir Informationen zur Herkunft erfassen und die möglichen Auswirkungen eines außer Kontrolle geratenen Agenten begrenzen.

Ich stelle mir diese sichere Agenten-Runtime-Architektur wie eine Matroschka- Puppe vor:

Infrastruktur → Sandbox → Agenten-Harness → Runtime → Modell

Jede Schicht hat einen anderen Eigentümer, einen anderen Fehlermodus und ein anderes Designprinzip. Sehen wir uns diese an.

Schicht 1: Infrastruktur

Die Agenten werden physisch in der Infrastruktur ausgeführt. Dabei kann es sich um GitHub Actions-Runner, Kubernetes-Pods oder virtuelle Maschinen (VMs) handeln. In dieser Schicht geht es um Computing, Networking und Ressourcenmanagement – und das ist wichtiger, als viele denken.

Stellen Sie sich vor, was passiert, wenn Sie von einem Agenten auf Dutzende skalieren, die parallel ausgeführt werden. Roy Belio hat das Autoresearch-System von Andrej Karpathy so konfiguriert, dass 198 autonome Experimente auf OpenShift AI durchgeführt wurden, darunter GPU-Scheduling und Job-Orchestrierung ohne menschliches Eingreifen. Das ist kein Harness-Problem. Das ist kein Sandbox-Problem. Es handelt sich um ein Infrastrukturproblem. Kann Ihre Plattform konkurrierende Ressourcenanforderungen verwalten, verhindern, dass sich gleichzeitige Agenten gegenseitig behindern, und GPU-Workloads planen?

Das GPU-Scheduling an sich entwickelt sich zu einer erstklassigen Infrastrukturdisziplin. Red Hat OpenShift 4.21 bietet eine dynamische Ressourcenzuweisung – eine Kubernetes-API, mit der Workloads GPUs anhand von Attributen (Modell, Speicher, Rechenleistung) anstatt nach Anzahl anfordern können. Sie ermöglicht auch die gemeinsame Nutzung von GPUs durch Container, sodass schlanke Inferenz-Sidecars nicht ein ganzes Gerät verschwenden. Das ist reine Infrastruktur – keine Sandbox-Richtlinie, kein AGENTS.md-Eintrag, keine Modellauswahl. Nur eine Plattform, die ihre Aufgabe erfüllt.

Schicht 2: Sandbox

Die Sandbox schränkt die Aktionen des Agenten ein und begrenzt die potenziellen Auswirkungen, wenn etwas schiefgeht. Es geht um Isolierung. Meine Kollegin, Marta Anon Ruiz, beschreibt diese Schicht so, dass sie „die Intentionalität des Agenten gestaltet“. Projekte wie OpenShell von NVIDIA werden auf dieser Schicht ausgeführt. Im Hinblick auf die Sicherheit der Softwarelieferkette stellt dies Ihre primäre Vertrauensgrenze dar. Dies ist der Unterschied zwischen einem Agenten, der rm -rf / ausführen kann, und einem, der dies nicht kann. Es ist zudem der Unterschied zwischen einem Agenten, der alle Ihre GitHub-Issues mit gh issue delete löschen kann, und einem, der dazu nicht in der Lage ist (oder einem, der ein eigenes Skript schreiben und ausführen kann, um dasselbe zu tun).

Wenn die Infrastruktur fragt: „Wo wird der Agent ausgeführt?“, fragt die Sandbox: „Was darf der Agent berühren?“ Dies sind unterschiedliche Fragen mit unterschiedlichen Antworten.

Red Hat hat einen ausführlichen Guide zum Thema Aufbau resilienter Leitplanken für KI-Agenten auf Kubernetes veröffentlicht, einschließlich restricted-v2 Security Context Constraints (SCC), Default-Deny-Egress-NetworkPolicies sowie rollenbasierter Zugriffskontrolle (RBAC) pro Agent. Dabei handelt es sich jeweils um eine subtraktive Kontrolle, bei der Sie mit sämtlichen Funktionen beginnen, die der Agent ausführen kann, und Funktionen entfernen, bis nur noch die erforderlichen verbleiben.

Die Sandbox-Schicht geht tiefer als Netzwerkrichtlinien. Red Hat OpenShift sandboxed containers, die auf Kata Containers und Peer-Pods basieren, ist eine Schlüsseltechnologie auf dieser Schicht, die zusätzliche Schritte zur Isolierung eines Agenten-Prozesses von seinem Host unternimmt. Lesen Sie auch den Artikel über Agent Skills und Sicherheitsbedrohungen, in dem Bedrohungen und Lösungen erläutert werden, einschließlich der kryptografischen Signierung von Agent Skills, mit denen Sie die Herkunft vor der Ausführung überprüfen können. Ein unsignierter Skill, der in die Toolchain eines Agenten injiziert wird, ist ein Angriff auf die Softwarelieferkette. Die Sandbox-Schicht kann dabei helfen, dies zu berücksichtigen.

Projekte wie OpenShell von NVIDIA sind für diese Schicht relevant, ebenso wie die in allgemeinen Container-Runtimes integrierten Sicherheitsprimitive. Keines davon ist ein „Harness“ im Sinne von Hashimoto: Sie bringen dem Agenten nicht bei, bessere Arbeit zu leisten, sondern verhindern, dass er gefährliche oder unerwartete Aufgaben ausführt.

Schicht 3: Agenten-Harness:

Dies ist die Schicht, über die Hashimoto geschrieben hat und die Birgitta Böckeler als User-Harness bezeichnet. Dies ist die Aktivierungsschicht, die AGENTS.md-Dateien, Skills, benutzerdefinierte Tools, manuell erstellte Linter, System-Prompts und eine gute Test-Suite umfasst. Dies sind die Dinge, die Sie iterativ entwickeln, um die Wahrscheinlichkeit zu erhöhen, dass der Agent Aufgaben korrekt ausführt.

Der Artikel von Marco Rizzi über Harness Engineering mit strukturierten Workflows bringt das Prinzip „Structure in, Struktur out“ auf den Punkt. Der Artikel beschreibt das Scannen der Projektstruktur mit LSP und MCP zum Generieren kontextbewusster Prompts, die dem Agenten nicht nur sagen, was er tun soll, sondern ihm auch die strukturellen Informationen geben, die er für eine ordnungsgemäße Ausführung benötigt. In der Terminologie von Birgitta handelt es sich um Feedforward-Steuerung.

Der Einsatz von Tools ist ein wesentlicher Bestandteil des Konzepts und ermöglicht das, was Birgitta Böckeler als „Computational Guides“ bezeichnet. Die Einführung von Tools und MCP als standardmäßiger Meilenstein hat sinnvolle Agenten ermöglicht. Dadurch haben Agenten-Runtimes bessere Chancen, ihre Ziele zu erreichen. Der Artikel über die Entwicklung effektiver KI-Agenten mit MCP geht ausführlich auf MCP ein und zeigt, wie Sie Agenten aktivieren können, indem Sie ihrem Harness die Möglichkeit geben, dynamisch auf die Ressourcen Ihres Unternehmens zuzugreifen.

Woher wissen Sie, dass Ihr Harness funktioniert? Sie evaluieren ihn. Michael Dawson schreibt über Eval-driven Development und entwirft ein 8-stufiges Evaluierungs-Framework mit DeepEval und LLM-as-Judge-Patterns. Evaluierungen sind die Feedback-Schleife, die Ihnen sagt, ob der Agent durch Ihre Harness-Änderungen verbessert oder verschlechtert wurde. Ohne sie wäre das Harness Engineering eine Vermutung. Tools wie Evaluation Hub helfen Ihnen dabei, dies in großem Umfang zu verwalten.

Harness-Artefakte bringen ein Verwaltungsproblem mit sich. Wenn Ihr AGENTS.md wächst, wenn Ihre benutzerdefinierten Tools immer mehr werden und sich Ihre System-Prompts weiterentwickeln, wie versionieren Sie diese? Wie kann man sie über Projekte hinweg teilen? Der Artikel über Lola, einen KI-Kontext-Paketmanager, behandelt KI-Kontext als versionierte Pakete. Diese Formulierung ist sinnvoll. Wenn es sich bei Ihren Harness-Artefakten um Engineering-Artefakte handelt, sollten Sie sie wie Engineering-Artefakte verwalten.

Schicht 4: Agenten-Runtime

Die Agenten-Runtime ist die Engine, die den Agenten-Loop antreibt. Claude Code, OpenCode, Goose oder eine Eigenentwicklung. Sie verarbeitet die Verteilung von Tools, Kontextfenstern und das Konversationsmanagement.

Das ist es, was Anthropic in dieser E-Mail als „Harness“ bezeichnet. Ich halte das für falsch – oder zumindest für ungenau. Die Runtime ist nichts, was Sie entwickeln und verbessern können, es sei denn, Sie entwickeln Ihre eigene. Sie führt den Loop aus: Prompt senden, Antwort empfangen, Tool-Aufrufe versenden, Ergebnisse zurückgeben. Ich möchte die Bedeutung dieser Schicht nicht schmälern. Die Runtimes werden immer besser, wovon wir alle profitieren.

Aber einige Organisationen entwickeln auch ihre eigene. Wenn Sie Souveränitätsanforderungen haben, Funktionen benötigen, die keine Standard-Runtime bietet, oder wenn Ihr Use Case ein besonders hohes Maß an Kontrolle über das Verhalten der Runtime erfordert, müssen Sie Ihre eigene entwickeln und benötigen APIs, auf denen Sie aufbauen können. Hier kommen Projekte wie Llama Stack ins Spiel, die offene APIs für Antworten, Dateiverwaltung, Suche und zukünftig Speicher bereitstellen. Eine souveräne Runtime, die auf offenen APIs aufbaut, unterscheidet sich von einer, die an einen proprietären Service gebunden ist. Die Plattformen von Red Hat unterstützen beide Strategien: Teams, die eine bestehende Runtime übernehmen und den User-Harness entsprechend anpassen, und Teams, die ihre eigene Runtime für offene APIs entwickeln, weil ihr Kontext dies erfordert.

Schicht 5: Modell- und Inferenzendpunkt

Auf der Bereitstellungsseite setzt der Guide von Red Hat zur Integration von Claude Code mit Red Hat AI Inference Server on OpenShift auf vLLM auf Red Hat AI für On-Premise-Inferenz. Ihr Modell, Ihr Cluster, Ihre Daten. Die Ausführung von Inferenzen auf Ihrer eigenen Hardware hat große Auswirkungen auf das Vertrauensmodell Ihres gesamten Agenten-Stacks.

Mit Hinblick auf die Herkunft ist die Arbeit von Red Hat zum Thema Sicherheit moderner Softwarelieferketten wichtig, insbesondere Red Hat Trusted Artifact Signer und das Signieren kryptografischer Modelle. Wenn Sie die Herkunft des verwendeten Modells nicht überprüfen und managen können, basiert Ihr gesamter Stack auf einer nicht verifizierten Basis. Das Signieren von Modellen ist für die Modellschicht das Gleiche wie das Signieren von Skills für die Harness-Schicht: eine kryptografische Garantie dafür, dass Sie genau das ausführen, was Sie auszuführen glauben.

Subtraktion oder additiv

Die Sandbox und der Harness haben gegensätzliche Design-Philosophien. Die Sandbox ist subtraktiv, d. h. Sie entfernen Fähigkeiten, um Risiken zu mindern. Der Harness ist additiv, d. h. Sie fügen Wissen und Tools hinzu, um die Kompetenz zu steigern. Wenn wir sie vermischen, verwischen wir die Design-Prinzipien, die jede einzelne leiten sollten.

Sie haben auch unterschiedliche Fehlermodi. Ein Sandbox-Fehler bedeutet, dass der Agent etwas getan hat, wozu er nicht hätte in der Lage sein dürfen. Ein Harness-Fehler bedeutet, dass der Agent etwas schlecht ausgeführt hat, das er eigentlich besser hätte machen sollen. Dies sind verschiedene Probleme, die unterschiedliche Reaktionen erfordern.

Die Sandbox hat die Möglichkeit, eine sekundäre Rolle als Aufzeichner zu spielen – als neutraler Beobachter der Aktivitäten des Agenten. Sie kann das Handeln des Agenten auf eine Weise bestätigen, die vertrauenswürdiger ist als die reine Selbst-Attestierung der Agenten-Runtime.

Die Sandbox schränkt ein und beobachtet. Der Harness ermöglicht es und Sie können ihn verbessern. Die Runtime führt aus und Sie sollten keine eigene entwickeln, es sei denn, Sie müssen es. Agenten sind nur so sicher und zuverlässig wie der ihnen zugrunde liegende Stack. Red Hat entwickelt diesen Stack – Open Source auf jeder Schicht, vom GPU-Scheduling bis hin zur kryptografischen Modellsignierung. Wenn Sie Agenten in der Produktion einsetzen und eine Basis suchen, die Sie verifizieren können, anstatt nur darauf zu hoffen, dann ist das unser Ziel.