DeepSeek Super-agent सेटअप: Router और Worker कैसे काम करते हैं

DeepSeek Super-agent को पहले एक रिपॉज़िटरी, एक अधिकृत अनुरोधकर्ता और अलग ऑपरेटिंग सिस्टम खाते के साथ आज़माएँ। इसका Router अधिकृत अनुरोधों से Ticket बनाता है, जबकि Worker अलग-अलग सत्रों और डायरेक्टरी में काम करते हैं। शुरुआत में observe चालू रखें, लेकिन समझें कि सीधे दिए गए अनुरोध फिर भी चल सकते हैं।

2026-11-09 तक dsh-superagent-prototype शोध के लिए बना प्रोटोटाइप है, DeepSeek का आधिकारिक उत्पाद या उत्पादन में इस्तेमाल के लिए तैयार सेवा नहीं। इसके पैकेज मैनिफ़ेस्ट में संस्करण 0.1.0 और MIT लाइसेंस दर्ज हैं। सार्वजनिक कार्यान्वयन टीम की आंतरिक प्रणाली और डिज़ाइन लेख में वर्णित कार्यान्वयन से भी अलग है।

Router, Ticket और Worker क्या करते हैं?

मुख्य बदलाव रिपॉज़िटरी से लगातार काम लेना है, कोई नया मॉडल या कोड लिखने का नया इंटरफ़ेस नहीं। यह बंडल DeepSeek Harness के भीतर चलता है। यह एक GitHub रिपॉज़िटरी पर नज़र रखता है और चाहें तो Feishu के संदेश भी ले सकता है।

इसका डोमेन मॉडल आने वाली घटनाओं को अधिकृत काम से अलग रखता है। Eval नाम का मूल्यांकन तंत्र तय करता है कि किसी संभावित काम के लिए नया Ticket बनना चाहिए या नहीं। हर स्वीकृत Ticket के साथ Mandate होता है, जिसमें अनुमति का आधार और काम की सीमा दर्ज रहती है।

Router मुख्य एजेंट सत्र है, जो तय करता है कि किस अनुरोध को कहाँ भेजना है। Worker स्वीकृत काम पूरा करता है। सेटिंग पन्नों में इसी Worker को Executor कहा गया है।

हर Worker का अपना सत्र और कार्यशील डायरेक्टरी होती है। परिणाम मूल बातचीत में लौटता है, जैसे GitHub टिप्पणी में पुल रिक्वेस्ट की कड़ी। अलग डायरेक्टरी कार्यशील प्रतियों को अलग रखती है; वह प्रक्रिया की फ़ाइल पढ़ने की पहुँच सीमित नहीं करती।

उदाहरण के लिए, दो असंबंधित बग रिपोर्ट एक कोडिंग बातचीत में मिलने के बजाय अलग Ticket बन सकती हैं। यह तब उपयोगी है जब आने वाले काम का समन्वय किसी एक कोडिंग कार्य को शुरू करने से अधिक ध्यान माँगता हो।

एक बदलाव पर बातचीत करते हुए काम करना हो तो अपना मौजूदा कोडिंग एजेंट रखें। सीमित काम सौंपने के लिए स्पष्ट मॉडल चयन वाले, केवल पढ़ने के लिए बने Claude Code सबएजेंट से शुरुआत करें।

observe सुरक्षा सैंडबॉक्स क्यों नहीं है?

observe संदर्भ से अनुमानित काम को सीमित करता है, हर प्रकार का निष्पादन नहीं। अनुमति के नियम सीधे दिए गए अनुरोधों को हर स्वीकृति मोड में चलने देते हैं।

observe में अनुमानित काम का सकारात्मक मूल्यांकन “would accept” रिकॉर्ड बनता है, लेकिन उससे नया काम शुरू नहीं होता। auto में सकारात्मक मूल्यांकन से अनुमानित काम स्वीकार हो सकता है। अनुमति सूची में शामिल व्यक्ति एजेंट का उल्लेख करके हर मोड में काम दे सकता है।

