Hermes Agent Web Dashboard: लोकल एक्सेस, प्रोफाइल और डायग्नोस्टिक्स

ग्राफिकल Hermes Agent Web Dashboard कॉन्फ़िगरेशन फ़ाइलों को सीधे संपादित करने की आवश्यकता को समाप्त करते हुए, ब्राउज़र के माध्यम से आपके एजेंट इंस्टॉलेशन के व्यवस्थापन (administration) की सुविधा प्रदान करता है। यह डैशबोर्ड आपको सिस्टम परिवेश को मैन्युअल रूप से बदले बिना एपीआई एक्सेस कुंजियों को प्रबंधित करने, सक्रिय प्रोफाइल स्विच करने, पिछले सत्रों का निरीक्षण करने और एक अंतर्निहित टर्मिनल शुरू करने की अनुमति देता है।

बुनियादी लॉन्च और सिस्टम निर्भरताएं

डिफ़ॉल्ट रूप से, डैशबोर्ड लूपबैक इंटरफ़ेस पर बाइंड होता है:

hermes dashboard

यह कमांड एक स्थानीय HTTP सर्वर शुरू करता है और आपके डिफ़ॉल्ट ब्राउज़र में http://127.0.0.1:9119 खोलता है। यदि वह पोर्ट पहले से ही किसी अन्य स्थानीय सेवा द्वारा उपयोग में है, तो इसे --port फ़्लैग के साथ ओवरराइड करें:

hermes dashboard --port 9120 --no-open

--no-open फ़्लैग स्वचालित रूप से एक नया ब्राउज़र टैब खोलने से रोकता है, जो बैकग्राउंड प्रक्रियाओं और ऑटोमेशन स्क्रिप्ट्स के लिए आदर्श है।

बेस hermes-agent पैकेज डिफ़ॉल्ट रूप से वेब स्टैक को शामिल नहीं करता है। Linux, macOS और WSL2 वातावरणों में, आवश्यक वैकल्पिक घटकों को एजेंट के वर्चुअल वातावरण में इंस्टॉल करें:

cd ~/.hermes/hermes-agent && uv pip install -e ".[web,pty]"

web एक्स्ट्रा FastAPI और Uvicorn इंस्टॉल करता है, जबकि pty POSIX सिस्टम के लिए ptyprocess जोड़ता है। डैशबोर्ड के स्टैटिक फ्रंटएंड को बनाने के लिए एक सक्रिय Node.js इंस्टॉलेशन की आवश्यकता होती है (जब npm मौजूद होता है, तो फ्रंटएंड पहले स्टार्ट पर स्वचालित रूप से बन जाता है)।

प्लेटफार्म की सीमाएं: नेटिव Windows बनाम WSL2

Windows (Native) गाइड के अनुसार, एक नेटिव Windows इंस्टॉलेशन कॉन्फ़िगरेशन, मेट्रिक्स, टास्क और सत्र डेटाबेस दृश्यों का समर्थन करता है। हालांकि, एम्बेडेड /chat टर्मिनल टैब POSIX PTY स्यूडो-टर्मिनलों पर निर्भर करता है। चूंकि नेटिव Windows इस इंटरफ़ेस का समर्थन नहीं करता है, इसलिए पूर्ण इंटरैक्टिव ब्राउज़र टर्मिनल सत्रों तक पहुंचने के लिए आपको एजेंट को WSL2 के भीतर चलाना होगा।

प्रक्रियाओं को अलग रखना भी आवश्यक है: वेब डैशबोर्ड और मैसेजिंग गेटवे (जैसे Telegram, Discord या अन्य प्लेटफ़ॉर्म के लिए) स्वतंत्र डेमन के रूप में काम करते हैं। वेब इंटरफ़ेस शुरू करने से प्लेटफ़ॉर्म मैसेजिंग गेटवे स्वचालित रूप से लॉन्च या सक्रिय नहीं होते हैं।

प्रोफाइल प्रबंधन और मॉडल कॉन्फ़िगरेशन

डैशबोर्ड मशीन स्तर पर संचालित होता है, जो सभी कॉन्फ़िगर किए गए प्रोफाइल में केंद्रीकृत प्रशासन प्रदान करता है। साइडबार में प्रोफाइल बदलने से URL क्वेरी पैरामीटर ?profile=<name> के माध्यम से वर्किंग संदर्भ अपडेट हो जाता है।

