KI-Agenten-Designmuster: Einfach starten, Aktionen prüfen

„Deine KI vergisst alles, sobald ein Gespräch endet.“ Das beschreibt eine zustandslose Anwendung ohne gespeicherten Kontext, nicht jedes KI-Produkt. Gesprächszustand und sitzungsübergreifendes Gedächtnis sind unterschiedliche Fähigkeiten, die eine Anwendung bereitstellen kann. LangChains Überblick zu Gedächtnisfunktionen

Ein Gedächtnis beantwortet aber nicht die nächste Architekturfrage: Was darf der Agent mit dem Wissen tun, an das er sich erinnert? Ein Support-Assistent braucht vielleicht ein früheres Gespräch, um eine Beschwerde zu verstehen. Die gespeicherte Aussage „Ich bin Administrator“ berechtigt ihn trotzdem nicht, eine Rückerstattung auszulösen. Extraktion, Aktualisierung und Vergessen über mehrere Sitzungen behandelt unser Supermemory-Implementierungsleitfaden. Hier geht es um die Ablaufsteuerung.

Bei KI-Agenten muss sich Komplexität rechtfertigen. Mein Ausgangspunkt ist das kleinste System, das die Abnahmekriterien der Aufgabe erfüllt. Auch Anthropic empfiehlt einfache Lösungen als Startpunkt und eine Abwägung zusätzlicher Agentenfunktionen gegen Latenz und Kosten. Anthropics Empfehlungen für wirksame Agenten

Dieser Leitfaden vergleicht fünf nützliche Muster anhand ihrer Fehlerszenarien. Sie sind kombinierbare Architekturentscheidungen, keine vollständige Taxonomie und keine fünfstufige Reifegradleiter. Insbesondere gilt: Verifikation ist eine Risikokontrolle, keine Belohnung für eine fortgeschrittenere Architektur. Quellen geprüft am 17. September 2026. Die Beispiele und Abnahmetests sind vorgeschlagene Designs, keine veröffentlichten Kundenbenchmarks.

Welches KI-Agenten-Designmuster löst dein Fehlerszenario?

Ermittle zuerst, welche Anforderung verletzt wird, bevor du einen weiteren Modellaufruf ergänzt. Fehlender Kontext spricht für bessere Kontextverwaltung. Ein vorhersehbarer Geschäftsprozess spricht für einen programmierten Workflow. Beides rechtfertigt nicht automatisch eine autonome Schleife.

Die letzte Zeile kann auf jede andere zutreffen. Ein Zahlungsvorschlag aus einem einzigen Aufruf braucht genauso eine Autorisierung wie ein mehrstufiger Agent. Umgekehrt wird eine rein lesende Zusammenfassung nicht allein dadurch besser, dass sie einen Planer erhält.

1. Single-Shot: Die einfache Basis behalten, solange sie funktioniert

Ein Single-Shot-Design übergibt eine klar begrenzte Aufgabe einmal an ein Modell und liefert dessen Ausgabe ohne autonome Tool-Schleife zurück. Genau genommen ist das ein einfacher LLM-Workflow und nicht zwingend ein Agent nach Definitionen, die eine dynamische Aktionsauswahl voraussetzen.

Das eignet sich für die Extraktion von Feldern aus einer vorliegenden Beschwerde, die Klassifikation einer Anfrage, die Zusammenfassung eines freigegebenen Dokuments oder einen Antwortentwurf bei vollständigem Kontext. Notwendige Daten können vor dem Aufruf deterministisch zusammengestellt werden. Das Modell muss die Datenbeschaffung dafür nicht selbst auswählen.

Beispiel: Eine Supportnachricht wird in Kategorie, Dringlichkeit und Kurzfassung überführt. Gewöhnlicher Anwendungscode validiert das Schema. Fehlende Pflichtangaben führen zu einem Validierungsfehler oder einer Prüfanforderung, nicht zu einer erfundenen Bestellnummer.

