प्रॉम्प्ट और लागू संदर्भ
आप एक एंटरप्राइज एजेंट प्लेटफॉर्म के स्वामी हैं। यह एजेंट MCP के माध्यम से टिकटिंग, सोर्स-कंट्रोल और फाइनेंस सिस्टम को कॉल कर सकता है। कुछ टूल केवल पढ़ने के लिए (read-only) हैं; अन्य कोड डिप्लॉय करते हैं, रिफंड जारी करते हैं, या डेटा हटाते हैं। सर्वर समय के साथ बदल सकते हैं, और टूल विवरण या परिणाम उन सर्वरों से आ सकते हैं जो पूरी तरह से विश्वसनीय नहीं हैं। डिस्कवरी, ऑथराइजेशन, इनवोकेशन, परिणाम प्रबंधन, ऑडिटिंग और रिकवरी डिज़ाइन करें। बताएं कि किन ऑपरेशनों के लिए मानवीय अनुमोदन की आवश्यकता है।
मुख्य प्रश्न यह है कि क्या प्रत्येक कॉल के पास चार प्रश्नों का स्पष्ट उत्तर है: कौन किसके लिए और किस दायरे में कार्य कर रहा है, किस टूल संस्करण का उपयोग किया गया था, क्या इनपुट और परिणामों को मान्य किया गया था, और क्या किसी विफलता को ट्रैक और वापस (reverse) किया जा सकता है। Amazon का SDE II दिशानिर्देश सिस्टम डिज़ाइन में विश्वसनीयता, स्केलेबिलिटी, सुरक्षा और ट्रेड-ऑफ का स्पष्ट रूप से मूल्यांकन करता है, जिससे यह एक उपयुक्त एंड-टू-एंड डिज़ाइन अभ्यास बन जाता है।
इंटरव्यूअर क्या मूल्यांकन करता है
एक मजबूत उत्तर मॉडल द्वारा कॉल प्रस्तावित करने की क्षमता को प्लेटफॉर्म द्वारा इसे निष्पादित करने के अधिकार से अलग करता है। मॉडल एक टूल और तर्कों (arguments) का सुझाव दे सकता है; एक पॉलिसी इंजन को उपयोगकर्ता, किरायेदार (tenant), संसाधन, जोखिम स्तर और अनुमोदन स्थिति का उपयोग करके फिर से अधिकृत करना चाहिए।
आपको MCP की सीमा को भी पहचानना चाहिए। सर्वर द्वारा प्रदान किए गए टूल एनोटेशन को अविश्वसनीय माना जाना चाहिए; readOnlyHint कोई ऑथराइजेशन तथ्य नहीं है। परिणामों में संरचित डेटा, टेक्स्ट, संसाधन लिंक या एम्बेडेड संसाधन हो सकते हैं। NSA के दिशानिर्देश डायनामिक इनवोकेशन, अंतर्निहित विश्वास और संदर्भ साझाकरण को सिस्टमिक जोखिमों के रूप में उजागर करते हैं।
इंटरव्यूअर विफलता के रास्तों की जांच करेगा: एक विषाक्त (poisoned) कैटलॉग, एक क्रॉस-टेनेंट तर्क जो स्कीमा सत्यापन पास करता है, अनुमोदन के बाद बदले गए पैरामीटर, टाइमआउट, बार-बार होने वाले साइड इफेक्ट्स, और एक अनुपलब्ध ऑडिट पाइपलाइन।
स्पष्टीकरण वाले प्रश्न
पहले साइड इफेक्ट्स के बारे में पूछें। क्या प्रश्नों (queries), राइट्स (writes), डिप्लॉयमेंट और विलोपन (deletions) को जोखिम के आधार पर रैंक किया जा सकता है? यदि प्रत्येक टूल केवल-पढ़ने के लिए है, तो अनुमोदन और रिकवरी सरल हो सकती है; धन हस्तांतरण, प्रोडक्शन परिवर्तन और व्यक्तिगत डेटा के लिए मजबूत नियंत्रण की आवश्यकता होती है।
फिर ट्रस्ट सीमाओं के बारे में पूछें। क्या सर्वर कंपनी द्वारा प्रबंधित हैं, थर्ड-पार्टी द्वारा होस्ट किए गए हैं, या उपयोगकर्ता द्वारा प्रदान किए गए हैं? यदि प्लेटफॉर्म सर्वर को नियंत्रित नहीं करता है, तो उसके विवरण, एनोटेशन, परिणाम टेक्स्ट और संसाधन URIs इनपुट डेटा हैं, पॉलिसी नहीं।
अंत में अनुपालन और रिकवरी उद्देश्यों के बारे में पूछें। किन प्रिंसिपलों, टेनेंट्स और डेटा श्रेणियों को रिकॉर्ड किया जाना चाहिए? क्या रोलबैक एक क्षतिपूर्ति लेनदेन (compensating transaction), एक विपरीत ऑपरेशन, या एक मैन्युअल प्रक्रिया है? वे उत्तर डेटा प्रतिधारण, क्रेडेंशियल स्कोप और वर्कफ़्लो डिज़ाइन को बदलते हैं।
30-सेकंड उत्तर ढांचा
आप कह सकते हैं:
"मैं मॉडल को एक अविश्वसनीय प्रस्तावक मानूंगा और निष्पादन को एक पॉलिसी इंजन और एक पृथक (isolated) रनर के पीछे रखूंगा। प्लेटफॉर्म प्रत्येक टूल को पंजीकृत और वर्शन करता है, उपयोगकर्ता, टेनेंट, संसाधन और साइड इफेक्ट के आधार पर न्यूनतम विशेषाधिकार लागू करता है, और डिप्लॉयमेंट, रिफंड और विलोपन जैसे उच्च जोखिम वाले कार्यों को सटीक पैरामीटर के अनुमोदन से बांधता है। केवल-पढ़ने वाले कॉल अभी भी इनपुट और परिणामों को मान्य करते हैं। निष्पादन से पहले और बाद में, हम सहसंबंधित ऑडिट ईवेंट लिखते हैं; परिणाम अगली कॉल के लिए प्राधिकरण नहीं बन सकते हैं। इडेम्पोटेंसी, टाइमआउट, सर्किट ब्रेकर, और रोलबैक या मैन्युअल रिकवरी रिट्राई, सर्वर परिवर्तन, अनुमोदन बेमेल और आंशिक विफलता को संभालते हैं।"
चरण-दर-चरण विस्तृत उत्तर
एक पहचान-जागरूक टूल कैटलॉग बनाएं
सर्वर पहचान, टूल नाम, इनपुट और आउटपुट JSON Schemas, कोड संस्करण, नेटवर्क स्कोप और वास्तविक साइड इफेक्ट्स पंजीकृत करें। एक कैटलॉग परिवर्तन एक संस्करण और समीक्षा रिकॉर्ड बनाता है; रनटाइम कॉल केवल स्वीकृत संस्करणों का उपयोग करते हैं। MCP विनिर्देश नाम, विवरण और इनपुट स्कीमा को परिभाषित करता है, और आउटपुट स्कीमा की अनुमति देता है, लेकिन क्लाइंट को अभी भी स्वतंत्र सत्यापन की आवश्यकता होती है।
प्राधिकरण को एक इनवोकेशन से बांधें
पॉलिसी इनपुट में प्रिंसिपल, टेनेंट, संसाधन, कार्रवाई, डेटा वर्ग, पर्यावरण और टूल संस्करण शामिल होना चाहिए। निर्णय अनुमति (allow), अस्वीकार (deny), या अनुमोदन-आवश्यक (approval-required) है, और यह एक अल्पकालिक (short-lived) इनवोकेशन टोकन उत्पन्न करता है। टोकन को पैरामीटर डाइजेस्ट से बांधें ताकि मॉडल अनुमोदन के बाद राशि, रिपॉजिटरी या संसाधन को बदल न सके।
एनोटेशन और विवरण को संकेतों के रूप में व्याख्या करें
readOnlyHint और destructiveHint रैंकिंग में सुधार कर सकते हैं, लेकिन वे निष्पादन को अधिकृत नहीं कर सकते। यदि कोई सर्वर केवल-पढ़ने के लिए होने का दावा करता है, तब भी पॉलिसी समीक्षा किए गए पंजीकरण और देखी गई क्षमताओं पर निर्भर करती है। "ignore previous instructions" जैसा टेक्स्ट डेटा है, पॉलिसी अपडेट नहीं।
एक पृथक रनर के अंदर निष्पादित करें
अल्पकालिक क्रेडेंशियल्स, प्रतिबंधित एग्रेस और संसाधन कोटा का उपयोग करें। रनर केवल पॉलिसी-जांचे गए संरचित तर्क प्राप्त करता है; यह पूरी बातचीत या किसी अन्य टेनेंट का डेटा प्राप्त नहीं करता है। टूल टेक्स्ट, लिंक और एम्बेडेड संसाधन पहले परिणाम संगरोध (quarantine) में प्रवेश करते हैं, फिर आउटपुट-स्कीमा, आकार, कंटेंट-प्रकार और डेटा-लेबल जांच पास करते हैं।
अनुमोदन को स्पष्ट और पैरामीटर-बाउंड बनाएं
अनुमोदन दृश्य प्रिंसिपल, सर्वर, टूल संस्करण, पूर्ण पैरामीटर सारांश, लक्ष्य संसाधन, अपेक्षित साइड इफेक्ट, समाप्ति और निरसन पथ दिखाता है। पैरामीटर डाइजेस्ट के साथ अनुमोदन संग्रहीत करें; किसी भी फ़ील्ड परिवर्तन से यह अमान्य हो जाता है। कम जोखिम वाले रीड पोस्ट-हॉक सैंपलिंग का उपयोग कर सकते हैं, जबकि उच्च जोखिम वाले कार्यों के लिए निष्पादन से पहले अनुमोदन की आवश्यकता होती है।
रिट्राई और आंशिक पूर्णता को संभालें
राइट्स केवल एक यादृच्छिक मॉडल मान के बजाय व्यावसायिक कार्रवाई और इनवोकेशन इरादे से प्राप्त एक इडेम्पोटेंसी कुंजी ले जाते हैं। अनुरोध, परिणाम और रिट्राई स्थिति को बनाए रखें। टाइमआउट होने पर, रिट्राई करने से पहले निष्पादन स्थिति की जांच करें। यदि क्षतिपूर्ति सुरक्षित नहीं है, तो रिफंड या डिप्लॉयमेंट को आंख मूंदकर दोहराने के बजाय कार्रवाई को एक मानवीय कतार में ले जाएं।
सहसंबंधित ऑडिट ईवेंट उत्सर्जित करें
एक ईवेंट में अनुरोध आईडी, प्रिंसिपल, टेनेंट, सर्वर फ़िंगरप्रिंट, टूल संस्करण, पैरामीटर डाइजेस्ट, पॉलिसी निर्णय, अनुमोदक, निष्पादन परिणाम और डाउनस्ट्रीम क्रेडेंशियल आईडी शामिल हैं। संवेदनशील तर्कों को केवल संशोधित डाइजेस्ट या एन्क्रिप्टेड संदर्भों के रूप में संग्रहीत करें। यदि ऑडिट स्टोरेज अनुपलब्ध है, तो उच्च-जोखिम वाले कॉल को चुपचाप आगे बढ़ने के बजाय बंद (fail closed) होना चाहिए या एक लंबित स्थिति में प्रवेश करना चाहिए।
क्रमिक रूप से रोल आउट और निरस्त करें
एक छोटे टेनेंट या संस्करण रोलआउट से पहले सैंडबॉक्स सर्वर और शैडो ट्रैफ़िक के विरुद्ध कैटलॉग, नीतियों और परिणाम जांच को मान्य करें। पुराना कैटलॉग संस्करण और क्रेडेंशियल-निरसन स्विच रखें। यदि आप विशेषाधिकार वृद्धि, प्रॉम्प्ट इंजेक्शन, या परिणाम संदूषण का पता लगाते हैं, तो पहले नए कॉल ब्लॉक करें और टोकन रद्द करें, फिर पूर्ण किए गए साइड इफेक्ट्स को संभालने के लिए ऑडिट ईवेंट का उपयोग करें।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं MCP एकीकरण को कैटलॉग, पॉलिसी, अनुमोदन, रनर और ऑडिट परतों में विभाजित करूंगा। कैटलॉग सर्वर फ़िंगरप्रिंट, टूल संस्करण, स्कीमा और वास्तविक साइड इफेक्ट्स रिकॉर्ड करता है। मॉडल कॉल का प्रस्ताव कर सकता है, लेकिन पॉलिसी इंजन इसे प्रिंसिपल, टेनेंट, संसाधन और पर्यावरण द्वारा अधिकृत करता है। अनुमोदन एक पैरामीटर डाइजेस्ट से बंधा होता है, इसलिए राशि या लक्ष्य बदलने से यह अमान्य हो जाता है। रनर अल्पकालिक क्रेडेंशियल्स, प्रतिबंधित नेटवर्किंग और इडेम्पोटेंसी कुंजियों का उपयोग करता है। एजेंट तक पहुंचने से पहले परिणामों को क्वारंटाइन किया जाता है और स्कीमा, आकार, सामग्री प्रकार और डेटा लेबल के लिए जांचा जाता है। प्रत्येक निर्णय और डाउनस्ट्रीम अनुरोध ऑडिट लॉग में सहसंबंधित होता है। सर्वर परिवर्तन, टाइमआउट, डुप्लिकेट प्रभाव और ऑडिट विफलताओं में अस्वीकार, सर्किट-ब्रेकर और रिकवरी पथ होते हैं, जिन्हें सैंडबॉक्स और चरणबद्ध रोलआउट के माध्यम से मान्य किया जाता है।"
सामान्य गलतियां
एक एनोटेशन को अनुमति के रूप में मानना
विफलता पैटर्न: कॉल को स्वचालित रूप से अनुमति देना क्योंकि इसमें readOnlyHint है। यह क्यों विफल होता है: MCP विनिर्देश कहता है कि अविश्वसनीय सर्वरों के एनोटेशन को सुरक्षा तथ्यों के रूप में नहीं माना जा सकता है। सुधार: एनोटेशन को संकेत के रूप में उपयोग करें; पंजीकरण, नीति और रनटाइम क्षमता जांच से अनुमति प्राप्त करें।
केवल जनरेट किए गए तर्कों को मान्य करना
विफलता पैटर्न: जैसे ही JSON Schema सत्यापन पास होता है, निष्पादित करना। यह क्यों विफल होता है: अच्छी तरह से टाइप किए गए तर्क अभी भी टेनेंट्स को पार कर सकते हैं, प्रोडक्शन को लक्षित कर सकते हैं, या एक अपरिवर्तनीय कार्रवाई को दोहरा सकते हैं। सुधार: प्रिंसिपल, संसाधन स्वामित्व, जोखिम, इडेम्पोटेंसी और अनुमोदन डाइजेस्ट को भी मान्य करें।
केवल एक प्राकृतिक-भाषा अनुमोदन दिखाना
विफलता पैटर्न: उपयोगकर्ता से "रिफंड संभालें" को अनुमोदित करने के लिए कहना। यह क्यों विफल होता है: स्वीकृत वस्तु अस्पष्ट है, इसलिए निष्पादन समय पर राशि या खाता बदल सकता है। सुधार: लक्ष्य, राशि, संस्करण, पैरामीटर डाइजेस्ट, समाप्ति प्रदर्शित करें और उस डाइजेस्ट से अनुमोदन को बांधें।
टूल आउटपुट को विश्वसनीय निर्देश मानना
विफलता पैटर्न: लौटाए गए टेक्स्ट को अगले सिस्टम प्रॉम्प्ट में जोड़ना। यह क्यों विफल होता है: परिणामों में प्रॉम्प्ट इंजेक्शन, क्रॉस-टेनेंट डेटा, या दुर्भावनापूर्ण URIs हो सकते हैं। सुधार: परिणामों को क्वारंटाइन करें, प्रकारों को मान्य करें, डेटा को लेबल करें, और केवल न्यूनतम आवश्यक फ़ील्ड पास करें।
केवल सुखद पथ (happy path) डिज़ाइन करना
विफलता पैटर्न: प्रत्येक टाइमआउट को रिट्राई करना और प्रत्येक त्रुटि के बाद आगे बढ़ जाना। यह क्यों विफल होता है: एक अज्ञात निष्पादन स्थिति एक राइट को डुप्लिकेट कर सकती है, जबकि आंशिक पूर्णता एक व्यावसायिक इनवेरिएंट का उल्लंघन कर सकती है। सुधार: इडेम्पोटेंसी, स्थिति लुकअप, क्षतिपूर्ति, सर्किट ब्रेकिंग, और मानवीय एस्केलेशन को एक साथ डिज़ाइन करें।
फॉलो-अप प्रश्न और प्रतिक्रियाएं
क्या होगा यदि कॉल के दौरान टूल कैटलॉग बदल जाता है?
उस कॉल द्वारा उपयोग किए गए सर्वर फ़िंगरप्रिंट, टूल संस्करण और स्कीमा को फ्रीज करें। कैटलॉग परिवर्तन केवल नई कॉल को प्रभावित करते हैं। यदि संस्करण निरस्त कर दिया जाता है, तो पॉलिसी इंजन पुराने टोकन को अस्वीकार कर देता है और नए अनुमोदन का अनुरोध करता है।
क्या होगा यदि अनुमोदन सेवा अनुपलब्ध है?
उच्च-जोखिम वाले कार्यों के लिए फ़ेल क्लोज़ करें, प्रस्ताव को एक लंबित कतार में बनाए रखें। कम जोखिम वाले रीड पूर्व-स्वीकृत नीति के तहत जारी रह सकते हैं, लेकिन वे अभी भी ऑडिट ईवेंट उत्सर्जित करते हैं; अनुमोदन टाइमआउट कोई प्राधिकरण नहीं है।
क्या होगा यदि मान्य JSON में किसी अन्य टेनेंट का डेटा है?
एक आउटपुट स्कीमा आकार को मान्य करता है, ऑथराइजेशन स्कोप को नहीं। परिणाम जारी करने से पहले टेनेंट और संसाधन स्कोप को डाउनस्ट्रीम पास करें और स्वामित्व, डेटा लेबल और परिणाम कार्डिनैलिटी की जांच करें। उल्लंघन होने पर क्वारंटाइन करें और अलर्ट करें।
आप कैसे तय करते हैं कि कोई टूल स्वचालित रूप से चल सकता है या नहीं?
प्रतिवर्तीता (reversibility), ब्लास्ट रेडियस, डेटा संवेदनशीलता, डुप्लिकेट लागत और पता लगाने की क्षमता का स्कोर बनाएं। प्रतिवर्ती, कम संवेदनशीलता, कम प्रभाव वाले प्रश्नों को स्वचालित रूप से चलाया जा सकता है; धन हस्तांतरण, प्रोडक्शन परिवर्तन, विलोपन और क्रॉस-टेनेंट रीड्स के लिए मानवीय अनुमोदन या एक समर्पित वर्कफ़्लो की आवश्यकता होती है।
आप प्रॉम्प्ट इंजेक्शन की जांच कैसे करते हैं?
अनुरोध आईडी द्वारा मूल इनपुट, टूल-विवरण संस्करण, मॉडल प्रस्ताव, पॉलिसी निर्णय, अनुमोदन दृश्य, टूल परिणाम और बाद के कॉल को सहसंबंधित करें। पहले प्रभावित सर्वर और टोकन को निरस्त करें, फिर पूर्ण किए गए साइड इफेक्ट्स की पहचान करने के लिए क्वारंटाइन किए गए लॉग से निर्णयों को रीप्ले करें।