Schleifen gegenüber Graphen: Zwei Ansätze zur Architektur von KI-Agenten
Loop-Engineering versus Graph-Engineering für KI-Agenten: Wie jede Architektur funktioniert, wann man die eine statt der anderen wählt, sowie eine Checkliste vor der Produktion.
Quellen: Loop Engineering vs. Graph Engineering: The Architecture Shift Quietly Reshaping AI Agents
Zwei Schlagwörter, eine Architekturfrage
Jeder, der KI-Agenten verfolgt, die im Internet suchen, Tools aufrufen, Code schreiben oder Workflows eigenständig ausführen, ist in letzter Zeit wahrscheinlich auf zwei Begriffe gestoßen: Loop Engineering und Graph Engineering. Sie klingen nach Marketing, beziehen sich aber auf eine echte strukturelle Entscheidung.
Betrachten wir einen Agenten, der für eine Frage, die in drei Schritten gelöst werden sollte, 40.000 Tokens sowie sechs Minuten Rechenzeit verbraucht. Mit dem Modell oder der Anfrage selbst ist alles in Ordnung. Das Problem liegt im Design, denn der Agent kann nicht erkennen, dass er bereits etwas versucht hat. Er wiederholt einfach immer wieder die Schritte Denken, Handeln, Beobachten, ohne Aufzeichnung davon, wie sein eigener Prozess abläuft.
Ein solcher Misserfolg verschiebt die Gestaltung von Agenten aus der Kategorie der Prompting-Methoden in den Bereich der Softwarearchitektur. Wenn man es so betrachtet, basiert fast jedes veröffentlichte Agentensystem auf einem von zwei Mustern: Schleifen und Graphen. Im Folgenden wird erläutert, was eaches dieser Muster ist, wie sie konstruiert werden, wo sie versagen und warum der Wechsel vom einen zum anderen die Herangehensweise der Ingenieure an diese Systeme verändert – jenseits eines bloßen Austauschs der Werkzeuge.
Was ein Agent tatsächlich tut
À jedem Zeitpunkt tut ein Agent eines von drei Dingen: Er denkt (eine Aufruf eines LLMs), er handelt (eine Aufruf eines Tools) oder er entscheidet, was als Nächstes kommt. Die Agentenentwicklung besteht im Wesentlichen darin, diese drei Funktionen miteinander zu verbinden.
In den ersten Jahren der LLM-Agenten konfigurierte fast jeder sie auf dieselbe Weise – als Schleife. Es war die offensichtliche Wahl. ReAct-basierte Agenten funktionierten von Anfang an so, und das entspricht auch der Beschreibung des einfachsten Agenten durch Anthropic: ein Modell, das autonom Tools in einer Schleife verwendet.
Später erhielten die Agenten längere und komplexere Aufgaben: mehrere spezialisierte Unteragenten, Wiederholungsversuche, menschliche Freigaben sowie verzweigte Geschäftsregeln. Eine einzelne Schleife reichte dafür nicht mehr aus. Die Teams wollten die Struktur des Prozesses direkt betrachten, anstatt darauf zu vertrauen, dass die Schleife letztendlich zu einem Ergebnis führen würde; daraus entstand die Graphen-Ingenieurwissenschaft, die den Prozess durch Knoten und Kanten darstellt und ihn nicht mehr in wiederholten Iterationen implizit lässt.
Keines der beiden Muster ist falsch. Sie lösen unterschiedliche Probleme, weshalb jedes einer genauen Betrachtung bedarf.
Eine Analogie aus der Küche
Stellen Sie sich vor, Sie bringen jemandem das Kochen bei. Bei der Schleifen-Ingenieurie wird eine einzige Anweisung immer wieder wiederholt: Den Suppenprobieren, bei Bedarf Salz hinzufügen, erneut probieren und so weiter, bis es richtig ist. Es handelt sich um einen Zyklus aus Handlung, Überprüfung und gegebenenfalls erneuter Wiederholung. Einfach, vorhersehbar und leicht vorstellbar.
Die Graph-Ingenieurie ähnelt einem vollständigen Rezept mit Verzweigungen. Man schneidet Gemüse, während jemand anderes Wasser kocht. Wenn beides fertig ist, werden sie miteinander vermischt. Wenn der Geschmackstester mehr Würze möchte, wird der Topf zurück an den Gewürzschritt geschickt, ansonsten wird das Gericht serviert. Hier gibt es keine einzige Abfolge von Schritten. Es existieren mehrere Pfade, einige Schritte laufen gleichzeitig, einige hängen von einer Entscheidung ab, und nur bestimmte Schleifen werden wiederholt, wenn etwas nicht stimmt.
Was Schleifen-Ingenieurie bedeutet
Eine Schleife ist die ursprünglichste und einfachste Methode, um einen Agenten zu erstellen. Sie läuft in einem kontinuierlichen Zyklus ab:
- Die Eingabe aufnehmen, also die Frage oder das Ziel des Benutzers.
- Überlegen Sie, was als Nächstes getan werden soll – das ist der Überlegungsschritt des Modells.
- Handeln, was normalerweise bedeutet, ein Tool aufzurufen, Code auszuführen oder nach Informationen zu suchen.
- Beobachten Sie, was die Aktion hervorgebracht hat.
- Gehen Sie zurück zu Schritt 2 und setzen Sie fort, bis der Agent feststellt, dass das Ziel erreicht ist.
Menschen bezeichnen dies oft als Denk-, Handlungs- und Beobachtungszyklus, und viele der frühesten Agenten wurden darauf basierend entwickelt. Im Rahmen der Loop-Engineering-Methodik wird ein Agent als ein einziger wiederkehrender Zyklus betrachtet: Das Modell überlegt, wählt eine Aktion aus, führt sie aus, untersucht das Ergebnis und schreibt dieses Ergebnis wieder in seinen eigenen Kontext, bevor der Zyklus erneut beginnt, bis er feststellt, dass die Aufgabe abgeschlossen ist oder eine Obergrenze erreicht wurde.
Mehrere Faktoren erklären seine Beliebtheit:
- Es bildet die Grundlage für das bekannte ReAct-Muster (Logikverarbeitung in Kombination mit Handlung) von Yao und seinen Kollegen, bei dem Logikspuren mit Aktionen abwechseln und ein Modell nicht unbedingt zuerst alle Überlegungen abschließen muss.
- Auch die meisten Agentenframeworks definieren einen „Agenten“ auf diese Weise als eine Steuerungsschleife mit einem gemeinsamen Kontextfenster und einer Schnittstelle zur Aufrufung von Tools.
- Die Implementierung eines solchen Agenten erfordert nur wenige Zeilen Code. Der Zustand besteht aus dem bisherigen Gesprächsverlauf, und es gibt nur eine einzige Abbruchbedingung. Ein Code-Assistent, der Dateien bearbeitet, oder ein Forschungsagent, der sucht, bis er zufrieden ist, benötigen nichts Komplexeres.
- Auch die Richtlinien von Anthropic besagen dies: Beginnen Sie mit dem einfachsten funktionierenden Ansatz und fügen Sie Struktur nur dann hinzu, wenn die Aufgabe es erfordert.
Das Problem ist, dass alles, worüber der Loop nachdenken muss – einschließlich dessen, was er bereits versucht hat, was fehlgeschlagen ist und was das Ziel war – in einem ständig wachsenden Kontextfenster untergebracht werden muss. Der Prozess verfügt über kein separates Gedächtnis. Er speichert lediglich eine Transkription.
Wie der Loop aufgebaut ist
Der Ablauf verläuft von Anfang bis Ende wie folgt.
Schritt für Schritt:
- Eine Benutzeraufgabe startet den Loop mit einem Ziel.
- In dem Denkschritt liest das Modell die Systemanweisung, die Konversationshistorie sowie die neueste Beobachtung und entscheidet anschließend, was als Nächstes passieren soll.
- Die Überprüfung „Ist die Aufgabe abgeschlossen?“ ist kein separates System. Das Modell entscheidet selbst, basierend auf seinem Kontext, ob die Aufgabe erledigt ist.
- Falls sie noch nicht abgeschlossen ist, wählt das Modell ein Tool aus und ruft es auf.
- Das Ergebnis oder der Fehler des Tools wird als Beobachtung zurückgegeben.
Eine kompakte Python-Version zeigt, wie wenig Code dafür benötigt wird.
def run_agent(task: str, tools: list, max_iterations: int = 10) -> str:
context = [{"role": "user", "content": task}]
for step in range(max_iterations):
response = llm.generate(context, tools=tools)
if response.is_final_answer:
return response.content
tool_result = execute_tool(response.tool_call)
context.append({"role": "assistant", "content": response.content})
context.append({"role": "tool", "content": tool_result})
return "Stopped: max iterations reached"
Was Graph-Engineering bedeutet
Graph-Engineering stellt den Prozess eines Agenten explizit dar. Es handelt sich um eine Ansammlung von Knoten, wobei jeder Knoten eine Arbeitseinheit wie einen Aufruf eines LLM, einen Tool-Aufruf oder einen Teil der Geschäftslogik darstellt, die durch Kanten miteinander verbunden sind, die entweder fest oder bedingungsabhängig sind. Alle Knoten lesen von und schreiben in ein gemeinsames, typisiertes Zustandsobjekt. Kurz gesagt, wird der Workflow zu einer Karte verbundener Schritte mit Pfaden dazwischen, wodurch ein einzelner wiederkehrender Zyklus ersetzt wird.
Ein Knoten kann eines von folgendem sein:
- ein Agent, eine spezialisierte KI mit einer bestimmten Aufgabe wie Forschung, Schreiben oder Analyse
- ein Tool-Aufruf, beispielsweise eine Websuche, eine Berechnung oder eine Datenbankabfrage
- ein Entscheidungspunkt, der den nächsten Pfad wählt
- ein Zusammenführungspunkt, der Ergebnisse aus mehreren Pfaden kombiniert
Mehrere Pfade können parallel ablaufen, während andere bedingungsabhängig sind und nur dann ausgeführt werden, wenn ein Test erfolgreich ist. Schleifen sind weiterhin möglich, erscheinen aber nur dort, wo sie benötigt werden, als kontrollierter Übergang, der die Arbeit einige Schritte zurückführt, anstatt alles blind erneut durchzuführen.
Warum Graphen attraktiv sind
- Parallelität. Unabhängige Aufgaben können nebeneinander ausgeführt werden, ohne in einer Warteschlange zu warten.
- Ableitung. Der Arbeitsablauf kann je nach Situation in verschiedene Richtungen verlaufen, anstatt immer nur die gleichen Schritte zu wiederholen.
- Spezialisierung. Jeder Knoten kann ein eigenständiger, fokussierter Agent sein, was der Vorgehensweise eines menschlichen Teams bei der Aufgabenteilung ähnelt.
- Zielgerichtete Wiederholungen. Wenn ein Schritt wie eine Qualitätsprüfung fehlschlägt, wird nur dieser Schritt zur erneuten Ausführung zurückgeschickt, während alles andere unberührt bleibt.
LangGraph ist ein Framework, das auf dieser Idee basiert und Workflows als Zustandsbasierte, zyklische gerichtete Graphen modelliert. Ein Graph kann weiterhin Schleifen aufweisen, da ein Knoten eine Kante zu einem früheren Knoten haben kann, wodurch Wiederholungen und Iterationen möglich bleiben. Was sich ändert, ist, dass die Schleife zu einer von vielen Kanten wird, die auf einer betrachtbaren Karte dargestellt werden, und nicht mehr die gesamte Architektur ausmacht.
Dies stimmt weitgehend mit der Unterscheidung überein, die Anthropic zwischen Workflows macht – bei denen LLMs und Tools vorgefertigte Codepfade folgen, die von Entwicklern gesteuert werden, und Agenten, bei denen das Modell seinen eigenen Prozess dynamisch steuert. Ein Graph kann beides in einer Struktur darstellen: mit festen Pfaden, wo Vorhersehbarkeit wichtig ist, und modellgesteuerten Verzweigungen, wo Flexibilität Vorteile bringt; der Unterschied wird im Diagramm sichtbar.
Wie der Graph zusammengestellt wird
Nehmen wir dasselbe Problem: einen Agenten, der recherchieren, Code schreiben und seine eigene Ausgabe überprüfen sowie neu erstellen muss, und bauen wir dies als Graph auf.
Schritt für Schritt:
- START ist der Eingangspunkt des Graphs.
- Ein Router-Node liest den aktuellen Zustand und wählt einen Pfad aus. Das kann ein einfacher
if/else-Ausdruck sein oder ein Aufruf eines LLMs, der die Anfrage klassifiziert.
Hier ist vereinfachter Pseudocode im Stil, den die meisten Graphen-Frameworks verwenden.
from graph_engine import StateGraph, START, END
def router(state: dict) -> str:
return state["task_type"] # "research" | "code" | "review"
def research_agent(state: dict) -> dict:
state["results"]["research"] = do_research(state["query"])
return state
def code_agent(state: dict) -> dict:
state["results"]["code"] = write_code(state["query"])
return state
def review_agent(state: dict) -> dict:
state["valid"] = validate(state["results"])
return state
def aggregator(state: dict) -> dict:
state["final_output"] = merge(state["results"])
return state
graph = StateGraph(schema=AgentState)
graph.add_node("router", router)
graph.add_node("research_agent", research_agent)
graph.add_node("code_agent", code_agent)
graph.add_node("review_agent", review_agent)
graph.add_node("aggregator", aggregator)
graph.add_conditional_edges("router", {
"research": "research_agent",
"code": "code_agent",
"review": "review_agent",
})
graph.add_edge(["research_agent", "code_agent", "review_agent"], "aggregator")
graph.add_conditional_edges("aggregator", {
"valid": END,
"invalid": "router", # explicit retry edge
})
app = graph.compile()
app.invoke({"query": "...", "results": {}, "task_type": "code"})
Wenn man die beiden Muster nebeneinander stellt, fällt der Kontrast leichter ins Auge.
Warum die Branche von Schleifen zu Graphen wechselt
Der Wandel geschah nicht plötzlich. Schleifen stießen aus verschiedenen Gründen an echte Grenzen, als Menschen versuchten, ehrgeizigere Systeme zu entwickeln.
Reale Arbeit verläuft nicht in gerader Linie. Forschung, Kundenservice, Finanzanalyse und Content-Pipelines teilen sich alle in verschiedene Richtungen auf. Wenn es um Abrechnungen geht, wird einer Weg eingeschlagen, und bei technischen Problemen ein anderer. Eine Schleife zwängt all das in eine lange Kette von Bedingungen, was schnell unübersichtlich wird.
Mehr-Agenten-Systeme benötigten eine bessere Struktur. Sobald ein System mehrere Agenten hatte – beispielsweise einen Forscher, einen Zusammenfasser und einen Faktenprüfer – konnte eine Schleife nicht darstellen, dass zwei Agenten gleichzeitig arbeiten sollten oder dass einer nur dann ausgeführt werden muss, wenn eine Überprüfung fehlschlägt. Ein Graph erfassen das natürlicherweise.
Über die Zeit sind Sichtbarkeit und Vertrauen wichtiger. Früher, als Agenten anspruchsvolle Aufgaben erledigten, benötigten Teams eine schrittweise Übersicht darüber, was geschah. Ein Graph kann gezeichnet und angezeigt werden, um genau zu zeigen, wo ein Ablauf gut oder schlecht verlief, während eine Schleife ein undurchsichtiger Block ist, der denselben Code zwanzig Mal ausführt.
Kosten und Geschwindigkeit. Jede verschwendete Iteration kostet Zeit und oft echtes Geld, da jeder Denkschritt eine Aufruf eines Sprachmodells darstellt. Unabhängige Schritte parallel auszuführen und nur den Teil, der neu durchgeführt werden muss, zurückzuschleifen, ist eindeutig effizienter.
Testing und Wartung werden einfacher. Man kann einen Graphen Knoten für Knoten erstellen, testen und ändern. Eine eng gefasste Schleife folgt in der Regel einer Logik von Alles-oder-Nichts, wodurch eine sichere Änderung nach dem Start schwieriger wird.
Die Wahl zwischen ihnen
Es folgt ein grobes Entscheidungskriterium.
Wählen Sie eine Schleife, wenn:
- Die Aufgabe hat ein einziges Ziel: ein einzelner Agent, ein einziges Ziel und ein Satz an Werkzeugen
- Ein frühes Prototyp muss überprüft werden, bevor Geld für die Architektur ausgegeben wird
- Die Anzahl der Schritte ist gering und recht vorhersehbar
- Eine Person ist für alles verantwortlich, und nichts muss an ein anderes Team weitergegeben werden
Wenden Sie ein Diagramm an, wenn:
- Zwei oder mehr spezialisierte Agenten oder Rollen beteiligt sind
- Wiederholversuche, Rückfälle oder menschliche Genehmigungen überprüft werden müssen
- Teile des Prozesses parallel laufen können und später zusammengeführt werden müssen
- Die Ausführung nachverfolgt, abgebrochen oder von einem bestimmten Punkt aus fortgesetzt werden muss – was eine wiedergegebene Transkription nicht bieten kann
- Getrennte Personen oder Teams für getrennte Abschnitte verantwortlich sind, wobei das Diagramm als Übereinkommen zwischen ihnen dient
Hier ist eine nützliche Überprüfung. Wenn der Code einer Schleife einen Kommentar wie „An diesem Punkt hätten wir bereits X ausprobiert haben sollen“ enthält, ist das ein Hinweis darauf, dass Sie innerhalb einer Schleife falsch einen Graphen modellieren – es ist wahrscheinlich an der Zeit, den Graphen zu zeichnen.
Es handelt sich dabei nicht wirklich um eine Entscheidung zwischen „entweder/nicht“. Es geht darum, das Werkzeug der Aufgabe anzupassen. Ein einfacher Chatbot, der Fragen nacheinander beantwortet, oder ein kleines Skript, das eine klare Aktion immer wieder wiederholt, bis sie abgeschlossen ist, eignen sich für eine Schleife. Eine Aufgabe mit mehreren verzweigten Schritten, mehreren zusammenarbeitenden Spezialisten-Agenten, parallellisierbaren Aufgaben oder dem Bedarf an klarer Sichtbarkeit darüber, was passiert ist und warum, eignet sich für einen Graphen. Eine sinnvolle Standardlösung ist, mit einer Schleife zu beginnen und sofort zu einem Graphen überzugehen, sobald die if-dann-Logik schwer nachvollziehbar wird.
Produktions-Checkliste
Bevor Sie eines dieser Muster einsetzen, lohnen sich diese Gewohnheiten:
- Begrenzen Sie die Schritte. Beide Muster benötigen einen Schalter, da ein Agent ohne Limit keine Obergrenze für die Rechnung hat.
- Machen Sie den „Erledigt“-Zustand überprüfbar. Die Abbruchbedingung sollte etwas sein, das ein Test überprüfen kann, niemals eine Vermutung des Modells.
- Instrumentieren Sie jeden Schritt. Geben Sie jedem Aufruf des LLM sowie jedem Tool-Aufruf einen eigenen OpenTelemetry-Span oder Ähnliches und vermeiden Sie einen einzigen Span für den gesamten Ablauf.
- Versionieren Sie das Diagramm. Behalten Sie die Definitionen wie jeden Code im Versionssystem, denn eine unauffällige Änderung einer Kante verändert das Verhalten unauffällig.
- Überprüfen Sie den Zustand an Knotenrändern. Prüfen Sie typisierte Schemata auf den Zuständen, die jeden Knoten betreten und verlassen, damit fehlerhafte Daten frühzeitig gestoppt werden.
Was letztendlich zählt
Eine Schleife ist das minimale Design mit einem Kontext, einem Zyklus und dem Modell, das den Ablauf steuert. Sie eignet sich für einfache, einzigartige Agenten. Ein Graph beschreibt den Prozess durch Knoten, typisierte Zustände sowie Kanten, die man zeichnen, verzweigen, parallel ausführen und gezielt wiederholen kann.
Die tiefere Veränderung besteht nicht darin, dass Graphen besser sind. Es handelt sich vielmehr um einen Wandel vom prozeduralen Denken, bei dem man fragt, was als Nächstes kommt, zum deklarativen Denken, bei dem man fragt, welche Form das System hat. Graphen eignen sich gut für die Nachverfolgbarkeit und Beobachtbarkeit, die Produktionsysteme benötigen, während Schleifen sich gut für schnelle Iterationen eignen.
Die meisten Produktionsysteme bestehen letztendlich aus Graphen, die aus Schleifen aufgebaut sind – im Grunde Zustandsmaschinen, deren Knoten kleine ReAct-ähnliche Zyklen sind. Dadurch sind diese beiden Muster unterschiedliche Zoomstufen derselben Architektur und keine Konkurrenten. Für jedes aktuelle Agentenprojekt ist eine berechtigte Frage, ob alles noch als ein langer Schleifenablauf läuft oder ob es an der Zeit ist, es als Graph darzustellen.
Verwandte Literatur
- Von Agenten-Schleifen zu Workflow-Graphen: Typisierte Zustände, Beweis-Türen und begrenzte Wiederherstellung — Warum langlaufende Agenten eine einzelne Schleife überschreiten und wie explizite Knoten, Kanten, typisierte Artefakte, überprüfte Übergänge sowie per-Knoten-Rechte zu ihrer Zuverlässigkeit beitragen.
- Agent-Harness-Engineering: Zustand, Überprüfung und Steuerung im Umfeld des Modells — Eine Sicht auf Produktionsagenten im Laufzeitumfeld: Warum Anfragen und Kontext nicht ausreichen und wie dauerhafte Zustände, Durchsetzung, Überprüfung sowie Beobachtbarkeit die Lücke schließen.