तुलना

Harness vs context engineering: harness engineering prompt और context engineering से कैसे अलग है

अपडेट किया गया: 12.10.2026 · Skillaria.Top

Prompt engineering एक अनुरोध के शब्दों को सुधारता है, context engineering तय करता है कि हर कदम पर मॉडल की window में कौन-सी जानकारी जाए, और harness engineering पूरा एजेंट-वातावरण बनाता है: निर्देश, उपकरण, वातावरण, स्थिति और फ़ीडबैक। पहले दो एक मॉडल-कॉल के भीतर काम करते हैं, जबकि harness पूरे सिस्टम और लंबे कामों पर लागू होता है, जहाँ लक्ष्य जवाब नहीं बल्कि सत्यापित परिणाम है।

संक्षेप में: एक ही काम के तीन स्तर

Prompt engineering सवाल का जवाब देता है "कैसे पूछें", context engineering "मॉडल को अभी क्या जानना चाहिए", और harness engineering "एजेंट किस वातावरण में काम करता है और उसे कैसे पता चलता है कि उसने गलती की"। ये तीन प्रतिस्पर्धी तरीक़े नहीं, बल्कि एक-दूसरे के भीतर बैठे स्तर हैं: अच्छा prompt अच्छे context का हिस्सा है, और सोच-समझकर बना context harness के चार-पाँच हिस्सों में से एक है।

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

Prompt engineering: एक अनुरोध का शब्द-संयोजन

Prompt engineering अनुरोध के टेक्स्ट पर काम है: भूमिका, कार्य, उत्तर का फ़ॉर्मेट, उदाहरण (few-shot), सीमाएँ, कदमों का क्रम। काम की इकाई एक मॉडल-कॉल है। नतीजा उत्तर से परखा जाता है: सही है या नहीं, सही फ़ॉर्मेट में है या नहीं, मॉडल भटका तो नहीं।

आम तकनीकें:

आउटपुट का फ़ॉर्मेट साफ़ लिखें (JSON schema, तालिका, सूची);
2 से 3 उदाहरण दें: "इनपुट → सही आउटपुट";
उत्तर से पहले कदम-दर-कदम सोचने को कहें;
निर्देश और डेटा को स्पष्ट सीमांकक से अलग करें;
बताएँ कि क्या नहीं करना है।

Prompt engineering "एक इनपुट — एक उत्तर" वाले कामों में अच्छा चलता है: वर्गीकरण, जानकारी निकालना, अनुवाद, टेम्पलेट से टेक्स्ट बनाना। इसकी सीमा तब दिखती है जब मॉडल काम करने लगता है: उपकरण चलाना, फ़ाइलें बदलना, दर्जनों कदम एक के बाद एक। वहाँ गुणवत्ता एक वाक्य पर नहीं, बल्कि उस पूरे वातावरण पर निर्भर करती है जो मॉडल को घेरे है।

Context engineering: model window में क्या जाता है

Context engineering हर कदम पर context window की सामग्री का प्रबंधन है। Window सीमित है, और लंबे सत्र में एजेंट कमांड का आउटपुट, फ़ाइलों की सामग्री और बातचीत का इतिहास जमा करता है। काम यह है कि हर पल वहाँ ज़रूरी चीज़ हो और बेकार चीज़ न हो।

इसमें आते हैं:

चयन: कौन-सी फ़ाइलें, दस्तावेज़ और code-फ़्रैगमेंट काम के हिसाब से लोड करने हैं (search, RAG, ज़रूरत पर पढ़ना);
संक्षेपण: लंबे इतिहास का सार, कमांड आउटपुट की कटौती, सत्र का compaction;
संरचना: प्रवेश फ़ाइल विषय-सूची की तरह, और विवरण अलग दस्तावेज़ों में जिन्हें एजेंट ज़रूरत पर खोलता है;
अलगाव: किसी उप-काम को अपने साफ़ context वाले subagent को सौंपना, ताकि मुख्य धारा न भरे।

Context engineering की माप यह है: क्या एजेंट ने सही नियम या तथ्य सही समय पर पाया, और क्या वह शोर में डूबा तो नहीं। विशिष्ट लक्षण: नियम CLAUDE.md में लिखा है, पर एजेंट उसे तोड़ता है, क्योंकि फ़ाइल पाँच पन्नों की है और नियम बाक़ी सामग्री में खो गया।

