Model, czat czy agent? Jak wybrać narzędzie do zadania analitycznego

W ostatnim roku słowo „agent” zrobiło karierę, której pozazdrościłby mu niejeden influencer. Agent do maili, agent do faktur, agent do planowania urlopu, agent, który pomaga wybrać agenta. Czasem za tą nazwą stoi system, który samodzielnie wykonuje kilkanaście kroków na Twoich plikach. Czasem formularz z jednym polem tekstowym i przyciskiem „Generuj”, który pod spodem wysyła jedno zapytanie do modelu i wyświetla odpowiedź. Obie rzeczy sprzedaje się pod tym samym szyldem, a różnią się mniej więcej tak, jak kalkulator różni się od księgowej.

Dla osoby, która chce używać AI w analizie danych, to zamieszanie ma praktyczny koszt. Jeśli nie wiesz, z czym pracujesz, trudno ocenić, czego się spodziewać, gdzie szukać błędów i ile uprawnień możesz bezpiecznie oddać. W tym artykule rozkładam temat na trzy poziomy tej samej technologii: model, czat i agenta. Każdy poziom dokłada coś do poprzedniego, a na końcu dostajesz prosty test, który pomaga dobrać poziom do zadania. Od tej mapy zaczynamy pierwszy tydzień kursu, bo bez niej trudno potem rozsądnie zaplanować cokolwiek innego.

Skąd wzięło się zamieszanie z nazwami

Zamieszanie ma dwa źródła. Pierwsze jest marketingowe. „Agent” brzmi poważniej niż „czat”, a „czat” poważniej niż „funkcja, która wysyła tekst do modelu”. Nazwa produktu mówi więc głównie o ambicjach działu sprzedaży.

Drugie źródło jest bardziej uczciwe: granice naprawdę się zacierają. Czaty dostały narzędzia, narzędzia dostały pętle, a pętle dostały dostęp do plików. Ta sama aplikacja potrafi raz odpowiedzieć na pytanie jak zwykły czat, a za chwilę uruchomić serię kroków na Twoim komputerze.

Najbardziej użyteczne rozróżnienie, jakie znam, zaproponowali inżynierowie Anthropic w tekście Building effective agents. Dzielą systemy oparte na modelach językowych na dwie grupy. Workflow to system, w którym model i narzędzia prowadzą z góry zapisane w kodzie ścieżki. Agent to system, w którym model sam kieruje swoim procesem i decyduje o użyciu narzędzi. Najważniejsze pytanie brzmi więc: kto decyduje o następnym kroku? Jeśli Ty albo programista, który napisał scenariusz, masz do czynienia z czymś prostszym niż agent. Jeśli model, zaczyna się agentowość, a razem z nią nowa kategoria problemów.

Poniżej idę od dołu do góry. Każdy poziom opisuję tak, jak widzi go osoba, która ma do zrobienia analizę, a niekoniecznie chce zostać inżynierem AI.

Poziom pierwszy: model

Na samym dole jest model językowy. Upraszczając tylko trochę: dostaje tekst i przewiduje, jaki fragment tekstu powinien nastąpić dalej. Potem dokłada kolejny fragment i kolejny, aż powstanie cała odpowiedź. Sam model nie ma dostępu do Twoich plików, nie widzi internetu, nie pamięta wczorajszej rozmowy i nie może niczego uruchomić. Ma wyłącznie to, czego nauczył się podczas treningu, oraz tekst, który dostał w bieżącym zapytaniu.

Z tego prostego opisu wynika większość błędów, które ludzie przypisują „głupocie” AI. Model zapytany o liczbę, której nie ma w kontekście, poda liczbę, która brzmi prawdopodobnie. Zapytany o wynik dzielenia dwóch dużych liczb często poda wynik bliski prawdy, choć niekoniecznie równy prawdzie, bo przewiduje tekst wyniku zamiast go liczyć. Zapytany o dane Twojej firmy odpowie na podstawie tego, jak zwykle wyglądają dane firm w internecie. Kasia opisuje te mechanizmy szerzej w artykule o sprawdzaniu wyników AI, więc tutaj zostanę przy jednym wniosku: model sam w sobie jest znakomitym generatorem tekstu i kiepskim źródłem faktów.

