कैसे जाँचें कि AI एजेंट ने काम सच में पूरा किया

आपने Claude Code, Codex या किसी दूसरे एजेंट से फ़ाइलें व्यवस्थित करने, स्प्रेडशीट अपडेट करने या व्यावसायिक रिकॉर्ड बनाने को कहा। उसने “पूरा हुआ” लिखा और कोई साफ़ त्रुटि नहीं दिखी। इससे केवल इतना पता चलता है कि रन बिना स्पष्ट रुकावट के समाप्त हुआ; यह प्रमाण नहीं है कि अपेक्षित व्यावसायिक परिणाम वास्तव में बन गया।

विश्वसनीय स्वीकृति प्रक्रिया अपेक्षित अंतिम स्थिति से शुरू होती है, गंतव्य सिस्टम से वास्तविक परिणाम दोबारा पढ़ती है, और छूटे हुए तथा अनपेक्षित दोनों प्रभावों की जाँच करती है। इसके बाद ही कार्य को पूरा मानें। परिणाम अज्ञात हो तो पूरा वर्कफ़्लो फिर चलाने के बजाय पहले पूछताछ करें।

सफल टूल कॉल का अर्थ कार्य पूरा होना क्यों नहीं है

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

• क्या सही फ़ाइल सही स्थान पर सही सामग्री के साथ लिखी गई?
• क्या स्प्रेडशीट या डेटाबेस ने हर अपेक्षित रिकॉर्ड स्थायी रूप से सहेजा?
• क्या डुप्लिकेट पंक्तियाँ, डुप्लिकेट ऑर्डर, अतिरिक्त सूचनाएँ या अनचाही फ़ाइलें बनीं?
• क्या कोई असिंक्रोनस जॉब अब भी कतार में है, या बाद में लिखाई वापस रोल बैक हो गई?
• क्या एजेंट ने रिकॉर्ड केवल पढ़ा, जबकि आवश्यक अपडेट छोड़ दिया?

Microsoft का सार्वजनिक ThinkingBox-Bench v1.0 एक कृत्रिम शोध बेंचमार्क है, उत्पादन घटनाओं की दर नहीं। इसमें पाँच व्यावसायिक डोमेन के 507 निष्पादन योग्य कार्य हैं और कोई प्रयास तभी स्वीकार होता है जब अंतिम स्थिति, दुष्प्रभाव और निर्दिष्ट संवाद गुणों पर सभी जाँचें पास हों। टैग किए गए दस्तावेज़ में आंशिक अंक नहीं हैं। नीचे दिए गए “आंशिक” और “असत्यापित” शब्द आपके संचालन की स्वीकृति स्थितियाँ हैं, बेंचमार्क स्कोर नहीं।

रन से पहले स्वीकृति अनुबंध तय करें

किसी कार्य को जल्दी सत्यापित करने का सर्वोत्तम तरीका है कि एजेंट शुरू होने से पहले उसकी अंतिम शर्तें लिख दी जाएँ। कम से कम चार बातें दर्ज करें:

मद	क्या परिभाषित करें	उदाहरण
आवश्यक स्थिति	कौन-सी वस्तुएँ, फ़ील्ड, गिनती और संबंध मौजूद होने चाहिए	120 फ़ाइलों का नाम बदला; शीट में 120 अद्वितीय ID जोड़े
निषिद्ध स्थिति	कौन-से बदलाव या दुष्प्रभाव नहीं होने चाहिए	स्रोत फ़ाइलें न मिटें; दूसरा ईमेल न जाए; दूसरी टैब न बदले
सत्य का स्रोत	किस सिस्टम की संग्रहीत स्थिति अंतिम निर्णय करेगी	गंतव्य फ़ोल्डर, वास्तविक शीट सेल, CRM रिकॉर्ड, टिकट स्थिति
रीट्राई पहचान	इसी व्यावसायिक ऑपरेशन को पहचानने वाली कुंजी	वर्तमान टास्क/ऑपरेशन के दायरे का operation_id या ऑर्डर नंबर; ग्राहक ID, फ़ाइल नाम, ऑब्जेक्ट ID और मैनिफ़ेस्ट हैश केवल क्वेरी लक्ष्य पहचानते हैं, इस ऑपरेशन को अकेले नहीं

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

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

