Najlepsze wtyczki do DeepSeek Harness na serwer VPS

Które wtyczki DeepSeek Harness warto zainstalować

Wtyczki DeepSeek Harness to kod firm trzecich, który działa wewnątrz agenta, z jego uprawnieniami, na opłacanej przez użytkownika maszynie. Lista społecznościowa obejmuje ponad dwadzieścia kategorii i przeszło tysiąc pozycji. Na wynajętym serwerze wirtualnym (VPS) niezbędnych jest pięć: dsh-budget do limitów wydatków, dsh-permission-rules do kontroli dostępu do narzędzi, dsh-defend do skanowania pod kątem iniekcji i sekretów, dsh-memory do faktów utrzymujących się po zakończeniu sesji oraz dsh-web-lan-access, ale dopiero po ustaleniu metody uwierzytelniania.

Harness to dsh, otwartoźródłowy szkielet agenta DeepSeek, zaprojektowany tak, aby każdy element był wtyczką. Własny plik README określa go jako wersję poglądową dla programistów i ostrzega THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Ten jeden fakt determinuje każdy z poniższych wyborów. Przypinaj wersje instalowanych wtyczek, licz się z tym, że aktualizacja może je uszkodzić i ogranicz ich liczbę na tyle, aby móc w całości przejrzeć ich kod. Jeśli szkielet jeszcze nie działa, zacznij od instalacji DeepSeek Harness na VPS i wróć tutaj. Jeśli elementy, do których podpinają się te wtyczki – pętla agenta, jego narzędzia, pamięć – są nadal niejasne, najpierw zapoznaj się z podstawami, ponieważ każdy z poniższych wyborów łatwiej ocenić, znając działanie poszczególnych warstw.

Sposób instalacji wtyczki przez dsh oraz lokalizacja konfiguracji

dsh składa się z wtyczek Cordis, dlatego uruchomiona instancja jest drzewem wtyczek, a nie pojedynczym programem. Profil to nazwany zestaw tych wtyczek. Dwa szablony to web oraz headless. $DSH_HOME domyślnie przyjmuje ~/.dsh, a profil znajduje się w $DSH_HOME/profiles/<name>/, przechowując własny package.json, manifest dsh.profile oraz cordis.patch.yml.

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

Dostępne są cztery formy źródła: nazwa pakietu npm, nazwa z zakresem (scoped name) taka jak @towzai/dsh-memory, odwołanie do GitHub takie jak github:PerryLink/dsh-budget#main oraz ścieżka lokalna z użyciem link: lub ./. Zaleca się stosowanie formy GitHub, ponieważ pozwala ona zastąpić #main identyfikatorem commitu, co gwarantuje uzyskanie tego samego kodu w przyszłości.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

Warstwy są nakładane w ustalonej kolejności: każdy pakiet zgodnie z kolejnością na liście profilu, następnie cordis.patch.yml profilu, potem cordis.patch.yml na poziomie użytkownika, a na końcu dowolna nakładka --patch. Kolejność ma znaczenie, ponieważ późniejsza warstwa może zmienić konfigurację lub usunąć ustawienia wprowadzone przez warstwę wcześniejszą. Jeśli wtyczka wydaje się zainstalowana, ale nie działa, należy otworzyć cordis.patch.yml profilu i sprawdzić dwie rzeczy: czy blok wstawiania (insert block) istnieje oraz czy żadna późniejsza warstwa go nie wyłącza.

Na dzień 17 sierpnia 2026 pakiet npm @deepseek-ai/dsh znajdował się w wersji 0.1.0-rc.7, podczas gdy poniższe wtyczki zostały zbudowane dla linii 0.1.0-rc. dsh-permission-rules oraz dsh-defend deklarują kompatybilność z 0.1.0-rc.5 do 0.1.0-rc.6, dsh-budget deklaruje wyłącznie 0.1.0-rc.6, dsh-memory ustawia tylko zakresy peer rozpoczynające się od ^0.1.0-rc.6, a dsh-web-lan-access nie deklaruje żadnej wersji dsh. Na dzień 10 października 2026 tag latest w npm to 0.2.0-rc.2, więc rozbieżność jest obecnie większa niż w momencie wyboru tych przypięć wersji. Taka rozbieżność jest typowa dla tego ekosystemu i stanowi najczęstszą przyczynę przestania ładowania się wtyczki: środowisko uruchomieniowe rozwija się szybciej niż otaczające je wtyczki. Należy celowo zaktualizować środowisko, a następnie przetestować wtyczki pojedynczo.

