5 DeepSeek Harness Plugin na Sulit I-install

Aling DeepSeek Harness plugins ang sulit i-install

Ang DeepSeek Harness plugins ay third-party code na tumatakbo sa loob ng iyong agent, gamit ang mga privilege ng agent, sa machine na binabayaran mo. May mahigit dalawampung kategorya at higit isang libong entry ang community list. Sa isang rented virtual private server (VPS), lima ang kailangan mo: dsh-budget para sa spend caps, dsh-permission-rules para sa tool gating, dsh-defend para sa injection at secret scanning, dsh-memory para sa mga fact na nananatili lampas sa isang session, at dsh-web-lan-access lamang kapag napagpasyahan mo na kung paano ka mag-a-authenticate.

Ang harness ay dsh, ang open-source agent harness ng DeepSeek na ginawa upang lahat ay plugin. Tinatawag ito ng sarili nitong README na developer preview at nagbababala ng THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Ito ang batayan ng bawat pagpili sa ibaba. I-pin ang anumang ini-install mo, asahang maaaring masira ito kapag nag-upgrade, at panatilihing maliit ang set para mabasa mo talaga ang lahat ng code. Kung hindi pa tumatakbo ang harness, magsimula sa pag-install ng DeepSeek Harness sa isang VPS at bumalik dito. Kung hindi pa malinaw ang mga bahaging hina-hook ng mga plugin na ito—ang agent loop, mga tool nito, at memory nito—unahin muna ang mga pangunahing konsepto, dahil mas madali mong masusuri ang bawat pagpili kapag alam mo na kung ano ang ginagawa ng bawat layer.

Paano nag-i-install ng plugin ang dsh, at saan napupunta ang configuration

Binubuo ng dsh ang sarili nito mula sa mga Cordis plugin, kaya ang tumatakbong instance ay isang puno ng mga plugin sa halip na isang program lang. Ang profile ay isang pinangalanang komposisyon ng mga plugin na iyon, na naka-store sa harness home. May limang profile template ang harness: web, headless, sdk, sdk-minimal at acp; ang dalawang mahalaga sa isang server ay web at headless. Naka-default ang $DSH_HOME sa ~/.dsh, at nasa $DSH_HOME/profiles/<name>/ ang isang profile. Idinedeklara nito ang sarili nito sa sarili nitong package.json sa ilalim ng field na dsh, kung saan inililista ng dsh.profile ang mga bundle ng profile. Nasa parehong directory rin ang anumang out-of-tree plugin na ini-install nito at ang sariling cordis.patch.yml ng user.

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

Apat na source form ang gumagana: bare npm package name, scoped npm name gaya ng @scope/plugin, GitHub reference gaya ng github:PerryLink/dsh-budget#main, at local path na may link: o ./. Gamitin ang GitHub form, dahil maaari mong palitan ang #main ng commit at makuha muli ang parehong code sa susunod na buwan.

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

May fixed na pagkakasunod-sunod ang paglalapat ng mga layer: bawat bundle ayon sa pagkakasunod nito sa profile, kasunod ang cordis.patch.yml ng profile, pagkatapos ang cordis.patch.yml sa home level, at pagkatapos ang anumang --patch overlay. Mahalaga ang pagkakasunod-sunod dahil maaaring i-reconfigure o alisin ng mas huling layer ang itinakda ng mas naunang layer. Kaya kapag mukhang naka-install ang isang plugin pero walang ginagawa, buksan ang cordis.patch.yml ng profile at suriin ang dalawang bagay: naroon ang insert block nito, at walang mas huling layer na nagdi-disable dito.

