---
title: "AI-Agenten: Harness-, Loop- und Graph-Engineering der Reihe nach verstehen"
locale: de
category: knowledge_base
category_name: "Wissensdatenbank"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/ai-agent-harness-loop-graph-engineering
published_at: 2026-08-16T00:45:12+09:00
---

# AI-Agenten: Harness-, Loop- und Graph-Engineering der Reihe nach verstehen

> Das Harness gestaltet die Arbeitsumgebung und Kontrollmechanismen des Agenten, der Loop die Wiederholungs- und Abbruchregeln und der Graph die zulässigen Zustände und Übergangspfade. Die drei Begriffe sind weniger als offiziell anerkannte Standardklassifikation zu verstehen, sondern vielmehr als praktische Perspektiven auf die Autonomie und die Risiken von AI-Agenten.

## Key Points

- Beim Harness-Engineering werden Kontext, Werkzeuge, Rechte, Prüfungen, Protokolle und Genehmigungsverfahren außerhalb des Modells als eine einheitliche Ausführungsumgebung gestaltet.
- Beim Loop-Engineering werden die Bedingungen und Budgets für die wiederholte Planung, Ausführung, Prüfung und Korrektur durch den Agenten sowie die Abbruchkriterien definiert.
- Beim Graph-Engineering werden Zustände und Übergangsregeln verwendet, um die Pfade, die ein Agent wählen kann, ausdrücklich einzuschränken oder anzupassen.
- Für die meisten Organisationen ist es effizienter, zunächst das Harness und das Bewertungssystem eines einzelnen Agenten zu verbessern, statt komplexe Multi-Agenten-Graphen einzusetzen.
- Bei Hochrisikocode reicht es nicht aus, nur einen von AI erstellten zusammenfassenden Bericht zu genehmigen; auch Tests, Änderungsumfang, Sicherheitsgrenzen und die ursprünglichen Arbeitsergebnisse müssen gemeinsam geprüft werden.

Da AI-Agenten zunehmend langfristige Aufgaben übernehmen, ist es schwieriger geworden, allein durch gut formulierte Prompts zuverlässige Ergebnisse zu erzielen. Denn es muss auch festgelegt werden, welche Informationen ein Agent sieht, welche Werkzeuge er verwendet, wann er etwas wiederholt, welchen Pfad er nimmt und an welchen Stellen die Zustimmung eines Menschen erforderlich ist.

Begriffe, die bei der Beschreibung dieses Problems häufig auftauchen, sind **Harness Engineering**, **Loop Engineering** und **Graph Engineering**. Dabei handelt es sich weder um internationale Standards noch um streng vereinbarte wissenschaftliche Kategorien. Sie überschneiden sich teilweise, und ihre Bedeutung kann je nach Produkt und Entwicklungsteam variieren. Daher ist es sinnvoller, sie anhand der Steuerungsfragen zu unterscheiden, die sie beantworten sollen, statt sie als jahresbezogene Modebegriffe auswendig zu lernen.

## Die drei Konzepte auf einen Blick

| Konzept | Kernfrage | Zentrale Gestaltungsobjekte | Typische Schutzmechanismen gegen Fehler |
|---|---|---|---|
| Harness Engineering | In welcher Umgebung und nach welchen Regeln arbeitet der Agent? | Kontext, Werkzeuge, Berechtigungen, Sandbox, Hooks, Logs, Genehmigungen, Evaluation | Minimale Berechtigungen, Genehmigung riskanter Befehle, Testausführung, Kontextauswahl |
| Loop Engineering | Was wird wiederholt und wann wird abgebrochen? | Planungs-, Ausführungs- und Prüfzyklen, Ereignisverarbeitung, Wiederholungsversuche, Budgets, Abbruchbedingungen | Maximale Anzahl von Wiederholungen, Zeit- und Token-Limits, Fortschrittsbewertung, Übergabe bei Fehlschlag |
| Graph Engineering | Welche Zustände und Pfade sind erlaubt? | Knoten, Zustände, Übergänge, Verzweigungen, Parallelverarbeitung, Checkpoints | Verbotene Übergänge, Zustandsprüfung, Genehmigungsknoten, Wiederherstellungspfade |

