SSD Nodes Learn Hosting plans →
Mwongozo Matt ConnorNa Matt Connor · Imeboreshwa 2026-08-30

Jinsi ya kuendesha DeepSeek Harness kwenye VPS kwa usalama

Jifunze kusakinisha DeepSeek Harness kwenye Linux VPS kwa kubandika toleo la npm. Tumia SSH tunnel kufikia port 3080 ili kuzuia hatari ya usalama kwa wakala wako wa Node.js.

DeepSeek Harness ni nini

DeepSeek Harness (dsh) ni runtime ya wakala wa Node.js unayoweza kuiendesha kwenye VPS (virtual private server), na njia salama ya kuiendesha ni kuifunga kwenye 127.0.0.1 huku kivinjari chako kikifikia huduma hiyo kupitia SSH (secure shell) tunnel. Inatoa web UI (user interface) kwenye port 3080 badala ya kufanya kazi ndani ya terminal. Seva hiyo ya wavuti haiitaji nenosiri lake, kwa hivyo port 3080 iliyochapishwa hadharani humpa yeyote anayeipata wakala anayeweza kusoma faili zako na kuendesha amri kama mtumiaji wako wa Linux.

DeepSeek ilitoa programu hiyo tarehe 13 Agosti 2026 chini ya leseni ya MIT, kama kifurushi cha npm @deepseek-ai/dsh. Mradi huu unajielezea kama onyesho la awali la msanidi programu na unasema kuwa mabadiliko yanayovunja utangamano yanatarajiwa. Kila namba ya toleo hapa chini ni picha ya hali ya Agosti 2026, kwa hivyo kagua hazina (repository) kabla ya kunakili chochote kwenye seva muhimu.

Wazo moja linapita katika muundo mzima: kila kitu ni plugin. Adapta ya modeli, sajili ya zana, logi ya kikao, sandbox, kipanga ratiba na kitanzi cha wakala chenyewe ni plugins zinazopakiwa kwenye muktadha mmoja ulioshirikiwa, na yoyote kati yao inaweza kubadilishwa. Hakuna msingi wenye upendeleo ambao plugins hupamba tu. Hilo ndilo linalofanya harness hii kustahili kujaribiwa, na pia ndipo hatari moja ya kweli ilipo. Ikiwa biashara hiyo ni sahihi inategemea kile unachokilinganisha nacho, na jinsi inavyolingana na Claude Code na Omnigent huweka muundo wa kila kitu-ni-plugin kando ya majibu mengine mawili kuhusu uunganishaji wa modeli, leseni na kiasi cha rasilimali za VPS ambacho kila moja inahitaji.

Harness siyo model

Harness huendesha loop ya agent. Utafakari hutokea kwenye model iliyo mahali pengine, kwa hivyo hakuna kinachofanya kazi hadi utakapoiwekea API (application programming interface) key au anwani ya model endpoint unayojiendeshea mwenyewe. Kila kitu katika chapisho hili ni usanidi wa harness na si tabia ya model, na mpaka kati ya vitu hivi viwili ni vyema ueleweke vizuri kabla ya kutumia mchana mzima kutatua tatizo bila kujua upande gani lilitokea.

Unasanidi hilo kwenye UI chini ya Settings kisha Models. Catalog ina kadi zilizotayarishwa kwa ajili ya watoa huduma wakubwa wa API (DeepSeek, OpenAI, Anthropic) ambapo unaweka key. "Add a custom provider" ndiyo chaguo la kuvutia: linahitaji provider ID, jina la kuonyesha, base URL, API protocol na credential, na linatumia protocol inayooana na OpenAI, kwa hivyo gateway yoyote au seva ya ndani inayotekeleza protocol hiyo itafanya kazi. Custom providers wanaweza pia kuuliza OpenAI-compatible GET /models endpoint ili kujaza orodha ya model kwa ajili yako.

Hivyo ndivyo unavyoelekeza harness kwenye model iliyo kwenye VPS hiyo hiyo. Ollama hutoa API inayooana na OpenAI kwenye http://127.0.0.1:11434/v1/, na inahitaji sehemu ya API key ijazwe na string yoyote, ollama kama ilivyo kawaida, kwa sababu sehemu hiyo ni lazima ijazwe na kisha hupuuzwa. Kama model ndogo inayotosha kwenye VPS yako inatosha kuendesha agent ni swali gumu zaidi, na tofauti kati ya Ollama na vLLM kama seva ya model ya ndani huamua ni kiasi gani cha RAM yako kitatumika kupata jibu.

