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

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

LangChain के पास इसके लिए सही सादृश्य है।
LLM को एक नए प्रकार के ऑपरेटिंग सिस्टम की तरह सोचें।
मॉडल CPU है — यह सोचने का काम करता है।
कॉन्टेक्स्ट विंडो RAM है — वह कार्यशील मेमोरी जहां वह सब कुछ रहता है जिसे मॉडल वर्तमान में देख और तर्क कर सकता है।
जिस तरह RAM भरने पर आपका कंप्यूटर धीमा हो जाता है, उसी तरह कॉन्टेक्स्ट विंडो भीड़भाड़ होने पर आपके एजेंट का तर्क क्षीण हो जाता है।
इसे कॉन्टेक्स्ट रॉट कहा जाता है।
Chroma ने 18 अत्याधुनिक मॉडलों — GPT-4.1, Claude 4, Gemini 2.5, Qwen3, और अन्य का मूल्यांकन करते हुए एक अध्ययन किया।
इनपुट लंबाई बढ़ने पर हर एक मॉडल का प्रदर्शन घट गया।
हार्ड लिमिट पर नहीं। उससे काफी पहले।
200K-टोकन विंडो वाला मॉडल 50K टोकन पर महत्वपूर्ण गिरावट दिखा सकता है।
गिरावट निरंतर है। कोई चट्टान नहीं है।
क्यों? ट्रांसफॉर्मर इस तरह काम करते हैं कि हर टोकन हर दूसरे टोकन पर ध्यान देता है — n-स्क्वेर्ड संबंध बनाता है। जैसे-जैसे संदर्भ बढ़ता है, मॉडल की उन सभी संबंधों को धारण करने की क्षमता कम होती जाती है।
और फिर "बीच में खो जाना" (Lost in the Middle) की समस्या है।
LLM एक U-आकार का ध्यान वक्र दिखाते हैं।
→ संदर्भ की शुरुआत: अच्छी तरह याद रहता है
→ संदर्भ का अंत: अच्छी तरह याद रहता है
→ बीच: काफी हद तक अनदेखा किया जाता है
शोधकर्ताओं ने 30+ प्रतिशत अंकों की सटीकता में गिरावट मापी जब प्रासंगिक जानकारी संदर्भ की शुरुआत से बीच में चली गई।
आपके मूल निर्देश — टूल आउटपुट के 50,000 टोकन के नीचे दबे हुए — प्रभावी रूप से गायब हो जाते हैं।
Claude Code उपयोगकर्ताओं ने पाया है कि आउटपुट गुणवत्ता कॉन्टेक्स्ट क्षमता के 40-60% पर घट जाती है। किसी भी हार्ड लिमिट से काफी पहले।
आपके एजेंट के संदर्भ में जगह के लिए वास्तव में क्या होड़ कर रहा है

7 श्रेणियां। सभी एक ही सीमित विंडो के लिए लड़ रही हैं।
1. सिस्टम प्रॉम्प्ट
एजेंट की पहचान। व्यवहार के नियम। नियंत्रण प्रवाह तर्क। विभिन्न कार्य प्रकारों के लिए निर्देश। एक एजेंट में, यह सिर्फ "मददगार बनो" नहीं है। यह पूरी आर्किटेक्चर को परिभाषित कर सकता है।
2. टूल परिभाषाएँ
एजेंट जिस भी टूल को कॉल कर सकता है, उसके लिए एक स्कीमा की आवश्यकता होती है जो बताती है कि वह क्या करता है, वह कौन से पैरामीटर लेता है, और इसका उपयोग कब करना है।
3. टूल कॉल परिणाम
हर टूल कॉल अपना आउटपुट संदर्भ में जोड़ता है। एक वेब पेज पुनर्प्राप्ति: 5,000-10,000 टोकन। एक फ़ाइल पढ़ना: समान। ये तेज़ी से जमा होते हैं।
4. पुनर्प्राप्त ज्ञान (RAG)
वेक्टर डेटाबेस से खींचे गए दस्तावेज़, खोज परिणाम, API प्रतिक्रियाएँ — एजेंट के निर्णयों को सूचित करने के लिए पुनर्प्राप्त की गई कोई भी चीज़।
5. वार्तालाप इतिहास
जो कुछ भी हुआ है उसका पूरा प्रतिलेख। उपयोगकर्ता संदेश, एजेंट प्रतिक्रियाएँ, तर्क, पिछले निर्णय। हर बारी के साथ रैखिक रूप से बढ़ता है।
6. मेमोरी
वर्तमान सत्र से अल्पकालिक मेमोरी। पिछले सत्रों से दीर्घकालिक मेमोरी — उपयोगकर्ता प्राथमिकताएँ, पिछले परिणाम, सीखे गए पैटर्न।
7. एजेंट की स्थिति
वर्तमान योजना, कार्य सूची, प्रगति संकेतक, स्क्रैचपैड नोट्स। वह मेटा-जानकारी जो ट्रैक करती है कि एजेंट एक बहु-चरणीय कार्य में कहाँ है।
सभी 7 एक ही विंडो के लिए प्रतिस्पर्धा कर रहे हैं।
कॉन्टेक्स्ट इंजीनियरिंग यह तय करना है कि क्या जीतता है।
4 मुख्य रणनीतियाँ
LangChain ने वह ढांचा प्रकाशित किया जो कॉन्टेक्स्ट इंजीनियरिंग की हर तकनीक को 4 श्रेणियों में व्यवस्थित करता है।
आप जो भी तकनीक कभी सीखेंगे, वह इनमें से किसी एक में फिट होगी।
लिखो। चुनो। संपीडित करो। अलग करो।