Kurz gesagt: **Ein Harness definiert Umgebung und Grenzen**, **ein Loop die Wiederholungsregeln** und **ein Graph die Struktur möglicher Pfade**. In realen Systemen kann sich ein Loop innerhalb eines Graphknotens befinden, während der gesamte Graph innerhalb eines Harness ausgeführt wird.

## Wie haben sich die Methoden zur Steuerung von Agenten verändert?

### Frühe Agenten: Vorgegebene Workflows ergänzten die Autonomie

Frühe generative AI-Agenten vergaßen bei langen Aufgaben häufig ihr Ziel, wiederholten falsche Werkzeugaufrufe oder erzeugten unbelegte Ergebnisse. Daher zerlegten Entwickler große Aufgaben in kleinere Schritte und legten die Ein- und Ausgaben jedes Schritts fest.

Bei diesem Ansatz schreibt ein Mensch das gesamte Verfahren als Chain, Flussdiagramm oder Zustandsmaschine, während das LLM begrenzte Aufgaben wie Klassifizierung, Extraktion, Zusammenfassung oder das Erstellen von Entwürfen übernimmt. Frameworks wie LangGraph werden verwendet, um unter Beibehaltung des Zustands Verzweigungen, Zyklen, Checkpoints und menschliche Eingriffe abzubilden.

Graphbasierte Orchestrierung ist jedoch keine veraltete Methode, die in einem bestimmten Jahr endete. Auch heute eignen sich explizite Graphen für Aufgaben, bei denen Auditierbarkeit, Reproduzierbarkeit, regulatorische Compliance oder präzise Wiederherstellungsverfahren wichtig sind.

### Leistungsfähigere Modelle: Von festen Pfaden zur dynamischen Werkzeugnutzung

Mit verbesserten Fähigkeiten zur Werkzeugnutzung und Schlussfolgerung kann ein einzelner Agent je nach Situation Aktionen wie Suchen, Bearbeiten von Code, Testen oder Lesen von Dateien auswählen. Ansätze aus der ReAct-Familie sind ein typisches Muster, bei dem sich Schlussfolgerung, Aktion und Beobachtung abwechseln.

Diese Veränderung verringerte den Aufwand, alle Verzweigungen im Voraus durch Menschen festlegen zu müssen. Gleichzeitig wurde es wichtiger, die vom Agenten gelesenen Informationen, seine Berechtigungen, die Ausführungskosten und den Umgang mit Fehlern zu verwalten. An diesem Punkt rückten Context Engineering und Harness Engineering ins Zentrum der praktischen Arbeit.

### Langfristige Aufgaben und Multi-Agenten-Systeme: Erneute Verbindung von Loops und Graphen

Bei langfristigen Aufgaben ist ein wiederholter Zyklus aus Planung, Ausführung und Prüfung wichtiger als ein einzelner Modellaufruf. Sind mehrere Agenten beteiligt, müssen auch Rollen, Formate der Arbeitsergebnisse, Berechtigungen und Abbruchbedingungen festgelegt werden. Werden autonome Loops jedoch vollständig sich selbst überlassen, können explodierende Kosten, endlose Wiederholungsversuche, Reward Hacking und die Optimierung auf falsche Ziele auftreten.

Daher werden moderne Agentensysteme nicht darauf ausgelegt, Autonomie zu beseitigen, sondern **Bereiche, in denen Autonomie erlaubt ist, mit Bereichen zu kombinieren, die deterministisch kontrolliert werden**. Dies ist keine einfache Rückkehr zu festen Chains der Vergangenheit, sondern ein Ansatz, bei dem flexible Ausführung von Zuständen, Übergängen und Richtlinien umgeben wird.

Diese Veränderung ist weniger eine genaue Chronologie als eine Verschiebung der gestalterischen Schwerpunkte. Graphen, Loops und Harnesses haben von Anfang an nebeneinander bestanden und werden auch heute gemeinsam eingesetzt.

