ai-agents loop-engineering langgraph agent-design guardrails

Schleifenentwicklung für KI-Agenten: Fünf Bestandteile, vier Formen und eine Implementierung in LangGraph

Schleifenengineering für KI-Agenten: fünf Teile, vier gängige Formen, ein Forschungsagent mit Funktionen zur Überprüfung und Wiederholung in LangGraph, Schutz vor Fehlern sowie Anhaltspunkte, wann keine Schleife verwendet werden sollte.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202615 Min. Lesezeit3382 Wörter

Quellen: Loop Engineering with Agents

Jeder KI-Agent läuft bereits in einer Schleife, und kaum jemand entwirft diese Schleife absichtlich. Diese Lücke unterscheidet einen Agenten, der seine Aufgabe leise und effizient erledigt, von einem, der über Nacht Budget verbraucht, obwohl er glaubt, Fortschritte zu machen. Die Praxis, diese Lücke zu schließen, hat einen Namen: Loop Engineering.

Strukturell ist es dabei nicht kompliziert. Bei jeder Iteration überlegt der Agent, was zu tun ist, führt eine Aktion wie einen Tool-Aufruf oder eine Suche durch, betrachtet das Ergebnis und überlegt erneut. Dieser Zyklus aus Denken, Handeln und Beobachten liegt den Tools wie Claude Code und Cursor zugrunde. Eine Zeit lang war die geforderte Fähigkeit Prompt Engineering – eine Anfrage so gut wie möglich zu formulieren. Modelle, die handeln, suchen und ihre eigenen Ausgaben lesen können, stellten eine größere Frage: Was bestimmt die nächste Aktion des Agenten und was sagt ihm, aufzuhören?

Loop-Engineering ist die Gewohnheit, diese Frage absichtlich zu beantworten. Der Entwerfer wählt das Ziel, die Überprüfungen sowie den Endpunkt und erstellt anschließend ein kompaktes System, das das Ziel nur einmal angibt und dem Agenten ermöglicht, weiterhin zu iterieren, bis die Aufgabe abgeschlossen ist. Die Verantwortung verschiebt sich dabei von der schrittweisen Anleitung des Agenten hin zur Erstellung dessen, was die Anweisungen erfordern.

Das ist eine gute Idee – doch genau hier beginnt auch der schwierige Teil. Unsaubere Schleifen verbrauchen Ressourcen, enden nie oder überzeugen sich selbst davon, Fortschritte zu machen. Gute Schleifen hingegen sind effizient, stoppen zum richtigen Zeitpunkt und liefern zuverlässige Ergebnisse. Ein klügerer Prompt schließt diese Lücke nicht – eine bessere Schleife schon.

Die untenstehenden Beispiele verwenden LangGraph, weil es die Struktur eines Loops leicht verständlich macht, doch nichts hier ist an ein bestimmtes Framework gebunden. Die gleichen Prinzipien gelten auch für ein anderes Agentenframework oder rein manuell geschriebenen Code. Frameworks ändern sich, die Konzepte bleiben jedoch bestehen.

Die fünf Bestandteile eines agentenbasierten Loops

Bevor man entscheidet, wann ein Loop geeignet ist, hilft es, zu wissen, woraus er besteht. Fast jeder agentenbasierte Loop hat fünf Bestandteile.

