Narzędzia vs Agenci: fundamentalna różnica w myśleniu

Czego się nauczysz

• Czym różni się model, narzędzie i agent w praktyce
• Dlaczego agent to nie jest po prostu “większy chat”
• Kiedy używać zwykłej odpowiedzi tekstowej, a kiedy wejść w tryb agentowy

Tu najłatwiej pomylić poziomy

Wokół Copilota bardzo łatwo mówić skrótami.

“Agent zrobił zmianę.” “Copilot użył narzędzia.” “Model znalazł błąd.”

Tylko że te trzy rzeczy nie są tym samym.

Jeśli tego nie rozdzielisz, będziesz mieć złe oczekiwania wobec produktu. Raz będziesz oczekiwać autonomii tam, gdzie dostajesz tylko odpowiedź tekstową. Innym razem uznasz, że agent “źle myśli”, chociaż problemem było złe narzędzie albo brak zgody na jego użycie.

Zacznijmy od najprostszej warstwy: model

Model językowy sam w sobie nie czyta Ci repo, nie uruchamia testów i nie zmienia plików.

Model generuje odpowiedzi na podstawie kontekstu, który dostał. Potrafi:

• wyjaśnić fragment kodu
• zaproponować plan
• napisać tekst albo kod
• zasugerować kolejny krok

Ale bez narzędzi jest ograniczony do świata promptu.

To oznacza, że czysty model jest świetny do:

• analizy
• tłumaczenia
• porównywania opcji
• szkicowania rozwiązania

I słaby do wszystkiego, co wymaga realnej interakcji z projektem albo środowiskiem.

Narzędzia dają modelowi ręce

W dokumentacji VS Code narzędzia są opisane jako mechanizm działania na środowisku deweloperskim.

Bez narzędzi model może tylko mówić. Z narzędziami może:

• czytać pliki
• zapisywać zmiany
• uruchamiać komendy terminala
• przeszukiwać codebase
• łączyć się z zewnętrznymi usługami

VS Code grupuje te narzędzia w trzy kategorie:

• built-in tools
• MCP tools
• extension tools

To ważne z perspektywy architektury pracy. Sam model nie “ma dostępu do bazy” ani “zna API Twojej firmy”. On może co najwyżej użyć narzędzia, które mu taki dostęp udostępnia.

Agent to orkiestracja, nie pojedyncza odpowiedź

Agent to warstwa wyżej.

W dokumentacji jest to opisane bardzo jasno: agent dostaje cel, planuje kroki, używa narzędzi, sprawdza wyniki i iteruje, dopóki nie domknie zadania albo nie trafi w ograniczenie.

Najprostsza robocza rama wygląda tak:

1. Understand
2. Act
3. Validate

Czyli agent:

• najpierw rozpoznaje problem
• potem wykonuje akcje
• na końcu sprawdza, czy wyszło

I jeśli nie wyszło, wraca do kolejnej iteracji.

To właśnie odróżnia agenta od zwykłego chatu. Chat odpowiada. Agent prowadzi proces.

Dlaczego agent to nie jest “większy chat”

To uproszczenie brzmi niewinnie, ale psuje workflow.

Jeśli traktujesz agenta jak większy chat, będziesz go oceniać po jakości jednej odpowiedzi tekstowej. A to zły punkt odniesienia.

Agenta ocenia się po czymś innym:

• czy dobrał sensowne kroki
• czy użył właściwych narzędzi
• czy potrafił się skorygować po błędzie
• czy umiał zweryfikować wynik

W praktyce agent może wygenerować przeciętny pierwszy opis, a mimo to dobrze dowieźć zadanie, bo czyta pliki, uruchamia testy i iteruje.

I odwrotnie: może brzmieć mądrze w pierwszej odpowiedzi, ale zawalić wykonanie, jeśli ma zły zestaw narzędzi albo zbyt szeroką autonomię bez kontroli.

Gdzie wchodzą approvals i trust

Narzędzia i agenty nie działają w próżni. VS Code celowo dokłada tu warstwę bezpieczeństwa.