## Was Harness Engineering umfasst

Ein Harness ist nicht das Basismodell selbst, sondern **das Ausführungssystem, das das Modell umgibt und ihm die tatsächliche Arbeit ermöglicht**. Selbst bei Verwendung desselben Modells können Erfolgsquote, Kosten, Sicherheit und Reproduzierbarkeit je nach Harness erheblich variieren.

### Zentrale Bestandteile eines Harness

1. **Anweisungssystem**: Systemanweisungen, Repository-Regeln, Coding-Standards, Prioritäten und verbotene Aktionen
2. **Kontextbereitstellung**: Suche, Dateiauswahl, Zusammenfassungen, Memory und das Einspeisen benötigter Dokumente zum richtigen Zeitpunkt
3. **Werkzeugschnittstellen**: Dateibearbeitung, Terminal, Browser, Datenbanken, externe APIs
4. **Berechtigungen und Isolation**: Lese- und Schreibbereiche, Zugriff auf Geheimnisse, Netzwerkeinschränkungen, Sandbox
5. **Prüfmechanismen**: Tests, Linter, Typprüfung, Schemavalidierung, Faktenprüfung
6. **Menschliche Genehmigung**: Zustimmung zu schwer rückgängig zu machenden Aktionen wie Deployment, Zahlungen, Löschungen und externer Übertragung
7. **Beobachtbarkeit**: Aufrufprotokolle, Kosten, Latenz, Fehler, Änderungsverlauf, Entscheidungsgrundlagen
8. **Wiederherstellungsrichtlinien**: Wiederholungsversuche, Wiederherstellung eines vorherigen Zustands, Abbruch der Aufgabe, Übergabe an Verantwortliche

Projektanweisungsdateien oder Hooks von Claude Code können als Beispiele für Harness-Komponenten betrachtet werden. Eine einzelne Funktion eines bestimmten Produkts steht jedoch nicht für den gesamten Harness.

### Unterschied zum Context Engineering

Context Engineering optimiert, welche Informationen und Anweisungen in den aktuellen Modellaufruf aufgenommen werden. Dazu gehören etwa das Abrufen ausschließlich relevanter Dokumente per Suche, das Zusammenfassen älterer Gespräche, das Speichern des Aufgabenstatus in einer externen Datei und die Trennung des Kontexts nach Teilaufgaben.

Harness Engineering ist umfassender. Es behandelt neben dem Kontext auch Werkzeugberechtigungen, Ausführungsumgebung, Genehmigungen, Prüfungen, Logging und Kostenlimits. Context Engineering ist daher ein zentraler Teil des Harness, beide Begriffe vollständig gleichzusetzen wäre jedoch ungenau.

## Beim Loop Engineering sind die Abbruchbedingungen entscheidend

Ein Loop sorgt dafür, dass ein Agent sein Ergebnis nach der Erstellung prüft und bei Mängeln einen neuen Versuch unternimmt. Entscheidend ist nicht die Wiederholung selbst, sondern **die Definition des Fortschritts und der Abbruchbedingungen**.

### Typische Loop-Arten

- **Prüf-Loop**: Nach Erstellung eines Entwurfs wird dieser anhand von Tests oder Bewertungskriterien geprüft, und fehlgeschlagene Punkte werden korrigiert.
- **Ereignisbasierter Loop**: Eine Aufgabe beginnt, wenn ein externes Ereignis wie eine E-Mail, eine Benachrichtigung, eine Codeänderung oder Sensordaten eintritt.
- **Explorations-Loop**: Mehrere Hypothesen oder Quellen werden untersucht, und der Suchbereich wird angepasst, bis genügend Belege vorliegen.
- **Verbesserungs-Loop**: Die nächste Strategie wird anhand vorheriger Ergebnisse und Bewertungen gewählt. Da die ausschließliche Optimierung einer einzelnen Kennzahl zu Reward Hacking führen kann, sind mehrere Bewertungskriterien und eine menschliche Prüfung erforderlich.
- **Wiederherstellungs-Loop**: Die Fehlerursache wird klassifiziert, innerhalb des erlaubten Rahmens werden neue Versuche unternommen, und falls das Problem ungelöst bleibt, wird es an einen Menschen übergeben.

