Planning vs Reactive Agents: was ist der Unterschied

Planning agents und reactive agents wirken oft wie Konkurrenten, aber in der Praxis sind es zwei Steuerungsmodi fuer Agentenverhalten. Planning fokussiert auf expliziten Plan, reactive fokussiert auf schnelle Anpassung an den aktuellen Zustand.

Vergleich in 30 Sekunden

Planning agents sind ein Ansatz, bei dem Agent zuerst einen Plan erstellt (Phasen, Reihenfolge, Abschlusskriterien) und ihn danach mit kontrollierten Korrekturen ausfuehrt.

Reactive agents sind ein Ansatz, bei dem Agent den naechsten Schritt im runtime ohne langen upfront-Plan entscheidet: observe -> decide -> act.

Hauptunterschied: Planning optimiert Konsistenz in langen Aufgaben, reactive optimiert schnelle Reaktion auf Kontextaenderungen.

Praktische Regel: wenn Aufgabe lang ist und eine vorhersagbare Aktionsreihenfolge braucht, gewinnt haeufig planning. Wenn Aufgabe kurz, dynamisch und stark von "was gerade passiert ist" abhaengt, gewinnt haeufig reactive.

Vergleichstabelle

Der zentrale Architektur-Unterschied ist, wo die Hauptsteuerungsentscheidung faellt: vor Ausfuehrungsstart oder bei jedem runtime-Schritt.

Architektonischer Unterschied

Planning agents sind um expliziten Plan und Phasenkontrolle gebaut. Reactive agents sind um schnellen Entscheidungszyklus auf Basis des aktuellen Zustands gebaut.

Engineering-Analogie: Planning ist eine Route mit Checkpoints, die vor Start validiert werden kann.
Reactive ist Fahren in Echtzeit, bei dem das naechste Manoever von der aktuellen Verkehrslage abhaengt.

In diesem Schema ist die Staerke vorhersagbare Ausfuehrung langer Route. Schwaeche ist Risiko eines veralteten Plans.

In diesem Schema ist die Staerke runtime-Anpassung. Schwaeche ist schwierigere Kontrolle langfristiger Strategie.

Was Planning Agents sind

Planning agents sind ein Ansatz, bei dem Agent zuerst Task-Plan erstellt und dann Schritte mit expliziter Fortschrittspruefung ausfuehrt.

Typischer Flow:

request -> create plan -> validate -> execute steps -> replan (if needed) -> finalize

Planning Agents Ideenbeispiel (Pseudocode)

Unten ist eine Logik-Illustration, kein woertliches API.

KNOWN_STEP_STATUSES = {"done", "blocked", "failed", "needs_replan"}

def run_planning_agent(request):
    state = init_state(request, max_steps=20, max_replans=3, budget_usd=1.4)
    plan = planner.create_plan(request)

    if not validate_plan(plan, max_steps=state.max_steps):
        return fail("invalid_plan")

    step_idx = 0
    replans = 0

    # Globaler Ausfuehrungs-Timeout und Watchdog sind auf Infrastruktur-Ebene.
    while step_idx < len(plan.steps) and state.cost_usd < state.budget_usd:
        step = plan.steps[step_idx]

        verdict = policy.check(step)
        if verdict == "deny":
            return fail("policy_denied")

        if verdict == "needs_approval":
            if not wait_for_human_approval(state.trace_id, timeout_sec=120):
                return fail("approval_timeout")

        result = executor.run(step, timeout_sec=10, retries=1)
        if result.status not in KNOWN_STEP_STATUSES:
            emit_trace(state.trace_id, step, "unknown_step_status")
            return fail("unexpected_step_response")

        emit_trace(state.trace_id, step, result.status)

        if result.status == "failed":
            return fail("step_failed")

        if result.status == "needs_replan":
            replans += 1
            if replans > state.max_replans:
                return fail("replan_limit_exceeded")

            plan = planner.replan(state, failed_step=step)
            if not validate_plan(plan, max_steps=state.max_steps):
                return fail("invalid_replan")

            # Nach replanning starten wir neuen Plan von vorne; Loop ist durch max_replans begrenzt.
            # max_steps begrenzt Laenge eines Plans; gesamtes oberes Schritt-Limit haengt von replanning ab
            # (meist als max_steps * (max_replans + 1) abgeschaetzt).
            step_idx = 0
            continue

        if result.status == "blocked":
            return fail("blocked_without_recovery")

        state = observe(state, step, result)
        step_idx += 1

    if state.cost_usd >= state.budget_usd:
        return fail("budget_exceeded")

    if step_idx < len(plan.steps):
        return fail("step_limit_or_incomplete")

    return finalize(state)