रणनीति 1 — लिखो (एजेंट भूल जाते हैं। उन्हें याद रखने का एक तरीका दें।)

जब किसी एजेंट का संदर्भ भर जाता है और संकुचित हो जाता है, तो वह जानकारी खो देता है।
यदि एजेंट ने ऐसा होने से पहले कुछ नहीं लिखा — तो वह जानकारी हमेशा के लिए खो जाती है।
लिखो का अर्थ है एजेंट को कॉन्टेक्स्ट विंडो के बाहर जानकारी बनाए रखने के तरीके देना।
तीन रूप:
स्क्रैचपैड
एजेंट को एक उपकरण दें जो उसे कार्य के दौरान नोट्स लेने दे। मध्यवर्ती निष्कर्ष। लिए गए निर्णय। वह जानकारी जिसकी उसे बाद में आवश्यकता होगी।
Anthropic ने एक "सोचो" (think) टूल बनाया — Claude के लिए समस्याओं पर काम करने का एक समर्पित स्थान।
tau-bench बेंचमार्क पर, इसने कुछ कार्यों पर प्रदर्शन में 54% तक सुधार किया।
नियम फ़ाइलें (Rules Files)
स्थायी प्रक्रियात्मक मेमोरी।
यदि आपने Claude Code का उपयोग किया है, तो आपने CLAUDE.md देखा होगा।
प्रत्येक सत्र की शुरुआत में लोड किए गए निर्देश — प्रोजेक्ट आर्किटेक्चर, परंपराएँ, टेस्ट कैसे चलाएँ, किन बातों का ध्यान रखना है।
एजेंट इसे हर बार पढ़ता है जब वह शुरू होता है।
यह कभी भी मूल बातें नहीं भूलता।
मेमोरी निष्कर्षण (Memory Extraction)
एजेंट तथ्यों, उपयोगकर्ता वरीयताओं और सीखे गए पैटर्न को सहेजता है ताकि वह उन्हें सत्रों के बीच पुनर्प्राप्त कर सके।
कॉन्टेक्स्ट विंडो के बाहर पूरी तरह से रहता है।
वह जानकारी जिसकी एजेंट को कल आवश्यकता होगी, कल आने पर वहाँ उपलब्ध रहती है।
रणनीति 2 — चुनो (एजेंट को सब कुछ मत दो। उसे वह दो जिसकी उसे अभी आवश्यकता है।)