अनुमति सूची ही एकमात्र नियंत्रण नहीं है। अनुमति तालिका की कोई सेल सूची से बाहर के लोगों को भी सीधे काम देने का अधिकार दे सकती है। इसलिए केवल observe पर निर्भर न रहें; नीचे दी गई एक-अनुरोधकर्ता नीति लागू करें।

danger-full-access का क्या अर्थ है?

ऐसा ऑपरेटिंग सिस्टम खाता इस्तेमाल करें जिसमें केवल एजेंट के क्रेडेंशियल हों। परिनियोजन मार्गदर्शिका की अलगाव संबंधी चेतावनी dsh-superagent-router और dsh-superagent-worker, दोनों पर लागू होती है। ये ऑपरेटर के सिस्टम उपयोगकर्ता के रूप में danger-full-access के साथ चलते हैं।

क्रेडेंशियल चुनने वाले रैपर खाते चुनते हैं; वे प्रक्रियाओं को अलग नहीं करते। Worker पूर्ण पथ से प्रोग्राम चला सकता है और ऑपरेटर की होम डायरेक्टरी पढ़ सकता है। कार्यान्वयन मार्गदर्शिका के अनुसार Router को भी शेल और फ़ाइल पढ़ने के उपकरण मिलते हैं।

पहले परीक्षण के लिए अस्थायी मशीन या वर्चुअल मशीन लें। एजेंट के खाते को प्रशासक अधिकार न दें। उस परिवेश में निजी क्रेडेंशियल, उत्पादन परिवेश के सीक्रेट और असंबंधित रिपॉज़िटरी न रखें। ये परिनियोजन की सावधानियाँ हैं, प्रोटोटाइप की अंतर्निहित सुरक्षा नहीं।

Harness प्रोफ़ाइल भी अलग रखें। प्लगइन पूरी प्रक्रिया के PATH और git सेटिंग बदलता है। पैनल को 127.0.0.1 पर ही बाँधकर रखें; इस परीक्षण सेवा को सार्वजनिक वेब सेवा के रूप में न खोलें।

केवल GitHub के साथ परीक्षण कैसे शुरू करें?

नीचे की मैन्युअल प्रक्रिया नए खाते और नई प्रोफ़ाइल पर अपनाएँ। रिपॉज़िटरी में एजेंट की मदद से सेटअप करने के लिए SETUP.md भी उपलब्ध है।

ज़रूरी सॉफ़्टवेयर और पहुँच जाँचें

Node.js 22.19+ या 24+, pnpm, git 2.32+, Python 3.8+, tmux और GitHub CLI 2.48+ स्थापित करें। ये दस्तावेज़ में दी गई आवश्यकताएँ हैं।

github.com पर एक रिपॉज़िटरी और DeepSeek Harness के लिए मॉडल प्रदाता भी चाहिए। GitHub Enterprise Server समर्थित नहीं है। लक्ष्य रिपॉज़िटरी Git LFS इस्तेमाल करती हो तो git-lfs स्थापित करें।

परीक्षण के लिए ऐसी रिपॉज़िटरी लें जो खाली न हो और जिसमें README.md मौजूद हो। पहली जाँच के लिए निजी रिपॉज़िटरी बेहतर है, जिसमें केवल आप और एजेंट हों।

Feishu वैकल्पिक है और इस परीक्षण में शामिल नहीं है। उसे जोड़ने के लिए बॉट वाला Feishu या Lark ऐप और lark-cli चाहिए। परियोजना के दस्तावेज़ में जाँचा गया संस्करण 1.0.90 है।

केवल एजेंट के खाते से साइन इन करें

एजेंट के लिए अलग GitHub उपयोगकर्ता खाता बनाएँ और उसे परीक्षण रिपॉज़िटरी में लिखने की अनुमति दें। ये कमांड अलग सिस्टम खाते के अंतर्गत Bash में चलाएँ।

unset GH_TOKEN GITHUB_TOKEN
gh auth login --hostname github.com --git-protocol https
gh api user --jq .login
gh auth setup-git --hostname github.com