Ein Auslöser. Ein Ereignis setzt den Prozess in Gang, wie zum Beispiel das Eintippen von „go“ durch eine Person, das Auslösen eines Schedulers, das Eintreffen eines Tickets oder das Öffnen eines Pull Requests. Ohne Auslöser bleibt der Agent untätig.
Ein überprüfbares Ziel. Der Loop muss wissen, wie ein Abschluss aussieht – am besten in einer Form, die von einer Maschine bestätigt werden kann. „Improve the app“ führt zu endlosen Durchläufen. Alle Tests müssen bestanden werden, oder es muss eine Antwort zurückgegeben werden, deren Behauptungen alle Quellen nennen und eine echte Ziellinie bieten.
Werkzeuge. Der Agent muss in der Lage sein, zu handeln und gleichzeitig das Ergebnis zu beobachten – sei es durch Ausführung von Code und Lesen von Fehlern oder durch Suchen im Internet und Lesen der Ergebnisse. Wenn die Umgebung nie antwortet, kann der Agent nur raten.
Zustand. Dies ist das aktuelle Bild der Aufgabe: bisherige Versuche, Erkenntnisse, wie viele Runden bereits abgeschlossen wurden. Es handelt sich dabei um den schwierigsten Teil des Loop-Designs, da ein übermäßiger Zustand das nützliche Signal unter Rauschen begräbt.
Stoppsregeln. Sie definieren, wie der Loop endet, und es gibt drei Möglichkeiten. Erfolg bedeutet, dass das Ziel erreicht wurde. Aufgeben bedeutet, dass das Versuchsbudget aufgebraucht ist. Weitergabe bedeutet, dass der Loop auf etwas Riskantes oder Unklares stieß und dies an eine Person weiterleitete, anstatt zu raten.

Der Rest der Diskussion, der behandelt, wann ein Loop angewendet werden sollte, wann nicht und wie, leitet sich von diesen fünf Punkten ab.

Wann sich ein Loop lohnt

Ein Loop ist sinnvoll, wenn eine einzige Durchlaufung des Modells nicht ausreicht und die Aufgabe tatsächlich erfordert, dass der Agent versucht, überprüft und erneut versucht. Vier Anzeichen deuten in diese Richtung.

Die Ergebnisse können überprüft werden. Das ist am wichtigsten. Wenn ein Ergebnis automatisch überprüft werden kann – sei es durch bestandene oder fehlgeschlagene Tests, ob eine Antwort auf echte Quellen verweist oder nicht, oder ob ein JSON-Payload gültig ist oder nicht – kann eine Schleife diese Überprüfung nutzen, um zur richtigen Lösung vorzudringen. Die Überprüfung fungiert wie das Lenkrad; eine Schleife ohne sie verschwendet lediglich Geld.
Der erste Versuch ist oft falsch, lässt sich aber beheben. Code, Forschungsvorlagen sowie die Aufbereitung unstrukturierter Daten verbessern sich durch Wiederholung. Der Agent erstellt etwas, bemerkt die Mängel und behebt sie.
Niemand weiß, wie viele Schritte nötig sein werden. Ein Problem einer bestimmten Art kann heute zwei Schritte erfordern und morgen sieben. Ein fester Ablaufprozess kann sich nicht so anpassen, während eine Schleife, die weiterläuft, bis das Ziel erreicht ist, dies kann.

Niemand beobachtet das. Das Bearbeiten von Tickets über Nacht oder das erneute Versuchen einer instabilen Integration, bis sie erfolgreich ist, erfordert ein System, das seine nächste Aktion selbst wählt und nicht auf eine Anweisung wartet.

Ein passendes Beispiel ist ein Forschungsagent, der seine eigenen Erkenntnisse überprüft. Er entwirft eine Antwort, prüft, ob die Quellen jede Behauptung stützen, und kehrt zu den schwachen Punkten zurück, um tiefer nachzuforschen. Er setzt diesen Kreislauf fort, bis die Antwort standhält oder eine Grenze erreicht ist. Alle vier Signale sind vorhanden, und das ist der Agent, der weiter unten implementiert wird.

Übliche Formen von Schleifen

Die meisten agentbasierten Schleifen sind Variationen einiger Grundformen. Ihr Erkennen hilft dabei, herauszufinden, welche Form ein Problem bevorzugt, bevor etwas miteinander verbunden wird.

Erzeugen und überprüfen, manchmal auch Reflexion genannt. In einer Phase wird eine Ausgabe erstellt und in einer zweiten wird sie geprüft; dieses Verfahren wird so lange wiederholt, bis die Prüfung erfolgreich ist. Das Steuerungssignal ist binär: Die Überprüfung genehmigt die Ausgabe oder weist auf Fehler hin. Dies eignet sich für Situationen, in denen die Richtigkeit getestet werden kann, wie z. B. Code, der Tests bestehen muss, oder Forschung, deren Behauptungen Unterstützung benötigen. Dies ist die später konstruierte Struktur.

   +-----------+      +-----------+
