Loop Engineering: Ein Agent-Loop, der weiß, wann Schluss ist

Um jedes KI-Modell herum gibt es eine Reihe unterstützender Bausteine, und einer der wichtigsten ist der Agent-Loop. Hier geht es genau um diesen Loop und darum, wie man ihn so baut, dass sich der Agent vorhersehbar verhält, bezahlbar bleibt und weiß, wann er aufhören muss.

Vom einzelnen Aufruf zum Zyklus

Ein einfacher Chatbot folgt meist einem einzigen geraden Weg:

User → LLM → Response

Ein Agent hat es schwerer. Eine Aufgabe zu erledigen kann mehrere Schritte brauchen, und nach jedem schaut sich das Modell an, was passiert ist:

User
 ↓
Understand the task
 ↓
Decide what to do
 ↓
Use a tool
 ↓
Observe the result
 ↓
Decide what to do next
 ↓
Use another tool
 ↓
Evaluate the result
 ↓
Finish

Genau mit dieser Wiederholung befasst sich Loop Engineering.

Ein Agent-Loop ist der Zyklus, in dem ein KI-Agent immer wieder Folgendes tut:

1. Informationen aufnehmen.
2. Entscheiden, was zu tun ist.
3. Eine Aktion ausführen.
4. Das Ergebnis betrachten.
5. Beurteilen, ob eine weitere Aktion nötig ist.
6. Irgendwann aufhören.

Vereinfacht sieht der Zyklus so aus:

┌───────────┐
        │  Observe  │
        └─────┬─────┘
              ↓
        ┌───────────┐
        │   Decide  │
        └─────┬─────┘
              ↓
        ┌───────────┐
        │    Act    │
        └─────┬─────┘
              ↓
        ┌───────────┐
        │  Observe  │
        │   Result  │
        └─────┬─────┘
              ↓
         Finished?
          /     \
        No       Yes
        ↓         ↓
     Decide     Stop

Entscheidend ist, dass ein einzelner Modellaufruf nicht gleich die endgültige Antwort liefern muss. Der Agent kann handeln, aus dem Ergebnis lernen und weitermachen.

Ein kleines Beispiel: Wetter in Bristol

Angenommen, jemand fragt: „Wie ist das Wetter in Bristol, und brauche ich einen Schirm?“ Ein Agent kann das in wenigen Zügen erledigen. Er nimmt die Frage entgegen und erkennt, dass er aktuelle Daten braucht. Dann ruft er eine Wetter-API auf, die Folgendes zurückgibt:

Temperature: 16°C
Condition: Heavy rain

Damit hat der Agent, was er braucht, und antwortet, dass es in Bristol regnet und ein Schirm eine gute Idee ist. Selbst diese winzige Anfrage brauchte mehr als eine Operation.

Es gibt auch einfache Aufgaben. Eine Frage wie „Was ist 15 × 20?“ braucht nur eine Operation. Schwerer ist etwa: „Recherchiere drei britische Universitäten mit einem MSc in Data Science und vergleiche Studiengebühren und Zulassungsvoraussetzungen.“ Das kann eine Abfolge wie diese erfordern:

Search University A
      ↓
Read information
      ↓
Search University B
      ↓
Read information
      ↓
Search University C
      ↓
Read information
      ↓
Compare results
      ↓
Generate answer

Keine einzelne Antwort eines Sprachmodells deckt das zuverlässig ab. Der Loop erlaubt es dem Agenten, eine große Aufgabe in kleine Aktionen zu zerlegen.

Der Agent als Zustandsautomat

Die Lage des Agenten lässt sich als Zustand beschreiben. Sei s_t der Zustand zum Zeitpunkt t. In jedem Takt erhält der Agent eine Beobachtung o_t, wählt eine Aktion a_t, und die Welt geht in ihren nächsten Zustand über:

In diesem Ausdruck ist s_t der aktuelle Zustand, o_t die aktuelle Beobachtung, a_t die Aktion, f die Zustandsübergangsfunktion und s_{t+1} der nächste Zustand. Auch die Wahl der Aktion lässt sich kompakt schreiben:

Der griechische Buchstabe Pi steht hier für die Entscheidungs-Policy. Bei einem LLM-basierten Agenten ist das Modell Teil dieser Policy. Eine Momentaufnahme könnte so aussehen:

State:
"We need the current weather."


Observation:
"Weather tool is available."
Action:
"Call weather(location='Bristol')"

Und nachdem das Tool geantwortet hat:

New observation:
"16°C, heavy rain"


Next action:
"Generate final response"

Den Agenten so zu sehen, als System, das seinen Zustand ändert, bringt mehr, als ihn für einen Chatbot mit Zusatzschritten zu halten.

Wissen, wann Schluss ist

Die schwierigste Frage beim Loop-Design ist wohl, woran ein Agent erkennt, dass er fertig ist. Stellen Sie sich einen Agenten vor, der hier festhängt:

Call search
 ↓
Get result
 ↓
Call search again
 ↓
Get result
 ↓
Call search again
 ↓
...

Ohne Ausstiegsregel könnte das ewig so weitergehen. Ein Agent in Produktion braucht deshalb Abbruchbedingungen. Einige sind üblich.

Die erste ist der Happy Path: Die Aufgabe ist erledigt.

Task completed → STOP

Die zweite ist ein Schrittbudget, zum Beispiel höchstens fünf:

Maximum steps = 5

Erreicht der Agent fünf Schritte, ohne fertig zu sein, hält er an:

STOP

Die dritte sind wiederholte Tool-Fehler, nach denen der Lauf beendet oder an jemand anderen übergeben werden sollte:

Tool failed repeatedly → STOP / ESCALATE

Die vierte ist eine riskante Aktion, bei der ein Mensch zustimmen muss, bevor irgendetwas passiert:

High-risk action → STOP → Ask human

Kosten, Latenz und Zuverlässigkeit

Behandeln Sie jeden Schritt als etwas, das Geld kostet. Angenommen, ein Schritt kostet so viel:

Ein normaler Lauf mit 10 Schritten kostet dann ungefähr das:

Ein Bug, der 1000 Schritte verursacht, verändert die Summe drastisch:

Für eine einzelne Anfrage kann das schon unangenehm sein.

Mal tausende Nutzer, und das Problem liegt auf der Hand. Bei Loop Engineering geht es deshalb um Kosten, Latenz und Zuverlässigkeit genauso wie um Funktionalität.

Umgang mit Fehlern

Echte Systeme gehen kaputt. Angenommen, der Wetteraufruf liefert Folgendes:

Error: API unavailable

Ein schlecht entworfener Agent scheitert einfach. Ein besserer Loop reagiert auf den Fehler:

Tool call
   ↓
Error
   ↓
Retry?
 ┌─┴─┐
Yes  No
 ↓    ↓
Retry Escalate

Auch Retries brauchen Grenzen. Nach zwei Fehlschlägen etwa kann das System anhalten, statt dieselbe aussichtslose Anfrage immer wieder abzuschicken.

Wo Loops vorkommen

Agent-Loops gibt es in vielen Bereichen. Hier sind fünf typische Zyklen.

Recherche:

Search → Read → Compare → Search again → Summarise

Programmierung:

Read code → Modify code → Run tests → Observe errors → Fix → Test again

Datenanalyse:

Inspect data → Run analysis → Observe result → Create visualisation → Explain

Kundensupport:

Understand issue → Search knowledge base → Check customer data → Respond

Computerbedienung:

Observe screen → Decide action → Click/type → Observe new screen → Continue

Der rote Faden ist einfach: handeln, das Ergebnis beobachten, dann entscheiden, was als Nächstes kommt.

Unkontrollierte und kontrollierte Loops

Vergleichen wir zwei Designs. Das erste gibt dem Modell ein Tool und lässt es laufen:

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
...

Darin kontrolliert nichts irgendetwas. Das zweite Design ergänzt Checkpoints rund um jeden Schritt:

Task
 ↓
Observe
 ↓
Decide
 ↓
Validate action
 ↓
Execute
 ↓
Observe result
 ↓
Evaluate
 ↓
 ┌───────────────┐
 │ Goal complete?│
 └───────┬───────┘
      Yes│    No
         ↓      ↓
       Stop   Continue

Das zweite Design bringt Kontrolle hinein, und genau das ist der Kern von Loop Engineering.

Einen Loop messen

Erfolg sollte man nicht nur daran messen, ob am Ende eine Antwort erscheint. Einige nützliche Messgrößen sind hier aufgeführt:

Weitere Werte, die man verfolgen sollte:

• wie lange eine Aufgabe dauert (Latenz)
• verbrauchte Tokens
• was jede erledigte Aufgabe kostet
• wie oft Aufrufe wiederholt werden
• der Anteil abgeschlossener Aufgaben
• wie oft ein Mensch eingreifen muss

Zusammen zeigen diese Werte, ob ein Agent wirklich besser wird.

Der Zielkonflikt bei der Schrittzahl

Zusätzliche Schritte erlauben es einem Agenten, schwierigere Probleme anzugehen. Sie bringen aber auch höhere Kosten, längere Wartezeiten, mehr Gelegenheiten für Fehler, mehr Tool-Ausfälle und weniger vorhersehbares Verhalten. Ziel ist also nicht, den Agenten möglichst viele Schritte laufen zu lassen. Ziel ist, die Aufgabe mit der kleinsten Schrittzahl zu erledigen, die noch zuverlässig funktioniert.

Was ein verlässlicher Loop braucht

Loop Engineering heißt, den sich wiederholenden Ausführungszyklus eines KI-Agenten zu entwerfen und zu kontrollieren. Das Grundmuster läuft so ab:

Es wiederholt sich, bis die Aufgabe erledigt ist oder das System beschließt anzuhalten. Ein verlässlicher Agent braucht diese Zutaten:

• klar definierte Aktionen
• Iterationen, die jemand kontrolliert
• explizite Abbruchbedingungen
• Fehlerbehandlung
• Obergrenzen für Retries
• verwalteten Zustand
• Ausgabenlimits
• laufende Evaluierung

Autonomie heißt nicht unbegrenzte Ausführung. Ein guter Agent weiß, was als Nächstes zu tun ist, und auch, wann er aufhören muss.

Ein starkes Modell und ein cleverer Loop können trotzdem danebenliegen, wenn der Agent die falschen Informationen bekommt. Das führt zur nächsten Frage: Was sollte ein Agent bei jedem Schritt eigentlich erhalten? Die Antwort gehört zum Context Engineering, bei dem es darum geht, Agenten zur richtigen Zeit die richtigen Informationen zu geben.