एआई प्रयोग

मैंने अपने एआई एजेंट को रोमेर्गो में आमंत्रित किया, और मुझे नहीं पता कि यह क्या है या इसे क्या कहा जाए।

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

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

मैं चैट और संपादक के बीच स्विच करते-करते थक गया, और मेरे मन में एक विचार आया: क्या होगा अगर मैं इससे पूरी तरह बच सकूं?

मैंने सीधे संपादक में एक एआई पैनल जोड़ा, लेकिन इसे रोमरगो द्वारा होस्ट किए गए मॉडल से नहीं जोड़ा। इसके बजाय, उपयोगकर्ता अपने व्यक्तिगत एआई एजेंट को खुले सत्र में आमंत्रित करता है।

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

कनेक्ट करने के बाद, उपयोगकर्ता सीधे बिल्डर से एजेंट को लिख सकता है:

• खुले दृश्य का वर्णन करें;
• इस अध्याय में संगीत बदलें;
• हाइलाइट किए गए संवाद को फिर से लिखें;
• एक अलग पृष्ठभूमि रखें;
• संक्रमण तर्क की जाँच करें;
• समझाएं कि दृश्य मेरी अपेक्षा के अनुरूप काम क्यों नहीं कर रहा है।

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

इसकी शुरुआत एक प्रयोग के तौर पर हुई थी

मेरा किसी नए प्रोटोकॉल का आविष्कार करने या नई उत्पाद श्रेणी लाने का कोई इरादा नहीं था। मैं एक सरल विचार का परीक्षण करना चाहता था: क्या एक व्यक्तिगत उपयोगकर्ता एजेंट न केवल एमसीपी के माध्यम से रोमेर्गो को बाहरी रूप से नियंत्रित कर सकता है, बल्कि अस्थायी रूप से संपादक के अंदर एक लाइव सत्र में शामिल हो सकता है?

पहला संस्करण एक प्रयोग था. मुझे आश्चर्य हुआ कि इसने इतना अच्छा काम किया कि मैं स्वयं इसका उपयोग शुरू कर सका।

सबसे छोटा आरेख इस प्रकार खींचा जा सकता है:

Personal AI agent  <->  MCP  <->  Romergo Builder

लेकिन दोनों दिशाओं में संकेत महत्वपूर्ण है।

एक सामान्य एमसीपी कॉल एजेंट पर शुरू होती है: एजेंट एप्लिकेशन से संपर्क करने का निर्णय लेता है और उसके टूल को कॉल करता है। मेरे प्रयोग में रोमेर्गो भी काम शुरू कर सकता है. उपयोगकर्ता बिल्डर में एक कमांड लिखता है, रोमरगो इसे एक सुरक्षित चैनल में रखता है, और पहले से कनेक्टेड एजेंट एमसीपी के माध्यम से कमांड प्राप्त करता है।

फिर एजेंट प्रोजेक्ट को पढ़ने या संशोधित करने के लिए सामान्य रोमरगो टूल का उपयोग करता है और उसी चैनल के माध्यम से बिल्डर को परिणाम लौटाता है।

यह एक बंद लूप बनाता है:

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

रोमरगो इनमें से किसी भी चरण पर मॉडल नहीं चलाता है।

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

द्विदिशात्मक व्यवहार एप्लिकेशन-सत्र स्तर पर दिखाई देता है, नए एमसीपी ट्रांसपोर्ट के माध्यम से नहीं। यह अंतर मायने रखता है: वर्तमान कार्यान्वयन को मानक एमसीपी कॉल के शीर्ष पर निर्मित एक छोटे सत्र अनुबंध के रूप में सबसे अच्छी तरह समझा जाता है।

एक एजेंट सत्र में कैसे प्रवेश करता है

बिल्डर एक अस्थायी चैनल कोड बनाता है. उपयोगकर्ता अपने एआई चैट में कुछ इस तरह से एक संक्षिप्त प्रारंभिक संकेत कॉपी करता है:

मेरे रोमरगो बिल्डर चैनल से जुड़ें। प्रत्येक नए कमांड को एक बार चलाएँ, परिणाम या प्रश्न बिल्डर को वापस भेजें, और तब तक प्रतीक्षा करते रहें जब तक मैं आपको स्पष्ट रूप से रुकने के लिए न कहूँ।

एजेंट फिर MCP टूल romergo_join_builder_channel को कॉल करता है और कोड पास करता है। यह एक हैंडशेक है: रोमरगो OAuth सत्र, चैनल के मालिक और उसकी समाप्ति तिथि की जांच करता है, और फिर वार्तालाप स्थिति और अंतिम कमांड कर्सर लौटाता है।

