DeepSeek Harness साठी सर्वोत्तम 5 प्लगइन्स

कोणते DeepSeek Harness प्लगइन्स इन्स्टॉल करणे फायदेशीर आहे

DeepSeek Harness प्लगइन्स हे थर्ड-पार्टी कोड आहेत जे तुमच्या एजंटच्या आत, तुमच्या एजंटच्या अधिकारांसह आणि तुम्ही पैसे भरलेल्या मशीनवर चालतात. कम्युनिटी लिस्टमध्ये वीसपेक्षा जास्त श्रेणी आणि हजाराहून अधिक एन्ट्रीज आहेत. भाड्याने घेतलेल्या व्हर्च्युअल प्रायव्हेट सर्व्हरवर (VPS) तुम्हाला पाच गोष्टींची गरज आहे: खर्चाच्या मर्यादेसाठी dsh-budget, टूल गेटिंगसाठी dsh-permission-rules, इंजेक्शन आणि सीक्रेट स्कॅनिंगसाठी dsh-defend, सेशन संपल्यानंतरही टिकून राहणाऱ्या माहितीसाठी dsh-memory, आणि तुम्ही ऑथेंटिकेशन कसे करणार हे ठरवल्यानंतरच dsh-web-lan-access.

हे हार्नेस dsh आहे, जे DeepSeek चे ओपन-सोर्स एजंट हार्नेस आहे आणि ते अशा प्रकारे बनवले आहे की प्रत्येक गोष्ट एक प्लगइन आहे. त्याच्या स्वतःच्या README मध्ये याला डेव्हलपर प्रिव्ह्यू म्हटले आहे आणि THERE WILL BE COMPATIBILITY-BREAKING CHANGES असा इशारा दिला आहे. ही एकच गोष्ट खालील प्रत्येक निवडीला आकार देते. तुम्ही जे इन्स्टॉल करता ते पिन करा, अपग्रेडमुळे ते बंद पडण्याची अपेक्षा ठेवा आणि प्लगइन्सची संख्या इतकी कमी ठेवा की तुम्ही ते सर्व वाचू शकाल. जर हार्नेस अजून सुरू नसेल, तर VPS वर DeepSeek Harness इन्स्टॉल करण्यापासून सुरुवात करा आणि मग इथे परत या. जर हे प्लगइन्स ज्या भागांशी जोडले जातात, जसे की एजंट लूप, त्याची टूल्स, त्याची मेमरी, हे अजूनही अस्पष्ट वाटत असेल, तर प्रथम मूलभूत गोष्टी समजून घ्या, कारण प्रत्येक लेयर काय काम करत आहे हे समजल्यावर खालील प्रत्येक निवड ठरवणे सोपे जाते.

dsh प्लगइन कसे इन्स्टॉल करतो आणि कॉन्फिगरेशन कोठे साठवले जाते

dsh स्वतःला Cordis प्लगइन्सपासून एकत्रित करते, त्यामुळे चालू असलेले इन्स्टन्स हे एका प्रोग्रामऐवजी प्लगइन्सचे एक ट्री (tree) असते. प्रोफाइल म्हणजे त्या प्लगइन्सची एक नामनिर्देशित रचना होय. दोन टेम्पलेट्स web आणि headless आहेत. $DSH_HOME डीफॉल्टनुसार ~/.dsh वर असते आणि प्रोफाइल $DSH_HOME/profiles/<name>/ येथे राहते, ज्यामध्ये स्वतःची package.json, एक dsh.profile मॅनिफेस्ट आणि एक cordis.patch.yml असते.

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

चार प्रकारचे सोर्स फॉर्म काम करतात: एक साधा npm पॅकेज नेम, @towzai/dsh-memory सारखे स्कोप्ड नेम, github:PerryLink/dsh-budget#main सारखा GitHub संदर्भ आणि link: किंवा ./ सह एक लोकल पाथ. GitHub फॉर्मचा वापर करा, कारण तुम्ही #main ला कमिटने बदलू शकता आणि पुढच्या महिन्यात तोच कोड पुन्हा मिळवू शकता.

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

