DeepSeek opublikował dsh-superagent, prototypowy projekt badawczy na licencji MIT, przedstawiany jako proaktywny agent programistyczny przeznaczony dla pojedynczego repozytorium GitHub. Zapakowany dla DeepSeek Harness, nasłuchuje on GitHub i opcjonalnie Feishu, a następnie przekształca autoryzowane żądania w zadania równoległe, każde w swojej własnej sesji agenta.
- DeepSeek udostępnia dsh-superagent, prototyp na licencji MIT, który pracuje nad jednym repozytorium GitHub.
- Agent otwiera Ticket dla każdego żądania uprawnionej osoby i wykonuje go w odrębnej sesji.
- Architektura Router-Worker oddziela zarządzanie komunikacją od wykonywania pracy, aby ograniczyć potrzebę uwagi człowieka.
- Wyniki symulacji są samodzielnie zgłoszone, nie mierzono jakości kodu, a agent działa z pełnymi uprawnieniami użytkownika, więc wymaga izolacji.
Agent czekający na wezwanie
Działanie opiera się na pojęciu Ticket, jednostki pracy otwieranej, gdy uprawniona osoba zwraca się do agenta. Każdy Ticket wykonuje się w swojej własnej sesji i własnym katalogu, a wyniki wracają do oryginalnej konwersacji, często w formie pull request, czyli propozycji zmiany kodu zgłoszonej do recenzji. Lokalny interfejs webowy wyświetla tylko elementy wymagające interwencji człowieka.
README projektu ustala prostą zasadę: minimalizować uwagę ludzką przy maksymalizacji dostarczanej wartości. Zgodnie z dokumentem filozofii projektu, agent prosi o potwierdzenie tylko raz, pozostaje cichy podczas pracy i odzywa się ponownie tylko z wynikiem, pytaniem lub informacją o niepowodzeniu.
Architektura Router-Worker
Według zespołu, typowe agenty traktują sesję jako jednostkę podstawową. Według raportu cytowanego przez ifeng, osoba może aktywnie śledzić tylko 3 do 5 sesji jednocześnie, przez co uwaga ludzka, a nie możliwości modelu, staje się czynnikiem ograniczającym pracę równoległą. Proponowana architektura ma dwie warstwy: długotrwały Router zarządza komunikacją i dystrybucją zadań, podczas gdy izolowane sesje Worker wykonują rzeczywistą pracę.
Model domenowy opisuje precyzyjny ciąg zdarzeń: GitHub lub Feishu generują zdarzenia, zwane Triggerami; etap oceny decyduje, czy partia Triggerów wymaga nowej pracy; każdy Ticket niesie niezmienny Mandate, który określa, dlaczego może być wykonany; wreszcie, późniejsze komentarze w pull request są kierowane do właściwego Workera bez nowego oznaczenia. Polecenia shell przechodzą w tło po 5 sekundach, aby Workers nadal otrzymywali wiadomości. Praca proaktywna jest ograniczona trzema trybami: off, observe (domyślny) i auto. W trybie observe agent jedynie rejestruje, co by zaakceptował.
Wyniki z symulacji
DeepSeek przetestował system na symulowanych strumieniach dyskusji grupowych i CI GitHub, z około 300 wiadomościami na próbę, w tym około 20 rzeczywistymi żądaniami pracy, przy czym każda konfiguracja była uruchamiana 5 razy. Super-agent wykazuje p50 na poziomie 12,4 minuty i p95 na poziomie 15,7 minuty, w porównaniu do p95 wynoszącego 29,5 minuty dla pojedynczej sesji z pod-agentami i neutralnym promptem, dla której nie podano p50. W tej konfiguracji referencyjnej pod-agent nie został wywołany ani razu w 5 próbach.
Według tych samych danych, gdy liczba napływających żądań wzrosła z około 1 do 40 na minutę, rozmiar partii wzrósł z 1,0 do 2,8, a opóźnienie na żądanie z 2,5 do 3,9 sekundy. Dane te są samodzielnie zgłoszone przez DeepSeek i pochodzą z wtórnych sprawozdań w raporcie. Projekt zaznacza ponadto, że był testowany tylko na syntetycznych wiadomościach i symulowanych narzędziach, a rzeczywista jakość generowanego kodu nie była mierzona.
Do instalacji prototyp wymaga Node.js 22.19+ lub 24+, git 2.32+, Python 3.8+, tmux i GitHub CLI 2.48+. Repozytorium wskazuje również, że agent działa z pełnymi uprawnieniami użytkownika systemu operacyjnego, co wymaga jego izolacji przed jakimkolwiek użyciem.