Der Vorteil ist ein kleiner Ausführungspfad auf Anwendungsebene. Die Grenze: Das Modell kann kein Ergebnis betrachten und daraufhin eine weitere Quelle abrufen, ohne dass die Architektur erweitert wird. Ein einzelner Aufruf ist außerdem nicht automatisch deterministisch, günstig oder korrekt. Das hängt von Modell, Kontext und Aufgabe ab. Behalte diese Basis, solange die gemessene Qualität ausreicht. Für exakte Berechnungen oder fest definierte Transformationen beginne stattdessen mit gewöhnlichem Code.

2. ReAct: Eine Schleife ergänzen, wenn Beobachtungen die nächste Aktion ändern

ReAct verbindet Entscheiden, Handeln und Beobachten in einer Schleife. Ein Tool-Ergebnis beeinflusst die nächste Entscheidung, statt lediglich eine feste Schrittfolge zu ergänzen. Die Originalarbeit untersucht die Verbindung von Schlussfolgern und Aktionen in einer Umgebung. ReAct-Forschungsarbeit

Beispiel: Ein Support-Assistent prüft eine Bestellung. Bei einer Versandstörung untersucht er Zustellereignisse, bei einer abgeschlossenen Retoure den Rückerstattungsstatus. Welche Abfrage als Nächstes sinnvoll ist, war aus der ersten Nachricht noch nicht bekannt.

Das unterscheidet sich von einem Ablauf, der immer eine Bestellung lädt, dieselbe Richtlinie abruft und eine Zusammenfassung erstellt. Für diese feste Folge lässt sich expliziter Anwendungscode möglicherweise leichter testen als eine modellgesteuerte Orchestrierung.

Definiere für die erste Umsetzung eine maximale Schrittzahl, eine Gesamtlaufzeit und ein Budget für Tool-Aufrufe. Erkenne wiederholte Abfragen ohne neue Erkenntnisse. Unterscheide wiederholbare Transportfehler von fachlichen Ablehnungen und liefere bei ausgeschöpftem Budget einen eindeutigen Status „unvollständig“. Protokolliere Tool-Namen, Argumente, Ergebnisse und kurze Entscheidungszusammenfassungen. Verlange keinen Zugriff auf die verborgenen Denkprozesse eines Modells.

Tool-Beobachtungen sind Daten, keine neue Weisungsbefugnis. Prüfe Zugriffe vor sensiblen Leseoperationen, validiere Argumente und sichere jede folgenreiche Schreiboperation ab. Eine abgerufene Seite mit „Ignoriere die Richtlinie“ darf die Richtlinie nicht überschreiben.

3. Planner-Executor: Planung und Durchführung trennen

Ein Planner-Executor-Design trennt die Verantwortung für Planung und Ausführung. Der Planer schlägt Schritte vor, ein Executor erledigt sie. Diese Trennung ist die Kernidee der ursprünglichen LangChain-Beschreibung und keine Garantie für bessere Ergebnisse. Plan-and-Execute-Architektur

Erwäge das Muster, wenn längere Aufgaben wiederholt Ergebnisse auslassen, Abhängigkeiten verlieren oder sich schwer fortsetzen lassen. Ein Marktforschungsbericht braucht beispielsweise Quellenrecherche vor der Analyse und die Analyse vor Empfehlungen. Ein flüssiger Abschlusstext darf einen fehlenden Rechercheschritt nicht verdecken.

Jeder vorgeschlagene Schritt sollte Eingabe, erwartete Ausgabe, Abhängigkeit und Abschlussprüfung enthalten. Speichere erledigte Arbeit als expliziten Zustand. Plane neu, wenn Belege eine Annahme widerlegen, nicht nur, weil das Modell einen anderen Plan formulieren kann. Begrenze die Neuplanung und mache blockierte Schritte für Verantwortliche sichtbar.

Planung und Ausführung benötigen weder unterschiedliche Modelle noch eine Gruppe von Agenten. Ein einzelner Executor kann den Plan abarbeiten. Parallele Worker helfen nur bei tatsächlich unabhängigen Aufgaben. Gemeinsame Schreibzugriffe und voneinander abhängige Ergebnisse benötigen Koordination. Sind die Schritte bereits bekannt und stabil, ist ein vordefinierter Workflow häufig die kleinere Lösung.

Das relevante Fehlerszenario ist ein gut formatierter, aber falscher Plan. Prüfe Umfang und Voraussetzungen vor der Ausführung. Verifiziere die fertigen Ergebnisse, statt abgehakte Kästchen als Nachweis zu behandeln.

