क्या आपने कभी ऐसी स्थिति का सामना किया है?
एक ही Claude, एक ही GPT-4o—एक व्यक्ति इसका उपयोग करके 5 महीनों में 1 मिलियन लाइन कोड लिख देता है, जबकि दूसरा इसे दो घंटे तक भी स्थिर रूप से नहीं चला पाता।
मॉडल एक जैसे हैं, लेकिन परिणाम आसमान-ज़मीन का फर्क दिखाते हैं।
समस्या कहाँ है?
मैंने हाल ही में OpenAI, Anthropic, Martin Fowler और Phil Schmid के कई लेख पढ़े, और पाया कि वे सभी एक ही चीज़ के बारे में बात कर रहे हैं।
वे इसे Harness Engineering कहते हैं।
सीधे शब्दों में कहें, तो यह आपके Agent के लिए एक "ऑपरेटिंग सिस्टम" बनाना है।
पहले समझें कि Harness क्या है
Phil Schmid ने HuggingFace ब्लॉग पोस्ट में एक बढ़िया उदाहरण दिया है।
Agent सिस्टम को एक कंप्यूटर की तरह समझें।
मॉडल CPU है, जो कच्ची कंप्यूटिंग शक्ति प्रदान करता है। कॉन्टेक्स्ट विंडो RAM है, जो चीज़ों को अस्थायी रूप से संग्रहीत करती है। Agent उस पर चलने वाला एप्लिकेशन है।
तो, ऑपरेटिंग सिस्टम क्या है?
Harness ही ऑपरेटिंग सिस्टम है।
OS के बिना, सबसे शक्तिशाली CPU भी सिर्फ एक चिप है। आप चिप पर टाइप नहीं कर सकते।
इसी तरह, Harness के बिना, सबसे बुद्धिमान मॉडल भी सिर्फ एक चैट बॉक्स है। अगर आप इसे एक घंटे के लिए कोई जटिल कार्य सौंपते हैं, तो क्या होगा अगर यह कॉन्टेक्स्ट भूल जाए? इसे बेकार कोड लिखने से कौन रोकेगा? क्या होगा अगर यह गलती करे और उसे पता भी न चले?
ये ऐसी समस्याएँ नहीं हैं जिन्हें आप "स्मार्ट मॉडल पर स्विच करके" हल कर सकते हैं।
Martin Fowler ने एक बात कही जो मेरे दिमाग में बैठ गई: Harnesses भविष्य में "सर्विस टेम्पलेट्स" बन सकते हैं। जिस तरह आज आप एक नया प्रोजेक्ट सर्विस टेम्पलेट के साथ शुरू करते हैं, उसी तरह आप एक नया Agent Harness टेम्पलेट के साथ शुरू करेंगे।
मुझे लगता है कि यह भविष्यवाणी सच होने वाली है।
2026 में अचानक इसका विस्फोट क्यों हो रहा है?
क्योंकि मॉडल अब काफी मजबूत हो गए हैं।
2024 में, हर कोई इस बात पर प्रतिस्पर्धा कर रहा था कि किसका मॉडल ज्यादा स्मार्ट है। 2026 तक, शीर्ष मॉडलों के बीच का अंतर बहुत छोटा हो गया है। यदि आप Claude और GPT को एक ही समस्या देते हैं, तो उनके स्कोर में केवल कुछ अंकों का अंतर होता है।
लेकिन अगर आप उन्हें लगातार 8 घंटे काम करने दें, तो अंतर सामने आ जाता है।
यह अंतर मॉडल में नहीं है; यह उसके चारों ओर के "harness" में है।
OpenAI की Codex टीम के पास एक चौंकाने वाला आँकड़ा है। उन्होंने Codex का उपयोग करके एक पूरा उत्पाद बनाया—5 महीने, 1 मिलियन लाइन कोड, शून्य लाइन हाथ से लिखी। पूरी प्रक्रिया के दौरान, उन्होंने पाया कि बाधा अब "क्या मॉडल कोड लिख सकता है" नहीं रह गई थी।
बाधा यह थी कि क्या मनुष्य कोड की समीक्षा पर्याप्त तेज़ी से कर सकते हैं।
मॉडल की आउटपुट गति मानव समीक्षा गति से आगे निकल गई है। इस बिंदु पर, मॉडल को अनुकूलित करने का क्या फायदा? आपको समीक्षा प्रक्रिया, गुणवत्ता नियंत्रण और आर्किटेक्चरल बाधाओं को अनुकूलित करना चाहिए।
Harness यही करता है।
तीन स्तंभ
तो, Harness में वास्तव में क्या होता है?
इन लेखों को पढ़ने के बाद, मैंने पाया कि हालाँकि शब्दावली अलग-अलग है, तीन मुख्य स्तंभ हैं।
1. मूल्यांकन बंद-लूप (Evaluation Closed-Loop)
Anthropic इस पर सबसे अधिक जोर देता है।
मुख्य विचार सरल है: एक Agent स्वयं को ग्रेड नहीं दे सकता।
इसके बारे में सोचें: यदि कोई इंटर्न एक रिपोर्ट पूरी करता है और आप उससे पूछते हैं कि उसने कैसा किया, तो वह कहेगा "ठीक है।" आपको मूल्यांकन करने के लिए एक स्वतंत्र व्यक्ति की आवश्यकता है।
Anthropic इसे "Evaluation-Driven Development" कहता है। पहले परिभाषित करें कि "अच्छा करने" का क्या मतलब है, फिर Agent को इसे करने दें, और अंत में एक स्वतंत्र मूल्यांकक इसे स्कोर करे।
Evaluation-Driven Development, Agent संस्करण का TDD है। पहले टेस्ट लिखें, फिर कोड। सिवाय इसके कि यहाँ "टेस्ट" Agent के लिए हैं।
मूल्यांकक सिर्फ कोड नहीं देखता। वह वास्तव में उत्पाद को संचालित करता है—Playwright का उपयोग करके बटन क्लिक करना, फॉर्म भरना और टेस्ट चलाना—फिर स्पष्ट मानकों के आधार पर निर्णय लेता है।
यहाँ एक दिलचस्प मामला है।
Anthropic के Opus 4.5 ने एक फ्लाइट बुकिंग परीक्षण के दौरान बुकिंग नीति में एक खामी पाई, और मानक उत्तर से बेहतर समाधान खोजा।
लेकिन मूल्यांकक ने इसे "विफलता" के रूप में चिह्नित किया।
क्यों? क्योंकि मूल्यांकक को ऐसे रचनात्मक समाधान की उम्मीद नहीं थी। केवल एक मानक उत्तर था, और क्योंकि Agent ने एक बेहतर उत्तर खोजा, उसे दंडित किया गया।
यह कहानी दो बातें दिखाती है: पहला, Agent इतने स्मार्ट हैं कि वे ऐसे समाधान खोज सकते हैं जिनके बारे में मनुष्यों ने नहीं सोचा। दूसरा, मूल्यांकन लूप सिर्फ Agent की जाँच नहीं कर रहा है; यह स्वयं मूल्यांकन की भी जाँच कर रहा है। यदि आपका मूल्यांकक बहुत कठोर है, तो वह बाधा बन जाता है।
एक और डेटा बिंदु: Opus 4.5 ने शुरू में CORE-Bench पर 42% स्कोर किया। स्कोरिंग बग को ठीक करने और स्कैफोल्ड बाधाओं को ढीला करने के बाद, स्कोर 95% तक पहुँच गया।
अक्सर, ऐसा नहीं है कि मॉडल पर्याप्त अच्छा नहीं है; बल्कि आपके Harness में समस्या है।
इस विधि का उपयोग करके, Anthropic ने एक Agent को 6 घंटे में $200 में एक पूरा गेम बनाने दिया।
2. आर्किटेक्चरल बाधाएँ (Architectural Constraints)
यह OpenAI Codex टीम की विशेषता है।
आप एक इंटर्न से कहते हैं "कोड को लेयर्ड होना चाहिए," वे सिर हिलाते हैं, फिर तुरंत डेटाबेस लेयर में UI लॉजिक लिख देते हैं।
बात करना बेकार है।
OpenAI का दृष्टिकोण है इसे linters और CI के माध्यम से यांत्रिक रूप से लागू करना। आर्किटेक्चरल नियमों का उल्लंघन करने वाला कोड तुरंत अस्वीकार कर दिया जाता है, बिना समीक्षा के भी।
उनकी कोड लेयरिंग इस प्रकार है: Types → Config → Service → UI। प्रत्येक लेयर केवल अपने ऊपर वाली लेयर पर निर्भर हो सकती है, कभी उल्टा नहीं। यह नियम सिर्फ एक दस्तावेज़ में नहीं लिखा है; इसे स्वचालित जाँच के लिए linter में लिखा गया है।
इससे भी बेहतर, ये linters स्वयं Codex द्वारा उत्पन्न होते हैं।
Agent अपने स्वयं के नियम लिखता है और फिर उनका पालन करता है।
Martin Fowler ने OpenAI का लेख पढ़ने के बाद कहा:
"विश्वास और विश्वसनीयता बढ़ाने के लिए समाधान स्थान को प्रतिबंधित करने की आवश्यकता है। इसका मतलब है 'कुछ भी उत्पन्न करने' की लचीलापन का कुछ हिस्सा छोड़ना।"
जितनी अधिक बाधाएँ, उतनी अधिक विश्वसनीयता।
यह उल्टा लगता है, लेकिन डेटा बोलता है। LangChain ने एक प्रयोग किया: मॉडल को बदले बिना, केवल Harness बदलने पर Terminal Bench 2.0 पास दर 52.8% से बढ़कर 66.5% हो गई। Vercel ने और आगे बढ़ते हुए 80% Agent टूल्स हटा दिए, जिसके परिणामस्वरूप कम कदम, तेज़ गति और बेहतर परिणाम मिले।
कम टूल्स अक्सर बेहतर प्रदर्शन देते हैं—यह निष्कर्ष Agent क्षेत्र में बार-बार सत्यापित किया गया है।
3. मेमोरी गवर्नेंस (Memory Governance)
इस स्तंभ पर कम चर्चा होती है, लेकिन मुझे लगता है कि लंबे समय में यह सबसे महत्वपूर्ण है।
PrismerCloud ने इस दिशा में गहरा काम किया है।
समस्या यह है: जब कई Agent एक ज्ञानकोष साझा करते हैं, Agent A एक अनुभव लिखता है, और Agent B इसे सत्य के रूप में पढ़ता है। लेकिन क्या होगा अगर Agent A गलत था?
एक Agent का भ्रम (hallucination) साझा ज्ञानकोष के माध्यम से सभी Agentों को दूषित कर सकता है।
PrismerCloud का दृष्टिकोण एक "Evolution Engine" बनाना है। प्रत्येक Agent अनुभव को पहले एक "सिग्नल" के रूप में रिकॉर्ड किया जाता है। एक बार सत्यापित होने के बाद, सिग्नल को "जीन" में आसुत किया जाता है, जो वास्तविक परिणामों के आधार पर लगातार अनुकूलित होते हैं।
सीधे शब्दों में कहें, जीन सत्यापित, प्रभावी ज्ञान हैं। यदि सत्यापित नहीं है, तो यह मायने नहीं रखता।
एक दिलचस्प आँकड़ा है: 3 लाइन प्रॉम्प्ट और एक मेमोरी सिस्टम लगभग 200 लाइनों के सावधानीपूर्वक तैयार किए गए विशेषज्ञ प्रॉम्प्ट जितना ही अच्छा प्रदर्शन करता है। इसके अलावा, पहला विकसित होता है, जबकि दूसरा स्थिर रहता है।
इसका मतलब है कि यदि आपकी मेमोरी सिस्टम अच्छी है, तो आपको जटिल प्रॉम्प्ट की आवश्यकता नहीं है। Agent समय के साथ स्वाभाविक रूप से बेहतर होता जाएगा।
बोनस: एंट्रॉपी प्रतिरोध (Entropy Resistance)
यह एक अलग स्तंभ नहीं है, लेकिन इसका उल्लेख करना उचित है।
Agent सिस्टम समय के साथ स्वाभाविक रूप से क्षय होते हैं। दस्तावेज़ समाप्त हो जाते हैं, आर्किटेक्चर को दरकिनार कर दिया जाता है, और ज्ञानकोष पुरानी जानकारी से भर जाते हैं।
OpenAI का दृष्टिकोण समय-समय पर एक "Refactoring Agent" चलाना है जो दस्तावेज़ विसंगतियों और आर्किटेक्चरल उल्लंघनों को स्कैन करता है। उन्होंने इसे सबसे अच्छा कहा:
"जब कोई Agent संघर्ष करता है, तो हम इसे एक संकेत के रूप में मानते हैं: पता लगाएं कि क्या गायब है, इसे कोडबेस में वापस फीड करें, और हमेशा Codex को फिक्स लिखने दें।"
जब किसी Agent में समस्या हो, तो सिर्फ Agent को ठीक न करें—Harness को ठीक करें। यह मानसिकता महत्वपूर्ण है।
यह कौन कर रहा है?
यह क्षेत्र दो पथों में विभाजित है: ओपन-सोर्स प्रोजेक्ट जिनका आप आज उपयोग कर सकते हैं, और वाणिज्यिक कंपनियों की आंतरिक प्रथाएँ जहाँ से आप केवल पद्धति सीख सकते हैं।
ओपन सोर्स प्रोजेक्ट: उपयोग के लिए तैयार
LangChain DeepAgents: संभवतः "यूनिवर्सल Claude Code" के सबसे करीब ओपन-सोर्स प्रोजेक्ट। प्लानिंग, फ़ाइल ऑपरेशन, सब-एजेंट डेलिगेशन, ऑटोमैटिक कॉन्टेक्स्ट कम्प्रेशन—बॉक्स से बाहर तैयार। GitHub पर 115k स्टार्स।
DeerFlow 2.0: ByteDance से। मार्च में ओपन-सोर्स किया गया, एक महीने में 39k स्टार्स मिले। यह खुद को "SuperAgent Harness" कहता है। यह v1 से पूरी तरह से फिर से लिखा गया है जिसमें सैंडबॉक्स निष्पादन, स्थायी मेमोरी और LangGraph पर आधारित स्किल सिस्टम है।
OpenHands: कोडिंग Agentों के लिए विशेष। SWE-bench Verified पर 77.6% हासिल किया। यह मॉडल-अज्ञेयवादी है और Laminar का उपयोग करके अवलोकन (observability) करता है, प्रत्येक Agent क्रिया को ट्रेस करता है।
SWE-agent: प्रिंसटन और स्टैनफोर्ड से। यह "evaluation-driven" विकास को पूर्ण करने पर केंद्रित है।
Goose: Block (Square/Cash App) द्वारा ओपन-सोर्स किया गया। एक सामान्य ऑन-मशीन Agent जो निर्भरताएँ स्थापित कर सकता है, टेस्ट चला सकता है और फ़ाइलों का प्रबंधन कर सकता है।
PrismerCloud: मेमोरी गवर्नेंस और इवोल्यूशन इंजन पर केंद्रित। मल्टी-एजेंट सिस्टम में भ्रम प्रदूषण को रोकने के लिए यह सबसे परिपक्व समाधान है।
Cognee: Agentों के लिए एक नॉलेज-ग्राफ-संचालित मेमोरी इंजन जो डेटा के बीच सिमैंटिक कनेक्शन स्थापित करने में मदद करता है।
वाणिज्यिक प्रथाएँ: पद्धति सीखें
Claude Code + Agent SDK: एक सामान्य Harness के लिए Anthropic का बेंचमार्क। यह सिर्फ कोडिंग के लिए नहीं है; वे इसका उपयोग शोध, वीडियो निर्माण और नोट लेने के लिए करते हैं।
OpenAI Codex: आर्किटेक्चरल बाधाओं में अंतिम अभ्यास। 1 मिलियन लाइन कोड बिना हाथ से लिखे, ऑटो-जनरेटेड linters और Agent पीयर रिव्यू पर निर्भर।
एक सबक जो मेरे साथ अटक गया
Rich Sutton ने "The Bitter Lesson" नामक एक क्लासिक पेपर लिखा था। सार यह है कि कम्प्यूटेशन का लाभ उठाने वाली सामान्य विधियाँ हमेशा लंबे समय में मानव-डिज़ाइन की गई विशिष्ट विधियों को मात देती हैं।
यह सबक Agent क्षेत्र में फिर से साबित हो रहा है।
Manus ने 6 महीनों में अपने Harness को 5 बार रीफैक्टर किया। LangChain ने एक वर्ष में 3 बार री-आर्किटेक्ट किया। Vercel ने अपने 80% टूल्स हटा दिए।
डिलीट करने के लिए बनाएँ (Build to Delete)।
आपका आज का "चतुर लॉजिक" कल मॉडल अपग्रेड होने पर अप्रचलित हो सकता है। आपका आर्किटेक्चर मॉड्यूलर होना चाहिए और स्क्रैप करने के लिए तैयार रहना चाहिए।
Phil Schmid ने एक बात कही जो याद रखने लायक है:
"प्रतिस्पर्धात्मक लाभ अब प्रॉम्प्ट नहीं है; यह आपके Harness द्वारा कैप्चर किए गए ट्रैजेक्टरीज़ (trajectories) हैं। हर सफलता और विफलता अगली पीढ़ी को प्रशिक्षित करने के लिए डेटा है।"
आपका Harness जितनी देर चलेगा और जितनी अधिक ट्रैजेक्टरीज़ जमा करेगा, आपका Agent उतना ही मजबूत होगा। आप सिर्फ मॉडल बदलकर पकड़ नहीं सकते।
तीन चरण
AI इंजीनियरिंग में Harness के स्थान को इस प्रकार समझें।
Prompt Engineering "क्या कहना है" हल करता है। एक एकल इंटरैक्शन।
Context Engineering "क्या जानना है" हल करता है। संदर्भ और इतिहास प्रदान करना।
Harness Engineering "लगातार, स्थिर और बड़े पैमाने पर कैसे काम करना है" हल करता है। मूल्यांकन लूप गुणवत्ता सुनिश्चित करते हैं, आर्किटेक्चरल बाधाएँ नियम सुनिश्चित करती हैं, और मेमोरी गवर्नेंस अनुभव संचय सुनिश्चित करती है।
Harness के बिना, एक Agent चीज़ें याद रख सकता है लेकिन उसकी कोई निगरानी नहीं होती, जिससे अराजकता होती है। जब तीनों परतें मौजूद हों, तो आपके पास एक ऐसा चरित्र होता है जो वास्तव में दीर्घकालिक रूप से काम कर सकता है।
OpenAI, Anthropic और LangChain पहले से ही ऐसा कर रहे हैं।
स्रोत: OpenAI Harness Engineering, Anthropic Demystifying Evals, Phil Schmid (HuggingFace) The Importance of Agent Harness in 2026, Martin Fowler Harness Engineering, LangChain Agent Frameworks.
