प्रोडक्शन-ग्रेड प्रॉम्पटिंग, एजेंट्स और टूल यूज

स्क्रीन 1: अंत तक आप क्या कर पाएंगे

मॉड्यूल 2 ओरिएंटेशन · 2 मिनट अंत तक आप क्या कर पाएंगे

Claude का उपयोग करने के लिए कोड लिखना Claude को कोड लिखने के लिए कहने से अलग है।

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

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

इस मॉड्यूल के अंत तक, आप निम्नलिखित कर पाएंगे: 1 सिस्टम प्रॉम्प्ट्स, XML टैग्स, फ्यू-शॉट उदाहरण, और आउटपुट बाधाओं का उपयोग करके प्रोडक्शन-रेडी प्रॉम्प्ट्स लिखें, और निदान करें कि जब पहली बार के परिणाम निशान से चूक जाएं तो एक प्रॉम्प्ट कम प्रदर्शन क्यों करता है। 2 निर्णय लें कि कब विस्तारित सोच को सक्षम करना है, इसके प्रयास सेटिंग को कैलिब्रेट करना है, और टूल-यूज़ टर्न्स में सोच ब्लॉक्स को सही तरीके से हैंडल करना है। 3 एक टूल स्कीमा को परिभाषित और लागू करें जिसे Claude सही तरीके से चुनता है, टूल-यूज़ लूप का निर्माण करें, मल्टी-टर्न मैसेज ब्लॉक्स को हैंडल करें, और यह अंतर करें कि कब एकल टूल कॉल का उपयोग करना है बनाम कई समानांतर कॉल्स। 4 एक स्ट्रीम की गई प्रतिक्रिया का उपभोग करें, स्ट्रीम की गई इवेंट्स को पूर्ण कंटेंट ब्लॉक्स में असेंबल करें, और जब एक स्ट्रीम आधे रास्ते में बाधित हो तो स्वच्छ रूप से पुनः प्राप्त करें। 5 कॉन्टेक्स्ट इंजीनियरिंग तकनीकें लागू करें जिनमें कॉन्टेक्स्ट विंडो को प्रबंधित करना, कॉम्पैक्ट करना, कार्यों के बीच इतिहास को साफ करना, और सबएजेंट हैंडऑफ्स शामिल हैं, ताकि मल्टी-टर्न एजेंट सेशन्स को बजट के भीतर रखा जा सके बिना कार्य निरंतरता खोए। 6 एक प्रोडक्शन एजेंट बनाएं वर्कफ़्लो और एजेंट पैटर्न के बीच चुनाव करके, टूल्स और कॉन्टेक्स्ट को एक कार्यशील लूप में वायर करके, एक वायरिंग पाथ चुनकर जो आपकी तैनाती की बाधाओं के अनुरूप हो, और ह्यूमन-इन-द-लूप (HITL) चेकपॉइंट्स जोड़कर जहां कार्य अपरिवर्तनीय हैं। 7 सेशन्स के पार एजेंट मेमोरी को प्रबंधित करें स्थायी स्टोरेज पैटर्न का उपयोग करके और सही मेमोरी स्कोप चुनकर ताकि एजेंट स्टेट टर्न्स के पार जीवित रहे बिना कॉन्टेक्स्ट कॉस्ट को बढ़ाए। 8 सही मैसेज ब्लॉक स्ट्रक्चर का उपयोग करके Claude को इमेजेस और PDFs भेजें, पुनः उपयोग योग्य एसेट्स के लिए Files API लागू करें, और Message Batches API का उपयोग करके उच्च-वॉल्यूम वर्कलोड्स सबमिट करें ताकि वे एसिंक्रोनसली पूर्ण हों।

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

"इस मॉड्यूल में बिल्ड"

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

शैक्षणिक सामग्री के लिए अस्वीकरण / नोटिस

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

स्क्रीन 2: सिस्टम प्रॉम्प्ट्स, XML, फ्यू-शॉट, और आउटपुट बाधाएं

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

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

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

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

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

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

कार्य किया गया उदाहरण: एक वर्गीकरण प्रॉम्प्ट पहले और बाद में एक डेवलपर को Claude को सपोर्ट टिकट्स को तीन श्रेणियों में वर्गीकृत करने की आवश्यकता है: बिलिंग, तकनीकी, और एस्केलेशन। पहला प्रॉम्प्ट आउटपुट पर कोई बाधा के साथ एक नंगा निर्देश है:

System: "You are a support classifier. Classify the ticket. "

User: <ticket>I was charged twice for the same month. </ticket>

Claude कुछ रन पर "Billing" लौटाता है, दूसरों पर "billing", और कभी-कभी "This looks like a billing issue. " जैसा एक पूरा वाक्य। डाउनस्ट्रीम राउटर एक निश्चित सेट के लेबल्स में से एक की अपेक्षा करता है और असंगति पर टूट जाता है।

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

System: "You are a support classifier. Classify each ticket into exactly one of: BILLING, TECHNICAL, ESCALATION. Return only the label. No other text. "

<sample_input>My account shows two charges for April. </sample_input> <ideal_output>BILLING</ideal_output>

<sample_input>The API keeps returning a 429 error. </sample_input> <ideal_output>TECHNICAL</ideal_output>

User: <ticket>I was charged twice for the same month. </ticket>

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

नीचे दी गई तालिका दिखाती है कि हम सभी चार तकनीकों को कैसे स्टैक कर सकते हैं, जहां प्रॉम्प्ट को सरल किया जाना चाहिए, और जहां हम अधिक जोड़ने से पहले निदान करना चाहिए।

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

जब प्रत्येक तकनीक तक पहुंचना है अब, आइए समझते हैं कि इनमें से प्रत्येक तकनीक के बारे में अधिक जानकारी प्राप्त करें और कब प्रत्येक लागू होता है:

सिस्टम प्रॉम्प्ट्स XML टैग्स फ्यू-शॉट उदाहरण आउटपुट बाधाएं

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

XML टैग्स का उपयोग तब किया जाता है जब प्रॉम्प्ट इनपुट्स को निर्देशों के साथ मिलाता है। एक प्रॉम्प्ट जो Claude को प्रदान किए गए दस्तावेज़ों का उपयोग करके कोड को डीबग करने के लिए कहता है एक अच्छा उदाहरण है; टैग्स के बिना, कोड और दस्तावेज़ Claude को समान दिखते हैं। उन्हें <my_code> और <docs> जैसे वर्णनात्मक टैग नामों के साथ लपेटें और सीमा स्पष्ट हो जाती है। आपको आधिकारिक XML टैग नामों का उपयोग करने की आवश्यकता नहीं है; वर्णनात्मक नाम जो आपकी सामग्री से मेल खाते हैं सबसे अच्छे काम करते हैं।

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

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

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

इसके बजाय, पहले समस्या का निदान करें, फिर अपने निष्कर्षों के आधार पर पुनः प्रॉम्प्ट करें। विफलता प्रकार आपको बताता है कि कौन सी तकनीक गायब है:

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

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

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

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

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

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

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

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

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

स्क्रीन 3: प्रॉम्प्ट जो लंबा हुआ बजाय बेहतर

सावधानीप्रॉम्पटिंग क्राफ्ट·5 मिनट प्रॉम्प्ट जो लंबा हुआ बजाय बेहतर

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

छह संशोधन पास, प्रत्येक अंतिम से लंबा पिछले उदाहरण में उपयोग किया गया प्रॉम्प्ट नीचे दिया गया है: एक डेवलपर को Claude को सपोर्ट टिकट्स को तीन श्रेणियों में वर्गीकृत करने की आवश्यकता है: बिलिंग, तकनीकी, और एस्केलेशन। पहला प्रॉम्प्ट एक नंगा निर्देश है: System: "You are a support classifier. Classify the ticket. " User: <ticket>I was charged twice for the same month. </ticket> नीचे दिया गया ट्रेस एक डेवलपर को एक वर्गीकरण प्रॉम्प्ट पर पुनरावृत्ति दिखाता है, और हालांकि प्रत्येक पास अधिक शब्द जोड़ता है, आउटपुट बहाव करता रहता है। यह पैटर्न तब उभरता है जब एक डेवलपर बाधा विनिर्देशों के संबंध में अपने प्रॉम्प्ट में जोड़ता है।

