Wie unterscheidet sich dies von einem reaktiven Agenten im ReAct-Stil?

Ein reaktiver Agent entscheidet jeweils eine Aktion auf Basis des aktuellen Zustands, ohne einen Plan als Artefakt zu haben. Goal Decomposition legt im Voraus einen geordneten Plan fest, wodurch die beabsichtigten Schritte überprüfbar und die Abhängigkeiten explizit werden. In der Praxis werden beide Ansätze oft kombiniert: Zuerst wird geplant, dann wird innerhalb jedes Schritts reaktiv ausgeführt und bei einem Fehlschlag neu geplant.

Was passiert, wenn ein Schritt mitten im Plan fehlschlägt?

Übergeben Sie die Kontrolle wieder an den Planer, um ausgehend vom aktuellen Zustand neu zu planen, anstatt blind fortzufahren. Der geschlossene Regelkreis der Neuplanung macht die Dekomposition robust. Begrenzen Sie diesen durch ein Budget, damit ein dauerhaft fehlschlagender Schritt keine endlosen Umschreibungen ohne Fortschritt auslöst.

Wann schadet die Planung mehr, als sie nützt?

Bei einfachen, einstufigen Zielen, bei denen die nächste Aktion offensichtlich ist, oder in Umgebungen, die sich schneller ändern, als ein Plan gültig bleibt. Dort führt eine Vorabplanung zu zusätzlicher Latenz und dem Risiko veralteter Pläne. Erkennen Sie triviale Ziele und lassen Sie diese den Planer umgehen, während Sie die Dekomposition für echte mehrstufige, voneinander abhängige Aufgaben reservieren.

OrchestrierungAktualisiert 2026-06-21 · Version 1.0

Goal Decomposition

Bei der Goal Decomposition zerlegt ein Agent ein übergeordnetes Ziel vor dem Handeln in eine geordnete Reihe kleinerer, handhabbarer Teilaufgaben – einen Plan –, führt diesen Plan aus, überwacht ihn und plant neu, wenn Schritte fehlschlagen. Der explizite Plan wird zu einem überprüfbaren Artefakt, das Sie reviewen, steuern und debuggen können. Nutzen Sie dieses Pattern, wenn ein Ziel mehrere voneinander abhängige Schritte erfordert und reaktive, schrittweise agierende Agenten abweichen oder ins Stocken geraten; überspringen Sie es bei einfachen Single-Shot-Aufgaben.

Evidenz: BranchenbeobachtungKonfidenz: HochQuelle: BranchenbeobachtungQuelle: Paper

Maschinenlesbar: JSON

Problem

Ein einzelner LLM-Aufruf, dem ein umfassendes, mehrstufiges Ziel übergeben wird, neigt zum Improvisieren. Reaktive Agenten, die jeweils nur eine Aktion auswählen, können bei langen Zeithorizonten den Faden verlieren: Sie wiederholen Arbeitsschritte, überspringen Voraussetzungen oder laufen in eine Sackgasse, ohne zu merken, dass das Gesamtziel mittlerweile unerreichbar ist. Da kein Plan als Artefakt existiert, können Sie die beabsichtigten Schritte vor ihrer Ausführung nicht überprüfen, nicht feststellen, ob ein Fehler auf eine schlechte Strategie oder eine fehlerhafte Ausführung zurückzuführen ist, und nach einer Unterbrechung nicht einfach fortfahren. Die Argumentation des Agenten ist implizit, flüchtig und schwer zu auditieren.

Wann zu verwenden

Dieses Pattern eignet sich für Ziele, die sich in mehrere voneinander abhängige Schritte mit einer sinnvollen Reihenfolge zerlegen lassen – z. B. erst recherchieren, dann synthetisieren; erst migrieren, dann verifizieren; erst erfassen, dann abgleichen, dann berichten. Es setzt voraus, dass das Modell aus dem Ziel und den verfügbaren Tools einen vernünftigen Plan erstellen kann und dass die Schritte ausreichend beobachtbar sind, um Fehler zu erkennen. Es ist besonders wertvoll, wenn Schritte kostspielig sind, Nebenwirkungen haben oder schwer rückgängig zu machen sind, sodass sich eine Überprüfung des Plans vor der Ausführung auszahlt. Es ist ungeeignet, wenn die nächste Aktion aus dem aktuellen Zustand offensichtlich ist oder wenn sich die Umgebung so schnell ändert, dass jeder im Voraus erstellte Plan bereits vor dem zweiten Schritt veraltet ist.

Lösung