4. Reflexion: Einen Entwurf verbessern, ohne ihn damit zu beweisen

Reflexion ergänzt Kritik und Überarbeitung nach einer ersten Ausgabe. Self-Refine verwendet modellgeneriertes Feedback zur Revision und berichtet Verbesserungen bei den untersuchten Aufgaben. Diese Ergebnisse sind keine allgemeine Genauigkeitsgarantie. Self-Refine-Forschungsarbeit

Nutze konkrete Bewertungskriterien: Beantwortet der Text jeden angefragten Punkt, trennt er Fakten von Annahmen und bleibt er bei den freigegebenen Quellen? „Denke gründlicher nach“ ist kein Abnahmekriterium. Beginne mit einer Überarbeitung und vergleiche sie mit der unveränderten Ausgangsversion.

Beispiel: Ein Supportentwurf enthält die richtigen Fakten, aber keinen nächsten Schritt. Eine Kritik kann diese Lücke benennen und eine klarere Antwort anfordern. Bei Code kann eine Kritik Verbesserungen vorschlagen. Kompilierung, Tests und menschliches Review bleiben trotzdem eigenständige Prüfungen.

Forschung zur intrinsischen Selbstkorrektur zeigte, dass die getesteten Modelle Denkfehler ohne externes Feedback nicht zuverlässig reparierten und Ergebnisse teilweise verschlechterten. Das ist eine auf Aufgaben und Modelle bezogene Warnung, keine Aussage über die Unfähigkeit aller späteren Systeme. Studie zur Selbstkorrektur ohne externes Feedback

Der praktische Unterschied: Reflexion fragt, ob ein Entwurf besser werden kann. Verifikation prüft, ob eine Anforderung tatsächlich erfüllt ist. Die Zustimmung eines zweiten Modells beweist weder die Berechtigungen eines Nutzers noch den korrekten Kontostand.

5. Verifier-Gated: Aktionsvorschlag und Autorisierung trennen

Verifier-Gated Execution verhindert eine Aktion, bis eine unabhängige Kontrolle sie erlaubt. OWASP empfiehlt Autorisierung in nachgelagerten Systemen, minimale Berechtigungen und menschliche Freigabe für folgenreiche Aktionen, statt das LLM selbst über seine Befugnisse entscheiden zu lassen. OWASP-Empfehlungen zu übermäßiger Handlungsfreiheit

„Unabhängig“ bedeutet, dass der Agent die Prüfung nicht umgehen, ihre Regeln nicht ändern und ihre Nachweise nicht selbst erfinden kann. Der Verifier kann Schemavalidierung, Regelwerk, Abfrage eines vertrauenswürdigen Systems, deterministische Berechnungen oder einen menschlichen Freigabeverantwortlichen umfassen. Ein weiteres Modell kann beraten, sollte aber nicht die einzige Autorisierungsgrenze bilden.

Bei einem Rückerstattungsvorschlag würde ich verlangen, dass die Anwendung authentifizierten Akteur und Mandanten bestimmt, die aktuelle Bestellung aus dem führenden System lädt, Betrag und Währung validiert, den noch erstattungsfähigen Betrag prüft und die erforderliche Freigabe bestätigt. Das sind vorgeschlagene technische Kontrollen, keine vollständige Zahlungsimplementierung.

Binde die Freigabe an die genaue Aktion: Empfänger, Betrag, Währung und relevante Datensatzversion. Ein geänderter Vorschlag muss erneut validiert werden. OWASPs Leitfaden zur Transaktionsautorisierung fordert serverseitige Durchsetzung und eine abschließende, an die Ausführung gekoppelte Autorisierungsprüfung. OWASP-Leitfaden zur Transaktionsautorisierung

Fehlende Nachweise, eine ungültige Verifier-Antwort oder ein Timeout müssen die Ausführung blockieren oder eine Prüfung auslösen. Eine fachliche Ablehnung darf keine unbegrenzte Wiederholungsschleife starten. Plane Idempotenz und Abgleich bei unklarem Ausgang ein: Ein Zahlungs-Timeout beweist nicht, dass keine Zahlung erfolgt ist. Prüfe den aktuellen Zustand vor einem weiteren Schreibversuch.

