Chain-of-Thought für Agenten: Wann hilft es, wann nicht?

Chain-of-Thought (CoT) ist eine Prompting-Technik, bei der ein Large Language Model seine Zwischenschritte explizit in Worten ausformuliert, bevor es antwortet. Statt direkt ein Ergebnis auszugeben, schreibt das Modell den Lösungsweg Schritt für Schritt nieder. Das steigert die Genauigkeit bei mehrstufiger Logik, Mathematik und Planung – kostet aber zusätzliche Tokens und Latenz. Für Agenten ist CoT zugleich der konzeptionelle Kern, aus dem nahezu alle modernen Agent-Architekturen abgeleitet sind.

• Hilft bei: mehrstufiger Logik, Mathematik, Planung und überall dort, wo ein nachvollziehbarer Denkpfad das Ergebnis verbessert.
• Hilft nicht bei: einfachen Lookups, Single-Step-Klassifikation sowie latenz- und kostenkritischen Anwendungen.
• Teils redundant bei: Reasoning-optimierten Modellen, die das schrittweise Denken bereits intern ausführen.

Was Chain-of-Thought technisch macht

CoT zwingt das Modell, den impliziten Sprung von der Frage zur Antwort in eine sichtbare Kette von Zwischenüberlegungen zu zerlegen. Der praktische Hebel ist klein, der Effekt oft groß: Ein vorangestellter Auslöser oder ein Beispiel-Lösungsweg verschiebt die Wahrscheinlichkeitsverteilung des Modells in Richtung strukturierter, schrittweiser Generierung.

Chain-of-Thought (Wei et al., 2022) ist die historische Wurzel praktisch aller heutigen Agent-Muster. Aus CoT sind ReAct, Tree-of-Thoughts, Plan-and-Solve/Plan-and-Execute und ReWOO hervorgegangen – sie alle bauen entweder auf dem expliziten Reasoning auf, strukturieren es um oder lehnen es bewusst ab. Wer CoT versteht, versteht damit das gemeinsame Fundament dieser Architekturen.

Die entscheidende Eigenschaft – und zugleich die zentrale Schwäche – von reinem CoT: Der Denkpfad ist strikt linksläufig. Das Modell generiert einen Schritt nach dem anderen und kann nicht zurückspringen oder eine eingeschlagene Sackgasse revidieren. Bei Aufgaben, die Suche, Lookahead oder Backtracking erfordern, bricht CoT deshalb ein. Genau hier setzt Tree-of-Thoughts an, das Reasoning als Suche über einen Baum von Zwischenzuständen umdeutet.

Zero-shot vs. few-shot CoT

In der Praxis gibt es zwei Varianten, die unterschiedliche Kosten-Nutzen-Profile haben.

• Zero-shot CoT: Der Aufgabe wird lediglich ein Auslöser wie „Lass uns Schritt für Schritt denken" vorangestellt. Keine Beispiele, minimaler Kontextaufwand. Aus dieser Idee ist das Plan-and-Solve-Prompting (Wang et al., 2023) entstanden – ein zweistufiger Zero-shot-Ansatz („Lass uns zuerst einen Plan entwerfen / Lass uns den Plan ausführen"), der Zero-shot-CoT bei mathematischem Reasoning übertrifft und zur Vorlage für die Plan-and-Execute-Agentenarchitektur wurde.
• Few-shot CoT: Im Prompt stehen ein bis mehrere vollständige Beispiel-Lösungswege. Das verankert nicht nur das schrittweise Denken, sondern auch ein gewünschtes Format und domänenspezifische Heuristiken. Few-shot CoT ist bei spezialisierten oder formatkritischen Aufgaben in der Regel präziser, kostet aber spürbar mehr Kontext-Tokens pro Anfrage.

Faustregel für Agenturen: Zero-shot CoT als kostengünstiger Standard, few-shot CoT nur dort, wo die zusätzliche Genauigkeit oder Formattreue den höheren Token-Verbrauch rechtfertigt.

Verhältnis zu ReAct: Reasoning braucht Erdung

Reines CoT hat ein grundsätzliches Problem für Agenten: Es halluziniert Fakten, weil ihm jede externe Erdung fehlt. Das Modell „denkt" zwar plausibel, hat aber keinen Mechanismus, um seine Annahmen gegen die Realität zu prüfen.

ReAct (Yao et al., 2022) löst genau das, indem es CoT um Handeln erweitert. Statt nur zu denken, verschränkt ReAct Reasoning-Schritte mit Tool-Aufrufen:

```
Thought: Ich muss den aktuellen Umsatz des Kunden nachschlagen.
Action: crm_lookup(kunde="Muster GmbH", feld="umsatz_q1")
Observation: Umsatz Q1 = 1.240.000 EUR
Thought: Das liegt 8 % über Vorjahr. Jetzt vergleiche ich mit der Pipeline.
Action: ...
```

