हम गलत सिस्टम बना रहे हैं। ग़लती से नहीं, ग़लती से, ग़लती से, ग़लती से। पैटर्न हमेशा समान है. एक टीम एक बड़े भाषा मॉडल की जादू की खोज करती है. वे इसे एक पियथन स्क्रिप्ट में लपेटते हैं. वे इसे डेटाबेस, एपीआई गेटवे और ग्राहक सहायता लॉग तक पहुंच देते हैं. वे संदर्भ विंडो में तीन जीबी दस्तावेज़ डंप करते हैं क्योंकि "1 मिलियन टोकन" अंतहीन भंडारण की तरह लगते हैं. इसे ‘एजेंट’ कहा जाता है। वास्तव में, उन्होंने एक भगवान एजेंट का निर्माण किया है. एक मोनोलिटिक, सर्वज्ञ, विभेदित तर्क का ब्लॉब जो सीईओ, जेनेटर, और डेटाबेस व्यवस्थापक के रूप में एक ही समय में होने की कोशिश करता है। और असफल हो जाता है। यह मूर्खता है. यह भ्रमित हो जाता है. यह टोकन उपयोग में एक भाग्य खर्च करता है. लाटेनता तब तक बढ़ जाती है जब तक कि उपयोगकर्ता का अनुभव 1999 में एक कॉल-अप कनेक्शन की प्रतीक्षा करने की तरह महसूस नहीं करता है. जब यह टूट जाता है (और यह हमेशा टूट जाता है) तो इंजीनियर इसे डिबग नहीं कर सकते हैं क्योंकि तर्क कोड में नहीं है. यह त्वरित इंजीनियरिंग और संदर्भ प्रदूषण की एक संभावना गंध में है. मैंने पिछले वर्ष इन प्रणालियों को टूटने में बिताया है. समाधान बेहतर त्वरित नहीं है. यह एक बड़ा मॉडल नहीं है. समाधान वास्तुकला है. कोड और बेंचमार्क के साथ पूर्ण तकनीकी विश्लेषण → कोड और बेंचमार्क के साथ पूर्ण तकनीकी विश्लेषण → हम 1 मिलियन टोकन को अंतहीन रैम की तरह क्यों व्यवहार कर रहे हैं? एआई विकास में वर्तमान आर्थोडिक्स को "संदर्भ विंडो मिथक" द्वारा आकर्षित किया जाता है। हम एक झूठ बेच दिया गया है. झूठ यह है कि यदि आप एक मॉडल को पर्याप्त संदर्भ देते हैं, तो यह किसी भी समस्या को हल कर सकता है. विक्रेता "अंतिम संदर्भ" को अंतिम विशेषता के रूप में दबाते हैं. 128k. 1 मिलियन. 2 मिलियन टोकन. प्रभाव आकर्षक है. आर्किटेक्चर के बारे में चिंता न करें. डेटा क्यूरेज के बारे में चिंता न करें. बस इसे सब कुछ फेंक दें. मॉडल इसे समझ जाएगा. यह परमेश्वर एजेंट पैराडाइम के उभरने के लिए प्रेरित किया है। इस दुनिया के दृष्टिकोण में, एक "एजेंट" एक अद्वितीय इकाई है. यह अनुप्रयोग की पूरी स्थिति रखता है. इसमें पुस्तकालय में हर उपकरण तक पहुंच है. जब कोई उपयोगकर्ता एक प्रश्न पूछता है, तो भगवान एजेंट पूछताछ प्राप्त करता है, इसके विशाल संदर्भ को देखता है (जो ब्रह्मांड के पूरे इतिहास को शामिल करता है), और जवाब के लिए अपना रास्ता समझने की कोशिश करता है. यह प्रगति की तरह लगता है. यह एक अद्वितीय, जागरूक एआई के वैज्ञानिक कथा के सपने की तरह दिखता है. लेकिन उत्पादन में, यह एक बुरा सपना है। हम प्रभावी रूप से एक जूनियर डेवलपर्स को पूरे कोडबेस, कंपनी मैनुअल और कानूनी संग्रह को याद रखने के लिए कह रहे हैं, और फिर उन्हें 30 सेकंड में एक सीएसएस बग को ठीक करने के लिए कह रहे हैं। वे बग को ठीक नहीं करेंगे. उनके पास एक आतंक हमला होगा. मेरे एजेंट को 'मैं नहीं जानता' कहने के लिए $ 50 लागत क्यों है? भगवान एजेंट आर्किटेक्चर में दरारें किसी भी कोड को उत्पादन में धक्का देने के लिए दिखाई देती हैं. यह आमतौर पर चार तरीकों से प्रकट होता है. जितना अधिक जानकारी आप प्रदान करते हैं, उतना ही मॉडल महत्वपूर्ण बिट्स पर कम ध्यान देता है. यह सिर्फ एक भावना नहीं है. यह एक वास्तुकला दोष है. अनुसंधान से पता चलता है कि मॉडल लंबे संदर्भों के बीच से जानकारी प्राप्त करने के लिए संघर्ष करते हैं. क्यूरेट करने में विफल होने से, हम सक्रिय रूप से प्रदर्शन को नुकसान पहुंचाते हैं. हम ऐसे सिस्टम बनाते हैं जहां अपरिवर्तनीय दस्तावेजों का "आउट" उपयोगकर्ता के विशिष्ट इरादे के "सिग्नल" को दूर करता है. 1. Context Pollution (The Needle in the Haystack) प्रत्येक टोकन पैसे खर्च करता है. प्रत्येक टोकन को संसाधित करने में समय लगता है. एक भगवान एजेंट जो बातचीत के प्रत्येक दौर के लिए एक 50k टोकन संदर्भ को फिर से पढ़ता है, नकद को जला रहा है. यह गणनात्मक रूप से बर्बाद है. हम एक सुपर कंप्यूटर चला रहे हैं जो "हाँ" या "नहीं" का जवाब देता है क्योंकि हम इनपुट को फ़िल्टर करने में परेशान नहीं थे. 2. Latency and Cost जब एक भगवान एजेंट असफल होता है, तो यह क्यों असफल होता है? यह निर्देश था? खोज चरण? उपकरण आउटपुट? या यह दस्तावेज़ के पृष्ठ 405 से एक अपरिवर्तनीय पाठ के टुकड़े से विचलित हो गया था? आप एक निर्देश का परीक्षण नहीं कर सकते हैं जो बड़े पैमाने पर संदर्भ विंडो के परिवर्तनीय सूप के आधार पर अपने व्यवहार को बदलता है। 3. The Debugging Black Hole सब कुछ तक पहुंच के साथ एक एकल एजेंट एक सुरक्षा सपने है. यदि त्वरित इंजेक्शन काम करता है, तो हमलावर महल का मालिक है. वहाँ कोई बड़े पैमाने पर है. कोई "शून्य भरोसा" नहीं है क्योंकि वास्तुकला एक संभावना मॉडल में अधिकतम भरोसा पर भरोसा करता है। 4. The Governance Void क्या समाधान सिर्फ माइक्रोसेवेज़ (अब से) है? हाँ, यह है। आगे का रास्ता है और यह . Aggressive Context Curation Agentic Mesh हमें इसे छोटे, विशेषज्ञ, अत्यधिक प्रतिबंधित एजेंटों के एक नेटवर्क के साथ बदलना चाहिए जो मानकीकृत प्रोटोकॉल के माध्यम से संचार करते हैं। मेष आर्किटेक्चर में, कोई भी एजेंट सब कुछ नहीं जानता है। राउटर एजेंट जानता है कि इरादों को कैसे वर्गीकृत किया जाए। समर्थन एजेंट वापसी नीति को जानता है। कोडिंग एजेंट Python को जानता है। SQL एजेंट डेटाबेस योजना को जानता है। वे संदर्भ विंडो साझा नहीं करते हैं, वे संदेश साझा करते हैं। यह एक मोनोलिट से माइक्रोसेसिस तक का स्विच है। यह जटिलता को स्केल करने का एकमात्र तरीका है। जब सहायता एजेंट काम कर रहा है, तो उसे डेटाबेस योजना को जानने की आवश्यकता नहीं है। चलो कोड संरचना में अंतर देखते हैं। पुराने तरीके: भगवान तुरंत आज ज्यादातर लोग यही लिख रहे हैं. यह एक गड़बड़ी है. # GOD AGENT - ANTI-PATTERN # We dump everything into one system prompt. system_prompt = """ You are an omniscient AI assistant for Acme Corp. You have access to: 1. The User Database (Schema: users, orders, items...) 2. The Codebase (Python, React, TypeScript...) 3. The Company Handbook (HR policies, returns, holidays...) 4. The Marketing Style Guide Instructions: - If the user asks about SQL, write a query. - If the user asks for a refund, check the handbook policy then query the DB. - If the user asks for code, write Python. Current Context: {entire_rag_retrieval_dump} {last_50_messages} """ # Result: The model gets confused. # It tries to apply HR policies to SQL queries. # It hallucinates tables that don't exist. पिथन The New Way: एजेंटिक मेष यहाँ, हम तर्क को विभाजित करते हैं. राउटर काम नहीं करता है. यह प्रतिनिधि करता है. # MESH ARCHITECTURE - PATTERN # Step 1: The Router Agent # Its only job is to classify and route. It has NO domain knowledge. router_prompt = """ You are a routing system. Analyze the user input and route to the correct agent. Available Agents: 1. billing_agent (Refunds, invoices, payments) 2. tech_support_agent (Python, SQL, Bug fixes) 3. general_chat_agent (Casual conversation) Output JSON only: {"target_agent": "name", "reasoning": "string"} """ # Step 2: The Specialist Agent (Billing) # This agent loads ONLY when called. # It has zero knowledge of Python or SQL. billing_agent_prompt = """ You are a Billing Specialist. You handle refunds and invoices. Tools available: [stripe_api, invoice_db] Context: {user_transaction_history_only} {refund_policy_summary} """ पिथन क्या आप अंतर देखते हैं? SQL सिंटाक्स को hallucinate नहीं कर सकता क्योंकि यह नहीं जानता कि SQL क्या है. इसका ब्रह्मांड छोटा है. छोटे ब्रह्मांड hallucination-resistant हैं. billing_agent एजेंट वास्तव में hallucinating के बिना बात कैसे करते हैं? मैं बड़े तकनीकी फ्रेमवर्क के बारे में संदेहजनक रहा हूं. वे आमतौर पर ब्लोट जोड़ते हैं. मुझे कच्चे कोड पसंद है. लेकिन Google के एजेंट विकास किट (एडीके) और एजेंट-टू-एजेंट (ए 2 ए) प्रोटोकॉल अलग हैं। Google ने महसूस किया है कि अगर हम चाहते हैं कि एजेंट काम करें, तो उन्हें एक दूसरे के साथ सॉफ्टवेयर की तरह बात करने की आवश्यकता है, चैटबॉट की तरह नहीं। A2A प्रोटोकॉल यह खेल परिवर्तनक है। A2A प्रोटोकॉल एजेंटों को एक दूसरे के साथ खोजने और बात करने के लिए एक निर्माता तटस्थ मानक है. यह "एजेंट कार्ड" का उपयोग करता है. ये मानकीकृत JSON मेटाडेटा फ़ाइल हैं जो वर्णन करते हैं कि एक एजेंट क्या कर सकता है। इसे इस तरह से सोचें: { "agent_id": "billing_specialist_v1", "capabilities": ["process_refund", "check_invoice_status"], "input_schema": { "type": "object", "properties": { "transaction_id": {"type": "string"}, "user_intent": {"type": "string"} } }, "output_schema": { "type": "object", "properties": { "status": {"type": "string", "enum": ["success", "failed"]}, "refund_amount": {"type": "number"} } } } जेसन जब एक राउटर एजेंट को एक रिफंड को संसाधित करने की आवश्यकता होती है, तो यह एपीआई कॉल को भ्रमित करने की कोशिश नहीं करता है। , A2A के माध्यम से हाथ पकड़ता है, संरचित उपयोगिता भार पारित करता है, और संरचित प्रतिक्रिया की प्रतीक्षा करता है। billing_specialist यह मानक है. यह हमें एक बनाने की अनुमति देता है जहां विभिन्न टीमों के एजेंट, या यहां तक कि विभिन्न कंपनियों से, सहयोग कर सकते हैं। Agentic Mesh वर्तमान में, एक ओपनएआई एजेंट एक वर्टेक्स एआई एजेंट से बात नहीं कर सकता है. ए 2 ए के साथ, वे एक प्रोटोकॉल साझा करते हैं. वे बातचीत करते हैं. वास्तव में इसका क्या मतलब है एक मेष वास्तुकला को अपनाना हमारे निर्माण के बारे में सब कुछ बदलता है। आप एक संभावना जाल के लॉग को नहीं पकड़ सकते हैं. पारंपरिक निगरानी (लॉग, मीट्रिक, ट्रैक) पर्याप्त नहीं है. हमें जरूरत है हमें देखने की जरूरत है कि . राउटर ने बिलिंग एजेंट को क्यों भेजा? बिलिंग एजेंट ने अनुरोध क्यों अस्वीकार किया? हमें नेट में प्रत्येक नोड के लिए लागत और देरी का ट्रैक करने की आवश्यकता है. यदि आपके पास यह नहीं है, तो आप एक प्रणाली का निर्माण नहीं कर रहे हैं. आप एक कैसीनो का निर्माण कर रहे हैं. 1. Observability is Mandatory Agentic Observability रिसर्च चेन एक भगवान एजेंट मॉडल में, सुरक्षा एक बाइनरी स्विच है। . बिलिंग एजेंट रूटर एजेंट को अनिवार्य रूप से भरोसा नहीं करता है. यह उपयोगी भार की जाँच करता है. यह नीति की जाँच करता है. यह विस्फोट रेंज को सीमित करता है. 2. Zero Trust Security Zero Trust त्वरित इंजीनियरिंग एक स्वतंत्र अनुशासन के रूप में मर रहा है. इसे प्रतिस्थापित किया जा रहा है . पंप केवल एक फ़ंक्शन कॉन्फ़िगरेशन है. वास्तविक काम मार्गदर्शन तर्क, योजना परिभाषा, और संदर्भ क्यूरेशन रणनीति में है। 3. The End of "Prompt Engineering" System Engineering हमें दयालु संपादकों बनने की जरूरत है. लक्ष्य संदर्भ विंडो को भरना नहीं है. लक्ष्य इसे खाली करना है. हमें संपीड़न करने की जरूरत है. हमें सारांश करने की जरूरत है. हमें केवल अगले तुरंत चरण के लिए आवश्यक चीजों को इंजेक्ट करने की जरूरत है. यदि एक एजेंट को SQL लिखने के लिए नियुक्त किया जाता है, तो उसे योजना की आवश्यकता होती है. यह करता है कंपनी के मिशन की जरूरत है। 4. Aggressive Context Curation नहीं (यह स्पष्ट लगता है. हालांकि, मैं इसे 90% कोडबेस में अनदेखा करता हूं। पूरी तकनीकी विघटन पढ़ें → पूरी तकनीकी विघटन पढ़ें → TL;DR के लिए Scrollers देव एजेंट विफलता: संदर्भ विंडो को गड़बड़, उच्च लागत और असंभव डिबगिंग का कारण बनता है। चिंताओं को अलग करना: विशेष एजेंटों (बिलिंग, एसक्यूएल, चैट) का निर्माण करें जो एक चीज को अच्छी तरह से करते हैं। उपयोग प्रोटोकॉल: एजेंटों को संचार के माध्यम से करना चाहिए