-->| Generate  |----->|  Verify   |----- pass -----> [ done ]
   +-----------+      +-----+-----+
        ^                   |
        +------- fail ------+

Wählen Sie diesen Ansatz, wenn es einen objektiven Test auf Richtigkeit gibt und der Agent weiterhin reparieren sollte, bis der Test bestanden ist. Ein Agent, der SQL-Anfragen ausführt und solange schleift, bis die Anweisung ausgeführt wird und plausible Zeilen zurückgibt, ist ein klassisches Beispiel.

Bewerter und Optimierer, auch als Generierer und Bewertungsmechanismus bezeichnet. Ein Bewertungsmechanismus bewertet jeden Versuch anstelle von einfachem Ja oder Nein, und der Schleifenprozess zielt auf die höchste Bewertung ab und nicht nur auf Richtigkeit. Dies ist nützlich, wenn es weder ein klares Bestehen noch Scheitern gibt, aber dennoch ein Maß für Verbesserung möglich ist – wie bei der Anpassung von Prompten, der Feinabstimmung von Werbetexten oder der Rangfolge von Ergebnissen.

   +-----------+      +-----------+
-->| Generate  |----->|  Score    |--- good enough --> [ done ]
   +-----------+      +-----+-----+
        ^                   |
        +-- improve --------+
            (use the score)

Wählen Sie es aus, wenn die Qualität zwar auf einer Skala bewertet werden kann, aber dennoch einer Zahl zugeordnet werden muss. Durch die Erstellung eines Produkt-Slogans, bei dem Klarheit und Wirkung bewertet werden, während der Schleifenprozess den besten Entwurf verfeinert, wird die Idee veranschaulicht.

Planen, ausführen, neu planen. Ein Planer legt die Schritte fest, die Ausführenden führen sie aus, und sobald ein Schritt unerwartete Erkenntnisse liefert, kehrt die Schleife zurück, um den Plan zu überarbeiten. Die Schleife umschließt den gesamten Plan und nicht nur ein einzelnes Ergebnis, wodurch sie sich für offene, mehrschrittige Arbeiten wie Forschung oder Softwareprojekte eignet.

   +-----------+      +-----------+
-->|   Plan    |----->|  Execute  |-- all steps done --> [ done ]
   +-----------+      +-----+-----+
        ^                   |
        +-- replan ---------+
            (hit a surprise)

Wählen Sie diese Methode, wenn die Aufgabe viele Schritte umfasst und nicht alle im Voraus bekannt sind. Der Umzug eines Services in ein neues Framework funktioniert: Planen Sie die Schritte, beginnen Sie mit der Ausführung und planen Sie neu, sobald ein Schritt eine unerwartete Abhängigkeit aufzeigt.

Geplante oder überwachende Schleife. Anstelle einer Iteration hin zu einem Ziel während einer einzigen Ausführung wird diese Variante durch einen Timer oder ein Ereignis aktiviert, um zu beobachten und zu reagieren – beispielsweise neue Tickets zu sortieren, fehlerhafte Builds zu überprüfen oder einen unzuverlässigen Vorgang erneut auszuführen. Sie erstreckt sich über Zeit und existiert nicht innerhalb einer einzigen Aufgabe.

   +-----------+     +-----------+     +-----------+
-->|   Wait    |---->|   Check   |---->|    Act    |---+
   | (timer /  |     +-----------+     +-----------+   |
   |  trigger) |                                       |
   +-----------+ <-------------------------------------+
        (no fixed end — keeps watching over time)

Wählen Sie diesen Ansatz, wenn es keine einzige Ziellinie gibt und das Ziel darin besteht, kontinuierlich zu beobachten und zu reagieren – ähnlich wie ein Posteingang alle paar Minuten überprüft wird oder abends abgelaufene Pull Requests gesichtet werden.