लेयर्स एका निश्चित क्रमाने लागू होतात: प्रोफाइलच्या यादीतील क्रमानुसार प्रत्येक बंडल, त्यानंतर प्रोफाइलची cordis.patch.yml, त्यानंतर होम-लेव्हलची cordis.patch.yml आणि शेवटी कोणतीही --patch ओव्हरले. क्रम महत्त्वाचा असतो कारण नंतरची लेयर आधीच्या लेयरने सेट केलेल्या गोष्टी पुन्हा कॉन्फिगर करू शकते किंवा काढून टाकू शकते. त्यामुळे जेव्हा एखादे प्लगइन इन्स्टॉल झाल्यासारखे वाटते पण काहीही काम करत नाही, तेव्हा प्रोफाइलची cordis.patch.yml उघडा आणि दोन गोष्टी तपासा: त्याचा इन्सर्ट ब्लॉक तिथे आहे का आणि नंतरच्या कोणत्याही लेयरने ते डिसेबल केलेले नाही ना.

17 ऑगस्ट 2026 पर्यंत, npm पॅकेज @deepseek-ai/dsh हे 0.1.0-rc.7 वर आहे, तर त्याखालील प्रत्येक प्लगइन 0.1.0-rc.5 ते 0.1.0-rc.6 सह सुसंगतता घोषित करते. या इकोसिस्टममध्ये ही तफावत सामान्य आहे आणि प्लगइन लोड होणे थांबण्याचे हेच नेहमीचे कारण असते: हार्नेस (harness) त्याच्या सभोवतालच्या प्लगइन्सपेक्षा वेगाने अपडेट होतो. हार्नेस मुद्दाम अपग्रेड करा आणि त्यानंतर एका वेळी एक प्लगइन तपासा.

प्लगइनवर विश्वास ठेवण्यापूर्वी ते तपासा

dsh प्लगइन हे हार्नेसपासून सँडबॉक्स केलेले नसते. ते त्याच Cordis ट्रीमध्ये, त्याच प्रोसेसमध्ये आणि त्याच ऑपरेटिंग सिस्टम युजरच्या अधिकारांसह लोड होते. त्याला त्याच मॉडेल क्रेडेंशियल्स आणि वर्किंग ट्रीचा ॲक्सेस असतो. एखादे प्लगइन इन्स्टॉल करणे म्हणजे ब्राउझर एक्स्टेंशन जोडण्यापेक्षा, दुसऱ्याची स्क्रिप्ट sudo वापरून चालवण्यासारखे आहे. हाच विश्वासाचा प्रश्न Claude Code प्लगइन्सच्या बाबतीत उद्भवतो, आणि त्याचे उत्तरही तेच आहे: कोड वाचा किंवा ते इन्स्टॉल करू नका.

खालील चार गोष्टी या क्रमाने तपासा:

• ते कोणत्या एक्सटेन्शन पॉइंट्सचा वापर करते. tools/pre-execute चा अर्थ असा की ते प्रत्येक टूल कॉल पाहू शकते आणि तो ब्लॉक करू शकते. agent/pre-step चा अर्थ असा की ते तुमचे मेसेज पाहू शकते. webServer.tapIndex चा अर्थ असा की ते तुमच्या ब्राउझरला सर्व्ह होणारे पेज पुन्हा लिहू शकते. ज्या प्लगइनचा यापैकी कशाशीही संबंध नाही ते फार कमी काम करू शकते; मात्र जे प्लगइन या सर्वांचा वापर करते, तेच तुमची सुरक्षा सीमा (security boundary) ठरते.
• ते नेटवर्कशी संवाद साधते का. सोर्स कोडमध्ये fetch, http आणि कोणत्याही हार्ड-कोडेड होस्टनेमसाठी सर्च करा. जर एखादे कॉस्ट मीटर माहिती बाहेर पाठवत असेल, तर ते तुमच्या वापराची पद्धत कुठेतरी पाठवत आहे.
• ते क्रेडेंशियल्स वाचते का. credentials.* किंवा प्रोव्हायडर की ला स्पर्श करणाऱ्या कोणत्याही गोष्टीचे कारण README मध्ये स्पष्ट केलेले असावे.
• परवाना आणि शेवटच्या कमिटची तारीख. दर आठवड्याला बदलणाऱ्या इकोसिस्टममध्ये, विना-परवाना असलेले आणि कित्येक महिन्यांपासून अपडेट न झालेले प्लगइन एक धोका ठरू शकते.

त्यानंतर, ब्रांचऐवजी कमिट आयडी वापरून इन्स्टॉल करा आणि इन्स्टॉलरने cordis.patch.yml मध्ये लिहिलेला इन्सर्ट ब्लॉक वाचा. तो ब्लॉक प्लगइन आयडी आणि त्याने नोंदणी केलेली कॉन्फिगरेशन दर्शवतो, जे तुम्ही काय जोडले आहे याचे सर्वात अचूक आणि प्रामाणिक वर्णन आहे. जिथे हार्नेस परवानगी देतो, तिथे प्रोव्हायडर की प्लगइनच्या आवाक्याबाहेर ठेवा, जसे की AI एजंट्सपासून सीक्रेट्स दूर ठेवणे या लेखात सांगितले आहे.