Przeanalizuj wtyczkę przed jej zaufaniem

Wtyczka dsh nie jest odizolowana od środowiska uruchomieniowego (harness). Ładuje się do tego samego drzewa Cordis, w tym samym procesie, jako ten sam użytkownik systemu operacyjnego, mając dostęp do tych samych poświadczeń modelu i tego samego drzewa roboczego. Instalacja wtyczki jest bardziej zbliżona do uruchomienia cudzego skryptu za pomocą sudo niż do dodania rozszerzenia przeglądarki. Jest to ten sam problem zaufania, który podnoszą wtyczki Claude Code, a odpowiedź pozostaje niezmienna: należy przeczytać kod lub zrezygnować z instalacji.

Cztery elementy wymagające sprawdzenia, w podanej kolejności:

• Punkty rozszerzeń, z których korzysta. tools/pre-execute oznacza, że wtyczka widzi każde wywołanie narzędzia i może je zablokować. agent/pre-step oznacza, że wtyczka ma wgląd w wiadomości użytkownika. webServer.tapIndex oznacza, że wtyczka modyfikuje stronę serwowaną w przeglądarce. Wtyczka, która nie korzysta z żadnego z tych punktów, ma bardzo ograniczone możliwości; wtyczka korzystająca ze wszystkich wymienionych stanowi granicę bezpieczeństwa.
• Komunikacja sieciowa. Należy przeszukać kod źródłowy pod kątem fetch, http oraz wszelkich zakodowanych na sztywno nazw hostów. Licznik kosztów, który łączy się z zewnętrznym serwerem, przesyła wzorce użytkowania poza system.
• Odczyt poświadczeń. Każdy element odwołujący się do credentials.* lub klucza dostawcy musi posiadać uzasadnienie w pliku README.
• Licencja i data ostatniego commita. Wtyczka bez licencji, nieaktualizowana od miesięcy w ekosystemie zmieniającym się co tydzień, stanowi ryzyko.

Instalację należy przeprowadzać, wskazując konkretny commit, a nie gałąź, oraz zweryfikować blok wstawiony przez instalator do pliku cordis.patch.yml. Blok ten zawiera identyfikator wtyczki oraz zarejestrowaną konfigurację, co stanowi najbardziej zwięzły i rzetelny opis dodanego komponentu. Należy ograniczać dostęp wtyczki do kluczy dostawcy wszędzie tam, gdzie pozwala na to środowisko uruchomieniowe, zgodnie z zasadami przechowywania sekretów poza agentami AI.

dsh-budget: jak zapobiec całonocnemu zużyciu środków przez agenta?

Agent na serwerze VPS działa bez nadzoru. Jest to główny cel umieszczania go w tym środowisku, ale stanowi również ryzyko. dsh-budget mierzy liczbę tokenów oraz szacowany koszt dla każdego modelu, sesji i dnia, a następnie egzekwuje limity dla tych sum.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

Wartości domyślne są wysokie: 10 USD na sesję, 50 na dzień oraz 500 na miesiąc. Są one odpowiednie dla finansowanych zespołów. Na serwerze osobistym są na tyle wysokie, że zapętlony proces zakończy się, zanim limit zostanie osiągnięty, dlatego należy je obniżyć już pierwszego dnia.

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

Sugerowana kolumna stanowi punkt wyjścia dla jednego operatora na jednej maszynie, a nie oficjalną wytyczną. Należy ją zwiększyć, gdy rzeczywisty miesiąc użytkowania dostarczy odpowiednich danych. Miesięczny limit w wysokości 40 USD z limitem sesji 2 powoduje szybkie i wyraźne przerwanie działania, co jest pożądane podczas nauki zapotrzebowania narzędzia na zasoby.

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