Harness engineering: मॉडल के चारों ओर सब कुछ

Harness ("साज़-सामान") वह वातावरण है जिसमें एजेंट काम करता है। मॉडल उसमें एक घटक है जो चक्र में एक बार आता है। बाक़ी सब कुछ, यानी निर्देश, उपकरण, वातावरण, स्थिति और फ़ीडबैक, इंजीनियर डिज़ाइन करता है। Harness engineering यह सुनिश्चित करता है कि एजेंट केवल कोड न लिखे, बल्कि उसे चलाए, जाँचे, अपनी गलती जाने और अगले सत्र में उसी जगह से आगे बढ़े।

हार्नेस को पाँच हिस्सों में बाँटना उपयोगी है:

हिस्सा	इसमें क्या है	टूटने का लक्षण
निर्देश	AGENTS.md / CLAUDE.md, skills, दस्तावेज़, ADR	एजेंट वे परंपराएँ तोड़ता है जिन्हें "सब जानते हैं"
उपकरण	shell, टेस्ट, linter, debugger, ब्राउज़र, MCP सर्वर	एजेंट "करना चाहता है, कर नहीं सकता": ज़रूरी कमांड की पहुँच नहीं
वातावरण	dependency lock files, runtime के संस्करण, Docker/devcontainer, git worktree, sandbox	हर सत्र वातावरण ठीक करने से शुरू होता है
स्थिति	PROGRESS.md, feature_list.json, DECISIONS.md, git इतिहास	नया सत्र नहीं जानता कि कहाँ रुके थे
फ़ीडबैक	make check, E2E टेस्ट, hooks, rubrics, स्वतंत्र मूल्यांकक	"तैयार" और वास्तविकता मेल नहीं खाती

इस योजना में context engineering पहले दो हिस्सों के भीतर रहता है: वह तय करता है कि निर्देश और उपकरणों का आउटपुट window में कैसे आए। हार्नेस वह जोड़ता है जो context में समाता ही नहीं: काम करने वाली जाँच की कमांड, दोहराने योग्य वातावरण, स्थिति की फ़ाइल जो restart के बाद भी बचे।

तुलना की तालिका

मानदंड	Prompt engineering	Context engineering	Harness engineering
काम की इकाई	एक अनुरोध	हर कदम पर मॉडल की window	पूरा सिस्टम: एजेंट, रिपॉज़िटरी, वातावरण, प्रक्रियाएँ
क्या बदलता है	अनुरोध का टेक्स्ट	window में जानकारी का मिश्रण और क्रम	उपकरण, वातावरण, स्थिति का भंडारण, जाँचें
समय सीमा	सेकंड	एक सत्र	कई सत्र, घंटे और दिन
क्या मापते हैं	उत्तर की गुणवत्ता	एजेंट को सही चीज़ मिली या नहीं, window भरी तो नहीं	कितने काम सचमुच चालू अवस्था तक पहुँचे; "तैयार" और जाँच के बीच का अंतर
आम कलाकृतियाँ	system prompt, उदाहरण	दस्तावेज़ों की संरचना, RAG, compaction, subagents	AGENTS.md, जाँच की स्क्रिप्ट, hooks, Docker, feature_list.json, PROGRESS.md
परिणाम कौन जाँचता है	इंसान उत्तर पढ़ता है	इंसान या मॉडल	मशीन: टेस्ट, linter, E2E, स्वतंत्र मूल्यांकक
सीमा कब आती है	जब मॉडल काम करने लगे	जब एजेंट को ज्ञान नहीं, क्षमता की कमी हो	जब काम में इंसान का फ़ैसला चाहिए (उत्पाद, जोखिम)

सिर्फ़ prompt और context क्यों काफ़ी नहीं

एक क्लासिक कहानी: टीम देखती है कि एजेंट गलतियाँ करता है, और एक हफ़्ता पाँच पन्नों की AGENTS.md लिखने में लगाती है। फिर भी एजेंट commit से पहले linter नहीं चलाता। कारण टेक्स्ट में नहीं है: एजेंट के पास सही अधिकारों वाला shell नहीं है, और linter image में इंस्टॉल ही नहीं है। यह उपकरण और वातावरण की समस्या थी, जिसका इलाज निर्देशों से किया जा रहा था।