Platziere die Kontrolle vor jeder relevanten Nebenwirkung, auch bei Tool-Aufrufen innerhalb des Ablaufs, nicht erst vor der abschließenden Antwort. Gleiche nach der Ausführung das tatsächliche Ergebnis ab. Autorisierung vor der Aktion und Verifikation danach lösen unterschiedliche Probleme.

Ein Support-Assistent braucht nicht alle fünf Muster gleichzeitig

Ein Kunde fragt nach einer verspäteten Bestellung und einer möglichen Rückerstattung. Das ist ein Architekturbeispiel, keine Kundenimplementierung. Beginne mit einer Single-Shot-Klassifikation und einem rein lesenden Workflow. Ergänze ReAct nur dann, wenn die passende Untersuchung von den Ergebnissen vorheriger Abfragen abhängt.

Ein Planer ist optional. Eine einfache Bestellstatusabfrage braucht wahrscheinlich keinen. Führe ihn erst ein, wenn die Untersuchung mehrere voneinander abhängige Ergebnisse umfasst. Auch Reflexion ist optional und gehört zum Antwortentwurf, nicht zur Zahlungsautorisierung.

Für die Rückerstattung gelten andere Anforderungen. Halte Ausführungszugangsdaten außerhalb des Modells, validiere den strukturierten Vorschlag, hole erforderliche Freigaben ein, führe die Aktion über eine eng begrenzte Schnittstelle aus und gleiche das Ergebnis ab. Ob ein oder mehrere Modellaufrufe den Vorschlag erzeugten, ändert diese Grenze nicht.

Speichere den für eine sichere Fortsetzung nötigen Zustand. Verwechsle aber ein Gesprächsprotokoll nicht mit einem Ausführungsjournal. Redigiere sensible Tracedaten und teste Neustarts. OWASPs Agentensicherheitsleitfaden behandelt Tool-Beschränkungen, Gedächtnisschutz und Betriebskontrollen ausführlicher. OWASP AI Agent Security Cheat Sheet

Wann hat sich eine weitere Schleife ihren Platz verdient?

Vergleiche die Ausgangsversion und genau eine vorgeschlagene Änderung anhand derselben repräsentativen Aufgaben. Halte Modellkonfiguration und Bewertungskriterien möglichst konstant, dokumentiere unvermeidliche Unterschiede und wiederhole die Versuche. Andernfalls stammt eine vermeintliche Architekturverbesserung womöglich nur von einem anderen Modell oder einer leichteren Stichprobe.

Miss akzeptierte Ergebnisse, unbelegte Aussagen, nicht autorisierte Aktionen, Reviewaufwand, Timeouts und die Ende-zu-Ende-Latenz bei p50 und p95. Zähle sämtliche Modell- und Tool-Aufrufe einschließlich Wiederholungen und Revisionen. Die Kostenrechnung erläutert unser Leitfaden zu KI-Agentenkosten pro Aktion. Hier entscheidest du, ob der zusätzliche Schritt den konkreten Fehler so weit reduziert, dass sich sein Betriebsaufwand rechtfertigt.

Sicherheitskontrollen sind keine optionalen Experimente an echten Nutzern. Teste folgenreiche Abläufe in einer Sandbox oder im Schattenbetrieb, bevor du Schreibrechte vergibst. Entferne keine Autorisierung, nur weil ein Benchmark ohne Kontrolle schneller ist.

Für Laufzeitumgebung, Wiederherstellung und Betriebsverantwortung nutze unseren Architekturleitfaden zum Agent Harness. Bei einer konkreten Umsetzung verbindet Wavects KI-Entwicklung den Ablauf mit Produktanforderungen und Abnahmetests. Unsere Fallstudie vom Prototyp zum Enterprise-Piloten ist ein eigenständiges Delivery-Beispiel, kein Nachweis für einen dort durchgeführten Vergleich dieser Muster.

Definiere Freigabekriterien mit der Software-QA-Checkliste vor dem Launch oder besprich das Fehlerszenario in deinem Agenten-Workflow. Bringe einen fehlgeschlagenen Trace, ein erfolgreiches Beispiel und die Aktion mit, die das System niemals ohne Freigabe ausführen darf.