Agent Design Patterns: Tool Loop, ReAct, Planning, Reflection, Routing

Bitten Sie fünf Engineers, „einen Agent zu bauen, der Fragen zu Kundenrückerstattungen beantwortet", und Sie erhalten fünf verschiedene Designs. Einer verbindet das Modell mit einer Datenbank und lässt es in einer Loop laufen. Einer lässt es vor jeder Aktion laut denken. Einer lässt es zuerst einen Plan schreiben. Einer lässt es seinen eigenen Entwurf kritisieren. Einer schickt einfache Fragen an ein günstiges Modell und schwierige an einen Experten. Gleiche Aufgabe, fünf Architekturen, und nur einige davon funktionieren wirklich zuverlässig.

Ein Agent ist einfach ein Sprachmodell, das in der Welt handeln kann (Tools aufrufen, suchen, Code ausführen) und anhand der Ergebnisse entscheidet, was als Nächstes zu tun ist. Das gewählte Design Pattern macht den Unterschied zwischen einem Agent, der still seine Arbeit macht, und einem, der endlos loopt, halluziniert oder Geld verbrennt.

Gehen wir die fünf Kern-Patterns durch, jedes mit einer konkreten Aufgabe.

Pattern 1: die Tool-Use-Loop

Das ist die Grundlage, auf der alles Weitere aufbaut. Ein Tool ist jede Funktion, die das Modell aufrufen kann: im Web suchen, eine Bestellung nachschlagen, eine E-Mail senden, eine Datenbank abfragen.

Die Loop ist einfach:

1. Geben Sie dem Modell ein Ziel und eine Liste von Tools.
2. Das Modell antwortet entweder direkt oder verlangt einen Tool-Aufruf.
3. Sie führen das Tool aus und geben das Ergebnis zurück.
4. Wiederholen, bis das Modell eine endgültige Antwort liefert.

Konkrete Aufgabe: „Wie ist der Status von Bestellung #4471?" Das Modell ruft get_order(4471) auf, sieht shipped und antwortet. Ein Tool-Aufruf, fertig.

Hier die Loop in anbieterneutralem Pseudocode. Das SDK jedes Anbieters verpackt genau diese Form.

messages = [{"role": "user", "content": "Status of order #4471?"}]

while True:
    response = model.generate(messages, tools=[get_order, cancel_order])

    if response.tool_calls:
        for call in response.tool_calls:
            result = run_tool(call.name, call.args)   # Sie führen es aus
            messages.append({"role": "tool", "content": result})
    else:
        print(response.text)   # endgültige Antwort, Loop verlassen
        break

Die Tool-Use-Loop reicht für eine große Zahl realer Aufgaben. Greifen Sie zu den raffinierteren Patterns erst, wenn dieses hier zu versagen beginnt.

Pattern 2: ReAct (reason, then act)

ReAct steht für „Reasoning and Acting". Das Modell schreibt vor jeder Aktion einen kurzen Gedanken, handelt dann, liest das Ergebnis und denkt erneut. Es verschränkt Denken und Handeln.

Konkrete Aufgabe: „Welches unserer drei Lager kann einen Stehschreibtisch am schnellsten nach Denver liefern?"

Eine einfache Tool-Loop würde sich vielleicht ein Lager greifen und aufhören. ReAct denkt sich durch:

Thought: Ich brauche Bestand und Lieferzeit von allen drei Lagern. Action: check_stock("desk", "Salt Lake") → auf Lager, 2 Tage Thought: Gut, aber Phoenix kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnte näher sein. Prüfen. Action: check_stock("desk", "Phoenix") → auf Lager, 1 Tag Thought: Phoenix ist schneller. Zur Sicherheit Dallas prüfen. Action: check_stock("desk", "Dallas") → nicht auf Lager Thought: Phoenix gewinnt. Dem Nutzer antworten.

Das sichtbare Reasoning hält das Modell ehrlich und macht Debugging einfach: Wenn etwas schiefgeht, sehen Sie genau, welcher Gedanke in die Irre geführt hat. ReAct ist das Arbeitspferd für Aufgaben, die mehrere voneinander abhängige Abfragen brauchen.

Das Original-Paper ist ein klarer, gut lesbarer Klassiker: ReAct: Synergizing Reasoning and Acting in Language Models.

Pattern 3: Planning (zuerst die Schritte schreiben)

Manchmal soll der Agent über die *gesamte* Aufgabe nachdenken, bevor ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → irgendetwas anfasst. Ein Planner erzeugt vorab eine geordnete Liste von Schritten und führt sie dann einen nach dem anderen aus.

Konkrete Aufgabe: „Erstelle ein Competitive Brief zu drei Konkurrenzprodukten."

ReAct könnte abschweifen. Ein Planner legt sich zuerst fest:

Plan: 1. Die drei wichtigsten Wettbewerber identifizieren. 2. Preise für jeden erheben. 3. Top-Features für jeden erheben. 4. Aktuelle Kundenbeschwerden für jeden finden. 5. Einen einseitigen Vergleich schreiben.

Dann arbeitet er die Liste ab. Der Vorteil: Bei langen, mehrstufigen Aufgaben verliert der Agent nicht auf halber Strecke den Faden. Sie können den Plan außerdem einem Menschen zur Freigabe zeigen, bevor irgendetwas läuft, was wichtig ist, wenn Schritte Geld kosten oder E-Mails versenden.

Ein häufiges Upgrade ist Plan-and-Execute mit Re-Planning: einige Schritte ausführen, prüfen, ob die Realität zum Plan passt, und die restlichen Schritte andernfalls neu schreiben. Echte Arbeit ist unordentlich, und starre Pläne brechen.

Daumenregel: Kurze, explorative Aufgaben sprechen für ReAct. Lange Aufgaben mit vielen bekannten Teilschritten sprechen für einen Planner.

