मानवीय मंज़ूरी और टेस्ट सत्यापन के साथ n8n में कोड बदलाव का वर्कफ़्लो बनाएं

वर्कफ़्लो एक नज़र में

n8n की मदद से AI एजेंट को रिपॉज़िटरी में बदलाव का प्रस्ताव देने दें, लेकिन write operation को मानवीय मंज़ूरी के अधीन रखें। मंज़ूरी के बाद बने हुए सटीक commit पर टेस्ट चलाएं और नतीजे की रिपोर्ट दें। merge या deployment को अलग निर्णय रखें।

यहां मुख्य अंतर टूल की मंज़ूरी और आउटपुट की मंज़ूरी के बीच है। n8n में मानवीय समीक्षा का चरण चुने हुए टूल के चलने से पहले AI Agent को रोक सकता है। समीक्षक को प्रस्तावित टूल और उसके parameters दिखते हैं; मंज़ूरी पर वह call चलती है, जबकि अस्वीकृति पर वह रद्द हो जाती है और एजेंट को इसकी सूचना मिलती है। यह व्यवहार n8n की human-in-the-loop गाइड में दर्ज है।

OneMux एक OpenAI-compatible API के ज़रिए AI मॉडल उपलब्ध कराता है। इस डिज़ाइन में यह मॉडल एक्सेस का एक संभावित विकल्प है, सत्यापित n8n एकीकरण नहीं। आप जिस endpoint और parameters का इस्तेमाल करना चाहते हैं, उनके लिए OneMux API दस्तावेज़ और अपने n8n node की कॉन्फ़िगरेशन जांचें।

शुरुआत से पहले क्या चाहिए

• AI Agent, उपयुक्त chat model कनेक्शन और Slack या n8n Chat जैसे मानवीय समीक्षा चैनल तक पहुंच वाला n8n instance।
• ऐसी रिपॉज़िटरी इंटीग्रेशन या कस्टम सेवा जो निर्दिष्ट revision पढ़ सके और non-production branch पर patch लागू कर सके। उसके write credential को केवल उस रिपॉज़िटरी और branch के लिए ज़रूरी पहुंच दें।
• production credentials और systems से अलग-थलग test runner। उसे सटीक commit identifier स्वीकार करना और status के साथ नतीजों का लिंक या संदर्भ लौटाना चाहिए।
• मॉडल calls के लिए OneMux चुनने पर OneMux अकाउंट और API एक्सेस। कनेक्शन की मौजूदा जानकारी के लिए quickstart और उपलब्ध मॉडल चुनने के लिए model catalogue देखें।
• ज्ञात test command और सुरक्षित default branch वाली रिपॉज़िटरी तथा प्रस्तावित बदलावों की समीक्षा के लिए अधिकृत व्यक्ति।

यह लागू करने का एक पैटर्न है, import किया जा सकने वाला वर्कफ़्लो नहीं। रिपॉज़िटरी टूल, runner integration, मॉडल का चुनाव और n8n के सटीक fields आपके वातावरण पर निर्भर करते हैं। खास तौर पर, दिए गए दस्तावेज़ यह स्थापित नहीं करते कि कोई विशेष OneMux मॉडल n8n AI Agent के लिए ज़रूरी tool-calling व्यवहार का समर्थन करता है। इस डिज़ाइन पर निर्भर होने से पहले इसकी पुष्टि करें।

सटीक revision के आधार पर वर्कफ़्लो डिज़ाइन करें

एक व्यावहारिक क्रम यह है:

1. अनुरोध प्राप्त करें। भरोसेमंद वर्कफ़्लो कॉन्फ़िगरेशन से रिपॉज़िटरी, issue का विवरण, लक्ष्य working branch, base commit और अनुमत test command लें।
2. पढ़ें और प्रस्ताव दें। एजेंट को base commit पर संबंधित फ़ाइलें जांचने और patch तैयार करने दें। पढ़ने की पहुंच से रिपॉज़िटरी में बदलाव करना संभव नहीं होना चाहिए।
3. write की समीक्षा करें। patch लागू करने वाले टूल को n8n की मानवीय समीक्षा से गुज़ारें। समीक्षक प्रस्तावित tool call को मंज़ूर या अस्वीकार करता है।
4. लागू करें और पहचान दर्ज करें। मंज़ूरी मिलने पर write सेवा जांचती है कि branch अभी भी मंज़ूर किए गए base commit की ओर इशारा करती है, फिर मंज़ूर patch लागू करके नया commit ID लौटाती है। अगर base बदल गया हो, तो सुरक्षित ढंग से प्रक्रिया रोकें और नया प्रस्ताव व मंज़ूरी मांगें।
5. सत्यापित करें। अलग-थलग runner में ठीक उसी नए commit पर कॉन्फ़िगर किए गए टेस्ट चलाएं। command, commit, status और नतीजों का संदर्भ दर्ज करें।
6. रिपोर्ट दें। समीक्षक और अनुरोधकर्ता को commit और टेस्ट का नतीजा भेजें। विफल, रद्द या अनुपलब्ध टेस्ट नतीजा पास नहीं माना जाता।

