Memory agentów i Subagenci

Czego się nauczysz

• Jak działa local memory w VS Code i czym różnią się scope’y user, repository i session
• Po co istnieją subagenci i kiedy naprawdę pomagają
• Dlaczego local memory i Copilot Memory to dwa różne mechanizmy

Bez pamięci każdy agent zaczynałby od zera

To byłoby kosztowne i irytujące.

Gdy agent ma rozwiązać złożone zadanie, potrzebuje dwóch rzeczy:

• miejsca, w którym zachowa trwałe lub tymczasowe ustalenia
• sposobu, żeby oddelegować część pracy bez zaśmiecania głównego kontekstu

W VS Code te dwa problemy rozwiązują odpowiednio memory i subagenci.

Local memory ma trzy scope’y

Dokumentacja memory tool jest bardzo konkretna. W lokalnym systemie pamięci VS Code masz trzy zakresy:

• user w /memories/
• repository w /memories/repo/
• session w /memories/session/

To nie są tylko trzy foldery. To trzy różne kontrakty trwałości.

User memory: rzeczy o Tobie, nie o projekcie

User memory przechodzi między workspace’ami i rozmowami. To dobre miejsce na preferencje, które mają sens niezależnie od repo.

Na przykład:

• sposób formatowania odpowiedzi
• preferowane komendy
• powtarzalne nawyki przy generowaniu kodu

To zły folder na architekturę konkretnego systemu. Jeśli tam wylądują fakty repozytoryjne, agent zacznie je przenosić do innych projektów i narobisz sobie szumu.

Repository memory: fakty o tym repo

Repository memory jest trwałe, ale tylko w obrębie danego workspace.

Tu trafiają rzeczy typu:

• komendy build/test
• konwencje nazewnicze w tym projekcie
• decyzje architektoniczne
• ustalone workflow zespołu

To dokładnie ten typ wiedzy, który chcesz zachować dla kolejnych rozmów, ale nie chcesz go przenosić do obcych repozytoriów.

Session memory: roboczy kontekst na teraz

Session memory znika po zakończeniu rozmowy. I dobrze.

To jest pamięć robocza, nie trwała baza wiedzy. Świetnie nadaje się do:

• planu implementacji
• notatek z bieżącej sesji
• tymczasowych decyzji potrzebnych do domknięcia zadania

Dokumentacja podaje ważny przykład: Plan agent zapisuje plan do plan.md w session memory.

To dobry wzorzec myślenia. Session memory służy do prowadzenia aktualnej operacji, a nie do przechowywania polityki projektu.

Local memory to nie to samo co Copilot Memory

To rozróżnienie trzeba zapamiętać bardzo wcześnie.

Local memory:

• jest przechowywane lokalnie na Twojej maszynie
• ma trzy scope’y: user, repository, session
• działa w ramach VS Code

Copilot Memory:

• jest hostowane po stronie GitHub
• jest repozytoryjne
• może być współdzielone przez różne powierzchnie Copilota, na przykład coding agent, code review i CLI
• jest opt-in i ma własny cykl życia

Jeśli pomylisz te dwa systemy, zaczniesz błędnie oczekiwać, że wszystko, co agent “zapamiętał” lokalnie, automatycznie zadziała też w chmurze albo na GitHubie.

Tak nie jest.

Po co w ogóle są subagenci

Subagent to niezależny agent uruchamiany do konkretnego podzadania.

Jego główna wartość nie polega na tym, że “robi więcej rzeczy naraz”. Jego wartość polega na izolacji kontekstu.

Gdy zlecasz subagentowi research, analizę albo review z konkretnej perspektywy, główna sesja dostaje z powrotem streszczenie, a nie cały ślad każdego pośredniego kroku.

To pozwala utrzymać główny kontekst czysty.

Kiedy subagenci pomagają naprawdę

Najlepsze scenariusze z dokumentacji są bardzo praktyczne:

• research przed implementacją
• równoległa analiza kilku aspektów kodu
• porównanie kilku możliwych rozwiązań
• review z wielu perspektyw

Czyli dokładnie tam, gdzie chcesz rozdzielić problem na niezależne strumienie myślenia.

Jeśli jednak zadanie jest małe i liniowe, subagent tylko dołoży narzut.

Co użytkownik widzi przy subagencie

To ważny detal interfejsu: subagent pojawia się jako collapsible tool call w czacie.

Domyślnie widzisz tylko skrót:

• nazwę agenta
• aktualnie wykonywane narzędzie

Po rozwinięciu możesz sprawdzić szczegóły. To dobre rozwiązanie, bo nie zaśmieca głównej rozmowy, ale nadal zostawia ślad kontrolny.

Subagent nie powinien być magiczną odpowiedzią na wszystko

Jest pokusa, żeby dla każdego większego promptu pisać “uruchom subagenta”. Dokumentacja sugeruje lepsze podejście.

To główny agent powinien rozpoznać, kiedy izolacja kontekstu naprawdę pomaga. Jeśli tworzysz własne agenty, lepiej zapisać taką zasadę w ich instrukcjach, niż za każdym razem ręcznie ją dopowiadać.

Innymi słowy: subagenci są częścią architektury workflow, nie ozdobnikiem promptu.

Nested subagents mają limit i nie są domyślne

To kolejny ważny bezpiecznik.

Domyślnie subagenci nie mogą uruchamiać kolejnych subagentów. Rekursję trzeba jawnie włączyć, a i wtedy istnieje limit głębokości.

To chroni przed zapętleniem i przed workflow, który wygląda ambitnie, ale w praktyce staje się nieprzewidywalny.

Dobra praktyka operacyjna

Jeżeli masz zaprojektować rozsądny workflow, trzymaj się prostego podziału:

• to, co ma zostać z Tobą między projektami, zapisuj jako user memory
• to, co dotyczy repo, trzymaj w repository memory
• to, co jest planem albo notatką tylko na tę sesję, wkładaj do session memory
• subagentów używaj tylko do zadań, które zyskują na izolacji albo równoległości

To zwykle wystarcza, żeby agentowy workflow był czytelny i powtarzalny.

Kluczowe wnioski

• Local memory w VS Code ma trzy scope’y: user, repository i session.
• Session memory służy do pracy bieżącej, a nie do trwałych zasad projektu.
• Local memory i Copilot Memory to dwa różne systemy o innym miejscu przechowywania i innym zasięgu.
• Subagenci pomagają wtedy, gdy chcesz odizolować kontekst albo rozdzielić analizę na niezależne strumienie.
• Nadmiar subagentów daje hałas, a nie produktywność.

Co dalej

Masz już model pracy agenta i sposób utrzymywania kontekstu. Teraz trzeba dołożyć najważniejszy bezpiecznik: jak ustawić poziom autonomii, approvals i granice dla narzędzi.