Diese Strukturen schließen einander nicht aus. Reale Systeme verwenden sie oft in Kombination, zum Beispiel einen planbaren Zyklus, der bei jedem Neustart einen Generierungs- und Überprüfungsprozess ausführt. Die häufigste Struktur, Generieren und Überprüfen, wird im Folgenden von Anfang bis Ende aufgebaut.

Einen Zyklus mit LangGraph erstellen

Der zu entwickelnde Agent ist ein Forscher, der seinem eigenen ersten Entwurf misstraut. Bei einer Frage sammelt er Informationen, schreibt eine Antwort und überprüft anschließend jede Behauptung anhand eigentlicher Quellen. Behauptungen ohne Unterstützung werden zur weiteren Recherche zurückgesandt. Der Kreislauf setzt sich fort, bis die vollständige Antwort steht oder eine Obergrenze für Versuche erreicht ist; in diesem Fall gibt der Agent seine beste Version ab und markiert das, was noch ungewiss ist. Kurz gesagt: Er gibt eine Antwort und überzeugt sich anschließend davon, dass sie richtig ist, bevor er sie weitergibt.

Dieses selbstüberprüfende Verhalten ist genau der Generieren-und-Überprüfen-Zyklus, wodurch eine saubere erste Erstellung entsteht.

LangGraph eignet sich gut, weil es einen Agenten als Graph beschreibt. Knoten sind Elemente, die Aufgaben ausführen, und Kanten sind Pfeile, die bestimmen, was als Nächstes ausgeführt wird. Kanten dürfen rückwärts zeigen, was einen Kreislauf ermöglicht. Eine einfache lineare Kette kann sich nicht wiederholen, aber ein Graph kann es.

Der Forscher hat drei Aufgaben, daher drei Knoten. Die ersten beiden teilen die Arbeit zwischen einem Ersteller und einem Prüfer auf, wobei ein Ausführender und ein Kritiker getrennt bleiben – ein Muster, das in Schleifen häufig vorkommt.

                    +------------------+
  START ----------> |     Research     | <-------------+
                    | (draft / revise) |               |
                    +--------+---------+               |
                             |                         |
                             v                         | needs work
                    +------------------+               | (+ feedback)
                    |      Verify      |               |
                    |  (check claims)  |               |
                    +--------+---------+               |
                             |                         |
                             v                         |
                       +-----------+   needs work      |
                       |  Decide   |-------------------+
                       | (router)  |
                       +-----+-----+
                             | verified / out of tries
                             v
                          [ END ]

Forschung sammelt Materialien und erstellt einen Entwurf für die Antwort.
Überprüfung prüft den Entwurf und überprüft, ob jede Behauptung belegt ist.
Entscheidung ist ein kleiner Router, der das Urteil liest und entscheidet, was als Nächstes zu tun ist: abschließen oder zurückgehen und die Schwachstellen weiter erforschen.

Das Beispiel läuft unter Python 3.12. Drei Pakete sind erforderlich:

pip install langgraph==1.2.6 langchain-openai==1.3.3 pydantic==2.13.4

langgraph ist der Graphen- und Schleifen-Engine, zusammen mit StateGraph, START und END.
langchain-openai umhüllt das OpenAI-Chat-Modell als ChatOpenAI.
pydantic definiert das strukturierte Ergebnis, das der Überprüfer zurückgibt.

Bevor es ausgeführt wird, muss auch eine OpenAI-API-Schlüssel im Umfeld vorhanden sein:

export OPENAI_API_KEY="your-key-here"

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field

# A model client on OpenAI's Responses API, with the built-in web-search tool
# bound on — so the model can search the web itself, no extra package needed.
# "gpt-5" is a reasoning model; swap it for any current model you have access to.
llm = ChatOpenAI(model="gpt-5", use_responses_api=True)
searcher = llm.bind_tools([{"type": "web_search"}])

MAX_ITERATIONS = 3         # a stop rule, decided up front

# STATE — the shared memory passed between every node
class ResearchState(TypedDict):
    question: str          # what we're answering
    draft: str             # the current best answer
    verdict: str           # "verified" or "needs_work"
    feedback: str          # what the verifier said to fix
    iterations: int        # how many times we've looped