Czy to znaczy, że model jest bezużyteczny w analizie? Wręcz przeciwnie. Świetnie radzi sobie z zadaniami, w których cały potrzebny materiał mieści się w zapytaniu: wyjaśni formułę, przepisze nazwy kolumn na zrozumiałe, zaproponuje kategorie dla komentarzy klientów, przetłumaczy zapytanie SQL na ludzki język. Warunek jest jeden: wszystko, czego potrzebuje, musisz mu dać, a wynik musisz umieć ocenić.

W praktyce rzadko rozmawiasz z „gołym” modelem. Spotykasz go zwykle jako element większej całości, na przykład w skrypcie, który dla każdego wiersza arkusza wysyła do modelu jeden komentarz i zapisuje odpowiedź. W słowniku Anthropic to klasyczny workflow: ścieżka jest stała, a model wykonuje jeden ściśle określony krok.

Poziom drugi: czat

Czat to model opakowany w aplikację. Ta aplikacja robi kilka rzeczy, których model sam nie potrafi.

Po pierwsze, pamięta rozmowę. Technicznie wysyła do modelu dotychczasową historię (całą albo jej część), dzięki czemu model „wie”, o czym mówiliście trzy wiadomości temu. Ta pamięć ma granice: okno kontekstu jest skończone, a w długich rozmowach wątki z początku zaczynają się gubić. Zamknięta karta oznacza zazwyczaj, że kontekst trzeba budować od nowa. Dlatego w kursie tak mocno naciskam na brief zapisany w pliku, który przeżyje każdą zamkniętą kartę.

Po drugie, ma narzędzia. Popularne czaty potrafią dziś przeszukać internet, przeczytać wgrany plik, a przede wszystkim napisać i uruchomić kod w izolowanym środowisku. Dla analityka to ogromna zmiana. Kiedy czat liczy średnią przez uruchomienie kodu w Pythonie, wynik pochodzi z obliczenia, a model zajmuje się tym, w czym jest dobry: napisaniem kodu i opisaniem wyniku.

Po trzecie, rozmowa nadal należy do Ciebie. Czat odpowiada na wiadomość i czeka. Może w jednej odpowiedzi wykonać kilka czynności, na przykład wczytać plik, policzyć i narysować wykres, ale następny ruch zawsze jest Twój. Ty oceniasz, czy wynik jest dobry albo czy trzeba coś poprawić, i Ty przenosisz efekty pracy tam, gdzie mają trafić.

Ta ostatnia cecha jest zarazem zaletą i ograniczeniem czatu. Zaletą, bo masz kontrolę nad każdym krokiem. Ograniczeniem, bo przy większym zadaniu stajesz się ręcznym przekaźnikiem: kopiujesz kod z czatu do pliku, wynik z pliku do czatu, wykres z czatu do prezentacji. Jeśli łapiesz się na tym, że przez pół dnia pełnisz rolę taśmociągu między oknem rozmowy a własnym dyskiem, masz dobry sygnał, że zadanie dojrzało do poziomu wyżej.

Poziom trzeci: agent

Agent dostaje cel zamiast pojedynczego polecenia. Sam planuje kroki, wybiera narzędzia, używa ich, ogląda wyniki i decyduje, co dalej. W tekście Anthropic pada zdanie, które dobrze to streszcza: agenci to zwykle po prostu modele, które używają narzędzi w pętli, kierując się informacją zwrotną z otoczenia. Ta informacja zwrotna ma kluczowe znaczenie. Agent, który uruchomił skrypt i zobaczył błąd, może poprawić kod i spróbować jeszcze raz. Ten sam tekst podkreśla, że agent powinien na każdym kroku czerpać z otoczenia „prawdę” o stanie rzeczy, na przykład z wyników uruchomionego kodu, zamiast polegać na własnych przypuszczeniach.