Noong 17 August 2026, ang npm package na @deepseek-ai/dsh ay nasa 0.1.0-rc.7, habang ang mga plugin sa ibaba ay binuo para sa 0.1.0-rc line. Sa mga commit na naka-pin dito, idinedeklara ng dsh-permission-rules at dsh-defend ang compatibility sa 0.1.0-rc.5 hanggang 0.1.0-rc.6, dsh-budget lamang ang idinedeklarang 0.1.0-rc.6, dsh-memory lamang ang nagse-set ng peer range na nagsisimula sa ^0.1.0-rc.6, at walang dsh version na idinedeklara ang dsh-web-lan-access. Noong 16 October 2026, ang latest tag sa npm ay 0.2.0-rc.2, kaya isang buong minor line na ang agwat ng mga naka-pin na commit sa harness. Karamihan sa mga plugin ay nakasabay na mula noon sa kanilang mga main branch. Nang suriin noong 16 October 2026, tinatanggap ng dsh-budget 0.4.17, dsh-permission-rules 0.7.15 at dsh-defend 0.3.21 ang dsh mula 0.1.2-rc.1 hanggang sa hindi kasama ang 0.3.0, at inililista ng bawat isa ang 0.2.1-alpha.1 sa mga harness release kung saan ito nasubukan. Ang dsh-web-lan-access 1.4.0, na inilabas noong 17 October 2026 at sinuri noong 18 October 2026, ay nagdedeklara ng >=0.2.1-rc.1. Nakalista ang mga nasubukang release hanggang 0.2.1-rc.2. Ang build na ito ay nasa next tag ng npm sa halip na latest; itinatambal ng README nito ang harness 0.2.0-rc.x at mga naunang bersyon sa plugin 1.3.x. Sa main, ang dsh-memory ay nagse-set pa rin lamang ng mga peer range mula ^0.1.0-rc.6. Wala sa mga mas bagong range na iyon ang sumasaklaw sa 0.1.0-rc build kung saan pinili ang mga pin, kaya ang paglipat ng isang pin sa kasalukuyang code ay nangangahulugan ding paglipat ng harness. Karaniwan ang agwat na ito sa ecosystem na ito, at ito ang karaniwang dahilan kung bakit humihinto sa pag-load ang isang plugin: mas mabilis umusad ang harness kaysa sa mga plugin sa paligid nito. I-upgrade ang harness nang sinasadya, pagkatapos ay subukan ang isang plugin bawat pagkakataon.

Basahin ang plugin bago ito pagkatiwalaan

Ang dsh plugin ay hindi naka-sandbox mula sa harness. Nilo-load ito sa parehong Cordis tree, sa parehong process, bilang parehong operating system user, at may access sa parehong model credentials at parehong working tree. Ang pag-install nito ay mas katulad ng pagpapatakbo ng script ng ibang tao gamit ang sudo kaysa sa pagdaragdag ng browser extension. Iyan ang parehong trust question na itinataas ng Claude Code plugins, at pareho rin ang sagot: basahin ang code, o huwag itong i-install.

Apat na bagay ang dapat suriin, sa ganitong pagkakasunod-sunod:

• Aling extension points ang ginagamit nito. Ibig sabihin ng tools/pre-execute, nakikita nito ang bawat tool call at maaari nitong i-block ang mga ito. Ibig sabihin ng agent/pre-step, nakikita nito ang iyong mga mensahe. Ibig sabihin ng webServer.tapIndex, nire-rewrite nito ang page na sine-serve sa iyong browser. Kaunti lamang ang magagawa ng plugin na wala sa mga iyon ang ginagamit; ang plugin na ginagamit ang lahat ng iyon ang iyong security boundary.
• Kung nakikipag-usap ito sa network. Hanapin sa source ang fetch, http, at anumang hard-coded hostname. Ang cost meter na nagpapadala ng usage pattern mo sa labas ay nagpapadala nito sa isang lugar.
• Kung nagbabasa ito ng credentials. Ang anumang tumatanggap sa credentials.* o sa provider key ay kailangang may malinaw na nakasaad na dahilan sa README.
• Ang license at petsa ng huling commit. Ang plugin na walang license at ilang buwan nang hindi ina-update, sa ecosystem na lingguhang nagbabago, ay isang liability.

Pagkatapos, mag-install gamit ang commit sa halip na branch, at basahin ang insert block na isinulat ng installer sa cordis.patch.yml. Nakasaad sa block na iyon ang plugin id at ang config na nirehistro nito. Iyon ang pinakamaikling tapat na paglalarawan ng idinagdag mo. Ilayo ang provider keys sa abot ng plugin kung pinapayagan ito ng harness, alinsunod sa pag-iwas na mailagay ang secrets sa mga AI agent.

dsh-budget: paano ko pipigilan ang agent na gumastos buong gabi?

Tumatakbo nang walang bantay ang isang agent sa VPS. Iyan ang dahilan kung bakit ito inilalagay doon, pero iyan din ang panganib. Sinusukat ng dsh-budget ang mga token at tinatayang cost ayon sa model, session, at araw, at nagpapatupad ito ng mga cap batay sa mga kabuuang iyon.

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