Ustawieniem zmieniającym zachowanie maszyny jest overLimit. Wartością domyślną jest alert, która wyświetla ostrzeżenie i kontynuuje wydatki, co sprawia, że w konfiguracji fabrycznej wtyczka pełni jedynie funkcję panelu informacyjnego. Należy ustawić ją na block, aby mechanizm odmawiał dalszych wywołań modelu po osiągnięciu limitu; dzięki temu zadanie uruchomione w nocy zostanie przerwane, zamiast generować koszty do rana. degrade to trzeci tryb: blokuje wywołanie, sugerując tańszy model z mapy degradation, co jest właściwym rozwiązaniem, gdy zadanie musi zostać ukończone, ale nie wymaga użycia najlepszego modelu. warnRatio domyślnie przyjmuje 0.8, więc powiadomienie pojawia się po osiągnięciu 80 procent limitu.

Istnieją dwa istotne ograniczenia. Koszt jest obliczany na podstawie wbudowanej tabeli cen połączonej z cenami dostarczonymi przez użytkownika, przy czym opiekun projektu ostrzega, że wbudowane ceny mogą ulegać zmianom. prices jest domyślnie puste. W przypiętym commicie 461d478, defaultPrice, czyli wartość zapasowa dla modelu nieujętego w żadnej z tabel, wynosi 1.0 USD za milion tokenów wejściowych i 3.0 za milion wyjściowych; w bieżącej wersji main, sprawdzonej 10 października 2026, domyślnie wynosi zero, a model jest oznaczany jako niewyceniony. Należy wprowadzić rzeczywiste wartości dla używanych modeli, w przeciwnym razie panel informacyjny będzie jedynie przybliżeniem udającym pomiar. Po drugie, w 461d478 wtyczka agreguje dane w uruchomionym procesie ze strumienia zdarzeń sesji, więc sumy resetują się po restarcie mechanizmu, a pętla awaryjna lub nadzorca restartujący dsh resetuje limit dzienny. Bieżąca wersja main domyślnie utrwala zasobniki dzienne i miesięczne (persistence.enabled: true, zapisywane co 10 sekund) i przywraca je przy starcie, więc restart nie czyści już limitu dziennego ani miesięcznego, pod warunkiem, że mechanizm zapewnia domenę przechowywania; bez niej agregacja pozostaje lokalna dla procesu. main również odnosi się do linii mechanizmu 0.2, więc zmiana przypięcia oznacza również zmianę mechanizmu. Niezależnie od tego, należy traktować dsh-budget jako zabezpieczenie przed własnymi zadaniami i utrzymywać limit wydatków na koncie dostawcy jako faktyczny pułap, co stanowi szerszy argument w kontrolowaniu kosztów agenta AI na serwerze VPS.

Na co dzień używa się /budget do przeglądu, /budget models do szczegółowego zestawienia według modeli oraz /budget unblock <scope> do zniesienia blokady po podjęciu decyzji o kontynuacji pracy.

reguły-uprawnień-dsh: których wywołań narzędzi nigdy nie uruchamiać?

dsh-permission-rules nakłada reguły deklaratywne na potok tools/pre-execute, dzięki czemu reguła jest oceniana przed uruchomieniem narzędzia. Istnieją trzy akcje. allow przepuszcza wywołanie, deny blokuje je i zwraca przyczynę, którą model może odczytać, a ask kieruje je do oficjalnego punktu zatwierdzania.

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

Reguły znajdują się w .dsh/rules.yaml względem katalogu roboczego sesji, z globalnym fallbackPath oraz opcjonalnym searchUp, pozwalającym na przeszukiwanie struktury w górę, w stronę głównego katalogu systemu plików. Dopasowanie obejmuje wzorce glob dla nazw narzędzi, kluczy i wartości parametrów, ścieżek relatywnych do obszaru roboczego, selektorów agentów takich jak main lub subagent, oraz celów sieciowych.

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