W praktyce agent analityczny to najczęściej narzędzie pracujące na folderze projektu: czyta pliki, pisze skrypty, uruchamia je w terminalu, sprawdza wyniki i zapisuje efekty. W czwartym tygodniu kursu pracujemy w ten sposób z Codexem i Claude Cowork. Agent działa wtedy jak wykonawca, któremu zlecasz zadanie i którego rozliczasz z efektu.

Cztery elementy agenta

Każdy agent, niezależnie od producenta i nazwy, składa się z czterech elementów. Warto je znać, bo każdy z nich wymaga osobnego pytania przed uruchomieniem.

1. Cel. Co ma zostać osiągnięte i po czym poznać, że zadanie jest skończone. Bez kryterium końca agent albo przerwie pracę za wcześnie, albo będzie ją ciągnął w nieskończoność, poprawiając rzeczy, których nikt nie zamawiał.
2. Narzędzia. Co agent może zrobić: czytać pliki, zapisywać pliki, uruchamiać polecenia, łączyć się z bazą danych, wysyłać wiadomości. Lista narzędzi wyznacza zasięg jego działania.
3. Pętla. Plan, działanie, obserwacja wyniku, korekta. Anthropic zaleca tu warunki zatrzymania, na przykład maksymalną liczbę iteracji, oraz punkty kontrolne, w których agent zatrzymuje się i czeka na człowieka.
4. Uprawnienia. Do czego agent ma dostęp i czego może dotknąć bez pytania. Ten element jest najmniej efektowny i moim zdaniem najważniejszy.

Dlaczego uprawnienia są ważniejsze niż inteligencja

Kiedy ludzie porównują agentów, pytają zwykle, który jest najmądrzejszy. Rozumiem to, sam też lubię rankingi. Przy pracy na prawdziwych danych pierwsze pytanie powinno jednak brzmieć inaczej: co ten agent może zepsuć, jeśli się pomyli?

Odpowiedź zależy prawie wyłącznie od uprawnień. Najbardziej błyskotliwy agent z dostępem tylko do odczytu w najgorszym razie przyniesie błędny wniosek, który wyłapiesz przy weryfikacji. Przeciętny agent z prawem zapisu do bazy produkcyjnej może jednym źle zrozumianym poleceniem usunąć dane, których nie da się odtworzyć. Inteligencja zmniejsza prawdopodobieństwo błędu. Uprawnienia decydują o jego koszcie.

Organizacja OWASP, znana z list najważniejszych zagrożeń dla aplikacji webowych, opisuje ten problem w zestawieniu ryzyk dla aplikacji opartych na modelach językowych pod nazwą Excessive Agency, czyli nadmierna sprawczość. Wskazuje trzy przyczyny: nadmiar funkcji (agent ma narzędzia, których do zadania nie potrzebuje), nadmiar uprawnień (narzędzia mają szerszy dostęp, niż wymaga zadanie) i nadmiar autonomii (agent wykonuje działania o dużych skutkach bez niezależnego sprawdzenia albo zatwierdzenia). Przykład z tego opracowania dobrze pokazuje, jak to wygląda w praktyce. Asystent ma wyłącznie streszczać przychodzące maile, ale wtyczka do poczty, z której korzysta, potrafi też je wysyłać. Wystarczy wiadomość z ukrytą instrukcją, żeby model przesłał poufną korespondencję na zewnątrz. Zalecane środki zaradcze są nudne i skuteczne: dostęp tylko do odczytu, zgoda człowieka przed działaniem o dużych skutkach i sprawdzanie uprawnień po stronie systemu docelowego zamiast polegania na osądzie modelu. Ukryte instrukcje w danych mają zresztą własną nazwę, prompt injection, i wracamy do nich w szóstym tygodniu kursu, przy bezpieczeństwie procesu.

