2026-01-31 · Aktualisiert 2026-07-14

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

AI Agent Reasoning Schleifen im Jahr 2026: ReAct gegenüber ReWOO und Plan-and-Execute

Teil 1 der Serie „Engineering des Agentic-Stacks“

Ein Agent Reasoning Loop bestimmt, wie ein System plant, Tools aufruft, Ergebnisse liest und entscheidet, wann es abbrechen soll. Dieser Steuerfluss beeinflusst die Kosten sowie die Latency und Wiederherstellungsfähigkeit des Systems, falls ein Tool unerwartete Ausgaben liefert.

In diesem Beitrag werden die drei im Jahr 2026 zu kennenden AI Agent Loop-Muster verglichen: ReAct, ReWOO sowie Plan-and-Execute. Als laufendes Beispiel dient ein Market Analyst Agent, den ich in LangGraph entwickelt habe; der vollständige Quellcode ist auf GitHub verfügbar.

Dies ist die innere Schicht der Serie. In den späteren Komponenten werden der Zustand, von dem der Loop fortgesetzt wird, die verfügbaren Tools, die Richtlinien für diese Aufrufe, das Runtime, das einen Lauf am Laufen hält, sowie die Harness-Prüfungen eingefügt, die entscheiden, ob die Arbeit tatsächlich abgeschlossen ist.

TL;DR: ReAct ist flexibel, erfordert jedoch hohe Kosten. ReWOO arbeitet schnell, sofern die Workflow vorhersagbar sind, während das Verfahren „Plan-and-Execute“ für mehrstufige Analysen geeignet ist. Ein produktiver AI Agent kann pro Anfrage zwischen verschiedenen Reasoning-Schleifen wechseln, wobei gemeinsam genutzte Zustände sowie checkpointierte LangGraph-Node genutzt werden, damit jede Aufgabe die Schleife erhält, die zu ihrer Struktur passt.

Der Schleifenzyklus steuert die Kosten, Latency, sowie den Wiederherstellungsprozess

Ein nützlicher Agent erfordert mehr als nur einen guten Prompt. Sein Steuerungsgraph muss Reasoning, Werkzeuge sowie Speicher miteinander verbinden und gleichzeitig mit Fehlern umgehen können.

Der Reasoning Loop steuert den Zeitpunkt, zu dem der Model plant, ein Tool aufruft, das Ergebnis liest und anschließend stoppt. Eine ungeeignete Wahl führt zu unnötigen Model Aufrufen sowie zu Latency. Zudem kann dies dazu führen, dass der Agent nicht in der Lage ist, sich von einem unerwarteten Tool Result zu erholen.

Drei AI Agent Reasoning-Muster

ReAct: Denken, Handeln, Beobachten, Wiederholen

ReAct (Yao et al., 2022) stellt das ursprüngliche Muster für interaktive Agents dar. Dabei wird eine Schleife ausgeführt:

1. Gedanke: Der Agent erzeugt einen „Gedanken“, um das Ziel zu analysieren und den nächsten Schritt zu planen.
2. Aktion: Auf Basis dieses Gedankens ruft er ein Tool auf.
3. Beobachtung: Der Agent liest das Ergebnis ein, wodurch sein Verständnis für den nächsten Gedanken aktualisiert wird.

Vorteile:

• Grounding in tatsächlichen Beobachtungen verringert erfundene Fakten.
• Der Agent kann seine Strategie dynamisch anhand dessen ändern, was er gerade wahrgenommen hat.
• Die Historie der Tool-Aufrufe sowie der Beobachtungen liefert Ihnen eine konkrete Ausführungs Trace.

Nachteile:

• Die Historie wird schrittweise akkumuliert und erneut verarbeitet, wodurch Latency sowie die damit verbundenen Kosten mit der Länge der Schleife ansteigen.
• Es entsteht Verschwendung, wenn der Tool Calls im Voraus geplant werden könnte – genau diese Nische wird von ReWOO bedient.
• Ohne Stoppsbedingung oder Schrittzahlbegrenzung wird die Schleife unbegrenzt weiterlaufen.