पासक्या जोड़ा गया थाआउटपुट व्यवहार 1"Classify this ticket as billing, technical, or escalation. "पूरे वाक्य लौटाता है: "This appears to be a billing issue. " पार्सर टूट जाता है। 2"Be concise. " और "Use only the category name. " जोड़ाकभी-कभी "Billing" कैपिटलाइज़्ड लौटाता है, कभी-कभी "billing" लोअरकेस। राउटर केस मिसमैच पर टूट जाता है। 3प्रत्येक श्रेणी का विस्तार से वर्णन करने वाले तीन पैराग्राफ जोड़ासरल टिकट्स पर सही आउटपुट। अस्पष्ट टिकट्स के लिए, 'billing/technical' के बजाय एक एकल लेबल लौटाता है। पार्सर स्लैश पर टूट जाता है। 4"Never return two categories. " और "If ambiguous, choose the most likely one. " जोड़ा80% टिकट्स पर काम करता है। उन टिकट्स पर विफल जो उचित रूप से दो श्रेणियों में फिट हो सकते हैं (जैसे, 'I was charged but the feature also stopped working')। यहां यह एक लेबल के बजाय एक पूरी व्याख्या लौटाता है। 5एज केस्स के बारे में दो और पैराग्राफ और सटीक होने की याद दिलाने वाली जोड़ाशब्दबहुल प्रॉम्प्ट अब प्रति कॉल 2,000 से अधिक वर्णों का उत्पादन कर रहा है, जैसा कि लंबे, अनफोकस्ड प्रॉम्प्ट्स करते हैं। मॉडल इनपुट से मेल खाने के लिए प्रतिक्रिया लंबाई और शैली को कैलिब्रेट करता है। लेटेंसी में काफी वृद्धि हुई है, लेकिन सटीकता में सुधार नहीं हुआ है। 6सभी निर्देशों को एक JSON स्कीमा और दो फ्यू-शॉट उदाहरणों से बदला गया जो सटीक इनपुट/आउटपुट जोड़ी दिखाते हैंहर टिकट पर {"category": "billing"} लौटाता है। पार्सर काम करता है। लेटेंसी गिरता है। अस्पष्ट टिकट्स पर सटीकता पास 4 से मेल खाती है।

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

System: "You are a support classifier. Classify each ticket into exactly one of: BILLING, TECHNICAL, ESCALATION. Return only the label. No other text. "

<sample_input>My account shows two charges for April. </sample_input> <ideal_output>BILLING</ideal_output>

<sample_input>The API keeps returning a 429 error. </sample_input> <ideal_output>TECHNICAL</ideal_output>

User: <ticket>I was charged twice for the same month. </ticket>

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

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

स्क्रीन 4: चेकपॉइंट 1 · टूटे हुए प्रॉम्प्ट को ठीक करें

चेकपॉइंटप्रॉम्पटिंग क्राफ्ट·4 मिनट चेकपॉइंट 1 · टूटे हुए प्रॉम्प्ट को ठीक करें यहां दिखाया गया प्रॉम्प्ट एक सपोर्ट टिकट से एक JSON ऑब्जेक्ट निकालता है जिसमें तीन फील्ड्स हैं: श्रेणी, तात्कालिकता, और एक-वाक्य सारांश। इसमें एक दोष है। सही किए गए सिस्टम प्रॉम्प्ट लिखें जो इसे ठीक करता है।

टूटा हुआ प्रॉम्प्ट System: "You are a support ticket processor. Extract the key information from the ticket below. "

User: <ticket>My API key stopped working after I rotated it last night. I have a production deployment that is failing. This needs to be fixed immediately. </ticket>

मॉडल उत्तर प्रकट करें अभी के लिए छोड़ें

स्क्रीन 5: विस्तारित सोच: तर्क को चालू करना, प्रयास को कैलिब्रेट करना, और इसे सही तरीके से पढ़ना

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

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

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

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

कब विस्तारित सोच का उपयोग करें

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

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

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

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

आगे का सूचक यह पाठ तर्क को सक्षम करता है और इसके प्रयास सेटिंग को कैलिब्रेट करता है; यह मॉडल चयन को कवर नहीं करता है। कौन सा मॉडल चलाना है, तर्क को सक्षम करना है या नहीं यह अलग है, MSO Foundations मॉड्यूल में सिखाया जाता है जो इससे पहले आता है।

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

स्क्रीन 6: चेकपॉइंट 2 · तय करें कि विस्तारित सोच अपनी लागत अर्जित करता है या नहीं

चेकपॉइंटविस्तारित सोच·3 मिनट चेकपॉइंट 2 · तय करें कि विस्तारित सोच अपनी लागत अर्जित करता है या नहीं नीचे तीन कार्य वर्णित हैं। बाईं ओर प्रत्येक कार्य को दाईं ओर सही विस्तारित-सोच निर्णय से मिलाएं। प्रति कार्य एक सही कॉल है।

50,000 सपोर्ट टिकट्स को रात भर तीन लेबल्स में वर्गीकृत करें।कभी ऐसा न करें।इसे बंद छोड़ें।इसे सक्षम करें, योजना चरण के लिए बजट करें।एक मल्टी-स्टेप रीफैक्टर की योजना बनाएं जहां प्रत्येक स्टेप पिछले पर निर्भर करता है।कभी ऐसा न करें।इसे बंद छोड़ें।इसे सक्षम करें, योजना चरण के लिए बजट करें।अगले टूल कॉल से पहले संदर्भ को बचाने के लिए बातचीत इतिहास से सोच ब्लॉक को छीनें।कभी ऐसा न करें।इसे बंद छोड़ें।इसे सक्षम करें, योजना चरण के लिए बजट करें।

सबमिट करें अभी के लिए छोड़ें

स्क्रीन 7: टूल स्कीमा Claude सही तरीके से चुनता है: परिभाषा, लूप, और कॉलिंग पैटर्न

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

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

यह बैक-एंड-फोर्थ प्रोडक्शन में अनदेखा नहीं किया जाना चाहिए: यदि आपका एप्लिकेशन रिटर्न को सही तरीके से हैंडल नहीं करता है, तो Claude को कभी भी डेटा नहीं मिलता है जिसे यह मांग रहा है, और लूप टूट जाता है। सही कार्यान्वयन सुनिश्चित करने के लिए अनुक्रम यहां है।

प्रत्येक चरण पर क्लिक करें यह देखने के लिए कि क्या होता है।

1स्कीमा परिभाषित करें 2संदेश भेजें 3tool_use ब्लॉक 4टूल निष्पादित करें 5परिणाम लौटाएं 6Claude जारी रखता है

स्कीमा परिभाषित करेंआप एक नाम, विवरण, और इनपुट स्कीमा के साथ एक स्कीमा परिभाषित करते हैं। Claude यह तय करने के लिए इसे पढ़ता है कि क्या और कब टूल को कॉल करना है।

यह ध्यान रखना महत्वपूर्ण है कि लूप स्वचालित नहीं है और आपको चौथे चरण को पूरा करने की आवश्यकता है। यदि मिस व्यवस्थित है, तो समाधान स्कीमा परिभाषा चरण में है।

टूल-यूज़ बातचीत में संदेश ब्लॉक संरचना एक टूल-यूज़ बातचीत सादे पाठ से नहीं, संरचित ब्लॉक्स से बनी है। प्रत्येक सहायक टर्न और उपयोगकर्ता टर्न ब्लॉक्स की एक सूची है, और चार ब्लॉक प्रकार एक टूल-यूज़ सेशन में काम करते हैं। एक पाठ ब्लॉक Claude की गद्य प्रतिक्रिया ले जाता है। एक tool_use ब्लॉक एक टूल कॉल ले जाता है, जिसमें टूल नाम, एक अद्वितीय ID, और इनपुट तर्क शामिल हैं। एक tool_result ब्लॉक आपके कोड द्वारा टूल चलाने के बाद लौटाया गया है। एक सोच ब्लॉक Claude के आंतरिक तर्क को ले जाता है, और यह केवल तब दिखाई देता है जब विस्तारित सोच सक्षम होता है।

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

नीचे दी गई तालिका प्रत्येक ब्लॉक प्रकार, इसमें क्या है, और नियम को सारांशित करती है जो आपके कोड को इसे हैंडल करने के लिए पालन करना चाहिए।