### Für sichere Loops erforderliche Verträge

Ein Vertrag zwischen Agenten ist kein juristischer Vertrag, sondern eine Ausführungsspezifikation, die Ein- und Ausgaben sowie Verantwortlichkeiten festlegt. Er sollte die folgenden Punkte enthalten.

| Vertragsbestandteil | Festzulegende Inhalte |
|---|---|
| Ziel | Das zu erreichende Ergebnis und der ausgeschlossene Umfang |
| Eingabe | Nutzbare Daten, Aktualität, Vertrauensniveau |
| Ausgabe | JSON-Schema, Dokumentformat, erforderliche Belege und Testergebnisse |
| Berechtigungen | Erlaubte Werkzeuge, Dateibereiche, Rechte zur externen Übertragung und Änderung |
| Prüfung | Zu bestehende Tests und Bewertungskriterien |
| Budget | Token, Zeit, Anzahl der Aufrufe, Zahl paralleler Aufgaben |
| Abbruch | Bedingungen für Erfolg, fehlenden Fortschritt, ausgeschöpftes Budget und erkannte Risiken |
| Übergabe | Welcher Mensch oder Agent bei einem Fehlschlag übernimmt |

Sind die Abschlussbedingungen unklar, kann ein Agent Sätze umformulieren oder dieselbe Suche wiederholen und dennoch annehmen, dass die Aufgabe voranschreitet. Statt nur eine maximale Anzahl von Wiederholungen festzulegen, ist es besser, Ergebnisqualität, Zuwachs an neuen Informationen, Fehlerveränderungen und Kosten gemeinsam zu betrachten.

## Graph Engineering strukturiert die Grenzen der Autonomie

Ein Graph stellt Aufgaben als Knoten und Verbindungslinien dar. Ein Knoten kann ein Modellaufruf, die Ausführung eines Werkzeugs, eine menschliche Genehmigung oder ein Prüfprozess sein, während die Verbindungslinien abhängig vom Zustand die nächste Aktion darstellen.

### Unterschied zwischen Chain und Graph

- **Eine Chain** eignet sich für lineare Abläufe, die von A zu B und von B zu C führen.
- **Ein Graph** eignet sich für Aufgaben, die bedingte Verzweigungen, Wiederholungen, parallele Ausführung, Wiederherstellung nach Fehlern oder Zwischenspeicherung erfordern.
- **Ein dynamischer Graph** lässt das Modell während der Ausführung die nächste Teilaufgabe oder den nächsten Pfad vorschlagen.
- **Ein eingeschränkter Graph** sorgt dafür, dass sich das Modell selbst bei eigener Auswahl nur innerhalb erlaubter Knoten und Übergänge bewegt.

Das Ziel moderner Graphgestaltung besteht nicht darin, jede Aktion im Voraus durch einen Menschen festzulegen. Vielmehr geht es darum, **einzuhaltende Invarianten** in die Struktur einzubauen, etwa indem vor dem Löschen von Daten zwingend ein Genehmigungsknoten durchlaufen werden muss oder bei fehlgeschlagenen Tests kein Übergang in den Deployment-Zustand möglich ist.

### Anzeichen dafür, dass ein Graph benötigt wird

Wenn mehrere der folgenden Bedingungen zutreffen, lohnt es sich, einen expliziten Graph zu erwägen.

- Der Wiederherstellungspunkt, zu dem nach einem Fehlschlag zurückgekehrt werden soll, ist klar.
- Es gibt einen Schritt, für den zwingend die Genehmigung eines Menschen erforderlich ist.
- Mehrere Aufgaben müssen parallel ausgeführt und ihre Ergebnisse anschließend zusammengeführt werden.
- Die verfügbaren Werkzeuge oder Berechtigungen unterscheiden sich je nach Zustand.
- Der gesamte Ausführungspfad muss auditiert oder reproduziert werden.
- Ein Loop eines einzelnen Agenten wiederholt denselben Fehler.

