DeepSeek Super-agent: czym są chmurowi agenci kodujący i gdzie się plasują

Wśród narzędzi dla programistów upowszechnił się nowy nawyk: zlecić zadanie w jakimś miejscu — Issue, wzmiance na czacie albo polu promptu — zamknąć laptopa, a potem wrócić do utworzonej przez agenta gałęzi lub pull requesta. GitHub, Cursor, OpenAI, Anthropic, Cognition i xAI oferują już własne wersje takich rozwiązań pod nazwami takimi jak agent chmurowy, agent działający w tle, sesja chmurowa czy autonomiczny inżynier oprogramowania. W tym artykule wyjaśniamy tę kategorię: co właściwie robią te produkty, jak przebiega ich cykl pracy, z czego trzeba zrezygnować i jakie miejsce zajmuje wśród nich open source’owy prototyp Super-agent od DeepSeek.

Czym jest chmurowy agent kodujący

To szerokie pojęcie, dlatego warto wymienić trzy elementy wspólne dla wszystkich produktów z tej kategorii:

• Wyzwalacz, który nie wymaga otwartego edytora. Zadanie może pojawić się jako przypisane Issue, wzmianka @ w Slacku lub Feishu, prompt w aplikacji internetowej, wywołanie API albo przekazanie z CLI.
• Środowisko poza Twoim komputerem. Agent klonuje repozytorium, instaluje potrzebne elementy i pracuje w piaskownicy lub przestrzeni roboczej zarządzanej przez dostawcę albo Twoją organizację.
• Wynik, który można sprawdzić. Na koniec otrzymujesz gałąź, diff, roboczy PR albo komentarz — coś, co człowiek może przejrzeć i wykorzystać.

To odróżnia tę kategorię od dwóch pokrewnych. Lokalny agent IDE działa na laptopie, gdy go obserwujesz; asystent czatowy odpowiada na pytania, nie ingerując w repozytorium. Chmurowy agent kodujący plasuje się pomiędzy nimi: ma dostęp do prawdziwych narzędzi i lokalnego checkoutu repozytorium, ale zakłada się, że człowiek odejdzie od komputera.

Słowo bot opisuje czatową odmianę tej samej koncepcji. Zamiast przypisywać Issue, oznaczasz agenta w Slacku, Teams lub Feishu. Zmienia się wyzwalacz, ale zdalne środowisko pozostaje takie samo. Wynikiem może być PR, diff albo zestaw gotowych plików.

Mapa produktów

Sześć produktów, opisanych zgodnie z tym, jak przedstawiają je ich dostawcy:

Grok Bot to najszersza pozycja na liście: xAI opisuje go jako stale dostępnego współpracownika AI, którego można uruchomić z poziomu czatu na komputerze lub urządzeniu mobilnym albo przez wzmiankę @bot na X, gdy konta są połączone. Działa na maszynie w chmurze przypisanej do konta i hostowanej przez Cursor, z dostępem do przeglądarki, pamięci masowej i wiersza poleceń. Dokumentacja opisuje gotowe pliki i wersje robocze, a nie pracę z repozytorium; nie wspomina o tworzeniu gałęzi ani PR-ów. To lokuje go po stronie botów.

Większe znaczenie niż sama tabela mają cztery różnice:

Gdzie znajduje się wyzwalacz. GitHub Copilot cloud agent i OpenAI Codex Cloud zaprojektowano z myślą o pracy, która już toczy się w GitHubie lub aplikacji ChatGPT. Cursor Cloud Agents i Devin stawiają na czat: wątek w Slacku lub Teams jest punktem wejścia. Claude Code cloud sessions przyjmują wyzwalacz z przeglądarki, telefonu, aplikacji desktopowej lub terminala za pomocą claude --cloud, a także mogą działać według harmonogramu.

Jak wiele informacji udostępnia dostawca. Claude Code szczegółowo opisuje izolację: w środowiskach hostowanych przez Anthropic każda sesja działa na odizolowanej maszynie wirtualnej, dostęp do sieci jest domyślnie ograniczony, a dane uwierzytelniające Git pozostają poza piaskownicą — w imieniu sesji uwierzytelnia się pośredniczący serwer proxy. Organizacje mogą zamiast tego kierować sesje do środowiska hostowanego samodzielnie; wówczas odpowiadają za jego izolację. Sesje chmurowe korzystają z limitów zapytań w ramach Twojego planu i nie wiążą się z osobną opłatą za maszynę wirtualną; wymagają zalogowania do claude.ai i nie są dostępne, gdy Claude Code skonfigurowano do pracy z Amazon Bedrock, Agent Platform w Google Cloud lub innym zewnętrznym dostawcą. Pozostali dostawcy ujawniają mniej szczegółów technicznych; „piaskownica” lub „maszyna wirtualna” często wyczerpuje zakres publicznego opisu.