पर्याप्त निष्पादन प्रमाण बचाएँ

इतना न्यूनतम प्रमाण रखें जिससे एक रन को उसकी लिखाइयों से जोड़ा जा सके:

• मूल कार्य, अनुमत दायरा और अपेक्षित अंतिम स्थिति;
• शुरू और खत्म होने का समय, कार्य निर्देशिका और लक्ष्य मैनिफ़ेस्ट;
• एजेंट सेशन ID और लौटाया गया कोई जॉब ID;
• operation_id या कोई दूसरा अद्वितीय व्यावसायिक कुंजी;
• रन से पहले की गिनती, मुख्य फ़ील्ड, संस्करण या हैश;
• स्पष्ट त्रुटियाँ, टाइमआउट, अनुमति अस्वीकृति और छोड़े गए चरण।

परिणाम स्वीकार करने के लिए एजेंट की निजी सोच की आवश्यकता नहीं है। पुनरुत्पाद्य इनपुट, पहचान, दायरा और गंतव्य स्थिति चाहिए। संवेदनशील फ़ील्ड छिपाएँ और स्वीकृति लॉग में कभी API key, access token या ग्राहक रहस्य न रखें।

एजेंट के अंतिम संदेश नहीं, सिस्टम की अंतिम स्थिति का इंतज़ार करें

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

पोलिंग के दौरान अंतिम अपडेट समय और प्रगति दर्ज करें। यदि गंतव्य में eventual consistency है, तो पहले से तय settling window दें और फिर दोबारा पढ़ें। अभी-अभी सबमिट रिकॉर्ड तुरंत न दिखे तो उसे विफल न घोषित करें, लेकिन अनंत समय तक भी न प्रतीक्षा करें। तय सीमा के बाद भी निर्णायक प्रमाण न मिले तो सही स्थिति असत्यापित है, “निष्पादित नहीं हुआ” नहीं।

छह प्रमाण स्तरों से परिणाम दोबारा पढ़ें

1. पुष्टि करें कि लक्ष्य वस्तु मौजूद है और इसी रन की है

पाथ, फ़ाइल नाम, रिकॉर्ड ID, संशोधन समय और संस्करण देखें। उसी नाम की पुरानी फ़ाइल प्रमाण नहीं है। गलत ग्राहक से जुड़ा नया रिकॉर्ड भी मान्य परिणाम नहीं है।

2. सामग्री और व्यावसायिक invariants जाँचें

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

3. आधिकारिक सिस्टम ऑफ़ रिकॉर्ड का उपयोग करें

एजेंट का सारांश, टर्मिनल आउटपुट और स्थानीय कैश केवल सहायक प्रमाण हैं। स्वीकृति उस सिस्टम से आनी चाहिए जो परिणाम संग्रहीत करता है: फ़ाइल सेवा, वास्तविक स्प्रेडशीट सेल, CRM, टिकट सिस्टम, डेटाबेस या भुगतान लेजर।

4. हर आवश्यक दुष्प्रभाव सत्यापित करें

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

5. ऐसे प्रभाव खोजें जो नहीं होने चाहिए थे

स्वीकृति केवल अपेक्षित चीज़ खोजने का नाम नहीं है। डुप्लिकेट पंक्तियाँ, डुप्लिकेट रिकॉर्ड, अतिरिक्त ईमेल, मिटाई गई फ़ाइलें, दायरे से बाहर बदलाव और गलत वस्तु पर लिखाई खोजें। अनपेक्षित प्रभाव को अलग अलर्ट मानें, क्योंकि अगला रीट्राई उसे और बढ़ा सकता है।

