Reflection-Agent-Pattern: Qualitätskontrolle in einem Durchlauf

Pattern-Kern

Reflection Agent ist ein Pattern, bei dem der Agent nach einem Entwurf eine schnelle Qualitätsprüfung macht: Er findet offensichtliche Probleme (unklare Formulierungen, Widersprüche, zu sichere Aussagen) und korrigiert sie einmal vor der finalen Antwort.

Wichtig: Reflection ist ein leichter Check vor dem Senden. Es ist keine vollständige Prüfung nach Regeln oder Policies.

Wann einsetzen: wenn vor dem Senden eine kurze kontrollierte Selbstprüfung und genau eine Revision nötig ist.

Reflection ersetzt den eigentlichen Arbeitsprozess des Agenten nicht.

Es ergänzt eine kurze Kontrollstufe:

• schnell prüfen, ob die Antwort klar ist, sich nicht widerspricht und keine wichtigen Hinweise auslässt
• offensichtliche Risiken finden
• nur das korrigieren, was nötig ist
• abschließen, ohne einen neuen Endlos-Loop zu erzeugen

Problem

Stell dir vor, ein Agent schreibt eine Antwort für einen High-Risk-Request.

Der Entwurf ist grundsätzlich richtig, hat aber kleine Risiken:

• zu kategorische Formulierung ohne Grundlage
• Widerspruch zwischen Absätzen
• fehlender Hinweis/Caveat
• unklare Gültigkeitsgrenzen

Ohne Kontroll-Durchlauf geht dieser Entwurf direkt an den Nutzer.

Die gefährlichsten Fehler sind oft nicht grob, sondern "fast unsichtbar" in normal wirkendem Text.

Folgen:

• Vertrauen in die Antwort sinkt
• falsche Sicherheit entsteht
• Risiko für Fehlentscheidungen steigt

Genau das ist das Problem: selbst ein guter Entwurf kann ohne Prüfung mit kritischen Ungenauigkeiten nach außen gehen.

Lösung

Reflection ergänzt eine Reflection-Policy vor der finalen Auslieferung.

Analogie: wie ein Schneider vor der Ausgabe eines Anzugs. Er prüft zuerst den Sitz und macht dann eine präzise Anpassung. Das verbessert das Ergebnis, macht den Prozess aber nicht zu endlosen Anproben.

Kernprinzip: Eine kurze Qualitätsprüfung und eine Korrektur, ohne endloses "noch besser machen".

Der Agent darf Änderungen vorschlagen, aber die Policy definiert:

• ob eine Revision nötig ist
• was genau geändert werden darf
• wann Stop/Eskalation gilt

Gesteuerter Ablauf:

1. Entwurf: erste Version erzeugen
2. Review: eine strukturierte Prüfung ausführen
3. Entscheidung: ok/revidieren/eskalieren
4. Revision: eine patch-only-Änderung nach fix_plan
5. Finalisieren: finales Ergebnis ohne neuen Loop zurückgeben

Das bringt:

• Entfernung offensichtlicher Risiken vor dem Senden
• spürbare Qualitätssteigerung mit kleinem Overhead
• Revisionskontrolle innerhalb von fix_plan
• Schutz vor endlosem Self-Edit

Funktioniert gut, wenn:

• no_new_facts erzwungen wird
• Änderungen nur als patch-only erlaubt sind
• High-Risk-Fälle eskaliert statt endlos umgeschrieben werden

Das Modell "will" oft immer weiter editieren, aber genau die reflection-policy beendet den Prozess in vorhersagbaren Grenzen.

Wie Es Funktioniert

Zentrale Regel: Reflection muss begrenzt sein.

Das heißt:

• maximal 1 Review-Pass
• maximal 1 Revisions-Pass
• keine neuen Fakten hinzufügen
• Revision muss patch-only sein und nur innerhalb von fix_plan
• bei High-Risk-Problemen eskalieren

Im Code Sieht Das So Aus

draft = writer.generate(goal, context)

review = reflector.review_once(
    draft=draft,
    rubric=[
        "no_new_facts",
        "preserve_uncertainty",
        "consistency_check",
    ],
)

if review.high_risk:
    return escalate_to_human(review.reason)

if review.ok:
    return draft

revised = writer.revise_once(
    draft=draft,
    fix_plan=review.fix_plan,
    rules=["no_new_facts", "keep_scope"],
)

# optional: prüfen, dass Revision innerhalb von `fix_plan` blieb
approved = supervisor.review_output_patch(
    original=draft,
    revised=revised,
    allowed_changes=review.fix_plan,
)

return approved

Reflection sollte nicht "bis perfekt" laufen. Ein Review-Pass, eine Überarbeitung via revise, und eine Prüfung, dass die Revision innerhalb von fix_plan blieb.

So Sieht Es Zur Laufzeit Aus

Goal: eine präzise Antwort mit korrekter SLA-Formulierung vorbereiten

Draft:
"SLA für alle Kunden beträgt 99.99%."

Review:
- Problem: zu kategorische Aussage
- Problem: Tarifstufe fehlt
- Fix: Bedingung und Quelle ergänzen

Revised:
"SLA hängt von der Tarifstufe ab. Für Enterprise beträgt sie 99.99% gemäß Support-Policy."

Wann Es Passt - Und Wann Nicht

Passt

Passt Nicht

Denn Reflection fügt einen weiteren Generierungs-Pass hinzu und erhöht Zeit und Kosten der Antwort.

Unterschied Zu Self-Critique

Reflection ist ein schneller begrenzter Kontrolllauf. Self-Critique ist ein tieferer Durchlauf mit Umschreiben.

Wann Reflection Unter Anderen Patterns Nutzen

Nutze Reflection, wenn eine Antwort vor dem Senden schnell geprüft werden muss: klar, logisch und ohne offensichtliche Fehler.

Kurzer Test:

• wenn du "kurz prüfen und vor dem Final korrigieren" musst -> Reflection
• wenn du "tief per Checkliste kritisieren und umschreiben" musst -> Self-Critique Agent

Wie Mit Anderen Patterns Kombinieren

• Reflection + RAG: Reflection prüft, dass Schlussfolgerungen wirklich zu den gefundenen Quellen passen.
• Reflection + Supervisor: High-Risk-Schlussfolgerungen werden nicht automatisch gefixt, sondern zur menschlichen Freigabe gesendet.
• Reflection + ReAct: nach einer Reihe von ReAct-Schritten macht der Agent einen finalen Check vor der Antwort.

Kurz

Vorteile Und Nachteile

FAQ

Q: Kann Reflection Fact-Checking und Tests ersetzen?
A: Nein. Das ist eine zusätzliche Qualitätsstufe. Fact-Checking, Validierung und Policy-Kontrollen bleiben separat nötig.

Q: Warum ist ein Pass-Limit wichtig?
A: Sonst wird Reflection zum zweiten Loop: Latenz, Kosten und Risiko neuer Fehler steigen.

Q: Was tun, wenn Reflection ein High-Risk-Problem findet?
A: Nicht automatisch weitermachen. Prozess stoppen oder zu menschlicher Prüfung / Supervisor-Policy eskalieren.

Was Danach

Reflection ergänzt eine begrenzte Qualitätskontrolle vor der finalen Antwort.

Was tun, wenn eine strengere Kritik und ein Revisionsprozess mit strukturierten Änderungsregeln nötig sind?