# The verifier returns a typed result, so the router gets a clean
# "verified" / "needs_work" to branch on instead of parsing prose.
class Verdict(BaseModel):
    status: str = Field(description='"verified" or "needs_work"')
    feedback: str = Field(description="claims lacking support, if any")

# NODE 1 — the maker: search the web, then draft (or revise) the answer.
def research(state: ResearchState) -> dict:
    prompt = "Search the web, then answer the question. Back every claim with a source.\n"
    if state.get("feedback"):
        prompt += f"A reviewer flagged these gaps — fix them:\n{state['feedback']}\n"
    prompt += f"\nQuestion: {state['question']}"
    draft = searcher.invoke(prompt).text
    return {"draft": draft, "iterations": state["iterations"] + 1}

# NODE 2 — the checker: search for evidence, then critique the draft.
def verify(state: ResearchState) -> dict:
    evidence = searcher.invoke(
        f"Search the web for evidence to fact-check claims about: {state['question']}"
    ).text
    checker = llm.with_structured_output(Verdict)
    result = checker.invoke(
        "You are a fact-checker. Using the evidence below, reply 'verified' "
        "only if every claim in the answer is supported; otherwise 'needs_work' "
        "and list the unsupported claims as feedback.\n\n"
        f"Evidence:\n{evidence}\n\nAnswer:\n{state['draft']}"
    )
    return {"verdict": result.status, "feedback": result.feedback}

# ROUTER — the heart of the loop. Reads the verdict, picks the next step.
def decide(state: ResearchState) -> Literal["research", "__end__"]:
    if state["verdict"] == "verified":
        return "__end__"                      # success: goal met
    if state["iterations"] >= MAX_ITERATIONS:
        return "__end__"                      # surrender: out of tries
    return "research"                         # loop back and fix the gaps

# WIRE IT UP
graph = StateGraph(ResearchState)
graph.add_node("research", research)
graph.add_node("verify", verify)

graph.add_edge(START, "research")            # trigger
graph.add_edge("research", "verify")         # always verify a fresh draft
graph.add_conditional_edges("verify", decide, {
    "research": "research",                   # the backward arrow = the loop
    "__end__": END,
})

agent = graph.compile()

result = agent.invoke({
    "question": "What were the main causes of the 2008 financial crisis?",
    "draft": "", "verdict": "", "feedback": "", "iterations": 0,
})
print(result["draft"])

Zwei Aspekte sind besonders hervorzuheben. Erstens erreichen beide Knoten das Live-Web über OpenAI’s integriertes web_search-Tool, das über bind_tools verbunden ist. Der research-Knoten durchführt eine Suche vor dem Erstellen eines Entwurfs, damit seine Aussagen auf tatsächlichen Ergebnissen beruhen. Der verify-Knoten führt eine zweite Suche durch, um den Entwurf anhand neuer Beweise statt anhand des Modellspeichers zu überprüfen, und genau diese zweite Suche liefert dem Schleifenprozess ein objektives Signal. Zweitens setzt verify auf with_structured_output, das einen typisierten verdict sowie feedback statt Prosa erzwingt, sodass der Router zuverlässig entscheiden kann, ohne freien Text analysieren zu müssen.

Die fünf Bestandteile der Schleife entsprechen eindeutig dem Code:

Trigger: Die Aufrufung von invoke(...) mit einer Frage startet einen Ablauf.
Überprüfbares Ziel: Die verify-Regeln geben an, ob etwas verified ist oder needs_work.
Werkzeuge: Beide Knoten nutzen die eingebauten Web-Suche, research zum Schreiben und verify zur Überprüfung.
Zustand: Das ResearchState-Wörterbuch überträgt Entwürfe, Feedback sowie die Iterationsanzahl zwischen den Knoten.
Stoppsregeln: Der decide-Router beendet den Ablauf bei Erfolg oder nach Erreichen von MAX_ITERATIONS.

Der letzte Punkt ist entscheidend, denn der Router ist der Ort, an dem die Schleifenlogik tatsächlich umgesetzt wird. Eine einzige Zeile – „stoppen, wenn überprüft“, „stoppen nach drei Versuchen“, ansonsten zurückgehen – unterscheidet einen Agenten, der zuverlässig seine Antwort verbessert, von einem, der unbegrenzt weiterläuft.