Ta sama logika przyświeca narzędziom agentowym, z których korzystamy na zajęciach. Claude Code w trybie ręcznym czyta pliki w katalogu projektu bez pytania, ale przed edycją pliku i przed większością poleceń w terminalu prosi o zgodę. Wygląda to na drobiazg, a wyznacza dokładnie tę granicę, która ma znaczenie: czytanie jest tanie i odwracalne, zmiana bywa droga i nieodwracalna.

To samo rozróżnienie wraca w drugim tygodniu kursu, kiedy łączymy AI z repozytorium, Notion i Linearem przez MCP. Twórcy protokołu porównują go do portu USB-C dla aplikacji AI: jeden standard, przez który podłączasz różne źródła danych i narzędzia. Port jest wygodny, ale kabel przewodzi w obie strony. Dlatego przy każdym nowym połączeniu pytamy osobno, czy agent będzie z niego wyłącznie czytał, czy także wprowadzał zmiany. O dostępie tylko do odczytu przy pracy z bazą danych pisze Kasia w tekście o SQL z AI.

Każdy poziom myli się inaczej

Program pierwszego tygodnia mówi też o tym, skąd biorą się błędne odpowiedzi. Na każdym z trzech poziomów błędy wyglądają trochę inaczej, więc i sprawdzanie warto do nich dopasować.

Model myli się najczęściej treścią. Podaje fakt, którego nie ma, liczbę, której nie policzył, albo definicję, która pasuje do „przeciętnej firmy z internetu”. Taki błąd wyłapiesz, porównując odpowiedź z materiałem, który mu dałeś.

Czat dokłada błędy procesu. Wczytał tylko część pliku, źle rozpoznał separator w CSV, zgubił warunek podany dwadzieścia wiadomości wcześniej albo napisał kod, który działa i liczy coś innego, niż miał. Tu pomaga prośba o pokazanie kodu i o raport z przetwarzania: ile wierszy wczytano, ile odrzucono i dlaczego.

Agent dokłada błędy decyzji. Wybrał zły plik, bo dwa miały podobne nazwy. Poprawił test zamiast poprawić kod, żeby „wszystko przechodziło”. Zrobił coś, o co nikt nie prosił, bo uznał to za pomocne. A ponieważ wykonuje wiele kroków bez Twojego udziału, mały błąd z kroku drugiego może urosnąć do kroku dziesiątego. Anthropic ujmuje to wprost: autonomia agentów oznacza wyższe koszty i ryzyko narastania błędów. Dlatego przy agencie przeglądam przede wszystkim listę zmian, zanim cokolwiek zatwierdzę, i trzymam go w miejscu, gdzie każdą zmianę da się cofnąć.

Prosty test wyboru

Teoria teorią, a w poniedziałek rano masz konkretne zadanie i chcesz wiedzieć, od czego zacząć. Używam trzech pytań. Zadaję je w tej kolejności, bo każde kolejne podnosi poprzeczkę.

Czy zadanie wymaga plików? Jeśli cały potrzebny materiał zmieści się w jednej wiadomości (kawałek formuły, kilkanaście komentarzy, opis problemu), wystarczy zwykłe pytanie w czacie. Jeśli potrzebujesz jednego czy dwóch plików, czat z narzędziami da radę. Jeśli plików jest kilkanaście, leżą w strukturze folderów i odwołują się do siebie, zaczyna się terytorium agenta.

Czy zadanie wymaga wielu kroków, z których każdy zależy od wyniku poprzedniego? Jedna analiza z jednym wykresem to jeden krok, nawet jeśli czat wykona go w kilku ruchach. Proces typu „wczytaj, oczyść, połącz, policz, sprawdź zgodność z raportem, popraw, wygeneruj dashboard” to wiele kroków, a jeśli po drodze trzeba reagować na błędy, agent zaoszczędzi Ci sporo przekładania.

