Schleifen-Ingenieurwesen: Aufbau von Agenten-Schleifen mit Überprüfungsmechanismen und Stoppsregeln.
Ein praktischer Leitfaden zum Aufbau von vier gestapelten Agenten-Schleifen: Grundlagen von ReAct, Bewertungssysteme, LangGraph-Routing, Schleifenverträge, Ereignistreiger, Hill-Climbing-Verfahren und Fehlerabsicherungen.
Die Denkweise hinter all dem lässt sich leicht erklären. Hören Sie auf, eine KI Schritt für Schritt mit Anweisungen zu steuern, und entwerfen Sie stattdessen den Kreislauf, in dem sie arbeitet. Die zentrale These lautet, dass der Überprüfer mehr als das Modell bestimmt, was man vertrauen kann. Man sollte sich vier ineinander verschachtelte Kreisläufe vorstellen. So lässt sich das umsetzen: Die Bestandteile eines Kreislaufs, der Code für jede Schicht, die möglichen Fehlerquellen sowie die Stoppsregeln, die verhindern, dass der Prozess Ihren Budgetrahmen übersteigt. Am Ende wissen Sie genug, um einen Kreislauf dazu zu bringen, während Sie schlafen, einen Pull Request vorzubereiten.
Die Codebeispiele folgen den dokumentierten APIs, die Modell-ID‑Werte sind Platzhalter, und jeder nur als Pseudocode dargestellte Ausschnitt wird in einem Kommentar angegeben. Ein Beispiel, das durchgehend verwendet wird und als Standardstarter in diesem Bereich gilt, zeigt einen Programmierkreislauf, der einen fehlerhaften Test nachstellt, diesen behebt, die Korrektur von etwas anderem als vom Agenten selbst überprüfen lässt und anschließend einen Entwurf für einen PR erstellt.
Die fünf Bestandteile einer Schleife
Egal, welches Framework Sie verwenden – eine funktionierende Schleife setzt sich immer aus fünf Elementen zusammen. Wenn eines fehlt, gerät die Schleife ins Stocken, hält an oder läuft endlos weiter.
- Ein Auslöser. Das, was die Schleife in Gang setzt – sei es eine menschliche Nachricht, ein geplanter Zeitpunkt, ein webhook oder eine neue Zeile in einer Tabelle.
- Ein Ziel, das eine Maschine überprüfen kann. „Die Tests erfolgreich abschließen“ erfüllt diese Voraussetzung, während „den Code verbessern“ das nicht tut. Wenn die Software nicht erkennen kann, ob das Ziel erreicht wurde, kann es das auch die Schleife nicht.
- Werkzeuge, die echte Rückmeldungen liefern. Der Agent muss auf die Umgebung reagieren und das Ergebnis durch Ausführung von Code, Lesen von stderr oder Aufruf einer API erkennen.
- Ein überschaubarer, verwalteter Zustand. Behalten Sie das Ziel, ein Notizbuch sowie Aufzeichnungen darüber bei, was bereits ausprobiert wurde. Ein übermäßig großer Zustand verursacht Verlangsamungen, Abweichungen und Überschreiten des Kontextfensters der Schleife.
Planen Sie drei Ausgänge und nicht zwei. Erfolg: Die Überprüfung ist bestanden, daher wird die Lieferung durchgeführt. Aufgabe: Das Budget oder die Iterationsgrenze ist erschöpft, daher wird gestoppt und zusammengefasst, was noch übrig ist. Weiterleitung: Der Agent stößt auf eine Entscheidung, die nur ein Mensch treffen sollte, wodurch es zu einer Eskalation kommt. Ein Teil der Gestaltung einer guten Schleife besteht darin, die Aufrufe zu erkennen, die sie selbst nicht ausführen sollte.
Schleife 1: die Agentenschleife
In der Mitte befindet sich der Zyklus, den alle Agenten bereits ausführen – das 2022er ReAct-Muster: Denken, durch Aufruf eines Tools handeln, das Ergebnis beobachten und so lange wiederholen, bis alles abgeschlossen ist. Im Jahr 2026 wird dieser Zyklus absichtlich gestaltet und nicht mehr manuell gesteuert. In seiner einfachsten Form besteht er aus einem einzigen Funktionsaufruf:
from langchain.agents import create_agent
def run_tests() -> str:
"""Run the project's test suite and return the raw output."""
…
agent = create_agent(
model="anthropic:claude-opus-5",
tools=[run_tests],
system_prompt="You are a careful Python engineer. Fix failing tests.",
)
# create_agent returns a graph that calls tools in a loop, repeating
# until the model replies with no tool calls. The loop runs on .invoke()
Die kurze Anweisung verbirgt einen Schleifenmechanismus, den Sie sich vorstellen können. Unten finden Sie dieselbe Steuerstruktur als Pseudocode – ohne jegliches Framework. Beachten Sie, dass jeder Austritt begrenzt ist:
# PSEUDOCODE - shows the control structure a harness implements.
# The helper names below are yours to supply, not a real library API.
def run_loop(goal):
state = init_state(goal) # goal + scratchpad + attempt log
for step in range(MAX_STEPS): # hard cap: never loop forever
thought = model.reason(state) # ReAct: reason…
action = model.choose_action(state) # …then pick a tool call
result = tools.execute(action) # touch the real environment
state = update(state, thought, action, result)
state = compact(state) # keep context under budget
if verifier.passes(state): # deterministic check = reward
return success(state)
if no_progress(state) or budget.exhausted():
return escalate_to_human(state) # third exit: hand-off
return escalate_to_human(state)
Von all den Formen hier sollten Sie sich gerade diese merken. Die anderen sind lediglich Verfeinerungen davon.
Schleife 2: Hinzufügen eines Überprüfers
Ein reiner Agent entscheidet selbst, wann er fertig ist – und das Vertrauen in diese Entscheidung führt zu falsch dargestellten Erfolgen. Deshalb wird der Agent in einen Bewertungsmechanismus eingebettet, der seine Arbeit anhand eines Kriterienkatalogs überprüft. Wenn die Arbeit fehlerhaft ist, wird die Kritik zurückgegeben und die Schleife bis zu einer Obergrenze fortgesetzt. Das Überprüfungs-Middleware befindet sich im deepagents-Paket.
from deepagents import RubricMiddleware, create_deep_agent
from langchain.messages import HumanMessage
from langgraph.checkpoint.memory import InMemorySaver
RUBRIC = """
- All tests pass in run_tests
- No test is skipped or deleted to force a pass
"""
agent = create_deep_agent(
model="anthropic:claude-opus-5",
system_prompt="You are a careful Python engineer.",
middleware=[
RubricMiddleware(
model="anthropic:claude-haiku-4–5", # a cheap grader is fine
system_prompt="Grade against the rubric. Be strict.",
max_iterations=5, # the stop rule (default is 3)
),
],
checkpointer=InMemorySaver(),
)
# The rubric is passed at invoke time - not to the constructor.
result = agent.invoke(
{
"messages": [HumanMessage("Make the failing tests pass.")],
"rubric": RUBRIC,
},
config={"configurable": {"thread_id": "fix-tests-session"}},
)
So funktioniert es: Immer wenn der Agent kurz davor ist, fertig zu werden, liest ein separater Unteragent zum Bewerten die Transkriptdatei anhand der Kriterienprüfung durch. Ein Urteil von needs_revision gibt die Rückmeldung wieder in das Gespräch als HumanMessage zurück, und der Agent setzt seine Arbeit fort. Die einzigen möglichen Ausgänge sind satisfied, failed, max_iterations_reached und grader_error; dadurch wird der Schleifenprozess beendet und die Ausführung immer abgeschlossen. Falls der Bewertungsagent eigene Überprüfungen durchführen muss, werden ihm dazu Tools in Form von BaseTool-Instanzen zur Verfügung gestellt.
Es gibt zwei Arten von Überprüfern, und die richtige Auswahl ist der wichtigste Aspekt bei der Umsetzung.
- Deterministisch: Die Tests werden ausgeführt, das Schema validiert und die Punktzahl bestätigt. Sie sind günstig, schnell und können nicht manipuliert werden – versuchen Sie daher zuerst diese Optionen.
Als Graph darstellen
Sobald eine Aufgabe nicht mehr trivial ist, ist ein expliziter Graph besser als eine versteckte Schleife: Die Knoten, Kanten sowie der Punkt, an dem die Beendigung entschieden wird, sind alle sichtbar. Ein Forschungsagent passt in drei Knoten, wobei jede Entscheidung zur Beendigung vom Router getroffen wird:
from typing import Literal, TypedDict
from pydantic import BaseModel, Field
from langgraph.graph import END, StateGraph
class ResearchState(TypedDict):
question: str
draft: str
verdict: str
feedback: str
iterations: int
class Verdict(BaseModel):
status: str = Field(description='"verified" or "needs_work"')
feedback: str = Field(description="claims lacking support, if any")
def decide(state: ResearchState) -> Literal["research", "__end__"]:
if state["verdict"] == "verified": # success exit
return "__end__"
if state["iterations"] >= MAX_ITERATIONS: # surrender exit
return "__end__"
return "research" # else: loop again with the feedback
builder = StateGraph(ResearchState)
builder.add_node("research", research_node) # generator
builder.add_node("verify", verify_node) # verifier
builder.add_edge("research", "verify")
builder.add_conditional_edges(
"verify", decide, {"research": "research", "__end__": END}
)
builder.set_entry_point("research")
graph = builder.compile()
In diesem Code ist keine clevere Anweisung enthalten. Die Intelligenz liegt in der Struktur: Ein Knoten erzeugt, ein anderer überprüft, und ein Router wandelt das Ergebnis entweder in eine weitere Iteration mit Feedback oder in einen Stopp um. LangGraph betrachtet die Sentinel-Werte __end__ und END als dasselbe.
Der Schleifenvertrag
Hier wird der Denkansatz konkret. Anstelle von Anweisungen schreibt man eine Spezifikation für „Fertig“, also eine Belohnungsfunktion zusammen mit einer Stoppregel. Das ist das Ergebnis, das man überprüft, vergleicht und speichert:
Ziel: ein grüner CI-Build auf der branches payments-refactor. Erfolgreich bedeutet, dass alle Tests bestehen und keiner ausgetauscht oder gelöscht wurde, um zu betrügen. Schritte: Den fehlgeschlagenen Test lesen, die wahrscheinliche Ursache beheben und erneut ausführen. Speicherung: Ein Protokoll der bereits versuchten Ansätze, damit nichts wiederholt wird. Man stoppt bei einem grünen Status, indem man einen Entwurf für eine PR erstellt, nach sechs Runden, indem man zusammenfasst, was noch zu tun ist, oder immer dann, wenn die Arbeit Authentifizierungs- oder Zahlungslogik betrifft, indem man die Aufgabe an eine andere Person weiterleitet.
Niemander hat Anweisungen an das Modell gegeben. Was geschrieben wurde, waren das Ziel, die Überprüfungen, die Speicherregel sowie die drei Ausstiegsbedingungen – und dieser Vertrag stellt eine Schleifen-Ingenieurskunst dar.
Schleifen 3 und 4: nach außen stapeln
Schon eine gut konstruierte Schleife hilft bereits. Die Vorteile verstärken sich, wenn weitere Schleifen darum herum gebaut werden, wobei jede auf einer langsameren Taktfrequenz läuft. Schleifen 1 und 2 erledigen die richtige Arbeit, während Schleifen 3 und 4 dafür sorgen, dass der Prozess kontinuierlich und sich selbst verbessert.
Schleife 3: Ereignisse
Ein externes Ereignis verwandelt Ihre Schleife von einem von Ihnen aufgerufenen Tool in einen selbstständig laufenden Service. Es ist außerdem der geeignete Ort für eine menschliche Freigabestufe vor dem Versand jeglicher Inhalte:
# Loop 3: an event turns the loop into a service
from pydantic import BaseModel
class CIEvent(BaseModel):
branch: str
@app.post("/webhook/ci-failed")
def on_ci_failure(event: CIEvent):
if not event.branch.startswith("fix/"): # cheap triage first
return {"skipped": True}
result = agent.invoke(
{
"messages": [HumanMessage(
f"Fix the failing test on {event.branch}.")],
"rubric": TEST_GREEN_RUBRIC,
},
config={"configurable": {"thread_id": event.branch}},
)
open_draft_pr(result) # a human approves the merge, not the loop
return {"opened_pr": True}
Schleife 4: Hügelbesteigung
Die äußerste Schleife ist die langsamste und arbeitet an der Schleife selbst. Jeder Durchlauf hinterlässt eine Spur. Ein Analyseagent liest diese Spuren, erkennt wiederkehrende Fehler und schlägt Änderungen am „Gurtzeug“ vor: die Anweisungen, die Werkzeuge sowie die Bewertungskriterien, die von Menschen überprüft werden. Stellen Sie sich den Rückkehrpfeil vor – anstatt nur zum Startpunkt zurückzukehren, reicht er in die innere Schleife hinein und verändert sie. Das System verbessert sich selbst.
Eine Vorsichtsmaßnahme: Äußere Schleifen vervielfachen alles, was sich in ihnen befindet. Fügen Sie sie nur hinzu, wenn der innere Überprüfer stark ist, denn eine vierte Schleife um einen schwachen Überprüfer führt lediglich dazu, dass zuverlässiger Unsinn in großem Maßstab automatisiert wird.
Warum dies als Ingenieurwesen gilt
Die Schutzmaßnahmen können wie Bürokratie erscheinen. Das ändert sich, sobald man einen Agenten als geschlossenen Rückkopplungskontroller betrachtet – also als eine Zuordnung, die Punkt für Punkt funktioniert. Das Ziel ist der Sollwert, der Agent ist der Kontroller, und Werkzeuge sowie Umgebung bilden das System. Der Überprüfer fungiert als Sensor, und sein Urteil „muss überarbeitet werden“ ist das Fehlersignal, das die nächste Korrektur auslöst. Eine abgeschlossene Aufgabe bedeutet Konvergenz. Der Kontroller wird durch die Differenz zwischen Sollwert und Sensorwert angetrieben – unabhängig davon, ob es sich um einen Strahltriebwerk oder um ein Testumfeld handelt.
Das gleiche Vokabular beschreibt zwei Möglichkeiten, wie ein Loop abbricht. Er kann oszillieren und eine bestimmte Aktion endlos wiederholen, oder er kann abweichen und vom Ziel entfernt werden, während Geld verloren geht. Schutzmechanismen sind lediglich die Stabilitätsbedingungen, die ihn begrenzen; die wichtigste Regel dabei ist, dass das System eine Abschlussgarantie bieten muss – und dem Agenten darf diese Verantwortung nicht übertragen werden.
Ein Tag mit allen vier Loops
Betrachten Sie, wie die vier Loops einen Morgen durchlaufen. Um 09:14 fehlschlägt ein Test zu „payments-refactor“ und ein webhook wird ausgelöst – das ist Loop 3 –, ohne dass jemand etwas eintippt. In den nächsten sieben Minuten liest der Agent den Fehler, behebt ihn, führt den Test erneut aus, liest den neuen Fehler und behebt ihn erneut, wobei er eine Protokollliste der Versuche führt (Loop 1). Nach jeder Runde läuft ein deterministischer Prüfer das gesamte Testset ab und überprüft, ob nichts weggelassen wurde, um einen Erfolg vorzutäuschen (Loop 2). Die vierte Runde endet mit einem grünen Ergebnis.
Um 09:22 endet der Zyklus auf die richtige Weise mit einem Entwurf für einen Pull Request, der zeigt, was geändert wurde und warum. Ein Mensch muss ihn genehmigen, da die Änderung Zahlungen betrifft. Über Nacht erkennt der Zyklus, dass es sich um den dritten Zeitzone-Fehler der Woche handelt, und erstellt eine neue Überprüfungskriterium-Prüfung, die Ihrer Überprüfung zugeleitet wird (Zyklus 4). Der morgige Ablauf beginnt intelligenter als der heutige.
Ihr habt den größten Teil davon verschlafen. Am Morgen gibt es einen Entwurf für einen Pull Request sowie eine Entscheidung zu treffen – und kein Keyboard, mit dem man draufhämmern könnte.
Wenn Zyklus fehlschlagen
Schleifen verstärken, und die Verstärkung wirkt in beide Richtungen. Jeder Fehlermodus trifft die Schleife an einer bestimmten Stelle und weist eine Standardabsicherung auf, wobei sich ein Thema wiederholt: Was auch immer erzeugt wird, darf nicht gleichzeitig bewertet werden. Der günstigste Schutz besteht darin, den Überprüfer vor dem Alleinlassen der Schleife mit Eingaben zu testen, von denen bekannt ist, dass sie gut oder schlecht sind. Stellen Sie sicher, dass er die schlechten Eingaben ablehnt, denn ein ungetesteter Überprüfer ist lediglich eine Meinung mit einem damit verbundenen Kostenrahmen.
Wann man keine Schleife bauen sollte
Es eilt, alles in Schleifen zu packen – das ist bereits ein eigener Fehlermodus. In diesen Fällen sollte man es auf einen einzigen Aufruf beschränken:
- Ein einziger Durchlauf reicht aus, wie bei einer Zusammenfassung, Übersetzung oder sauberen Extraktion. Eine Schleife fügt nur Kosten und Verzögerungen hinzu.
- Es lässt sich kein Ziel überprüfen. Ohne Möglichkeit, „erledigt“ zu prüfen, gibt es kein Fehlersignal, wodurch eine offene Schleife weiterhin Geld verbraucht.
Schleifenengineering bedeutet, zu wissen, welche Probleme eine Schleife erfordern, genauso wie zu wissen, wie man eine solche erstellt.
Bauen Sie sie so, als würden Sie den Job behalten
Das sind die Werkzeuge: Anatomie, Agentenschleife, Überprüfer, Graph, Vertrag, äußere Schleifen und Fehlerkatalog. Ausstatten Sie die Schleife mit einem starken Überprüfer, einer festen Stoppregel sowie Grenzen, die sie nicht überschreiten darf. Fügen Sie an allen Stellen mit hohen Risiken menschliche Kontrollpunkte hinzu, und bedenken Sie, dass eine Schleife, die eine Lösung liefert, nicht bedeutet, dass man sie verstanden hat. Lassen Sie sie dann laufen – so wie jemand, der beabsichtigt, weiterhin Ingenieur zu bleiben und nicht nur die Person zu sein, die sie startet.
Der nächste Schritt
Eine Frage, die man stellen sollte, bevor eine Schleife unüberwacht wird, lautet: Wie schwach kann ein Überprüfer sein und dennoch ein grünes Ergebnis anzeigen? Um das herauszufinden, wurde ein Vergleichstest erstellt. Dabei werden aufgezeichnete Belohnungshacks untersucht und die Schwellenwert-Einstellungen danach bewertet, wie viele Hacker sie durchlassen. Eine Schleuse, die den eigenen Bericht des Agenten ignoriert und den Testumfang erneut ausführt – also die zuvor als erstes Mittel vorgeschlagene deterministische Überprüfung – stoppte keinen der acht Hacker. Das erneute Ausführen des Testumfangs bestätigt lediglich, dass das Belohnungssignal erfüllt wurde, und genau das erreicht ein Belohnungshack auch.
Falls also der Überprüfer das System einschränkt, wird die anschließend notwendige seltene Fähigkeit offensichtlich: das Entwerfen, Versionieren und Verbessern der Überprüfungen selbst. Man bezeichnet dies als Evaluationsingenieurwesen – die Aufgabe, die Anforderungen festzulegen, die ein Algorithmus erfüllen muss. Ein einzelner Überprüfer arbeitet innerhalb eines einzigen Zyklus. Das Evaluationsingenieurwesen umfasst hingegen viele solcher Schritte, durch Datensätze und Bewertungskriterien, die zeigen, ob das System insgesamt besser oder schlechter wird.
Die Stärkung einer Überprüfungsfunktion gleicht einem Leiterwerk, dessen Höhepunkt unerwartet sein kann. Die beste Überprüfung erweist sich letztendlich überhaupt nicht aus klugem Code zu bestehen, sondern lediglich aus einigen Aussagen, die dem Agenten niemals zugänglich gemacht wurden. Daher liegt die Grenze der Überprüfung an einer unhandlichen Stelle. Sie hängt weniger davon ab, wie gut eine Überprüfungsfunktion konstruiert ist, sondern vielmehr von der Qualität der zurückgehaltenen Daten sowie davon, ob verhindert wird, dass sie wieder in den Zyklus gelangen.