بهترین pluginهای DeepSeek Harness برای نصب روی VPS

کدام pluginهای DeepSeek Harness ارزش نصب دارند

pluginهای DeepSeek Harness کدی از طرف اشخاص ثالث هستند که با سطح دسترسی agent شما، داخل agent و روی ماشینی که هزینه آن را پرداخت می‌کنید اجرا می‌شوند. فهرست جامعه کاربری بیش از بیست دسته و بیش از هزار مورد دارد. در یک سرور خصوصی مجازی اجاره‌ای (VPS)، به 5 مورد نیاز دارید: dsh-budget برای تعیین سقف هزینه، dsh-permission-rules برای کنترل دسترسی ابزارها، dsh-defend برای اسکن injection و secret، dsh-memory برای نگهداری factهایی که از یک session فراتر می‌روند، و dsh-web-lan-access فقط پس از آن‌که روش authentication خود را مشخص کردید.

harness همان dsh، یعنی agent harness متن‌باز DeepSeek، است که به‌گونه‌ای ساخته شده است تا همه‌چیز plugin باشد. README خود آن را developer preview معرفی می‌کند و درباره THERE WILL BE COMPATIBILITY-BREAKING CHANGES هشدار می‌دهد. همین واقعیت بر همه انتخاب‌های زیر اثر می‌گذارد. نسخه‌ای را که نصب می‌کنید pin کنید، انتظار داشته باشید یک upgrade آن را از کار بیندازد، و مجموعه را آن‌قدر کوچک نگه دارید که واقعاً بتوانید تمام کد آن را بخوانید. اگر harness هنوز اجرا نمی‌شود، با نصب DeepSeek Harness روی VPS شروع کنید و سپس به این بخش برگردید. اگر بخش‌هایی که این pluginها به آن‌ها متصل می‌شوند—یعنی حلقه agent، ابزارهای آن و memory آن—هنوز برایتان روشن نیست، ابتدا مبانی را مرور کنید؛ زیرا پس از آن‌که بدانید هر لایه چه کاری انجام می‌دهد، ارزیابی هر یک از انتخاب‌های زیر آسان‌تر خواهد بود.

نحوه نصب plugin توسط dsh و محل قرارگیری configuration

dsh خود را از Cordis pluginها تشکیل می‌دهد؛ بنابراین یک نمونه در حال اجرا، درختی از pluginها است، نه یک برنامه واحد. profile ترکیبی نام‌گذاری‌شده از این pluginها است. دو template عبارت‌اند از web و headless. مقدار پیش‌فرض $DSH_HOME، ~/.dsh است و هر profile در $DSH_HOME/profiles/<name>/ قرار دارد و package.json اختصاصی، manifest مربوط به 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 package، نام scoped مانند @towzai/dsh-memory، یک ارجاع GitHub مانند github:PerryLink/dsh-budget#main و یک مسیر محلی با link: یا ./. از شکل GitHub استفاده کنید، چون می‌توانید #main را با یک commit جایگزین کنید و ماه آینده نیز دقیقاً همان کد را دریافت کنید.

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

لایه‌ها با ترتیب ثابتی اعمال می‌شوند: ابتدا هر bundle بر اساس ترتیب فهرست‌شده در profile، سپس cordis.patch.yml مربوط به profile، بعد cordis.patch.yml در سطح home و در پایان هر overlay از نوع --patch. ترتیب اهمیت دارد، چون یک لایهٔ بعدی می‌تواند تنظیمات لایهٔ قبلی را تغییر دهد یا حذف کند. بنابراین وقتی به نظر می‌رسد یک plugin نصب شده است اما کاری انجام نمی‌دهد، cordis.patch.yml مربوط به profile را باز کنید و دو مورد را بررسی کنید: block مربوط به insert وجود داشته باشد و هیچ لایهٔ بعدی آن را غیرفعال نکرده باشد.

