एक एजेंट एक रिपोर्ट लिखता है, एक फ़ाइल बनाता है और फिर एक संदेश भेजता है। तभी प्रक्रिया बीच में रुक जाती है। दोबारा शुरू होने पर चैट कहती है: “मैं अब परिणाम भेज रहा हूँ।” क्या संदेश जा चुका है? क्या फ़ाइल फिर से बनानी होगी? एक सहज बातचीत का इतिहास इन प्रश्नों का उत्तर नहीं देता।
19 अक्टूबर 2026 को Vercel ने durable-harness प्रकाशित किया। यह प्रोजेक्ट एजेंट के चरणों और परिणामों को दर्ज करता है ताकि काम फिर से शुरू किया जा सके, और बाधित टूल्स के साथ उनकी रीप्ले विशेषता के आधार पर अलग-अलग व्यवहार करता है। यह रिलीज़ काम की स्थिति पर अधिक ध्यान से विचार करने का अवसर है। इस लेख का उदाहरण हमारा अपना मॉडल है, न कि कोई परीक्षण जो हमने इस प्रोजेक्ट पर चलाया हो।
इरादा, कॉल और परिणाम तीन अलग-अलग चीज़ें हैं
इरादा बताता है कि आगे क्या होना है। शुरू की गई कॉल दिखाती है कि काम आरंभ हो चुका है। केवल सहेजा गया परिणाम ही यह दर्ज करता है कि आपकी अपनी प्रक्रिया उसके बारे में क्या जानती है। यदि इन स्तरों को आपस में मिला दिया जाए, तो रीस्टार्ट आसानी से दोहरा काम पैदा कर सकता है या किसी ऐसी चीज़ को छोड़ सकता है जो कभी पूरी ही नहीं हुई।
इसलिए रिपोर्ट के लिए “एक्सपोर्ट पूरा” जैसी प्रविष्टि पर्याप्त नहीं है। इसमें उपयोग किए गए इनपुट और वास्तव में बनाई गई फ़ाइल का संदर्भ होना चाहिए। यदि स्रोत दस्तावेज़ बदल जाता है, तो पहले का एक्सपोर्ट अब भी मौजूद हो सकता है, लेकिन वह अब सही परिणाम नहीं रहता। पुनः उपयोग स्पष्ट संबद्धता से शुरू होता है।
Step: export-17
Input: bericht-v3
State: completed
Result: bericht-v3.pdf
Next step: notificationयह एक पढ़ने योग्य नियंत्रण कार्ड है, कोई API फ़ॉर्मेट नहीं। यह बातचीत में उल्लिखित किसी फ़ाइल नाम और किसी विशिष्ट चरण के पता लगाए जा सकने वाले परिणाम के बीच का मूल अंतर दिखाता है। किसी वास्तविक प्रक्रिया में, संबंधित फ़ाइल का अस्तित्व सत्यापन योग्य तरीके से होना चाहिए।
एक सुरक्षित रीस्टार्ट अस्पष्ट स्थितियों को पहचानता है
तीन ऐसे बिंदुओं पर विचार कीजिए जहाँ प्रक्रिया रुक सकती है। एक्सपोर्ट से पहले, अभी कोई परिणाम नहीं है। एक्सपोर्ट के बाद लेकिन संदेश से पहले, फ़ाइल का फिर से उपयोग किया जा सकता है। संदेश भेजे जाने के दौरान स्थिति अधिक कठिन होती है: हो सकता है कि प्राप्तकर्ता को वह पहले ही मिल चुका हो, जबकि आपके अपने लॉग में पुष्टि मौजूद न हो।
इसलिए स्थानीय स्थिति “कोई पुष्टि सहेजी नहीं गई” यह सिद्ध नहीं करती कि “भेजा नहीं गया”। इस चरण को बिना सोचे दोहराने से यह अनिश्चितता एक दोहरे संदेश में बदल सकती है। एक समझदार प्रक्रिया इस चरण को अस्पष्ट के रूप में चिह्नित करती है और बाहरी सेवा से जाँच करती है, बशर्ते वह सेवा उपयुक्त स्थिति-पूछताछ की सुविधा देती हो।
ठीक यहीं पर क्रियाएँ एक-दूसरे से भिन्न होती हैं। किसी मौजूदा फ़ाइल को फिर से पढ़ने से आमतौर पर प्राप्तकर्ता के लिए कुछ नहीं बदलता। इसके विपरीत, एक और संदेश, ऑर्डर या भुगतान एक नया प्रभाव पैदा कर सकता है। एक टिकाऊ लॉग बाहरी सिस्टम की ओर से इन अंतरों को हल नहीं करता।
आइडेम्पोटेंसी ऑपरेशन की एक विशेषता है
एक दोहराए जा सकने वाले ऑपरेशन की पहचान इस तरह होनी चाहिए कि वही अनुरोध गलती से कोई नया काम न बना दे। यदि कोई सेवा इस उद्देश्य के लिए बनी कुंजी का समर्थन करती है, तो उसी तार्किक ऑपरेशन के लिए वही कुंजी बनी रहनी चाहिए। हर रीस्टार्ट पर नए सिरे से बनाई गई कुंजी ठीक यही संबंध खो देगी।
यह भरोसेमंद ढंग से काम करता है या नहीं, और कैसे, यह वास्तविक सेवा अनुबंध पर निर्भर करता है। कोई एजेंट फ़्रेमवर्क किसी क्रिया को केवल एक अच्छा-सा लेबल देकर सुरक्षित रूप से दोहराने योग्य नहीं बना सकता। न ही “ठीक एक बार” लॉग के टिकाऊ रूप से सहेजे जाने का कोई मुफ़्त परिणाम है।
एक छोटा अबॉर्ट परीक्षण एक सफल रन से अधिक समझाता है
अपने स्वयं के डेवलपमेंट वातावरण में एक हानिरहित अभ्यास सुझाया जा सकता है: पहले भेजने वाले चरण को एक स्थानीय लॉग से बदल दीजिए, उल्लिखित तीन बिंदुओं पर प्रक्रिया को बाधित कीजिए और देखिए कि रीस्टार्ट पर कौन-सी स्थितियाँ मौजूद हैं। पहले से नोट कर लीजिए कि कौन-से चरण दोहराए जा सकते हैं और किनकी जाँच आवश्यक है। इस पहली जाँच के लिए वास्तविक भुगतानों या संदेशों का उपयोग न करें।
यह अंतर्दृष्टि किसी गढ़ी गई सफलता दर में नहीं है। यह अपनी प्रक्रिया में स्थिति की सीमाओं को नाम दे पाने में है। Durable-harness इसके लिए एक ठोस तकनीकी दृष्टिकोण है। फिर भी, एक अच्छा रीस्टार्ट हमेशा उसी प्रश्न से शुरू होता है: क्या प्रमाणित रूप से हो चुका है, और कहाँ हमें अभी तक पता नहीं है?
स्रोत और स्थिति
25 अक्टूबर 2026 तक का शोध और दस्तावेज़ीकरण। हर हार्नेस को टिकाऊ बनाना।