Am besten geeignet für: explorative Aufgaben, Fehlerbehebung sowie Situationen, in denen man nicht vorhersagen kann, was als Nächstes geschieht.

ReWOO: Planen Sie alles im Voraus.

ReWOO (Reasoning Ohne Beobachtung) ist eine effizientere Variante von ReAct. Der Schlüssel liegt darin, Reasoning von der Ausführung der Tools zu entkoppeln: Anstatt bei jeder Aktion anzuhalten, um diese zu beobachten, plant ReWOO die gesamte Abfolge der Tool Calls in einem einzigen Durchlauf.

1. Plan: Ein einziger Aufruf von LLM schreibt den vollständigen Plan für Tool Calls, wobei variable Platzhalter verwendet werden.#E1, #E2) für Ausgaben, die noch nicht vorhanden sind.
2. Worker: Ein nicht-LLM Executor führt die geplanten Tools nacheinander oder parallel aus und füllt dabei die Platzhalter auf.
3. Solver: Eine abschließende LLM-Aufruf verarbeitet die gesammelten Beobachtungen und schreibt das Ergebnis aus.

Vorteile:

• Weniger wiederholte Aufrufe von Model im Vergleich zu ReAct, solange der ursprüngliche Plan weiterhin gültig ist.
• Ein niedrigererer Wert für Latency. Es ist nicht notwendig, den Historieverlauf bei jedem Schritt erneut einzusenden.
• Der Planner kann unabhängig voneinander feinjustiert werden, ohne dass eine Live-Umgebung erforderlich ist.

Nachteile:

• Brüchig, falls die Tools unerwartet fehlerhaft agieren. Der Plan setzt voraus, dass alles ordnungsgemäß funktioniert.
• Er benötigt vorhersehbare Workflows.
• Ohne explizite Fallback-Logik setzt ein fehlerhafter Plan seine Ausführung fort.

Am besten geeignet für: schnelle Snapshots-Ausführungen, Statusüberprüfungen sowie Dashboards. Für alle Anwendungen, bei denen sich die Tools zuverlässig verhalten.

Planen und Ausführen: ein Hybridansatz

Planen und Ausführen es befindet sich zwischen den beiden. Der Artikel skizziert eine einfache Aufteilung, die von den meisten modernen Agents übernommen wurde:

1. Planning-Phase: Zunächst erstellt der Agent einen Plan, der die Aufgabe in kleinere Unteraufgaben aufteilt.
2. Ausführungsphase: Anschließend führt der Agent diese Unteraufgaben aus.

Die ursprüngliche Veröffentlichung konzentrierte sich auf Zero-Shot-Prompting. Moderne Frameworks-Systeme wie LangGraph haben dieses Konzept zu einem vollständigen Orchestration-Muster weiterentwickelt, das sequenzielle Ausführung sowie eine schrittweise Model-Entscheidungsfindung beinhaltet – wobei die erste Variante eine leistungsstarke Reasoning Model-Lösung für Planning darstellt, während die zweite Variante kostengünstiger in der Umsetzung ist.

Vorteile:

• Hierarchische Reasoning Struktur, die dem Vorgehen eines menschlichen Experten bei der Aufteilung eines Projekts entspricht.
• Eine erneute Planning ist jederzeit möglich – man kann einen Schritt pausieren und neu bewerten, falls das Ergebnis unerwartet ist.
• Model Spezialisierung: Die Planner kann kostspielig sein, während die Executor günstig ausfallen kann.
• Begrenzte Komplexität, wobei nach jedem Schritt eine klare Checkpoint vorliegt.

Nachteile:

• Höherer Latency als bei ReWOO, da die Schritte sequenziell ausgeführt werden.
• Mehr Zustände müssen verwaltet werden.
• Überdimensioniert für Einmalkontakte.