इसके बाद, एजेंट romergo_wait_for_builder_command को कॉल करता है। यह एक लंबा सर्वेक्षण है जो संपादक के अगले आदेश की प्रतीक्षा करता है। यदि कुछ नहीं आता है, तो एजेंट कर्सर को सहेज लेता है और फिर से प्रतीक्षा करना शुरू कर देता है। यदि आदेश मौजूद है, तो इसमें शामिल है:

• निर्देश पाठ;
• कमांड आईडी;
• मोनोटोनिक अनुक्रम;
• बिल्डर में वर्तमान पथ;
• खुले प्रोजेक्ट, अध्याय और दृश्य की आईडी, जब वे यूआरएल में हों;
• संपादक सतह प्रकार और संदर्भ कैप्चर समय;
• उपयोगकर्ता द्वारा चयनित पाठ, यदि कोई हो।

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

एजेंट मौजूदा रोमरगो एमसीपी टूल का उपयोग करके कार्य करता है। उदाहरण के लिए, यह प्रोजेक्ट और अध्याय को पढ़ सकता है, परिसंपत्तियां ढूंढ सकता है, दृश्य बदल सकता है और फिर सहेजे गए परिणाम को सत्यापित कर सकता है।

जब यह काम कर रहा हो, तो एजेंट romergo_report_builder_event को कॉल कर सकता है और पैनल भेज सकता है:

• status - लघु मध्यवर्ती स्थिति;
• question - एक ऐसा प्रश्न जिसके उत्तर के बिना इसे जारी रखना सुरक्षित नहीं है;
• reply - समाप्त परिणाम;
• error - त्रुटि का स्पष्ट विवरण।

प्रतिक्रिया commandId से जुड़ी है, और अगला आदेश अंतिम संसाधित अनुक्रम से पढ़ा जाता है। जब पहली बार जारी किया जाता है, तो एपीआई परमाणु रूप से client_id OAuth क्लाइंट को कमांड सौंपता है। कोई अन्य कनेक्टेड एजेंट एक ही समय में समान कार्य नहीं कर पाएगा. कर्सर टाइमआउट या पुन: कनेक्शन के बाद जारी रखने में मदद करता है, और विशिष्ट टूल कॉल की एक बार की पुष्टि एक तर्क फिंगरप्रिंट द्वारा संरक्षित होती है और इसे किसी अन्य कार्रवाई के लिए पुन: उपयोग नहीं किया जा सकता है।

अधिकार कमरे के हैं, प्रॉम्प्ट के नहीं

कनेक्ट करने से पहले, उपयोगकर्ता चैनल सेटिंग्स देखता है और चुनता है कि एजेंट को क्या करने की अनुमति है: प्रोजेक्ट पढ़ें, सामग्री संपादित करें, मीडिया और ऑडियो के साथ काम करें, डेटा प्रकाशित करें या हटाएं। इन सेटिंग्स को पैनल हेडर में गियर के माध्यम से किसी भी समय खोला जा सकता है।

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

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

प्रत्येक संशोधित टूल की शुरुआत, पूर्णता, त्रुटि और अवरोधन स्वचालित रूप से पैनल पर वापस आ जाते हैं। प्रत्येक अंतिम उत्तर में स्थिति और परिणाम के विशिष्ट विवरण के साथ एक संरचित सारांश होना चाहिए। परिवर्तनों के बाद, एजेंट बदली हुई संस्थाओं, की गई जाँचों और परिणाम के लिंक को भी सूचीबद्ध करता है; बिल्डर इस सारांश को सीधे प्रतिक्रिया पाठ के नीचे प्रदर्शित करता है। चैनल को सेटिंग्स से स्पष्ट रूप से समाप्त किया जा सकता है; पुराना कोड तुरंत काम करना बंद कर देता है.

रोमेर्गो में क्या है, और उपयोगकर्ता के पास क्या रहता है

मैं इस वास्तुकला को चिंताओं के पृथक्करण के रूप में सोचना पसंद करता हूं।

रोमेर्गो प्रदान करता है:

• संपादक और दृश्य कार्यक्षेत्र;
• वर्तमान परियोजना, पृष्ठ और चयन;
• दोतरफा संचार के लिए अस्थायी कमरा;
• किसी प्रोजेक्ट को पढ़ने, संशोधित करने और जाँचने के लिए डोमेन-विशिष्ट उपकरण;
• OAuth, पहुंच अधिकार और सत्र ईवेंट इतिहास;
• एक इंटरफ़ेस जिसमें उपयोगकर्ता प्रश्न, प्रगति और परिणाम देखता है।

उपयोगकर्ता एजेंट लाता है:

• मॉडल और गणना;
• स्वयं की सदस्यता;
• तर्क और योजना;
• स्मृति और वैयक्तिकरण, यदि चयनित एजेंट द्वारा प्रदान किया गया हो;
• अन्य जुड़े उपकरण;
• उपयोगकर्ता से परिचित कार्यशैली।