40 उपकरणों, एक बड़े ज्ञानकोष और कई सत्रों के इतिहास वाला एजेंट यह सब एक साथ लोड नहीं कर सकता।
किसी को यह तय करना होगा कि इस चरण के लिए क्या प्रासंगिक है।
पारंपरिक RAG: सिस्टम तय करता है।
उपयोगकर्ता पूछता है → दस्तावेज़ पुनर्प्राप्त करें → प्रॉम्प्ट में डालें → हो गया।
स्थिर। एक शॉट। मॉडल की कोई राय नहीं।
एजेंटिक RAG: एजेंट तय करता है। वह अपनी ज़रूरत की चीज़ें खोजता है, क्वेरी को परिष्कृत करता है, टूल चुनता है, यह निर्धारित करता है कि उसके पास पर्याप्त जानकारी है या नहीं।
पुनर्प्राप्ति एक पुनरावृत्त प्रक्रिया के रूप में, न कि एक-शॉट पाइपलाइन।
यह मायने रखता है क्योंकि प्रत्येक चरण पर जो प्रासंगिक है वह बदलता है — और केवल एजेंट जानता है कि उसे आगे क्या चाहिए।
टूल चयन की समस्या वह है जो लोगों को सबसे अधिक परेशान करती है।
यदि आपके एजेंट के पास 40+ उपकरण हैं, तो कोई भी काम शुरू होने से पहले संदर्भ में संभावित रूप से 10,000 टोकन की टूल परिभाषाएँ बैठी होती हैं।
समाधान: टूल विवरणों पर RAG।
हर कॉल में सभी टूल परिभाषाओं को डंप करने के बजाय, वर्तमान चरण से प्रासंगिक केवल टूल को सतह पर लाने के लिए सिमैंटिक सर्च का उपयोग करें।
RAG-MCP नामक एक पेपर ने इसका परीक्षण किया।
टूल-चयन सटीकता: 14% → 43% (3x सुधार)। टोकन उपयोग: लगभग आधा कट गया।
Anthropic इसे हाइब्रिड रणनीति कहता है: पहले से आवश्यक संदर्भ लोड करें (जैसे CLAUDE.md), बाकी सब कुछ के लिए एजेंट को जस्ट-इन-टाइम पुनर्प्राप्ति करने दें।
मूल बातें पहले से लोड करें। बाकी को मांग पर पुनर्प्राप्त करें।
रणनीति 3 — संपीडित करो (संदर्भ जमा होता रहता है। अर्थ बनाए रखें, टोकन काटें।)

अच्छे चयन के बावजूद, संदर्भ जमा होता रहता है।
हर टूल कॉल, पुनर्प्राप्त दस्तावेज़ और निर्णय विंडो में बना रहता है।
कल्पना करें कि आपके एजेंट ने 20 टूल कॉल किए हैं।
संदर्भ: संचित टूल आउटपुट, वार्तालाप इतिहास, तर्क निशानों के 80,000 टोकन।
इसमें से अधिकांश अब प्रासंगिक नहीं है। एजेंट ने पहले ही उस पर कार्रवाई कर ली है।
लेकिन यह अभी भी वहाँ है, जगह ले रहा है, ध्यान को कम कर रहा है, लागत और विलंबता बढ़ा रहा है।
आप 3 बिंदुओं पर संपीड़ित कर सकते हैं।
जानकारी संदर्भ में प्रवेश करने से पहले:
→ पुनर्प्राप्ति से पहले बड़े दस्तावेज़ों को सुसंगत टुकड़ों में विभाजित करें
→ पुनर्क्रमित करें ताकि केवल सबसे उपयोगी टुकड़े ही अंदर आएं
→ मुख्य संदर्भ में प्रवेश करने से पहले टूल आउटपुट को चलते-फिरते सारांशित करें
जब एजेंट काम कर रहा हो:
→ वार्तालाप इतिहास का रोलिंग सारांश — लगातार अपडेट होता रहता है
→ लोकप्रिय हाइब्रिड: अंतिम 10 संदेशों को शब्दशः रखें + उससे पुराने सब कुछ का सारांश दें
→ हार्ड ट्रिमिंग: एक बार संदर्भ आकार सीमा तक पहुँचने पर पुराने संदेशों को हटा दें
→ Claude Code ऑटो-कॉम्पैक्शन: 95% क्षमता पर ट्रिगर होता है, स्वचालित रूप से पूर्ण प्रक्षेपवक्र का सारांश देता है
एजेंट द्वारा किसी चीज़ पर कार्रवाई करने के बाद:
→ टूल परिणाम सफाई: एक बार टूल परिणाम का उपयोग 15 कदम पहले हो जाने पर, इसे हटा दें
→ इसे एक-पंक्ति सारांश से बदलें या पूरी तरह से हटा दें
→ एजेंट को उस वेब पेज का पूरा टेक्स्ट नहीं चाहिए जो उसने 20 कदम पहले लाया था
लक्ष्य: टोकन गणना कम करना। वास्तव में क्या मायने रखता है, उसे संरक्षित करना।
रणनीति 4 — अलग करो (सबसे शक्तिशाली रणनीति। मल्टी-एजेंट सिस्टम को सक्षम बनाती है।)