Am besten geeignet für: komplexe mehrschrittige Analysen, Forschungsaufgaben sowie alle Anwendungen, bei denen am Ende eine Synthese erforderlich ist.

Auswahl nach potenziellen Versagenpunkten des Plans

Die Tabelle dient lediglich als Ausgangspunkt und nicht als Benchmark Ergebnis. Wenden Sie ReAct an, wenn jede Beobachtung die folgende Aktion verändern kann. Verwenden Sie den Ansatz „Planen und Ausführen“, wenn die Gesamtaufgabe in Teilaufgaben zerlegt werden kann, diese jedoch weiterhin Rückmeldungen benötigen. Nutzen Sie ReWOO, wenn Abhängigkeiten bereits vor der Ausführung bekannt sind und ein fehlerhafter Eingabewert die nachfolgenden Aufrufe blockieren kann. Messen Sie alle drei Ansätze in Ihrem eigenen Tool Latency, Model, dem Aufgabensatz sowie der Wiederholungsstrategie, bevor Sie ausschließlich aufgrund der Kosten eine Entscheidung treffen.

Ein Beispiel aus der Praxis: Der Marktanalyst Agent

Um dies konkret zu machen, habe ich ein Marktanalyst Agent ein Projekt, das bei einer Marktforschungsaufgabe alle drei Muster in derselben Codebasis verwendet.

Es verwendet LangGraph für Orchestration. Da alle drei Muster denselben Zustandsobjekt teilen, kann der Router pro Anfrage entscheiden, welches davon ausgeführt werden soll:

Zustandsdefinition

Der gemeinsame Zustand speichert alles, was der Agent in den verschiedenen Modi benötigt:

class PlanStep(BaseModel):
    """A single step in the research plan."""
    step_number: int
    description: str
    tool_hint: str | None = None
    completed: bool = False
    result: str | None = None

class UserProfile(BaseModel):
    """Structured user context loaded from long-term memory."""
    risk_tolerance: str | None = None
    investment_horizon: str | None = None

class AgentState(BaseModel):
    """Main state for the Market Analyst Agent graph."""

    # Identity and profile context for memory-backed personalization
    user_id: str
    user_profile: UserProfile = Field(default_factory=UserProfile)

    # Message history with LangGraph's add_messages reducer
    messages: Annotated[list, add_messages] = Field(default_factory=list)

    # Execution mode (set by router)
    execution_mode: ExecutionMode | None = None

    # Plan-and-Execute state
    plan: list[PlanStep] = Field(default_factory=list)
    current_step_index: int = 0

    # ReWOO state
    rewoo_plan: list[ReWOOPlanStep] = Field(default_factory=list)

    # Research results
    research_data: ResearchData | None = None

    # HITL output
    draft_report: DraftReport | None = None
    report_approved: bool = False

Muster 1: Implementierung nach dem Prinzip „Planen und Ausführen“

„Plan-and-Execute“ eignet sich hervorragend für Aufgaben, die eine mehrstufige Synthese erfordern. Der Schlüssel liegt darin, Planning und die eigentliche Ausführung voneinander zu trennen: Zunächst wird ein solider Model für die vorläufige Planung erstellt, anschließend wird eine ReAct-Schleife verwendet, um jede einzelne Stufe auszuführen – wobei dabei genügend Spielraum vorhanden ist, um react zu Tool Results.

Wie es zum Muster passt:

1. Eine einzige Vorabphase von Planning. Ein einziger Aufruf von LLM erzeugt den gesamten Plan als Liste von Schrittbeschreibungen.
2. Ausgabe unter Verwendung eines Schemas, das den Plan vor der Ausführung validiert.
3. Noch keine Ausführung von Tools. Der Planner entscheidet lediglich darüber, was zu tun ist, nicht jedoch wie.
4. Menschlich lesbare Schritte. Jeder Schritt besteht aus Text, den ein Executor interpretieren wird.