6. सिस्टमों के बीच मिलान करें

जब कार्य फ़ाइल, शीट और व्यावसायिक एप्लिकेशन तक फैला हो, हर क्वेरी को पहले वर्तमान operation_id या टास्क के दायरे से बाँधें, फिर ग्राहक/ऑब्जेक्ट ID, अपेक्षित स्थिति या संस्करण और मैनिफ़ेस्ट जाँचें। केवल ऑब्जेक्ट पहचान मिलना यह सिद्ध नहीं करता कि यही ऑपरेशन लागू हुआ। स्पष्ट ID सेटों की तुलना करें और छूटी तथा अतिरिक्त वस्तुओं की सूची बनाएँ।

परिणाम को चार संचालन स्थितियों में वर्गीकृत करें

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

असत्यापित का अर्थ विफल नहीं है। इसका अर्थ है कि अभी पता नहीं है। यही अंतर तय करता है कि अगला कदम एक और क्वेरी होगी या एक और लिखाई।

इस क्रम में तय करें कि रीट्राई करना है या नहीं

1. पहले इसी ऑपरेशन को खोजें। सिस्टम ऑफ़ रिकॉर्ड की क्वेरी को operation_id या ऑर्डर नंबर से वर्तमान टास्क तक सीमित करें, फिर फ़ाइल नाम, ग्राहक/ऑब्जेक्ट ID और अपेक्षित स्थिति या संस्करण जोड़ें। केवल ऑब्जेक्ट मिलना इस लिखाई का प्रमाण नहीं है।
2. पूर्ण सीमा पहचानें। पूरे वर्कफ़्लो को एक अपारदर्शी सफलता या विफलता न मानें; सफल और गायब वस्तुओं की अलग सूची बनाएँ।
3. Idempotent तरीके से सुधारें। यदि सिस्टम गारंटी देता है कि समान कुंजी दूसरा व्यावसायिक परिणाम नहीं बना सकती, तो केवल गायब वस्तुएँ सबमिट करें। Idempotency अज्ञात हो तो अपरिवर्तनीय कार्रवाई स्वतः फिर न चलाएँ।
4. रिकॉर्ड, सूचनाएँ और लेनदेन अलग करें। रिकॉर्ड मौजूद है पर ईमेल विफल हुआ तो केवल ईमेल फिर भेजें। ईमेल जा चुका है और रिकॉर्ड की स्थिति अस्पष्ट है तो पहले रिकॉर्ड पूछें।
5. अनपेक्षित प्रभाव पर रुकें। गलत वस्तुओं को वापस लें या सुधारें; उसके बाद मानव तय करे कि ऑटोमेशन फिर शुरू हो सकता है या नहीं।

संक्षिप्त नियम: अनुपस्थिति की पुष्टि होने पर ही रीट्राई करें; आंशिक लिखाई के बाद केवल गायब भाग सुधारें; परिणाम अज्ञात हो तो कार्रवाई से पहले क्वेरी करें; और सिस्टम में गलत परिणाम हो तो रुकें।

उदाहरण: फ़ाइलें, एक शीट और CRM रिकॉर्ड

यह एक काल्पनिक उदाहरण है, ग्राहक घटना या पुनरुत्पादित उत्पादन लॉग नहीं।

एक एजेंट को 120 फ़ाइलों के नाम बदलने, ट्रैकिंग शीट में 120 पंक्तियाँ लिखने, CRM में 12 सारांश रिकॉर्ड बनाने और फिर एक completion email भेजने हैं। दोबारा पढ़ने पर सभी फ़ाइलें और पंक्तियाँ सही मिलती हैं, CRM में केवल 9 रिकॉर्ड हैं और ईमेल पहले ही भेजा जा चुका है।

सही स्थिति आंशिक है—न पूर्ण, न पूरी तरह विफल। सुरक्षित पुनर्प्राप्ति इस प्रकार होगी:

• CRM को operation_id और अपेक्षित 12 व्यावसायिक कुंजियों से क्वेरी करें;
• मौजूद 9 रिकॉर्ड पहचानें और deduplication keys के साथ केवल गायब 3 बनाएँ;
• अंतिम 12 CRM ID को फ़ाइल और शीट सारांश से मिलाएँ;
• फ़ाइलों के नाम फिर न बदलें, 120 पंक्तियाँ फिर न लिखें और ईमेल फिर न भेजें।

यदि CRM को क्वेरी नहीं किया जा सकता, परिणाम असत्यापित रखें। उस समय पूरा रन दोबारा चलाने से डुप्लिकेट रिकॉर्ड और दूसरी सूचना बन सकती है।

यह स्वीकृति रिकॉर्ड कॉपी करें

फ़ील्ड	क्या दर्ज करें
कार्य और दायरा	अपेक्षित कार्रवाई, अनुमत गंतव्य और निषिद्ध बदलाव
अपेक्षित अंतिम स्थिति	वस्तुएँ, फ़ील्ड, गिनती, संबंध और अंतिम स्थितियाँ
निष्पादन पहचान	सेशन ID, जॉब ID, operation_id और व्यावसायिक कुंजियाँ
आधिकारिक प्रमाण	गंतव्य वस्तुएँ, क्वेरी समय, ID और लिंक
गायब प्रभाव	अनुपस्थित अनिवार्य वस्तुएँ या कार्रवाइयाँ
अतिरिक्त प्रभाव	डुप्लिकेट, deletion, दायरे से बाहर लिखाई या अतिरिक्त सूचनाएँ
स्वीकृति स्थिति	पूर्ण, आंशिक, असत्यापित या अनपेक्षित दुष्प्रभाव
अगला कदम	बंद करें, प्रतीक्षा करें, सुधारें, रीट्राई करें, रोल बैक करें या मानव को सौंपें

रिकॉर्ड को स्वयं ऑडिट योग्य बनाएँ। केवल “जाँच लिया” लिखने के बजाय ID सूची, diff और क्वेरी टाइमस्टैम्प जोड़ें।

BetterToken मॉडल कनेक्शन दे सकता है, परिणाम की स्वीकृति नहीं

Claude Code को BetterToken से जोड़ते समय वर्तमान Claude Code सेटअप और कनेक्शन जाँच गाइड का पालन करें। कनेक्शन या मॉडल त्रुटि के बिना सामान्य मॉडल उत्तर यह पुष्टि करता है कि कनेक्शन कॉन्फ़िगरेशन काम कर रहा है; इससे यह प्रमाणित नहीं होता कि फ़ाइल, स्प्रेडशीट या तीसरे पक्ष का व्यावसायिक रिकॉर्ड अपेक्षित अंतिम स्थिति तक पहुँच गया।

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

कार्य बंद करने से पहले तीन अंतिम प्रश्न

“पूरा हुआ” स्वीकार करने से पहले पूछें:

1. क्या अपेक्षित अंतिम स्थिति आधिकारिक सिस्टम में दिखाई देती है, न कि केवल एजेंट के वर्णन में?
2. क्या मैंने गायब परिणाम, डुप्लिकेट लिखाई और अन्य अनपेक्षित दुष्प्रभाव जाँचे?
3. यदि परिणाम अज्ञात है, तो सुधार या रीट्राई तय करने से पहले क्या मैं किसी अद्वितीय व्यावसायिक कुंजी से क्वेरी कर सकता हूँ?

तीनों उत्तर स्पष्ट हों तभी कार्य बंद करें। अगले उच्च-प्रभाव एजेंट रन से पहले ऊपर का स्वीकृति रिकॉर्ड कॉपी करें और अंतिम स्थिति, निषिद्ध स्थिति तथा रीट्राई पहचान भरें। इतनी छोटी तैयारी अक्सर बाद में डुप्लिकेट सबमिशन सुलझाने से सस्ती होती है।