W procesie oceny pierwsze dopasowanie wygrywa, więc szeroka reguła allow umieszczona na początku listy po cichu anuluje każdą węższą regułę znajdującą się poniżej. Reguły blokujące należy umieszczać na początku, a reguły zezwalające na końcu. Wzorzec glob dla nazwy narzędzia obejmuje mcp__*, co pozwala na kontrolowanie narzędzi pochodzących z serwera Model Context Protocol (MCP), a nie z samego środowiska uruchomieniowego; ma to znaczenie w momencie uruchamiania serwerów MCP na VPS.

Należy zaplanować następujące zachowanie: ask wymaga podmiotu zatwierdzającego. W profilu headless nikt może nie monitorować działań, a nieodebrane ask nie czeka na pojawienie się użytkownika: bez skonfigurowanego podmiotu zatwierdzającego łańcuch zatwierdzeń środowiska kończy się odmową i wywołanie zostaje odrzucone. Na serwerze bez nadzoru reguła ask zachowuje się zatem jak deny, której nie zdefiniowano celowo. Używaj deny dla wszystkiego, czego nigdy nie zatwierdzisz, zachowaj ask dla profilu, przy którym pracujesz bezpośrednio, a jeśli chcesz, aby zatwierdzenia działały bez nadzoru, potrzebujesz rzeczywistej ścieżki zatwierdzania, co jest tematem kontrolowania działań agentów AI za pomocą zatwierdzeń.

dsh-defend: co z prompt injection i wyciekiem sekretów?

dsh-defend skanuje w trzech punktach: wiadomości przychodzące w agent/pre-step, argumenty narzędzi w tools/pre-execute (w tym zabezpieczenie przed destrukcyjnym usuwaniem) oraz wyniki narzędzi w tools/post-execute. Ten ostatni punkt jest szczególnie istotny, ponieważ to w nim treść pobrana ze strony WWW jest weryfikowana, zanim model podejmie na niej jakiekolwiek działania.

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

Ustawienia domyślne są ostrożne, a nie restrykcyjne: detection.injectionAction, detection.jailbreakAction oraz detection.secretAction mają wartość ask, podczas gdy detection.secretBlockCritical ma wartość true, co oznacza, że krytyczny sekret jest blokowany niezależnie od pozostałych ustawień. Na serwerze działającym bez nadzoru należy zmienić istotne akcje na block, ponieważ ask w sytuacji, gdy nie ma kogo zapytać o zgodę, nie stanowi realnej decyzji.

Projekt audytu zasługuje na uznanie. Zdarzenia defend/detection rejestrują identyfikator reguły, rodzinę, kategorię, poziom ważności, decyzję oraz fakty dotyczące skanowania, ale nigdy nie zapisują dopasowanego tekstu; sekrety są rejestrowane wyłącznie według typu. Włączenie dziennika audytu nie tworzy zatem drugiej kopii poświadczeń, które miały zostać zabezpieczone.

Należy jasno określić, co zapewnia to rozwiązanie. Detekcja opiera się na regułach, a plik README wprost informuje, że nowe sformułowania oraz ataki wieloetapowe mogą je ominąć. Mechanizm ten zmniejsza częstotliwość występowania oczywistych ataków. Nie czyni on agenta bezpiecznym w kontakcie z niezaufaną treścią, dlatego należy utrzymać restrykcyjne reguły uprawnień na niższym poziomie.

dsh-memory: co agent zapamiętuje na jutro?

Dwie różne wtyczki noszą nazwę dsh-memory, o czym warto wiedzieć przed wpisaniem polecenia instalacji. Należy instalować je z jawnego źródła, aby otrzymać wersję, z którą się zapoznano.

Wersją, którą warto umieścić na małym serwerze, jest kompilacja SQLite. Rejestruje się ona jako memory, przechowuje jeden plik w $DSH_HOME/memory/memory.db współdzielony między profilami i udostępnia memory_write, memory_search oraz memory_forget. Wyszukiwanie opiera się na słowach kluczowych w zapisanych tekstach i tagach. Nie wymaga usługi osadzania (embedding), klucza API ani dodatkowego procesu.

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