इंटेलिजेंस एप्लिकेशन से संबंधित नहीं है. ऐप एक ऐसी जगह बनाता है जहां यह इंटेलिजेंस सुरक्षित रूप से काम कर सकता है।

एक नियमित अंतर्निर्मित सहपायलट क्यों नहीं बनाते?

अंतर्निहित AI को समझाना आसान होगा और सक्षम करना आसान होगा। उपयोगकर्ता एक बटन दबाता है, एप्लिकेशन चयनित मॉडल को कॉल करता है, सब कुछ काम करता है।

लेकिन तब रोमेर्गो को एआई इंफ्रास्ट्रक्चर का ऑपरेटर भी बनना होगा:

• अनुमान के लिए भुगतान करें या इसकी लागत को किसी योजना के माध्यम से पारित करें;
• उपयोगकर्ता के लिए मॉडल चुनें;
• अपनी स्वयं की स्मृति और वैयक्तिकरण बनाएं;
• बाहरी सेवाओं को पुनः कनेक्ट करें;
• अतिरिक्त संवेदनशील संदर्भ संग्रहीत करें;
• क्षैतिज AI उत्पादों की क्षमताओं को लगातार पकड़ते रहें।

व्यक्तिगत एजेंट का उपयोग करते समय, यह सब उपयोगकर्ता पक्ष पर पहले से ही मौजूद होता है। रोमेर्गो कोई अन्य चैटजीपीटी बनाने का प्रयास नहीं कर रहा है। यह चैटजीपीटी, क्लाउड या किसी अन्य एजेंट को एक विशेष कार्यक्षेत्र और स्पष्ट उपकरण देता है।

यह एक रचनात्मक संपादक के लिए विशेष रूप से दिलचस्प है। वही एजेंट जान सकता है कि उपयोगकर्ता संवाद कैसे लिखता है, उन्हें कौन सा स्वर पसंद है, कौन से संदर्भों पर पहले ही चर्चा हो चुकी है, और वे कौन से बाहरी टूल का उपयोग करते हैं। रोमेर्गो को केवल एक पृष्ठभूमि को बदलने या किसी दृश्य को पुनर्व्यवस्थित करने में मदद के लिए इस पूरे सिस्टम की प्रतिलिपि बनाने की आवश्यकता नहीं है।

सबसे अजीब हिस्सा: एजेंट बाहर और अंदर दोनों है

एजेंट भौतिक रूप से रोमेर्गो नहीं जाता है। इसका मॉडल और एजेंट लूप मूल AI क्लाइंट में चलते रहते हैं।

लेकिन उपयोगकर्ता के दृष्टिकोण से, एजेंट संपादक के अंदर मौजूद है:

• अंतर्निर्मित पैनल से आदेश प्राप्त करता है;
• जानता है कि उपयोगकर्ता किस पृष्ठ पर है;
• संलग्न चयन देखता है;
• उसी प्रोजेक्ट को बदलता है;
• प्रश्न पूछता है और उसी पैनल को उत्तर लौटाता है;
• पेज बदलने या पुनः कनेक्ट करने के बाद बातचीत जारी रख सकते हैं।

इसलिए, अभिव्यक्ति "एप्लिकेशन के अंदर एआई" और "एमसीपी के माध्यम से बाहर एआई" दोनों यहां पूरी तरह से सटीक नहीं हैं। बल्कि यह एप्लिकेशन सत्र में किसी बाहरी एजेंट की अस्थायी उपस्थिति है।

मैं इस दिशा में आगे बढ़ने वाला पहला व्यक्ति नहीं हूं

प्रयोग के सफल होने के बाद, मैंने इसी तरह के तरीकों की तलाश शुरू कर दी।