लंबे एजेंट रन के साथ यहाँ गहरी समस्या है।
यह सिर्फ जगह नहीं है। यह संदूषण है।
शोध चरण के विस्तृत फ़ाइल खोज अभी भी संदर्भ में बैठे हैं जब एजेंट कोड लिखने की ओर बढ़ता है।
वह पुराना शोध संदर्भ अब शोर है। यह मॉडल को उस चरण के दौरान विचलित कर रहा है जहाँ उसे स्वच्छ कार्यान्वयन पर ध्यान केंद्रित करने की आवश्यकता है।
अलग करो का अर्थ है काम के विभिन्न हिस्सों को उनकी अपनी अलग कॉन्टेक्स्ट विंडो देना।
उप-एजेंट (Sub-agents)
एक मूल एजेंट एक केंद्रित उप-कार्य — "कोडबेस में सभी प्रमाणीकरण-संबंधित फ़ाइलों को खोजें" — को एक उप-एजेंट को सौंपता है।
उप-एजेंट अपनी स्वच्छ कॉन्टेक्स्ट विंडो में काम करता है।
जब वह वापस रिपोर्ट करता है, तो वह केवल एक संघनित सारांश लौटाता है।
सभी गड़बड़ खोज संचालन उप-एजेंट के संदर्भ में पृथक रहते हैं और कभी भी मूल को प्रदूषित नहीं करते।
स्टेट स्कीमा पृथक्करण (LangGraph का दृष्टिकोण)
एजेंट की स्थिति को डिज़ाइन करें ताकि विभिन्न फ़ील्ड विभिन्न प्रकार के संदर्भ को संग्रहीत करें।
LLM केवल वर्तमान चरण से प्रासंगिक फ़ील्ड देखता है।
टूल परिणाम एक "बैकस्टेज" फ़ील्ड में बैठते हैं — मॉडल के लिए तब तक अदृश्य जब तक स्पष्ट रूप से सतह पर नहीं लाया जाता।
अलग उप-एजेंटों को स्पिन किए बिना प्रत्येक चरण पर एजेंट क्या देखता है, इस पर सूक्ष्म-नियंत्रण।
पृथक्करण ही वह चीज़ है जो जटिल बहु-चरणीय वर्कफ़्लो को वास्तव में विश्वसनीय बनाती है।
अलग-अलग काम। अलग-अलग कॉन्टेक्स्ट विंडो। कोई संदूषण नहीं।
एजेंट के असफल होने के 4 तरीके (असफलता का नाम बताएं। इसे ठीक करें।)
Drew Breunig ने एजेंट संदर्भ बढ़ने पर चार अलग-अलग विफलता मोड की पहचान की।
आपने जो भी टूटा हुआ एजेंट देखा है, वह इनमें से किसी एक में आता है।