Malalaki ang default nito: 10 USD bawat session, 50 bawat araw, at 500 bawat buwan. Angkop ang mga ito sa team na may pondo. Sa personal na server, sapat na mataas ang mga ito para matapos muna ang runaway loop bago maabot ang cap. Kaya ibaba ang mga ito sa unang araw.

[
  {
    "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
  }
]

Ang iminungkahing halaga ay panimulang punto para sa isang operator sa isang machine, hindi isang opisyal na figure. Itaas ito kapag ipinakita ng aktuwal na paggamit sa loob ng isang buwan na kailangan mo iyon. Ang monthly cap na 40 USD at session cap na 2 ay mabilis at malinaw na magfa-fail kapag lumampas, na siyang gusto mo habang inaalam mo pa ang konsumo ng tool.

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

Ang setting na nagbabago sa asal ng machine ay overLimit. Ang default nito ay alert, na nagpi-print ng warning at patuloy na gumagastos. Kaya sa default configuration, dashboard ang plugin na ito. Itakda ito sa block upang tanggihan ng harness ang mga susunod na model call kapag naabot ang cap. Dahil dito, hihinto ang overnight job sa halip na patuloy na masingil hanggang umaga. Ang degrade ang ikatlong mode. Hinaharang nito ang call at nagbibigay ng gabay na tumutukoy sa mas murang model mula sa degradation map. Angkop ito kapag kailangang matapos ang job pero hindi kailangan ang pinakamahusay mong model. Ang default ng warnRatio ay 0.8, kaya makakatanggap ka ng abiso kapag umabot sa 80 percent ng cap.

Dalawa ang dapat tandaan tungkol sa mga limitasyon. Kinukuwenta ang cost mula sa built-in price table na pinagsasama sa mga presyong ibinibigay mo, at nagbabala ang maintainer na maaaring magbago ang built-in prices. Walang laman ang prices bilang default. Sa pinned commit na 461d478, ang defaultPrice, na fallback para sa model na wala sa alinmang table, ay 1.0 USD bawat milyong input token at 3.0 bawat milyong output token. Sa kasalukuyang main, na sinuri noong 10 October 2026, zero ang default nito at lumalabas ang model na walang price. Ilagay ang aktuwal na mga halaga para sa iyong mga model. Kung hindi, hula lamang ang dashboard na mukhang measurement. Ikalawa, sa 461d478, nag-aaggregate ang plugin sa tumatakbong process mula sa session event stream. Nire-reset nito ang mga total kapag nag-restart ang harness. Kaya ang crash loop, o supervisor na nagre-restart sa dsh, ay makakapag-reset ng daily cap. Ang kasalukuyang main ay nagpe-persist bilang default sa day at month buckets (persistence.enabled: true, na kumukuha ng snapshot bawat 10 segundo) at nire-restore ang mga ito sa startup. Dahil dito, hindi na binubura ng restart ang daily o monthly cap doon, basta ibinibigay ng harness ang storage domain. Kung wala ito, nananatiling process-local ang aggregation. Tumatarget din ang main sa 0.2 harness line, kaya kapag binago mo ang pin, kailangan mo ring baguhin ang harness. Sa alinmang setup, ituring ang dsh-budget bilang guardrail laban sa sarili mong mga job. Magtakda rin ng spend limit sa provider account bilang aktuwal na pinakamataas na hangganan. Ito ang mas malawak na dahilan para sa pagkontrol sa cost ng AI agent sa VPS.

Sa araw-araw, gamitin ang /budget para sa overview, /budget models para sa breakdown ayon sa model, at /budget unblock <scope> upang alisin ang block kapag napagpasiyahan mong magpatuloy.

dsh-permission-rules: aling tool calls ang hindi dapat kailanman patakbuhin?

dsh-permission-rules ay naglalagay ng declarative rules sa tools/pre-execute waterfall, kaya sinusuri ang isang rule bago patakbuhin ang tool. May tatlong action. Ipinapasa ng allow ang call, bina-block ito ng deny at ibinabalik ang dahilan na mababasa ng model, at niruruta ito ng ask sa official approval seam.

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

Nasa .dsh/rules.yaml ang mga rule kaugnay ng session working directory, may global na fallbackPath at optional na searchUp para umakyat patungo sa filesystem root. Saklaw ng matching ang tool-name globs, parameter key at value globs, workspace-relative path globs, agent selector gaya ng main o subagent, at network targets.

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"

