2026 में ओपनएआई एजेंट्स एपीआई: लॉन्च से पहले किसी एजेंट का मूल्यांकन कैसे करें

एक लॉन्च की शुरुआत स्कोप से होती है

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

पथ का परीक्षण करें, केवल उत्तर का नहीं

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

अनुमतियाँ और पुष्टि अवश्य दिखनी चाहिए

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

लागत सीमा और वसूली गुणवत्ता का हिस्सा हैं

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

रिहाई के बाद मूल्यांकन बनाए रखें

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

टूल वाले एजेंट के लिए एक लॉन्च गेट

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

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

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

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

विफलता के मामले ग्राहकों के सामने परीक्षण के लायक हैं

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

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

मालिक के लिए एक रिलीज़ प्रश्न

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