Agenci — kiedy LLM dostaje ręce i pamięć

Złota reguła: Najpierw workflow, agent dopiero gdy inaczej się nie da. Autonomia to nie feature; to koszt w tokenach, latency i nieprzewidywalności. Kupuj ją tylko do zadań wymagających eksploracji: nieznane dane, nieznane środowisko, nieznana liczba kroków.

Co to jest

Agent = LLM w pętli z narzędziami (search, shell, API) i jakąś formą pamięci. Cykl jest tępy:

while not done:
    zdecyduj(następną akcję) → wywołaj tool → przeczytaj wynik → zaktualizuj plan

I tyle. Reszta to wariacje. Czym to nie jest: nie świadomość, nie AGI, nie jeden wielki prompt. Stan, plan i pamięć żyją poza LLM, w aplikacji. Model tylko wybiera następną akcję.

Agent vs workflow — decyzja, która ma znaczenie

Workflow ma kroki z góry; LLM wypełnia luki (klasyka „summarize → translate → send”). Agent sam wybiera kolejny krok ze stanu. Workflow jest tańszy, bezpieczniejszy i łatwiejszy w debugu. Agent unosi zadania, których ścieżki nie znasz z góry. Większość produkcyjnych „agentów” to workflow z jednym krokiem agentowym — i tak ma być.

Closed-loop: bez weryfikacji autonomia to drogi random walk

One-shot (model pisze, człowiek domyka) daje krótkie poczucie szybkości i źle się skaluje. Closed-loop znaczy: po akcji agent odpala check — test, lint, SQL assert, screenshot, CI — i idzie dalej albo naprawia, idealnie bez człowieka w każdym kroku.

Weryfikacja to nie gate doklejony na końcu. To zmysł „done” pętli. Bez maszynowo sprawdzalnego końca agent nie wie, kiedy przestać, a ty nie wiesz, kiedy wolno dać więcej autonomii. U coding agentów to testy i CI przed flotą background jobów. U business agentów — asercje: rekord istnieje, mail jest draftem do akceptacji, kwota się zgadza.

Szybkość agentów nie stoi naprzeciw jakości. Szybkość jest zakodowaną jakością: evale, skills, pliki instrukcji, wąskie tools, logi. Czego nie uruchomisz automatycznie, tego nie przeskalujesz.

Buduj agenta krok po kroku

1. Spróbuj bez agenta. Jeden dobry prompt. Potem stały workflow. Dopiero potem pętla. Każdy stopień w dół jest o rząd wielkości tańszy w runie i debugu.

2. Zdefiniuj „done” maszynowo. Testy przeszły, rekord znaleziony, plik istnieje. Pętla bez stop condition to generator kosztów. To rdzeń closed-loop.

3. Zacznij od 3–5 tools. Mniej narzędzi = lepsze wybory. Opisy tools pisz jak docs dla nowego kolegi: co robi, kiedy użyć, co zwraca. Złe opisy to cicha przyczyna głupich agentów.

4. Ustaw limity. Max kroków, budżet tokenów, timeout. Zapętlony agent ma failować głośno, nie spalać budżetu. Loguj każdą akcję — inaczej nie dowiesz się dlaczego zrobił to, co zrobił.

5. Human-in-the-loop przy nieodwracalnych akcjach. Delete, płatność, deploy, dane na zewnątrz — człowiek potwierdza. Autonomię rozszerzaj na podstawie logów i success rate, nie hype’u z dema.

6. Warstwuj pamięć świadomie. Working memory (bieżące okno), episodic (poprzednie biegi: log + streszczenie), semantic (fakty domeny: structured store + lookup). Jednej magicznej warstwy pamięci nie ma. To marketing.

7. Mierz success rate i liczbę akcji na zadanie. Jeśli nie znasz średniej liczby kroków i success rate, zgadujesz, nie operujesz. Eval set ze znanym wynikiem jest u agentów tak samo krytyczny jak u RAG. Śledź też koszt i udział biegów z interwencją człowieka.

Słowniczek

• Tool use — format „wywołaj X z argumentami Y”. U dużych providerów problem rozwiązany.
• MCP (Model Context Protocol) — standard udostępniania tools i zasobów jak pluginów.
• ReAct — oryginalny paper „rozumuj i działaj”; dziś historyczna nazwa pętli agenta.
• Closed-loop — agent + automatyczna weryfikacja w pętli, nie one-shot i ludzki last mile przy każdym kroku.

Częste błędy

• Agent na zadanie workflow → zejdź poziom niżej.
• Brak limitów pętli → max kroków + budżet + timeout, fail głośno.
• Za dużo tools → poniżej 10, najlepiej 3–5; routuj albo dziel na specjalistów.
• Brak człowieka przy nieodwracalnych akcjach → approval; autonomia się zarabia.
• Stan upchany w prompcie → plan i wyniki pośrednie trzymaj w aplikacji; do kontekstu tylko to, czego potrzebuje następny krok.
• Ocena po demie → demo to wyselekcjonowany sukces; decyduj po success rate na eval set.
• Autonomia bez weryfikacji → najpierw sygnał pass/fail, potem background i automerge.

Kiedy tego nie używać

Gdy da się rozpisać stałe kroki — wygrywa workflow. Gdy zadanie jest jednorazowe i taniej ręcznie. Gdy nie umiesz weryfikować wyników: agent bez weryfikacji to drogi random walk po twoim systemie.

Źródła

• Building effective agents (Anthropic)
• 12-Factor Agents
• Claude Code: Best practices for agentic coding (Anthropic)
• AI Engineering (Chip Huyen)
• METR

Co zapamiętać

Agent to tępa pętla wokół mądrego modelu. Większość problemów, które ludzie zwalają na model (pętle, zgubiony kontekst, złe wybory), to bugi pętli. Buduj od najprostszego: prompt → workflow → agent. Zdefiniuj done maszynowo, ogranicz tools i kroki, loguj wszystko, dawkuje autonomię według danych. Bez weryfikacji nie kupujesz agenta. Kupujesz generator akcji.