- Agent to model językowy w pętli, który sam wybiera narzędzia i kroki, aż osiągnie cel lub utknie.
- Workflow ma ścieżkę zapisaną w kodzie, a agent decyduje w trakcie pracy.
- Zaczynaj od najprostszego rozwiązania; agent kosztuje czas i pieniądze, więc używaj go tam, gdzie potrzebna jest elastyczność.
Słowo „agent” bywa używane na tyle luźno, że warto je doprecyzować, zanim zacznę porównywać narzędzia. Anthropic w swoim opracowaniu o budowaniu skutecznych agentów zauważa, że niektórzy rozumieją przez to w pełni autonomiczne systemy pracujące długo i samodzielnie, a inni raczej systemy realizujące z góry ustalony przepis. Wszystko to nazywa systemami agentowymi, ale rysuje jedną ważną granicę, którą przeniosę na grunt kodowania.
Workflow kontra agent
Według tego opracowania workflow to układ, w którym model i narzędzia są prowadzone przez ścieżki kodu zapisane z góry. Agent to układ, w którym model sam kieruje własnym przebiegiem pracy i wyborem narzędzi, zachowując kontrolę nad tym, jak wykona zadanie. Różnica jest praktyczna: w workflow wiesz, jakie kroki nastąpią i w jakiej kolejności, bo napisał je człowiek. W agencie kroki wynikają z tego, co model zobaczy po drodze.
| Workflow | Agent | |
|---|---|---|
| Kto wybiera kroki | Autor kodu, z góry | Model, w trakcie pracy |
| Przewidywalność | Wysoka | Niższa |
| Elastyczność | Niska, do znanych zadań | Wysoka, do otwartych zadań |
| Koszt i opóźnienie | Zwykle mniejsze | Zwykle większe |
| Testowanie | Prostsze | Trudniejsze |
Autorzy zalecają szukanie najprostszego rozwiązania i dokładanie złożoności tylko wtedy, gdy jest potrzebna. Systemy agentowe zwykle wymieniają opóźnienie i koszt na lepsze wyniki zadań, więc trzeba się zastanowić, czy ta wymiana ma sens. Dla wielu zastosowań wystarcza pojedyncze, dobrze przygotowane wywołanie modelu z wyszukiwaniem i przykładami w kontekście.
Pętla, w której pracuje agent kodowania
Agent kodowania, taki jak Claude Code, to model uruchomiony w pętli z dostępem do narzędzi. Badanie ReAct opisało ideę, na której opiera się ten wzorzec: model generuje na przemian ślady rozumowania i działania, a rozumowanie pomaga mu ustalać plan i radzić sobie z wyjątkami, podczas gdy działania pozwalają zdobywać informacje ze świata zewnętrznego. W kodowaniu świat zewnętrzny to twój projekt.
- 01CelOpisujesz zadanie i kryterium sukcesu.
- 02MyślModel ustala następny krok.
- 03NarzędzieCzyta plik, szuka, edytuje albo uruchamia polecenie.
- 04WynikWidzi odpowiedź narzędzia: kod, błąd, wyjście testów.
- 05DecyzjaPoprawia, idzie dalej albo kończy.
- 06CzłowiekPrzegląda zmiany i zatwierdza.
Dobrze widać to na przykładzie błędu testu. Agent czyta komunikat, otwiera plik z funkcją, proponuje poprawkę, uruchamia test jeszcze raz i patrzy, czy przeszedł. Jeśli nie, wraca do kroku „myśl”. Taka pętla jest siłą, bo agent koryguje się na podstawie faktów, a nie zgaduje. Jest też źródłem ryzyka: każdy obrót to koszt, a model może utknąć w kółko albo pójść w złą stronę, jeśli cel był niejasny.
Z czego składa się agent
Opracowanie Anthropic wskazuje podstawowy element: model rozszerzony o wyszukiwanie, narzędzia i pamięć, który sam generuje zapytania, wybiera narzędzia i decyduje, co zachować. W praktyce kodowania oznacza to cztery składniki. Po pierwsze model, który rozumuje i pisze kod. Po drugie narzędzia: odczyt i edycja plików, wyszukiwanie, uruchamianie poleceń, czasem przeglądarka lub serwery MCP. Po trzecie kontekst: to, co model aktualnie „widzi”, ograniczone oknem kontekstu. Po czwarte pamięć projektu, na przykład plik z zasadami, który wczytuje się na starcie sesji. Dlatego dwa agenty na tym samym modelu mogą działać zupełnie inaczej: różni je zestaw narzędzi, sposób zarządzania kontekstem i uprawnienia.
Kiedy agent się opłaca
Zalecenie z opracowania brzmi: agent jest lepszy, gdy potrzebna jest elastyczność i decyzje podejmowane przez model na dużą skalę, a workflow, gdy zadanie jest dobrze zdefiniowane. Przy kodowaniu agent wygrywa w zadaniach otwartych: zbadaj, skąd bierze się błąd, dodaj funkcję w kilku plikach, zrefaktoryzuj moduł. Przegrywa tam, gdzie wystarczy sztywna sekwencja, na przykład codzienne formatowanie plików, które lepiej załatwi skrypt.
Dobra praktyka to trzy pytania przed użyciem agenta. Czy da się to zrobić prostszym narzędziem? Czy umiem opisać, jak wygląda dobry wynik? Czy potrafię sprawdzić wynik szybko? Jeśli na ostatnie pytanie odpowiedź brzmi „nie”, nawet najlepszy agent da ci problem zamiast pomocy. Pokrewnym tematem jest człowiek w pętli: ustalenie, które kroki agent robi sam, a które wymagają twojej zgody.
Typowe błędy w pracy z agentem
Pierwszy błąd to zbyt duże zadanie w jednym podejściu. Agent pracuje w ograniczonym kontekście, więc po wielu krokach zaczyna gubić wcześniejsze ustalenia. Lepiej dzielić pracę na etapy, które da się sprawdzić osobno. Drugi błąd to brak kryterium zakończenia: bez niego agent kończy, gdy uzna, że skończył, a nie wtedy, gdy zadanie jest wykonane. Trzeci to zbyt szerokie uprawnienia na starcie. Gdy agent może wszystko, każda pomyłka ma pełne skutki, więc zacznij od trybu, który pyta o zgodę, i rozluźniaj go tylko dla poleceń, które znasz. Czwarty to zaufanie do własnych deklaracji agenta: zdanie „wszystko działa” nie jest dowodem, dowodem jest uruchomiony przez ciebie test.
Warto też pamiętać o prostym podziale odpowiedzialności. Agent odpowiada za wykonanie, ty za cel i za ocenę. Jeśli zlecisz cel „popraw kod”, dostaniesz zmiany, które agent uzna za poprawę; jeśli zlecisz „sprawić, by test X przechodził bez zmiany jego treści”, dostaniesz coś, co możesz zweryfikować. Im konkretniejsze kryterium, tym mniej pętli i mniej poprawek.
Porównanie konkretnych narzędzi znajdziesz w artykule Claude Code, Codex CLI i Gemini CLI: czym się różnią.
Stan wiedzy: 20 października 2026. Pojęcia są stabilne, ale produkty i ich możliwości zmieniają się szybko, więc szczegóły sprawdzaj w dokumentacji.