First match wins ang evaluation, kaya tahimik na kinakansela ng malawak na allow sa itaas ang lahat ng mas tiyak na rule sa ibaba nito. Ilagay muna ang mga denial at ang permissive rules sa hulihan. Sinasaklaw ng tool-name glob ang mcp__*. Ito ang paraan para i-gate ang mga tool na nagmula sa model context protocol (MCP) server sa halip na sa harness mismo, at mahalaga ito kapag nagpapatakbo ka ng MCP servers sa isang VPS.

May isang behavior na dapat planuhin: kailangan ng ask ng sumasagot. Sa isang headless profile, maaaring walang nakabantay, at ang hindi nasagutang ask ay hindi naghihintay na may dumating: kapag walang naka-compose na sumasagot, nagfa-fail closed ang harness approval chain at tinatanggihan ang call. Sa unattended box, ang ask rule ay kumikilos na parang deny na hindi mo sinadyang isulat. Gamitin ang deny para sa anumang hindi mo kailanman aaprubahan, panatilihin ang ask para sa profile na binabantayan mo, at kung gusto mong gumana ang approvals nang unattended, kailangan mo ng tunay na answering path. Ito ang paksa ng pag-gate ng mga AI agent action gamit ang approvals.

dsh-defend: paano naman ang prompt injection at mga na-leak na secret?

dsh-defend nag-scan sa tatlong punto: mga inbound message sa agent/pre-step, mga tool argument sa tools/pre-execute kasama ang guard para sa destructive delete, at mga resulta ng tool sa tools/post-execute. Mahalaga ang huli dahil dito sinusuri ang content na kinuha mula sa isang web page bago ito gamitin ng model.

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

Maingat ang mga default sa halip na mahigpit: ang detection.injectionAction, detection.jailbreakAction, at detection.secretAction ay lahat ask, samantalang ang detection.secretBlockCritical ay true. Dahil dito, bina-block ang isang kritikal na secret anuman ang ibang setting. Sa isang unattended box, baguhin sa block ang mga action na kailangan mong ipatupad, dahil ang ask na walang mapagtatanungan ay hindi isang decision.

Karapat-dapat purihin ang disenyo ng audit. Itinatala ng mga event na defend/detection ang rule id, family, category, severity, decision, at scan facts, ngunit hindi kailanman ang tumugmang text; type lamang ng secret ang itinatala. Kaya hindi lumilikha ang pag-enable ng audit log ng pangalawang kopya ng credential na pinoprotektahan mo.

Linawin kung ano ang naibibigay nito. Rule-based ang detection, at malinaw na sinasabi ng README na maaaring makalusot ang bagong phrasing at mga multi-step attack. Binabawasan nito ang dami ng mga halatang attack. Hindi nito ginagawang ligtas ang isang agent na direktang gumamit ng untrusted content, kaya panatilihin ang mga permission rule sa ilalim nito.

dsh-memory: ano ang naaalala ng agent bukas?

Dalawang magkaibang plugin ang tinatawag na dsh-memory. Mahalagang malaman ito bago ka mag-type ng install command. Mag-install gamit ang tahasang source para makuha mo ang plugin na binasa mo.

Ang ilalagay ko sa isang maliit na server ay ang SQLite build. Nagrerehistro ito bilang memory, nag-iimbak ng isang file sa $DSH_HOME/memory/memory.db na shared sa lahat ng profile, at naglalabas ng memory_write, memory_search, at memory_forget. Keyword-based ang search sa nakaimbak na text at mga tag. Walang embedding service, API key, o karagdagang process.

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

Maliit lang ang configuration na kailangan mong galawin: path para sa database file, promptRecentCount (default na 10) para sa bilang ng mga hindi naka-pin na memory na ini-inject, at promptMaxChars (default na 2000) para sa rendering budget. Umaasa ito sa node:sqlite, na minamarkahan pa ring experimental ng Node 22 at 24. Kaya ang pag-upgrade ng Node ay dapat subukan, hindi basta ipalagay na gagana.