Do czego agent może uzyskać dostęp. Niektóre produkty ograniczają się do jednego repozytorium, inne deklarują obsługę pracy w całej organizacji lub w wielu repozytoriach. To pierwsza rzecz, którą należy sprawdzić w kontekście własnej konfiguracji, bo agent o dużych możliwościach, ale z niewłaściwym zakresem dostępu do repozytoriów, jest albo bezużyteczny, albo niebezpieczny.

Do jakiego rodzaju pracy służy. Większość produktów na tej liście zajmuje się kodowaniem w określonym repozytorium. Grok Bot to uniwersalny współpracownik działający w chmurze: jego dokumentacja opisuje pliki i wersje robocze, a nie pracę z repozytorium. Traktuj określenie „agent chmurowy” jako spektrum, a nie jeden konkretny rodzaj produktu.

Jak przebiega cykl pracy

Gdy odrzucić marketingowe nazwy, cykl pracy wygląda podobnie we wszystkich produktach:

1. Przyjęcie zadania. Pojawia się wyzwalacz. Produkt ustala, czy chodzi o rzeczywiste zadanie, czasem zadaje pytanie doprecyzowujące, a następnie umieszcza zadanie w kolejce sesji.
2. Środowisko. Agent klonuje repozytorium z właściwej gałęzi, uruchamia skrypt konfiguracyjny lub obraz i instaluje łańcuch narzędzi. Dostęp do sieci i dane poufne konfiguruje się na tym etapie, a nie później.
3. Praca. Agent czyta kod, edytuje pliki, uruchamia testy i polecenia, a czasem otwiera przeglądarkę. Długotrwałe zadania są kontynuowane, nawet gdy laptop przechodzi w tryb uśpienia.
4. Wynik. Agent wysyła gałąź i otwiera PR albo pozostawia diff oraz pisemne podsumowanie. Niektóre produkty tworzą robocze PR-y, ponieważ oczekuje się, że agent zatrzyma się przed scaleniem.
5. Przegląd. Człowiek czyta diff, dodaje komentarze i albo scala zmiany, prosi o poprawki, albo przenosi pracę z powrotem do sesji lokalnej. Niektóre produkty mogą też monitorować PR i wysyłać poprawki, gdy CI zakończy się niepowodzeniem.

Problemy kryją się w etapach 2 i 5. Skrypt konfiguracyjny, którego uruchomienie trwa zbyt długo, repozytorium, którego agent nie może sklonować, polityka sieciowa blokująca rejestr pakietów albo dane uwierzytelniające niedostępne w piaskownicy — każdy z tych problemów może zatrzymać zadanie, które wydawało się proste. A „wynik, który można sprawdzić” nadal oznacza, że człowiek musi go przejrzeć: żaden z tych produktów nie eliminuje etapu przeglądu, tylko przenosi samo pisanie kodu.

Dlaczego ta fala nadchodzi właśnie teraz

Muszą współistnieć trzy warunki. Modele stały się wystarczająco niezawodne, by obsługiwać długie cykle pracy z narzędziami bez ciągłego nadzoru. Piaskownice i skrypty konfiguracyjne stały się na tyle tanie, że każde zadanie może mieć własne środowisko. A pull request stał się domyślnym interfejsem między agentem a osobą przeglądającą zmiany, więc zespoły nie musiały wymyślać nowego procesu przeglądu.

Znaczenie ma też kwestia uwagi. W eseju towarzyszącym projektowi DeepSeek przedstawia to wprost: ograniczeniem pojedynczego zadania są możliwości modelu, ale ograniczeniem liczby zadań, które człowiek może wykonać, jest jego uwaga. Agent chmurowy przejmuje zarządzanie sesjami, przełączanie kontekstu i oczekiwanie. To teza z eseju DeepSeek, a nie wniosek z niezależnego badania, ale wyjaśnia, dlaczego ta kategoria wydaje się użyteczna.

Z czego trzeba zrezygnować

Każdy hostowany produkt wymienia kontrolę na wygodę:

• Granica zaufania. Twój kod, a czasem również dane uwierzytelniające, opuszczają Twój komputer. Dostawcy publikują różny zakres informacji o izolacji, przechowywaniu danych i dostępie do sieci; sprawdzaj je osobno dla każdego produktu, zamiast zakładać, że cała kategoria działa tak samo.
• Izolacja. Zarządzana maszyna wirtualna ma odizolować agenta, ale nadal działa w środowisku dostawcy. „Piaskownica” może oznaczać wszystko — od wzmocnionej maszyny wirtualnej po kontener z szerokim dostępem do sieci.
• Możliwości dostosowania. Hostowane agenty udostępniają ustawienia, a nie kod źródłowy. Jeśli Twój przepływ pracy wymaga innego wyzwalacza, innej zasady przeglądu lub innego modelu, ograniczają Cię możliwości oferowane przez produkt.
• Model kosztów. Większość tych produktów jest rozliczana w ramach subskrypcji lub planu z limitami użycia; czas pracy agenta nie jest pozycją kosztową, którą możesz bezpośrednio kontrolować. Planuj budżet według planu, a nie liczby tokenów.
• Zakres i uzależnienie od dostawcy. Obsługa wielu repozytoriów, integracje czatowe i mechanizmy kontroli dla przedsiębiorstw różnią się zależnie od dostawcy, a przeniesienie przepływu pracy z jednego produktu do drugiego nie jest darmowe.

Wariant hostowany samodzielnie: Super-agent DeepSeek

Premiera DeepSeek jest interesująca, bo stawia pytanie, jak wyglądałby ten sam cykl pracy, gdyby warstwa sterująca pozostała pod Twoją kontrolą. Repozytorium zawiera wtyczkę TypeScript na licencji MIT dla DeepSeek Harness (DSH), w wersji 0.1.0, opublikowaną jako prototyp badawczy. README jasno informuje, że wtyczka została dostosowana do publikacji, nie jest identyczna z wersją używaną wewnętrznie przez DeepSeek i nie realizuje wszystkich pomysłów z eseju projektowego.

Rozwiązanie opiera się na długotrwałej sesji Router oraz osobnej sesji Worker dla każdego zgłoszenia. Zdarzenia przechodzą przez etapy Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Zespół autoryzuje pracę za pomocą polityki; akceptowane są jawne wzmianki @ od dozwolonych osób, natomiast praca proaktywna zaczyna się w trybie observe, który rejestruje, co agent by zrobił, nie otwierając zgłoszeń. Każdy Ticket ma własną sesję i katalog; polecenie przygotowujące może utworzyć dla niego osobne drzewo robocze Git.

Model działania jest przeciwieństwem piaskownicy dostawcy. System nasłuchuje jednego repozytorium github.com (bez GitHub Enterprise Server) i opcjonalnie Feishu. Zarówno ustawienia Router, jak i Worker uruchamiają się z danger-full-access jako użytkownik systemu operacyjnego operatora; nakładki na konta wybierają dane uwierzytelniające agenta, ale nie izolują procesu. W przewodniku wdrożeniowym zaleca się użycie dedykowanego konta systemowego, które przechowuje wyłącznie dane uwierzytelniające agenta. Stan jest przechowywany w SQLite w lokalizacji skonfigurowanej jako stateDir. Filozofię projektu streszcza założony cel: jak najmniej angażować uwagę człowieka i dostarczać jak najwięcej wartości.

W eseju przedstawiono wyniki planowania z syntetycznego obciążenia — około 300 wiadomości i 20 próśb o wykonanie pracy, symulowane narzędzia, pięć uruchomień — z p50/p95 na poziomie około 12.4 / 15.7 minuty, w porównaniu z około 29.5 minuty p95 dla bazowego rozwiązania z pojedynczą sesją, które nie wywoływało podagentów. Są to własne pomiary DeepSeek przeprowadzone z symulowanymi narzędziami, a nie wyniki niezależnego benchmarku jakości kodowania.

Prototyp nie tyle zapowiada nowy produkt, ile pokazuje coś węższego i bardziej użytecznego: agent kodujący uruchamiany przez zdarzenia, który na końcu wymaga przeglądu, nie musi działać wyłącznie w chmurze dostawcy. Możesz samodzielnie zarządzać orkiestratorem, stanem i wyborem modelu. Pokazuje też jednak, ile kosztuje taka niezależność: musisz uruchamiać proces, zabezpieczyć konto i zaakceptować, że prototyp domyślnie nie ma piaskownicy.

Kto powinien wybrać którą opcję

