Erklärung des Agent Harness: Die Komponenten, die einen LLM in einen Agenten verwandeln.
Was ein Agent-Harness ist, warum langlaufende LLM-Agenten einen benötigen, die acht Komponenten, aus denen er besteht, und wie sie bei einer echten Programmieraufgabe zusammenarbeiten.
Quellen: Agent Harness — A complete guide
Im Jahr 2023 war es einfach, die Arbeit mit einem Sprachmodell zu beschreiben. Man gab eine Frage ein, wie zum Beispiel „Schreibe eine Python-Funktion, die einen Array von Zahlen sortiert“, und fast sofort kam eine Antwort. Das Modell schaltete keinen sichtbaren Denkmodus ein. Es handelte sich um ein reines LLM ohne die Zusatzfunktionen, die heutige Agentensysteme ausmachen: Werkzeuge, Speicher, Fähigkeiten und mehr. Genau diese Zusatzfunktionen verwandeln ein einfaches LLM in einen KI-Agenten.
Wie sich das Rennen veränderte
Während 2023 und 2024 drehte sich der Wettbewerb um Modelle. OpenAI hatte ein führendes Allzweckmodell, Anthropic ein führendes Programmiermodell, und alle konkurrierten miteinander bei Benchmarks wie MMLU und SWE-bench. Irgendwann begann sich dieser Wettbewerb zu glätten, und Schlussfolgerungsvermögen sowie der Umgang mit langen Kontexten rückten in den Vordergrund. In Chat-Interfaces erschien allmählich ein „Denk...“-Indikator, und die Leute fragten sich, was dahinter vor sich ging.
Auch die Nutzer änderten sich. Mit der Verbesserung der Modelle hörten die Menschen auf, Fragen zu stellen, und begannen, Aufgaben zu übertragen. Eine Aufgabe erfordert von dem System, Ziele zu setzen, externe Tools wie einen Browser zu nutzen, frühere Gespräche sowie gespeicherte Fakten abzurufen und anschließend etwas zu liefern.
Vergleichen Sie diese beiden Epochen anhand eines Beispiels. Früher könnte jemand möglicherweise einen Screenshot der Amazon-Startseite machen, ihn an ein Programmiermodell geben und sofort eine Seite im gleichen Aussehen verlangen. Das Ergebnis wäre eine akzeptable Benutzeroberfläche. Stellen Sie sich nun vor, man wolle die Benutzeroberfläche, den Backend, die Infrastruktur sowie alles Weitere auf einmal einrichten.
Bis 2026 könnte derselbe Benutzer schreiben: „Beheben Sie den Fehler, der in Issue #122 auf GitHub gemeldet wurde.“ In diesem einen Satz sind mehrere Schritte verborgen. Ein Modell aus dem Jahr 2023 hätte geantwortet, dass es nicht auf Ihr Repository zugreifen könne. Ein in einem guten „Harness“ eingebettetes Modell geht in einen Denkzyklus: es überlegt, plant, wählt ein Werkzeug oder eine Aktion aus, führt sie aus, beobachtet das Ergebnis und wiederholt den Prozess oder stoppt ihn.
Was ein Harness ist
All diese Erweiterungen um ein LLM (Kontext, Werkzeuge, Speicher usw.) benötigen eine geordnete Art und Weise, um mit dem Modell zu interagieren. Diese Disziplin hat einen Namen – die übliche Definition ist kurz: Es handelt sich um die Infrastruktursschicht, die einen KI-Agenten umgibt und dafür verantwortlich ist, ihn einzubinden, zu steuern, zu testen, zu überwachen und seine Ergebnisse zu bewerten. Einfach ausgedrückt: Es ist das Betriebssystem um das LLM herum.
Diese Schicht umfasst die Agent-Architektur, das Orchestrierungsframework, das die Sub-Agenten koordiniert, das Bewertungssystem zur Beurteilung der Ausgaben, die Laufzeitinfrastruktur, die Sicherheit, das Governance-System sowie die Überwachungsfunktionen.
Warum sie notwendig ist
Die Aufgaben, die den Agenten zugewiesen werden, werden immer umfangreicher, genauso wie die Zeit, die sie dafür aufwenden müssen. Die Daten von Anthropic zeigen, dass die Ausführungsdauer in rasantem Tempo zunimmt. Noch vor einem Jahr, im Jahr 2025, benötigte ein Agent für eine bestimmte Aufgabe etwa eine Stunde. Heute liegt diese Zeitspanne eher bei zwölf Stunden.
Aufgaben mit langem Zeitrahmen bringen ihre eigenen Probleme mit sich. Agenten können endlos im Kreis laufen, Tools erfinden, die nicht existieren, ihren eigenen Zustand beschädigen, ihr Token-Budget aufbrauchen, den Kontext verlieren, fehlerhafte Aktionen erneut ausführen, ohne jemandem Bescheid zu geben fehlschlagen, Berechtigungen missbrauchen oder sogar das Ziel vergessen.
Diese Fehler kosten echtes Geld. Ein Agent, der zwölf Stunden lang in einer endlosen Schleife feststeckt, würde eine enorme Menge an Tokens sowie Rechenleistung verbrauchen. Ein Harness kann dies begrenzen, indem er ein Budget pro Aufgabe vorgibt – gemessen in Zeit, Tokens oder Rechenleistung.
Sicherheit ist das größere Problem. Falls das Modell ein zerstörerisches Werkzeug wählt, beispielsweise eines, das das Dateisystem löscht, entscheidet der Harness darüber, was dieses Werkzeug berühren darf. Kurz gesagt gibt der Harness Ihnen die Kontrolle über den Agenten und damit die Gewissheit, dass dieser das tut, was Sie beabsichtigt haben.
Die Komponenten
Egal, wie ein bestimmtes Team seinen Harness nennt – seine Bestandteile lassen sich in acht Gruppen einteilen. Jede dieser Gruppen steht für eine Frage, die der Agent beantworten können muss.
- Agentenzustand: Wo befindet sich die Ausführung gerade? Er verfolgt die aktuelle Aufgabe, den Schritt, Beobachtungen und Entscheidungen. Wenn ein Plan aus vier Schritten besteht, protokolliert der Zustand, welche abgeschlossen sind, welcher gerade läuft und welche noch nicht begonnen haben. Ohne ihn hat ein unterbrochener Agent keine Möglichkeit, dort weiterzumachen, wo er aufgehört hat.
- Werkzeuge: Welche Aktionen stehen zur Verfügung? Dies ist der am meisten sichtbare Teil. Codeausführung, ein Browser, APIs, Datenbanken und eine Shell befinden sich alle hier. Für einen Programmieragenten ist die Funktion
read_fileeine der Grundfunktionen. - Planung: Was kommt als Nächstes? Er entscheidet, was als Nächstes geschieht, und entwirft oder überarbeitet den Plan. Bei einer Programmieraufgabe kann er eine Abfolge von vier oder fünf Schritten erstellen.
Die Praxis, diese Komponenten so zu entwerfen, zu entwickeln und auszuführen, dass der Agent optimal arbeitet, wird als Harness Engineering bezeichnet. Es handelt sich um ein relativ neues Fachgebiet, und die meisten Teams arbeiten noch daran herauszufinden, wofür jeweils die Verantwortung liegt.
Ein Programmieragent von Anfang bis Ende
Nehmen Sie einen Programmieragenten mit einem Steuergerät und geben Sie ihm den Befehl „Beheben Sie den Fehler in Issue #122 auf GitHub“. Es handelt sich dabei nicht um eine Anfrage vom Typ „Erklären Sie mir das“. Es ist eine echte Aufgabe, die Planung, den Einsatz von Werkzeugen sowie das Speichern von Informationen erfordert. Ein logischer Ablauf sieht wie folgt aus:
- Die Eingabe des Benutzers gelangt in den Kontext. Das Modell überlegt darüber nach und formuliert ein Ziel, das im Kontext bleibt, bis es erreicht ist.
- Das Modell plant die Arbeit: Es prüft verwandte Fehler, repariert die richtige Datei, kompiliert, führt Tests durch und aktualisiert den Speicher.
- Zum ersten Schritt holt das Steuergerät Informationen aus einer Vektordatenbank ab, genauer gesagt Details früherer Fehler, die für diesen relevant sind. Authentifizierungsbezogene Notizen werden als am nächsten passend erkannt und in den Kontext aufgenommen.
auth.py zu öffnen und den Authentifizierungsfehler zu beheben. Dafür werden die Tools read_file und write_file benötigt, mit denen das Modell die Datei bearbeitet und speichert.Bislang wurde die Bewertung noch nicht durchgeführt, und sie verdient eine eigene Behandlung. Sie geht über die Genauigkeit hinaus und kann mehrere Metriken berücksichtigen, die mit dem tatsächlichen Verhalten des Agenten zusammenhängen.
Wohin es geht
Die Zuverlässigkeit über einen langen Zeitraum gehört zu den größten offenen Problemen. Da Agenten stunden- oder tagelang laufen, muss ein Lauf zuverlässig sein. Ein Agent, der in einer Schleife steckt oder in einem beschädigten Zustand ist, verschwendet Ressourcen und kann die Sicherheit gefährden.
Auch die Bewertung wird schwieriger, je komplexer die Umgebungen werden. Jede Aufgabe hinterlässt Spuren in Form von Daten wie dem Speicherverbrauch, und die Teams müssen entscheiden, ob sie das Modell austauschen, die Umgebung überarbeiten, neue Tools hinzufügen oder bestehende reparieren sollen. Die Gemeinschaft arbeitet aktiv an der Lösung dieser Probleme.