در 17 August 2026، npm package مربوط به @deepseek-ai/dsh در نسخهٔ 0.1.0-rc.7 بود، در حالی که pluginهای زیر برای خط نسخهٔ 0.1.0-rc ساخته شده بودند. dsh-permission-rules و dsh-defend سازگاری با 0.1.0-rc.5 تا 0.1.0-rc.6 را اعلام می‌کنند، dsh-budget فقط 0.1.0-rc.6 را اعلام می‌کند، dsh-memory فقط محدوده‌های peer را از ^0.1.0-rc.6 به بعد تعیین می‌کند و dsh-web-lan-access هیچ نسخه‌ای از dsh را اعلام نمی‌کند. در 10 October 2026، tag مربوط به latest در npm برابر با 0.2.0-rc.2 است؛ بنابراین اکنون فاصله بیشتر از زمانی است که این pinها انتخاب شدند. این فاصله در این ecosystem طبیعی است و معمولاً دلیل متوقف‌شدن بارگذاری یک plugin محسوب می‌شود: harness سریع‌تر از pluginهای پیرامون خود پیش می‌رود. harness را آگاهانه upgrade کنید و سپس هر plugin را جداگانه آزمایش کنید.

پیش از اعتماد، کد plugin را بخوانید

یک plugin از نوع dsh از harness ایزوله نیست. این plugin در همان درخت Cordis و همان process، با همان کاربر سیستم‌عامل و با دسترسی به همان model credentials و همان working tree بارگذاری می‌شود. نصب آن بیشتر شبیه اجرای script شخص دیگری با sudo است تا افزودن یک browser extension. این همان پرسش اعتماد است که در pluginهای Claude Code مطرح می‌شود؛ پاسخ نیز همان است: کد را بخوانید یا آن را نصب نکنید.

چهار مورد را به‌ترتیب زیر بررسی کنید:

• این plugin به کدام extension pointها متصل می‌شود. tools/pre-execute یعنی plugin همه tool callها را می‌بیند و می‌تواند آن‌ها را مسدود کند. agent/pre-step یعنی پیام‌های شما را می‌بیند. webServer.tapIndex یعنی صفحه‌ای را که به browser شما ارائه می‌شود بازنویسی می‌کند. pluginی که به هیچ‌کدام از این موارد متصل نباشد، توان محدودی دارد؛ pluginی که به همه آن‌ها متصل باشد، مرز امنیتی شماست.
• آیا با network ارتباط برقرار می‌کند یا نه. کد منبع را برای fetch، http و هر hostname hard-coded جست‌وجو کنید. یک cost meter که اطلاعات را به سرور سازنده ارسال می‌کند، الگوی استفاده شما را به محل دیگری می‌فرستد.
• آیا credentials را می‌خواند یا نه. هر چیزی که به credentials.* یا یک provider key دسترسی دارد، باید در README دلیل مشخصی برای این کار ارائه کند.
• License و تاریخ آخرین commit. plugin بدون license که چند ماه به‌روزرسانی نشده است، در ecosystemی که هر هفته تغییر می‌کند، یک ریسک است.

سپس plugin را با commit نصب کنید، نه با branch، و insert block را که installer در cordis.patch.yml نوشته است بخوانید. این block، plugin id و configuration ثبت‌شده توسط آن را مشخص می‌کند و کوتاه‌ترین توضیح صادقانه درباره چیزی است که به سیستم اضافه کرده‌اید. تا جایی که harness اجازه می‌دهد، provider keyها را از دسترس plugin دور نگه دارید؛ مشابه رویکرد دور نگه‌داشتن secretها از AI agentها.

dsh-budget: چگونه جلوی هزینه‌کرد agent در تمام شب را بگیرم؟

agent روی یک VPS بدون نظارت اجرا می‌شود. هدف از قرار دادن آن روی VPS همین است، اما همین موضوع ریسک نیز ایجاد می‌کند. dsh-budget تعداد tokenها و هزینه تخمینی را برای هر model، هر session و هر روز اندازه‌گیری می‌کند و در برابر این مجموع‌ها سقف اعمال می‌کند.

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

مقادیر پیش‌فرض آن سخاوتمندانه‌اند: 10 USD برای هر session، 50 در روز و 500 در ماه. این مقادیر برای یک تیم دارای بودجه مناسب‌اند. روی یک سرور شخصی، این سقف‌ها آن‌قدر بالا هستند که یک حلقه runaway پیش از فعال‌شدن cap به پایان می‌رسد؛ بنابراین آن‌ها را در همان روز اول کاهش دهید.

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

مقدار پیشنهادی ستون، نقطه شروعی برای یک operator روی یک box است و رقم منتشرشده‌ای نیست. وقتی یک ماه استفاده واقعی نشان داد که به سقف بیشتری نیاز دارید، آن را افزایش دهید. cap ماهانه 40 USD همراه با cap هر session به مقدار 2، خطا را زود و آشکار اعلام می‌کند. تا زمانی که هنوز در حال یادگیری الگوی مصرف tool هستید، همین رفتار مطلوب است.

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

