Third-Party Agents i Plugins

Czego się nauczysz

• Czym różnią się third-party agents od agent plugins
• Jak wygląda model instalacji, trustu i zarządzania nimi w VS Code
• Kiedy rozszerzanie ekosystemu ma sens, a kiedy lepiej pozostać przy wbudowanych mechanizmach

To są dwa różne światy

I warto je rozdzielić bardzo ostro.

Third-party agents to alternatywne harnessy agentowe dostarczane przez zewnętrznych providerów, takich jak Claude czy Codex.

Agent plugins to paczki customizations, które mogą dostarczać skills, custom agents, hooks, MCP servers i slash commands.

Jedno nie zastępuje drugiego.

Third-party agents: inny silnik, ten sam punkt pracy

Dokumentacja third-party agents pokazuje dużą zaletę: możesz pracować z różnymi providerami w tym samym doświadczeniu VS Code.

To oznacza, że nadal masz wspólny punkt zarządzania sesjami, ale sam agent może być dostarczony przez inny system.

Praktyczny sens jest prosty:

• wybierasz agenta według mocnych stron
• nie rezygnujesz z ergonomii VS Code

Lokalny i cloudowy third-party agent to nie to samo

W docsach pojawia się ważne rozróżnienie:

• lokalne sesje third-party agenta
• cloudowe sesje third-party agenta

Cloud wymaga dodatkowego włączenia po stronie konta Copilot i polityk. Lokalny wariant bywa zależny od rozszerzenia providera.

To ma znaczenie zarówno dla możliwości, jak i dla trust modelu.

Permission modes nadal mają znaczenie

Na przykładzie Claude Agent dokumentacja pokazuje różne tryby pracy:

• automatyczna edycja
• request approval
• plan

To dobry reminder: nawet jeśli agent pochodzi od partnera, nadal musisz myśleć kategoriami zakresu zaufania i nadzoru.

Nie ma tu żadnej magii bezpieczeństwa tylko dlatego, że agent nie jest wbudowany.

Plugin to paczka capability, nie pojedyncza funkcja

Agent plugin może zawierać kilka różnych rzeczy naraz:

• slash commands
• skills
• custom agents
• hooks
• MCP servers

To bardzo wygodny model dystrybucji. Jednym pluginem możesz spakować cały workflow domenowy.

Ale to oznacza też, że oceniasz nie pojedynczy feature, tylko cały bundle możliwości.

Marketplace i install from source dają wygodę, ale podnoszą próg review

Plugin możesz znaleźć przez @agentPlugins, zainstalować z marketplace albo bezpośrednio z repozytorium Git.

To jest świetne dla eksperymentów i dzielenia się workflow. Jednocześnie docs wyraźnie ostrzegają, że plugin może zawierać hooki i MCP servers uruchamiające kod na Twojej maszynie.

Czyli każda wygoda instalacji powinna iść w parze z review źródła i zawartości pluginu.

Third-party agents i pluginy rozwiązują inne problemy

To najlepszy filtr decyzyjny:

• third-party agent: gdy chcesz inny model agentowy i inne mocne strony providera
• plugin: gdy chcesz dostarczyć albo zainstalować gotowy pakiet workflow i customizations

Jeśli pomylisz te warstwy, zaczniesz szukać pluginu tam, gdzie tak naprawdę potrzebujesz innego agenta, albo odwrotnie.

Settings też są częścią ekosystemu

W settings reference pojawiają się ważne przełączniki:

• chat.plugins.enabled
• chat.plugins.marketplaces
• chat.pluginLocations

To są ustawienia, które faktycznie kontrolują zasięg ekosystemu pluginów. Dobrze o nich pamiętać, bo pozwalają trzymać porządek między oficjalnym marketplace, lokalnym pluginem i eksperymentami zespołowymi.

Najzdrowszy model: rozszerzaj tylko tam, gdzie naprawdę zyskujesz

Nie każda różnica między providerami albo każdy community plugin jest wart dodatkowej powierzchni zaufania.

W praktyce warto pytać:

• czy daje nową zdolność, której nie mam dziś w VS Code
• czy upraszcza workflow zespołu, a nie tylko mnoży konfigurację
• czy rozumiem, co ten komponent wnosi do mojego modelu bezpieczeństwa

Kluczowe wnioski

• Third-party agents i agent plugins to dwa różne poziomy ekosystemu.
• Third-party agent zmienia silnik i zachowanie agenta, plugin dostarcza pakiet customizations.
• Najważniejsze decyzje dotyczą trustu, źródła i realnej wartości dodanej, nie samej nowości funkcji.
• Rozszerzanie ekosystemu ma sens tylko wtedy, gdy zwiększa capability bez niepotrzebnego chaosu i ryzyka.

Co dalej

Zostaje ostatni element tego modułu: Copilot CLI. Czyli jak przenieść pracę agenta do background sessions i terminalowego workflow, zamiast trzymać wszystko w jednej lokalnej sesji w edytorze.