Key zinazoandikwa kwenye UI ni za kuandika pekee (write-only). Harness huzihifadhi kwenye $DSH_HOME/.credentials.yaml na huweka tu reference ya credential kwenye settings.yaml. $DSH_HOME kwa kawaida huwa ~/.dsh. Ichukulie faili hiyo kama faili ya nenosiri, kwa sababu ndivyo ilivyo: mtu yeyote anayesoma faili hiyo anaweza kutumia bajeti yako ya API. Ikiwa unataka kuhariri faili hizo moja kwa moja badala ya kubofya kupitia Settings, mwongozo wa dsh config files, keys na model endpoints unaonyesha kila key inafanya nini na nini kinatoka kwenye mashine yako katika kila mode.

Mahitaji kabla ya kusakinisha

  • VPS inayoendesha Ubuntu 24.04 au mfumo mwingine wa kisasa wa Linux, ikiwa na uwezo wa kufikia kupitia SSH
  • Node.js 22.19 au toleo jipya zaidi katika mfululizo wa 22.x, au Node.js 24 na kuendelea, ambayo ndiyo toleo ambalo mradi huu hujengwa na kufanyiwa majaribio
  • akaunti ya kawaida ya mtumiaji, si root, kwa sababu wakala huendesha amri za shell kama mtumiaji aliyeanzisha mchakato huo
  • pnpm kwenye PATH ikiwa unapanga kusakinisha programu jalizi (plugins), kwa sababu amri ya plugin hutumia programu hiyo
  • port 3080 ikiwa imefungwa kwenye firewall yako na kwenye firewall ya mtandao ya mtoa huduma wako

Kifurushi cha nodejs cha Ubuntu ni cha zamani kuliko mahitaji ya mfumo huu, kwa hivyo sakinisha Node kutoka NodeSource au nvm badala ya kutumia apt install nodejs. Ikiwa VPS ni mpya, kuimarisha usalama wa SSH kabla ya jambo lingine lolote ni muhimu kwa dakika kumi, kwa sababu handaki (tunnel) unayotegemea itakuwa imara kulingana na seva ya SSH iliyo nyuma yake.

Sakinisha DeepSeek Harness kwenye VPS, ukiifunga kwenye toleo maalum

node --version
npx @deepseek-ai/dsh@0.1.0-rc.6 web

npx hupakua kifurushi na kuendesha binary yake ya dsh. web ni alias ya --profile web, ambayo huwasha programu ya kivinjari, na mchakato huo huchapisha anwani inayoisikiliza. Chaguo-msingi ni http://127.0.0.1:3080. Namba hizo ni uamuzi wa kisheria wa mawasiliano badala ya mpangilio wa kawaida tu, na kwa nini dsh huchapisha anwani ya loopback inaelezea kile ambacho harness itajibu na isichojibu kabla hujaanza kuitafuta kutoka kwenye laptop yako.

Funga toleo (pin the version). npx @deepseek-ai/dsh web hutatua chochote ambacho tag ya latest inaelekeza wakati unapoikimbiza, na mradi huu umeshatoa matoleo kadhaa ya majaribio (release candidates) na unasema mabadiliko makubwa yanakuja. 0.1.0-rc.6 ndicho ambacho latest ilikuwa ikielekeza mnamo 13 Agosti 2026. Toleo lililofungwa linamaanisha kuwa seva uliyoiweka leo itafanya kazi vilevile mwezi ujao, hivyo uboreshaji unakuwa uamuzi unaoufanya wewe badala ya ajali unayokutana nayo. Wakati amri iliyofungwa bado inaanza na build isiyo sahihi au inakataa kusakinika kabisa, makosa ya kawaida ya usakinishaji na toleo la dsh yanaelezea jinsi ya kufuta cache ya npx na kuangalia ni npm ipi ambayo Node yako inatumia.

Kwa matumizi ya kila siku, isakinishe mara moja badala ya kuiazimia upya kila unapoianzisha.

npm install -g @deepseek-ai/dsh@0.1.0-rc.6
dsh --profile web --help