Teilen Sie den Agenten in eine Planungsphase und eine Ausführungsphase auf. Der Planer liest das Ziel, die verfügbaren Tools sowie den aktuellen Zustand und gibt einen expliziten, geordneten Plan aus: eine Liste (oder einen Graphen) von Teilaufgaben mit ihren Abhängigkeiten und erwarteten Ergebnissen. Den Plan als First-Class-Artefakt zu behandeln, ist die Kernidee – er kann protokolliert, einem Menschen zur Genehmigung vorgelegt, mit Richtlinien abgeglichen und über verschiedene Durchläufe hinweg verglichen (diffed) werden. Codieren Sie Abhängigkeiten explizit, sodass unabhängige Teilaufgaben parallel ausgeführt werden können und abhängige auf ihre Eingaben warten, anstatt eine fragile lineare Sequenz zu erzwingen, die das Modell erfunden hat.

Ein Executor führt den Plan anschließend Schritt für Schritt aus, leitet das Ergebnis jedes Schritts weiter und gleicht es mit der erwarteten Ausgabe des Schritts ab. Wenn ein Schritt fehlschlägt, ein unbrauchbares Ergebnis liefert oder eine nachgelagerte Annahme entkräftet, übergeben Sie die Kontrolle wieder an den Planer, um ausgehend vom aktuellen Zustand neu zu planen, anstatt blind fortzufahren – dieser geschlossene Regelkreis unterscheidet eine robuste Dekomposition von einer einmaligen Planung (One-Shot Planning). Halten Sie Pläne so flach, wie es das Ziel erlaubt: Bevorzugen Sie wenige, gut gewählte Schritte gegenüber einem tiefen Baum, begrenzen Sie die Neuplanung durch ein Budget, damit der Agent nicht in Endlosschleifen gerät, und lassen Sie triviale Ziele die Planung komplett umgehen.

Komponenten

Planer, der einen geordneten, abhängigkeitsbewussten Plan ausgibtPlandarstellung (Aufgabenliste oder Aufgabengraph) als überprüfbares ArtefaktExecutor, der Schritte ausführt und Ergebnisse weiterleitetSchrittweise Verifizierung anhand der erwarteten AusgabenTrigger für Neuplanung und Schleife mit einem Schritt-/IterationsbudgetOptionaler Freigabeschritt durch einen Menschen vor der Ausführung

Vorteile

Ziele mit langem Zeithorizont bleiben kohärent, da die beabsichtigten Schritte im Voraus festgelegt und nicht einzeln improvisiert werden.
Der explizite Plan ist überprüfbar: Er kann gereviewt, genehmigt, auditiert und verglichen werden, bevor Nebenwirkungen auftreten.
Fehler lassen sich leichter lokalisieren – ein schlechter Plan lässt sich von einer fehlerhaften Ausführung eines Schritts unterscheiden.
Unabhängige Teilaufgaben ermöglichen Parallelisierung und erlauben es, die Arbeit nach einer Unterbrechung ab dem zuletzt abgeschlossenen Schritt wieder aufzunehmen.

Risiken

Eine fehlerhafte anfängliche Dekomposition pflanzt sich fort: Jeder nachfolgende Schritt übernimmt eine falsche Annahme oder eine fehlende Voraussetzung.
Übermäßige Planung (Over-Planning) erhöht die Latenz und die Kosten bei einfachen Zielen, die ein reaktiver Agent in einem einzigen Schritt erledigen würde.
Pläne veralten in sich schnell verändernden Umgebungen, sodass ein Schritt auf Basis eines veralteten Weltzustands ausgeführt wird.
Unbegrenzte Neuplanungsschleifen, in denen der Agent den Plan wiederholt umschreibt, ohne echten Fortschritt zu erzielen.

Wann nicht zu verwenden

Die nächste Aktion ist aus dem aktuellen Zustand offensichtlich und ein einzelner reaktiver Schritt löst das Ziel.
Die Umgebung ändert sich schneller, als ein Plan gültig bleibt, wodurch jede im Voraus geplante Sequenz veraltet.
Schritte sind kostengünstig, umkehrbar und unabhängig, sodass der Planungsaufwand den Nutzen übersteigt.

Technologien

Planner/executor frameworksLangGraphReAct / Plan-and-SolveTask graphs

Beispiele

