कोडिंग और अन्य कार्यों में सबसे अधिक उत्पादक होने के लिए, एजेंट्स को स्वायत्तता का एक संतुलित स्तर चाहिए। इसका मतलब है कि वे स्वतंत्र रूप से काम कर सकें, रचनात्मक हों, और बार-बार अनुमति माँगने के लिए रुके बिना काम पूरा कर सकें।

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

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

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

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

#संदर्भ में जोखिम का आकलन

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

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

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

#क्लासिफ़ायर का निर्माण

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

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

हमने क्लासिफ़ायर को एजेंटिक भी बनाया, क्योंकि कुछ कार्रवाइयों का आकलन सिर्फ़ कमांड से नहीं किया जा सकता। python script.py जैसी कमांड सुरक्षित भी हो सकती है और असुरक्षित भी—यह इस पर निर्भर करता है कि फ़ाइल के अंदर क्या है। इसलिए क्लासिफ़ायर फ़ैसला लेने से पहले ReadFile, Grep, Glob, और ListDir जैसे टूल्स की मदद से कार्यस्थान की जाँच कर सकता है।

हमने अलग classification endpoint का उपयोग नहीं किया, क्योंकि हर समीक्षित टूल कॉल से ठीक पहले एक अतिरिक्त round trip सीधे लेटेंसी बढ़ा देती। इसके बजाय, क्लासिफ़ायर पैरेंट एजेंट की उसी RPC stream में चलता है और उप-एजेंट जैसी आर्किटेक्चर का उपयोग करता है।

#फ़ीडबैक लूप का डिज़ाइन

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

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

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

#क्लासिफ़ायर की टेस्टिंग

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

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

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

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

हमने flapping भी खोजी। अगर वही मामला छह बार allow हुआ और चार बार block, तो आम तौर पर इसका मतलब था कि नीति या प्रॉम्प्ट पर्याप्त स्पष्ट नहीं था। बार-बार के रन ने हमें ऐसे अस्थिर मामलों को खोजने का तरीका दिया और क्लासिफ़ायर को तब तक और सख्त किया, जब तक उसका व्यवहार अधिक सुसंगत नहीं हो गया।

#सीधे ब्लॉक को न्यूनतम रखना

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

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

क्लासिफ़ायर के कुछ ब्लॉक उपयोगकर्ता के लिए रुकावट बन जाते हैं, लेकिन कुल मिलाकर हम देख रहे हैं कि ऑटो-रिव्यू मोड में कुल चैट्स में से केवल लगभग 7% में ही कम-से-कम एक रुकावट आती है। तुलना के लिए, जिन कुछ Enterprise ग्राहकों के साथ हम काम कर रहे हैं, उन्होंने पहले अपने organization के भीतर लगभग 40% कार्रवाइयों के ब्लॉक होने का अनुभव किया था।

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

#एजेंट स्वायत्तता को बेहतर बनाना

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

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

ऑटो-रिव्यू अब नए उपयोगकर्ताओं के लिए डिफ़ॉल्ट है। मौजूदा उपयोगकर्ताओं के लिए, आप इसे Settings > Agents में सक्षम कर सकते हैं।