dsh-budget: एजंट रात्रभर खर्च करत असेल तर ते कसे थांबवावे?

एका VPS वर एजंट विना देखरेख (unattended) चालतो. त्याला तिथे ठेवण्याचा उद्देशच हा आहे, पण तोच एक धोकाही आहे. dsh-budget प्रत्येक मॉडेलसाठी, प्रत्येक सत्रासाठी आणि दररोजच्या टोकन्सचे आणि अंदाजित खर्चाचे मोजमाप करते आणि त्या एकूण रकमेवर मर्यादा (caps) लादते.

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

याचे डीफॉल्ट सेटिंग्ज उदार आहेत: प्रति सत्र 10 USD, दररोज 50 आणि दरमहा 500 USD. हे निधी असलेल्या टीमसाठी योग्य आहेत. वैयक्तिक सर्व्हरवर या मर्यादा इतक्या जास्त आहेत की एखादी अनियंत्रित लूप (runaway loop) मर्यादा गाठण्यापूर्वीच संपू शकते, म्हणून पहिल्याच दिवशी त्या कमी करा.

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

सुचवलेला रकाना हा एका ऑपरेटरसाठी एका बॉक्सवर सुरूवातीचा बिंदू आहे, ही काही प्रकाशित आकडेवारी नाही. प्रत्यक्ष वापराचा एक महिना पूर्ण झाल्यावर जेव्हा तुम्हाला गरज वाटेल तेव्हा ती वाढवा. 40 USD ची मासिक मर्यादा आणि 2 ची सत्र मर्यादा लवकर आणि स्पष्टपणे अपयशी ठरते, जे तुम्ही टूलची क्षमता शिकत असताना अपेक्षित असते.

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

मशीन कसे वागेल हे ठरवणारे सेटिंग overLimit आहे. याचे डीफॉल्ट alert आहे, जे फक्त एक चेतावणी देते आणि खर्च सुरू ठेवते, त्यामुळे हे प्लगइन सुरुवातीला फक्त एक डॅशबोर्ड म्हणून काम करते. ते block वर सेट करा, म्हणजे मर्यादा गाठल्यावर हार्नेस पुढील मॉडेल कॉल्स नाकारेल. याचा अर्थ असा की, रात्रभर चालणारे काम सकाळी बिल येण्यापूर्वीच थांबेल. degrade हा तिसरा मोड आहे: तो मॉडेल बदलून degradation मॅपमधील स्वस्त मॉडेल वापरतो. जेव्हा काम पूर्ण होणे आवश्यक असते पण त्यासाठी सर्वोत्तम मॉडेलची गरज नसते, तेव्हा हे योग्य ठरते. warnRatio डीफॉल्टनुसार 0.8 वर असते, त्यामुळे मर्यादेच्या 80 टक्के खर्च झाल्यावर तुम्हाला त्याबद्दल माहिती मिळते.

दोन महत्त्वाच्या मर्यादा लक्षात घ्या. खर्च तुम्ही दिलेल्या किमतींवरून मोजला जातो: prices डीफॉल्टनुसार रिकामे असते आणि defaultPrice प्रति दशलक्ष इनपुट टोकन्ससाठी 1.0 USD आणि आउटपुटसाठी 3.0 USD वर आधारित असते. तुमच्या मॉडेल्ससाठी प्रत्यक्ष आकडे भरा, अन्यथा डॅशबोर्डचे मोजमाप केवळ एक अंदाज असेल. दुसरे म्हणजे, प्लगइन सत्र इव्हेंट स्ट्रीममधून चालू असलेल्या प्रक्रियेत डेटा एकत्रित करते, त्यामुळे हार्नेस रीस्टार्ट झाल्यावर एकूण बेरीज रिसेट होते. क्रॅश लूप किंवा dsh ला रीस्टार्ट करणारा सुपरव्हायझर दैनंदिन मर्यादा रिसेट करतो. dsh-budget ला तुमच्या स्वतःच्या कामांविरुद्ध एक सुरक्षा कवच (guardrail) म्हणून वापरा आणि प्रत्यक्ष खर्चाची मर्यादा तुमच्या प्रोव्हायडर अकाउंटवर ठेवा, ज्याबद्दल अधिक माहिती VPS वर AI एजंटचा खर्च नियंत्रित करणे येथे दिली आहे.

