Plan-and-Execute
Jak działa
1. Planer otrzymuje cel i ewentualny kontekst, po czym generuje uporządkowaną listę kroków (plan) — najczęściej w formacie strukturyzowanym (JSON / lista). 2. Executor pobiera pierwszy nieukończony krok i wykonuje go: typowo w pętli ReAct (thought → action → observation), z dostępem do narzędzi. 3. Wynik kroku jest dopisywany do stanu (scratchpad). 4. (Wariant z re-planowaniem) Planer ocenia, czy plan nadal jest aktualny w świetle obserwacji — jeśli nie, generuje nowy plan dla pozostałej części zadania. 5. Pętla trwa, aż plan jest wyczerpany lub planer zwróci sygnał ukończenia. Końcowa odpowiedź syntetyzowana jest na podstawie zebranych obserwacji.
Rozwiązany problem
Czysto reaktywne pętle agentowe typu ReAct mają tendencję do gubienia długoterminowego celu, mnożenia zbędnych wywołań narzędzi i przepalania tokenów silnego LLM na każdym pojedynczym kroku rozumowania. Plan-and-Execute wprowadza globalny kontekst (jawny plan) i pozwala odciążyć drogi model planowania od taniego modelu wykonującego rutynowe kroki.
Komponenty
Silny LLM, który na podstawie celu generuje uporządkowaną listę kroków. Często działa raz na początku i opcjonalnie ponownie przy re-planowaniu.
Oficjalna
Agent (zwykle pętla ReAct) wykonujący pojedynczy krok planu z dostępem do narzędzi. Może być oparty o tańszy / mniejszy model niż planer.
Oficjalna
Opcjonalny komponent oceniający aktualność planu po każdym kroku i generujący skorygowaną listę pozostałych kroków lub sygnał zakończenia.
Oficjalna
Zbiór narzędzi (wyszukiwarka, kalkulator, API, kod) dostępnych dla executora; planer może być świadomy tego zbioru przy konstrukcji planu.
Oficjalna
Pamięć robocza akumulująca cel, plan, wykonane kroki i ich obserwacje; współdzielona między planerem a executorem.
Implementacja
Planer generuje kroki, których executor nie jest w stanie wykonać (brak narzędzia, zła sygnatura). Powoduje pętle błędów i marnowanie tokenów.
Sztywne wykonanie planu po pojawieniu się sprzecznych obserwacji prowadzi do nonsensownych kroków końcowych.
Re-planowanie po każdym kroku w silnym modelu radykalnie zwiększa koszt — czasem przekraczając ReAct na pojedynczym modelu.
Bardzo drobne kroki dają plany o setkach pozycji (eksplozja stanu), bardzo grube — kroki, których executor nie potrafi wykonać atomowo.
Ewolucja
Yao et al. proponują przeplatanie rozumowania i działań — bezpośredni poprzednik koncepcyjny, w którym planowanie i wykonanie są zlane w jedną pętlę.
Yohei Nakajima publikuje minimalistyczny agent z osobnym task-creator i task-executor — pierwsza popularna implementacja Plan-and-Execute w open source.
Wang et al. formalizują rozdział na fazę planowania i wykonania w zero-shot CoT i pokazują przewagę nad „Let’s think step by step".
Harrison Chase wprowadza referencyjną implementację wzorca w LangChain — planer LLM + executor ReAct + opcjonalny re-planner.
Xu et al. proponują wariant, w którym planer generuje cały plan jako zmienne, a wykonanie narzędzi i synteza są oddzielone — drastyczna redukcja tokenów.
Kim et al. rozszerzają Plan-and-Execute o graf zależności między krokami i równoległe wykonanie niezależnych wywołań narzędzi.
Hiperparametry (konfigurowalne osie)
Model używany do generowania planu. Zwykle silny model rozumujący (np. GPT-4 / Claude Opus / o1).
Model wykonujący pojedyncze kroki. Często tańszy/szybszy niż planer.
Kiedy uruchamiać re-planowanie: nigdy / po każdym kroku / tylko po porażce / przy zmianie scope’u.
Twardy limit liczby kroków planu / iteracji executora; bezpiecznik przed pętlami.
Zbiór narzędzi udostępnionych executorowi; wpływa na to, co planer w ogóle może zaplanować.
Paradygmat wykonania
Dwa odrębne etapy (planowanie, wykonanie) o różnych charakterystykach obliczeniowych — często realizowane na różnych modelach.
Planer kieruje przepływem przez wybór kolejnych kroków i ich przypisanie do narzędzi w executorze; w wariancie z re-planowaniem może zmienić trasę po obserwacji.
Równoległość
Kroki planu wykonywane są zwykle sekwencyjnie (krok n+1 zależy od obserwacji z kroku n). Warianty takie jak LLMCompiler wykrywają niezależne kroki i wykonują je równolegle.
Wymagania sprzętowe
Wzorzec orkiestracyjny — działa na dowolnej infrastrukturze obsługującej wybrane LLM-y.