تنظیمی که رفتار machine را تغییر می‌دهد overLimit است. مقدار پیش‌فرض آن alert است؛ این مقدار warning چاپ می‌کند و به spending ادامه می‌دهد. بنابراین در حالت پیش‌فرض، این plugin فقط یک dashboard است. آن را روی block تنظیم کنید تا harness پس از رسیدن به هر cap، model callهای بیشتری را رد کند. در این حالت، یک job شبانه متوقف می‌شود و تا صبح هزینه ایجاد نمی‌کند. degrade mode سوم است: call را همراه با راهنمایی برای استفاده از model ارزان‌تر موجود در map مربوط به degradation مسدود می‌کند. این mode زمانی مناسب است که job باید کامل شود، اما به بهترین model شما نیاز ندارد. مقدار پیش‌فرض warnRatio، 0.8 است؛ بنابراین در 80 درصد cap از آن مطلع می‌شوید.

دو محدودیت مهم وجود دارد. هزینه بر اساس price table داخلی محاسبه می‌شود که با قیمت‌هایی که شما ارائه می‌کنید ادغام شده است؛ maintainer هشدار می‌دهد که قیمت‌های داخلی ممکن است تغییر کنند. prices به‌طور پیش‌فرض خالی است. در commit ثابت‌شده 461d478، defaultPrice، یعنی fallback برای modelی که در هیچ‌یک از دو table وجود ندارد، 1.0 USD به ازای هر یک میلیون input token و 3.0 به ازای هر یک میلیون output token است. اما در main فعلی که در 10 October 2026 بررسی شده، مقدار پیش‌فرض آن zero است و model بدون قیمت نمایش داده می‌شود. اعداد واقعی modelهای خود را وارد کنید؛ در غیر این صورت dashboard فقط حدسی است که به شکل measurement ارائه شده است.

محدودیت دوم این است که در 461d478، plugin داده‌ها را در process در حال اجرا و از روی session event stream تجمیع می‌کند. بنابراین با restart شدن harness، totalها reset می‌شوند. یک crash loop یا supervisorی که dsh را restart می‌کند نیز cap روزانه را reset می‌کند. در main فعلی، bucketهای روزانه و ماهانه به‌طور پیش‌فرض persist می‌شوند (persistence.enabled: true، با snapshot‌گیری هر 10 ثانیه) و هنگام startup بازیابی می‌شوند. بنابراین restart دیگر cap روزانه یا ماهانه را در آنجا پاک نمی‌کند، مشروط بر آن‌که harness، storage domain را فراهم کند؛ بدون آن، aggregation همچنان محدود به process می‌ماند. main همچنین برای خط harness مربوط به 0.2 است؛ بنابراین تغییر pin به معنای تغییر harness نیز هست. در هر دو حالت، dsh-budget را guardrailی در برابر jobهای خودتان در نظر بگیرید و یک spend limit را در account مربوط به provider به‌عنوان سقف واقعی نگه دارید. این موضوع، استدلال گسترده‌تر درباره کنترل هزینه agentهای AI روی VPS است.

در استفاده روزمره، برای overview از /budget، برای تفکیک بر اساس model از /budget models و برای رفع block پس از تصمیم به ادامه کار از /budget unblock <scope> استفاده می‌کنید.

dsh-permission-rules: کدام فراخوانی‌های ابزار نباید هرگز اجرا شوند؟

dsh-permission-rules قواعد اعلانی را روی زنجیرهٔ tools/pre-execute قرار می‌دهد؛ بنابراین هر قاعده پیش از اجرای ابزار ارزیابی می‌شود. 3 اقدام وجود دارد. allow فراخوانی را عبور می‌دهد، deny آن را مسدود می‌کند و دلیلی را برمی‌گرداند که مدل می‌تواند بخواند، و ask آن را به مسیر رسمی تأیید هدایت می‌کند.

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

قواعد در .dsh/rules.yaml و نسبت به working directory نشست قرار دارند. یک fallbackPath سراسری و یک searchUp اختیاری نیز برای حرکت به سمت ریشهٔ filesystem وجود دارد. تطبیق شامل globهای نام ابزار، globهای کلید و مقدار پارامتر، globهای مسیرهای نسبی به workspace، انتخاب‌گرهای agent مانند 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"