दैनंदिन वापरासाठी तुम्ही ओव्हरव्ह्यू पाहण्यासाठी /budget, प्रति-मॉडेल ब्रेकडाउनसाठी /budget models आणि काम सुरू ठेवण्याचा निर्णय घेतल्यावर ब्लॉक काढण्यासाठी /budget unblock <scope> वापरू शकता.

dsh-permission-rules: कोणत्या टूल कॉल्सना कधीही रन होऊ देऊ नये?

dsh-permission-rules हे tools/pre-execute वॉटरफॉलवर डिक्लेरेटिव्ह नियम लागू करते, त्यामुळे टूल रन होण्यापूर्वी नियमाचे मूल्यमापन केले जाते. यामध्ये तीन कृती उपलब्ध आहेत. allow कॉलला पुढे जाऊ देते, deny त्याला ब्लॉक करते आणि मॉडेलला वाचता येईल असे कारण परत करते, आणि ask त्याला अधिकृत मंजुरीच्या सीम (approval seam) कडे वळवते.

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

नियम हे सेशनच्या वर्किंग डिरेक्टरीच्या संदर्भात .dsh/rules.yaml मध्ये असतात, ज्यामध्ये एक ग्लोबल fallbackPath आणि फाइलसिस्टम रूटच्या दिशेने वर जाण्यासाठी पर्यायी searchUp असते. मॅचिंगमध्ये टूल-नेम ग्लोब्स (globs), पॅरामीटर की आणि व्हॅल्यू ग्लोब्स, वर्कस्पेस-रिलेटिव्ह पाथ ग्लोब्स, main किंवा subagent सारखे एजंट सिलेक्टर्स आणि नेटवर्क टार्गेट्स यांचा समावेश होतो.

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) हे धोरण वापरले जाते, त्यामुळे वरच्या बाजूला असलेला एखादा व्यापक allow नियम त्याच्या खालील सर्व मर्यादित नियमांना शांतपणे रद्द करतो. त्यामुळे नाकारण्याचे (denials) नियम आधी लिहा आणि परवानगी देणारे (permissive) नियम शेवटी लिहा. टूल-नेम ग्लोबमध्ये mcp__* चा समावेश होतो, ज्याद्वारे तुम्ही अशा टूल्सवर नियंत्रण ठेवू शकता जी हार्नेसऐवजी मॉडेल कॉन्टेक्स्ट प्रोटोकॉल (MCP) सर्व्हरवरून येतात. जेव्हा तुम्ही VPS वर MCP सर्व्हर्स चालवता, तेव्हा हे महत्त्वाचे ठरते.

नियोजनासाठी एक वर्तन लक्षात घेणे आवश्यक आहे: ask ला उत्तर देणाऱ्याची (answerer) गरज असते. headless प्रोफाइलवर कदाचित कोणीही लक्ष ठेवून नसेल, त्यामुळे ask नियम एखादी रन कोणीतरी येईपर्यंत थांबवून ठेवू शकतो. ज्या गोष्टींना तुम्ही कधीही मंजुरी देणार नाही त्यासाठी deny वापरा, ज्या प्रोफाइलसमोर तुम्ही स्वतः बसता त्यासाठी ask ठेवा, आणि जर तुम्हाला मंजुरीची प्रक्रिया विना-हस्तक्षेप (unattended) सुरू ठेवायची असेल, तर तुम्हाला खऱ्या अर्थाने उत्तर देणारा मार्ग आवश्यक आहे, जो AI एजंटच्या कृतींना मंजुरीसह नियंत्रित करणे या विषयाचा भाग आहे.

dsh-defend: प्रॉम्प्ट इंजेक्शन आणि लीक झालेल्या सीक्रेट्सचे काय?

dsh-defend तीन टप्प्यांवर स्कॅन करते: agent/pre-step वरील येणारे संदेश, tools/pre-execute वरील टूल आर्ग्युमेंट्स (ज्यामध्ये डिस्ट्रक्टिव्ह-डिलीट गार्डचा समावेश आहे), आणि tools/post-execute वरील टूल रिझल्ट्स. शेवटचा टप्पा महत्त्वाचा आहे, कारण वेब पेजवरून मिळवलेली माहिती मॉडेलने त्यावर प्रक्रिया करण्यापूर्वी येथे तपासली जाते.

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