एजेंट के खाते से GitHub CLI का इंटरैक्टिव लॉगिन पूरा करें। gh api कमांड में उसी का लॉगिन दिखना चाहिए। दोनों वेरिएबल हटाने से परिवेश के क्रेडेंशियल सहेजे गए लॉगिन की जगह नहीं लेते।

अलग से चलाया गया gh auth setup-git Git को क्रेडेंशियल सहायक के रूप में GitHub CLI इस्तेमाल करने के लिए सेट करता है। यह ज़रूरी है क्योंकि तैयारी और ब्रांच भेजने के चरण Git को सीधे चलाते हैं।

दस्तावेज़ में दिए GitHub CLI क्लोन सिंटैक्स से स्थानीय क्लोन बनाएँ:

read -r -p "Repository (owner/name): " TARGET_REPOSITORY
mkdir -p "$HOME/src"
gh repo clone "$TARGET_REPOSITORY" "$HOME/src/superagent-target"

अब gh api से अलग, HTTPS पहुँच जाँचें:

GIT_TERMINAL_PROMPT=0 git ls-remote \
  "https://github.com/$TARGET_REPOSITORY.git" HEAD

GIT_TERMINAL_PROMPT=0 git -C "$HOME/src/superagent-target" push --dry-run \
  "https://github.com/$TARGET_REPOSITORY.git" \
  HEAD:refs/heads/agent-auth-check

git ls-remote को दूरस्थ रिपॉज़िटरी का HEAD लौटाना चाहिए। सार्वजनिक रिपॉज़िटरी में यह पढ़ना बिना पहचान प्रमाणित किए भी सफल हो सकता है। push --dry-run की जाँच दूरस्थ रेफ़ बदले बिना पुश कनेक्शन आज़माती है।

दोनों कमांड सफल होनी चाहिए। फिर भी, आगे वास्तविक PR के लिए ब्रांच भेजना ही अंतिम डिलीवरी जाँच रखें।

यह उदाहरण gh को सीधे इस्तेमाल करता है क्योंकि पूरा सिस्टम खाता एजेंट के लिए है। निजी खाते की कई लॉगिन वाली कॉन्फ़िगरेशन दोबारा इस्तेमाल न करें।

Harness की अलग प्रोफ़ाइल स्थापित करें

परिनियोजन मार्गदर्शिका में तय Harness संस्करण 0.2.1-rc.3 इस्तेमाल करें। बंडल मैनिफ़ेस्ट में engines.dsh के लिए ^0.2.1-alpha.2 की शर्त है।

किसी भी dsh कमांड से पहले DSH_HOME सेट करें। इस संस्करण का CLI संदर्भ नाम वाली प्रोफ़ाइल $DSH_HOME/profiles/<name> के अंतर्गत रखता है। इस परीक्षण के लिए $HOME/.dsh पथ स्पष्ट रूप से चुना गया है।

नीचे की Bash कमांड केवल नई स्थापना के लिए हैं:

export DSH_HOME="$HOME/.dsh"

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

पहले से मौजूद स्थापना पर प्रोफ़ाइल बनाने वाली कमांड दोबारा न चलाएँ। वह प्रोफ़ाइल बदल देती है और उसकी cordis.patch.yml मिटा देती है। अपडेट के लिए परिनियोजन मार्गदर्शिका की अपग्रेड प्रक्रिया अपनाएँ।

मशीन कॉन्फ़िगरेशन लिखने से पहले प्रोफ़ाइल मैनिफ़ेस्ट का होना जाँचें। उसी Bash शेल में आगे बढ़ें:

test -f "$DSH_HOME/profiles/superagent/package.json" || exit 1

cat > "$DSH_HOME/profiles/superagent/cordis.patch.yml" <<EOF
- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: "$DSH_HOME/state/superagent"
EOF

if tmux list-sessions >/dev/null 2>&1; then
  tmux set-environment -g DSH_HOME "$DSH_HOME"
  if tmux has-session -t '=dsh-superagent' 2>/dev/null; then
    tmux set-environment -t '=dsh-superagent' DSH_HOME "$DSH_HOME"
  fi
fi

scripts/dsh-superagent start
scripts/dsh-superagent status