Czy zadanie wymaga dostępu do systemów i wprowadzania w nich zmian? Czytanie danych z bazy, aktualizacja zadania w Linearze, zapis pliku w repozytorium. Odpowiedź „tak” wskazuje na agenta, ale przede wszystkim otwiera rozmowę o uprawnieniach, zanim cokolwiek uruchomisz.

Jeśli na wszystkie trzy pytania odpowiadasz „nie”, użyj czatu i nie komplikuj. Jedno „tak” zwykle oznacza czat z narzędziami. Dwa lub trzy oznaczają, że agent ma sens, pod warunkiem że zaczniesz od najwęższych uprawnień, jakie pozwalają wykonać zadanie.

Na końcu zadaję jeszcze czwarte pytanie: czy zadanie będzie się powtarzać? Jeśli co tydzień robisz te same kroki w tej samej kolejności, być może potrzebujesz skryptu albo workflow z modelem w jednym, ściśle określonym miejscu. Agentowi zostawisz wtedy napisanie takiego skryptu. W szóstym tygodniu kursu poświęcamy temu cały temat: kiedy wystarczy skrypt, a kiedy potrzebny jest agent.

Trzy przykłady z analizy danych

Najłatwiej zrozumieć różnicę na przykładach. Wszystkie trzy to typowe sytuacje z pracy analitycznej, dobrane tak, żeby każda pasowała do innego poziomu.

Model w ustalonym kroku: kategorie komentarzy klientów

Masz arkusz z kilkuset komentarzami z ankiety i chcesz przypisać każdemu jedną z sześciu kategorii. Zadanie jest powtarzalne, krok jest zawsze ten sam, a materiał do każdego kroku to jeden komentarz. Najrozsądniejsze rozwiązanie to prosty workflow: skrypt (albo funkcja w arkuszu) wysyła do modelu komentarz razem z listą kategorii i ich definicjami, a odpowiedź zapisuje w kolumnie obok. Model decyduje wyłącznie o kategorii. Ty sprawdzasz losową próbkę i liczbę komentarzy w każdej kategorii.

Agent byłby tu przesadą. Nie ma czego planować ani czego eksplorować. Jest jeden krok powtórzony kilkaset razy.

Czat z narzędziami: szybka analiza eksportu sprzedaży

Szef pyta, dlaczego sprzedaż w październiku wygląda gorzej niż we wrześniu, i chce odpowiedzi na jutro. Masz eksport z systemu sprzedaży w CSV. Wgrywasz plik do czatu razem z krótkim briefem: cel, definicja sprzedaży, znane dziwactwa danych, kryterium poprawności. Czat pisze kod, liczy, rysuje wykres. Ty dopytujesz o podział na kategorie i regiony, porównujesz sumę z raportem finansowym i decydujesz, które obserwacje warto pokazać.

Czat sprawdza się tu najlepiej, bo zadanie jest eksploracyjne i krótkie. Każda kolejna wiadomość zależy od Twojej oceny poprzedniego wyniku, a tę ocenę lepiej zostawić sobie.

Agent na projekcie: miesięczny raport z kilku źródeł

Co miesiąc przygotowujesz raport, który łączy dane z trzech eksportów, przelicza wskaźniki według firmowych definicji i aktualizuje dashboard w HTML. Pliki leżą w folderze projektu, definicje w pliku z instrukcjami, a poprzednie wersje raportu obok. Agent może przeczytać wszystko, napisać i uruchomić skrypty, porównać wynik z zeszłym miesiącem, wyłapać zmiany w strukturze plików i przygotować nową wersję dashboardu do Twojego przeglądu.

Tutaj agent zaczyna się opłacać, bo zadanie ma wiele kroków, wymaga plików i się powtarza. Warunki brzegowe: agent pracuje na kopii danych, nie ma prawa zapisu w systemach źródłowych, a nowa wersja raportu trafia do odbiorców dopiero po Twojej akceptacji. Jak zapisać stałe instrukcje projektu, żeby agent nie zaczynał co miesiąc od zera, opisuję w tekście o pamięci projektu w README, AGENTS.md i CLAUDE.md.