Werden selbst einfache Dokumentzusammenfassungen oder einmalige Datentransformationen als Graph modelliert, kann dies lediglich die Komplexität erhöhen.

## Praktische Einführungsreihenfolge: Mit dem Harness beginnen und nach Bedarf erweitern

Für die meisten Teams ist die folgende Reihenfolge realistisch.

1. **Eine einzelne Aufgabe und ihre Erfolgskriterien definieren.** Zunächst Eingaben, erwartete Ausgaben und Fehlerfälle sammeln.
2. **Einen minimalen Harness erstellen.** Nur den erforderlichen Kontext und die benötigten Werkzeuge bereitstellen sowie Berechtigungen, Tests, Logs und Kostenlimits festlegen.
3. **Ein Evaluationsset aufbauen.** Neben normalen Fällen auch mehrdeutige Anfragen, fehlerhafte Dokumente, Werkzeugfehler und Versuche zur Überschreitung von Berechtigungen einbeziehen.
4. **Punkte mit Wiederholungsbedarf in Loops umwandeln.** Wiederholungsversuche nur in Bereichen erlauben, in denen Prüfung und Korrektur die tatsächliche Qualität erhöhen.
5. **Bei komplexen Verzweigungs- und Wiederherstellungsprozessen zu einem Graph erweitern.** Zustände und Übergänge explizit definieren und vor riskanten Aktionen Genehmigungsknoten einfügen.
6. **Multi-Agenten-Systeme nur verwenden, wenn eine Aufgabenteilung Vorteile bietet.** Sind weder parallele Exploration noch unterschiedliche Fachrollen erforderlich, kann ein einzelner Agent einfacher und kostengünstiger sein.

## Unterschiede bei der Anwendung auf Coding und Recherche

| Aspekt | Coding-Aufgaben | Rechercheaufgaben |
|---|---|---|
| Prüfbarkeit | Automatische Prüfung durch Tests, Builds, Typprüfungen usw. ist vergleichsweise einfach | Quellenqualität, Auslassungen und widersprüchliche Belege müssen umfassend beurteilt werden |
| Wert dynamischer Exploration | Kann begrenzt sein, wenn der Änderungsumfang klar ist | Hoch beim Vergleich verschiedener Suchpfade und Hypothesen |
| Hauptrisiken | Fehlerhafte Änderungen, Sicherheitslücken, ausschließlich auf Tests zugeschnittener Code | Aussagen ohne Quellen, redundantes Material, Bestätigungsfehler |
| Geeignete Kontrollen | Begrenzung auf den Repository-Bereich, Tests, Prüfung des diff, Deployment-Genehmigung | Dokumentation von Quellen, unabhängige Suche, Suche nach Gegenbelegen, Prüfung von Zitaten |

Es lässt sich nicht pauschal behaupten, dass dynamische Workflows beim Coding immer ineffizient und bei der Recherche immer vorteilhaft seien. Eine testbare Migration im großen Maßstab kann für einen autonomen Agenten geeignet sein, während bei einer Faktenabfrage mit eindeutiger Antwort ein festgelegtes Rechercheverfahren effizienter sein kann. Die entscheidenden Variablen sind weniger das Fachgebiet als vielmehr **die Klarheit des Ziels, die Möglichkeit automatischer Prüfung, der Explorationsraum und die Fehlerkosten**.

## Code Reviews verschwinden nicht, sondern ihre Prüfungseinheit verändert sich

Wenn Agenten Code schreiben, übernehmen Entwickler zunehmend die Rolle, Anforderungen, Design, Testergebnisse, Änderungsumfang und Risiken zu überwachen, statt jede Zeile selbst einzugeben. Zusammenfassungen von Pull Requests und Berichte von Agenten können den Prüfprozess beschleunigen.