डीफॉल्ट सेटिंग्ज कठोर नसून सावधगिरी बाळगणाऱ्या आहेत: detection.injectionAction, detection.jailbreakAction आणि detection.secretAction हे सर्व ask वर सेट केलेले आहेत, तर detection.secretBlockCritical हे true वर आहे, त्यामुळे इतर सेटिंग्ज काहीही असल्या तरी महत्त्वाचे सीक्रेट ब्लॉक केले जाते. अनअटेंडेड (विना देखरेख) सर्व्हरवर तुम्हाला महत्त्वाच्या वाटणाऱ्या कृती block वर बदला, कारण कोणालाही विचारण्याची सोय नसताना ask करणे हा निर्णय असू शकत नाही.

ऑडिट डिझाइन कौतुकास्पद आहे. defend/detection इव्हेंट्समध्ये रूल आयडी, फॅमिली, कॅटेगरी, सीव्हेअरिटी, निर्णय आणि स्कॅन फॅक्ट्स नोंदवले जातात, परंतु मॅच झालेला मजकूर कधीही नोंदवला जात नाही; सीक्रेट्स फक्त त्यांच्या प्रकारानुसार नोंदवले जातात. त्यामुळे ऑडिट लॉग सुरू केल्याने तुम्ही ज्या क्रेडेंशियलचे संरक्षण करण्याचा प्रयत्न करत आहात, त्याची दुसरी प्रत तयार होत नाही.

यामुळे तुम्हाला नक्की काय मिळते हे स्पष्ट असावे. डिटेक्शन हे नियमांवर आधारित आहे आणि README मध्ये स्पष्टपणे नमूद केले आहे की नवीन प्रकारची वाक्यरचना आणि बहु-स्तरीय हल्ले यातून सुटू शकतात. हे स्पष्ट हल्ल्यांचे प्रमाण कमी करते. हे एजंटला असुरक्षित मजकुरासाठी पूर्णपणे सुरक्षित बनवत नाही, त्यामुळे त्याखालील परमिशन रूल्स कायम ठेवा.

dsh-memory: एजंटला उद्या काय आठवेल?

dsh-memory नावाचे दोन वेगळे प्लगइन्स उपलब्ध आहेत, त्यामुळे इन्स्टॉल कमांड टाईप करण्यापूर्वी हे जाणून घेणे महत्त्वाचे आहे. तुम्ही ज्याबद्दल वाचले आहे तेच मिळवण्यासाठी स्पष्ट स्त्रोतावरून (source) इन्स्टॉल करा.

मी लहान सर्व्हरवर SQLite बिल्ड वापरण्याचा सल्ला देईन. हे memory म्हणून नोंदणीकृत होते, सर्व प्रोफाइल्ससाठी $DSH_HOME/memory/memory.db वर एक फाईल साठवते आणि memory_write, memory_search व memory_forget उघड करते. यामध्ये साठवलेला मजकूर आणि टॅग्सवर आधारित कीवर्ड-आधारित शोध (search) घेता येतो. यात कोणतीही एम्बेडिंग सर्व्हिस, API की किंवा अतिरिक्त प्रोसेस नसते.

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

तुम्हाला फक्त थोड्या कॉन्फिगरेशनमध्ये बदल करावा लागेल: डेटाबेस फाईलसाठी path, किती अनपिन केलेल्या मेमरीज इंजेक्ट करायच्या आहेत यासाठी promptRecentCount (डीफॉल्ट 10) आणि रेंडरिंग बजेटसाठी promptMaxChars (डीफॉल्ट 2000). हे node:sqlite वर अवलंबून आहे, जे Node 22 आणि 24 मध्ये अजूनही प्रायोगिक (experimental) मानले जाते, त्यामुळे Node अपग्रेड गृहीत धरण्याऐवजी आधी तपासून पहा.

मेमरीमुळे मशीनमध्ये नेमका काय बदल होतो ते येथे दिले आहे: इंजेक्ट केलेल्या मेमरीज प्रत्येक टर्नवर सिस्टम प्रॉम्प्टमध्ये समाविष्ट केल्या जातात. 2000-कॅरेक्टरचे बजेट म्हणजे प्रत्येक विनंतीवर कायमस्वरूपी काहीशे अतिरिक्त इनपुट टोकन्स. यामुळे तुमच्या बिलात थेट वाढ होऊ शकते, म्हणूनच dsh-memory आधी dsh-budget सर्व्हरवर असणे आवश्यक आहे. promptMaxChars मर्यादित ठेवा आणि फाईलची साईज वाढू न देता memory_forget वापरून ती वेळोवेळी साफ करा.