ये अनुशंसित नियंत्रण हैं, n8n के मानवीय समीक्षा चरण द्वारा गारंटीकृत सुविधाएं नहीं। खास तौर पर, आपकी रिपॉज़िटरी सेवा को base-commit की जांच लागू करनी होगी और सुनिश्चित करना होगा कि वही patch लागू हो जिसे मंज़ूरी मिली थी।

मॉडल कनेक्शन कॉन्फ़िगर करें

n8n में ऐसा chat model कॉन्फ़िगरेशन चुनें जो कॉन्फ़िगर किए जा सकने वाले OpenAI-compatible endpoint और आपके AI Agent के लिए ज़रूरी tool-calling व्यवहार का समर्थन करे। मौजूदा OneMux दस्तावेज़ में निर्दिष्ट endpoint, authentication method और model identifier का इस्तेमाल करें। credentials को prompts या वर्कफ़्लो संदेशों के बजाय n8n के credential system में रखें।

रिपॉज़िटरी एक्सेस जोड़ने से पहले एक छोटा परीक्षण अनुरोध करें और जांचें कि response, n8n node को अपेक्षित फ़ॉर्मैट में आता है या नहीं। फिर कोई नुकसान न पहुंचाने वाली tool call जांचें। OpenAI-compatible होने का मतलब यह नहीं कि हर endpoint, parameter या tool-call फ़ॉर्मैट एक-दूसरे की जगह इस्तेमाल हो सकता है: यहां संगतता इस पर निर्भर है कि दोनों पक्ष ज़रूरी requests और responses का समर्थन करते हैं या नहीं। इस लेख के लिए इस कॉन्फ़िगरेशन का परीक्षण नहीं किया गया है।

अगर उपलब्ध मॉडल कनेक्शन एजेंट की tool calls का समर्थन नहीं कर सकता, तो मॉडल को सीधे write credentials देकर मंज़ूरी प्रक्रिया को दरकिनार न करें। संगत कॉन्फ़िगरेशन इस्तेमाल करें या write सेवा को काम सौंपने के लिए अलग, स्पष्ट रूप से समीक्षित प्रक्रिया बनाएं।

रिपॉज़िटरी write पर मानवीय मंज़ूरी लगाएं

AI Agent node में Tools connector खोलें और Tools Panel में Human review ढूंढ़ें। मंज़ूरी का चैनल चुनें और उसके credentials कॉन्फ़िगर करें। रिपॉज़िटरी में लिखने वाले टूल को समीक्षा चरण के tool connector से जोड़ें। जहां उचित हो, केवल पढ़ने वाले टूल अलग रखें और बाहरी स्थिति बदल सकने वाले अन्य टूल को भी उनकी अपनी समीक्षा या समान नियंत्रण के अधीन रखें।

n8n दस्तावेज़ के अनुसार, समीक्षक को टूल का नाम और AI द्वारा दिए गए parameters मिल सकते हैं। उदाहरण के लिए, समीक्षा संदेश इस तरह कॉन्फ़िगर करें:

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

ऐसा write टूल इस्तेमाल करें जिसके समीक्षा योग्य inputs में रिपॉज़िटरी, branch, base commit और पूरा patch या digest के साथ अपरिवर्तनीय patch reference शामिल हो। अगर patch चैनल के लिए बहुत बड़ा है, तो समीक्षा के लिए सुरक्षित और सुलभ स्थान दें तथा सुनिश्चित करें कि write सेवा वही सामग्री लागू करे। “टेस्ट ठीक करें” जैसा अस्पष्ट निर्देश किसी खास रिपॉज़िटरी बदलाव को मंज़ूरी देने के लिए पर्याप्त नहीं है।

दस्तावेज़ में बताए गए $tool.parameters के मानों में $fromAI() expressions से कॉन्फ़िगर किए गए fields शामिल हैं; यह न मानें कि संदेश हर fixed credential, छिपी कॉन्फ़िगरेशन वैल्यू या आगे होने वाले प्रभाव को दिखाता है। fixed settings को सीमित रखें और समीक्षकों को उन्हें जांचने का अलग तरीका दें। tool parameters में secrets रखने से बचें, क्योंकि parameters मंज़ूरी संदेशों में दिखाई दे सकते हैं।

