Ein praktischer Leitfaden zu den 3 Ebenen, die ständig verwechselt werden
Die meisten Menschen reden über KI-Agenten, als wäre es eine einzige Sache.
Ist es aber nicht.
Sobald ein Agent über eine Spielzeug-Demo hinausgeht und anfängt, mit Dateien, APIs, Dokumenten, Kunden oder Produktionscode zu interagieren, bist du nicht mehr nur dabei, "ein Modell zu prompten".
Du entwirfst ein System.
Und in diesem System werden drei Konzepte ständig miteinander vermischt:
- Agent-Harness-Engineering
- Loop-Engineering
- Graph-Engineering
Sie alle drehen sich um dasselbe Modell.
Sie alle beeinflussen die Zuverlässigkeit.
Und ja, sie können alle Schleifen enthalten.
Aber sie lösen unterschiedliche Probleme.
Wenn du sie verwechselst, debugst du am Ende die falsche Ebene.
Die 30-Sekunden-Antwort
Hier ist die klare Version:
- Harness-Engineering baut die Umgebung um das Modell herum auf
- Loop-Engineering entwirft den wiederholten Arbeits- und Feedback-Zyklus
- Graph-Engineering macht die Workflow-Topologie explizit
Ein gutes mentales Modell ist:
Umgebung → Feedback → Ablauf
- Das Harness gibt dem Modell Werkzeuge, Gedächtnis, Kontrolle und einen Arbeitsbereich
- Der Loop entscheidet, wie Arbeit wiederholt, überprüft und verbessert wird
- Der Graph definiert, welcher Schritt als nächstes erlaubt ist
Das ist der Unterschied.
Warum diese Begriffe jetzt wichtig sind
Ein rohes Modell kann von sich aus keine echte Arbeit erledigen.
Es kann nicht:
- den Projektzustand über Sitzungen hinweg verwalten
- sicher Tools aufrufen
- einen Browser inspizieren
- Berechtigungen durchsetzen
- fehlgeschlagene Arbeit wiederholen
- die Ausgabequalität validieren
- Aufgaben an Spezialisten weiterleiten
- im richtigen Moment anhalten
All das kommt von dem System um es herum.
Mit der Reife von agentischer Software zeichnet sich ein praktischer Stack ab:
- Das Harness gibt dem Modell Betriebsbedingungen
- Die Loops machen die Arbeit wiederholbar und überprüfbar
- Der Graph macht komplexe Workflows explizit und kontrollierbar
Sobald du diese als separate Ebenen siehst, verschwindet eine Menge Verwirrung in der KI-Architektur.
Was ein ernsthaftes Harness normalerweise beinhaltet
- Kontextinjektion
Was das Modell sieht, bevor es handelt:
- Anweisungen
- abgerufenes Wissen
- Gesprächszustand
- Gedächtnis
- Richtlinien
- aufgabenspezifische Regeln
- Aktionsflächen
Was das Modell tun kann:
- API-Aufrufe
- Browser-Aktionen
- Shell-Befehle
- Code-Ausführung
- MCP-Tools
- Datenbanken
- benutzerdefinierte Funktionen
- Persistenz
Was über die Zeit hinweg bestehen bleibt:
- Dateien
- Prüfpunkte
- Sitzungszustand
- Fortschrittsprotokolle
- Git-Verlauf
- Langzeitgedächtnis
- Ausführungskontrolle
Wie der Durchlauf verwaltet wird:
- Wiederholungen
- Zeitüberschreitungen
- Budgets
- Modellauswahl
- Erzeugen von Sub-Agenten
- Genehmigungsstufen
- Sicherheit und Governance
Was das System sicher hält:
- Berechtigungen nach dem Least-Privilege-Prinzip
- Isolation
- Whitelists
- Geheimnisverwaltung
- menschliche Genehmigung
- Beobachtbarkeit
Womit du es debuggen kannst:
- Ablaufverfolgungen
- Tool-Eingaben und -Ausgaben
- Zustandsübergänge
- Latenz
- Kosten
- Evaluierungsergebnisse
Warum Harness-Engineering wichtig ist
Zwei Teams können dasselbe Modell verwenden und völlig unterschiedliche Ergebnisse erzielen.
Warum?
Weil ein Team dem Modell Folgendes gibt:
- saubere Tools
- stabilen Zustand
- strukturiertes Gedächtnis
- klare Berechtigungen
- beobachtbare Ausführung
Und das andere gibt ihm:
- einen vagen Prompt
- unordentliche Tools
- verrauschten Kontext
- kein Gedächtnis
- keine Überprüfung
Das Modell mag dasselbe sein.
Die Arbeitsbedingungen sind es nicht.
Harness-Engineering ist immer dann wichtig, wenn der Agent:
- nicht auf die richtige Fähigkeit zugreifen kann
- den Kontext zwischen Sitzungen verliert
- sich inkonsistent über Umgebungen hinweg verhält
- nicht geprüft werden kann
- zu viele Berechtigungen hat
- sich nach einer Unterbrechung nicht sauber erholen kann
Wenn das Modell nicht zuverlässig arbeiten kann, ist der erste Ort, an dem man suchen sollte, das Harness.
2. Loop-Engineering
Was es ist
Jeder Tool-nutzende Agent hat bereits eine winzige eingebaute Schleife:
- Rufe das Modell auf
- Beobachte das Ergebnis
- Führe Tools aus
- Gib die Beobachtungen zurück
- Wiederhole, bis fertig
Loop-Engineering beginnt, wenn du absichtlich zusätzliche Zyklen um dieses Verhalten herum entwirfst.
Nicht nur "frag nochmal".
Nicht nur "wiederhole es".
Sondern ein echtes Arbeits- und Feedback-System.
Anatomie eines guten Loops
Auslöser
Was startet einen neuen Zyklus?
- Benutzeranfrage
- fehlgeschlagener Test
- neues Dokument
- geplanter Durchlauf
- Webhook
- Evaluator-Feedback
Ziel
Welche spezifische Bedingung versuchen wir zu erreichen?
Nicht "verbessere dich weiter".
Ein echtes Ziel.
Zustand
Was muss der nächste Zyklus wissen?
- aktueller Entwurf
- vorheriger Versuch
- Tool-Ergebnisse
- Fehler
- Fortschrittsstatus
Aktionsrichtlinie
Was darf der Agent tun?
- bearbeiten
- delegieren
- Tools aufrufen
- Tokens ausgeben
- Dateien schreiben
- PRs öffnen
Nachweis
Woher wissen wir, ob es funktioniert hat?
- Tests
- Schema-Validierung
- Zitierungen
- Diffs
- Metriken
- Prüfer-Genehmigung
Feedback
Was genau ist fehlgeschlagen?
Das Feedback sollte kompakt und umsetzbar sein.
Stoppregel
Wann endet es?
- Erfolg
- Zeitüberschreitung
- Budget erschöpft
- Maximale Wiederholungen erreicht
- Nicht behebbarer Fehler
- Eskalation an einen Menschen
Das wichtigste Prinzip im Loop-Engineering
**Schleife nicht auf Vertrauen.
Schleife auf Nachweisen.**
"Der Agent sagt, es ist fertig" ist keine Stoppbedingung.
Eine echte Stoppbedingung sieht eher so aus:
- die Tests bestehen
- das Schema validiert
- die Zitierungen lösen auf
- der Prüfer genehmigt
- die Richtlinienprüfung ist sauber
Das ist Loop-Engineering.
Warum Loop-Engineering nicht nur Prompt-Engineering ist
Ein Prompt sagt dem Modell, was es während eines Aufrufs tun soll.
Ein Loop definiert, was das System nach dem Aufruf tut.
Das beinhaltet:
- wie es Ergebnisse überprüft
- wie es auf Fehler reagiert
- wie es den Fortschritt speichert
- wie es entscheidet, fortzufahren
- wie es abbricht
Prompting verbessert eine Antwort.
Ein Loop verbessert einen Prozess.
Das ist ein ganz anderes technisches Problem.
3. Graph-Engineering
Was es ist
Graph-Engineering macht die Workflow-Struktur explizit.
Es beantwortet eine andere Frage:
Nicht nur "was soll der Agent tun?" Sondern "was darf als nächstes passieren?"
Im Graph-Engineering:
- sind Schritte Knoten
- sind Übergänge Kanten
- ist Verzweigung explizit
- ist parallele Arbeit explizit
- sind Zusammenführungen explizit
- sind Wiederholungen explizit
- sind menschliche Unterbrechungen explizit
Der Graph wird zur Steuerungskarte des Systems.
Was Graphen-Ingenieure tatsächlich entwerfen
Knotengrenzen
Was gehört in:
- eine deterministische Funktion
- einen LLM-Aufruf
- einen spezialisierten Agenten
- einen menschlichen Überprüfungsschritt
Zustandsschema
Was jeder Knoten lesen oder schreiben kann.
Routing-Bedingungen
Welche Nachweise bewegen den Job:
- vorwärts
- rückwärts
- seitwärts
- zur Eskalation
Nebenläufigkeit
Was parallel laufen kann und was warten muss.
Zyklen und Ausgänge
Wo Wiederholungen erlaubt sind, wie viele erlaubt sind und wie sie aufhören.
Haltbarkeit
Wo Prüfpunkte gesetzt werden und wie der Workflow nach einer Unterbrechung fortgesetzt wird.
Wann sich Graphen lohnen
Graphen sind wertvoll, wenn der Prozess Folgendes beinhaltet:
- sinnvolle Verzweigungen
- Genehmigungen
- spezialisierte Übergaben
- parallele Arbeit
- Wiederherstellungspfade
- mehrschrittige Workflows mit expliziten Kontrollpunkten
Sie sind weniger nützlich, wenn die Aufgabe einfach ist:
"Gib einem Agenten ein paar Werkzeuge und lass ihn arbeiten."
In diesem Fall können ein solides Harness und ein paar Loops ausreichen.
Ein Graph fügt Klarheit hinzu, aber er fügt auch Struktur hinzu.
Zu viel Struktur zu früh kann das System spröde machen.
Wie die 3 Ebenen zusammenarbeiten
Nehmen wir an, du baust einen Recherche- und Publikations-Agenten.
Er muss:
- ein Thema eingrenzen
- Quellen sammeln
- Zitierungen prüfen
- einen Bericht entwerfen
- die rechtliche Prüfung bestehen
- nur nach Genehmigung veröffentlichen
So sehen die Ebenen aus:
Harness
Bietet:
- Browser-Zugriff
- Suchwerkzeuge
- Datei-Arbeitsbereich
- Gedächtnis
- Zitierungen
- Genehmigungen
- Ablaufverfolgungen
- Modell-Routing
Loop
Handhabt:
- Wiederholen des Quellenabrufs, wenn die Beweise schwach sind
- Beheben von Zitierungsfehlern
- Ausführen von Bewertungsprüfungen
- Aktualisieren der Arbeit, wenn sich der Markt ändert
Graph
Steuert den Pfad:
- Eingrenzung
- Recherche
- Prüfung
- Synthese
- Entwurf
- Überprüfung
- Veröffentlichung
Mit einer menschlichen Hürde vor der Freigabe.
Deshalb sind die 3 Ebenen nicht austauschbar.
Sie arbeiten zusammen, aber sie sind nicht dasselbe.
Diagnostiziere den Fehler, bevor du die Lösung wählst
Hier ist die praktische Regel:
Wenn der Agent nicht arbeiten kann, repariere das Harness
Beispiele:
- fehlender Tool-Zugriff
- veralteter Zustand
- schwaches Gedächtnis
- schlechte Berechtigungen
- keine Beobachtbarkeit
Wenn der Agent fast funktioniert, aber unzuverlässig ist, repariere den Loop
Beispiele:
- erster Entwurf ist nah dran, aber schwach
- Erfolg ist inkonsistent
- Wiederholungen sind unkontrolliert
- es gibt keinen Nachweis der Fertigstellung
Wenn der Prozess selbst komplex ist, repariere den Graphen
Beispiele:
- viele Spezialisten
- Genehmigungen
- Verzweigungslogik
- parallele Pfade
- strukturierte Übergaben
Häufige Fehler
1. Den Graphen zu früh bauen
Teams diagrammieren oft einen riesigen Workflow, bevor sie sehen, wie sich die Arbeit tatsächlich verhält.
Besserer Ansatz:
- beginne mit einem einfacheren Harness
- sammle Ablaufverfolgungen
- finde die stabilen Muster
- formalisiere nur das, was Kontrolle verdient
2. Dasselbe Modell schreiben und benoten lassen, ohne Sicherheitsvorkehrungen
Selbstüberprüfung kann helfen, aber sie teilt dieselben blinden Flecken.
Bevorzuge:
- deterministische Prüfungen, wo möglich
- separaten Prüfer-Kontext
- externe Evaluatoren
- menschliche Genehmigung für Aktionen mit hohen Auswirkungen
3. "Weiterversuchen" als Loop verwenden
Das ist kein Loop-Design.
Das ist ein unkontrolliertes Kostenleck.
Jeder Loop braucht:
- ein messbares Ziel
- echte Nachweise
- Wiederholungsgrenzen
- Eskalationsregeln
4. Das Harness wie eine Rumpelkiste behandeln
Mehr Werkzeuge bedeuten nicht automatisch bessere Agenten.
Zu viele Werkzeuge erzeugen:
- Auswahlfehler
- verrauschten Kontext
- schwache Zuverlässigkeit
- breitere Risikooberfläche
Ein gutes Harness ist nicht überladen.
Es ist präzise.
5. Dem Modell die Schuld für Orchestrierungsfehler geben
Ein Modell kann nicht kompensieren für:
- kaputte APIs
- veralteten Zustand
- fehlende Ausstiegsbedingungen
- vage Tool-Schemata
- unsichtbare Fehlermodi
Repariere die Ebene, die für den Fehler verantwortlich ist.
Eine einfache Produktions-Checkliste
Harness
- Sind die Tools eng gefasst und dokumentiert?
- Ist der Zustand dauerhaft?
- Sind die Berechtigungen nach dem Least-Privilege-Prinzip?
- Können Betreiber pausieren, inspizieren und fortsetzen?
- Sind die Ablaufverfolgungen sichtbar?
Loop
- Welcher Nachweis beweist den Erfolg?
- Welches Feedback wird bei einem Fehler zurückgegeben?
- Wie viele Wiederholungen sind erlaubt?
- Was ist die Stoppregel?
- Was passiert, wenn das Budget aufgebraucht ist?
Graph
- Welche Pfade müssen deterministisch sein?
- Was kann parallel laufen?
- Wo sind die menschlichen Hürden?
- Welcher Zustand wird geteilt?
- Wo beginnen die Wiederherstellungspfade?
Evaluierung
- Kannst du echte Ablaufverfolgungen wiederholen?
- Kannst du Versionen vergleichen?
- Kannst du eine Verbesserung einer echten Änderung zuordnen?
Betrieb
- Verfolgst du die Kosten?
- die Latenz?
- die Fehlerrate?
- die Interventionsrate?
- den Aufgabenerfolg in der Produktion?
Der einfachste Weg, sich den Unterschied zu merken
Wenn du dir nur eines merken kannst, dann merke dir dies:
- Harness-Engineering macht das Modell betriebsbereit
- Loop-Engineering macht die Arbeit iterativ und überprüfbar
- Graph-Engineering macht den Ausführungspfad explizit und kontrollierbar
Keines ersetzt die anderen.
Ein perfekter Graph wird ein schwaches Harness nicht retten.
Ein starkes Harness wird trotzdem Geld verschwenden, ohne gute Loops.
Und saubere Loops werden schwer zu verwalten, wenn Verzweigungen und Genehmigungen in Ad-hoc-Code versteckt bleiben.
Zuverlässige Agentensysteme entstehen, wenn alle 3 Ebenen absichtlich entworfen werden.
Das ist der eigentliche Architektur-Stack.
Abschließende Erkenntnis
Die Leute reden ständig über KI-Agenten, als wäre der Durchbruch das Modell.
In der Produktion ist das selten der wirkliche Unterschied.
Der Unterschied ist das System um das Modell herum:
- das Harness, das ihm das Arbeiten ermöglicht
- die Loops, die ihm die Verbesserung ermöglichen
- der Graph, der ihm das Arbeiten unter Kontrolle ermöglicht
So werden Spielzeug-Agenten zu echten Systemen.
Wenn du bis hierher gelesen hast:
- MERKE DIR DAS.
- Folge @LunarResearcher
- Folge meinem Substack
- Folge meinem Privaten Telegram-Kanal