विफलता 1: कॉन्टेक्स्ट पॉइज़निंग (संदर्भ विषाक्तता)
एक भ्रम या त्रुटि संदर्भ में प्रवेश करती है।
एजेंट बाद के चरणों में बार-बार इसका संदर्भ देता है।
चरण 5 का खराब डेटा बाद के हर चरण में जुड़ता जाता है।
समाधान: टूल आउटपुट को संदर्भ में प्रवेश करने से पहले मान्य करें। किसी त्रुटि से उबरने के बाद, असफल-प्रयास इतिहास को संपीड़ित करें। जब केवल समाधान मायने रखता है, तो डेड-एंड डिबगिंग के 10 कदम दृश्यमान न छोड़ें।
━━━
विफलता 2: कॉन्टेक्स्ट डिस्ट्रैक्शन (संदर्भ विकर्षण)
संदर्भ इतना लंबा हो जाता है कि मॉडल हाल के इतिहास पर अत्यधिक निर्भर होने लगता है।
एक नई योजना बनाने के बजाय, यह बस हाल ही में जो किया उसे दोहराता है।
यह सोचना बंद कर देता है। यह दोहराने लगता है।
समाधान: आक्रामक रूप से सारांशित और छाँटें। तब भी जब आपके पास बड़ी कॉन्टेक्स्ट विंडो उपलब्ध हो। बड़ी विंडो का मतलब इसे भरना नहीं है।
━━━
विफलता 3: कॉन्टेक्स्ट कन्फ्यूज़न (संदर्भ भ्रम)
अनावश्यक सामग्री मॉडल को निम्न-गुणवत्ता वाले निर्णयों की ओर ले जाती है।
उत्कृष्ट उदाहरण: एक मॉडल 46 टूल दिए जाने पर एक बेंचमार्क में विफल हो रहा है — भले ही संदर्भ सीमा के भीतर अच्छी तरह से था — लेकिन केवल 19 टूल के साथ ठीक काम कर रहा था।
टूल संदर्भ में रखने के लिए बहुत अधिक नहीं थे।
वे मॉडल के स्पष्ट रूप से तर्क करने के लिए बहुत अधिक थे।
समाधान: गतिशील टूल प्रबंधन। वर्तमान चरण से प्रासंगिक केवल टूल को सतह पर लाने के लिए RAG-MCP का उपयोग करें। टूल सेट को वर्तमान चरण से मेल खाता रखें।
━━━
विफलता 4: कॉन्टेक्स्ट क्लैश (संदर्भ टकराव)
नई जानकारी पहले से संदर्भ में मौजूद किसी चीज़ का खंडन करती है।
सिस्टम प्रॉम्प्ट एक बात कहता है। एक पुनर्प्राप्त दस्तावेज़ कुछ अलग कहता है।
एजेंट विरोधाभास को सुलझा नहीं पाता। असंगत व्यवहार उत्पन्न करता है।
समाधान: एक स्पष्ट प्राधिकरण क्रम स्थापित करें। सिस्टम प्रॉम्प्ट > पुनर्प्राप्त तथ्य > वार्तालाप इतिहास। नई जानकारी को संदर्भ में इंजेक्ट करने से पहले मौजूदा संदर्भ के विरुद्ध मान्य करें। XML टैग और स्पष्ट शीर्षकों का उपयोग करें ताकि मॉडल को पता चले कि किस स्रोत पर भरोसा करना है।
एजेंट के लिए सिस्टम प्रॉम्प्ट कैसे लिखें (चैटबॉट नहीं। एजेंट।)

एक चैटबॉट सिस्टम प्रॉम्प्ट एक स्वर निर्धारित करता है।
"आप एक सहायक सहायक हैं। संक्षिप्त और मैत्रीपूर्ण रहें।"
एक एजेंट सिस्टम प्रॉम्प्ट आर्किटेक्चर को परिभाषित करता है।
यह नियंत्रण प्रवाह निर्दिष्ट करता है — कार्य प्रकारों तक कैसे पहुँचें, कौन से टूल का उपयोग कब करें, त्रुटियों पर क्या करें, कौन से सुरक्षा उपाय अपनाएँ।
यह एक स्वायत्त कर्मचारी के लिए नौकरी का विवरण लिखने के करीब है, न कि व्यक्तित्व प्रॉम्प्ट।
Anthropic इसे "सही ऊंचाई" पर लिखना कहता है।
बहुत अधिक निर्देशात्मक:"यदि उपयोगकर्ता बिलिंग का उल्लेख करता है और रिफंड का उल्लेख करता है और राशि $100 से अधिक है, तो टूल X को कॉल करें।" नाजुक। हर उस किनारे के मामले पर टूट जाता है जिसकी आपने कल्पना नहीं की थी।
बहुत अस्पष्ट:"मददगार बनें और उपयुक्त टूल का उपयोग करें।" एजेंट को कुछ नहीं देता। वह ठोस संकेतों के बिना अच्छे स्वायत्त निर्णय नहीं ले सकता।
सबसे उपयुक्त बिंदु:स्वायत्त व्यवहार का मार्गदर्शन करने के लिए पर्याप्त विशिष्ट। मॉडल को नई परिस्थितियों में निर्णय लागू करने के लिए पर्याप्त लचीला। मजबूत अनुमान। कठोर नियम नहीं।
व्यावहारिक सुझाव:
→ XML टैग या मार्कडाउन हेडर के साथ व्यवस्थित करें — पृष्ठभूमि, निर्देश, टूल मार्गदर्शन
→ न्यूनतम शुरू करें और विफलताओं पर पुनरावृति करें — हर किनारे के मामले का पहले से अनुमान लगाने की कोशिश न करें
→ न्यूनतम का मतलब छोटा नहीं है — एक जटिल एजेंट सिस्टम प्रॉम्प्ट हजारों टोकन का हो सकता है और यह ठीक है जब तक हर टोकन अपनी जगह कमाता है
→ कुछ-शॉट उदाहरणों का उपयोग करें — एजेंट को दिखाएँ कि अच्छा व्यवहार कैसा दिखता है, न कि हर नियम को शब्दों में समझाने की कोशिश करें
KV-कैश: कॉन्टेक्स्ट ऑर्डर की परवाह करने का $$$ कारण

