फ़िलहाल मैंने MCP(Model Context Protocol) के ज़रिए 32 देशों की news/information collection service और प्रमुख देशों (अमेरिका, जापान, ब्रिटेन, कोरिया) तथा coin/futures market के daily snapshots उपलब्ध कराने वाला एक फ़ीचर विकसित किया है। अभी मैं इसी के आधार पर OpenClaw की तरह अधिक स्वतंत्र रूप से काम करने वाला एक investment program बना रहा हूँ.
मैं जिन दो बिंदुओं पर विचार कर रहा हूँ, वे ये हैं।
-
AI की 'स्वतंत्रता' और frontend UI का सह-अस्तित्व
मैं पारंपरिक software की तरह तयशुदा UI और फ़ीचर मूल रूप से उपलब्ध कराते हुए, हर फ़ीचर को API में बदलकर इस तरह इम्प्लीमेंट कर रहा हूँ कि IDE या AI उन्हें पूरी तरह समझ और नियंत्रित कर सके। अंततः मुझे लगता है कि भविष्य का software development इस बात पर केंद्रित होगा कि AI कितनी स्वतंत्रता से फ़ीचर को विस्तार दे सकता है और चला सकता है, यानी 'AI की स्वतंत्रता' पर। इस बारे में आप सबकी राय जानना चाहता हूँ। -
user experience में बदलाव: "यह कर दो" का युग
आगे चलकर users सिर्फ "यह कर दो" जैसे साधारण command से मनचाहा परिणाम पाना चाहेंगे। यहाँ तक कि अगर कोई फ़ीचर developer ने पहले से परिभाषित न भी किया हो, तब भी AI को सीधे internet search करके या code लिखकर user की ज़रूरत पूरी करनी चाहिए। (उदाहरण: कोई legal program भी user के कहने पर flight booking में मदद कर सके, इस स्तर तक)
अगर technology को user को अत्यधिक सुविधा देनी है, तो हम developers को 'closed features' नहीं बल्कि 'open extensibility' के बारे में कहाँ तक सोचना चाहिए? OpenClaw जैसे agents के उभरने से इन दिनों यह सोच और गहरी हो गई है.
5 टिप्पणियां
मैं खुद पहला मामला टेस्ट कर रहा/रही हूँ
नतीजे में, जैसे-जैसे असफल अनुभव जमा होते गए, वह खुद ही अपने ऊपर पाबंदियां लगाना शुरू कर दिया।
जानकारी के लिए, मैं अभी hallucination को pass channel exploration engine की तरह इस्तेमाल करने वाले चरण में हूँ।
(a) मौजूदा ऐप की क्षमताओं का और विस्तार करना
(b) पहले से आज़माई गई, इंसानों द्वारा की जाने वाली विभिन्न सेवाओं के API को जोड़कर क्षमताओं का विस्तार करना
(a) के मामले में अभी AI पर छोड़कर उसे मनमाने ढंग से फ़ीचर विस्तार करने देना भरोसेमंद नहीं लगता।
(b) नियंत्रित होने की वजह से वह फिर भी कुछ बेहतर विकल्प लगता है.
लेकिन मुझे नहीं लगता कि कोई 'कानूनी प्रोग्राम' जाकर फ्लाइट बुकिंग करेगा। तब वह कानूनी प्रोग्राम रहेगा ही नहीं। वह तो एक सामान्य-उद्देश्य वाला Her OS बन जाएगा। जैसे लोगों के संगठन और ज़िम्मेदारियाँ बाँटने के पीछे कारण हैं, वैसे ही प्रोग्रामिंग/आर्किटेक्चर को भी बाँटकर बनाने के पीछे कारण हैं। जो मैं चाहता हूँ उसे सच में समझकर हर काम मेरी पसंद के अनुसार संभाल लिया जाए — यह बात किसी डिजिटल क्लोन की चर्चा जैसी लगती है।
"यह कर दो" का मतलब एक निजी सहायक जैसा सिस्टम है, जो मुझे लंबे समय से जानता हो, इसलिए मुझे हर बात बहुत ठोस और विस्तार से बतानी न पड़े (आजकल बहुत चर्चा में रहने वाले spec-driven की तरह नहीं)। लेकिन इसके लिए उसे मेरे बारे में सब कुछ स्कैन करके ज्ञान जमा करना होगा और याद रखना होगा, और फिर भी अंत में कुछ न कुछ गलती होगी (Her में भी शुरुआती सेटिंग के समय यूज़र के ईमेल और सारे डेटा को जाँचने वाला दृश्य आता है) -- फिर ज़रूरी यह है कि वह उन गलतियों को कितनी अच्छी तरह पहचान और फ़िल्टर कर सकता है, या उन्हें सुधारना जानता है; और अभी लगता है कि हम उससे काफ़ी दूर हैं। लोगों से काम करवाकर देखें तो पता चलता है कि 10-20 साल साथ काम करने वाले लोग भी मेरी मंशा को पूरी तरह नहीं समझते, या जिनमें समझदारी कम होती है वे बार-बार वही गलती करते रहते हैं... जब इंसान की यह हालत है, तो मुझे लगता है कि पहले momento जैसी, और बिना ज़िम्मेदारी वाली AI को कम से कम इंसानों के इस स्तर तक लाना ज़रूरी है।
आपने जिस खुले विस्तार की बात की, वैसा हो तो अच्छा है, लेकिन उसके लिए वह एक सामान्य-उद्देश्य वाली निजी सहायक AI होनी चाहिए (जैसा ऊपर किसी और ने लिखा, टोस्टर कोई दूसरा काम न करने लगे), और उसे यूज़र के साथ इंटरैक्शन के ज़रिए लगातार यूज़र को सीखते रहना होगा। मैं नहीं चाहूँगा कि कार टैक्स रिटर्न तैयार करे। इंसानों के साथ भी यही बात लागू होती है; आपने किसी कर्मचारी को एक खास काम दिया, और वह उससे अलग दूसरे काम भी करने लगे, तो नियोक्ता खुश भी हो सकता है, लेकिन ज़्यादातर मामलों में शायद चिंतित ही होगा.
स्पष्ट documentation और अच्छी तरह डिज़ाइन की गई accessibility आखिरकार जीतती है। AI की स्वतंत्रता पर अलग से फोकस किए बिना भी, अच्छी तरह डिज़ाइन की गई accessibility इंसानों और AI दोनों के लिए समझना आसान बनाती है.
नहीं, least privilege principle का पालन ज़रूर होना चाहिए। मैं चाहता हूँ कि मेरा toaster सिर्फ़ ब्रेड टोस्ट करे; मैं यह नहीं चाहता कि वह इंटरनेट से कनेक्ट होकर news summarize करे और Doom चलाए.
दार्शनिक रूप से मैं Andy Clark के extended mind सिद्धांत की सिफारिश करूँगा। यह समझने में गहराई देगा कि केवल दिखावे पर टिका LLM टूल्स के माध्यम से cognition तक कैसे विस्तृत होता है।
व्यावहारिक रूप से OpenCode में agent configuration के हर हिस्से खुले हैं, इसलिए यह आपके लिए मददगार होगा।
दूसरा बिंदु तो पहले से ही हकीकत है। शुरू में दिए गए टूल्स में से एक code interpreter था। इसलिए, किसी खास domain agent के बारे में मेरी राय यह है कि वह आखिरकार एक अल्पकालिक लड़ाई है जो खत्म हो जाएगी।
आप जिस domain पर अभी काम कर रहे हैं, उसमें शायद पारंपरिक ML को MCP के रूप में उपलब्ध कराना बेहतर होगा। language model pattern analysis या linear prediction में बिल्कुल भी फायदेमंद नहीं हैं।
सिर्फ इंसानी UI के आधार पर tool symmetry डिज़ाइन करने की ज़रूरत नहीं लगती। वैसे भी webMCP या GDI-आधारित automated MCP, जहाँ agent खुद UI को समझेगा और नियंत्रित करेगा, बहुत जल्द आ जाएगा। क्योंकि इंसानों के लिए बने कई legacy systems का उपयोग करना ही पड़ेगा। अगर native multimodal क्षमताओं वाला LLM-आधारित agent हो, तो developer को GUI को MCP में अनुवाद करने की मेहनत करने की ज़रूरत ही नहीं रहेगी। foundation स्तर पर GUI पर मज़बूत पकड़ रखने वाला iOS शायद अगला version आते ही इसकी शुरुआत कर दे।
फिर तो बस कोई भी stock app इंस्टॉल करके agent को investment सौंपा जा सकेगा।