ब्लॉक प्रकारभूमिकाइसमें क्या हैनियंत्रक नियम पाठ ब्लॉकसहायक/Claudeकी गद्य आउटपुटClaude एक ही टर्न में एक tool_use ब्लॉक के साथ एक पाठ ब्लॉक लौटा सकता है। जब यह करता है, तो आपके कोड को पूर्ण सामग्री सरणी को संरक्षित करना चाहिए, जिसमें पाठ ब्लॉक भी शामिल है, जब उस टर्न को बातचीत इतिहास में जोड़ा जाता है। पाठ ब्लॉक को छोड़ना उस संदर्भ को भ्रष्ट करता है जिस पर Claude अनुवर्ती टर्न्स के लिए निर्भर करता है। tool_use ब्लॉकसहायक/Claudeटूल नाम, एक अद्वितीय ID, और इनपुट तर्क Claude आपके फ़ंक्शन को पास करना चाहता हैहर tool_use ब्लॉक को तुरंत अनुसरण करने वाले उपयोगकर्ता टर्न में एक tool_result ब्लॉक द्वारा उत्तर दिया जाना चाहिए। tool_result को समान ID ले जाना चाहिए। उस जोड़ी के बिना, API अगले अनुरोध को अस्वीकार करता है। tool_result ब्लॉकउपयोगकर्तामेल खाने वाली tool_use ID, परिणाम सामग्री, और एक वैकल्पिक is_error फ्लैग जब टूल कॉल विफल होता हैtool_use_id मान मूल tool_use ब्लॉक से बिल्कुल मेल खाना चाहिए। Claude इस ID का उपयोग प्रत्येक परिणाम को उस कॉल से जोड़ने के लिए करता है जिसने इसे उत्पादित किया, जो महत्वपूर्ण है जब एक सहायक टर्न कई टूल कॉल्स जारी करता है और परिणाम एक अलग क्रम में आते हैं। सोच ब्लॉकसहायक (विस्तारित सोच केवल)/Claudeकी आंतरिक तर्क, केवल तब दिखाई देता है जब विस्तारित सोच सक्षम होता हैब्लॉक को अपरिवर्तित रूप से अनुवर्ती टर्न्स में API को वापस पास किया जाना चाहिए। हस्ताक्षर सत्यापित करता है कि तर्क को संशोधित नहीं किया गया है, इसलिए कोई भी संपादन या सारांश हस्ताक्षर को तोड़ता है और API संदेश को अस्वीकार करता है। संपादित सोच ब्लॉक्स समान नियम का पालन करते हैं: उन्हें प्राप्त के रूप में वापस पास करें, भले ही सामग्री एन्क्रिप्ट की गई हो और मानव-पठनीय न हो।

महत्वपूर्ण अपरिवर्तनीय यह है कि एक सहायक टर्न से हर tool_use ब्लॉक को तुरंत अनुसरण करने वाले उपयोगकर्ता टर्न में एक संबंधित tool_result ब्लॉक होना चाहिए। गायब tool_result ब्लॉक्स, या tool_result ब्लॉक्स जो तुरंत अनुसरण करने वाले उपयोगकर्ता टर्न के बजाय एक बाद के टर्न में दिखाई देते हैं, एक API सत्यापन त्रुटि का कारण बनते हैं।

स्कीमा शरीर: Claude क्या पढ़ता है एक टूल चयन निर्णय करने के लिए एक टूल स्कीमा में तीन भाग होते हैं, जिसमें नाम, विवरण, और input_schema शामिल हैं। विवरण यह निर्धारित करता है कि Claude टूल को सही तरीके से चुनता है या नहीं।

नाम: एक छोटा पहचानकर्ता जो विशिष्ट होना चाहिए। उदाहरण के लिए, get_account_balance get_data से अधिक उपयोगी है Claude के लिए। विवरण: एक महत्वपूर्ण भाग जो Claude एक टूल की आवश्यकता है या नहीं यह तय करने के लिए पढ़ता है। आपको हमेशा विवरण को दो भागों में लिखना चाहिए, जिसमें कब और कब नहीं शामिल है:

एक विवरण जो कहता है "इसका उपयोग जानकारी खोजने के लिए करें" गलत चयन का कारण बनेगा क्योंकि Claude इसे किसी अन्य टूल से अलग नहीं कर सकता जो कुछ भी पुनः प्राप्त करता है। एक विवरण जो कहता है "इसका उपयोग एक विशिष्ट खाता ID के लिए वर्तमान शेष राशि पुनः प्राप्त करने के लिए करें और लेनदेन इतिहास के लिए इसका उपयोग न करें" Claude को काम करने के लिए एक बहिष्कार शर्त देता है और उचित रूप से वर्णनात्मक है।

input_schema: JSON स्कीमा का उपयोग करके पैरामीटर्स (आपके टूल फ़ंक्शन स्वीकार करने वाले इनपुट्स) को परिभाषित करता है।

आपको पैरामीटर्स को आवश्यक के रूप में चिह्नित करना चाहिए जब Claude को उन्हें सही तरीके से कॉल करने के लिए आवश्यकता होती है। आप पैरामीटर्स को वैकल्पिक के रूप में चिह्नित कर सकते हैं जब टूल उनके बिना काम कर सकता है। टूल्स के बीच ओवरलैपिंग पैरामीटर प्रकार गलत-टूल कॉल्स का सबसे आम स्रोत हैं।

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

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

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

एक डेवलपर दो टूल्स रजिस्टर करता है, जिसमें search_knowledge_base और get_cached_result शामिल हैं। टूल नाम अलग हैं, लेकिन Claude का टूल चयन विवरण को भारी करता है; जब विवरण ओवरलैप करते हैं, तो नाम अकेले disambiguate करने के लिए पर्याप्त नहीं है। दोनों के विवरण हैं जो "जानकारी खोजने के लिए इसका उपयोग करें" से शुरू होते हैं। बहिष्कार शर्तों के बिना, Claude अस्पष्ट इनपुट्स पर विकास परीक्षण के दौरान अक्सर गलत टूल चुनता है।

समस्या यह है कि दोनों विवरण Claude को चयन निर्णय के बिंदु पर समान दिखते हैं। समाधान प्रत्येक विवरण में एक अतिरिक्त वाक्य जोड़ना है:

search_knowledge_base: "Use this to search the knowledge base when the user asks a question that requires looking up current information. Do not use this if the result of a prior search in this session already covers the question. "

get_cached_result: "Use this to retrieve a result that was already fetched during this session. Only use this if search_knowledge_base was called earlier in this conversation for the same query. "

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

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

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

जब किसी और ने पहले से ही आपके टूल्स लिखे हैं: MCP मैनुअल स्कीमा लेखन के लिए एक विकल्प के रूप में पिछले अनुभागों में सब कुछ मानता है कि आप टूल स्कीमा स्वयं लिख रहे हैं: नाम, विवरण, input_schema, और फ़ंक्शन जो Claude एक tool_use ब्लॉक जारी करता है तो निष्पादित होता है। कई एकीकरणों के लिए, आपको ऐसा करने की आवश्यकता नहीं है। Model Context Protocol, MCP, एक मानकीकृत संचार परत है जो टूल परिभाषाओं और निष्पादन को आपके एप्लिकेशन कोड से बाहर और समर्पित सर्वर में ले जाता है। जब एक MCP सर्वर उस सेवा के लिए मौजूद है जिसे आप तक पहुंचना चाहते हैं, तो आप मैनुअल रूप से एकीकरण बनाने के बजाय सीधे MCP सर्वर से जुड़ सकते हैं।

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

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

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

यदि आप API MCP Connector का उपयोग कर रहे हैं, तो आप tools सरणी में एक mcp_toolset ऑब्जेक्ट के माध्यम से लोडिंग लागत को नियंत्रित करते हैं। mcp_toolset एक default_config ब्लॉक ले जाता है जो सर्वर पर हर टूल पर लागू होता है, और आप configs में टूल नाम द्वारा कुंजीकृत व्यक्तिगत टूल्स को ओवरराइड कर सकते हैं। कॉन्टेक्स्ट लागत के लिए दो सेटिंग्स महत्वपूर्ण हैं:

defer_loading बूलियन, default_config के अंदर या configs में एक प्रति-टूल प्रविष्टि में सेट, जब मॉडल को इसकी आवश्यकता होती है तब तक एक टूल परिभाषा को लोड करने में देरी करता है, जो अपफ्रंट कॉन्टेक्स्ट लागत को कम करता है जब आप एक बड़ी टूल सूची वाले सर्वर को जोड़ते हैं। enabled बूलियन व्यक्तिगत टूल्स को चालू या बंद करता है, इसलिए आप एक सर्वर को रजिस्टर कर सकते हैं लेकिन केवल उन टूल्स को उजागर कर सकते हैं जिन्हें आप मॉडल को देखना चाहते हैं। MCP Connector को अनुरोध पर mcp-client-2025-11-20 बीटा हेडर सेट करने की आवश्यकता है।

उस हेडर के बिना, mcp_toolset कॉन्फ़िगरेशन यहां वर्णित के रूप में लागू नहीं होगा।