Staerke des planning-Ansatzes ist Steuerbarkeit langer Aufgaben. Schwaeche ist: wenn Plan schwach oder veraltet ist, skalieren Fehler mehrere Schritte nach vorne.

Was Reactive Agents sind

Reactive agents sind ein Ansatz, bei dem Agent keinen langen fixen Plan haelt, sondern naechsten Schritt aus aktuellem Zustand entscheidet.

Typischer Flow:

request -> observe -> decide next action -> act -> observe

Reactive Agents Ideenbeispiel (Pseudocode)

Unten ist eine Logik-Illustration, kein woertliches API.

KNOWN_ACTION_STATUSES = {"ok", "blocked", "failed", "no_op"}

def run_reactive_agent(request):
    state = init_state(request, max_steps=16, budget_usd=0.9)

    # Globaler Loop-Timeout und Watchdog sind auf Infrastruktur-Ebene.
    while state.step < state.max_steps and state.cost_usd < state.budget_usd:
        action = reactive_policy.decide(state)

        if action.type == "final":
            return finalize(state)

        verdict = policy.check(action)
        if verdict == "deny":
            return fail("policy_denied")

        # Approval vor riskanter Aktion, um separaten approved_retry-Loop nach blocked zu vermeiden.
        if verdict == "needs_approval":
            if not wait_for_human_approval(state.trace_id, timeout_sec=90):
                return fail("approval_timeout")

        result = tool_gateway.call(action, timeout_sec=8, retries=1)
        if result.status not in KNOWN_ACTION_STATUSES:
            emit_trace(state.trace_id, action, "unknown_action_status")
            return fail("unexpected_action_response")

        emit_trace(state.trace_id, action, result.status)

        if result.status == "failed":
            return fail("action_failed")

        if result.status == "blocked":
            # blocked bedeutet hier externe Ausfuehrungssperre, nicht fehlendes approval.
            return fail("blocked_without_recovery")

        # no_op beendet Loop nicht: Stop wird durch max_steps/budget/explicit final gesteuert.
        # observe/state update muss step erhoehen, damit kein Retry-Pfad den Zaehler umgeht.
        state = observe(state, action, result)

    if state.step >= state.max_steps:
        return fail("step_limit_exceeded")

    if state.cost_usd >= state.budget_usd:
        return fail("budget_exceeded")

    return finalize(state)

Staerke des reactive-Ansatzes ist schnelle Anpassung an Veraenderungen. Schwaeche ist: ohne harte Grenzen wird Loop leicht zu teurem und verrauschtem Schritt-Probieren.

Wann Planning Agents einsetzen

Planning agents passen, wenn Szenario lang, strukturiert und empfindlich fuer Schrittreihenfolge ist.

Passt

Wann Reactive Agents einsetzen

Reactive agents passen, wenn sich Umgebung haeufig aendert und schnelle lokale Reaktion wichtig ist.

Passt

Nachteile von Planning Agents

Planning-Ansatz erhoeht Vorhersagbarkeit, hat aber eigene Risiken in dynamischer Umgebung.

Nachteile von Reactive Agents