अधिकांश एजेंट निर्माताओं को पता नहीं है कि यह मौजूद है।
जब आप LLM को टोकन भेजते हैं, तो मॉडल प्रत्येक टोकन के लिए कुंजी-मूल्य प्रतिनिधित्व की गणना करता है।
कम्प्यूटेशनल रूप से महंगा।
इसलिए इन्फ्रेंस प्रदाता इन प्रतिनिधित्वों को कैश करते हैं।
यदि आपके संदर्भ की शुरुआत — उपसर्ग — API कॉल के बीच समान रहती है, तो प्रदाता कैश की गई गणना का पुन: उपयोग करता है और केवल अंत में नए टोकन संसाधित करता है।
तेज़। सस्ता।
लेकिन यदि आप कॉल के बीच अपने संदर्भ के शुरुआती हिस्से को पुनर्व्यवस्थित या बदलते हैं — तो आप कैश को अमान्य कर देते हैं। प्रदाता शुरू से सब कुछ पुन: गणना करता है।
Claude Sonnet पर लागत अंतर:
→ कैश किए गए इनपुट टोकन: $0.30 प्रति मिलियन
→ बिना कैश किए गए इनपुट टोकन: $3.00 प्रति मिलियन
10x अंतर।
एक एजेंट के लिए जो प्रति कार्य 30-40 API कॉल करता है, यह तेज़ी से बढ़ता है।
KV-कैश दक्षता के लिए व्यावहारिक नियम:
→ स्थिर सामग्री संदर्भ के शीर्ष पर जाती है — सिस्टम प्रॉम्प्ट, टूल परिभाषाएँ, ऐसा कुछ भी जो बारी के बीच नहीं बदलता है
→ गतिशील सामग्री नीचे जाती है — वार्तालाप इतिहास, वर्तमान चरण, एजेंट की स्थिति
→ बातचीत के बीच में गतिशील रूप से टूल न जोड़ें और न हटाएं — यह कैश को अमान्य करता है
→ टूल हटाने के बजाय टूल मास्किंग का उपयोग करें — सभी टूल परिभाषाओं को उपसर्ग (कैश्ड) में स्थिर रखें, वर्तमान चरण के लिए अप्रासंगिक को केवल अनुपलब्ध के रूप में चिह्नित करें
वह वर्कफ़्लो जो 7 घंटे में 35,000 लाइन कोड शिप करता है