Konfiguracja, którą należy zmodyfikować, jest niewielka: path dla pliku bazy danych, promptRecentCount (domyślnie 10) dla liczby wstrzykiwanych nieprzypiętych wspomnień oraz promptMaxChars (domyślnie 2000) dla budżetu renderowania. Opiera się ona na node:sqlite, co w Node 22 i 24 nadal jest oznaczone jako eksperymentalne, więc aktualizację Node należy przetestować, zamiast zakładać jej poprawne działanie.

Oto jak pamięć faktycznie zmienia działanie maszyny: wstrzyknięte wspomnienia są dołączane do promptu systemowego przy każdej turze. promptMaxChars to górny limit dla renderowanej sekcji, a nie stała wartość, jednak gdy zapisane wspomnienia go wypełnią, budżet 2000 znaków oznacza kilkaset dodatkowych tokenów wejściowych w każdym pojedynczym żądaniu, bezterminowo. Jest to realny koszt na rachunku i dlatego dsh-budget powinno znaleźć się na serwerze przed dsh-memory. Należy utrzymywać promptMaxChars na niskim poziomie i czyścić dane za pomocą memory_forget, zamiast pozwalać na niekontrolowany wzrost pliku.

Alternatywna kompilacja przechowuje wspomnienia w pliku YAML i wykonuje wyszukiwanie semantyczne z automatycznym wstrzykiwaniem do promptu; instaluje się ją za pomocą dsh plugin --profile web add github:towzai/dsh-memory. Jej wyszukiwanie semantyczne wymaga lokalnej instancji ollama oraz modelu osadzania, domyślnie qwen3-embedding:0.6b, z możliwością nadpisania przez DSH_MEMORY_EMBED_MODEL; bez ollama system przełącza się na wyszukiwanie wyłącznie po słowach kluczowych. Przywoływanie semantyczne jest skuteczniejsze niż wyszukiwanie po słowach kluczowych. Oznacza to jednak drugą usługę i zestaw wag modelu rezydujących na tym samym serwerze, co w przypadku małego planu oznacza pamięć RAM odebraną zadaniom, do których serwer został wynajęty. Należy wybrać to rozwiązanie, gdy dysponuje się wolną pamięcią RAM. Ogólny kompromis między jakością przywoływania a kosztem zasobów omówiono w lokalna pamięć dla agentów.

dsh-web-lan-access: czy interfejs WWW powinien nasłuchiwać poza loopback?

npx @deepseek-ai/dsh web udostępnia interfejs na 127.0.0.1:3080. Przeglądarki udostępniają crypto.randomUUID() wyłącznie w bezpiecznym kontekście, dlatego ładowanie tej samej strony przez zwykły protokół HTTP z innej maszyny kończy się niepowodzeniem. dsh-web-lan-access rozwiązuje ten problem, wykorzystując webServer.tapIndex do wstrzyknięcia niewielkiego polyfillu i zmienia powiązanie serwera na 0.0.0.0.

Przed instalacją należy zapoznać się z ostrzeżeniem. W commicie oznaczonym jako e27e909 plik README informował, że powiązanie z 0.0.0.0 sprawia, iż agent staje się dostępny bez uwierzytelniania dla każdego użytkownika w tej samej sieci lokalnej (LAN), a na serwerze z publicznym adresem IP – dla całego Internetu. Krótka lista wrażliwych metod (settings.*, credentials.*, llm.discoverModels) była przypisana do loopback i zwracała błąd 403 dla zdalnych źródeł. Stan ten uległ zmianie. Obecne kompilacje, sprawdzone 10 października 2026, uwierzytelniają przeglądarkę: token startowy w wydrukowanym adresie URL jest wymieniany na podpisane ciasteczko sesyjne, którego wymaga każda trasa i strumień Host API. Obecny plik README wtyczki określa trustedHosts jako zabezpieczenie typu Origin/Host, a nie tożsamości. Informuje, że powiązanie z 0.0.0.0 wystawia powierzchnię uwierzytelniania na każdym dostępnym interfejsie i umożliwia dostęp do ustawień Host dla uwierzytelnionej strony zdalnej. W obecnych kompilacjach zalogowana zdalna przeglądarka może uzyskać dostęp do ustawień Host. Ryzyko zostało przeniesione, a nie wyeliminowane: każdy, kto ma dostęp do portu, może testować logowanie, wydrukowany adres URL sam w sobie stanowi poświadczenie, a w przypadku zwykłego HTTP token ten przesyłany jest przez sieć otwartym tekstem.

