TAO Loop
Jak działa
W każdej iteracji agenta model generuje strukturalny krok złożony z trzech sekcji. (1) Thought: krótka notatka rozumowania w języku naturalnym o tym, co model wie i co zamierza zrobić dalej. (2) Action: wywołanie narzędzia w ustalonym formacie (JSON, function call, lub specjalny token typu „Action: search[query]"). (3) Observation: wynik wykonania akcji (zwrot z API, fragment dokumentu, błąd) wstrzyknięty do kontekstu jako osobna wiadomość albo blok tekstu. Model widzi pełną historię (T,A,O,T,A,O,...) w kolejnej turze i albo emituje kolejny krok TAO, albo wystawia "Final Answer". Pętla jest ograniczona przez max_iterations, budżet tokenów i regułę zatrzymania po Final Answer.
Rozwiązany problem
Czysty LLM, nawet z function callingiem, łatwo „przeskakuje" wprost do akcji, traci wątek lub halucynuje wynik narzędzia bez czekania na rzeczywistą odpowiedź. TAO wymusza trójfazową dyscyplinę: rozumuj, działaj, obserwuj — eliminując zlewanie się rozumowania z wykonaniem, ułatwiając debugging i pozwalając na multi-step problem solving z narzędziami.
Implementacja
Model emituje od razu Action i fałszywą Observation w jednej turze, zanim narzędzie naprawdę zwróci wynik. Mitigacja: parsuj odpowiedź, ucinaj po Action, przerywaj generowanie na stop-tokenie i wymuszaj rolę "tool" jako jedyne źródło Observation.
Agent powtarza tę samą Action z drobnymi wariantami i nie zbliża się do celu. Mitigacja: deduplikacja akcji, twardy limit max_iterations, watchdog wykrywający brak nowych obserwacji, opcjonalna faza Reflexion.
Wynik narzędzia (cała strona, wynik SQL z setkami rekordów) zapełnia okno kontekstu w 2–3 iteracjach. Mitigacja: truncate Observation, streszczanie, retrieval-on-result, paginacja.
Model wpisuje wnioski końcowe do pola Thought zamiast wyemitować "Final Answer", przez co aplikacja nigdy nie kończy pętli. Mitigacja: jasne reguły w prompt systemowym, przykłady few-shot z poprawnym Final Answer, parser wymuszający format.
Treść zwrócona z narzędzia (strona, e-mail, wynik SQL) zawiera instrukcje próbujące przejąć agenta — typowy wektor ataku w pętli TAO. Mitigacja: izolacja Observation, oznaczanie jej jako nieufnej, polityki uprawnień narzędzi.
Ewolucja
Yao i in. (Princeton + Google) formalizują przeplatanie kroków rozumowania (Thought) i działania (Action) z obserwacjami zwrotnymi z narzędzi i otoczenia (Observation) — fundament wszystkich późniejszych pętli agentowych.
LangChain wprowadza ReAct Agent i Agent Executor, czyniąc pętlę "Thought / Action / Action Input / Observation" domyślnym wzorcem implementacyjnym dla agentów LLM w przemyśle.
Shinn i in. rozszerzają TAO o fazę refleksji nad poprzednimi obserwacjami, pokazując, że agenci uczą się skuteczniej, gdy między iteracjami przeprowadzają jawną krytykę.
OpenAI Function Calling (czerwiec 2023) i kolejni dostawcy zastępują free-text "Action:" strukturalnym wywołaniem JSON, a Observation staje się dedykowaną wiadomością roli "tool" — kanoniczna implementacja TAO przesuwa się z promptu do schematu API.
LangGraph (graf stanu z węzłami Thought/Action/Observation) oraz kurs Hugging Face Agents (rozdział "The Thought-Action-Observation Cycle") utrwalają TAO jako kanoniczny opis pętli agenta niezależnie od dostawcy.
Hiperparametry (konfigurowalne osie)
Maksymalna liczba pełnych pętli T-A-O zanim wymusimy Final Answer.
Jak długie i szczegółowe powinny być sekcje Thought — wpływa na koszt i jakość rozumowania.
Limit długości Observation (np. pierwsze N tokenów wyniku narzędzia) — chroni okno kontekstu.
Reguła zatrzymania pętli: emisja "Final Answer", brak nowej Action przez N kroków, osiągnięcie max_iterations, przekroczenie budżetu tokenów.
Paradygmat wykonania
Występują dwa konkurencyjne idiomy implementacji: (a) free-form ReAct-style "Thought:/Action:/Observation:" zaszyte w prompt, (b) strukturalny tool-use z osobnymi rolami "assistant" / "tool" w API czatu.
Model sam decyduje, kiedy zakończyć Thought i wyemitować Action, oraz kiedy po kilku iteracjach przejść do Final Answer. Routing jest implicit w przestrzeni tokenów wyjściowych, sterowany promptem systemowym i przykładami few-shot.
Równoległość
TAO jest z definicji sekwencyjne — Observation zależy od Action, kolejny Thought zależy od Observation. Równoległość wprowadzają dopiero rozszerzenia (parallel tool calls w ramach jednej Action, multi-agent fan-out na poziomie wyższym).
Wymagania sprzętowe
TAO jest wzorcem na poziomie orkiestracji agenta — działa wszędzie, gdzie działa LLM zdolny do tool-use, niezależnie od backendu sprzętowego.