Ein Forschungsassistent plant die Schritte Quellen-sammeln, Behauptungen-extrahieren, Gegenprüfung und anschließende Synthese, wobei die Quellensammlung parallel vor dem abhängigen Syntheseschritt ausgeführt wird.
Ein Code-Migrations-Agent plant die Schritte Verwendungen-inventarisieren, Dateien-transformieren, Tests-ausführen und plant den Transformationsschritt neu, wenn der Testschritt einen übersehenen Sonderfall aufdeckt.
Ein Datenabgleichs-Agent zerlegt das Ziel 'Bücher schließen' in Hauptbücher-abrufen, Normalisieren, Einträge-abgleichen und Ausnahmen-kennzeichnen, wobei der Abgleich erst nach erfolgreicher Normalisierung erfolgt.

KPIs

Zielerreichungsquote: Anteil der vollständig erreichten End-to-End-Ziele; ein gutes Ergebnis zeigt sich darin, dass die Dekomposition eine reaktive Baseline bei denselben mehrstufigen Aufgaben übertrifft.
Neuplanungshäufigkeit: Wie oft ein Durchlauf eine Neuplanung auslöst; ein gesunder Bereich bedeutet, dass die Schleife echte Fehler abfängt, ohne bei jedem Schritt ins Stocken zu geraten.
Schritte pro Ziel im Vergleich zum Minimum: Planlänge im Verhältnis zu einem sinnvollen Minimum; achten Sie auf Over-Planning, das die Anzahl der Schritte bei einfachen Zielen unnötig aufbläht.
Freigabequote für Pläne: Anteil der Pläne, die vor der Ausführung von Reviewern oder Richtlinienprüfungen akzeptiert werden; niedrige Quoten weisen auf eine systematisch schwache Dekomposition hin.

Beobachtete Fehlermuster

Fehlerhafte Dekomposition pflanzt sich fort: Eine falsche frühe Annahme beeinträchtigt jeden nachfolgenden abhängigen Schritt.
Neuplanungsschleife: Der Agent schreibt den Plan wiederholt um, ohne zu konvergieren oder Fortschritte zu erzielen.
Ausführung eines veralteten Plans: Ein Schritt wird auf Basis eines Weltzustands ausgeführt, der sich seit der Erstellung des Plans geändert hat.
Über-Dekomposition: Ein triviales Ziel wird in unnötige Schritte zerlegt, was Latenz, Kosten und die Fehleranfälligkeit erhöht.

Lessons Learned

Machen Sie den Plan zu einem echten Artefakt – protokollieren Sie ihn, zeigen Sie ihn an, vergleichen Sie ihn –, damit Fehler debuggbar und nicht rätselhaft sind.
Schließen Sie immer den Regelkreis: Erkennen Sie das Fehlschlagen von Schritten und planen Sie ausgehend vom aktuellen Zustand neu, anstatt blind fortzufahren.
Begrenzen Sie sowohl die Plantiefe als auch die Neuplanung durch explizite Budgets, um zu verhindern, dass einfache Ziele aus dem Ruder laufen.
Lassen Sie triviale Ziele den Planer umgehen; reservieren Sie die Dekomposition für wirklich mehrstufige, voneinander abhängige Aufgaben.

FAQs

Wie unterscheidet sich dies von einem reaktiven Agenten im ReAct-Stil?: Ein reaktiver Agent entscheidet jeweils eine Aktion auf Basis des aktuellen Zustands, ohne einen Plan als Artefakt zu haben. Goal Decomposition legt im Voraus einen geordneten Plan fest, wodurch die beabsichtigten Schritte überprüfbar und die Abhängigkeiten explizit werden. In der Praxis werden beide Ansätze oft kombiniert: Zuerst wird geplant, dann wird innerhalb jedes Schritts reaktiv ausgeführt und bei einem Fehlschlag neu geplant.
Was passiert, wenn ein Schritt mitten im Plan fehlschlägt?: Übergeben Sie die Kontrolle wieder an den Planer, um ausgehend vom aktuellen Zustand neu zu planen, anstatt blind fortzufahren. Der geschlossene Regelkreis der Neuplanung macht die Dekomposition robust. Begrenzen Sie diesen durch ein Budget, damit ein dauerhaft fehlschlagender Schritt keine endlosen Umschreibungen ohne Fortschritt auslöst.
Wann schadet die Planung mehr, als sie nützt?: Bei einfachen, einstufigen Zielen, bei denen die nächste Aktion offensichtlich ist, oder in Umgebungen, die sich schneller ändern, als ein Plan gültig bleibt. Dort führt eine Vorabplanung zu zusätzlicher Latenz und dem Risiko veralteter Pläne. Erkennen Sie triviale Ziele und lassen Sie diese den Planer umgehen, während Sie die Dekomposition für echte mehrstufige, voneinander abhängige Aufgaben reservieren.