पर्यायी बिल्ड मेमरीज एका YAML फाईलमध्ये साठवते आणि स्वयंचलित प्रॉम्प्ट इंजेक्शनसह एम्बेडिंग सर्च करते, जे dsh plugin --profile web add github:towzai/dsh-memory वापरून इन्स्टॉल केले जाते. यासाठी स्थानिक ollama इन्स्टन्स आणि एम्बेडिंग मॉडेलची आवश्यकता असते, जे डीफॉल्टनुसार qwen3-embedding:0.6b असते आणि DSH_MEMORY_EMBED_MODEL वापरून बदलता येते. सिमेंटिक रिकॉल (semantic recall) हे कीवर्ड रिकॉलपेक्षा अधिक प्रभावी असते. याचा अर्थ असा की, सर्व्हरवर दुसरी सर्व्हिस आणि मॉडेल वेट्स (model weights) चालू राहतील, ज्यामुळे लहान सर्व्हर प्लॅनवर ज्या कामासाठी तुम्ही सर्व्हर भाड्याने घेतला आहे, त्या कामाची मेमरी कमी होऊ शकते. जेव्हा तुमच्याकडे अतिरिक्त RAM उपलब्ध असेल तेव्हाच हा पर्याय निवडा. रिकॉल गुणवत्ता आणि सर्व्हरवरील लोड यांच्यातील सामान्य तफावत एजंटसाठी स्थानिक मेमरी मध्ये स्पष्ट केली आहे.

dsh-web-lan-access: वेब UI ने लूपबॅकच्या पलीकडे लिसन करावे का?

npx @deepseek-ai/dsh web हे इंटरफेस 127.0.0.1:3080 वर सर्व्ह करते. ब्राउझर केवळ सुरक्षित संदर्भातच crypto.randomUUID() उघड करतात, त्यामुळे दुसऱ्या मशीनवरून साध्या HTTP द्वारे तेच पेज लोड करणे अयशस्वी ठरते. dsh-web-lan-access हे एक लहान polyfill इंजेक्ट करण्यासाठी webServer.tapIndex चा वापर करून ही समस्या सोडवते आणि ते सर्व्हर बाइंडिंग 0.0.0.0 वर बदलते.

तुम्ही ते इंस्टॉल करण्यापूर्वी त्यातील स्वतःची चेतावणी वाचा. 0.0.0.0 बाइंड केल्यामुळे, स्थानिक नेटवर्कवर (LAN) असलेल्या कोणालाही प्रमाणीकरणाशिवाय (authentication) एजंटपर्यंत पोहोचता येते आणि सार्वजनिक IP पत्ता असलेल्या सर्व्हरवर याचा अर्थ संपूर्ण इंटरनेट असा होतो. संवेदनशील पद्धतींची एक छोटी यादी (settings.*, credentials.*, llm.discoverModels) लूपबॅकवरच पिन केलेली राहते आणि रिमोट ओरिजिनवरून 403 एरर देते, ज्यामुळे होणारे नुकसान मर्यादित राहते. हे पूर्णपणे प्रतिबंध करत नाही, कारण टूल-कॉलिंग पृष्ठभाग पोर्ट शोधणाऱ्या कोणासाठीही खुला असतो.

बहुतेक वेळा तुम्हाला या प्लगइनची अजिबात गरज नसते. त्याऐवजी SSH द्वारे पोर्ट फॉरवर्ड करा.

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

त्यानंतर तुमच्या स्थानिक ब्राउझरमध्ये http://127.0.0.1:3080 उघडा. हार्नेस फक्त लूपबॅकवरच लिसन करत राहतो, त्यामुळे काहीही उघड होत नाही आणि ब्राउझर 127.0.0.1 ला सुरक्षित ओरिजिन मानत असल्याने, crypto.randomUUID() उपलब्ध असते आणि कोणत्याही polyfill ची गरज पडत नाही. एक कमांड, कोणतेही प्लगइन नाही, कोणताही नवीन अटॅक सरफेस नाही.