W dokumentacji jest to opisane przez approval prompts, permission levels i kontrolę dostępu do URL-i albo działań ubocznych.

To ważne z dwóch powodów:

• agent może zrobić więcej niż sam model, więc ryzyko też jest większe
• autonomia bez granic nie jest oznaką dojrzałości workflow, tylko proszeniem się o błędy

Praktyczny wniosek jest prosty: agent jest najbardziej wartościowy wtedy, gdy ma wystarczająco dużo narzędzi do działania, ale nadal pracuje w granicach, które kontrolujesz.

Po czym poznać, że potrzebujesz tylko narzędzia

Nie każde zadanie wymaga pełnego trybu agentowego.

Wystarczy zwykły chat albo pojedyncze narzędzie, gdy:

• chcesz tylko wyjaśnienia fragmentu kodu
• potrzebujesz jednego searcha albo odczytu pliku
• chcesz szybko porównać dwa podejścia
• potrzebujesz jednorazowej komendy albo jednej poprawki

W takich sytuacjach agent bywa po prostu cięższy niż potrzeba.

Po czym poznać, że potrzebujesz agenta

Agent ma sens wtedy, gdy zadanie jest wieloetapowe i wymaga pętli wykonawczej.

Na przykład gdy trzeba:

• znaleźć miejsca zmian w kilku plikach
• wprowadzić poprawki
• odpalić testy albo build
• przeanalizować błąd
• poprawić wynik i sprawdzić ponownie

To jest dokładnie ten typ pracy, dla którego sama odpowiedź tekstowa robi się za krótka, a agent zaczyna oszczędzać czas.

Subagenci i pamięć to kolejny poziom, nie podstawa

W dokumentacji VS Code agenty mają też memory, planning i subagents.

To ważne, ale na tym etapie kursu trzeba zobaczyć priorytety:

• model odpowiada
• narzędzia wykonują akcje
• agent koordynuje sekwencję działań

Dopiero na tym fundamencie sensownie rozumiesz, po co są subagenci, planowanie i pamięć.

Bez tego łatwo wpaść w myślenie, że wszystko jest jedną “mądrzejszą wersją chatu”. Nie jest.

Mój praktyczny filtr wyboru

Jeśli masz zdecydować szybko, użyj tego filtra:

• potrzebuję zrozumieć temat: użyj chatu i modelu
• potrzebuję konkretnego działania na jednym zasobie: użyj właściwego narzędzia
• potrzebuję procesu obejmującego kilka kroków i weryfikację: użyj agenta

To proste rozróżnienie porządkuje większość codziennej pracy z Copilotem.

Ćwiczenie praktyczne

Weź jedno małe zadanie z repo i zrób je na dwa sposoby.

1. W Ask poproś o wyjaśnienie problemu i plan naprawy.
2. W Agent poproś o wykonanie tej samej zmiany wraz z weryfikacją.
3. Zapisz, które elementy były tylko tekstem modelu, które wynikały z użycia narzędzi i gdzie agent wykonał pętlę: zrozumienie, działanie, walidacja.

Po tym ćwiczeniu powinno być już jasne, że “agent” nie oznacza po prostu dłuższej odpowiedzi. Oznacza inny tryb pracy.

Kluczowe wnioski

• Model generuje odpowiedzi, ale bez narzędzi nie działa na środowisku.
• Narzędzia dają dostęp do plików, terminala, searcha i usług zewnętrznych.
• Agent orkiestruje cały proces: rozumie, działa i waliduje.
• Nie każde zadanie wymaga agenta; wiele zadań lepiej obsłużyć prostszym trybem.
• Dobra praca agentowa wymaga też kontroli uprawnień i sensownego zestawu narzędzi.

Co dalej

Skoro fundament działania Copilota jest już jasny, można przejść do pierwszej powierzchni, z którą realnie pracujesz przez cały dzień: sugestii inline i tego, jak utrzymać flow bez ciągłego przełączania się do chatu.