Es ist jedoch kein sicherer Standard, ausschließlich eine Zusammenfassung zu lesen und dann zu genehmigen. Änderungen, die der Agent ausgelassen hat, oder falsch verstandene Logik erscheinen möglicherweise auch nicht in der Zusammenfassung. In den folgenden Situationen müssen der ursprüngliche diff und der relevante Code direkt geprüft werden.

- Änderungen an Authentifizierung, Zahlungen, personenbezogenen Daten, Verschlüsselung oder Zugriffskontrollen
- Änderungen am Datenbankschema oder irreversible Migrationen
- Leistungs- und nebenläufigkeitskritischer Code
- Umfangreiches Refactoring außerhalb der Testabdeckung
- Änderungen an externen Abhängigkeiten, Deployment-Konfigurationen oder der Verarbeitung von Geheimnissen
- Fälle, in denen die Erklärung des Agenten nicht mit dem tatsächlichen diff übereinstimmt

Human-in-the-loop bedeutet nicht, dass ein Mensch lediglich formal auf eine Schaltfläche klickt. Es umfasst auch die Bereitstellung von Änderungsnachweisen, Testergebnissen, möglichen Fehlern und Rollback-Verfahren, damit Menschen eine fundierte Entscheidung treffen können.

## Häufige Fallstricke

### Multi-Agenten-Systeme ohne Zweck

Mehr Agenten verursachen Kosten für Rollenabstimmung, redundante Aufrufe, Kontextübertragung und Zusammenführung von Ergebnissen. Wenn weder eine parallele Exploration aus unterschiedlichen Perspektiven erforderlich ist noch ein Grund zur Trennung des Kontexts besteht, ist ein einzelner Agent besser.

### Unbegrenzte dynamische Workflows

Darf ein Agent fortlaufend neue Teilaufgaben erstellen, steigen die Kosten für Token und Werkzeugaufrufe schnell an. Die Kosten ergeben sich ungefähr aus der Summe der Kosten für Ein- und Ausgabe-Token jedes Schritts, der Werkzeugkosten, der Zahl paralleler Agenten und der Anzahl der Wiederholungen. Die Zahl der Aufrufe, die Anzahl gleichzeitiger Ausführungen, das Gesamtbudget und die maximale Ausführungszeit müssen jeweils separat begrenzt werden.

### Optimierung nur einer Bewertungskennzahl

Wird ausschließlich die Testbestehensquote als Ziel vorgegeben, kann eine Fehloptimierung entstehen, bei der Tests abgeschwächt oder Ausnahmebehandlungen verborgen werden. Qualität, Sicherheit, Änderungsumfang, Kosten, Latenz und menschliche Bewertungen müssen gemeinsam berücksichtigt werden.

### Verwechslung von Dokumenteinspeisung mit Fine-Tuning

Dokumentsuche oder Projektanweisungen können Ergebnisse dauerhaft verändern, ohne dass sich die Modellgewichte ändern. Im weiteren Sinne lässt sich dies als Lerneffekt des Systems beschreiben, genau genommen handelt es sich jedoch um eine Anpassung mithilfe von externem Memory und Kontext. Dokumente oder Suchindizes müssen erhalten bleiben, damit die Veränderungen auch bei der nächsten Ausführung bestehen.

## Evaluation, Sicherheit und Wirtschaftlichkeit, die im Betrieb leicht übersehen werden

Agentendesign endet nicht bei einem Architekturdiagramm. Im realen Betrieb ist ein System wichtig, das **nicht nur misst, was erlaubt wurde, sondern was tatsächlich geschehen ist**.

### Minimale Betriebskennzahlen

- Erfolgsquote der Aufgaben und menschliche Korrekturrate
- Modell- und Werkzeugkosten pro Aufgabe sowie Gesamtausführungszeit
- Anzahl der Wiederholungen und Anteil der ohne Fortschritt verbrauchten Aufrufe
- Anzahl der Genehmigungsanfragen, Ablehnungen und Versuche zur Überschreitung von Berechtigungen
- Fehlerhafte Werkzeugaufrufe und Erfolgsquote der Wiederherstellung
- Anteil der ohne Quellen oder Tests eingereichten Ergebnisse
- Ausmaß, in dem Ergebnisse bei gleicher Eingabe variieren