# System prompt guides the LLM to think like a research analyst
# creating a strategic plan, not immediate tool calls
PLANNER_SYSTEM_PROMPT = """You are a senior investment research analyst.
Break down stock analysis requests into 4-6 research steps covering:
1. Current price and basic metrics
2. Recent news and announcements
3. Competitor analysis (if relevant)
4. Financial health assessment
5. Risk factors
6. Investment thesis synthesis

Output as JSON with step_number, description, and tool_hint."""

# Schema-Guided Reasoning: Enforce structure with Pydantic
class PlanOutput(BaseModel):
    """Structured output for the planner."""

    steps: list[PlanStep] = Field(description="Research steps to execute")
    ticker: str = Field(description="The stock ticker being analyzed")

def planner_node(state: AgentState) -> dict:
    """Generate a research plan from the user's request.

    This is Phase 1 of Plan-and-Execute: creating the high-level strategy.
    """

    # Use a powerful model for strategic planning
    llm = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0)

    # Ask for a typed plan and validate it before execution.
    # The API can still fail, so production code also handles that exception.
    structured_llm = llm.with_structured_output(PlanOutput)

    # Context from long-term memory personalizes the plan
    profile_context = f"""
User Profile:
- Risk Tolerance: {state.user_profile.risk_tolerance}
- Investment Horizon: {state.user_profile.investment_horizon}
"""

    # Single LLM call creates the complete plan
    result: PlanOutput = structured_llm.invoke([
        SystemMessage(content=PLANNER_SYSTEM_PROMPT + profile_context),
        HumanMessage(content=f"Create a research plan for: {last_user_message}"),
    ])

    # State update: Store the plan and initialize tracking
    return {
        "plan": result.steps,           # The sequential steps to execute
        "current_step_index": 0,        # Start at step 0
        "research_data": ResearchData(ticker=result.ticker),  # Initialize data container
    }

Dieser llm.with_structured_output(PlanOutput) Die Zeile ist Schema-gesteuertes Reasoning (SGR), was ich bereits erläutert habe. ein früherer Beitrag. Durch das Schema kann die Anwendung einen fehlerhaften Plan bereits vor dem Einsatz der validierten Felder durch LangGraph zur Erstellung bedingter Kanten ablehnen.

Muster 2: Ausführung von ReAct

Sobald der Plan vorliegt, führt der Executor jeden Schritt als eigenständige ReAct Schleife aus. Dies ist Phase 2: Jeder Schritt ist klein genug, damit ein Thought-Action-Observation-Zyklus konzentriert bleibt, und der Agent kann react auf das reagieren, was das Tool zurückgibt.

Wie der ReAct-Teil abgestimmt ist:

1. Iterative Ausführung. Schritt für Schritt unter Berücksichtigung von Beobachtungsfeedback.
2. Der Thought-Action-Observation-Zyklus läuft im Inneren create_react_agent.
3. Die Ergebnisse des vorherigen Schritts werden als Kontext für den aktuellen Reasoning bereitgestellt.
4. Der Agent wählt die geeigneten Werkzeuge anhand der Beschreibung des jeweiligen Schritts aus.
5. Er kann seine Vorgehensweise während eines Schritts anpassen, je nachdem, welche Ausgabe ein Werkzeug liefert.

# Tools available for the ReAct agent to choose from
TOOLS = [
    get_stock_snapshot,
    get_price_history,
    search_news,
    search_competitors,
    get_financials,
]