सेवा स्क्रिप्ट tmux के ज़रिए dsh --profile superagent चलाती है। नया tmux सर्वर निर्यात किए गए परिवेश वेरिएबल अपनाता है। यह कोड पहले से चल रहे सर्वर या सत्र के tmux परिवेश को भी अपडेट करता है।

सर्वर मशीन के ब्राउज़र में http://127.0.0.1:3082 खोलें। Harness की सेटिंग में Open configuration file ऊपर दिया superagent/cordis.patch.yml पथ खोलना चाहिए। दूसरे पथ की फ़ाइल खुले तो रुकें। प्रदाता सेटिंग जोड़ने के बाद यह पैच दोबारा लिखकर न बदलें।

साइडबार में Superagent चुनें। रिपॉज़िटरी और खाते की सेटिंग पूरी होने तक प्रारंभिक सेटअप चेतावनी आना अपेक्षित है। अनुरोध लेने की सेटिंग से पहले नीचे का मॉडल चयन अनुभाग पूरा करें।

अनुरोध स्वीकार करने और हर Ticket के कार्यशील ट्री की सेटिंग करें

Superagent → Settings खोलें और दस्तावेज़ में दिए समूहों का उपयोग करें।

Sources → GitHub में रिपॉज़िटरी को अपने owner/name पर और एजेंट CLI को gh पर सेट करें। सभी Issues, पुल रिक्वेस्ट, टिप्पणियाँ और डिफ़ॉल्ट ब्रांच के CI प्राप्त करने वाले स्विच बंद रखें। Feishu भी बंद रहने दें।

Eval → On each Source → GitHub में GitHub accounts that may originate work में केवल आपका व्यक्तिगत लॉगिन होना चाहिए। बाकी प्रविष्टियाँ हटाएँ और बॉट सूची खाली रखें। सूची से बाहर के लोगों की सभी दिखाई देने वाली अनुमति सेल में ignore सेट करें। इसमें एजेंट को सीधे संबोधित करने वालों की सेल भी शामिल हैं। स्वीकृति मोड observe रखकर सहेजें।

सूची से बाहर के लोगों की डिफ़ॉल्ट सेटिंग अनुमति मैट्रिक्स में परिभाषित हैं। ये नए काम के अनुरोध सीमित करती हैं। जिन चर्चाओं की सदस्यता ली गई है, उनके संदेश फिर भी मौजूदा Ticket तक संदर्भ बनकर पहुँच सकते हैं। परीक्षण की बातचीत केवल अपने और एजेंट के बीच रखें।

Execution में परीक्षण की शुरुआत समवर्ती कार्यों की संख्या 1 से करें। डायरेक्टरी का मूल पथ डिफ़ॉल्ट रहने दें। नीचे का कोड तैयारी कमांड वाले फ़ील्ड में डालें। यह sh के अंतर्गत चलता है और इसका सिंटैक्स Bash में भी मान्य है।

git -C "$HOME/src/superagent-target" fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C "$HOME/src/superagent-target" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" \
  "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

यह परिनियोजन मार्गदर्शिका के कार्यशील ट्री उदाहरण को ऊपर बनाए क्लोन के अनुरूप ढालता है। यह संबंधित हेड लाता है और Ticket की ब्रांच तथा कार्यशील प्रति बनाता है। तैयारी कमांड न हो तो Worker खाली डायरेक्टरी से शुरू करता है।

Prompts में एजेंट के कमिट लेखक की पहचान और एजेंट की भागीदारी बताने वाला पाठ सेट करें। मर्ज करने का काम इंसान के पास रखें और अलग मर्ज खाता न दें। प्रॉम्प्ट के निर्देश मार्गदर्शन हैं, रिपॉज़िटरी पर लागू सुरक्षा नियम नहीं।

क्या दूसरा मॉडल चुन सकते हैं?

हाँ, DeepSeek Harness में कॉन्फ़िगर किए गए प्रदाताओं के ज़रिए। dsh-v0.2.1-rc.3 टैग की प्रदाता मार्गदर्शिका स्थापित संस्करण के लिए नीचे की प्रक्रिया बताती है।