1. Config और API Keys अनुभाग: Config पृष्ठ config.yaml में मापदंडों को संपादित करता है, जहां परिवर्तनों को Save बटन पर क्लिक करके लागू किया जाता है। इसके विपरीत, API Keys पृष्ठ ~/.hermes/.env में पर्यावरण चर (environment variables) का प्रबंधन करता है: कुंजियां प्रत्येक चर के लिए अलग-अलग सेट और हटाई जाती हैं, जिसमें कोई वैश्विक सेव बटन या सभी फ़ील्ड्स में बैच सत्यापन नहीं होता है।
2. प्रदाता और मॉडल की निरंतरता (Consistency): चयनित मॉडल और क्रेडेंशियल्स को सख्ती से एक ही प्रदाता के अनुरूप होना चाहिए। किसी तृतीय-पक्ष OpenAI-संगत सेवा को एकीकृत करते समय, अपस्ट्रीम मापदंडों की पुष्टि करें: उदाहरण के लिए, कनेक्शन सेटिंग्स, मॉडल आईडी और आवश्यक फ़ील्ड BetterToken गाइड में प्रलेखित हैं। एक तृतीय-पक्ष प्रदाता केवल स्वतंत्र एपीआई मॉडल एक्सेस प्रदान करता है और स्वयं Hermes डैशबोर्ड को होस्ट नहीं करता है या नेटवर्क टनल का प्रबंधन नहीं करता है।
3. Sessions के माध्यम से कार्यक्षमता का सत्यापन: मैन्युअल हेल्थ चेक के लिए, केवल पढ़ने योग्य (read-only) संक्षिप्त प्रॉम्प्ट भेजें। ध्यान रखें कि परीक्षण प्रश्नों के लिए प्रदाता द्वारा बिल लिया जा सकता है। सफल इन्फेरेंस की पुष्टि तब होती है जब आपको इंटरफ़ेस में एक सार्थक उत्तर प्राप्त होता है और सत्र मेटाडेटा या प्रदाता लॉग में टोकन खपत दर्ज की जाती है। Sessions टैब सूची में केवल एक नई प्रविष्टि का दिखना केवल यह दर्शाता है कि एक सत्र रिकॉर्ड बनाया गया था, यह नहीं कि मॉडल ने सफलतापूर्वक उत्तर दिया।

सुरक्षित रिमोट एक्सेस

डिफ़ॉल्ट रूप से, वेब सर्वर विशेष रूप से 127.0.0.1 पर सुनता है। बाहरी इंटरफेस (--host 0.0.0.0) से बाइंड करते समय, एक प्रमाणीकरण गेट (authentication gate) स्वचालित रूप से लागू किया जाता है। यदि कोई प्रमाणीकरण प्रदाता कॉन्फ़िगर नहीं किया गया है, तो एजेंट एक त्रुटि (fail-closed) के साथ समाप्त हो जाता है। लीगेसी --insecure फ़्लैग अब प्रमाणीकरण को बायपास नहीं करता है। Hermes Agent दस्तावेज़ के अनुसार सार्वजनिक या बाहरी नेटवर्क बाइंडिंग के लिए अनिवार्य प्रमाणीकरण की आवश्यकता होती है।

बाहरी पोर्ट को उजागर किए बिना रिमोट सर्वर से कनेक्ट करने का अनुशंसित तरीका एक SSH टनल पर स्थानीय पोर्ट अग्रेषण (local port forwarding) है (यहाँ user@your-server को अपने रिमोट सर्वर पते और उपयोगकर्ता नाम से बदलें):

ssh -N -L 9119:127.0.0.1:9119 user@your-server

यदि स्थानीय पोर्ट 9119 आपके स्थानीय वर्कस्टेशन पर पहले से उपयोग में है, तो एक वैकल्पिक स्थानीय पोर्ट का उपयोग करें:

ssh -N -L 9120:127.0.0.1:9119 user@your-server

इस सेटअप के साथ, रिमोट होस्ट पर Hermes सर्वर केवल स्थानीय 127.0.0.1 लूपबैक इंटरफ़ेस पर सुनता रहता है, सारा ट्रैफ़िक SSH टनल के माध्यम से एन्क्रिप्ट होता है, और आप अपने वर्कस्टेशन से http://127.0.0.1:9119 (या यदि वैकल्पिक स्थानीय पोर्ट का उपयोग कर रहे हैं तो http://127.0.0.1:9120) पर डैशबोर्ड का उपयोग कर सकते हैं।

चरणबद्ध समस्या निवारण