Pozostań przy hostowanym agencie chmurowym, jeśli zależy Ci na braku obowiązków operacyjnych, piaskownicy zarządzanej przez dostawcę, obsłudze wielu repozytoriów lub organizacji oraz możliwości uruchamiania zadań z poziomu GitHub, Slacka, Teams lub aplikacji internetowej. Dostawca odpowiada za izolację i dostępność.

Rozważ samodzielnie hostowany prototyp, jeśli kod nie może opuścić Twojej infrastruktury, musisz modyfikować orkiestrację lub chcesz dobierać model do każdej roli. Zaplanuj budżet na dedykowaną maszynę lub konto systemu operacyjnego i traktuj kod jak oprogramowanie badawcze.

Praktyczne połączenie: hostowani agenci do rutynowych zadań w repozytoriach, a samodzielnie hostowany agent tylko w repozytoriach, w których istotna jest granica dostępu do danych. W obu przypadkach etap przeglądu wygląda tak samo.

Kilka słów o modelach

Prototyp nie ma na stałe przypisanego modelu. Korzysta z domyślnego profilu Harness, chyba że ustawienia Eval lub Execution go nadpiszą, więc zespół może przypisać lżejszy model do Routera, a mocniejszy do Workerów. AIHubMix łączy DeepSeek Harness przez punkt końcowy zgodny z OpenAI pod adresem https://aihubmix.com/v1; przykład w przewodniku DeepSeek Harness wykorzystuje dostawcę aihubmix i model auto. Przewodnik omawia podstawowe połączenie z DSH, a nie wtyczkę Super-agent; opisane wyżej hostowane produkty samodzielnie zarządzają wyborem modeli.

FAQ

Czym jest chmurowy agent kodujący?
To oprogramowanie, które przyjmuje zadanie programistyczne z issue, wzmianki na czacie lub wywołania API, wykonuje je w środowisku poza Twoim komputerem i zwraca gałąź, diff lub pull request do przeglądu.

Czy to to samo co lokalny agent kodujący?
Nie. Lokalny agent działa w terminalu lub IDE, gdy go obserwujesz. Agent chmurowy pracuje dalej po zamknięciu laptopa i jest przeznaczony do późniejszego przeglądu.

Czy nadal trzeba przeglądać kod?
Tak. Każdy opisany tu produkt kończy pracę diffem lub PR-em, który musi przejrzeć człowiek. Agent przejmuje pisanie kodu, ale nie podejmowanie decyzji o jego akceptacji.

Gdzie uruchamiany jest Twój kod?
W środowisku dostawcy. Szczegóły są różne: Copilot opisuje piaskownicę w chmurze lub środowisko Actions, Cursor — izolowane maszyny wirtualne, Codex — obszar roboczy w chmurze, Claude Code — izolowaną maszynę wirtualną zarządzaną przez Anthropic lub środowisko hostowane samodzielnie przez organizację, a Devin — obszar roboczy z terminalem, edytorem i przeglądarką. Zanim powierzysz któremuś z nich prywatny kod, zapoznaj się z dokumentacją bezpieczeństwa dostawcy.

Czym jest bot kodujący?
To wersja tej samej koncepcji obsługiwana przez czat: zamiast przypisywać issue, wspominasz agenta w Slacku, Teams lub Feishu. Nadal działa on w zdalnym środowisku; wynikiem może być PR lub diff albo — w przypadku uniwersalnego współpracownika, takiego jak Grok Bot — gotowe pliki i wersje robocze.

Co wnosi Super-agent od DeepSeek?
To hostowana samodzielnie implementacja na licencji MIT, realizująca tę samą pętlę działania, z architekturą Router–Worker, modelem polityk i zgłoszeń oraz opcjonalną integracją z Feishu. To prototyp badawczy, a nie hostowany produkt.

Czy nadaje się do środowiska produkcyjnego?
Nie. Plik README określa go jako kod badawczy, gotowe konfiguracje działają z danger-full-access, a domyślnie nie ma piaskownicy. Jeśli zdecydujesz się go wypróbować, użyj dedykowanego konta systemu operacyjnego i dedykowanego konta agenta w GitHub.

Źródła

1. deepseek-ai/dsh-superagent-prototype — plik README, przywołany w nim esej projektowy oraz dokumenty docs/000–008
2. Połącz DeepSeek Harness z AIHubMix — AIHubMix
3. Chmurowy agent GitHub Copilot — dokumentacja GitHub
4. Agenci chmurowi Cursor — dokumentacja Cursor
5. Codex Cloud — ChatGPT Learn / OpenAI
6. Claude Code w chmurze — Anthropic
7. Dokumentacja Devin — Cognition
8. Dokumentacja Grok Bot — xAI