Harness में Settings → Models खोलें। DeepSeek कार्ड में API कुंजी डालकर सहेजें। दूसरे समर्थित प्रदाता के लिए Add model provider चुनें। क्रेडेंशियल इस स्थानीय इंटरफ़ेस में डालें, GitHub चर्चा में नहीं।

Custom model API के लिए छोटे अक्षरों में Provider ID, बेस URL, मेल खाता API प्रोटोकॉल, क्रेडेंशियल और कम-से-कम एक मॉडल दें। अपने प्रदाता के दस्तावेज़ में दिए मान इस्तेमाल करें। प्रदाता सहेज लेना यह साबित नहीं करता कि उसका मॉडल ज़रूरी उपकरण कॉल कर सकता है।

इसके बाद इस संस्करण की वेब इंटरफ़ेस मार्गदर्शिका के अनुसार Choose workspace से $HOME/src/superagent-target जोड़ें और चुनें। सामान्य सत्र शुरू करें और उसके मॉडल चयन में कॉन्फ़िगर किया गया मॉडल चुनें। यह चयन नए सत्रों के लिए डिफ़ॉल्ट बनता है।

एक और नया सत्र खोलें। अनुरोध भेजने से पहले जाँचें कि वही प्रदाता और मॉडल दिख रहे हैं। उससे README.md पढ़कर बिना बदलाव किए पहला शीर्षक लौटाने को कहें। उत्तर को फ़ाइल से मिलाएँ। इस जाँच में किसी भी प्रबंधित dsh-superagent-* प्रीसेट का उपयोग न करें।

फिर वही जाँचा हुआ प्रदाता और मॉडल Superagent → Settings → Eval तथा Execution में स्पष्ट रूप से चुनें। Eval, Router और मूल्यांकन के लिए मॉडल देता है; Execution, Worker के लिए। यह परीक्षण किसी अपुष्ट डिफ़ॉल्ट पर निर्भर नहीं रहता। इनमें से कोई चयन खाली तभी छोड़ें जब प्रोफ़ाइल का डिफ़ॉल्ट जाँच लिया हो।

Executor का मॉडल चयन सत्र बनते समय लागू होता है। मौजूदा Worker सत्र अपना मॉडल रखते हैं और Retry उसी सत्र को दोबारा इस्तेमाल करता है। बाद में मॉडल बदलें तो नए Ticket पर जाँचें।

एक अनुरोध जाँचें और विफलता की जगह पहचानें

कोड बदलने को कहने से पहले GitHub पर पूरा अनुरोध और उसका उत्तर जाँचें। केवल पैनल चलने से अनुमति, तैयारी और मॉडल कॉल का सही होना सिद्ध नहीं होता।

पहले scripts/dsh-superagent status दोबारा चलाएँ। निकास कोड 0 होना चाहिए और कोई सेटअप समस्या नहीं होनी चाहिए। अनुमति वाले व्यक्तिगत खाते से issue पर नया कमेंट डालें। @AGENT_LOGIN की जगह एजेंट का लॉगिन लिखें:

@AGENT_LOGIN Read README.md and reply here with its first heading.
Do not edit files, push a branch, or open a pull request.

परिनियोजन मार्गदर्शिका की परीक्षण प्रक्रिया के अनुसार बना हुआ Ticket Overview में दिखता है। मूल GitHub बातचीत में आए उत्तर में सही शीर्षक होना चाहिए।

यह जाँच सफल होने पर दस्तावेज़ में छोटा बदलाव और मानवीय समीक्षा के लिए पुल रिक्वेस्ट माँगें। जाँचें कि ब्रांच वास्तव में भेजी गई, PR एजेंट के खाते से बना और diff तय दायरे में है। ये स्वीकृति जाँचें हैं, मॉडल के परिणाम की गारंटी नहीं।

Ticket न मिले तो अनुमति वाला लॉगिन, अनुमति सेल, रिपॉज़िटरी और GitHub स्रोत की स्थिति जाँचें। फिर एजेंट का उल्लेख करते हुए नया कमेंट डालें।