त्रुटियां होने पर, पूरे स्टैक का एक साथ परीक्षण करने के बजाय विफल लेयर (स्तर) को अलग करना महत्वपूर्ण है।

+----------------------------------------------------------------+
| 1. HTTP-транспорт      | 127.0.0.1:9119 /api/status            |
+------------------------+---------------------------------------+
| 2. Окружение и PTY     | Node.js / POSIX ptyprocess (WSL2)     |
+------------------------+---------------------------------------+
| 3. Сокеты и каналы     | /api/pty (Chat) / /api/ws (Desktop)   |
+------------------------+---------------------------------------+
| 4. Провайдер инференса | Ключи API, лимиты и сетевой эндпоинт  |
+----------------------------------------------------------------+

ऊपर दिए गए निर्णय वृक्ष (decision tree) में उल्लिखित नैदानिक स्तर (diagnostic layers) निम्नलिखित का प्रतिनिधित्व करते हैं:

• लेयर 1 (HTTP ट्रांसपोर्ट / HTTP-транспорт): 127.0.0.1:9119 /api/status
• लेयर 2 (परिवेश और PTY / Окружение и PTY): Node.js / POSIX ptyprocess (WSL2)
• लेयर 3 (सॉकेट्स और चैनल्स / Сокеты и каналы): /api/pty (Chat) / /api/ws (Desktop)
• लेयर 4 (इन्फेरेंस प्रदाता / Провайдер инференса): एपीआई कुंजियां, कोटा और नेटवर्क एंडपॉइंट (Ключи API, лимиты и сетевой эндпоинт)

1. नेटवर्क लेयर (HTTP): GET /api/status से सफल प्रतिक्रिया केवल यह साबित करती है कि Uvicorn प्रक्रिया चल रही है और HTTP अनुरोधों का उत्तर दे रही है। यह अनधिकृत एंडपॉइंट यह गारंटी नहीं देता है कि प्राधिकरण पास हो गया है या इंटरैक्टिव चैट इंटरफ़ेस तैयार है।
2. PTY और इंटरफ़ेस लेयर: Connection closed त्रुटि के कई अलग-अलग कारण हो सकते हैं। नेटिव Windows पर, इसका मुख्य नैदानिक कारण POSIX PTY समर्थन का अभाव है (ऐसी स्थिति में निष्पादन को WSL2 में स्थानांतरित किया जाना चाहिए)। अन्य प्लेटफ़ॉर्म पर, यह लक्षण केवल PTY तक सीमित नहीं है और इसके लिए सिस्टम लॉग व सॉकेट कनेक्शन की जांच की आवश्यकता होती है। ब्लैंक स्क्रीन की समस्या या सीएसएस/स्टाइल बिल्ड त्रुटियों के लिए अपने Node.js संस्करण की जांच करने और फ्रंटएंड निर्भरताओं को फिर से बनाने की आवश्यकता होती है।
3. सॉकेट चैनल्स और प्राधिकरण: ब्राउज़र का अंतर्निहित टर्मिनल /api/pty के माध्यम से संचार करता है, जबकि रिमोट डेस्कटॉप क्लाइंट /api/ws पर जुड़ता है। यदि क्लाइंट रिपोर्ट करता है कि बैकएंड पहुंच योग्य है लेकिन सत्र प्रतिक्रिया नहीं दे रहे हैं, तो संबंधित सॉकेट कनेक्शन सत्यापित करें: विफलताएं अक्सर अनुपलब्ध या समाप्त हो चुके सत्र टिकटों (session tickets) से उत्पन्न होती हैं, या जब Host हेडर बाइंड पते से मेल नहीं खाता है तो DNS-रिबाइंडिंग सुरक्षा अनुरोधों को ब्लॉक कर देती है।
4. मॉडल प्रदाता लेयर: सक्रिय टर्मिनल में प्रॉम्प्ट सबमिट करने के बाद होने वाली देरी या त्रुटि संदेश आमतौर पर एपीआई स्तर से उत्पन्न होते हैं (जैसे .env में अमान्य कुंजी, दुर्गम प्रदाता एंडपॉइंट, या समाप्त कोटा और शेष राशि)। हालांकि, प्रदाता त्रुटियां यह साबित नहीं करती हैं कि डैशबोर्ड सर्वर स्वयं पूरी तरह से ठीक है: विफलताओं का निदान करने के लिए रनटाइम स्थिति और सत्र जीवनचक्र (session lifecycle) की जांच करने की भी आवश्यकता हो सकती है।