ارزیابی بر اساس نخستین تطبیق انجام می‌شود؛ بنابراین یک allow گسترده در ابتدای فهرست، همهٔ قواعد محدودتر پس از خود را بدون اعلام لغو می‌کند. قواعد منع را ابتدا و قواعد مجازکننده را در انتها بنویسید. glob نام ابزار شامل mcp__* نیز می‌شود. به این ترتیب می‌توانید ابزارهایی را کنترل کنید که از یک سرور model context protocol (MCP) آمده‌اند، نه از خود harness. این موضوع به‌محض اجرای سرورهای MCP روی یک VPS اهمیت پیدا می‌کند.

باید برای یک رفتار مشخص برنامه‌ریزی کنید: ask به یک پاسخ‌دهنده نیاز دارد. در یک پروفایل headless ممکن است کسی در حال نظارت نباشد، و یک ask بدون پاسخ منتظر ظاهرشدن فردی نمی‌ماند. اگر پاسخ‌دهنده‌ای پیکربندی نشده باشد، زنجیرهٔ تأیید harness به‌صورت پیش‌فرض بسته عمل می‌کند و فراخوانی رد می‌شود. بنابراین در یک سیستم بدون نظارت، قاعدهٔ ask عملاً مانند یک deny عمل می‌کند که عمداً ننوشته‌اید. برای هر چیزی که هرگز تأیید نمی‌کنید از deny استفاده کنید، ask را برای پروفایلی نگه دارید که جلوی آن می‌نشینید، و اگر می‌خواهید تأییدها در حالت بدون نظارت کار کنند، به یک مسیر پاسخ‌گویی واقعی نیاز دارید؛ موضوعی که در کنترل اقدامات AI agent با تأییدها بررسی می‌شود.

dsh-defend: دربارهٔ prompt injection و افشای secretها چه می‌دانیم؟

dsh-defend در 3 نقطه اسکن انجام می‌دهد: پیام‌های ورودی در 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 است؛ بنابراین یک secret بحرانی، صرف‌نظر از تنظیمات دیگر، مسدود می‌شود. در یک سرور unattended، اقدام‌های موردنظر خود را روی block تنظیم کنید، زیرا ask بدون کسی که بتوان از او سؤال کرد، تصمیم‌گیری محسوب نمی‌شود.

طراحی audit شایستهٔ تقدیر است. رویدادهای defend/detection شناسهٔ rule، family، category، severity، decision و facts مربوط به اسکن را ثبت می‌کنند، اما هرگز متن منطبق‌شده را ثبت نمی‌کنند؛ secretها فقط بر اساس type ثبت می‌شوند. بنابراین فعال‌کردن audit log یک نسخهٔ دوم از credential مورد حفاظت ایجاد نمی‌کند.

دقیقاً مشخص کنید این سازوکار چه مزیتی دارد. تشخیص بر اساس rule انجام می‌شود و README صراحتاً می‌گوید که عبارت‌بندی‌های جدید و حمله‌های چندمرحله‌ای می‌توانند از آن عبور کنند. این سازوکار نرخ حمله‌های آشکار را کاهش می‌دهد. اما باعث نمی‌شود بتوانید یک agent را با خیال راحت در معرض محتوای غیرقابل‌اعتماد قرار دهید؛ بنابراین permission ruleها را همچنان در لایهٔ زیرین آن حفظ کنید.

dsh-memory: عامل فردا چه چیزی را به یاد می‌آورد؟

دو افزونهٔ متفاوت با نام dsh-memory وجود دارد. پیش از واردکردن دستور نصب، دانستن این موضوع مهم است. نصب را با تعیین صریح source انجام دهید تا همان افزونه‌ای را دریافت کنید که دربارهٔ آن مطالعه کرده‌اید.

برای یک سرور کوچک، من build مبتنی بر SQLite را انتخاب می‌کنم. این build با نام memory ثبت می‌شود، یک فایل را در مسیر $DSH_HOME/memory/memory.db بین profileها به‌اشتراک می‌گذارد و memory_write، memory_search و memory_forget را در اختیار شما قرار می‌دهد. جست‌وجو بر اساس keyword روی متن و tagهای ذخیره‌شده انجام می‌شود. به embedding service، API key یا process اضافی نیاز ندارد.

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