def executor_node(state: AgentState) -> dict:
    """Execute the current step using a ReAct agent.

    This is Phase 2 of Plan-and-Execute: adaptive execution of each planned step.
    Each step runs as a mini ReAct loop until completion.
    """

    # Get the current step from the plan
    current_step = state.plan[state.current_step_index]

    # Build context from what we've learned so far
    # This matters: each step builds on previous observations
    previous_context = ""
    for step in state.plan[:state.current_step_index]:
        if step.result:
            previous_context += f"\nStep {step.step_number}: {step.result}\n"

    # Create a ReAct agent for this step
    # LangGraph's create_react_agent implements the full Thought-Action-Observation loop:
    # 1. Agent generates a "thought" about what tool to call
    # 2. Agent calls the tool ("action")
    # 3. Tool returns result ("observation")
    # 4. Agent decides: call another tool or finish
    react_agent = create_react_agent(
        model=ChatAnthropic(model="claude-sonnet-4-5-20250929"),
        tools=TOOLS,
    )

    # Invoke the ReAct loop for this single step
    # The agent will loop internally until it completes the step
    result = react_agent.invoke({
        "messages": [
            SystemMessage(content=EXECUTOR_SYSTEM_PROMPT),
            HumanMessage(content=f"""Execute Step {current_step.step_number}:
{current_step.description}

Ticker: {state.research_data.ticker}
Previous findings: {previous_context}"""),
        ]
    })

    # Extract the final answer from the ReAct agent's message history
    # The last message contains the synthesis after all tool calls
    updated_plan = list(state.plan)
    updated_plan[state.current_step_index] = PlanStep(
        step_number=current_step.step_number,
        description=current_step.description,
        completed=True,
        result=result["messages"][-1].content,  # Final observation
    )

    # State update: Mark step complete and advance to next
    return {
        "plan": updated_plan,
        "current_step_index": state.current_step_index + 1,
    }

Das ist der Kern des Planen-und-Ausführen-Flusses: Ein leistungsstarker Model erstellt den Plan, wobei anschließend ReAct jeden Schritt mit voller Anpassungsfähigkeit ausführt.

Muster 3: ReWOO für schnelle Snapshots-Implementierung

Zur schnellen Einweisung überspringt ReWOO die miteinander verknüpften Reasoning und führt die Tools parallel aus. Der Planner generiert im Voraus ein kompiliertes Skript aus Tool Calls, wodurch der Worker dieses ohne weitere Einmischung von LLM ausführen kann.

Die Form davon:

1. Drei Phasen (Planner → Worker → Solver), ohne Schleifen.
2. Referenz auf Tool Calls #E1, #E2 Platzhalter für Ergebnisse, die noch nicht vorhanden sind.
3. Während der Ausführung tritt kein LLM auf. Der Worker führt lediglich die Tools aus.
4. Die unabhängigen Tools laufen parallel.
5. Am Ende erfolgt eine einzige Syntheseveranlassung, bei der alle Daten gleichzeitig verarbeitet werden.

Phase 1: ReWOO Planner (erstellt im Voraus das vollständige Ausführungsgraphen)

class ReWOOPlanStep(BaseModel):
    """A step in the ReWOO plan with variable placeholders.

    Key difference from Plan-and-Execute's PlanStep:
    - Contains actual tool_name and tool_args (not just description)
    - Uses variable references (#E1) for dependencies
    """
    step_id: str  # e.g., "#E1" - becomes a variable
    description: str
    tool_name: str     # Exact tool to call
    tool_args: dict    # May contain variable refs like {"price": "#E1"}
    depends_on: list[str] = []  # For dependency ordering
    result: str | None = None

class ReWOOPlanOutput(BaseModel):
    """Structured output for ReWOO planner."""
    steps: list[ReWOOPlanStep] = Field(description="Planned tool calls with variables")

def rewoo_planner_node(state: AgentState) -> dict:
    """Generate a complete plan of tool calls upfront.

    This is the key difference from Plan-and-Execute: instead of creating
    human-readable step descriptions, we create EXACT tool calls that
    the worker will execute blindly.
    """

    llm = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0)

    # Schema-Guided Reasoning ensures valid tool call specifications
    structured_llm = llm.with_structured_output(ReWOOPlanOutput)

    ticker = state.research_data.ticker if state.research_data else "UNKNOWN"

    # Single LLM call to plan ALL tool executions
    result: ReWOOPlanOutput = structured_llm.invoke([
        SystemMessage(content=REWOO_PLANNER_PROMPT),
        HumanMessage(content=f"""Create a ReWOO plan for: {query}

Ticker: {ticker}

Output tool calls with:
- step_id: Variable name (#E1, #E2, etc.)
- description: What this accomplishes
- tool_name: Exact tool from the list
- tool_args: Dictionary of arguments
- depends_on: List of step_ids this depends on"""),
    ])

    # State update: Store the complete execution plan
    # Worker will execute this without any LLM involvement
    return {"rewoo_plan": result.steps}

