Local vs Background vs Cloud Agents: który i kiedy

Czego się nauczysz

• Jak odróżnić typ sesji agenta od roli samego agenta
• Kiedy wybrać local, background albo cloud workflow
• Dlaczego Ask, Plan i Agent nie konkurują z cloud agentem, tylko działają na innym poziomie decyzji

Najpierw rozdziel dwie osie decyzji

W dokumentacji agentów bardzo łatwo przeoczyć jedną rzecz: są tu dwa różne pytania.

Pierwsze pytanie brzmi: gdzie agent pracuje?

• lokalnie w VS Code
• w tle na Twojej maszynie
• zdalnie w chmurze

Drugie pytanie brzmi: jaką rolę ma pełnić?

• Ask
• Plan
• Agent
• custom agent

Jeśli pomieszasz te dwa poziomy, szybko zrobi się chaos. Możesz mieć przecież lokalną sesję Ask, lokalną sesję Plan, lokalną sesję Agent, a potem oddać wynik do cloud agentu.

Local agent: najlepszy tam, gdzie liczy się kontekst IDE

Local agent działa w samym VS Code i ma dostęp do tego, co widzi Twój edytor.

To obejmuje między innymi:

• pliki workspace
• problemy z edytora
• wyniki lintingu i testów
• narzędzia wnoszone przez rozszerzenia i MCP
• modele dostępne lokalnie w Twoim środowisku VS Code

To jest najlepszy wybór, gdy problem wymaga szybkiej iteracji i bieżącego kontekstu deweloperskiego.

Przykłady:

• “dlaczego ten test pada po ostatniej zmianie”
• “rozpisz plan refaktoru dla tego modułu”
• “napraw ten flow i sprawdź, czy projekt dalej się buduje”

Built-in agenci w local workflow

W ramach lokalnej pracy masz trzy główne wbudowane role:

• Ask: do pytań, analizy i wyjaśnień bez automatycznych zmian w plikach
• Plan: do rozpisania implementacji przed kodowaniem
• Agent: do wykonania zadania z użyciem narzędzi i iteracji

To znaczy, że local agent nie jest jednym trybem. To całe środowisko interaktywnej pracy z różnymi intencjami.

Warto też pamiętać o ważnym detalu z dokumentacji: stary Edit Mode jest oznaczony jako deprecated. W praktyce multi-file edits przejął Agent.

Background agent: gdy chcesz delegować, ale na swojej maszynie

Drugi typ to praca w tle, czyli przede wszystkim Copilot CLI.

Ten wariant ma sens, kiedy chcesz zlecić dobrze określone zadanie i nie chcesz siedzieć cały czas w aktywnej sesji chatu. To dobry model dla:

• proof of conceptów
• eksperymentów w odseparowanym worktree
• zadań, które mogą wykonywać się obok Twojej bieżącej pracy

Z punktu widzenia workflow to pomost między pełną interaktywnością a pełną delegacją.

Cloud agent: delegacja z myślą o repo i PR-ach

Cloud agent działa zdalnie i najlepiej sprawdza się wtedy, gdy zadanie jest dobrze określone i gotowe do wykonania bez bieżącej współpracy człowiek-model co kilka minut.

Najmocniejsze scenariusze z dokumentacji to:

• większy refaktor w repo
• implementacja feature’a z wysokopoziomowego opisu
• automatyczne przygotowanie PR-a
• adresowanie feedbacku z review

Najważniejsza różnica względem local agentów jest praktyczna: cloud agent nie ma bezpośredniego dostępu do kontekstu runtime Twojego VS Code, na przykład do aktywnej selekcji, lokalnych problemów edytora czy bieżących wyników testów w sesji.

Jak wybierać między local, background i cloud

Dobry filtr decyzyjny jest prosty.

Wybierz local, gdy:

• potrzebujesz szybkiej iteracji
• zadanie wymaga kontekstu edytora
• chcesz na bieżąco sterować kierunkiem pracy

Wybierz background, gdy:

• zadanie jest dobrze określone
• chcesz je odpalić obok własnej pracy
• potrzebujesz bardziej autonomicznego przebiegu, ale nadal na swojej maszynie

Wybierz cloud, gdy:

• zadanie nadaje się do delegacji repozytoryjnej
• ważny jest PR i współpraca zespołowa
• nie potrzebujesz bieżącego kontekstu lokalnego IDE

Handoff jest ważniejszy niż idealny pierwszy wybór

Dużo osób szuka jednego najlepszego typu agenta na start. To nie jest najlepszy model myślenia.

Aktualne docs mówią wprost: możesz przekazywać sesję dalej.

Praktyczny workflow często wygląda tak:

• lokalnie doprecyzowujesz temat w Ask
• lokalnie robisz plan w Plan
• oddajesz implementację do cloud agentu albo background agenta

To podejście jest bardziej profesjonalne niż próba zamknięcia wszystkiego w jednej sesji tylko dlatego, że już ją masz otwartą.

A co z third-party agents

W overview pojawia się jeszcze czwarta kategoria: third-party agents, na przykład Anthropic albo OpenAI.

Nie są sednem tej lekcji, ale warto zapamiętać jedną rzecz: to kolejna odpowiedź na pytanie gdzie i przez kogo działa agent, a nie zamiennik dla Ask czy Plan.

Innymi słowy: provider modelu i typ sesji to nadal nie to samo co rola agenta.

Najczęstszy błąd praktyczny

Najczęściej spotkasz taki błąd:

• ktoś mówi “użyj Plana w chmurze” albo “cloud Ask”

To nie jest całkiem błędne językowo, ale zwykle maskuje brak rozumienia warstw.

Lepiej myśleć tak:

• najpierw wybieram środowisko wykonania sesji
• potem wybieram rolę albo handoff

Dzięki temu łatwiej zbudować sensowny workflow, a nie tylko losowo klikać kolejne opcje w UI.

Kluczowe wnioski

• Typ agenta odpowiada na pytanie, gdzie i w jaki sposób sesja działa: local, background albo cloud.
• Rola agenta odpowiada na pytanie, jakiego rodzaju pracę ma wykonać: Ask, Plan, Agent albo custom.
• Local jest najlepszy do zadań wymagających kontekstu IDE i szybkiej iteracji.
• Cloud wygrywa tam, gdzie liczy się delegacja, PR i współpraca wokół repozytorium.
• Najlepszy workflow często łączy kilka typów sesji przez handoff, zamiast zamykać wszystko w jednym trybie.

Co dalej

Skoro już wiesz, gdzie agent pracuje, trzeba zrozumieć, jak utrzymuje kontekst między zadaniami i jak rozbija problem na mniejsze części bez zatruwania całej sesji.