अन्य टुकड़ा जो इस चरण पर जानने योग्य है वह यह है कि क्लाइंट वास्तव में सर्वर से कैसे बात करता है। MCP दो ट्रांसपोर्ट्स पर चलता है, और कौन सा आप उपयोग करते हैं यह इस बात पर निर्भर करता है कि सर्वर कहां रहता है। स्थानीय सर्वर्स stdio का उपयोग करते हैं और आपका एप्लिकेशन सर्वर को एक सबप्रोसेस के रूप में स्पॉन करता है और मानक इनपुट और आउटपुट पर संचार करता है। दूरस्थ सर्वर्स Streamable HTTP का उपयोग करते हैं और आपका एप्लिकेशन HTTP के माध्यम से नेटवर्क पर जुड़ता है, क्लाइंट-से-सर्वर संदेशों के लिए POST का उपयोग करते हुए और सर्वर-शुरू किए गए संदेशों के लिए एक वैकल्पिक GET-आधारित SSE स्ट्रीम। एक पुरानी SSE-केवल ट्रांसपोर्ट मौजूद है लेकिन पदावनत है, और नए एकीकरण को Streamable HTTP का उपयोग करना चाहिए। एक बाधा ध्यान देने योग्य है यदि आप API में Anthropic के MCP कनेक्टर का उपयोग कर रहे हैं: केवल HTTP-उजागर सर्वर्स कनेक्टर के माध्यम से समर्थित हैं, और stdio सर्वर्स को SDK के माध्यम से MCP क्लाइंट कनेक्शन को स्वयं प्रबंधित करने की आवश्यकता है। एक बार कनेक्शन स्थापित हो जाने और टूल परिभाषाएं प्राप्त हो जाने के बाद, आपका एप्लिकेशन कोड दोनों ट्रांसपोर्ट्स को समान रूप से मानता है।