Mstari huo wa pili unastahili kuendeshwa, kwa sababu launcher na web app hubeba seti tofauti za flag. dsh --help huonyesha chaguzi za launcher yenyewe. dsh --profile web --help huonyesha flag ambazo web application inakubali, ambapo --port, --host na --trusted-host inayoweza kurudiwa hupatikana.

Sasa thibitisha inachoisikiliza.

ss -tlnp | grep 3080

Safu ya anwani ya ndani (local address) inapaswa kusoma 127.0.0.1:3080. Ikiwa inasoma 0.0.0.0:3080, UI inaweza kufikiwa kutoka kwenye Internet, na unapaswa kusimamisha mchakato huo kabla ya kufanya jambo lingine lolote.

Kwa nini hupaswi kamwe kuchapisha port 3080

Seva ya wavuti haina safu ya uthibitishaji (authentication layer). Usanidi wake hufichua host ya kusikiliza na port ya kusikiliza, na hiyo ndiyo sehemu nzima ya kuingilia. Udhibiti wa ufikiaji kwa ajili ya deployments zisizo za loopback ni mpangilio tofauti wa trusted-host, ambao si skrini ya kuingia (login screen).

Sasa fikiria kile kilichopo nyuma ya port hiyo. Wakala (agent) huhariri faili kwenye workspace na kuendesha amri za shell, na vitambulisho vyako vya mtoa huduma vipo kwenye diski karibu na hapo. Kwa hivyo, port 3080 iliyo wazi ni shell ya mbali yenye kiolesura cha gumzo, inayofanya kazi kama mtumiaji aliyeianzisha, ikiwa na API key yako iliyoambatishwa. Hakuna anayehitaji exploit kwa ajili hiyo. Wanahitaji tu namba ya port, na skana hupata namba za port ndani ya saa chache baada ya host kuanza kufanya kazi mtandaoni.

CLI (command line interface) inakubaliana na hili. Kuanzia 0.1.0-rc.6, kwa makusudi haitumii --host 0.0.0.0 na inatoka kwa kutoa hitilafu ya matumizi badala ya kuanza. Kukataa huko ni kipengele cha usalama, kwa hivyo usitafute kiraka (patch) kinachoondoa kizuizi hicho.

Deployments nyingine mbili ni za busara wakati tunnel haikufai. Weka kisanduku kwenye mtandao wa kibinafsi wa overlay ili kiwe na anwani ambayo vifaa vyako pekee vinaweza kuifikia, jambo ambalo seva ya kudhibiti ya Headscale inayojiendesha yenyewe hukupa. Au iweke nyuma ya reverse proxy inayothibitisha ombi kabla halijafika kwenye port 3080, kwa mfano seva ya Authentik ya single sign-on inayofanya forward auth. Reverse proxy isiyo na uthibitishaji mbele yake si udhibiti wa usalama. Ni URL ndefu zaidi tu.

Fikia web UI kupitia SSH tunnel

Tekeleza amri hii kwenye laptop yako, siyo kwenye seva.

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

-L hufungua port 3080 kwenye laptop yako na kusambaza chochote kinachounganishwa nayo kupitia session ya SSH iliyosimbwa. Sehemu ya 127.0.0.1:3080 hutatuliwa kwenye seva, kwa hivyo muunganisho hufika kwenye harness kutoka loopback, kama vile unavyotumia mashine hiyo moja kwa moja. -N huagiza kutozindua remote shell, kwa sababu unahitaji usambazaji wa port pekee.

Kisha fungua http://127.0.0.1:3080 kwenye kivinjari chako cha ndani. Ikiwa port 3080 inatumiwa na programu nyingine kwenye laptop yako, badilisha namba ya upande wa kushoto: ssh -N -L 3180:127.0.0.1:3080 you@your-server, kisha uende kwenye http://127.0.0.1:3180. Namba iliyo upande wa kushoto ni ya ndani (local) na namba iliyo upande wa kulia ni ya seva, kwa hivyo ile ya kushoto pekee ndiyo inayoweza kubadilishwa.

Ihifadhi kwenye ~/.ssh/config ili usilazimike kuiandika kila mara.

Host dsh
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  LocalForward 3080 127.0.0.1:3080

Baada ya hapo, ssh -N dsh huanzisha tunnel. Kivinjari kinachotoa ujumbe kuwa muunganisho umekataliwa (connection refused) mara nyingi humaanisha kuwa tunnel inafanya kazi lakini hakuna huduma inayopokea maombi upande wa pili, kwa sababu SSH husambaza port bila kujali kama harness inafanya kazi au la. Kagua seva kwa kutumia amri ya ss hapo juu.