Das Beispiel weist zwei Ausgänge auf. In Produktionsumgebungen werden oft ein dritter Ausgang hinzugefügt, nämlich eine Übertragung an einen Menschen. Wenn auf etwas Riskantes oder Unklares gestoßen wird, ist es für den Agenten besser, weder zu raten noch stillzuschweigen, sondern anzuhalten und alles, was gesammelt wurde, mitzuteilen. Im Router ist dies lediglich ein weiterer Zweig: Wenn das Vertrauen gering ist oder die Aktion sensibel ist, beendet der escalate-Pfad den Loop und zeigt den Entwurf, die offenen Fragen sowie die unternommenen Versuche. Zu wissen, wann man nicht entscheiden sollte, gehört zum guten Loop-Design.

Fehlermöglichkeiten und deren Schutzmechanismen

Sobald ein Loop selbstständig läuft, treten einige vorhersehbare Fehler auf, und jeder davon hat einen standardmäßigen Schutzmechanismus.

Der endlose Kreislauf. Der Agent kommt niemals zu dem Schluss, dass er fertig ist, und setzt seine Arbeit fort, bis etwas kaputtgeht oder das Geld aufgebraucht ist. Eine feste Iterationsgrenze, wie zum Beispiel MAX_ITERATIONS oben, stellt einen Ausstieg dar, der nicht von der eigenen Einschätzung des Agents abhängt.
Token-Verbrauch. Bei jeder Durchlaufphase werden immer mehr Kontextdaten erneut übertragen, wodurch der Aufwand unbemerkt zunimmt. Halten Sie den Zustand übersichtlich, indem Sie nur das weitergeben, was für den nächsten Schritt erforderlich ist – den aktuellen Entwurf sowie die spezifischen Rückmeldungen – und niemals die gesamte Historie.
Illusionärer Fortschritt. Der Agent gibt an, Erfolge erzielt zu haben, die er tatsächlich nicht erreicht hat, beispielsweise behauptet er, eine Fehlerbehebung vorgenommen zu haben, die nie stattgefunden hat. Lassen Sie ihn nicht seine eigene Arbeit in Bezug auf die wichtigen Aspekte als abgeschlossen markieren. Ein separates Überprüfungsverfahren mit objektiven Tests, tatsächlich ausgeführten Tests oder tatsächlich existierenden Quellen sorgt dafür, dass „erledigt“ wirklich bedeutet, „erledigt“ zu sein.

Wiederholung derselben Fehler. Der Loop versucht erneut dieselbe fehlerhafte Aktion und erleidet wieder denselben Misserfolg. Der frühere Fehler muss in den nächsten Versuch übertragen werden, damit sich der Ansatz ändert – deshalb erhält research die Feedback-Meldung des Verifizierers.

Unkontrollierbare Aktionen. Bei langen Laufzeiten wird es schwierig, zu erkennen, was passiert ist und warum. Jeder Schritt muss aufgezeichnet werden: Was der Agent gesehen, entschieden und getan hat. Die Beobachtbarkeit ist nicht mehr optional, sobald ein Loop etwas Wichtiges berührt, und es gibt Tools wie LangSmith, um solche Laufzeiten nachzuvollziehen.

Vollständige Autonomie von Anfang an. Ein Loop, der bereits am ersten Tag unüberwacht agiert, hat noch kein Vertrauen erworben. Führen Sie dies schrittweise ein: Zuerst ein rein berichtender Modus, der angibt, was er tun würde, anschließend unterstützte Änderungen, die von einer Person genehmigt werden, und schließlich uneingeschränkte Betriebsweise – jede Stufe muss erst erreicht werden, bevor die nächste beginnt.

Wann man keinen Schleifenbau verwenden sollte

Schleifen sind mächtig, weshalb sie leicht übermäßig eingesetzt werden. In solchen Fällen ist etwas Einfacheres besser.