MCP का उपयोग करें जब एक अच्छी तरह से बनाए रखा MCP सर्वर पहले से ही उस सेवा के लिए मौजूद है जिसकी आपको आवश्यकता है (जांचें कि यह विशिष्ट संचालन को कवर करता है जिसकी आपको आवश्यकता है और सेवा के वर्तमान API के विरुद्ध सक्रिय रूप से बनाए रखा जाता है। उन स्कीमा को स्वयं लिखना और स्वामित्व करना कोई अतिरिक्त क्षमता के लिए कार्यान्वयन ओवरहेड जोड़ता है। ध्यान दें कि Claude API MCP Connector केवल दूरस्थ सर्वर्स को समर्थन करता है। स्थानीय stdio सर्वर्स को Claude Desktop या Claude Code के रूप में क्लाइंट की आवश्यकता है; उन्हें API के माध्यम से सीधे जोड़ा नहीं जा सकता है।

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

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

स्क्रीन 8: विवरण जो Claude को गलत टूल पर भेजा

सावधानीटूल-यूज़ और स्कीमा डिज़ाइन·5 मिनट विवरण जो Claude को गलत टूल पर भेजा

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

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

आइए नीचे दिया गया विनिमय देखें जो तब होता है जब एक डेवलपर सुबह से गलत टूल चयन को डीबग कर रहा है। सीनियर डेवलपर एक प्रश्न पूछता है जो पूरी समस्या को फिर से तैयार करता है:

डेवलपर: "Claude क्यों search_docs को कॉल करता रहता है जब उत्तर पहले से ही संदर्भ में है? मैंने इसे चार बार फिर से चलाया है, और यह गलत टूल पर जाता रहता है।" सीनियर डेवलपर: "search_docs के लिए विवरण क्या कहता है? " डेवलपर: "'Use this to find information about the product. '" सीनियर डेवलपर: "और get_context_summary क्या कहता है? " डेवलपर: "'Use this to retrieve relevant information from the current session. '" सीनियर डेवलपर: "वे विवरण Claude के दृष्टिकोण से एक ही चीज़ हैं। दोनों कहते हैं, 'जानकारी खोजें।' उनमें से एक को कहने की आवश्यकता है कि कब इसे कॉल न करें।" डेवलपर: "तो, मुझे एक बहिष्कार जोड़ने की आवश्यकता है? " सीनियर डेवलपर: "सही। search_docs को 'use this when the user asks a question that requires looking up content not already present in this conversation. Do not call this if the answer is available in the current session context. ' तब get_context_summary in-context केस को हैंडल करता है। आप get_context_summary के विवरण को समान तरीके से कसना चाहेंगे: 'Only use this if the answer is already present in the current session. Do not use this to look up new information. ' दोनों टूल्स को सीमा की आवश्यकता है, केवल एक को नहीं।" डेवलपर: "यह दो वाक्य हैं।" सीनियर डेवलपर: "सही। एक यह कहने के लिए कि इसे कब उपयोग करें, एक यह कहने के लिए कि कब नहीं। यह पूरा समाधान है।"

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

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

स्क्रीन 9: चेकपॉइंट 3 · स्कीमा बग को स्पॉट और ठीक करें

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

ट्रेस को पढ़ने से पहले जानने योग्य एक सम्मेलन: tool_result ब्लॉक्स हमेशा उपयोगकर्ता भूमिका में भेजे जाते हैं, भले ही सामग्री आपके एप्लिकेशन द्वारा उत्पन्न की गई हो बजाय किसी व्यक्ति द्वारा टाइप की गई। भूमिका फील्ड चिह्नित करता है कि कौन Claude को संदेश भेज रहा है, अंतर्निहित सामग्री के लेखक को नहीं। ट्रेस में टर्न 3 को "User (tool result)" के रूप में लेबल किया गया है ताकि वह असाइनमेंट स्पष्ट हो।

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

सेशन ट्रेस टर्न 1: उपयोगकर्ता: [पाठ]: "What is the current balance for account A-4471? "

टर्न 2: सहायक: [पाठ]: "I'll look that up. " [tool_use]: id="toolu_01", name="get_account_balance", input={"account_id": "A-4471"}

टर्न 3: उपयोगकर्ता (टूल परिणाम): [tool_result]: tool_use_id="toolu_02", content="Balance: $1,240. 18"

टर्न 4: API प्रतिक्रिया: त्रुटि: invalid_request_error "tool_result block references unknown tool_use_id"

Aget_account_balance पर विवरण को अपडेट करें ताकि एक बहिष्कार शर्त जोड़ी जा सके।Btool_result ब्लॉक पर tool_use_id को सही करें ताकि यह सहायक टर्न में जारी किए गए id से मेल खाए।Cटूल के input_schema में एक आवश्यक सरणी जोड़ें ताकि account_id को छोड़ा न जा सके।

सबमिट करें अभी के लिए छोड़ें

स्क्रीन 10: स्ट्रीमिंग प्रतिक्रियाएं और आंशिक आउटपुट को बिना स्टेट को भ्रष्ट किए हैंडल करना

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

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

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

इवेंट अनुक्रम, और आपका हैंडलर प्रत्येक के साथ क्या करता है

इवेंटयह क्या संकेत देता हैआपका हैंडलर क्या करता है message_startएक नया संदेश शुरू हो रहा है। खाली सामग्री और प्रारंभिक उपयोग के साथ संदेश शेल ले जाता है।एकत्रित करने के लिए एक खाली सामग्री सरणी सेट अप करें ब्लॉक्स में। content_block_startएक नया सामग्री ब्लॉक खुल रहा है, इसके प्रकार (पाठ, tool_use, या सोच) और सूचकांक के साथ।उस सूचकांक पर नाम किए गए ब्लॉक प्रकार के लिए एक स्लॉट बनाएं। एक tool_use ब्लॉक अपने नाम और id के साथ खुलता है, लेकिन अभी तक कोई इनपुट नहीं। content_block_deltaएक ब्लॉक का एक वृद्धिशील टुकड़ा: एक पाठ टुकड़ा, एक टूल कॉल के लिए JSON इनपुट का एक टुकड़ा, या एक सोच टुकड़ा।उस सूचकांक पर ब्लॉक में टुकड़े को जोड़ें। टूल-कॉल इनपुट्स कई deltas में एक आंशिक JSON स्ट्रिंग के रूप में आते हैं, आप उन्हें तब तक पार्स नहीं कर सकते जब तक ब्लॉक बंद न हो जाए। content_block_stopइस सूचकांक पर ब्लॉक पूर्ण है।ब्लॉक को अंतिम रूप दें। एक tool_use ब्लॉक के लिए, यह पहली बार है जब संचित JSON इनपुट पार्स करने के लिए पूर्ण है। message_deltaसंदेश के शीर्ष-स्तरीय परिवर्तन: stop_reason और अंतिम उपयोग गणना।stop_reason रिकॉर्ड करें। यह आपको बताता है कि क्या मॉडल समाप्त हुआ या किसी अन्य कारण से रुका। message_stopस्ट्रीम पूर्ण है।असेंबल की गई सामग्री सरणी अब समाप्त संदेश है। यहां से, इसे एक गैर-स्ट्रीम किए गए प्रतिक्रिया की तरह मानें।

नियम जो आपके स्टेट को भ्रष्ट होने से रोकता है: एक आंशिक ब्लॉक पर कार्य न करें tool_use ब्लॉक वह है जिसे देखना है। इसका इनपुट कई content_block_delta इवेंट्स में एक आंशिक JSON स्ट्रिंग के रूप में दिखाई देता है, और वह स्ट्रिंग तब तक वैध JSON नहीं है जब तक content_block_stop ब्लॉक को बंद न कर दे। यदि आपका कोड ब्लॉक बंद होने से पहले इनपुट को पार्स करने या टूल को चलाने का प्रयास करता है, तो यह या तो खराब JSON पर दम तोड़ता है या आधे तर्कों के साथ चलता है। तो, नियम सरल है: deltas को एकत्रित करें, और केवल उस ब्लॉक के लिए content_block_stop के बाद कार्य करें।

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

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

पूर्णता पर उद्देश्य से ट्रैक करें। एक टर्न केवल message_stop आने के बाद उपयोग योग्य है। तब तक, जो आपने एकत्रित किया है उसे अनंतिम के रूप में मानें। एक बाधित स्ट्रीम पर, आंशिक सहायक टर्न को इतिहास में सहेजने के बजाय फेंक दें, फिर अनुरोध को फिर से प्रयास करें। एक आधा-निर्मित टर्न को प्रतिबद्ध करना बिल्कुल वह है जो अगले अनुरोध को तोड़ता है। अगले लूप को जारी रखने से पहले message_delta से stop_reason की जांच करें। एक stop_reason of tool_use का मतलब है कि आपकी असेंबल की गई टूल कॉल्स चलाने के लिए तैयार हैं; कोई अन्य मान का मतलब है कि आप एक अलग पाथ पर हैं, टूल पाथ पर नहीं।

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

स्क्रीन 11: स्ट्रीम जो इतिहास में एक आधा-लिखा टूल कॉल छोड़ गया

सावधानीस्ट्रीमिंग प्रतिक्रियाएं·5 मिनट स्ट्रीम जो इतिहास में एक आधा-लिखा टूल कॉल छोड़ गया

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

पोस्टमॉर्टम: एक बाधित स्ट्रीम के बाद इतिहास में प्रतिबद्ध आंशिक tool_use ब्लॉक एक एजेंट ने स्ट्रीमिंग का उपयोग किया ताकि इसके ऑपरेटर्स प्रतिक्रियाओं को वास्तविक समय में उत्पन्न देख सकें। हैंडलर content_block_delta इवेंट्स को एकत्रित करता है और जब इसका पढ़ने वाला लूप समाप्त हुआ तो सहायक टर्न को इतिहास में जोड़ता है। एक तेजी से स्थानीय कनेक्शन पर परीक्षण में, स्ट्रीम्स हमेशा पूर्णता तक चलते थे, इसलिए लूप हमेशा message_stop पर समाप्त होता था और संग्रहीत टर्न्स हमेशा पूर्ण होते थे।

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

टीम ने एक दोपहर स्कीमा और रिट्राई तर्क का निरीक्षण करते हुए बिताई, क्योंकि त्रुटि रिट्राई अनुरोध पर सामने आई। हालांकि, वास्तविक कारण अपस्ट्रीम था: हैंडलर ने 'पढ़ने वाला लूप समाप्त' को 'संदेश पूर्ण' के बराबर माना, और वे समान नहीं हैं।

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

स्क्रीन 12: चेकपॉइंट 4 · टूटे हुए स्ट्रीम हैंडलर को मरम्मत करें

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

टूटा हुआ हैंडलर blocks = {} stop_seen = False with client. messages. stream(model=model, max_tokens=4096, messages=messages, tools=tools) as stream: for event in stream: if event. type == "content_block_start": blocks[event. index] = init_block(event) elif event. type == "content_block_delta": apply_delta(blocks[event. index], event. delta) elif event. type == "message_stop": stop_seen = True messages. append({"role": "assistant", "content": assemble(blocks)})

मॉडल उत्तर प्रकट करें अभी के लिए छोड़ें

स्क्रीन 13: मॉडल चयन और मल्टी-टर्न सेशन्स को बजट में रखना

शिक्षणकॉन्टेक्स्ट इंजीनियरिंग·16 मिनट मॉडल चयन और मल्टी-टर्न सेशन्स को बजट में रखना आप एक प्रारंभिक पसंद करते हैं: कौन सा मॉडल वर्कलोड को चलाता है। Claude परिवार लागत, लेटेंसी, और क्षमता ट्रेडऑफ्स की एक श्रृंखला को कवर करता है, इसलिए आप जो मॉडल चुनते हैं वह मूल्य और गति फ्लोर सेट करता है जिसे हर बाद का निर्णय आगे बढ़ता है।

एक बार मॉडल सेट हो जाने के बाद, अगली बाधा कॉन्टेक्स्ट विंडो है: पूर्ण पाठ की अवधि जिसे मॉडल एक बार में ले सकता है, जिसमें आपका प्रॉम्प्ट, अब तक की बातचीत, और हर टूल परिणाम शामिल है। हर टूल परिणाम Claude लौटाता है कॉन्टेक्स्ट विंडो में जोड़ा जाता है और सेशन के बाकी हिस्से के लिए वहां रहता है। एक एकल-टर्न प्रॉम्प्ट में, यह अदृश्य है। एक मल्टी-स्टेप एजेंट सेशन में दस या बीस टूल कॉल्स चलाते हुए, विंडो तेजी से भर जाता है, और एक बार भरने के बाद, एजेंट या तो कॉम्पैक्ट करता है (विवरण खो रहा है) या कार्य पूरा होने से पहले रुक जाता है।

तो, किसी भी एजेंट वर्कफ़्लो के लिए सवाल यह है कि क्या आपने पहले से तय किया है कि कॉन्टेक्स्ट विंडो में क्या जाता है, क्या एक सारांश के रूप में वापस आता है, और क्या कभी प्रवेश नहीं करता है। विकल्पों का वह सेट कॉन्टेक्स्ट इंजीनियरिंग है।

मॉडल चयन: Sonnet से शुरू करें, जानबूझकर आगे बढ़ें Claude मॉडल परिवार वर्तमान में चार स्तरों को फैलाता है: Fable, Opus, Sonnet, और Haiku, प्रत्येक विभिन्न लागत, लेटेंसी, और क्षमता ट्रेडऑफ्स के लिए अनुकूलित। Sonnet अधिकांश प्रोडक्शन वर्कलोड्स के लिए संतुलित डिफ़ॉल्ट है। Haiku गति और लागत दक्षता के लिए बनाया गया है उन कार्यों पर जो इसकी क्षमता लिफाफे में फिट होते हैं। Opus Sonnet लिफाफे के ऊपर मांग वाले काम को हैंडल करता है, और Fable Anthropic का सबसे सक्षम मॉडल है, जटिल तर्क, उन्नत कोडिंग, अनुसंधान संश्लेषण, और परिष्कृत एजेंटिक वर्कफ़्लो सहित सबसे मांग वाले कार्यों के लिए बनाया गया है जहां अधिकतम बुद्धिमत्ता प्राथमिकता है। बिल्ड समय पर platform. claude. com/docs के विरुद्ध वर्तमान लाइनअप और मॉडल पहचानकर्ताओं की पुष्टि करें।

डिफ़ॉल्ट शुरुआती बिंदु Sonnet है। केवल तब Opus तक जाएं जब एक eval सेट आपको बताए कि Sonnet आपकी गुणवत्ता बार को पूरा नहीं कर रहा है। केवल तब Haiku तक जाएं जब एक eval सेट आपको बताए कि गुणवत्ता प्रतिगमन आपके कार्य पर स्वीकार्य है, केवल लागत बचाने के लिए नहीं। आपकी मॉडल्स को स्थानांतरित करने का निर्णय हमेशा एक मापा निर्णय होना चाहिए।

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

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

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

रणनीतिइसे क्या करता हैकब लागू करेंआप किस निरंतरता को खो देते हैं

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

कॉम्पैक्शन (/compact Claude Code में; API में सर्वर-साइड कॉम्पैक्शन, एक बीटा रणनीति जो प्लेटफॉर्म आपके लिए करता है, मैनुअल सारांश के साथ क्लाइंट-साइड विकल्प के रूप में) बातचीत इतिहास को एक संघनित संस्करण में सारांशित करता है जो Claude ने सीखी मुख्य जानकारी को संरक्षित करता है। सारांश मूल टर्न्स की तुलना में कम टोकन खर्च करता है। जब सेशन कॉन्टेक्स्ट छत के पास पहुंच रहा हो लेकिन आप उसी सुविधा पर काम करना जारी रखना चाहते हैं जिसे Claude ने बनाया है। विवरण सारांश में खो सकते हैं। कुछ भी जो सारांश में कैप्चर नहीं किया गया है वह आगे Claude के लिए उपलब्ध नहीं होगा।

साफ करना (/clear Claude Code में; API में नया सेशन) एक नई बातचीत शुरू करता है खाली संदर्भ के साथ। पिछले सेशन से कुछ भी आगे नहीं बढ़ता है। जब अगला कार्य वर्तमान से पूरी तरह अलग हो, और पूर्व संदर्भ केवल पूर्वाग्रह या भ्रम का परिचय देगा। सभी सेशन संदर्भ चला गया है। कुछ भी Claude को सेशन्स के पार याद रखने की आवश्यकता है कहीं स्थायी रखना चाहिए, जैसे एक CLAUDE. md फाइल।

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

दो और लीवर: प्रॉम्प्ट कैशिंग और टोकन गणना ऊपर दी गई चार रणनीतियां प्रबंधित करती हैं कि कॉन्टेक्स्ट विंडो में क्या प्रवेश करता है। दो API सुविधाएं कम करती हैं कि आप जो पहले से वहां है उसके लिए क्या भुगतान करते हैं।

प्रॉम्प्ट कैशिंग आपके अनुरोध के एक स्थिर उपसर्ग पर किए गए प्रसंस्करण कार्य को संग्रहीत करता है ताकि अनुवर्ती अनुरोध इसे फिर से प्रसंस्करण करने के बजाय पुनः उपयोग कर सकें। पहला अनुरोध उपसर्ग को कैश में लिखता है; बाद के अनुरोध जो उस बिंदु तक समान सामग्री भेजते हैं मूल लागत का एक अंश भुगतान करते हैं। सबसे मजबूत उम्मीदवार अनुरोध के वे हिस्से हैं जो टर्न्स में शायद ही कभी बदलते हैं: एक लंबा सिस्टम प्रॉम्प्ट, एक बड़ी टूल परिभाषा सेट, या एक संदर्भ दस्तावेज़ जिसे आप बार-बार क्वेरी करते हैं। आप एक cache_control फील्ड के साथ एक cache breakpoint चिह्नित करके कैशिंग को सक्षम करते हैं जो अंतिम ब्लॉक पर ephemeral प्रकार का है जिसे आप कैश करना चाहते हैं। आप चार breakpoints तक रख सकते हैं। एक स्थिर सिस्टम प्रॉम्प्ट और टूल स्कीमा के साथ मल्टी-टर्न सेशन्स के लिए, उन उपसर्गों को कैश करना और टर्न्स के पार पुनः उपयोग करना उपलब्ध सबसे अधिक लीवरेज लागत में कमी है।

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

RAG पाथ के तीन स्थान जहां यह टूट सकता है पाथ के तीन स्थान हैं जहां यह गलत हो सकता है: चंकिंग, एम्बेडिंग मैच, और प्रॉम्प्ट में असेंबली।

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

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

असेंबली चरण वह है जहां पुनः प्राप्त चंक्स को प्रॉम्प्ट में उस संरचना में पहुंचना चाहिए जिसकी प्रॉम्प्ट अपेक्षा करता है, अन्यथा मॉडल मेमोरी से उत्तर देता है बजाय पुनः प्राप्त पाठ से।

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

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

अब, आइए दो सबसे आम रणनीतियों को समझते हैं: कॉम्पैक्शन और सबएजेंट हैंडऑफ्स।

कॉम्पैक्शन लागू करना: क्या संरक्षित है यह इस बात पर निर्भर करता है कि आप सारांशकार को कैसे लिखते हैं जब आप Claude Code में /compact का उपयोग करते हैं, तो टूल तय करता है कि सारांश में क्या शामिल करना है। API में, प्रलेखित प्राथमिक रणनीति सर्वर-साइड कॉम्पैक्शन (बीटा) है: प्लेटफॉर्म अनुरोध पर कॉन्फ़िगर किए जाने पर आपके लिए बातचीत को सारांशित करता है। जब आप इसके बजाय API सेशन में मैनुअल कॉम्पैक्शन लागू करते हैं, तो आप सारांशकार प्रॉम्प्ट स्वयं लिखते हैं। वह प्रॉम्प्ट यह निर्धारित करता है कि एजेंट बाद के टर्न्स में क्या जानता है।

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

यह एक एज केस नहीं है; एक अनिर्दिष्ट सारांशकार से कार्य-महत्वपूर्ण स्टेट हानि मल्टी-सेशन एजेंट विफलताओं के सबसे आम स्रोतों में से एक है।

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

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

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

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

स्क्रीन 14: सेशन जो विकास में ठीक चलता था, फिर प्रोडक्शन में एक छत को मारा

सावधानीकॉन्टेक्स्ट इंजीनियरिंग·5 मिनट सेशन जो विकास में ठीक चलता था, फिर प्रोडक्शन में एक छत को मारा

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

पोस्टमॉर्टम: कॉन्टेक्स्ट बजट को कभी प्रोडक्शन टूल आउटपुट्स के विरुद्ध मापा नहीं गया एक एजेंट को 40k कॉन्टेक्स्ट विंडो टोकन बजट के तहत बिक्री रसीदों को प्रसंस्करण करने के लिए बनाया गया था, एक कैप जो टीम ने एजेंट के कॉन्टेक्स्ट पर लागत नियंत्रण के रूप में सेट किया था बजाय मॉडल की छत के। मॉडल स्वयं बहुत अधिक कमरा प्रदान करता है। वर्तमान Claude API मॉडल्स कम से कम 200k-टोकन कॉन्टेक्स्ट विंडो ले जाते हैं, और नवीनतम फ्लैगशिप मॉडल्स, Fable सहित, डिफ़ॉल्ट रूप से 1M टोकन परोसते हैं, इसलिए 40k आंकड़ा एक जानबूझकर बजट था जो टीम ने लागू किया था, मॉडल द्वारा नहीं। विकास ने बीस रसीदों का एक टेस्ट फिक्सचर सेट का उपयोग किया, प्रत्येक लगभग 800 टोकन का एक टूल परिणाम लौटाता है। पूरा बीस-टर्न सेशन लगभग 18,000 टोकन खर्च करता है, टीम के 40k टोकन बजट सीमा के भीतर अच्छी तरह से।

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

विकासप्रोडक्शन उपलब्ध कॉन्टेक्स्ट विंडो200k मानक, 1M वर्तमान Opus और Sonnet पर200k मानक, 1M वर्तमान Opus और Sonnet पर टीम बजट कैप40k टोकन40k टोकन औसत टूल आउटपुट~800 टोकन प्रति कॉल~3,200 टोकन प्रति कॉल विंडो भरने से पहले टर्न्सबजट कैप तक पहुंचे बिना सेशन पूर्ण होते हैंकैप आठ टर्न पर पहुंचा देखी गई लक्षणकोई नहीं। सेशन्स साफ-सुथरे रूप से पूर्ण होते हैंआठ टर्न के बाद गलत टूल चयन और अधूरे आउटपुट शुरू होते हैं पहचाना गया मूल कारणलागू नहीं होता हैटोकन उपयोग ऑडिट, तैनाती के दो दिन बाद समाधानलागू नहीं होता हैटूल आउटपुट्स को उपयोग के बाद प्रूनड करें, और कैप तक पहुंचने से पहले सक्रिय रूप से कॉम्पैक्शन लागू करें।

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

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

स्क्रीन 15: चेकपॉइंट 5 · कॉन्टेक्स्ट विफलता का निदान करें

चेकपॉइंटकॉन्टेक्स्ट इंजीनियरिंग·3 मिनट चेकपॉइंट 5 · कॉन्टेक्स्ट विफलता का निदान करें नीचे दिया गया सेशन ट्रेस एक मल्टी-टर्न एजेंट रन को गिरते हुए टूल चयन के साथ दिखाता है। ट्रेस पढ़ें, पहचानें कि कौन सा टर्न विफलता को ट्रिगर किया, तंत्र का नाम दें, और नीचे दिए गए तीन विकल्पों से एक-पंक्ति समाधान चुनें।

सेशन ट्रेस प्रत्येक टर्न का निरीक्षण करने के लिए क्लिक करें।

टर्नटूल कॉल किया गयापरिणाम आकार 1fetch_policy_document, सही चयन2,400 टोकन 2fetch_policy_document, सही चयन2,400 टोकन 3fetch_policy_document, सही चयन2,400 टोकन 4fetch_policy_document, सही चयन2,400 टोकन 5search_knowledge_base के बजाय apply_coverage_rule, गलत चयन1,800 टोकन 6search_knowledge_base फिर से, गलत चयन (टर्न 5 के समान)1,800 टोकन 7सेशन परिणाम के बिना समाप्त होता हैN/A

टर्न 4fetch_policy_document, सही चयन, 2,400 टोकन। अंतिम सही टर्न। चार बड़े टूल परिणाम (9,600 टोकन) अब कॉन्टेक्स्ट विंडो में बैठे हैं, अगले टूल को कौन सा उपयोग करना है यह बताने वाले निर्देशों को भीड़ दे रहे हैं।

Aapply_coverage_rule टूल स्कीमा पर एक स्पष्ट विवरण जोड़ें।Bfetch_policy_document परिणामों को प्रत्येक टर्न के बाद प्रूनड करें ताकि जमा आउटपुट्स वर्तमान निर्देशों को भीड़ न दें, और टर्न 5 से पहले कॉम्पैक्शन लागू करें।Cअधिक कमरा देने के लिए API कॉल में max_tokens बढ़ाएं।

सबमिट करें अभी के लिए छोड़ें

स्क्रीन 16: एक प्रोडक्शन एजेंट बनाना: लूप, वायरिंग पाथ्स, ऑर्केस्ट्रेशन, और ह्यूमन-इन

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

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

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

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

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

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

तीन वायरिंग पाथ्स हैं, और वे कितने बुनियादी ढांचे पर आप स्वामित्व रखते हैं इसके एक स्पेक्ट्रम पर बैठते हैं। आप Messages API के विरुद्ध लूप को सीधे लिख सकते हैं, जो आपको पूर्ण नियंत्रण और पूर्ण जिम्मेदारी देता है। आप Agent SDK का उपयोग कर सकते हैं, जो आपकी अपनी प्रक्रिया के अंदर एक ही लूप चलाता है और आपको टूल निष्पादन, कॉन्टेक्स्ट प्रबंधन, और पुनरावृत्ति संरचना पहले से बनाई गई देता है। या आप Claude Managed Agents (वर्तमान में सार्वजनिक बीटा में) का उपयोग कर सकते हैं, जहां Anthropic लूप और सैंडबॉक्स चलाता है और आपका एप्लिकेशन इवेंट्स को स्ट्रीम करता है और परिणाम वापस करता है। अनुभाग जो अनुसरण करते हैं लूप को सिखाते हैं, क्योंकि लूप वह है जो स्थिर रहता है। आप जो पाथ चुनते हैं वह तय करता है कि इसके चारों ओर कितना आप बनाए रखते हैं।

वायरिंग पाथ्स: कौन लूप चलाता है, और आप क्या लेते हैं तीन पाथ्स एक चर में भिन्न होते हैं: आप एजेंट के रनटाइम का कितना स्वामित्व रखते हैं। तालिका ऊपर से नीचे तक कितने बुनियादी ढांचे को आप सौंपते हैं इसके क्रम में है। अपनी तैनाती और अनुपालन बाधाओं के आधार पर चुनें, केवल सबसे तेजी से प्रोटोटाइप करने के लिए प्रलोभन न दें।

Raw Messages API लूप Agent SDK Claude Managed Agents

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

कौन लूप चलाता है: SDK आपकी अपनी प्रक्रिया के अंदर लूप चलाता है। यह पुनरावृत्ति करता है और कॉन्टेक्स्ट को प्रबंधित करता है, और आपका कोड अभी भी एजेंट को कॉल करने वाले टूल्स को निष्पादित करता है। आप क्या स्वामित्व रखते हैं: टूल निष्पादन और आसपास का एप्लिकेशन। SDK लूप संरचना, कॉन्टेक्स्ट प्रबंधन, और टूल पंजीकरण प्रदान करता है। इसे कब चुनें: आप Claude Code को शक्ति देने वाले लूप, कॉन्टेक्स्ट हैंडलिंग, और टूल स्कैफोल्डिंग चाहते हैं बिना उन्हें फिर से बनाए, और आप एजेंट को अपने स्वयं के वातावरण में Python या TypeScript में चलाना चाहते हैं। प्रतिबद्ध करने से पहले क्या जांचें: क्या फाइलसिस्टम-आधारित सुविधाएं जैसे CLAUDE. md और कौशल Agent SDK में लोड होते हैं settingSources कॉन्फ़िगरेशन द्वारा नियंत्रित होता है। डिफ़ॉल्ट पर भरोसा न करें: हमेशा settingSources को स्पष्ट रूप से उन स्रोतों पर सेट करें जिनका आप इरादा रखते हैं (उदाहरण के लिए, ["user", "project", "local"] Claude Code CLI व्यवहार से मेल खाने के लिए, या [] पूरी तरह से अलग-थलग चलाने के लिए केवल जो आप प्रोग्रामेटिकली पास करते हैं)। बिल्ड समय पर Agent SDK संदर्भ के विरुद्ध वर्तमान डिफ़ॉल्ट व्यवहार की पुष्टि करें।

कौन लूप चलाता है: Anthropic लूप और सैंडबॉक्स चलाता है। आपका एप्लिकेशन उपयोगकर्ता इवेंट्स भेजता है और सर्वर-भेजे गए इवेंट्स पर परिणाम स्ट्रीम करता है। आप क्या स्वामित्व रखते हैं: एप्लिकेशन परत और एजेंट परिभाषा। आप मॉडल, सिस्टम प्रॉम्प्ट, टूल्स, MCP सर्वर्स, और कौशल एक बार परिभाषित करते हैं, फिर सेशन्स के पार एजेंट ID द्वारा संदर्भ देते हैं। इसे कब चुनें: आपको मिनट या घंटों में मापी गई लंबे-चलने वाली निष्पादन की आवश्यकता है, आप एक प्रबंधित सैंडबॉक्स चाहते हैं, या आप लूप, सैंडबॉक्स, और टूल-निष्पादन परत को बिल्कुल बनाने से बचना चाहते हैं। AWS पर Claude Platform पर भी उपलब्ध है कुछ सुविधा अंतर के साथ, प्रतिबद्ध करने से पहले अपनी तैनाती सतह के विरुद्ध क्षमता समानता सत्यापित करें। प्रतिबद्ध करने से पहले क्या जांचें: सेशन्स स्टेटफुल हैं और सर्वर-साइड संग्रहीत हैं, जिसका मतलब है कि वे वर्तमान में Zero Data Retention या एक HIPAA Business Associate Agreement के लिए पात्र नहीं हैं। (Anthropic API डेटा प्रतिधारण दस्तावेज़ देखें platform. claude. com पर, प्रकाशन पर सत्यापित करें।) वर्तमान में सार्वजनिक बीटा में, सभी एंडपॉइंट्स को managed-agents-2026-04-01 बीटा हेडर की आवश्यकता है और व्यवहार रिलीज़ के बीच परिष्कृत किए जा सकते हैं। एक माइग्रेशन योजना के साथ बनाएं।

Claude Managed Agents: कब उपयोग करें ऊपर की तालिका Managed Agents को तीसरे पाथ के रूप में सूचीबद्ध करती है। आइए उस पसंद को ठोस बनाएं क्योंकि कुछ वर्कलोड्स के लिए यह सही डिफ़ॉल्ट है।

यहां मुख्य अंतर है: एक raw लूप या Agent SDK के साथ, आपका कोड पुनरावृत्ति चलाता है। आप प्रत्येक अनुरोध भेजते हैं, टूल-यूज़ ब्लॉक्स पढ़ते हैं, टूल्स को चलाते हैं, और परिणामों को जोड़ते हैं। Managed Agents के साथ, Anthropic लूप और सैंडबॉक्स चलाता है। आपका एप्लिकेशन एजेंट को एक बार परिभाषित करता है (मॉडल, सिस्टम प्रॉम्प्ट, टूल्स, MCP सर्वर्स, कौशल), ID द्वारा संदर्भ देता है, उपयोगकर्ता इवेंट्स भेजता है, और सर्वर-भेजे गए इवेंट्स पर परिणाम स्ट्रीम करता है।

आप क्या स्वामित्व छोड़ते हैं, और इसके बजाय क्या लेते हैं

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

Managed Agents चुनें जब

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

बाधा जो इसे विनियमित कार्य के लिए तय करता है Managed Agent सेशन्स स्टेटफुल हैं और सर्वर-साइड संग्रहीत हैं। वह भंडारण कारण है कि ये सेशन्स वर्तमान में Zero Data Retention या एक HIPAA Business Associate Agreement के लिए पात्र नहीं हैं। तो, यदि आपके वर्कलोड में PHI है या एक ZDR आवश्यकता के तहत गिरता है, तो यह पाथ नियंत्रक बाधा के कारण नियम से बाहर है, भले ही यह परिचालन रूप से अच्छी तरह से फिट हो, और आप Agent SDK या एक कवर किए गए कॉन्फ़िगरेशन पर एक raw लूप के लिए रूट करते हैं। शासी बाधा सुविधा से पहले पाथ को चुनता है।

एक सामान्य प्रगति स्थानीय रूप से Agent SDK पर प्रोटोटाइप करना है, फिर प्रोडक्शन के लिए Managed Agents में जाना है। मुख्य एजेंट परिभाषा अवधारणात्मक रूप से ले जाता है। जो बदलता है वह प्रारूप है: Agent SDK कोड-स्तरीय और फाइलसिस्टम कॉन्फ़िगरेशन का उपयोग करता है, जबकि Managed Agents एजेंट को एक संस्करण किए गए API संसाधन के रूप में परिभाषित करता है। एक पुनः-अभिव्यक्ति चरण की अपेक्षा करें, सीधा निर्यात नहीं।

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

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

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

लूप वायरिंग चेकलिस्ट: पाथ की परवाह किए बिना इन्हें सत्यापित करें

#आइटमक्या सत्यापित करें 1टूल्स पंजीकृतहर टूल जिसे एजेंट को चाहिए हो सकता है पंजीकरण सूची में है। कोई अपंजीकृत टूल्स सिस्टम प्रॉम्प्ट में संदर्भित नहीं हैं। 2सिस्टम प्रॉम्प्ट स्कोप किया गयासिस्टम प्रॉम्प्ट कार्य और उपलब्ध टूल्स का नाम देता है। यह उन टूल्स का वर्णन नहीं करता है जिनके पास एजेंट नहीं है। यह उन टूल्स को छोड़ता नहीं है जिनके पास एजेंट है जिन्हें स्कोपिंग मार्गदर्शन की आवश्यकता है। 3टूल-यूज़ लूप लागू किया गयाआपका कोड Claude द्वारा जारी की गई हर tool_use ब्लॉक को हैंडल करता है और अगले सहायक टर्न से पहले प्रत्येक के लिए एक tool_result ब्लॉक लौटाता है। एक एकल सहायक टर्न से सभी tool_use ब्लॉक्स को एक साथ समाधान किया जाना चाहिए। 4HITL insertion बिंदु परिभाषितलूप में कम से कम एक बिंदु पर एक मानव-इन-द-लूप जांच है। नीचे दिए गए अनुभाग के लिए देखें कि प्रत्येक को कहां सम्मिलित करना है। 5निकास शर्तें परिभाषितलूप के पास एक स्पष्ट रोकने की कसौटी है जो Claude को स्वेच्छा से रुकने पर निर्भर नहीं करती है।

ह्यूमन-इन-द-लूप (HITL): insertion बिंदु और कब प्रत्येक लागू होता है एक ह्यूमन-इन-द-लूप चेकपॉइंट एजेंट निष्पादन को रोकता है और परिणामी कार्य से पहले एक मानव समीक्षा चरण में रूट करता है। वह प्रश्न जो यह निर्धारित करता है कि कहां एक को सम्मिलित करना है: यदि यह चरण मानव जांच के बिना चलता है तो सबसे खराब संभावित परिणाम क्या है?

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

टूल ऑर्केस्ट्रेशन: ओवर-टूलिंग और अंडर-टूलिंग एजेंट का राउटिंग व्यवहार दो चीजों द्वारा आकार दिया जाता है, जिसमें टूल्स का वर्णन कैसे किया जाता है और कितने टूल्स पंजीकृत हैं। बहुत अधिक टूल्स ओवरलैपिंग विवरण के साथ अस्थिर राउटिंग का उत्पादन करते हैं। बहुत कम टूल्स एजेंट को या तो एक पाथ को हॉलुसिनेट करने या एक अधूरा परिणाम लौटाने के लिए बाध्य करते हैं।

ओवर-टूलिंग प्रोडक्शन एजेंट्स में अधिक आम समस्या है। टीम्स हर टूल को पंजीकृत करती हैं जिसे वे "बस मामले में" चाहिए सकते हैं और खोजते हैं कि Claude का चयन गुणवत्ता टूल सतह बढ़ने के साथ गिरती है। कार्य के लिए आवश्यक न्यूनतम सेट के साथ शुरू करें और केवल तब टूल्स जोड़ें जब एक विशिष्ट क्षमता अंतर की पुष्टि की जाए।

जब एजेंट्स सही कॉल हैं क्या आप लेते हैं जब आप एक एजेंट का उपयोग करते हैं कब एक वर्कफ़्लो के बजाय चुनें

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

विनियमित डेटा बाधाएं आपकी डिलीवरी रूट और क्रेडेंशियल्स को सेट करती हैं इससे पहले कि आप पहली पंक्ति लिखें यदि आपके डेटा को विशिष्ट बाधाओं के साथ हैंडल किया जाना चाहिए (जैसे, वकील-क्लाइंट विशेषाधिकार, HIPAA, GDPR, FedRAMP, या एक आंतरिक डेटा-निवास नीति), वह बाधा तय करती है कि आपका कोड कौन सी एंडपॉइंट को कॉल करता है, कौन सी क्रेडेंशियल्स को ले जाता है, और कहां इसके लॉग्स उतरते हैं इससे पहले कि आप प्रॉम्प्ट्स, टूल्स, या मेमोरी के बारे में एक एकल डिज़ाइन निर्णय लें।

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

बाधाइसे कोड में क्या नियम करता हैआमतौर पर एक कोड समीक्षा से गुजरता है वकील-क्लाइंट विशेषाधिकारएक उपभोक्ता-ग्रेड Claude. ai सतह से कॉल्स जिन्हें फर्म अंत-से-अंत ऑडिट नहीं कर सकता। कोड पाथ्स जो विशेषाधिकार प्राप्त दस्तावेज़ सामग्री को किसी भी एंडपॉइंट को भेजते हैं जिसे फर्म विशेषाधिकार प्राप्त सामग्री के लिए अनुमोदित नहीं किया है, प्रॉम्प्ट या सिस्टम संदेश में संरचना की परवाह किए बिना।फर्म के अपने एप्लिकेशन के अंदर से सीधे API या SDK कॉल्स, SSO के माध्यम से प्रमाणित, एक फर्म-अनुमोदित LLM गेटवे के माध्यम से राउट किए गए पूर्ण अनुरोध और प्रतिक्रिया लॉगिंग के साथ। ध्यान दें कि Anthropic के मूल Compliance Conversation सामग्री (प्रॉम्प्ट्स, प्रतिक्रियाएं, और टूल कॉल पेलोड्स) डिफ़ॉल्ट रूप से सीधे API ट्रैफिक पर Anthropic द्वारा कैप्चर नहीं किए जाते हैं, इसलिए संगठन को एप्लिकेशन परत में बातचीत लॉगिंग लागू करना चाहिए और इसे एक अनुमोदित लॉग गंतव्य में राउट करना चाहिए। टूल कॉल्स और टूल परिणाम ऑडिट किए गए पाथ के अंदर रहते हैं। अंतिम लॉगिंग डिज़ाइन को अपने Anthropic खाता टीम के साथ पुष्टि करें। HIPAA (PHI हैंडलिंग)कोड जो Protected Health Information को किसी भी एंडपॉइंट या डिलीवरी रूट को भेजता है जो उपयोग में विशिष्ट कॉन्फ़िगरेशन के लिए एक Business Associate Agreement द्वारा कवर नहीं किया जाता है। यह किसी भी लॉगिंग या प्रतिधारण पाथ को शामिल करता है जिसे आपका कोड लिखता है जिसे समान BAA के तहत स्कोप नहीं किया गया है।सीधे API या SDK कॉल्स एक BAA-कवर किए गए कॉन्फ़िगरेशन पर। Anthropic के साथ BAA कवरेज पहली बार API एक्सेस के लिए व्यवस्थित किया जाता है, जो Anthropic एक समर्पित HIPAA-सक्षम संगठन को प्रावधान करता है जो अपने स्वयं के अंत पर सुविधा प्रतिबंध को लागू करता है। कवर किए गए कॉन्फ़िगरेशन को अपने Anthropic खाता टीम के साथ पुष्टि करें। एक विकल्प AWS Bedrock या GCP Vertex पर एक क्लाउड-मध्यस्थ रूट है पार्टनर के मौजूदा HIPAA-पात्र क्लाउड खाते पर। ध्यान दें: BAA Console, Workbench, बीटा सुविधाओं, या उपभोक्ता योजनाओं को कवर नहीं करता है। सभी API सुविधाएं BAA के तहत कवर नहीं हैं, कॉन्फ़िगर करने से पहले Anthropic के Implementation Guide में वर्तमान सुविधा पात्रता सूची सत्यापित करें। GDPR और डेटा निवास