ऐसा system instruction जोड़ें जिसमें मंज़ूरी के अधीन टूल का नाम हो और एजेंट को बताया गया हो कि अस्वीकृति पर क्या करना है। उदाहरण के लिए:

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

यह निर्देश एजेंट को समीक्षा संभालने में मदद करता है; यह सुरक्षा सीमा नहीं है। अनुमतियां और branch प्रतिबंध prompt के बाहर लागू करें।

मंज़ूर किए गए बदलाव का सत्यापन करें

write सेवा के commit ID लौटाने के बाद ही test runner चलाएं। runner को latest branch head के बजाय उसी ID को check out करने और आपकी टीम द्वारा तय allowlist में शामिल command चलाने के लिए कॉन्फ़िगर करें। जिस रिपॉज़िटरी के maintainers ने इसे चुना हो, उसके लिए एक उदाहरण command यह हो सकती है:

npm test

यह command केवल उदाहरण है; प्रोजेक्ट के वास्तविक टेस्ट निर्देशों का इस्तेमाल करें। रिपॉज़िटरी कोड, dependency installation scripts और test output को अविश्वसनीय मानें। इन्हें सीमित network और filesystem पहुंच, बिना production secrets तथा समय और संसाधन सीमाओं के साथ चलाएं। टेस्ट सूट का पास होना सिर्फ यह दिखाता है कि चुनी गई जांचें उस वातावरण में पास हुईं; इससे यह साबित नहीं होता कि बदलाव सुरक्षित या सही है।

संक्षिप्त नतीजे में मंज़ूर base, नया commit, test command, pass/fail status और logs का लिंक लौटाएं। टेस्ट विफल होने पर एजेंट संशोधित patch का प्रस्ताव दे सकता है, लेकिन दोबारा write के लिए अलग मंज़ूरी ज़रूरी है। समीक्षक द्वारा पहले tool call को मंज़ूरी देने के कारण अपने आप merge न करें।

समस्या निवारण और संचालन की सीमाएं

मंज़ूरी अनुरोध में उपयोगी संदर्भ नहीं है

जांचें कि कौन से inputs AI द्वारा दिए गए हैं और $tool.parameters में दिखाई देते हैं। patch की पहचान, branch और base revision को समीक्षा योग्य tool input में रखें या समीक्षा के लिए सुरक्षित, अपरिवर्तनीय artifact दें। अगर समीक्षक सटीक write की पहचान नहीं कर सकता, तो उसे अस्वीकार करें।

एजेंट टूल को call नहीं कर पा रहा है

पहले रिपॉज़िटरी अनुमतियों से अलग कोई नुकसान न पहुंचाने वाला टूल जांचें। n8n node, OneMux endpoint, चुने हुए मॉडल और आवश्यक tool-call parameters को उनके मौजूदा दस्तावेज़ों से मिलाकर जांचें। दिए गए स्रोत किसी खास मॉडल-node संयोजन को सत्यापित नहीं करते।

branch बदल गई या टेस्ट पूरे नहीं हुए

किसी अलग base पर patch लागू करने के बजाय पुराने आधार वाले write को अस्वीकार करें। timeout, runner error या log न मिलने पर सत्यापन को अधूरा रिपोर्ट करें। जहां उचित हो, उसी commit पर दोबारा टेस्ट चलाएं; अगर प्रस्तावित write बदलती है, तो नई मंज़ूरी मांगें।

निष्कर्ष

उपयोगी सीमा स्पष्ट है: एक व्यक्ति किसी खास रिपॉज़िटरी write को मंज़ूरी देता है और अलग-थलग runner बने हुए commit को सत्यापित करता है। n8n दस्तावेज़ में वर्णित टूल-स्तरीय विराम और मंज़ूरी प्रक्रिया देता है; बाकी सुरक्षा उपाय आपकी रिपॉज़िटरी सेवा, runner, अनुमतियां और समीक्षा प्रक्रिया प्रदान करते हैं। OneMux को मॉडल एक्सेस की परत के रूप में तभी इस्तेमाल करें जब पुष्टि कर लें कि चुना हुआ endpoint और parameters आपकी n8n कॉन्फ़िगरेशन के साथ काम करते हैं।

स्रोत

• n8n: Human-in-the-loop for tools — टूल मंज़ूरी का व्यवहार, सेटअप, समीक्षा चैनल और समीक्षा संदेश के variables।
• OneMux documentation — मौजूदा API कनेक्शन विवरण के लिए देखें।