W większości przypadków ta wtyczka nie jest potrzebna. Zamiast tego należy przekierować port przez SSH.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

Następnie należy otworzyć http://127.0.0.1:3080 w lokalnej przeglądarce. Mechanizm nadal nasłuchuje tylko na loopback, więc nic nie jest wystawione na zewnątrz, a ponieważ przeglądarki traktują 127.0.0.1 jako bezpieczne źródło, crypto.randomUUID() jest dostępne i nie ma potrzeby stosowania polyfillu. Jedno polecenie, brak wtyczki, brak nowej powierzchni ataku.

Wtyczkę należy instalować tylko wtedy, gdy przekierowanie nie jest wystarczające, na przykład gdy telefon w tej samej sieci musi uzyskać dostęp do interfejsu WWW. W takim przypadku należy powiązać ją z prywatnym interfejsem sieciowym, utrzymać regułę firewalla zezwalającą na ruch tylko z tego interfejsu oraz wymienić nazwy, które będą używane, w sekcji trustedHosts we wpisie web-runtime. Do obsługi wielu użytkowników służy dsh-passwords, który dodaje uprawnienia dla podużytkowników, godzinowe tokeny i dzienne limity czasowe dla każdego z nich, automatyczne certyfikaty TLS (transport layer security) przez Let's Encrypt oraz szyfrowany dziennik zdarzeń. Należy traktować to rozwiązanie jako platformę, a nie wtyczkę: wymaga portów 80 i 443, posiada własny instalator, a udokumentowana szybka ścieżka instalacji przesyła skrypt powłoki z sieci bezpośrednio do bash. Zaleca się użycie npm install -g dsh-passwords, a następnie dsh-passwords install, aby kod znajdował się na dysku, gdzie można go przejrzeć przed uruchomieniem.

Jak poprawnie usunąć wtyczkę

Proces odinstalowania składa się z dwóch kroków, z których drugi jest często pomijany.

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list nie powinno już wyświetlać wtyczki. Następnie należy otworzyć $DSH_HOME/profiles/web/cordis.patch.yml i usunąć wszelkie pozostałe bloki typu insert, które odwołują się do tej wtyczki, ponieważ to właśnie ten wpis odpowiada za jej ładowanie do drzewa. Należy zrestartować harness, aby drzewo zostało przebudowane; wtyczka załadowana do pamięci pozostanie aktywna do momentu restartu. Na koniec należy pamiętać, że dane istnieją niezależnie od kodu. $DSH_HOME/memory/memory.db oraz .dsh/rules.yaml pozostają po odinstalowaniu. Należy usunąć je ręcznie, jeśli celem było całkowite usunięcie danych.

Co i kiedy przeczytano

Każde odniesienie w tym miejscu wskazuje na konkretny commit, a nie na branch, ponieważ main będzie zawierać inny kod w momencie czytania tego tekstu. Całość materiału została przeanalizowana 17 sierpnia 2026 roku, a sam zestaw narzędzi znajdował się tego dnia w wersji 0.1.0-rc.7 w repozytorium npm. Domyślne ustawienia oraz opisane powyżej zachowania zweryfikowano ponownie w oparciu o źródła pierwotne 10 października 2026 roku, kiedy to tag latest w npm wskazywał na wersję 0.2.0-rc.2.

Przed skopiowaniem polecenia należy ponownie sprawdzić przypięte wersje. W ekosystemie typu developer-preview tylko numer wersji powiązany z datą ma znaczenie.

FAQ

Które wtyczki DeepSeek Harness należy zainstalować jako pierwsze na VPS?