### Für die Sicherheit erforderliche Invarianten

- Anweisungen in externen Dokumenten erhalten keine höhere Priorität als Systemrichtlinien.
- Geheimnisse werden nicht unnötig in Modelleingaben und Logs offengelegt.
- Leseberechtigungen werden von Schreib-, Lösch- und Deployment-Berechtigungen getrennt.
- Für externe Übertragungen und irreversible Aktionen gelten separate Genehmigungen oder Richtlinienprüfungen.
- Agenten dürfen ihre eigenen Bewertungskriterien, Tests oder Audit-Logs nicht nach Belieben ändern.

Diese Invarianten lassen sich sicherer durch Sandboxes, Zugriffskontrollen, Graphübergänge und unabhängige Prüfsysteme erzwingen als durch einen einzelnen Satz in einem Prompt. Das Risikomanagement für generative AI muss neben der Genauigkeit des Modells auch die Betriebsumgebung, menschliche Aufsicht und Reaktion auf Zwischenfälle umfassen.

## Welches Konzept sollte man zuerst lernen?

In der heutigen Praxis sollte man sich zuerst mit Harness Engineering vertraut machen. Ein präziser Kontext, minimale Berechtigungen, automatische Prüfungen, Logs, Genehmigungen und Kostenlimits können viele Fehler eines einzelnen Agenten reduzieren.

Anschließend werden Aufgaben, bei denen Wiederholungen die Qualität erhöhen, um Loops mit klaren Abbruchbedingungen ergänzt. Wenn Verzweigungen, Parallelverarbeitung, Wiederherstellung und Genehmigungsverfahren komplex werden, werden sie explizit als Graph modelliert. Wichtiger als die Übernahme komplexer Begriffe ist es, Ziele, Berechtigungen, Belege, Kosten und Abbruchbedingungen des Agenten in messbarer Form festzulegen.

## FAQ

### Worin unterscheidet sich Harness Engineering von Prompt Engineering?
Prompt Engineering befasst sich hauptsächlich mit den Anweisungen und Formulierungen, die an das Modell übermittelt werden. Harness Engineering bezeichnet die Gestaltung einer umfassenderen Ausführungsumgebung, die neben Prompts auch die Kontextsuche, Werkzeuge, Berechtigungen, Sandboxes, Tests, Protokolle, menschliche Freigaben und die Fehlerbehebung umfasst.

### Bedeuten Context Engineering und Harness Engineering dasselbe?
Nein. Context Engineering konzentriert sich darauf, die Informationen, die das Modell aktuell kennen muss, auszuwählen, zu suchen, zusammenzufassen und anzuordnen. Harness Engineering befasst sich über die Kontextverwaltung hinaus auch mit Berechtigungen, Werkzeugen, Validierung, Kostenlimits und Betriebsrichtlinien.

### Was ist der wichtigste Unterschied zwischen einer Schleife und einem Graphen?
Eine Schleife definiert, was wiederholt wird und wann sie endet, etwa Planung, Ausführung, Validierung und Korrektur. Ein Graph definiert, welche Zustände existieren und wie von einem Zustand in einen anderen gewechselt werden kann. Ein Graph kann eine oder mehrere Schleifen enthalten.

### Benötigen alle KI-Agenten ein Graph-Framework wie LangGraph?
Nein. Für einfache, kurze Aufgaben können ein einzelner Agent und ein minimales Harness ausreichen. Der Nutzen eines Graphen steigt, wenn bedingte Verzweigungen, parallele Verarbeitung, Zwischenspeicherung, Fehlerbehebung, menschliche Freigaben oder eine Prüfung des Ausführungspfads erforderlich sind.

### Erzielen Multi-Agenten-Systeme immer eine bessere Leistung als einzelne Agenten?
Nein. Multi-Agenten-Systeme sind nützlich, wenn parallele Recherchen, unterschiedliche spezialisierte Rollen oder eine Trennung der Kontexte erforderlich sind. Wenn sich Rollen überschneiden oder Ziele unklar sind, können lediglich redundante Arbeit, Übergabefehler, Verzögerungen und Kosten zunehmen.