Pattern 4: Reflection (den eigenen Entwurf kritisieren)

Modelle liefern bessere Arbeit, wenn sie sie überprüfen. Eine Reflection Loop lässt den Agent einen Entwurf erzeugen, dann die Rolle wechseln und diesen Entwurf kritisieren, dann überarbeiten.

Konkrete Aufgabe: „Schreibe eine SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen →-Query, die Kunden findet, die im letzten Quartal gechurnt sind."

1. Draft: Der Agent schreibt die Query.
2. Reflect: „Behandelt das Kunden ohne Bestellungen? Verwendet ‚letztes Quartal' die richtigen Daten? Gibt es Joins, die Zeilen duplizieren könnten?"
3. Revise: Er behebt die gerade gefundenen Probleme.

Sie können den Entwurf sogar ausführen und die *tatsächliche* Fehlermeldung zurückgeben, was Reflection in eine engmaschige selbstkorrigierende Loop verwandelt. Dieses Pattern glänzt bei Code, strukturiertem Schreiben und allem, wo es eine klare Vorstellung von „korrekt" gibt.

Eine minimale Reflection Loop:

draft = model.generate("Write a SQL query for churned customers last quarter.")

for _ in range(2):   # Iterationen begrenzen
    critique = model.generate(f"Find bugs or gaps in this query:\n{draft}")
    if "no issues" in critique.lower():
        break
    draft = model.generate(f"Fix these issues:\n{critique}\n\nQuery:\n{draft}")

Eine Warnung: Begrenzen Sie die Loop immer. Ohne Limit kann Reflection sich endlos im Kreis „verbessern" und Ihre Rechnung hochtreiben.

Pattern 5: Routing (an Spezialisten verteilen)

Ein Router schaut sich eine eingehende Anfrage an und schickt sie an den richtigen Handler: ein bestimmtes Modell, ein bestimmtes Tool-Set oder einen bestimmten Sub-Agent. Denken Sie an eine kluge Empfangskraft.

Konkrete Aufgabe: ein Support-Postfach, das drei Arten von Nachrichten erhält.

• Fragen zur Abrechnung → an den Billing-Agent routen (hat Rückerstattungs-Tools).
• Technische Bugs → an den Troubleshooting-Agent routen (kann Logs lesen).
• „Wie mache ich...?"-Fragen → an ein günstiges, schnelles Modell mit den Docs routen.

Routing kann zwei Dinge gut. Es hält jeden Spezialisten einfach, denn ein Billing-Agent, der nur Abrechnung bearbeitet, lässt sich leichter richtig hinbekommen als ein Agent, der alles versucht. Und es spart Geld: einfache Fragen an ein kleines, günstiges Modell, das teure Modell bleibt den schwierigen vorbehalten.

Ein Router ist oft nur ein Modellaufruf, der eine Kategorie zurückgibt:

route = model.generate(
    f"Classify this message as one of: billing, technical, howto.\n\n{message}"
)

handler = {"billing": billing_agent,
           "technical": tech_agent,
           "howto": docs_agent}[route.strip()]

handler.run(message)

So werden 2026 die meisten ernsthaften Produktions-Agents gebaut: nicht ein riesiges Gehirn, sondern ein Dispatcher vor mehreren fokussierten Spezialisten.

Patterns kombinieren

Das sind keine rivalisierenden Lager. Echte Systeme stapeln sie.

Ein Support-Agent in Produktion könnte: eine Nachricht an den Billing-Spezialisten routen, der eine ReAct-Loop über seine Rückerstattungs-Tools laufen lässt, und wenn er eine Kunden-E-Mail entwirft, vor dem Versand einen Reflection-Durchgang ausführen. Ein Research-Agent könnte den Report planen und dann für jeden Abschnitt eine Tool Loop nutzen.

Starten Sie mit dem einfachsten Pattern, das funktionieren könnte (meist die einfache Tool Loop), und fügen Sie Komplexität erst hinzu, wenn Sie ein konkretes Versagen sehen. Ein Agent zu over-engineeren ist ein genauso reales Risiko wie ihn zu under-engineeren.

Jeder große Anbieter liefert ein SDK, das Ihnen diese Patterns als Bausteine gibt: das OpenAI Agents SDK, das Claude Agent SDK und Googles Agent Development Kit (ADK). Die Patterns hier lassen sich über alle hinweg übertragen; die Deep-Dive-Blöcke zu den Anbietern behandeln die toolspezifische Syntax. Für eine breite, anbieterneutrale Übersicht ist Anthropics Building Effective Agents eine sehr gute kostenlose Lektüre.

Key Takeaways

• Starten Sie mit der Tool-Use-Loop. Dem Modell Tools geben, sie ausführen, Ergebnisse zurückgeben, wiederholen. Die meisten Aufgaben brauchen nicht mehr.
• Passen Sie das Pattern zur Aufgabe. ReAct für explorative, voneinander abhängige Abfragen; einen Planner für lange mehrstufige Aufgaben; Reflection für alles mit einer „korrekten" Antwort; Routing, wenn Anfragen in klare Kategorien fallen.
• Begrenzen Sie Ihre Loops immer. Reflection und ReAct können endlos kreisen. Setzen Sie eine maximale Zahl an Iterationen und ein Budget.
• Routen Sie, um Geld zu sparen und einfach zu bleiben. Einfache Anfragen an ein günstiges Modell, schwierige an einen Experten. Kleine fokussierte Spezialisten schlagen einen riesigen Alles-Agent.
• Stapeln Sie Patterns, aber verdienen Sie sich die Komplexität. Fügen Sie einen Planner oder einen Reflection-Schritt erst hinzu, wenn Sie ein echtes Versagen gesehen haben, nicht vorher.