घरेलू एजेंट के लिए Kimaki के साथ OpenCode मुफ्त टियर
नमस्ते, मैं अक्षम हूँ।
मैं होम सर्वर पर रहने वाले एजेंट के विचार के खिलाफ था, लेकिन मुफ्त टियर में इसे हासिल करना मुश्किल लग रहा था, इसलिए मैंने नहीं किया। फिर भी, बाहर से समानांतर जाँच कराने या आसानी से रुचि के आँकड़ों के चार्ट प्लॉट कराने की इच्छा हुई।
तो, मैं सोच रहा था कि OpenCode के करीब एक बॉट कैसे बनाया जाए। OpenClaw का रिपॉजिटरी खुद बहुत शानदार है, लेकिन कुछ अलग इस्तेमाल करने की इच्छा से खोजने पर मुझे Kimaki मिला, इसलिए मैंने इसे आज़माया।
इससे पहले मैंने OpenCode को रैप करके बॉट एजेंट के रूप में चलाने की कोशिश की थी, लेकिन कई बदलावों का प्रबंधन खुद करना मुश्किल था, इसलिए अगर तैयार समाधान से काम चल जाए तो अच्छा होगा।
आवश्यकताएँ:
Discord का स्पष्ट रूप से समर्थन होना
OpenCode की सब्सक्रिप्शन के तहत मुफ्त में चलाने में सक्षम होना
Kimaki का उपयोग करना
इंस्टॉलेशन
https://github.com/remorses/kimaki
npx -y kimaki@latestअगर आपने OpenCode इंस्टॉल नहीं किया है तो यह इसे इंस्टॉल कर देगा, और bun भी इंस्टॉल होगा क्योंकि यह निर्भरता के रूप में आवश्यक है।
फिर अंत में दिखाई देने वाले लिंक से Kimaki बॉट को अपने सर्वर पर आमंत्रित करना ही काफी है।
इसके अलावा, इस स्थिति में डिफ़ॉल्ट रूप से बॉट Kimaki के माध्यम से चल रहा है, इसलिए बेहतर होगा कि चैट में गोपनीय चीज़ें साझा न करें, और शायद एक समर्पित Discord सर्वर बनाना भी उचित रहेगा।
अपने Dev Portal से बॉट बनाने की झंझट नहीं है, इसलिए आसानी के मामले में यह अच्छा लगता है।
मॉडल बदलने के लिए इसे /model के माध्यम से बदला जा सकता है, इसलिए केवल Discord के ज़रिए ही कुछ हद तक आसानी हो सकती है।
इसके अलावा, इसी के साथ OpenCode API कॉल के दौरान एक विशेष HTTP हेडर का उपयोग करता है, जैसा कि नीचे दिखाया गया है।
https://github.com/earendil-works/pi/issues/2824
क्या API सर्वर की डिज़ाइन में 403 के बजाय 429 लौटाकर जानबूझकर अस्पष्टता पैदा की गई है ताकि दुरुपयोग से बचा जा सके? वास्तव में, OpenCode द्वारा जारी किए जाने वाले API Key को OpenCode एजेंट तक सीमित रखने का इरादा हो सकता है, लेकिन वर्तमान में इस API एंडपॉइंट पर API Key प्रमाणीकरण के साथ अनुरोध करना संभव है, इसलिए मुझे लगता है कि नई प्रमाणीकरण प्रणाली या कंपनियों द्वारा दुरुपयोग रोकने के समाधान के उपयोग के मामले आगे बढ़ेंगे।
उदाहरण के लिए, यदि mTLS के रूप में उपयोगकर्ताओं को क्लाइंट प्रमाणपत्र वितरित किए जाएँ और उन्हें समर्पित TPM या EC कंट्रोलर जैसी सुरक्षा चिप में संग्रहीत किया जाए, ताकि बिना किसी निश्चित मार्ग के कॉल न हो सके, तो शायद आज की स्वतंत्र रूप से हिट करने वाली दुनिया समाप्त हो सकती है।
लेकिन आखिरकार, यदि क्लाइंट प्रमाणपत्र रिवर्स इंजीनियरिंग द्वारा निकाल लिया गया तो वह भी बेकार है। हालाँकि, TPM तकनीक में हालिया प्रगति को देखते हुए BIOS पासवर्ड को क्रैक करना काफी कठिन हो गया है, इसलिए भविष्य में हार्डवेयर-एकीकृत अनुप्रयोगों की सुरक्षा बढ़ाने वाली सुविधाएँ भी सामने आ सकती हैं।