Phase 2: ReWOO Worker (führt Tools aus, ohne LLM Reasoning)

def rewoo_worker_node(state: AgentState) -> dict:
    """Execute all planned tools in parallel (no LLM calls).

    This is the key efficiency: Worker is "dumb" - it just runs tools
    according to the plan. No LLM calls = massive token savings.
    """

    results = {}  # Store results keyed by step_id (e.g., "#E1": "$150.23")

    # Execute ALL independent steps in parallel using ThreadPoolExecutor
    # This is where ReWOO gets its speed advantage
    with ThreadPoolExecutor(max_workers=5) as executor:
        futures = {
            executor.submit(execute_tool, step): step
            for step in state.rewoo_plan
            if not step.depends_on  # Only independent tools for parallel batch
        }

        # Collect results as they complete
        for future in as_completed(futures):
            step = futures[future]
            results[step.step_id] = future.result()
            # No LLM reasoning here - just store the raw tool output

    # State update: Store results for the Solver phase
    return {"rewoo_plan": updated_steps}

Phase 3: ReWOO Solver (synthetisiert alle Ergebnisse in einem einzigen Aufruf von LLM)

def rewoo_solver_node(state: AgentState) -> dict:
    """Synthesize all tool results into a flash briefing.

    This is the second efficiency gain: Instead of interleaving
    LLM calls with tool execution (like ReAct), we make ONE
    final synthesis call with all gathered data.
    """

    # Build context from ALL tool results at once
    tool_results = []
    for step in state.rewoo_plan:
        if step.result:
            tool_results.append(f"### {step.description}\n{step.result}")

    context = "\n\n".join(tool_results)

    # Single LLM call to synthesize everything
    structured_llm = llm.with_structured_output(FlashBriefingOutput)
    result = structured_llm.invoke([
        SystemMessage(content=REWOO_SOLVER_PROMPT),
        HumanMessage(content=f"Create a flash briefing from this data:\n\n{context}"),
    ])

    return {"draft_report": result}

ReWOO plant jeden Tool Call im Voraus und speichert die Abhängigkeiten in Platzhaltern wie #E1 und #E2. Der Executor kann unabhängige Aufrufe parallel ausführen, ohne den Model fragen zu müssen, was als Nächstes zu tun ist. Ein letzter Model-Aufruf fügt die Ergebnisse zusammen, wodurch die Kosten für vorhersehbare Workflows-Operationen gering bleiben.

Wo jedes Muster auf den Model verweist

Die drei Muster unterscheiden sich darin, zu welchem Zeitpunkt und auf welche Weise sie den LLM aufrufen:

Der Unterschied zwischen ihnen besteht darin, was der Planner erzeugt. Dies bestimmt alles in den nachfolgenden Schritten.

1. Plan-and-Execute erzeugt menschenlesbare Beschreibungen der Schritte:

   # Planner output (list of PlanStep objects)
   plan = [
       PlanStep(
           step_number=1,
           description="Get current price and key financial metrics",
           tool_hint="get_stock_price"
       ),
       PlanStep(
           step_number=2,
           description="Search for recent news and earnings",
           tool_hint="search_news"
       ),
       # ... more steps
   ]

   Der Executor liest jede Beschreibung und entscheidet, welche Tools aufgerufen werden sollen. Er ist flexibel, erfordert jedoch für jeden Schritt einen Aufruf von LLM.