Ein einziger Durchlauf reicht aus. Das Zusammenfassen eines Dokuments, das Übersetzen von Texten, das Beantworten einer faktischen Frage sowie die Klassifizierung einer E-Mail sind einmalige Aufgaben. Eine Schleife dazu führt nur zu zusätzlichen Kosten, Verzögerungen und neuen Möglichkeiten zum Scheitern. Wenn eine einfache Abfolge von Schritten funktioniert, sollte diese verwendet werden.
Der Erfolg ist nicht erkennbar. Wenn das Ziel subjektiv oder unklar ist oder nur von einem Menschen beurteilt werden kann, hat die Schleife nichts, woran sie sich orientieren kann, und wird willkürlich enden oder endlos weiterlaufen. Ein Ziel, das nicht überprüft werden kann, ergibt eine Spielmaschine – keine Schleife.

Fehler sind teuer oder dauerhaft. Ein Schleifenprozess, der bei jeder Iteration E-Mails versendet, Geld überweist oder Daten löscht, kann schnell erheblichen Schaden anrichten. Halten Sie eine Person im Genehmigungsprozess oder vermeiden Sie Schleifen bei den nachfolgenden Aktionen.

Geschwindigkeit und Kosten haben Vorrang vor Autonomie. Jede Iteration bedeutet zusätzliche Anrufe, Ressourcen und Zeit. Bei Funktionen mit hohem Volumen, geringen Gewinnen oder empfindlicher Latenz ist oft ein vorhersehbarer einziger Anruf besser als eine clevere, aber kostspielige Schleife.

Ein Faustregel: Wenn die Bedingungen für Erfolg und Aufgabe nicht schriftlich festgelegt werden können, ist die Schleife noch nicht bereit zur Implementierung.

Checkliste vor dem Schleifenprozess

Die Schleifenarchitektur verschiebt den Zeitpunkt der Belohnung. Ein fehlerfreier Prompt zu verfassen ist weniger wichtig als die Gestaltung des Systems, das den Agenten steuert – also seine Auslösebedingungen, Ziele, Werkzeuge, Zustände sowie Stoppsregeln. Dennoch ist eine Schleife nur eines von vielen Werkzeugen und niemals die Standardlösung. Fünf Fragen sind es wert, zuerst gestellt zu werden:

Kann der Erfolg automatisch überprüft werden? Falls nicht, verzichten Sie auf die Schleife, da es sonst nichts gäbe, wofür sie steuern könnte.
Verbessert sich die Aufgabe durch Wiederholung? Wenn eine einzige Durchführung ausreicht, halten Sie es einfach.
Was bedeutet genau „erledigt“? Legen Sie die Erfolgsbedingung schriftlich fest, bevor Sie codieren.
Wann sollte sie aufhören? Legen Sie eine feste Grenze fest, damit die Schleife nicht ewig laufen kann.
Können die Aktionen sicher wiederholt werden? Falls eine Iteration Schaden anrichten könnte, fügen Sie einen menschlichen Überprüfungspunkt hinzu oder vermeiden Sie eine Schleife in diesem Schritt.

Durch ehrliche Antworten auf alle fünf Fragen kann das Ergebnis ein zuverlässiger Kreislauf sein und nicht nur etwas Scheinvolles. Ein bescheidenes erstes Projekt funktioniert am besten: eine Forschungs- und Überprüfungsphase wie oben beschrieben, wobei die Stoppsregeln bereits vor dem weiteren Ausbau festgelegt werden.

Ein letzter Punkt: Ein Kreislauf beschleunigt die Arbeit nicht nur – er verstärkt vielmehr jede Entscheidung, die in ihn eingeflossen ist, indem er gute wie schlechte Entscheidungen in Maschinengeschwindigkeit wiederholt. Das Ziel ist daher nicht, ihn einmal einzurichten und dann wegzugehen. Die Disziplin besteht darin, nahe genug dran zu bleiben, um weiterhin zu verstehen, was der Kreislauf nach dem Alleinlaufen tut, sodass sein Entwerfer weiterhin sein Ingenieur bleibt und nicht nur die Person, die den Startknopf drückt.