जेव्हा फॉरवर्डिंग शक्य नसेल, उदाहरणार्थ जेव्हा त्याच नेटवर्कवरील फोनला UI पर्यंत पोहोचायचे असेल, तेव्हाच प्लगइन इंस्टॉल करा. जर तुम्ही तसे केले, तर ते खाजगी नेटवर्क इंटरफेसच्या मागे बाइंड करा, फक्त त्या इंटरफेसची परवानगी देणारा फायरवॉल नियम ठेवा आणि तुम्ही वापरणार असलेली नावे web-runtime एंट्रीवरील trustedHosts अंतर्गत सूचीबद्ध करा. खऱ्या अर्थाने मल्टी-युजर ॲक्सेससाठी dsh-passwords उपलब्ध आहे, जे सब-युजर परवानग्या, प्रति सब-युजर तासाचे टोकन आणि दैनंदिन वेळेचा कोटा, Let's Encrypt द्वारे स्वयंचलित TLS (transport layer security) प्रमाणपत्रे आणि एनक्रिप्टेड ऑडिट लॉग जोडते. याला प्लगइनऐवजी एक प्लॅटफॉर्म म्हणून पहा: याला पोर्ट 80 आणि 443 ची गरज असते, हे स्वतःचे इंस्टॉलर सोबत आणते आणि दस्तऐवजीकरण केलेला क्विक पाथ नेटवर्कवरून शेल स्क्रिप्ट थेट bash मध्ये पाईप करतो. npm install -g dsh-passwords आणि त्यानंतर dsh-passwords install वापरणे अधिक श्रेयस्कर आहे, जेणेकरून कोड डिस्कवर राहील आणि रन करण्यापूर्वी तुम्ही तो वाचू शकाल.

प्लगइन पूर्णपणे काढून टाकण्याची पद्धत

अनइन्स्टॉल करण्याची प्रक्रिया दोन टप्प्यांची आहे, परंतु अनेकदा लोक दुसरा टप्पा वगळतात.

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

list मध्ये ते प्लगइन आता दिसू नये. त्यानंतर $DSH_HOME/profiles/web/cordis.patch.yml उघडा आणि त्या प्लगइनचे नाव असलेले कोणतेही उरलेले 'insert block' काढून टाका, कारण त्या एन्ट्रीमुळेच ते ट्री (tree) मध्ये लोड होते. हार्नेस (harness) रीस्टार्ट करा जेणेकरून ट्री पुन्हा तयार होईल; जोपर्यंत तुम्ही असे करत नाही, तोपर्यंत आधीच लोड झालेले प्लगइन मेमरीमध्ये राहते. शेवटी, हे लक्षात ठेवा की डेटा हा कोडपेक्षा जास्त काळ टिकतो. $DSH_HOME/memory/memory.db आणि .dsh/rules.yaml हे अनइन्स्टॉल केल्यानंतरही तसेच राहतात. जर तुमचा उद्देश डेटा काढून टाकणे हा असेल, तर तो तुम्हाला स्वतःहून डिलीट करावा लागेल.

मी काय वाचले आणि कधी

येथे दिलेला प्रत्येक संदर्भ हा एक commit आहे, branch नाही, कारण तुम्ही हे वाचताय तोपर्यंत main मधील कोड बदललेला असेल. मी हे सर्व 17 ऑगस्ट 2026 रोजी वाचले आणि त्या दिवशी npm वर harness स्वतः 0.1.0-rc.7 या आवृत्तीवर होता.

कोणतीही कमांड कॉपी करण्यापूर्वी हे pins पुन्हा तपासा. डेव्हलपर-प्रिव्ह्यू इकोसिस्टममध्ये, तारखेसह असलेला आवृत्ती क्रमांक हाच एकमेव अर्थपूर्ण असतो.

FAQ

VPS वर सर्वात आधी कोणते DeepSeek Harness प्लगइन्स इन्स्टॉल करावेत?

इतर कोणत्याही गोष्टीआधी dsh-budget आणि dsh-permission-rules इन्स्टॉल करा. overLimit: block सह सेट केलेले बजेट एजंटला रात्रभर चालण्यापासून आणि खर्च वाढण्यापासून रोखते, तर .dsh/rules.yaml फाईल तुम्हाला मान्य नसलेल्या टूल कॉल्सना प्रतिबंध करते. जेव्हा एजंट सार्वजनिक वेबवरून माहिती वाचू लागेल तेव्हा dsh-defend जोडा आणि जेव्हा तुम्हाला प्रत्येक सत्रात तोच संदर्भ पुन्हा पुन्हा पेस्ट करावा लागत असल्याचे जाणवेल तेव्हा dsh-memory वापरा. थीम्स आणि स्टेटस चिप्सकडे दुर्लक्ष करा: त्या तुमच्या एजंटच्या अधिकारांसह कोड चालवतात, परंतु मशीनच्या कार्यक्षमतेत कोणताही बदल करत नाहीत.