Ito ang aktuwal na epekto ng memory sa machine: ang mga ini-inject na memory ay kasama sa system prompt sa bawat turn. Ang promptMaxChars ay maximum para sa na-render na section, hindi nakapirming dami. Pero kapag napuno ito ng mga nakaimbak na memory, ang 2000-character budget ay nagdaragdag ng ilang daang input token sa bawat request, nang tuloy-tuloy. May totoong dagdag ito sa bill mo. Ito ang dahilan kung bakit dapat mauna sa box ang dsh-budget bago ang dsh-memory. Panatilihing maliit ang promptMaxChars at mag-prune gamit ang memory_forget sa halip na hayaang lumaki ang file.

Ang alternative build ay nag-iimbak ng mga memory sa YAML file at gumagamit ng embedding search na may automatic prompt injection. Ini-install ito gamit ang dsh plugin --profile web add github:towzai/dsh-memory. Kailangan ng embedding search nito ang lokal na ollama instance at isang embedding model, qwen3-embedding:0.6b bilang default, na maaaring palitan gamit ang DSH_MEMORY_EMBED_MODEL. Kung walang ollama, babalik ito sa keyword-only search. Mas mahusay ang semantic recall kaysa keyword recall. Nangangahulugan din ito ng ikalawang service at isang set ng model weights na nananatili sa parehong server. Sa isang maliit na plan, memory ito na hindi na magagamit para sa trabaho kung saan mo inarkila ang box. Piliin ito kapag may sapat kang RAM. Tinalakay ang pangkalahatang tradeoff sa pagitan ng kalidad ng recall at resident cost sa lokal na memory para sa mga agent.

dsh-web-lan-access: dapat bang makinig ang web UI sa labas ng loopback?

npx @deepseek-ai/dsh web ang nagse-serve ng interface sa 127.0.0.1:3080. Sa secure context lamang inilalantad ng mga browser ang crypto.randomUUID(), kaya sa mga harness build hanggang sa 0.2.0 line, nagfa-fail ang pag-load ng parehong page gamit ang plain HTTP mula sa ibang machine. Inayos ito ng dsh-web-lan-access 1.3.x sa pamamagitan ng pag-tap sa webServer.tapIndex upang mag-inject ng maliit na polyfill, at binago nito ang server binding sa 0.0.0.0. Ang Version 1.4.0, na inilabas noong 17 October 2026 para sa dsh 0.2.1, ay nag-alis ng polyfill: bumubuo ang harness na iyon ng UUID gamit ang crypto.getRandomValues, kaya nagre-render ang page na plain HTTP sa LAN nang walang patch. Tumatap pa rin ang plugin sa webServer.tapIndex, ngunit ngayon ay para mag-inject ng bootstrap script na nagbibigay-daan sa isang remote page na gumamit ng mga setting na naka-back sa Host, at nagbi-bind pa rin ito sa 0.0.0.0. Sa 0.2.1, mismong harness ang tumatanggi sa wildcard bind at nagbibigay ng babala na ang pag-bind sa bawat interface ay maglalantad ng remote code execution sa network; pinapalitan ng plugin ang shipped webserver upang malampasan ang check na iyon. Sinuri noong 18 October 2026.

Basahin muna ang sariling babala nito bago ito i-install. Sa commit na binanggit dito, e27e909, sinasabi sa README na ang pag-bind sa 0.0.0.0 ay nagbibigay-daan sa sinumang nasa parehong local area network (LAN) na maabot ang agent nang walang authentication, at sa server na may public IP address, maging sa buong internet. Samantala, ang maikling listahan ng sensitive method (settings.*, credentials.*, llm.discoverModels) ay naka-pin sa loopback at nagbabalik ng 403 mula sa remote origin. Nagbago na ito. Sa kasalukuyang harness build, na sinuri noong 10 October 2026, ina-authenticate ang browser: ipinagpapalit ang launch token sa naka-print na URL para sa isang signed session cookie, at kinakailangan ito ng bawat Host API route at stream. Tinatawag ng kasalukuyang README ng plugin ang trustedHosts na Origin/Host fence, hindi identity. Sinasabi rin nito na inilalantad ng pag-bind sa 0.0.0.0 ang authentication surface sa bawat reachable interface. Pinapagana na rin nito ang mga setting na naka-back sa Host para sa isang authenticated remote page, kaya sa kasalukuyang build, maaabot din ng naka-sign-in na remote browser ang Host settings. Lumipat ang panganib ngunit hindi ito nawala: maaaring i-probe ng sinumang makakaabot sa port ang login, credential mismo ang printed URL, at sa plain HTTP, dumadaan sa network ang token bilang cleartext.