Kuweka harness ikiendelea kufanya kazi baada ya kutoka kwenye mfumo (logout)

Amri ya npx hufa pindi shell yako inapofungwa. Huduma ya mtumiaji (user service) ya systemd huendelea kufanya kazi, na huirejesha harness baada ya hitilafu au reboot. Unit iliyopo hapa ni ndogo kwa makusudi; kama unataka harness ifanye kazi chini ya akaunti yake iliyolindwa, ikiwa na toleo lililofungwa (pinned) ndani ya unit na logi unazoweza kuzitafuta, usanidi wa headless systemd kwa ajili ya dsh unaelezea hayo kikamilifu.

loginctl enable-linger $USER
mkdir -p ~/.config/systemd/user
command -v dsh

enable-linger ni muhimu kwa sababu huduma za mtumiaji kwa kawaida husimama wakati kikao chako cha mwisho kinapomalizika, hivyo bila hiyo, harness hufa pindi tu unapofunga tunnel. Chukua njia kamili (absolute path) iliyochapishwa na command -v dsh na uiweke kwenye unit, kwa sababu systemd haitafuti kwenye PATH inayojengwa na login shell yako.

[Unit]
Description=DeepSeek Harness web UI
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/projects/site
ExecStart=/usr/local/bin/dsh web
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

WorkingDirectory si ya kupendezesha tu. Mchakato wa dsh hutumia saraka (directory) iliyouanzisha kama eneo chaguo-msingi la mfumo wa faili, hivyo huduma iliyoanzishwa mahali pasipo sahihi huipa agent workspace isiyo sahihi. Bado unaweza kuchagua workspace kwenye UI.

systemctl --user daemon-reload
systemctl --user enable --now dsh
systemctl --user status dsh

Unit inayokataa kuanza karibu kila mara inatokana na njia ya ExecStart isiyo sahihi au toleo la Node ambalo binary hiyo inalikataa, na journalctl --user -u dsh -n 50 huonyesha ni lipi. Mfumo huohuo unahusu kuweka agent yoyote ya uandishi wa msimbo ikiwa hai kwenye VPS, na njia za kufeli ni zilezile.

Mambo ambayo plugin inaruhusiwa kufanya