सेवा स्क्रिप्ट प्रक्रिया या रनटाइम की समस्या पर 1, घटक त्रुटियों पर 2 और अधूरे सेटअप पर 3 लौटाती है। 1 में पुनः शुरू करना मदद कर सकता है। 2 या 3 में बताई गई वजह ठीक करें।

अस्थायी मॉडल या नेटवर्क विफलताओं के लिए निष्पादन मार्गदर्शिका बढ़ती देरी के साथ तीन पुनःप्रयास बताती है। इनमें HTTP 408, 429 और 5xx शामिल हैं। विफल तैयारी कमांड पर यह स्वचालित पुनःप्रयास लागू नहीं होता।

तैयारी कमांड विफल हो तो काम कैसे फिर शुरू करें?

Retry चुनने से पहले दर्ज तैयारी त्रुटि और Ticket की डायरेक्टरी देखें। लॉन्च का कार्यान्वयन तैयारी केवल तब चलाता है जब वह डायरेक्टरी मौजूद न हो। मौजूद डायरेक्टरी को तैयार मान लिया जाता है, भले काम अधूरा हो।

डायरेक्टरी न हो तो क्रेडेंशियल या तैयारी कमांड की समस्या ठीक करें, फिर Retry चुनें। नया लॉन्च तैयारी फिर आज़माएगा।

डायरेक्टरी मौजूद हो तो Ticket के विवरण से उसका पथ लें और Bash में जाँचें:

read -r -p "Ticket directory (absolute path): " TICKET_DIR
git -C "$TICKET_DIR" rev-parse --show-toplevel
git -C "$TICKET_DIR" status --short --branch

दिखाया गया कार्यशील ट्री का सबसे ऊपरी पथ Ticket की डायरेक्टरी होना चाहिए, उसके ऊपर की कार्यशील प्रति नहीं। ब्रांच और कार्यशील ट्री की स्थिति, अपेक्षित फ़ाइलें और तैयारी के हर पहले विफल चरण को जाँचें।

मौजूद डायरेक्टरी पर Retry तभी करें जब उसकी तैयारी पूरी करके जाँच ली हो। Retry उसे दोबारा नहीं बनाता। अधूरी कार्यशील प्रति सुरक्षित रूप से ठीक न कर सकें तो उसे बचाकर रखें और वह Ticket रोक दें। कमांड ठीक करके नए issue से अनुरोध भेजें। आगे बढ़ने से पहले सुनिश्चित करें कि नया Ticket नई डायरेक्टरी इस्तेमाल करता है।

Ticket विफल हो जाने के बाद CI और बॉट के संदेश उसके Worker को फिर नहीं चलाते। किसी व्यक्ति को कार्रवाई करनी होती है। परीक्षण पूरा होने पर सेवा रोक दें:

scripts/dsh-superagent stop

सेवा चालू रखना कब उचित है?

प्रोटोटाइप तभी चालू रखें जब उसके अनुरोध बाँटने के फैसले और दिए गए बदलाव रखरखाव की मेहनत को उचित ठहराएँ। शुरुआत सीमित रखें। उपयोगी परिणाम और प्रदाता का उपयोग मापने के बाद ही समवर्ती कार्यों की संख्या बढ़ाएँ।

केवल मॉडल की कीमत नहीं, हर स्वीकृत बदलाव की लागत की तुलना करें। अनुरोध बाँटना, मूल्यांकन, Worker कॉल और विफलता से उबरना, सब परीक्षण बजट में जोड़ें। कोडिंग एजेंट की प्रति-कार्य लागत मार्गदर्शिका मॉडल और उसकी निष्पादन व्यवस्था को साथ परखने का तरीका देती है।

आंतरिक प्रदर्शन को इस सार्वजनिक कोड के बराबर न मानें। रिपॉज़िटरी चेतावनी देती है कि व्यापक डिज़ाइन लेख की कुछ बातें अभी लागू नहीं हुई हैं। अपनी स्वीकृति जाँचों से व्यापक उपयोग उचित साबित होने तक मानवीय समीक्षा और अलगाव बनाए रखें।