Zainstaluj dsh-budget oraz dsh-permission-rules przed wszystkimi innymi. Budżet z overLimit: block zapobiega niekontrolowanemu zużyciu środków przez całą noc, a plik .dsh/rules.yaml blokuje wywołania narzędzi, których użytkownik nie zatwierdziłby. Dodaj dsh-defend, gdy agent zacznie odczytywać dane z publicznej sieci, oraz dsh-memory, gdy zauważysz, że wklejasz ten sam kontekst do każdej sesji. Pomiń motywy i wskaźniki statusu: dodają one kod wykonywany z uprawnieniami agenta, nie zmieniając przy tym sposobu działania maszyny.

Czy wtyczki dsh są odizolowane od harnessa?

Nie. Wtyczka ładuje się do tego samego drzewa Cordis co harness, w tym samym procesie, jako ten sam użytkownik systemu operacyjnego, z tymi samymi poświadczeniami modelu i tym samym drzewem roboczym. Wtyczka korzystająca z tools/pre-execute widzi i może blokować każde wywołanie narzędzia; wtyczka korzystająca z agent/pre-step widzi wiadomości użytkownika. Należy zatem czytać kod źródłowy, sprawdzać licencję oraz datę ostatniego commita, a także instalować wtyczki według konkretnego commita, a nie gałęzi, aby kod nie zmienił się w sposób niekontrolowany.

Czy dsh-budget faktycznie zatrzyma agenta, czy tylko wyświetli ostrzeżenie?

Zależy to od overLimit. Wartością domyślną jest alert, która ostrzega przy warnRatio i pozwala na dalsze wydatki. block odmawia kolejnych wywołań modelu po osiągnięciu limitu, a /budget unblock <scope> znosi go po podjęciu decyzji o kontynuacji. degrade blokuje działanie, sugerując tańszy model z mapy degradation. Jeden limit jest istotny: przy przypiętym commicie 461d478 sumy są agregowane w uruchomionym procesie, więc restart harnessa resetuje je, a pętla restartów może obejść limit dzienny. Bieżące main domyślnie przechowuje dzienne i miesięczne limity między restartami. Niezależnie od tego, należy utrzymywać limit wydatków na koncie dostawcy jako ostateczne zabezpieczenie.

Jak całkowicie usunąć wtyczkę dsh?

Uruchom dsh plugin --profile web remove <package-name>, potwierdź za pomocą dsh plugin --profile web list, a następnie otwórz $DSH_HOME/profiles/web/cordis.patch.yml i usuń pozostały blok wstawiania dla tej wtyczki, ponieważ to ten wpis odpowiada za jej ładowanie. Zrestartuj harness, aby drzewo wtyczek zostało przebudowane. Dane zapisane przez wtyczkę pozostają na dysku: $DSH_HOME/memory/memory.db oraz .dsh/rules.yaml przetrwają odinstalowanie, dopóki nie zostaną usunięte ręcznie.

Czy bezpieczne jest udostępnianie interfejsu webowego dsh w sieci?

Nie samodzielnie. dsh web nasłuchuje na 127.0.0.1:3080, a dsh-web-lan-access zmienia to powiązanie na 0.0.0.0. W cytowanym tutaj commicie plik README informował, że czyni to agenta dostępnym bez uwierzytelniania dla każdego w tej samej sieci, przy czym tylko settings.*, credentials.* oraz llm.discoverModels były przypięte do interfejsu loopback. Bieżące kompilacje harnessa, sprawdzone 10 października 2026, uwierzytelniają sesję przeglądarki za pomocą tokena startowego w wyświetlonym adresie URL oraz podpisanego ciasteczka sesji, jednak panel logowania jest wtedy wystawiony na każdym interfejsie, a zwykły adres HTTP przesyła ten token otwartym tekstem. Należy użyć przekierowania portu SSH, ssh -N -L 3080:127.0.0.1:3080 you@your-server lub umieścić port za prywatnym interfejsem sieciowym wraz z regułą firewalla, a także zapewnić terminację TLS przed jakimkolwiek dostępem z zewnątrz.