Kadalasan, hindi mo kailangan ang plugin na ito. I-forward na lamang ang port sa SSH.

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

Pagkatapos, buksan ang http://127.0.0.1:3080 sa iyong local browser. Patuloy na nakikinig ang harness sa loopback lamang, kaya walang nailalantad, at dahil itinuturing ng mga browser ang 127.0.0.1 bilang secure origin, available ang crypto.randomUUID() at hindi kailangan ng polyfill. Isang command lamang, walang plugin, at walang bagong attack surface.

I-install lamang ang plugin kapag hindi sapat ang forwarding, halimbawa kung kailangang maabot ng phone na nasa parehong network ang UI. Kung gagawin mo ito, i-bind ito sa likod ng private network interface, panatilihin ang firewall rule na nagpapahintulot lamang sa interface na iyon, at ilista ang anumang hostname na gagamitin mo sa ilalim ng trustedHosts. Sa plugin 1.4.0, nasa connection entry ang listahang iyon. Pinapalitan ng literal na listahan ang mga interface address na dina-derive ng plugin sa halip na idagdag ang mga ito, kaya isama sa listahan ang mga IP na iyon. Para sa tunay na multi-user access, may dsh-passwords. Nagdaragdag ito ng login, subuser permissions, per-subuser hourly token at daily time caps, automatic TLS (transport layer security) certificates sa pamamagitan ng Let's Encrypt sa host install, audit log, at encryption ng sensitive field sa SQLite store nito. Suriin ito bilang platform, hindi bilang plugin. Ang inirerekomendang setup nito, na sinuri noong 17 October 2026, ay Docker container na naka-publish sa loopback lamang (-p 127.0.0.1:3088:3088), nagse-serve ng plain HTTP, at nangangailangan ng reverse proxy sa harap nito para sa HTTPS. Kasama lamang sa host install ang automatic HTTPS at kailangan nito ang public ports 80 at 443; hindi kailangan ang port 80 kung magbibigay ka ng sarili mong certificate sa pamamagitan ng MCP_GATEWAY_TLS_CERT at MCP_GATEWAY_TLS_KEY. Ang quick path ng host install ay nagpi-pipe ng shell script mula sa network direkta sa sudo bash. Kung mag-i-install ka sa host, mas mainam ang npm install -g dsh-passwords na sinusundan ng sudo dsh-passwords install, upang nasa disk ang code at mabasa mo muna ito bago tumakbo.

Paano mag-alis ng plugin nang malinis

Dalawang hakbang ang pag-uninstall, pero madalas nakakaligtaan ang ikalawang hakbang.

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

Hindi na dapat ito ipakita ng list. Pagkatapos, buksan ang $DSH_HOME/profiles/web/cordis.patch.yml at tanggalin ang anumang natitirang insert block na naglalaman ng pangalan ng plugin na iyon, dahil ang entry na iyon ang naglo-load dito sa tree. I-restart ang harness para mabuo muli ang tree; mananatiling naka-load ang plugin na na-load na hanggang sa gawin mo ito. Panghuli, tandaan na mas matagal na nananatili ang data kaysa sa code. Nananatili ang $DSH_HOME/memory/memory.db at .dsh/rules.yaml kahit na-uninstall na. Tanggalin mismo ang mga ito kung layunin mong alisin ang data.

Ano ang binasa ko, at kailan

Ang bawat reference dito ay isang commit, hindi isang branch, dahil iba na ang code ng main kapag binasa mo ito. Binasa ko ang lahat noong 17 August 2026, at nasa 0.1.0-rc.7 sa npm ang harness mismo noong araw na iyon. Muli kong sinuri ang mga default at behavior na inilarawan sa itaas laban sa mga pangunahing source noong 10 October 2026, nang ang latest tag sa npm ay 0.2.0-rc.2, at muli kong sinuri ang idineklarang harness compatibility ng mga plugin noong 16 October 2026, nang ganoon pa rin ito. Noong 17 October 2026, muli kong sinuri ang profile layout laban sa harness architecture doc, sa dalawang dsh-memory README at sa dsh-passwords README; nasa 0.2.0-rc.2 pa rin ang latest noong araw na iyon. Noong 18 October 2026, muli kong sinuri ang dalawang dsh-memory build at ang kasalukuyang dsh-web-lan-access package at README; nasa 0.2.0-rc.2 pa rin ang latest, na may 0.2.1-rc.2 sa next tag.