2. ReAct verfügt über keinen vordefinierten Plan. Stattdessen wird ein iterativer Reasoning angewandt:

   # No planning phase - ReAct works step-by-step with accumulated messages
   messages = [
       HumanMessage(content="Execute Step 1: Get current price"),
       AIMessage(content="I'll call get_stock_price"),
       ToolMessage(tool_call_id="1", content="$132.45"),
       AIMessage(content="Now I need metrics..."),
       # ... agent continues until step complete
   ]

   Mehrere Aufrufe von LLM pro Schritt passen sich den Beobachtungen an und sind in der Regel teurer als die beiden geplanten Modi.

3. ReWOO erzeugt explizite, ausführbare Tool Call-Spezifikationen:

   # Planner output (list of ReWOOPlanStep objects)
   rewoo_plan = [
       ReWOOPlanStep(
           step_id="#E1",
           tool_name="get_stock_price",
           tool_args={"ticker": "NVDA"}
       ),
       ReWOOPlanStep(
           step_id="#E2",
           tool_name="search_news",
           tool_args={"query": "NVDA earnings", "limit": 5}
       ),
       # ... all tool calls planned upfront
   ]

   Der Worker führt seine Aufgaben blind aus, ohne jegliche Beteiligung von LLM. Alle Aufrufe von Model finden innerhalb des Planner sowie des Lösers statt, wodurch die Anzahl der Model-Aufrufe vorhersehbar bleibt.

Speicherverwaltung und Zustandsfluss:

• Plan-and-Execute: Der Zustand durchläuft die Schritte plan → current_step_index → research_data.
• ReAct: Der Zustand sammelt sich im System an. messages Array (die vollständige Konversationshistorie). ReWOO: Der Zustand wechselt durch. rewoo_plan, zusammen mit result von dem Benutzer ausgefüllte Felder.

Alles zusammenfügen: Verkabelung des Graphen

So koexistieren die drei Muster innerhalb eines einzigen LangGraph-Systems. Sie teilen sich ein gemeinsames AgentState und leben in einem einzigen Graphen. Ein Router wählt für jede Anfrage den entsprechenden Pfad aus, wodurch es sich um einen Agent mit drei Ausführungsmodi handelt – und nicht um drei Agents, die getrennt voneinander arbeiten.

LangGraph behält die Verkabelung deklarativ bei:

def create_graph(checkpointer=None):
    builder = StateGraph(AgentState)

    # Add nodes
    builder.add_node("router", router_node)
    builder.add_node("planner", planner_node)
    builder.add_node("executor", executor_node)
    builder.add_node("reporter", reporter_node)
    builder.add_node("rewoo_planner", rewoo_planner_node)
    builder.add_node("rewoo_worker", rewoo_worker_node)
    builder.add_node("rewoo_solver", rewoo_solver_node)

    # Define edges
    builder.add_edge(START, "router")
    builder.add_conditional_edges("router", route_after_router, {
        "planner": "planner",
        "rewoo_planner": "rewoo_planner",
    })

    # Deep Research path
    builder.add_edge("planner", "executor")
    builder.add_conditional_edges("executor", route_after_executor, {
        "executor": "executor",  # Loop back for more steps
        "reporter": "reporter",  # Done with plan
    })
    builder.add_edge("reporter", END)

    # Flash Briefing path (ReWOO)
    builder.add_edge("rewoo_planner", "rewoo_worker")
    builder.add_edge("rewoo_worker", "rewoo_solver")
    builder.add_edge("rewoo_solver", END)

    return builder.compile(
        checkpointer=checkpointer,
        interrupt_before=["reporter"],  # HITL pause for approval
    )

Automatische Musterauswahl mithilfe eines Router

Um für jede Anfrage den richtigen Loop auszuwählen, habe ich einen Router-Klassifikator hinzugefügt. Dieser nutzt schema-gestützte Reasoning-Methoden, um eine zuverlässige Klassifizierung zu gewährleisten:

class ExecutionMode(str, Enum):
    """Execution mode for the agent."""

    DEEP_RESEARCH = "deep_research"  # Plan-and-Execute + ReAct (thorough)
    FLASH_BRIEFING = "flash_briefing"  # ReWOO (fast, token-efficient)