[एजेंट क्लाइंट प्रोटोकॉल] (https://agentclientprotocol.com/) Zed और JetBrains जैसे संपादकों को बाहरी कोडिंग एजेंटों को कनेक्ट करने की अनुमति देता है। [टाइडवेव](आरजीपीआरएसईआरवीई001टोकन) क्लाउड कोड, कोडेक्स और अन्य एसीपी एजेंटों को चल रहे वेब एप्लिकेशन के बगल में रखता है और उन्हें ब्राउज़र और रनटाइम संदर्भ से गुजरता है। [ओब्सीडियन एजेंट क्लाइंट] (https://community.obsidian.md/plugins/agent-client) नोट्स के ठीक बगल में क्लाउड कोड, कोडेक्स और जेमिनी दिखाता है और सक्रिय दस्तावेज़ और चयन को स्वचालित रूप से संलग्न करता है। मैरिमो बाहरी एजेंट को साझा कार्यक्षेत्र के रूप में एक लाइव नोटबुक देता है।

और भी सामान्य प्रयोग हैं। AG-UI यूजर इंटरफेस और एजेंट बैकएंड के बीच दो-तरफा संचार को मानकीकृत करता है। WebMCP का प्रस्ताव है कि वेब पेज किसी कनेक्टेड ब्राउज़र या डेस्कटॉप एजेंट के लिए उपलब्ध टूल को पंजीकृत करें। [एजेंट एप्लिकेशन प्रोटोकॉल] (https://agentapplicationprotocol.com/overview) एक मॉडल का वर्णन करता है जिसमें एप्लिकेशन यूआई और डोमेन टूल का मालिक होता है, और बाहरी एजेंट तर्क, इतिहास और सामान्य-उद्देश्य वाले टूल का मालिक होता है।

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

रोमेर्गो प्रयोग मेरे लिए थोड़ा अलग प्रश्न के कारण दिलचस्प है: यदि एक व्यक्तिगत उपयोगकर्ता एजेंट एक नियमित रचनात्मक एप्लिकेशन में प्रवेश कर सके तो क्या होगा?

कोई नया मॉडल नहीं. मॉडल के लिए एपीआई कुंजी नहीं. बिल्ट-इन कोपायलट एप्लिकेशन नहीं। एक एजेंट जिसे एक व्यक्ति पहले से ही हर दिन उपयोग करता है।

सुविधा केवल आधी समस्या है

एक बार जब कोई बाहरी एजेंट एप्लिकेशन कमांड सुन सकता है और प्रोजेक्ट बदल सकता है, तो सुरक्षा अब एक वैकल्पिक सुविधा नहीं है।

ऐसे प्रश्न उठते हैं जिनका उत्तर एक OAuth स्क्रीन से नहीं दिया जा सकता:

• किसी विशिष्ट कक्ष के लिए कौन से पृष्ठ और संस्थाएँ उपलब्ध हैं;
• पुष्टि के बिना किन कार्यों की अनुमति है;
• क्या प्रोजेक्ट टेक्स्ट में शीघ्र इंजेक्शन शामिल हो सकता है;
• एक एजेंट को उपयोगकर्ता कमांड को अविश्वसनीय डेटा से कैसे अलग करना चाहिए;
• टाइमआउट के बाद कमांड का क्या होता है;
• उपयोगकर्ता को वास्तविक परिवर्तन कैसे दिखाएं, न कि केवल एक आश्वस्त पाठ उत्तर;
• किसी सत्र को कैसे रद्द करें और साबित करें कि एजेंट ने वास्तव में सुनना बंद कर दिया है;
• किसी विशेष एप्लिकेशन में व्यक्तिगत एजेंट की मेमोरी और बाहरी कनेक्शन का कौन सा हिस्सा उपयोग करने के लिए स्वीकार्य है।

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

इसे क्या कहें

मेरे पास अभी तक कोई अंतिम शीर्षक नहीं है।

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

शायद यह है:

• एक लाइव एजेंट चैनल;
• एक एप्लिकेशन-एजेंट सत्र;
• एक एजेंट उपस्थिति परत;
• एक निजी एजेंट ब्रिज;
• द्विदिश एमसीपी;
• या मौजूदा विचारों के शीर्ष पर बस एक सफल प्रयोग।

मैं सिर्फ नाम के लिए कोई नया मानक नहीं लाना चाहता। सबसे पहले, मेरे लिए यह समझना अधिक महत्वपूर्ण है कि क्या ऐसा मॉडल रोमेर्गो के बाहर उपयोगी है और इस पर भरोसा करने के लिए किन सीमाओं की आवश्यकता है।

एप्लिकेशन को मूल AI की आवश्यकता नहीं हो सकती है

आज, लगभग हर उत्पाद अपना स्वयं का सहायक बनाने का प्रयास करता है। परिणामस्वरूप, उपयोगकर्ता के पास कई अलग-अलग एआई हैं: एक संपादक में, दूसरा मेल में, तीसरा कार्य प्रणाली में। प्रत्येक की अपनी संक्षिप्त स्मृति, अपनी सीमाएँ और अपनी कीमत होती है।

एक और संभावित मॉडल है.

ऐप एक कार्यक्षेत्र, लाइव संदर्भ और विशेष उपकरण प्रदान करता है। उपयोगकर्ता एक एजेंट लाता है जिस पर उन्हें पहले से ही भरोसा है। काम करते समय, एजेंट एप्लिकेशन से जुड़ता है, कार्य पूरा करने में मदद करता है और उपयोगकर्ता के साथ चला जाता है।

मैं अभी तक नहीं जानता कि यह एक स्वतंत्र वास्तुशिल्प श्रेणी बनेगी या नहीं। लेकिन अब मुझे पता है कि ऐसी साइकिल को असेंबल किया जा सकता है और इसका वास्तव में उपयोग भी किया जा सकता है।

लेकिन मैं जानता हूं कि प्रयोग करना बहुत मजेदार है।

डेव ब्लॉग पर वापस जाएँ