Dex Horthy (HumanLayer के CEO) ने इसे AI Engineer Code Summit में प्रस्तुत किया।
कथित तौर पर उनकी टीम ने इसका उपयोग एक बड़े Rust कोडबेस में एक 7-घंटे के सत्र में ~35,000 लाइन कोड शिप करने के लिए किया।
विधि: बारंबार जानबूझकर संघनन (Frequent Intentional Compaction)।
एजेंट के काम को चरणों में संरचित करें। प्रत्येक चरण एक संघनित आर्टिफैक्ट तैयार करता है। प्रत्येक नया चरण केवल उस आर्टिफैक्ट के साथ एक नई कॉन्टेक्स्ट विंडो से शुरू होता है।
हर समय जानबूझकर कॉन्टेक्स्ट विंडो के 40-60% से नीचे रहें।
चरण 1 — अनुसंधान
उप-एजेंट कोडबेस का पता लगाते हैं। फ़ाइलें पढ़ते हैं। डेटा प्रवाह का पता लगाते हैं। आर्किटेक्चर मैप करते हैं।
सभी गड़बड़ grep परिणाम और फ़ाइल सामग्री उप-एजेंट संदर्भों में रहती है। कभी भी मूल को स्पर्श न करें। (अलग करो)
आउटपुट: एक संघनित research.md — फ़ाइल पथ, फ़ंक्शन हस्ताक्षर, पैटर्न, समस्याएँ। (लिखो)
संदर्भ रीसेट: कच्चे शोध ने विंडो का 60-80% उपयोग किया। शोध आर्टिफैक्ट इसे 15-20% तक संपीड़ित करता है। (संपीडित करो)
चरण 2 — योजना
नई कॉन्टेक्स्ट विंडो। इसमें केवल शामिल है: शोध दस्तावेज़ + समस्या की परिभाषा।
एजेंट एक विस्तृत कार्यान्वयन योजना तैयार करता है।
यह सबसे महत्वपूर्ण मानव समीक्षा जांच बिंदु है।
यहाँ तर्क त्रुटियों को पकड़ें जहाँ उन्हें ठीक करना आसान और मुफ्त है। बाद में इसकी कीमत घंटों लगेगी।
चरण 3 — कार्यान्वयन
एक और ताज़ा कॉन्टेक्स्ट विंडो। इसमें केवल शामिल है: योजना।
एजेंट कदम दर कदम इसका पालन करता है।
जटिल कार्यों के लिए: एक progress.md ट्रैक करता है कि क्या पूरा हो चुका है और क्या बाकी है। (लिखो)
परिणाम: प्रत्येक चरण में एक स्वच्छ, केंद्रित एजेंट। कोई संदूषण नहीं। कोई कॉन्टेक्स्ट रॉट नहीं। कोई "लापरवाह चरण 20" नहीं।
सर्वश्रेष्ठ प्लेटफ़ॉर्म इसे अलग तरीके से कैसे संभालते हैं
Claude Code
हाइब्रिड पुनर्प्राप्ति। CLAUDE.md पहले से लोड होता है। glob और grep जैसे टूल जस्ट-इन-टाइम कोडबेस नेविगेशन को संभालते हैं।
95% पर ऑटो-कॉम्पैक्शन — आर्किटेक्चरल निर्णयों और सबसे हाल ही में एक्सेस की गई 5 फ़ाइलों को संरक्षित करता है।
जटिल उप-कार्यों के लिए उप-एजेंट उत्पन्न कर सकता है, प्रत्येक का अपना स्वच्छ संदर्भ होता है।
दर्शन: "सबसे सरल चीज़ करें जो काम करती है।" मॉडल को इस बारे में स्मार्ट रहने दें कि उसे क्या चाहिए और उसे खोजने के लिए उपकरण दें।
Manus
KV-कैश-जागरूक संदर्भ क्रम: स्थिर उपसर्ग, गतिशील प्रत्यय। टूल हटाना नहीं, मास्किंग।
अवलोकन संपीड़न पाइपलाइन — एजेंट के संदर्भ में प्रवेश करने से पहले हर टूल आउटपुट संसाधित किया जाता है।
स्थिति ट्रैकिंग के लिए लगातार कार्य सूची।
निकाले गए संदर्भ के लिए ओवरफ्लो मेमोरी के रूप में फ़ाइल सिस्टम।
स्केल के लिए बनाया गया। सैकड़ों हजारों उपयोगकर्ताओं की सेवा करना जहाँ दक्षता एक व्यवसाय-लागत की समस्या है।
ChatGPT Agent
दृश्य-प्रथम दृष्टिकोण। एजेंट GUI ब्राउज़र के साथ इंटरैक्ट करता है।
स्क्रीनशॉट को विज़ुअल स्नैपशॉट के रूप में संदर्भ में जोड़ा जाता है। मॉडल जो देखता है उस पर तर्क करता है।
विज़ुअल टोकन महंगे हैं इसलिए एजेंट स्क्रीनशॉट की संख्या के बारे में चयनात्मक है।
स्पष्ट रूप से प्रोग्राम करने के बजाय हजारों वर्चुअल मशीनों में इष्टतम टूल-उपयोग रणनीतियों को सीखने के लिए RL का उपयोग करता है।
Google ADK
सबसे सैद्धांतिक आर्किटेक्चरल दृष्टिकोण।
तीन डिज़ाइन सिद्धांत:
- भंडारण को प्रस्तुतीकरण से अलग करें — स्थायी स्थिति वह नहीं है जो प्रत्येक API कॉल में दिखाई देती है
- स्पष्ट परिवर्तन — नामित, क्रमबद्ध प्रोसेसर जो परीक्षण योग्य, रचनात्मक चरणों में संदर्भ को बदलते हैं
- डिफ़ॉल्ट रूप से संदर्भ का दायरा — प्रत्येक मॉडल कॉल केवल न्यूनतम आवश्यक जानकारी देखता है
प्रॉम्प्ट क्राफ्टिंग पर इंजीनियरिंग अनुशासन।
सार्वभौमिक एजेंट टर्न पाइपलाइन
हर गंभीर प्लेटफ़ॉर्म प्रति एजेंट टर्न एक ही 5-चरणीय लूप में परिवर्तित होता है:
→ संग्रह करें — उपयोगकर्ता इनपुट, वार्तालाप इतिहास, टूल आउटपुट, पुनर्प्राप्त दस्तावेज़, एजेंट की स्थिति
→ चुनें — इस चरण के लिए शेष टोकन बजट के भीतर क्या प्रासंगिक है
→ संपीडित करें — संदर्भ में फिट होने के लिए सारांशित, छाँटें या पुनर्गठित करें
→ व्यवस्थित करें — पहले स्थिर सामग्री (कैश), अंत में गतिशील सामग्री
→ इकट्ठा करें + कॉल करें — अंतिम संदर्भ → API कॉल → आउटपुट प्राप्त करें → लूप
यह वह लूप है जो आपके द्वारा उपयोग किए गए हर प्रोडक्शन एजेंट के अंदर चल रहा है।
इसे समझना ही उन निर्माताओं को अलग करता है जो विश्वसनीय एजेंट शिप करते हैं, उन निर्माताओं से जो सोचते हैं कि उनका एजेंट चरण 15 पर लापरवाह क्यों हो जाता है।
सारांश
कॉन्टेक्स्ट रॉट वास्तविक है और आपकी कॉन्टेक्स्ट सीमा से काफी पहले शुरू होता है।
4 रणनीतियाँ जो इसे ठीक करती हैं:
→ लिखो — जानकारी को संदर्भ के बाहर बनाए रखें ताकि एजेंट भूलें नहीं
→ चुनो — इस चरण के लिए केवल आवश्यक चीज़ें खींचें
→ संपीडित करो — टोकन काटें, अर्थ रखें, सक्रिय रूप से न कि प्रतिक्रियात्मक रूप से
→ अलग करो — अलग-अलग कामों के लिए अलग-अलग संदर्भ, कोई संदूषण नहीं
ध्यान देने के लिए 4 विफलता मोड:
→ विषाक्तता — खराब डेटा हर चरण के माध्यम से बढ़ता जाता है
→ विकर्षण — लंबा इतिहास एजेंटों को सोचने के बजाय दोहराने पर मजबूर करता है
→ भ्रम — बहुत अधिक टूल निर्णय की गुणवत्ता को कम करते हैं
→ टकराव — विरोधाभास असंगत व्यवहार उत्पन्न करते हैं
KV-कैश 10x लागत बचत के लायक है। स्थिर सामग्री को पहले रखें।
सबसे अच्छा वर्कफ़्लो: शोध → संघनित → योजना → संघनित → कार्यान्वित करें। हर चरण पर ताज़ा संदर्भ।
गंभीर एजेंट कार्य के लिए कॉन्टेक्स्ट इंजीनियरिंग वैकल्पिक नहीं है।
यही कार्य है।
यदि यह उपयोगी था:
→ इसे हर उस एजेंट निर्माता के साथ साझा करने के लिए रिपोस्ट करें जिसे आप जानते हैं
→ अधिक ऐसी प्रणालियों के लिए @sairahul1 को फॉलो करें जो आपके सोते समय काम करती हैं
→ इसे बुकमार्क करें — आप 4 रणनीतियों के ढांचे पर वापस आएंगे
मैं AI, उत्पाद बनाने और ऐसी प्रणालियों के बारे में लिखता हूँ जो वास्तव में काम करती हैं।