दूसरी कहानी: एजेंट लगातार तीसरे सत्र में वही बग ठीक करने की कोशिश कर रहा है, क्योंकि restart के बाद उसे याद नहीं कि उसने पहले क्या आज़माया। सत्र के भीतर context engineering इसमें मदद नहीं करेगा, क्योंकि window साफ़ हो जाती है। चाहिए स्थिति का हिस्सा: एक फ़ाइल जिसमें एजेंट प्रयास और फ़ैसले लिखता है, और नियम कि काम शुरू करने से पहले उसे पढ़ा जाए।

तीसरी कहानी सबसे महँगी है: एजेंट "तैयार" लिखता है, unit tests हरे हैं, पर फ़ीचर काम नहीं करता। न "ध्यान से जाँचो" वाला prompt, न window में ज़्यादा दस्तावेज़ एजेंट को स्वतंत्र जाँच दे सकते हैं। यह केवल मशीन के फ़ीडबैक से आती है: end-to-end टेस्ट, सत्यापन की स्क्रिप्ट, या एक अलग मूल्यांकक जिसे काम करने वाले के तर्क नहीं दिखते।

सामान्य निष्कर्ष: prompt और context इस पर असर डालते हैं कि मॉडल क्या सोचता है। हार्नेस इस पर असर डालता है कि मॉडल क्या कर सकता है और कार्रवाई के बाद क्या जानता है।

मॉडल बदलना क्यों हल नहीं है

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

हार्नेस नए मॉडलों के आने से पुराना नहीं होता। निर्देश, दोहराने योग्य वातावरण और जाँचें हर मॉडल को चाहिए। बदलता बस यह है कि कितना हाथ से निर्देश देना ज़रूरी है: मज़बूत मॉडल को invariants काफ़ी हैं ("डेटा सीमा पर validate हो"), चरण-दर-चरण आदेश नहीं।

किस स्तर को ठीक करना है, यह कैसे पहचानें

लक्षणों से निदान प्रयोगों से तेज़ है:

लक्षण	समस्या कहाँ है	क्या करें
उत्तर ग़लत फ़ॉर्मेट में, मॉडल ने कार्य नहीं समझा	Prompt	फ़ॉर्मेट स्पष्ट करें, उदाहरण जोड़ें
नियम लिखा है, पर एजेंट लागू नहीं करता	Context / निर्देश	प्रवेश फ़ाइल को विषय-सूची तक सीमित करें, विवरण ज़रूरत पर दस्तावेज़ों में रखें, ज़रूरी नियम को जाँच में बदलें
सत्र के बीच एजेंट शुरुआती फ़ैसले "भूल" जाता है	Context	Compaction, बगल के काम के लिए subagents, स्थिति की फ़ाइल में लिखना
एजेंट कहता है "मैं चला नहीं सकता"	उपकरण	कमांड की पहुँच, MCP सर्वर, अनुमतियाँ
सत्र वातावरण इंस्टॉल करने और ठीक करने से शुरू होता है	वातावरण	Lock files, Docker/devcontainer, init.sh स्क्रिप्ट
नया सत्र पूछता है कि कल क्या किया था	स्थिति	PROGRESS.md, स्थिति वाली फ़ीचर-सूची, checkpoint commits
"तैयार", पर फ़ीचर काम नहीं करता	फ़ीडबैक	E2E, Definition of Done, सत्यापन स्क्रिप्ट, स्वतंत्र मूल्यांकक

हार्नेस कहाँ से शुरू करें

शून्य से बनाएँ तो व्यावहारिक क्रम है: फ़ीडबैक → निर्देश → स्थिति → वातावरण → उपकरण। फ़ीडबैक पहले, क्योंकि उसके बिना दूसरे बदलावों का असर नहीं मापा जा सकता। जब तक ऐसी कमांड नहीं जो ईमानदारी से बताए कि "काम करता है या नहीं", निर्देशों में हर सुधार केवल अंदाज़े से परखा जाता है।

न्यूनतम शुरुआत कुछ ऐसी दिखती है:

# AGENTS.md (अंश)
## कैसे जाँचें
- make check   # लिंट, टाइप, unit tests
- make e2e     # end-to-end परिदृश्य
फ़ीचर तभी तैयार है, जब दोनों कमांड कोड 0 पर पूरी हों।

## नियम
- MUST: सभी SQL queries parameterized हों
- MUST: commit से पहले make check चलाएँ
- भुगतान के विवरण: docs/payments.md (जब काम भुगतान से जुड़ा हो तब पढ़ें)

आख़िरी पंक्ति पर ध्यान दें: यह हार्नेस के भीतर context engineering ही है। प्रवेश फ़ाइल नक्शा है, पाठ्यपुस्तक नहीं, और विवरण "कब" की शर्त पर लोड होते हैं।

हर हिस्से का योगदान कैसे मापें

हार्नेस के पास एक मेट्रिक है जो prompt के पास नहीं: वह हिस्सा जिन कामों को एजेंट "तैयार" बताता है, पर स्वतंत्र जाँच उसकी पुष्टि नहीं करती। इसे verification gap कहते हैं। पीछे के 10 काम लें, हर एक के बाद दर्ज करें कि एजेंट ने "तैयार" कहा या नहीं, और जाँच पास हुई या नहीं। जो अनुपात निकले, वही बदलावों की तुलना का आधार है।

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

आम गलतियाँ

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

निष्कर्ष

Prompt engineering अनुरोध के शब्द सुधारता है, context engineering मॉडल की window में जानकारी का चयन करता है, और harness engineering पूरे एजेंट-वातावरण पर काम करता है, जिसमें उपकरण, वातावरण, स्थिति और जाँचें शामिल हैं। जब एजेंट लंबे समय तक काम करता है और ख़ुद कोड बदलता है, तब हार्नेस निर्णायक हो जाता है: वह "एजेंट ने कहा तैयार है" को "सिस्टम ने जाँचा कि काम करता है" में बदलता है। इसलिए harness vs context engineering का सवाल "या–या" नहीं है: context हार्नेस का हिस्सा है, और वही हिस्सा ठीक करें जिसकी ओर लक्षण इशारा करें। यह विषय एक पेमेंट बैकएंड की असली परियोजना पर व्यावहारिक पाठ्यक्रम में समझाया गया है।

अक्सर पूछे जाने वाले प्रश्न

क्या harness engineering prompt engineering की जगह ले लेता है?

नहीं, वह उसे अपने भीतर रखता है। निर्देशों के शब्द अब भी मायने रखते हैं, पर वे पाँच हिस्सों में से केवल एक हैं, उपकरण, वातावरण, स्थिति और फ़ीडबैक के साथ।

अगर मैं एजेंट का उपयोग केवल छोटे बदलावों के लिए करता हूँ, तो क्या हार्नेस चाहिए?

न्यूनतम हार्नेस हमेशा चाहिए: स्टैक और जाँच की कमांड वाली निर्देश फ़ाइल। पूरा सेट, फ़ीचर-सूची और मूल्यांकक के साथ, लंबे कामों और टीमों में फ़ायदेमंद है।

context engineering और RAG में क्या फ़र्क है?

RAG context engineering की एक तकनीक है: प्रासंगिक टुकड़े खोजकर लोड करना। Context engineering इससे व्यापक है और इसमें इतिहास का संक्षेपण, दस्तावेज़ों की संरचना और subagents में उप-कामों का अलगाव भी आता है।

harness engineering में सबसे पहले कौन-सा हिस्सा बनाएँ?

फ़ीडबैक: ऐसी कमांड जो मशीन से बताए कि परिणाम काम करता है या नहीं। इसके बिना बाक़ी सुधारों का असर नापा नहीं जा सकता।

क्या यह दृष्टिकोण केवल Claude Code के लिए है?

नहीं। सिद्धांत सामान्य हैं: AGENTS.md कई एजेंट पढ़ते हैं, और जाँच की स्क्रिप्ट, Docker, स्थिति की फ़ाइलें और E2E टेस्ट किसी एक उपकरण पर निर्भर नहीं।

इस विषय को वीडियो में सीखें

यह विषय “Harness Engineering: инженерия надёжности AI-агентов” कोर्स में अभ्यास के साथ विस्तार से समझाया गया है।

कोर्स पर जाएँ