class RouterOutput(BaseModel):
    """Structured output for the router."""

    mode: ExecutionMode  # DEEP_RESEARCH or FLASH_BRIEFING
    ticker: str
    reasoning: str

ROUTER_SYSTEM_PROMPT = """Classify the user's request:

1. **deep_research**: Complex analysis requiring synthesis
   - Examples: "Analyze strategic risks", "investment thesis"

2. **flash_briefing**: Quick snapshots, simple data retrieval
   - Examples: "quick snapshot", "current price"

Default to deep_research if unclear."""

structured_llm = llm.with_structured_output(RouterOutput)

Da dies bereits implementiert ist, müssen die Benutzer keinen Modus auswählen. Der Router leitet den Begriff „aktueller Preis“ automatisch an ReWOO weiter und den Begriff „Investitionsstrategie“ an Plan-and-Execute.

Wichtige Erkenntnisse

1. ReAct bietet die häufigsten Rückmeldepunkte – allerdings zum Preis wiederholter Model-Aufrufe.
2. ReWOO verringert die Model-Wege, sofern die Tools zuverlässig sind und die Abhängigkeiten vorhersehbar.
3. Plan-and-Execute eignet sich für komplexe Analysen, die vor der Ausführung zerlegt werden können, aber dennoch Schritt-für-Schritt-Rückmeldungen erfordern.
4. Ein Router kann je nach Anfrage zwischen diesen Ansätzen wählen, sodass die Benutzer dies nicht selbst tun müssen.
5. Der Loop benötigt einen gespeicherten Zustand, um bei Unterbrechungen oder Neustarts des Workers weiterhin funktionstüchtig zu bleiben. Dies ist Gegenstand von Teil 2.

Die vollständige Implementierung, einschließlich des Router sowie des gemeinsamen Zustands, befindet sich im Marktanalysten-Repository Agent.

Die nächste Schicht ist das Speichersystem

Teil 2, AI Agent Memory Architektur im Jahr 2026, es trennt die wiederaufnahmefähigen Checkpoints von den cross-Session-Wissensinhalten sowie den Projektdokumenten. Ohne diese Zustandsschicht funktionieren die oben genannten Router und Executor nur dann, wenn ein Prozess sowie eine Context Window weiterhin aktiv sind.

Referenzen

• ReAct: Synergie zwischen Reasoning und Handeln in Sprache Models (Yao et al., 2022)
• ReWOO: Trennung von Reasoning von Beobachtungen zur effizienten Erweiterung sprachbasierter Models Systeme (Xu et al., 2023)
• Plan-and-Solve Prompting: Verbesserung von Zero-Shot Chain-of-Thought Reasoning durch große Sprachmodelle Models (Wang et al., 2023) Marktanalyse-Repository Agent

Der Marktanalyse-Code von Agent ist verfügbar GitHub Falls Sie gerne mitlesen möchten._

Reihe: Entwicklung der Agentic-Stack-Struktur

• Teil 1: AI Agent Reasoning Schleifen im Jahr 2026 (dieser Artikel) Teil 2: AI Agent Memory Architektur im Jahr 2026 — Checkpoints, Vector Stores sowie Dokumentenmemorie Teil 3: AI Agent Tool Use im Jahr 2026 — MCP, CLI, Fähigkeiten, Ausführung von Code sowie ACI Teil 4: AI Agent Sicherheit im Jahr 2026 — Guardrails, Berechtigungen, Sandboxes, HITL sowie die Begrenzung des MCP-Bereichs
• Teil 5: Langlaufende AI Agent Runtime im Jahr 2026 — Sessions, Sandboxes, Checkpoints, Steuermechanismen sowie Deployment-Formen
• Teil 6: Harness Engineering für AI Agents (folgt bald) — Akzeptanzprüfungen, Traces, Wiederholungsversuche, Übergaben sowie der Zyklus innerhalb des Model