Assistants, agents और permissions

पहचानें कि system कैसे काम करता है

Assistant code समझा सकता है, योजना दे सकता है या implementation सुझा सकता है। Agent tools का उपयोग करके environment में कार्रवाई भी कर सकता है। Product के नाम भरोसेमंद सीमा नहीं बताते। कुछ chat interfaces commands execute कर सकते हैं। कुछ coding tools केवल text सुझाते हैं।

उपलब्ध tools का निरीक्षण करें। उपयोगी विवरण बताता है कि system क्या पढ़, बदल, execute और publish कर सकता है। यह विवरण हर कार्रवाई में इस्तेमाल होने वाले credentials और environment भी बताता है।

Anthropic पहले से तय workflows और tools इस्तेमाल करने का क्रम स्वयं चुनने वाले agents में अंतर करता है। इस अंतर से समझ आता है कि काम कैसे आगे बढ़ता है। इससे यह तय नहीं होता कि कोई कार्रवाई सुरक्षित है या नहीं। दोनों designs को स्पष्ट permission सीमा चाहिए।

लक्ष्य और अनुमति को अलग रखें

एक काल्पनिक अनुरोध लें: “Invoice export ठीक करें।” Agent repository देख सकता है, दोष दोबारा पैदा कर सकता है, branch edit कर सकता है और checks चला सकता है। उसे अपने environment में production database के credentials भी मिल सकते हैं।

लक्ष्य हर उपलब्ध कार्रवाई की अनुमति नहीं देता। Production table पढ़ने, invoice records बदलने और नया version deploy करने के अलग-अलग परिणाम होते हैं। “काम पूरा करें” जैसा व्यापक instruction यह नहीं बताता कि इनमें से किन कार्रवाइयों की संगठन अनुमति देता है।

काम शुरू होने से पहले सीमा तय करें। इस उदाहरण में agent मनगढ़ंत डेटा और local database का उपयोग कर सकता है। वह pull request बना सकता है। वह production records access नहीं कर सकता और बदलाव deploy नहीं कर सकता। इन कार्रवाइयों के लिए अलग release प्रक्रिया है।

अधिकार लागू करने के लिए technical controls इस्तेमाल करें

Instructions से agent को काम समझने में मदद मिलती है। Credentials और access controls तय करते हैं कि agent वास्तव में क्या कर सकता है। दोनों का उपयोग करें।

केवल सुविधा के लिए read-only काम को write credentials नहीं देने चाहिए। Test environment को चुपचाप production access नहीं मिलना चाहिए। Tools, identities और resources के बीच connections का review करें। शक्तिशाली identity इस्तेमाल करने पर मामूली दिखने वाली command का बड़ा असर हो सकता है।

तय करें कि काम कब रुकना चाहिए

अगली कार्रवाई अधिकार से बाहर होने पर agent के लिए रुकने की शर्त चाहिए। प्रमाण पर्याप्त न होने पर भी ऐसी शर्त चाहिए।

Invoice वाले उदाहरण में, दोष ठीक करने के लिए production data बदलना पड़े तो रुकें। माँगा गया व्यवहार दर्ज accounting rule से टकराए तो रुकें। संबंधित प्रमाण और जिम्मेदार व्यक्ति से जरूरी निर्णय के साथ टकराव बताएँ।

बार-बार प्रयास के लिए समय या लागत की सीमा उपयोगी है। यह permission सीमा की जगह नहीं लेती। दस अधिकृत प्रयास और एक अनधिकृत deployment अलग समस्याएँ हैं।

परिणाम और कार्रवाइयों के record का मूल्यांकन करें

काम पूरा होने पर केवल अंतिम उत्तर न देखें। बदली हुई files, की गई checks और बची हुई अनिश्चितता का review करें। जाँचें कि कार्रवाइयाँ तय दायरे के भीतर रहीं।

सक्षम agent हाथ से किए जाने वाले काम को कम कर सकता है। फिर भी संगठन को स्वीकार्य कार्रवाइयाँ तय करनी हैं, महत्वपूर्ण परिणाम जाँचने हैं और release के निर्णय की जिम्मेदारी लेनी है। अधिक autonomy से इन जिम्मेदारियों का महत्व बढ़ता है।