### Wie lässt sich eine Endlosschleife bei Agenten verhindern?
Neben einer maximalen Anzahl von Wiederholungen müssen auch Budgets für Zeit, Tokens, Werkzeugaufrufe und Kosten festgelegt werden. Ein Zustand ohne neue Informationen oder Fehlerreduktion sollte als mangelnder Fortschritt eingestuft werden, und das System muss so gestaltet sein, dass es bei Erreichen bestimmter Kriterien abbricht oder die Aufgabe an einen Menschen übergibt.

### Reicht es aus, bei von KI erstelltem Code nur die Zusammenfassung des Pull Request zu prüfen?
Die Zusammenfassung ist lediglich ein Hilfsmittel und ersetzt nicht die Prüfung der eigentlichen Änderungen. Bei risikoreichen Änderungen, etwa an Authentifizierung, Zahlungen, personenbezogenen Daten, Datenmigrationen und Bereitstellungseinstellungen, müssen der tatsächliche diff, der Testumfang, die Abhängigkeiten und das Verfahren zur Rückgängigmachung direkt geprüft werden.

### Hat das Modell gelernt, wenn ihm fortlaufend Unternehmensdokumente zugeführt werden?
Die Ergebnisse können sich dauerhaft verändern, doch die Modellgewichte wurden dadurch nicht aktualisiert. Es handelt sich um eine Anpassung auf Systemebene, bei der externe Dokumente, Suchindizes, Speicherinhalte und Anweisungen aufbewahrt und bei der nächsten Ausführung erneut bereitgestellt werden; dies ist von Fine-Tuning im strengen Sinne zu unterscheiden.

### Bedeutet Graph Engineering eine Rückkehr zu den festen Workflows der Anfangszeit?
Nicht unbedingt. Moderne Graphen ähneln eher einer hybriden Steuerung: Sie erlauben Agenten, in bestimmten Abschnitten autonom zu planen und Werkzeuge auszuwählen, schränken zugleich jedoch riskante Übergänge und obligatorische Freigabepunkte explizit ein.

### Was sollte bei der Gestaltung eines Harness zuerst festgelegt werden?
Zuerst müssen die Erfolgskriterien der Aufgabe und die Kosten eines Fehlschlags festgelegt werden. Anschließend sollten nur der erforderliche Kontext und die erforderlichen Werkzeuge bereitgestellt sowie minimale Berechtigungen, automatische Validierung, Ausführungsprotokolle, Kostenlimits und Abbruchbedingungen eingerichtet werden.

## Sources

- [Anthropic — Entwicklung effektiver Agenten](https://www.anthropic.com/research/building-effective-agents)
- [Anthropic — Effektives Kontext-Engineering für KI-Agenten](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [Anthropic — Wie wir unser Multi-Agenten-Forschungssystem entwickelt haben](https://www.anthropic.com/engineering/multi-agent-research-system)
- [Überblick über LangGraph](https://docs.langchain.com/oss/python/langgraph/overview)
- [ReAct: Synergie von Schlussfolgern und Handeln in Sprachmodellen](https://arxiv.org/abs/2210.03629)
- [NIST AI 600-1 — Rahmenwerk für das Risikomanagement künstlicher Intelligenz: Profil für generative künstliche Intelligenz](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)

## Images

![Zentrales KI-System, umgeben von Kreispfeilen und einem Netz aus Erfolgs- und Fehlerknoten](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI0NSwicHVyIjoiYmxvYl9pZCJ9fQ==--3a03e254c3d24990df4c3fc46145a5db24e457ba/ai-eb0e40fe.webp)
![KI-Roboter durchläuft eine sichere Umgebung, eine Werkzeugschleife und einen verzweigten Graphen bis zur Warnschranke](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6ODI1MSwicHVyIjoiYmxvYl9pZCJ9fQ==--cea797c99aabaa4b8f760264327fe2ee8b34b423/ai-23d7d97a.webp)