Suriing muli ang mga pin na iyon bago ka kumopya ng command. Sa isang developer-preview ecosystem, ang version number na may kasamang petsa ang tanging may malinaw na kahulugan.

FAQ

Aling DeepSeek Harness plugins ang dapat ko munang i-install sa isang VPS?

I-install muna ang dsh-budget at dsh-permission-rules bago ang iba. Pinipigilan ng budget na may overLimit: block ang unattended run na gumastos buong gabi, at pinipigilan ng .dsh/rules.yaml file ang tool call na hindi mo kailanman inaprubahan. Idagdag ang dsh-defend kapag may binabasa ang agent mula sa public web, at ang dsh-memory kapag napapansin mong pareho ang context na ipinapaste mo sa bawat session. Laktawan ang themes at status chips: nagdadagdag ang mga ito ng code na tumatakbo gamit ang privileges ng agent nang hindi binabago ang ginagawa ng machine.

Naka-sandbox ba ang dsh plugins mula sa harness?

Hindi. Naglo-load ang plugin sa parehong Cordis tree ng harness, sa parehong process, bilang parehong operating system user, at gamit ang parehong model credentials at working tree. Nakikita at maaaring i-block ng plugin na kumokonekta sa tools/pre-execute ang bawat tool call; nakikita naman ng kumokonekta sa agent/pre-step ang iyong mga mensahe. Kaya basahin ang source, tingnan ang license at petsa ng huling commit, at mag-install batay sa commit sa halip na branch upang hindi mabago ang code nang hindi mo nalalaman.

Talaga bang ihihinto ng dsh-budget ang agent, o magbibigay lang ito ng babala?

Depende ito sa overLimit. Ang default ay alert, na nagbibigay ng babala sa warnRatio at patuloy na gumagastos. Tinatanggihan ng block ang mga kasunod na model call kapag naabot ang cap, at inaalis ito ng /budget unblock <scope> kapag pinili mong magpatuloy. Nagba-block ang degrade at nagbibigay ng gabay na tumutukoy sa mas murang model mula sa degradation map. May isang limitasyon: sa commit na naka-pin sa 461d478, ina-aggregate ang mga total sa tumatakbong process, kaya nire-reset ng pag-restart ng harness ang mga ito at malalampasan ng restart loop ang daily cap. Awtomatikong pinapanatili ng kasalukuyang main ang day at month buckets kahit mag-restart. Sa alinmang paraan, magtakda ng spend limit sa provider account bilang aktuwal na ceiling.

Paano ko ganap na aalisin ang isang dsh plugin?

Patakbuhin ang dsh plugin --profile web remove <package-name>, kumpirmahin gamit ang dsh plugin --profile web list, pagkatapos ay buksan ang $DSH_HOME/profiles/web/cordis.patch.yml at tanggalin ang anumang natitirang insert block para sa plugin na iyon, dahil ang entry na iyon ang naglo-load dito. I-restart ang harness upang mabuo muli ang plugin tree. Mananatili sa disk ang data na isinulat ng plugin: parehong mananatili ang $DSH_HOME/memory/memory.db at .dsh/rules.yaml hanggang ikaw mismo ang mag-delete sa mga ito.

Ligtas bang i-expose sa network ang dsh web UI?

Hindi kung mag-isa lamang ito. Nakikinig ang dsh web sa 127.0.0.1:3080, at binabago ng dsh-web-lan-access ang binding na iyon sa 0.0.0.0. Sa commit na binanggit dito, nakasaad sa README nito na dahil dito ay maa-access ang agent nang walang authentication ng sinumang nasa parehong network, habang ang settings.*, credentials.* at llm.discoverModels lamang ang naka-pin sa loopback. Ang kasalukuyang harness builds, na sinuri noong 10 October 2026, ay nag-a-authenticate sa browser session gamit ang launch token sa naka-print na URL at signed session cookie, ngunit nakalantad na sa bawat interface ang login surface, at ipinapadala ng plain HTTP URL ang token nang cleartext. Gumamit ng SSH port forward, ssh -N -L 3080:127.0.0.1:3080 you@your-server, o ilagay ang port sa likod ng private network interface at firewall rule, at maglagay ng TLS sa harap ng anumang maa-access mula sa labas.