Kiedy agent to przesada

Na koniec zostawiłem temat, który w czwartym tygodniu kursu omawiamy pod hasłem doboru skali rozwiązania. Programiści znają zasadę YAGNI, czyli „You Aren’t Gonna Need It”: nie buduj czegoś, dopóki naprawdę tego nie potrzebujesz. W świecie AI przekłada się ona na prostą regułę. Zaczynaj od najprostszego narzędzia, które załatwi sprawę, i przechodź poziom wyżej dopiero wtedy, gdy prostsze wyraźnie nie wystarcza.

Anthropic mówi to samo w swoim tekście: radzi szukać najprostszego możliwego rozwiązania i zwiększać złożoność dopiero wtedy, gdy jest potrzebna. Przypomina też, że systemy agentowe często płacą opóźnieniem i kosztem za lepszy wynik. Każdy dodatkowy krok, który agent wykonuje samodzielnie, jest kolejnym miejscem, w którym może skręcić w złą stronę, a Ty możesz tego nie zauważyć.

Oto sytuacje, w których agent przypomina wynajęcie ekipy remontowej do wkręcenia żarówki:

• Jednorazowe pytanie. „Co znaczy ta formuła?” nie wymaga planu, narzędzi ani dostępu do Twojego dysku.
• Zadanie, którego nie umiesz sprawdzić. Jeśli nie potrafisz ocenić wyniku, agent wygeneruje go szybciej i w większej ilości, a Twoja niepewność urośnie razem z nim. Najpierw kryterium poprawności, potem automatyzacja.
• Zadanie bez jasnego celu. Agent z mglistym celem będzie bardzo pracowity w nieokreślonym kierunku. Lepiej najpierw doprecyzować zadanie w czacie, a potem przekazać je agentowi jako brief.
• Dane, do których agent nie powinien mieć dostępu. Jeśli zadanie wymaga danych osobowych albo poufnych, a nie masz pewności, gdzie trafią, odpowiedź brzmi „jeszcze nie”, bez względu na to, jak wygodny byłby agent.
• Zadanie, które zrobisz szybciej sam. Opisanie celu, przygotowanie folderu i przejrzenie zmian też zajmuje czas. Jeśli całość zajmie Ci pięć minut w arkuszu, zrób to w arkuszu.

Na zajęciach powtarzam, że najlepsze rozwiązanie to najprostsze, które przechodzi weryfikację. Czasem będzie nim agent. Częściej, zwłaszcza na początku, wystarczy dobrze przygotowany czat.

Jak zacząć w tym tygodniu

Jeśli chcesz przetestować tę mapę na sobie, proponuję trzy kroki.

1. Weź listę zadań analitycznych z ostatniego miesiąca i przy każdym zadaj trzy pytania z testu: pliki, kroki, systemy. Zapisz, na jaki poziom wskazuje odpowiedź.
2. Wybierz jedno zadanie z poziomu czatu i zrób je z briefem, z prośbą o pokazanie kodu i z kontrolą sumy. Zobacz, ile czasu zajmuje Ci przekładanie wyników między oknem rozmowy a dyskiem.
3. Jeśli przekładanie zajmuje więcej niż sama analiza, wypróbuj agenta na kopii projektu, w trybie, w którym prosi o zgodę przed każdą zmianą. Obserwuj, jakie kroki planuje, zanim pozwolisz mu działać szerzej.

Po kilku takich próbach zauważysz, że pytanie „który model jest najlepszy” traci na znaczeniu. Ważniejsze staje się to, jak zaprojektujesz pracę: co dostaje model, kto decyduje o następnym kroku i czego narzędzie nie może dotknąć bez Twojej zgody. Tego uczymy w pierwszym tygodniu i na tym budujemy kolejne pięć.