Die Reasoning-Schritte steuern den Tool-Einsatz; die Tool-Beobachtungen korrigieren das Reasoning. CoT bleibt also der Kern – ReAct fügt nur die Erdung hinzu, die reinem CoT fehlt. Für die meisten produktiven Agenten (Chatbots mit CRM- und Wissensdatenbank-Zugriff, Ticket-Triage) ist diese geerdete Variante der richtige Startpunkt, nicht reines CoT.

Wann CoT hilft – und wann nicht

Die wichtigste Erkenntnis aus Feldberichten 2024–2026 lautet: Mit dem einfachsten Muster starten, das funktioniert, und erst dann eskalieren, wenn gemessene Fehlerquoten es erzwingen. Übertragen auf CoT heißt das: nicht reflexartig jeden Prompt mit „Schritt für Schritt"-Anweisungen aufblähen, sondern nur dort, wo der Aufgabentyp es belegbar verlangt.

Beispiel mit und ohne CoT: das Game of 24

Das „Game of 24" (aus vier Zahlen mit Grundrechenarten die 24 bilden) zeigt die Grenze von reinem CoT besonders deutlich. Unter GPT-4-Bedingungen erreicht reines CoT hier nur 4 % Erfolgsquote, weil das Modell sich früh auf einen Pfad festlegt und nicht zurückspringen kann. Tree-of-Thoughts, das mehrere Kandidaten pro Schritt erzeugt, bewertet und verzweigt, kommt auf 74 % (b=5, BFS über drei Denkschritte).

Ähnlich bei Mini-Crosswords (5×5): Auf Spielebene löst reines CoT nur 1 % der Aufgaben, Tree-of-Thoughts 20 %. Bei kreativem Schreiben mit Vorgaben liegt die Kohärenz-Bewertung von CoT bei rund 6,2 von 10, Tree-of-Thoughts bei rund 7,6.

Die Lehre ist nicht „CoT ist schlecht", sondern: CoT passt zu linearen Denkaufgaben, nicht zu Suchproblemen. Bei einer mehrstufigen Rechen- oder Planungsaufgabe verbessert CoT das Ergebnis spürbar; bei einem Suchproblem mit vielen Sackgassen braucht es eine Baumstruktur, bei einem reinen Lookup gar kein Reasoning.

Hinweis: Diese Zahlen stammen aus den Originalpapieren (überwiegend GPT-3.5/GPT-4-Ära, 2022–2023). Moderne Frontier-Modelle setzen diese Werte neu – die Größenordnungen sind als relative Effektindikatoren zu lesen, nicht als heutige Absolutwerte.

CoT und Kosten: die Latenz-/Token-Rechnung

Jeder Reasoning-Schritt erzeugt zusätzliche Tokens und – weil die Generierung sequenziell ist – zusätzliche Latenz. Bei einem einfachen Lookup, den das Modell direkt beantworten könnte, ist das reiner Overhead. Bei Hochvolumen-Anwendungen (z. B. Support-Ticket-Triage) summiert sich dieser Overhead schnell zu spürbaren Kosten.

Ein praktischer Kostenhebel ist das Model-Tiering: ein starkes, teures Modell für die anspruchsvolle Reasoning-/Planungsphase, ein kleineres, günstiges Modell für die einfachen Ausführungsschritte. Dieser Ansatz – aus dem Plan-and-Execute-Muster bekannt – spart auf mehrstufigen Workflows in der Größenordnung 40–70 % der Tokens. Für CoT bedeutet das: Reasoning gezielt dort einkaufen, wo es zählt, und nicht über alle Schritte gleich verteilen.

Wichtig für die Modellwahl 2026: Reasoning-optimierte Modelle (o-Serie, Claude mit Extended Thinking, Gemini-Thinking-Varianten) führen den schrittweisen Denkprozess bereits intern aus. Explizites CoT-Prompting bringt dort oft wenig zusätzlichen Nutzen und kann sogar stören. Explizites CoT bleibt vor allem relevant für kleinere/günstigere Modelle, für nachvollziehbare Audit-Trails und in regulierten DACH-Kontexten, wo der Denkpfad dokumentiert werden muss.

Für Agenturen und B2B: die pragmatische Entscheidung

Für DACH-Marketing-Agenturen und B2B-Teams lässt sich CoT auf eine einfache Heuristik verdichten: CoT ist kein Standard-Aufschlag, sondern ein gezieltes Werkzeug. Setzen Sie es ein, wenn die Aufgabe mehrere Denkschritte, Rechnen oder Planung verlangt – etwa bei der Aufbereitung von Reports, der Plausibilisierung von Kennzahlen oder der Zerlegung komplexer Kundenanfragen. Verzichten Sie darauf bei Lookups, Klassifikation und allem, wo Geschwindigkeit und Stückkosten dominieren. Wählen Sie zwischen Zero-shot (günstig) und few-shot (präziser, teurer) bewusst nach Aufgabe. Und prüfen Sie bei Reasoning-Modellen, ob explizites CoT überhaupt noch etwas beiträgt, bevor Sie Tokens dafür ausgeben. Wer diese vier Entscheidungen sauber trifft, erhält genauere Agenten zu kontrollierten Kosten – statt teuren, langsamen Reasoning-Overhead über die ganze Pipeline zu streuen.