پیکربندی موردنیاز کوچک است: path برای فایل database، promptRecentCount با مقدار پیش‌فرض 10 برای تعیین تعداد memoryهای بدون pin که inject می‌شوند، و promptMaxChars با مقدار پیش‌فرض 2000 برای تعیین budget مربوط به rendering. این build به node:sqlite متکی است؛ Node 22 و 24 هنوز آن را experimental علامت‌گذاری می‌کنند. بنابراین ارتقای Node باید آزمایش شود و نباید بدون بررسی فرض شود که مشکلی ایجاد نمی‌کند.

Memory از نظر عملی این تغییر را در ماشین ایجاد می‌کند: memoryهای inject‌شده در هر نوبت داخل system prompt قرار می‌گیرند. promptMaxChars سقف بخش renderشده است، نه یک مقدار ثابت. اما وقتی memoryهای ذخیره‌شده این ظرفیت را پر کنند، budget برابر با 2000 کاراکتر در هر request، برای همیشه چند صد token ورودی اضافه ایجاد می‌کند. این هزینه واقعاً در صورت‌حساب شما ثبت می‌شود. به همین دلیل، dsh-budget باید پیش از dsh-memory روی سرور قرار بگیرد. مقدار promptMaxChars را محدود نگه دارید و با memory_forget موارد اضافی را حذف کنید؛ اجازه ندهید فایل بدون کنترل بزرگ شود.

build جایگزین، memoryها را در یک فایل YAML ذخیره می‌کند و با استفاده از embedding search، prompt را به‌صورت خودکار inject می‌کند. نصب آن با dsh plugin --profile web add github:towzai/dsh-memory انجام می‌شود. embedding search آن به یک نمونهٔ محلی ollama و یک embedding model نیاز دارد؛ مقدار پیش‌فرض qwen3-embedding:0.6b است و می‌توان آن را با DSH_MEMORY_EMBED_MODEL تغییر داد. بدون ollama، سیستم به جست‌وجوی صرفاً keyword-based برمی‌گردد. semantic recall از keyword recall بهتر است. اما این روش به یک service دوم و مجموعه‌ای از model weightها نیاز دارد که روی همان سرور در memory باقی می‌مانند. در یک plan کوچک، این memory از منابعی کم می‌شود که برای اجرای workload اصلی سرور اجاره کرده‌اید. زمانی این گزینه را انتخاب کنید که RAM اضافی دارید. tradeoff کلی میان کیفیت recall و هزینهٔ resident در memory محلی برای agentها توضیح داده شده است.

dsh-web-lan-access: رابط وب باید فراتر از loopback گوش دهد؟

npx @deepseek-ai/dsh web رابط را روی 127.0.0.1:3080 ارائه می‌کند. مرورگرها فقط در یک secure context، crypto.randomUUID() را در اختیار صفحه قرار می‌دهند؛ بنابراین بارگذاری همان صفحه از رایانه‌ای دیگر روی HTTP ساده شکست می‌خورد. dsh-web-lan-access با استفاده از webServer.tapIndex یک polyfill کوچک تزریق می‌کند و binding سرور را به 0.0.0.0 تغییر می‌دهد.

پیش از نصب، هشدار خود آن را بخوانید. در commit ذکرشده در اینجا، e27e909، فایل README می‌گفت که binding روی 0.0.0.0 باعث می‌شود agent بدون احراز هویت برای هر فردی در همان شبکهٔ محلی (LAN) قابل دسترسی باشد؛ و در سروری با public IP address، برای کل اینترنت نیز قابل دسترسی شود. فقط فهرست کوتاهی از متدهای حساس (settings.*، credentials.*، llm.discoverModels) روی loopback محدود شده بودند و از originهای remote کد وضعیت 403 برمی‌گرداندند. این وضعیت تغییر کرده است. buildهای فعلی harness که در 10 October 2026 بررسی شده‌اند، مرورگر را احراز هویت می‌کنند: launch token موجود در URL چاپ‌شده با یک signed session cookie مبادله می‌شود و هر route و stream مربوط به Host API به آن نیاز دارد. README فعلی plugin، trustedHosts را یک سد Origin/Host، نه هویت، می‌داند و می‌گوید binding روی 0.0.0.0 سطح احراز هویت را روی هر interface قابل دسترسی آشکار می‌کند. اکنون نیز تنظیمات مبتنی بر Host را برای یک صفحهٔ remote احراز هویت‌شده فعال می‌کند؛ بنابراین در buildهای فعلی، یک مرورگر remote که وارد حساب شده باشد می‌تواند به تنظیمات Host نیز دسترسی پیدا کند. ریسک از بین نرفته، بلکه جابه‌جا شده است: هر فردی که بتواند به port دسترسی پیدا کند می‌تواند login را بررسی کند، URL چاپ‌شده خود یک credential است و در HTTP ساده، این token به‌صورت متن آشکار از شبکه عبور می‌کند.