Plugin ni moduli inayoongeza huduma, matukio yaliyopangwa (typed events), na athari zinazoweza kutenduliwa kwenye muktadha wa pamoja. Sehemu za upanuzi (extension points) ndizo zinazopaswa kusomwa kwa umakini:

  • kusajili mtoa huduma wa model kwenye ctx.llm
  • kuongeza zana zinazotumiwa na model kwenye ctx.tools
  • kutoa backend ya shell kupitia ctx.shell
  • kutoa ufikiaji wa mfumo wa faili au sera kupitia ctx.fs
  • kusajili amri za binadamu kwenye ctx.commands
  • kuendesha kazi za usuli (background work) kupitia ctx.jobs
  • kufunga michakato iliyoanzishwa (spawned processes) kwa kutumia backend ya ctx.sandbox
  • kuzuia maombi na miito ya zana (tool calls) kupitia matukio ya agent/* na tools/*
  • kupanua hali ya session inayodumu (durable session state)
  • kuendesha UI kupitia ctx.agents

Soma orodha hiyo kwa mtazamo wa mshambuliaji. Plugin inaweza kutoa safu ya mfumo wa faili na safu ya shell, na inaweza kujiingiza katikati ya kila mwito wa zana unaofanywa na model. Hakuna kisanduku cha idhini (permission dialog) kinachozuia plugin kufikia sehemu hizo, kwa sababu plugin ni msimbo wa kawaida wa Node unaopakiwa kwenye mchakato uleule kama kila kitu kingine. Kusakinisha plugin ni sawa na kuendesha msimbo wa mtu usiyemjua kwa kutumia ruhusa za wakala wako, na ruhusa za wakala wako ni sawa na ruhusa za mtumiaji wako wa Unix.

Huu ni uamuzi uleule wa uaminifu unaoufanya unapounganisha seva ya MCP kwenye wakala katika VPS, ambapo MCP ni itifaki ya muktadha wa model (model context protocol). Hii ndiyo sababu kuendesha wakala wa usimbaji kwa usalama kwenye VPS huanzia kwenye akaunti inayouendesha badala ya kuanzia kwenye model, na ndiyo sababu mashambulizi ya mnyororo wa usambazaji wa npm huleta madhara makubwa kwenye seva: hatua ya usakinishaji ndiyo inayofanikisha uvamizi, na hakuna onyo lolote linalotokea.

Mahali plugins zinapotoka

Plugins hukaa ndani ya profiles. Profile ni mkusanyiko wenye jina uliotunzwa chini ya $DSH_HOME, ambao kwa kawaida ni ~/.dsh, na kila saraka ya profile huhifadhi plugins za nje (out-of-tree) inazozisakinisha. CLI huzisimamia kwa kusambaza hoja zako moja kwa moja kwenda pnpm, ikitumia saraka ya profile kama saraka ya kazi (working directory).

dsh plugin --profile web add github:deepseek-harness/turtle-ui
dsh plugin --profile web remove turtle-ui

Kwa sababu hoja hufika kwenye pnpm bila kubadilishwa, add, remove, update na why hufanya kazi kama zinavyofanya katika mradi wowote wa pnpm, na plugin inaweza kuwa kifurushi cha npm au rejeleo la GitHub. pnpm lazima iwepo kwenye PATH kwanza. Kwenye Node 22 na matoleo mapya zaidi, corepack enable pnpm huiweka hapo.

Ugunduzi hufanyika kupitia mada (topic) ya GitHub. Waandishi wa plugins huongeza mada ya dsh-plugin kwenye hazina (repository) zao, na kuvinjari mada hiyo ndiyo njia ya kupata yale yaliyopo. Mada ni lebo ambayo mwandishi huiweka kwenye hazina yake mwenyewe. Hakuna anayekagua na hakuna anayesaini, na ukurasa wa mada hupangwa kwa nyota, ambazo hupima umaarufu badala ya usalama.

Tabia nne hufanya hili liweze kudhibitika. Soma chanzo (source) kabla ya kusakinisha, kwa sababu plugins nyingi ni ndogo kiasi cha kusomeka ndani ya dakika kumi. Funga (pin) toleo kamili au commit badala ya kufuatilia branch. Endesha harness chini ya mtumiaji asiye na kitu kingine chochote, kwenye VPS ambayo uko tayari kuijenga upya. Ipe agent ufunguo wake wa API wenye kikomo chake cha matumizi, tofauti na ufunguo unaotumiwa na huduma zako za uzalishaji (production). Unapoketi kusoma plugin na kutaka kujua ni faili zipi zinabeba hatari, mwongozo wa kukagua plugin ya dsh hupitia manifest, sehemu ya kuingilia (entry point) na sehemu za upanuzi (extension points) ambazo plugin husajili.

Ikiwa ungependa kulinganisha usanifu kabla ya kuchagua mmoja, harness ya mawakala wengi ya Omnigent hujibu tatizo lilelile kwa muundo tofauti, na faida na hasara huwa dhahiri pindi plugins zinapoanza kutumika. Ikiwa utaishia kuhifadhi mbili au tatu kati ya hizo kwenye mashine moja badala ya kuchagua mshindi mmoja, kuweka kila harness nyuma ya API moja inayojiendesha (self-hosted) hukuokoa na hitaji la tunnel kwa kila port, kwa gharama ya huduma moja zaidi ambayo lazima ifungwe kwenye loopback na kupewa nenosiri halisi kuanzia siku ya kwanza.

Nini huvunjika kwanza

Node ni ya zamani sana. Mradi huu unalenga Node 22.19 na matoleo mapya zaidi katika mfululizo wa 22.x, au Node 24 na kuendelea, na CI yetu hufanya majaribio kwenye matoleo hayo. Runtime ya zamani hushindwa kuanza kwa sababu msimbo hutumia sintaksia na API ambazo haijazijua. Tekeleza node --version kabla ya kitu kingine chochote.

Port 3080 tayari inatumiwa. Harness ya pili, mchakato uliokwama (stale process), au programu nyingine isiyohusiana inayotumia 3080. Iitafute kwa kutumia ss -tlnp | grep 3080, kisha uisimamishe au uanzishe harness mahali pengine kwa kutumia dsh web --port 3180. --port ni ya programu ya wavuti, kwa hivyo huja baada ya web.

Kivinjari hakiwezi kuunganishwa kupitia tunnel. Thibitisha kuwa umevinjari kwenda 127.0.0.1 na si anwani ya umma ya seva, kwa sababu port iliyoelekezwa (forwarded port) ipo kwenye kompyuta yako ya mkononi pekee. Kisha thibitisha kuwa harness inasikiliza kwenye seva, kwa sababu SSH huweka uelekezaji (forward) bila kujali kama kuna kitu kinachojibu upande wa pili au la.

dsh plugin inashindwa mara moja. Amri hii ni kanga (wrapper) inayozunguka pnpm, kwa hivyo kukosekana kwa binary ya pnpm huizuia kabla ya kazi yoyote ya plugin kuanza.

Agent haiwezi kuona mradi wako. Workspace huchagua saraka (directory) ambayo mchakato ulianzishiwa kwa chaguo-msingi, kwa hivyo kitengo ambacho WorkingDirectory yake ni saraka yako ya nyumbani (home directory) kitampa agent saraka yako ya nyumbani. Chagua workspace kwenye UI, au rekebisha kitengo hicho na ukipakie upya.

FAQ

Je, ni salama kufungua DeepSeek Harness web UI kwenye port 3080?

Hapana. Web server hii haina mfumo wake wa kuingia (login), na wakala (agent) aliye nyuma yake anaweza kuhariri faili na kuendesha amri za shell kama mtumiaji aliyeanzisha mchakato huo, huku API key ya mtoa huduma wako ikiwa imehifadhiwa kwenye diski hiyo hiyo. Weka listener kwenye 127.0.0.1 na uifikie kupitia SSH tunnel. Mtandao wa kibinafsi wa overlay, au reverse proxy inayothibitisha kila ombi kabla halijafika kwenye port hiyo, pia inafaa. Kuanzia toleo la 0.1.0-rc.6, CLI inakataa --host 0.0.0.0 na kusimama kwa kutoa hitilafu ya matumizi, jambo linaloonyesha maoni ya waandishi kuhusu wazo hilo.

Je, nahitaji DeepSeek API key, au naweza kutumia model ya ndani?

Vyote vinawezekana, kwa sababu harness ni runtime na si model. Chini ya Settings kisha Models unaweza kubandika key kwenye kadi ya mtoa huduma wa catalog, au chagua "Add a custom provider" na upe URL ya msingi inayotumia itifaki inayooana na OpenAI. Seva ya ndani ya Ollama inajibu kwenye http://127.0.0.1:11434/v1/ na inakubali mfuatano wowote wa herufi kwenye sehemu ya API key. Keys huhifadhiwa kwenye $DSH_HOME/.credentials.yaml, ambayo kwa kawaida ni ~/.dsh/.credentials.yaml.

Kusakinisha plugin ya DeepSeek Harness kunampa plugin hiyo nini hasa?

Ruhusa za akaunti inayoendesha harness. Plugin ni msimbo wa Node unaopakiwa kwenye mchakato uleule, na sehemu za upanuzi (extension points) zinajumuisha shell backend, filesystem layer, tool registry na matukio yanayozunguka kila wito wa zana. Hakuna kinachoweka plugin kwenye sandbox mbali na sehemu hizo isipokuwa kama plugin yenyewe itatoa sandbox hiyo. Soma msimbo wa chanzo (source code) kabla ya kusakinisha, na uendeshe harness kama mtumiaji asiye na umiliki wa kitu chochote unachokijali.

Ni toleo gani ninalopaswa kusakinisha, na je, litaendelea kufanya kazi?

Sakinisha toleo kamili, kwa mfano npx @deepseek-ai/dsh@0.1.0-rc.6 web. Hilo ndilo toleo ambalo tag ya latest ilikuwa ikielekeza mnamo 13 Agosti 2026. Mradi huu unajiita developer preview na unasema mabadiliko yanayovunja utangamano yanatarajiwa, kwa hivyo amri isiyofungwa kwenye toleo maalum inaweza kufanya kazi tofauti siku hadi siku. Kagua hazina (repository) kabla ya kupandisha toleo, na tarajia funguo za usanidi na violesura vya plugin kubadilika wakati toleo bado linaanza na 0.

#deepseek#agent-harness#self-hosting#nodejs#plugins