DeepSeek udostępnia dsh-superagent, prototyp agenta kodującego z routerem i workerami

31 października zespół DeepSeek Harness opublikował na oficjalnym koncie WeChat artykuł „Exploring Super-agent Design: Towards a More Autonomous Agent System”. Jak relacjonuje Yicai, DeepSeek twierdzi, że dominujące dziś konstrukcje agentów nie radzą sobie z wieloma zadaniami naraz i z pracą zespołową, bo limit wyznacza ludzka uwaga. Razem z tekstem pojawiło się repozytorium dsh-superagent-prototype na licencji MIT. Repozytorium opisał też The Next Web. W maju pisaliśmy o powstaniu zespołu Harness i projekcie autonomicznego programisty.

Router i workerzy zamiast jednej sesji

Punkt wyjścia jest prosty: większość agentów traktuje jedną sesję jako podstawową jednostkę pracy, a człowiek potrafi aktywnie śledzić ich naraz 3–5. DeepSeek proponuje architekturę dwuwarstwową. Długo działający Router odpowiada za interakcję i rozdzielanie zadań, a izolowane sesje Worker wykonują właściwą robotę. System ma przejąć żmudne zarządzanie sesjami i synchronizację kontekstu, żeby człowiek zajmował się decyzjami i odbiorem wyników. Wśród rozwiązań DeepSeek wymienia też architekturę zdarzeniową, asynchroniczną komunikację wieloma kanałami, rozdzielenie pamięci i obliczeń oraz zewnętrzny Watchdog. W opisie koncepcji DeepSeek wymienia również pomysły wykraczające poza obecny prototyp.

Sam prototyp to pakiet w TypeScripcie (v0.1.0) dla DeepSeek Harness, obsługujący jedno repozytorium GitHub. Opcjonalnie podłącza się do komunikatora Feishu. Gdy uprawniona osoba zwróci się do agenta, powstaje Ticket, czyli jednostka autoryzowanej pracy z niezmiennym Mandate, który uzasadnia, dlaczego agent może działać. Każdy Ticket dostaje własną sesję i katalog, a wynik wraca do pierwotnej rozmowy, często jako pull request. Późniejsze komentarze do PR trafiają do właściwego workera bez ponownego oznaczania agenta. Lokalny panel WWW pokazuje wyłącznie sprawy wymagające człowieka.

Agent ma potwierdzić przyjęcie zadania raz, milczeć w trakcie pracy i odezwać się dopiero z wynikiem, pytaniem lub informacją o błędzie. Samodzielne podejmowanie zadań jest domyślnie wyłączone w praktyce. Tryby akceptacji to off, observe i auto. W domyślnym observe agent tylko zapisuje, co by przyjął.

Według DeepSeeka wewnętrzna instancja Super-agenta działa już na co dzień: pomaga w odtwarzaniu i naprawianiu błędów, odpowiada na uwagi z code review i uczestniczy w rozwoju samego Harnessa. Gdy ktoś w czacie zespołu opisze problem, agent potrafi rozpoznać prawdopodobny błąd bez wywołania, spróbować go odtworzyć w tle i poszukać poprawki.

Wyniki z symulacji

Testy opisane w artykule DeepSeeka polegały na symulowanym strumieniu wiadomości z czatu grupowego i GitHub CI. Jedno uruchomienie obejmowało ok. 300 wiadomości, z czego ok. 20 było prawdziwymi prośbami o pracę. Każdy wariant uruchomiono pięciokrotnie.

• Super-agent: mediana czasu ukończenia zadań 12,4 min, p95 15,7 min.
• Pojedyncza sesja z subagentami (neutralny prompt): p95 29,5 min, czyli około 1,9 raza dłużej.
• Router przy wzroście ruchu z ok. 1 do 40 zgłoszeń na minutę: rozmiar paczki zdarzeń rósł z 1,0 do 2,8, a opóźnienie na zgłoszenie z 2,5 do 3,9 s.

Przewaga ma haczyk. Przy neutralnym prompcie wariant bazowy ani razu nie uruchomił subagenta w pięciu przebiegach. Porównanie pokazuje więc raczej koszt nieskorzystania z równoległości niż klasę rozwiązania. Wszystkie liczby pochodzą od DeepSeeka. Testy DeepSeeka obejmowały wyłącznie syntetyczne wiadomości i symulowane narzędzia, bez pomiaru jakości kodu.

Uruchomienie i ryzyka

Agent działa lokalnie jako osobny profil Harnessa. Dokumentacja wdrożeniowa wymaga Node.js 22.19+ lub 24+, git 2.32+, Pythona 3.8+, tmuxa i GitHub CLI 2.48+. Model bierze z konfiguracji profilu. Marktechpost ostrzega, że agent ma pełny dostęp na poziomie użytkownika systemu, więc przed uruchomieniem warto go odizolować.