Reactive-Ansatz ist flexibel, kippt ohne Disziplin aber schnell in instabilen Loop.

In der Praxis funktioniert oft ein hybrider Ansatz

Hauefiges Praxis-Szenario: Support-Automatisierung in SaaS startete als reaktiver Agent.

Am Start funktionierte reaktiver Loop gut fuer kurze Aufgaben: Status pruefen, Daten holen, antworten oder eine Aktion ausfuehren.

Dann entstanden Trigger fuer zusaetzlichen planning-Layer:

• Enterprise-Anfragen brauchten lange Route mit mehreren Abhaengigkeiten
• Incidents stiegen, bei denen lokal korrekte Schritte nicht zur korrekten Endaktion fuehrten
• Compliance verlangte explizite Spur: warum genau diese Schrittreihenfolge gewaehlt wurde

Was im reaktiven Loop blieb:

• kurze operative Aktionen mit schnellem Feedback
• runtime-Anpassung nach Antworten externer API
• guenstiger Pfad fuer viele "schnelle" Anfragen

Was in planning-Layer verschoben wurde:

• Aufbau phasenbasierter Route fuer lange Faelle
• Plan-Validierung vor Ausfuehrungsstart
• replanning-Limits und explizite Abschlusskriterien (criteria of done)

Warum das funktionierte:

• kurze Aufgaben blieben schnell
• lange Aufgaben wurden vorhersagbarer und leichter zu debuggen
• Team schrieb nicht den ganzen Loop neu, sondern isolierte nur Szenarien mit langem Entscheidungshorizont

Kurz gesagt

FAQ

Q: Was zuerst waehlen: planning oder reactive?
A: Teams starten oft mit reactive fuer schnelleren Launch. Fuer high-risk oder auditable Szenarien kann planning aber der Startpunkt sein.

Q: Wann reicht reactive nicht mehr aus?
A: Wenn drei Signale gemeinsam auftreten: Szenario-Laenge waechst, Incidents "Schritte waren logisch, Ergebnis war falsch" haeufiger werden, und Debugging Dutzende kleiner Entscheidungen ohne expliziten Plan rekonstruieren muss.

Q: Wann ist planning overengineering?
A: Wenn der meiste Traffic kurze dynamische Aufgaben sind und Team mehr Zeit in Planbau und Planpflege als in echten Nutzer-Value investiert.

Q: Koennen planning und reactive in einem System kombiniert werden?
A: Ja, und das ist meist der praktischste Weg. Planning steuert oft das lange Prozess-"Skelett", waehrend reactive einzelne Schritte ausfuehrt, die vom aktuellen Zustand abhaengen.

Q: Welche Signale zeigen, dass planning-Layer noetig wird?
A: Praktische Signale: wiederholte Ausfaelle mitten in langen Routen, haeufige manuelle Eingriffe zur Korrektur der Schrittreihenfolge, Compliance-Anforderungen an erklaerbare Entscheidungssequenz.

Q: Welche Mindestkontrolle braucht man in beiden Ansaetzen?
A: Fuer planning Minimum: Plan-Validierung, replanning-Limits, Abschlusskriterien (criteria of done), policy checks pro Phase, Abweichungs-Audit. Fuer reactive Minimum: budgets, stop conditions, policy checks pro Schritt, State-Memory, idempotency und Tracing.

Verwandte Vergleiche

Wenn du Architektur fuer ein Agent-System waehlst, helfen auch diese Seiten:

• LLM Agents vs Workflows - wann ein Agent-Loop noetig ist und wann workflow reicht.
• Single-Agent vs Multi-Agent - ein Entscheidungs-Loop versus Koordination mehrerer Agenten.
• OpenAI Agents vs LangGraph - gemanagter runtime versus explizite Graph-Uebergangskontrolle.
• LangChain vs LangGraph - Komponenten versus formalisierter Zustandsgraph.
• RAG vs Agents - knowledge pipeline versus decision loop.