DeepSeek otwiera prototyp Super-agenta: Router, Worker, Watchdog

• DeepSeek Harness opublikował wieczorem 31 października opis Super-agenta i prototyp dsh-superagent-prototype na GitHubie, na licencji MIT.
• Stały Router przyjmuje wiadomości i tylko rozdziela zadania. Izolowane sesje Worker robią robotę równolegle i odpowiadają na przykład pull requestem.
• Zewnętrzna sesja Watchdog sprawdza, czy Worker naprawdę posuwa zadanie do przodu.
• Wyniki testów są wstępne i pochodzą z obciążenia syntetycznego. README zastrzega, że to kod badawczy, a nie oficjalny produkt DeepSeek.

Zespół DeepSeek Harness wieczorem 31 października opublikował opis tego, co nazywa Super-agentem: agenta, który działa non stop, prowadzi kilka zadań naraz, sam szuka pracy i podnosi się po awariach. Razem z opisem wypuścił prototyp badawczy na GitHubie, na licencji MIT. Zespół podaje też własne, wstępne pomiary. Dla większości z nas to na razie podgląd tego, w którą stronę idą agenci kodujący, a nie narzędzie do wdrożenia w poniedziałek.

Recepcja, która nie rusza klucza: jak DeepSeek dzieli pracę agenta

Repozytorium dsh-superagent-prototype to proaktywny agent kodujący dla jednego repozytorium GitHub, spakowany jako bundle dla DeepSeek Harness. Nasłuchuje GitHuba i opcjonalnie komunikatora Feishu. Gdy dozwolony użytkownik poprosi o pracę, agent otwiera zadanie i obsługuje je we własnej sesji i własnym katalogu. Odpowiedź (na przykład pull request) wysyła z powrotem do rozmowy, w której padła prośba.

Sedno to dwie warstwy. Router to stała sesja, która przyjmuje całą rozmowę z ludźmi ze wszystkich kanałów. Niczego sama nie robi, tylko rozdziela zadania. Zespół pisze, że Router może nie mieć nawet narzędzia Bash. To recepcja w warsztacie, której nie wolno dotknąć klucza, ale która wie, do którego mechanika wysłać auto.

Workery to izolowane sesje z pełnym zestawem narzędzi. Pracują równolegle i raportują do Routera, zamiast rozmawiać z użytkownikami. Każdy Worker subskrybuje wątki, na których mu zależy, na przykład konkretny pull request albo temat czatu. Kolejne zdarzenia trafiają od razu do niego, z pominięciem Routera. To po prostu podział ról.

Agent, który po cichu odtwarza błąd i odzywa się z gotową poprawką

System jest sterowany zdarzeniami. Wyzwalaczami są wiadomości na czacie, e-maile, komentarze z review i wyniki CI (automatycznych testów kodu). Najpierw filtruje je deterministyczny kod, czyli zwykłe reguły bez modelu, a dopiero potem model. Prosty filtr odsiewa to, co da się odsiać regułą, a model ocenia resztę.

Zespół oddziela też stan agenta od środowisk wykonawczych. Dzięki temu agent może działać w chmurze i jednocześnie sięgać do maszyn użytkownika. Do tego dochodzi zewnętrzna sesja Watchdog, która sprawdza, czy Workery realnie robią postępy, a nie tylko wyglądają na zajęte. Podobny kierunek (agent, który deleguje pracę dalej) opisywaliśmy przy okazji tekstu o tym, jak DeepSeek Harness zleca zadania Codex i Claude Code.

Najciekawszy jest wątek z wewnętrznej grupy użytkowników zespołu. Jedna instancja agenta działa tam według reguły: po cichu odtwarzaj zgłoszone błędy i odezwij się dopiero, gdy masz prostą poprawkę. Czasem otwiera pull request, zanim ktokolwiek ją oznaczy. To opis jednej grupy i jednej reguły, a nie dowód, że agent sam ogarnia każdy bug. Szerzej o tym, dlaczego to system wokół modelu decyduje o jakości takiego agenta, piszemy w tekście o harness engineering.

Liczby z testów: wstępne, syntetyczne i z haczykiem

Najpierw deklaracja zespołu, potem wynik. W wstępnych testach na syntetycznym obciążeniu (około 300 wiadomości i około 20 zleceń) Super-agent skończył połowę zadań w 12,4 minuty, a 95% w 15,7 minuty. Był przy tym szybszy niż pojedyncza sesja z narzędziem subagenta, ale kosztem większej liczby tokenów z cache. Szybciej, lecz nie za darmo.

Dwie inne liczby pokazują, po co jest bezpośrednie kierowanie zdarzeń do Workerów. Bez niego liczba decyzji Routera rosła o około 30%. Z kolei batching (łączenie decyzji w paczki) pod obciążeniem skrócił czas wnioskowania na jedną decyzję Routera z 6,4 do 1,6 sekundy. Sam zespół nazwał te wyniki wstępnym punktem odniesienia. Test był syntetyczny, więc nic tu nie mówi o tym, jak agent poradzi sobie w Twoim repozytorium.

Co zespół sam uznaje za nierozwiązane

• skalowanie Routera,
• pamięć długoterminowa,
• komunikacja między agentami,
• ryzyko prompt injection, gdy agent w chmurze ma dostęp do poświadczeń na urządzeniach lokalnych.

Ostatni punkt jest najbardziej przyziemny. Prompt injection to podrzucenie agentowi instrukcji ukrytej w treści, którą czyta. Agent z kluczami do Twoich maszyn to wygodny cel. Pokazywał to już przypadek, który opisaliśmy w tekście o AGENTS.md w Download. Zespół nie podał terminu, kiedy cokolwiek z tego trafi do oficjalnego produktu DeepSeek. README mówi wprost, że to kod badawczy, a część rozwiązań z opisu nie jest zaimplementowana.

Werdykt: jeśli nie programujesz, nie musisz czytać kodu z GitHuba. Z tego prototypu da się za to wyciągnąć wzór myślenia o automatyzacji, który działa także w zwykłej firmie. Nie musisz wiedzieć, jak działa CI. Wystarczy, że znasz własne wyzwalacze pracy. Weź kartkę i wypisz pięć rzeczy, które zwykle uruchamiają Twoją robotę (mail od klienta, komentarz pod dokumentem, wiadomość na czacie zespołu). Przy każdej dopisz „reguła”, jeśli da się ją rozpoznać prostym warunkiem, na przykład po nadawcy albo słowie w temacie, albo „ocena”, jeśli trzeba pomyśleć. Dziesięć minut i zobaczysz, ile z Twojej pracy to filtr, a ile osąd. Dokładnie taki podział DeepSeek zaszył w swoim agencie. Jeśli ciekawi Cię, jak podobne ryzyka i podział ról wyglądają w polskiej firmie, zajrzyj do historii o tym, jak PKO BP i agenci AI dzielą decyzje między człowieka a bramkę.