در بیشتر مواقع اصلاً به این plugin نیاز ندارید. در عوض، port را از طریق SSH forward کنید.

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

سپس http://127.0.0.1:3080 را در مرورگر محلی خود باز کنید. harness همچنان فقط روی loopback گوش می‌دهد؛ بنابراین چیزی expose نمی‌شود. از آنجا که مرورگرها 127.0.0.1 را یک secure origin در نظر می‌گیرند، crypto.randomUUID() در دسترس است و به polyfill نیازی نیست. یک command، بدون plugin و بدون ایجاد attack surface جدید.

فقط زمانی plugin را نصب کنید که port forwarding کافی نباشد؛ برای مثال، وقتی تلفنی در همان شبکه باید به رابط دسترسی داشته باشد. در این صورت، آن را پشت یک private network interface bind کنید، یک firewall rule نگه دارید که فقط به همان interface اجازه دهد و نام‌هایی را که استفاده می‌کنید، در بخش trustedHosts از ورودی web-runtime فهرست کنید. برای دسترسی واقعی چندکاربره، dsh-passwords وجود دارد که subuser permissions، سهمیهٔ ساعتی token برای هر subuser، سهمیهٔ روزانهٔ زمان، گواهی‌های TLS (امنیت لایهٔ انتقال) خودکار از طریق Let's Encrypt و یک audit log رمزنگاری‌شده را اضافه می‌کند. با آن مانند یک platform، نه یک plugin، برخورد کنید: به portهای 80 و 443 نیاز دارد، installer خود را ارائه می‌کند و مسیر سریع مستندشده، یک shell script را مستقیماً از شبکه به داخل bash pipe می‌کند. npm install -g dsh-passwords را اجرا و سپس dsh-passwords install را دنبال کنید تا code روی دیسک قرار گیرد و بتوانید پیش از اجرا آن را بخوانید.

نحوه حذف صحیح یک plugin

Uninstall کردن دو مرحله دارد، اما بسیاری از افراد مرحله دوم را انجام نمی‌دهند.

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

list دیگر نباید آن را نمایش دهد. سپس $DSH_HOME/profiles/web/cordis.patch.yml را باز کنید و هر insert block باقی‌مانده‌ای را که نام آن plugin را دارد حذف کنید؛ همین entry باعث load شدن plugin در tree می‌شود. harness را restart کنید تا tree دوباره ساخته شود؛ pluginای که قبلاً load شده است تا زمان restart همچنان load باقی می‌ماند. در پایان، به خاطر داشته باشید که data بیشتر از code باقی می‌ماند. $DSH_HOME/memory/memory.db و .dsh/rules.yaml پس از Uninstall نیز باقی می‌مانند. اگر هدف شما حذف data است، آن‌ها را به‌صورت دستی حذف کنید.

آنچه خواندم و زمان آن

هر ارجاع در این بخش به یک commit اشاره دارد، نه یک branch؛ زیرا تا زمانی که این متن را می‌خوانید، main کد متفاوتی خواهد بود. من همه موارد را در 17 August 2026 خواندم و خود harness نیز در آن روز روی npm در 0.1.0-rc.7 قرار داشت. در 10 October 2026، پیش‌فرض‌ها و رفتارهای توضیح‌داده‌شده در بالا را در برابر منابع اصلی دوباره بررسی کردم؛ در آن زمان، tag latest روی npm برابر با 0.2.0-rc.2 بود.

پیش از کپی‌کردن یک command، این pinها را دوباره بررسی کنید. در یک ecosystem مربوط به developer preview، فقط شماره نسخه‌ای که همراه با تاریخ ثبت شده باشد معنای قابل‌اتکایی دارد.

FAQ

کدام افزونه‌های DeepSeek Harness را ابتدا روی یک VPS نصب کنم؟