dsh प्लगइन्स हार्नेसपासून सँडबॉक्स केलेले असतात का?

नाही. प्लगइन हार्नेसच्या त्याच Cordis ट्रीमध्ये, त्याच प्रोसेसमध्ये, त्याच ऑपरेटिंग सिस्टम युजरच्या अधिकारांसह, त्याच मॉडेल क्रेडेंशियल्ससह आणि त्याच वर्किंग ट्रीमध्ये लोड होते. tools/pre-execute वापरणारे प्लगइन प्रत्येक टूल कॉल पाहू शकते आणि रोखू शकते; तर agent/pre-step वापरणारे प्लगइन तुमचे मेसेज पाहू शकते. त्यामुळे सोर्स कोड वाचा, लायसन्स आणि शेवटच्या कमिटची तारीख तपासा. प्लगइन इन्स्टॉल करताना ब्रांचऐवजी कमिट आयडी वापरा, जेणेकरून कोड तुमच्या नकळत बदलला जाणार नाही.

dsh-budget खरोखर एजंटला थांबवते की फक्त इशारा देते?

हे overLimit वर अवलंबून आहे. डीफॉल्ट सेटिंग alert आहे, जी warnRatio वर इशारा देते पण खर्च सुरू ठेवते. block मर्यादा गाठल्यावर पुढील मॉडेल कॉल्स नाकारते आणि /budget unblock <scope> तुम्हाला सुरू ठेवण्याचा पर्याय निवडल्यावर मर्यादा वाढवते. degrade हे degradation मॅपमधील स्वस्त मॉडेलवर स्विच करते. एक महत्त्वाची गोष्ट लक्षात ठेवा: एकूण खर्च सेशन इव्हेंट स्ट्रीममधून रनिंग प्रोसेसमध्ये मोजला जातो, त्यामुळे हार्नेस रीस्टार्ट केल्यास तो रिसेट होतो. रीस्टार्ट लूपमुळे दैनिक मर्यादा ओलांडली जाऊ शकते. त्यामुळे प्रत्यक्ष खर्च मर्यादेसाठी प्रोव्हायडर अकाउंटवरच बजेट लिमिट सेट ठेवा.

मी dsh प्लगइन पूर्णपणे कसे काढून टाकू शकतो?

dsh plugin --profile web remove <package-name> रन करा, dsh plugin --profile web list सह कन्फर्म करा, त्यानंतर $DSH_HOME/profiles/web/cordis.patch.yml उघडा आणि त्या प्लगइनसाठी असलेला इन्सर्ट ब्लॉक डिलीट करा, कारण तोच घटक प्लगइन लोड करतो. हार्नेस रीस्टार्ट करा जेणेकरून प्लगइन ट्री पुन्हा तयार होईल. प्लगइनने लिहिलेला डेटा डिस्कवरच राहतो: $DSH_HOME/memory/memory.db आणि .dsh/rules.yaml हे दोन्ही अनइन्स्टॉल केल्यानंतरही तसेच राहतात, जोपर्यंत तुम्ही ते स्वतः डिलीट करत नाही.

dsh वेब UI नेटवर्कवर उघड करणे सुरक्षित आहे का?

नाही. dsh web हे 127.0.0.1:3080 वर लिसन करते आणि dsh-web-lan-access ते बाइंडिंग बदलून 0.0.0.0 करते. त्याच्या README मध्ये स्पष्ट नमूद केले आहे की, यामुळे एजंट नेटवर्कवरील कोणालाही ऑथेंटिकेशनशिवाय उपलब्ध होतो. जर तो पब्लिक IP वर असेल, तर याचा अर्थ तो इंटरनेटवर उपलब्ध होतो. काही पद्धती (settings.*, credentials.*, llm.discoverModels) लूपबॅकवरच मर्यादित राहतात आणि रिमोट ओरिजिनवरून 403 एरर देतात, ज्यामुळे धोका कमी होतो पण पूर्णपणे टळत नाही. SSH पोर्ट फॉरवर्डिंग, ssh -N -L 3080:127.0.0.1:3080 you@your-server वापरा किंवा पोर्टला प्रायव्हेट नेटवर्क इंटरफेस आणि फायरवॉल नियमांच्या मागे ठेवा. बाहेरून प्रवेश देण्यापूर्वी त्यावर योग्य ऑथेंटिकेशन लागू करा.