پیش از هر چیز dsh-budget و dsh-permission-rules را نصب کنید. تعیین بودجه با overLimit: block مانع می‌شود یک اجرای بدون نظارت تمام شب هزینه ایجاد کند، و فایل .dsh/rules.yaml جلوی فراخوانی ابزاری را می‌گیرد که هرگز آن را تأیید نمی‌کردید. وقتی agent چیزی از وب عمومی می‌خواند، dsh-defend را اضافه کنید. هرگاه متوجه شدید همان context را در هر session تکراراً paste می‌کنید، dsh-memory را اضافه کنید. از themeها و status chipها صرف‌نظر کنید؛ این موارد بدون تغییر رفتار ماشین، کدی را با دسترسی‌های agent اجرا می‌کنند.

آیا افزونه‌های dsh از harness sandbox شده‌اند؟

خیر. یک افزونه در همان درخت Cordis مربوط به harness، در همان process، با همان کاربر سیستم‌عامل، همان اعتبارنامه‌های model و همان working tree بارگذاری می‌شود. افزونه‌ای که به tools/pre-execute متصل شود، همه فراخوانی‌های ابزار را می‌بیند و می‌تواند آن‌ها را مسدود کند؛ افزونه‌ای که به agent/pre-step متصل شود، پیام‌های شما را می‌بیند. بنابراین source را بخوانید، license و تاریخ آخرین commit را بررسی کنید و افزونه را بر اساس commit، نه branch، نصب کنید تا کد نتواند بدون اطلاع شما تغییر کند.

آیا dsh-budget واقعاً agent را متوقف می‌کند یا فقط به من هشدار می‌دهد؟

این موضوع به overLimit بستگی دارد. مقدار پیش‌فرض alert است؛ این مقدار در warnRatio هشدار می‌دهد و به مصرف ادامه می‌دهد. block پس از رسیدن به سقف، فراخوانی‌های بیشتر model را رد می‌کند و /budget unblock <scope> هنگام انتخاب شما برای ادامه، این محدودیت را برمی‌دارد. degrade با ارائه راهنمایی، اجرای درخواست را مسدود می‌کند و نام model ارزان‌تری را از map مربوط به degradation اعلام می‌کند. یک محدودیت مهم وجود دارد: در commit مشخص‌شده در 461d478، مجموع‌ها در process در حال اجرا جمع می‌شوند؛ بنابراین restart کردن harness آن‌ها را reset می‌کند و یک restart loop می‌تواند سقف روزانه را بی‌اثر کند. نسخه فعلی main bucketهای روزانه و ماهانه را به‌طور پیش‌فرض بین restartها حفظ می‌کند. در هر دو حالت، برای حساب provider یک spend limit تعیین کنید؛ این حد واقعی هزینه خواهد بود.

چگونه یک افزونه dsh را به‌طور کامل حذف کنم؟

dsh plugin --profile web remove <package-name> را اجرا کنید، با dsh plugin --profile web list تأیید کنید، سپس $DSH_HOME/profiles/web/cordis.patch.yml را باز کنید و هر insert block باقی‌مانده مربوط به آن افزونه را حذف کنید؛ زیرا همین entry آن را بارگذاری می‌کند. harness را restart کنید تا درخت افزونه دوباره ساخته شود. داده‌هایی که افزونه روی دیسک نوشته است باقی می‌مانند: $DSH_HOME/memory/memory.db و .dsh/rules.yaml هر دو پس از uninstall نیز باقی می‌مانند، مگر آن‌که خودتان آن‌ها را حذف کنید.

آیا expose کردن web UI مربوط به dsh روی شبکه امن است؟

به‌تنهایی خیر. dsh web روی 127.0.0.1:3080 گوش می‌دهد و dsh-web-lan-access این binding را به 0.0.0.0 تغییر می‌دهد. در commit ذکرشده در اینجا، README اعلام می‌کرد که با این کار agent بدون authentication برای هر فردی در همان شبکه قابل دسترسی می‌شود و فقط settings.*، credentials.* و llm.discoverModels به loopback محدود می‌مانند. نسخه‌های فعلی harness که در 10 October 2026 بررسی شده‌اند، session مرورگر را با launch token موجود در URL چاپ‌شده و یک signed session cookie احراز هویت می‌کنند؛ اما در این حالت login surface روی همه interfaceها expose می‌شود و یک URL معمولی HTTP آن token را به‌صورت cleartext ارسال می‌کند. از SSH port forward، یعنی ssh -N -L 3080:127.0.0.1:3080 you@your-server، استفاده کنید؛ یا port را پشت یک private network interface به‌همراه firewall rule قرار دهید و برای هر چیزی که از خارج قابل دسترسی است، TLS را در جلوی آن نگه دارید.