Harness Engineering क्या है? AI Agent युग में LLM के चारों ओर की परत को डिज़ाइन करना

Harness engineering शब्द फ़रवरी 2026 में तेज़ी से फैला। 5 फ़रवरी 2026 को Mitchell Hashimoto (Ghostty टर्मिनल के निर्माता और HashiCorp के सह-संस्थापक) ने इसे एक आदत का नाम दिया: जब भी agent कोई ग़लती करे, ऐसा समाधान बनाइए कि वह वही ग़लती दोबारा कभी न करे। छह दिन बाद OpenAI ने अपनी Codex टीम की रिपोर्ट के शीर्षक में यही शब्द रखा। Anthropic इससे पहले ही लंबे समय तक चलने वाले agents के आसपास की व्यवस्था के डिज़ाइन "harness" नाम से प्रकाशित कर रहा था। अगर 2025 में कहा जा रहा था कि prompts के बाद context engineering आती है, तो harness engineering उससे भी बाहर की परत से जुड़ी है।

यह लेख स्पष्ट करता है कि harness engineering असल में क्या है, यह prompt engineering और context engineering से कैसे अलग है, एक harness बनाने वाले छह घटक कौन-कौन से हैं, OpenAI और Anthropic के प्रकाशित असली harness, एक व्यावहारिक डिज़ाइन चेकलिस्ट और आज के अग्रणी tools की तुलना — वह बुनियाद जो आपको चाहिए अगर आप AI agents को गंभीरता से इस्तेमाल या निर्माण करना चाहते हैं।

1. Harness Engineering क्या है?

"Harness" मूल रूप से घोड़े पर लगने वाले साज़-सामान को कहा जाता है — वह सरंजाम जो जानवर की ताक़त को आपकी मनचाही दिशा में मोड़ता है। AI में यह शब्द ठीक उसी रूपक के तौर पर काम करता है: शक्तिशाली लेकिन बेक़ाबू LLM को उत्पादक काम पर लगाने वाला पूरा साज़-सामान।

ठोस रूप से इसमें शामिल है:

• Tools: file operations, web search, code execution — वे साधन जिनसे LLM कार्रवाई कर सकता है।
• Context management: prompt में क्या जाएगा और क्या compress या discard होगा, इसकी रणनीति।
• Memory systems: persistent knowledge और user preferences जो sessions के पार बनी रहती हैं।
• Agent loop: perceive → reason → act → observe चक्र।
• Guardrails: permissions, sandbox, Hooks, approval flows।
• Output format: markdown, JSON, citations, streaming।

इन सबको एक साथ डिज़ाइन करना ही harness engineering कहलाता है। LLM को training देना या ख़ुद उसे सुधारना नहीं, बल्कि LLM के चारों ओर सब कुछ engineer करके वास्तविक दुनिया की उपयोगिता बढ़ाने का शिल्प। Claude Code, Cursor, Devin, Codex CLI — ये सभी मोटे तौर पर एक जैसे models पर चलते हैं, फिर भी इनका व्यवहार और प्रदर्शन तीखे ढंग से अलग होता है क्योंकि इनके harnesses में अंतर है।

"Harness" शब्द कहाँ से कहाँ तक जाता है, इसे Thoughtworks की Birgitta Böckeler ने martinfowler.com पर (2 अप्रैल 2026) साफ़ बताया है: harness यानी agent में model को छोड़कर बाक़ी सब कुछ, यानी Agent = Model + Harness। Anthropic भी अपनी cloud सेवा Claude Managed Agents को एक configurable agent harness कहता है।

2. Harness Engineering बनाम Prompt Engineering

Prompt engineering ख़त्म नहीं हुई है — लेकिन इसका दायरा मूलतः अलग है।

अगर prompt engineering "LLM से क्या कहें" का शिल्प है, तो harness engineering "LLM को क्या दें और उसे कैसे चलाएँ" का शिल्प है। दोनों प्रतिस्पर्धी नहीं हैं — वे स्तरीय (layered) हैं। Prompt harness के भीतर का सिर्फ़ एक घटक है।

दूसरा शब्द जिससे अक्सर भ्रम होता है, वह है context engineering। 29 सितंबर 2025 के लेख में Anthropic ने इसे prompt engineering का स्वाभाविक अगला चरण कहा। Böckeler coding agent के लिए harness बनाने को context engineering का एक विशेष रूप बताती हैं। इन्हें साथ रखें तो ये एक-दूसरे के भीतर आते हैं: prompt (आप क्या कहते हैं) ⊂ context (model क्या देखता है) ⊂ harness (उसे क्या दिया जाता है, उसके काम की जाँच कैसे होती है और उसे कैसे रोका जाता है)। Harness की ख़ास बात वह हिस्सा है जो linters और tests की तरह नतीजों को यांत्रिक रूप से जाँचकर ग़लतियाँ agent को वापस लौटाता है।

3. Harness के 6 घटक

1. Tool Use

दुनिया पर कार्रवाई करने का LLM का साधन: files पढ़ना और लिखना, code execute करना, web search करना, APIs call करना। Tool interface ग़लत हो — names, arguments, return values — तो LLM उसे ठीक से इस्तेमाल नहीं कर सकता। ठोस तौर पर:

• Verb-आधारित, स्पष्ट names (जैसे read_file)।
• आवश्यक बनाम वैकल्पिक arguments स्पष्ट हों, defaults के साथ।
• विफलता पर structured error messages (model को बताएँ कि आगे क्या करना है)।
• Side-effecting (विनाशकारी) operations पर स्पष्ट चेतावनियाँ।

2. Context Management

LLM का ध्यान सीमित है — आप जो दिखाते हैं वही तय करता है कि वह क्या कहेगा। ठोस तौर पर:

• Relevance filtering: पूरी files नहीं, सिर्फ़ task से प्रासंगिक हिस्से लें।
• Compaction: लंबी बातचीत को बनाए रखने के लिए summarize करें।
• RAG integration: vector search के ज़रिए जो ज़रूरी है उसे लाएँ।
• Caching: Anthropic के prompt cache जैसे tools से दोहराए गए system prompts पर cost घटाएँ।

संबंधित: RAG क्या है?

3. Memory System

Sessions के पार ज्ञान बनाए रखना। Claude Code की CLAUDE.md, Cursor की .cursor/rules, और Codex की AGENTS.md — ये सब project memory के उदाहरण हैं। इसके अलावा:

• Short-term memory: हाल की बातचीत का इतिहास।
• Long-term memory: user profile, पिछले निर्णय।
• Factual knowledge: domain-विशिष्ट knowledge bases।

4. Agent Loop

वह केंद्रीय हिस्सा जो "AI agent" को असल में काम करवाता है। मूल रूप perceive → reason → act → observe चक्र है:

1. User का लक्ष्य प्राप्त करना।
2. वर्तमान स्थिति का विश्लेषण (ज़रूरत पड़े तो tools से जानकारी जुटाना)।
3. अगली कार्रवाई की योजना।
4. Tool के माध्यम से कार्रवाई।
5. परिणाम observe करना; जाँचना कि लक्ष्य पूरा हुआ या नहीं।
6. नहीं हुआ तो loop, हुआ तो terminate।

आपका agent कितना smart बनेगा, यह इस बात पर निर्भर है कि आप replanning, self-critique और subgoal decomposition को बेक़ायदा रूप से अंदर रखते हैं या नहीं।

5. Guardrails

बेलगाम व्यवहार रोकने वाले तंत्र। जैसा कि AI आपके .md rules क्यों नज़रअंदाज़ करता है में बताया गया है, environment के ज़रिए व्यवहार लागू करना गद्य में विनम्रता से कहने से कहीं ज़्यादा भरोसेमंद है:

• Approval mode: ख़तरनाक operations चलने से पहले इंसान पुष्टि करता है (जैसे Claude Code की permission settings, Codex CLI के approval modes)।
• Sandbox: filesystem और network access को सीमित करें।
• Hooks: tool calls से पहले और बाद में मनमाफ़िक जाँचें।
• Rate limiting: कुछ ग़लत हो जाए तो नुक़सान न्यूनतम रखें।

6. Output UX

परिणाम ऐसे रूप में पेश करना जिसे user समझ और सत्यापित कर सके। Markdown rendering, source citations, syntax-highlighted code blocks, streaming output, दिखने वाला reasoning (thinking), structured output (JSON), इत्यादि। "सही उत्तर" तैयार करना ही काफ़ी नहीं है — उसे user के भरोसे और जाँच-योग्य रूप में पहुँचाना harness का काम है।

4. Harness Engineering, और अभी क्यों?

Harness काम में बढ़ती दिलचस्पी की तीन वजहें हैं।

1. यह दिखाया जा चुका है कि एक ही model अपने आसपास की व्यवस्था के हिसाब से बहुत अलग नतीजे देता है। Anthropic के 24 मार्च 2026 को प्रकाशित प्रयोग में उसी Claude Opus model से एक वाक्य में 2D retro game maker बनाने को कहा गया। अकेला agent 20 मिनट और $9 में ख़त्म हो गया, पर उसका बनाया level खेला नहीं जा सकता था। Planner, generator और evaluator में बँटा harness 6 घंटे चला और $200 लगे — और ऐसा game बना जिसमें character को सचमुच चलाया जा सकता था (physics अब भी खुरदरी थी)। लागत 20 गुना से ज़्यादा थी, पर गुणवत्ता का अंतर भी उतना ही बड़ा था। गुणवत्ता और लागत में से क्या चुनना है, यह अब model जितना ही harness का फ़ैसला है।

2. ऐसी समस्याएँ जमा हो रही हैं जिन्हें अकेले prompts हल नहीं कर सकते। "बहुत सारे tools हैं, model ग़लत चुन लेता है।" "Context इतना भरा है कि ज़रूरी संकेत दब जाता है।" "लंबे tasks में agent बीच में ही धागा खो देता है।" ये एक turn में चालाक शब्दों से ठीक होने वाली समस्याएँ नहीं हैं — ये design की समस्याएँ हैं।

3. इंजीनियर का काम ख़ुद बदलने लगा है। OpenAI की Codex टीम ने बताया कि उसने पाँच महीने तक हाथ से लिखी एक भी line के बिना एक आंतरिक product बनाया, जो लगभग 10 लाख lines और लगभग 1,500 pull requests तक पहुँचा (11 फ़रवरी 2026)। उनका निष्कर्ष: मुख्य काम code लिखने से हटकर environment डिज़ाइन करने, इरादा स्पष्ट करने और feedback loops बनाने पर आ गया है। Claude Code, Codex, Cursor, Devin और बाक़ी बड़े products model के बाहर के डिज़ाइन पर होड़ कर रहे हैं।

5. प्रकाशित उदाहरण: तीन असली harness

Harness engineering आसानी से अमूर्त बन जाती है। यहाँ तीन उदाहरण हैं जिनके निर्माताओं ने विवरण प्रकाशित किए हैं — उन्होंने असल में क्या किया, उसी स्तर पर।

1. OpenAI की Codex टीम: AGENTS.md एक नक़्शा, नियम linters से लागू

• उन्होंने AGENTS.md को लगभग 100 lines की विषय-सूची तक सीमित रखा और repository की docs/ directory को design, plans और quality notes का आधिकारिक स्रोत बनाया। एक विशाल file context से काम को बाहर धकेलती थी, जल्दी पुरानी हो जाती थी और उसे यांत्रिक रूप से जाँचा नहीं जा सकता था।
• Docs ताज़ा रहें, इसके लिए linters और CI cross-links और ढाँचे की जाँच करते हैं, और एक नियमित agent ऐसे विवरण खोजता है जो अब code से मेल नहीं खाते, और सुधार के PR खोलता है।
• Layers, dependency की दिशा, structured logging, file size की सीमा और बहुत कुछ custom linters और structural tests से लागू किया जाता है। Error messages में सुधार का तरीक़ा साफ़ लिखा होता है, ताकि agent उन्हें पढ़कर अपना काम ख़ुद ठीक कर सके।

2. Anthropic: लंबे समय तक चलने वाले agents का हस्तांतरण डिज़ाइन करना

जब development कई context windows में फैल जाता है, तो agents एक साथ बहुत कुछ बनाने की कोशिश करते थे या बीच में ही काम पूरा घोषित कर देते थे। Anthropic (26 नवंबर 2025) ने इसे ऐसे सुलझाया:

• सिर्फ़ पहला session अपने अलग prompt के साथ एक initializer agent चलाता है। वह features की सूची (feature_list.json), progress log (claude-progress.txt), dev server शुरू करने वाली init.sh और पहला git commit तैयार करता है।
• हर अगला session progress log और git log पढ़कर स्थिति समझता है, सिर्फ़ एक feature बनाता है, और commit व log अपडेट के साथ ख़त्म होता है।
• Feature list Markdown नहीं, JSON में है, क्योंकि model उसे अनुचित रूप से कम बदलता था। उसे सिर्फ़ pass/fail वाला field (passes) बदलने की अनुमति है।
• कोई feature तभी पूरा माना जाता है जब उसे browser automation से शुरू से अंत तक, एक user की तरह, test कर लिया गया हो।

3. Mitchell Hashimoto: एक ही ग़लती दो बार नहीं

नाम देने वाले ख़ुद छोटे पैमाने पर काम करते हैं। Agent कोई सरल ग़लती करे तो वे AGENTS.md में एक line जोड़ते हैं; उनके Ghostty टर्मिनल project में इस file की हर line किसी पुराने ग़लत व्यवहार से जुड़ी है, और इससे वे लगभग सब दूर हो गए। जहाँ लिखा हुआ काफ़ी न हो, वहाँ वे असली scripts बनाते हैं — screenshots लेने के लिए, चुने हुए tests चलाने के लिए — और agent को दे देते हैं।

तीनों में साझा बात यह है कि ज़ोर लिखकर अनुरोध करने से ज़्यादा, काम जाँचकर लौटाने वाली व्यवस्था पर है। कितना हिस्सा व्यवस्था में बदलना है, यह तय करने में नीचे की चेकलिस्ट मदद करती है।

6. व्यावहारिक Harness डिज़ाइन चेकलिस्ट

7. प्रमुख Harnesses की तुलना

इन सभी harnesses के नीचे लगभग एक जैसे LLMs (Claude / GPT / Gemini) चलते हैं, फिर भी इनकी शक्तियाँ harness design दर्शन के अंतर के कारण तीखे ढंग से अलग होती हैं। "कौन-सा LLM?" से ज़्यादा "कौन-सा harness?" मायने रखता है — यही agent युग का असली मैदान है।

8. Anti-Patterns

1. बहुत ज़्यादा tools जोड़ना

जितने ज़्यादा tools, LLM के ग़लत tool चुनने की संभावना उतनी ज़्यादा। Anthropic के documentation के अनुसार 30–50 से ज़्यादा tools उपलब्ध होने पर Claude की tool चुनने की सटीकता घटने लगती है, और इसके लिए tool search दिया गया है, जो ज़रूरत पड़ने पर सिर्फ़ प्रासंगिक tools लोड करता है। कंपनी की tools लिखने की गाइड भी कहती है कि ज़्यादा tools का मतलब बेहतर नतीजे नहीं: हर API endpoint को अलग tool बनाने के बजाय मिलते-जुलते functions को एक साथ जोड़ें।

2. context में सब कुछ भरना

"सुरक्षा के लिए सब कुछ दिखा दो" उल्टा असर करता है। Relevance filter से गुज़ारें और सिर्फ़ ज़रूरी ही शामिल करें। Context महत्वपूर्ण संकेत को सामने लाने का साधन है — स्टोरेज ख़ज़ाना नहीं।

3. सुरक्षा सिर्फ़ prompts से लागू करना

"कृपया ख़तरनाक operations न करें" परिस्थिति के अनुसार देर-सवेर नज़रअंदाज़ हो जाता है। सही जवाब है इसे environment स्तर पर भौतिक रूप से असंभव बनाना — sandbox, Hooks, permission limits।

4. जो जोड़ा, उसकी कभी समीक्षा न करना

हर जोड़ा गया हिस्सा harness को भारी, धीमा और महँगा बनाता है। ऊपर वाले प्रयोग के बाद Anthropic ने components को एक-एक करके हटाया और नतीजों की तुलना की, और सिर्फ़ वही रखा जो अब भी मदद कर रहा था (planner और evaluator)। उनका तर्क: harness का हर component इस धारणा पर टिका है कि model अपने आप क्या नहीं कर सकता, और models बेहतर होने के साथ ये धारणाएँ जल्दी पुरानी पड़ जाती हैं। Model बदलने पर एक-एक करके जाँचें कि आपकी जोड़ी हर जाँच और हर बँटवारा अब भी काम का है या नहीं।

सारांश

Harness engineering LLM के "बाहर" वाली परत को डिज़ाइन करने का शिल्प है। Prompt engineering harness के भीतर का सिर्फ़ एक घटक है। छह तत्वों — tool definition, context management, memory, loop, guardrails, output UX — को सोच-समझकर बरतने से एक ही underlying LLM से वास्तविक दुनिया का प्रदर्शन रूपांतरित किया जा सकता है।

2026 के अनुसार, production AI agents का मुख्य मैदान स्पष्ट रूप से harness पर शिफ़्ट हो गया है। "Smart prompts" लिखना नहीं, बल्कि "smart harnesses" बनाना — यही अगली पीढ़ी के engineers का अंतर तय करेगा।

FAQ

Q1. तो अब prompt engineering की ज़रूरत नहीं?

ग़लत। यह अब भी ज़रूरी है — harness के भीतर एक घटक के रूप में। Tool descriptions, system prompts, error messages — ये सब prompt design की सतहें हैं। पुराना तरीक़ा है यह सोच कि "मैं इसे बेहतर prompt से ठीक कर लूँगा"।

Q2. Harness engineering सीखने का पहला क़दम क्या है?

Claude Code या Cursor लें और सिर्फ़ इस्तेमाल मत करें — config बदलकर इसका व्यवहार बदलें। Hashimoto के तरीक़े को चरणों में बदलें तो यह ऐसा दिखता है:

1. Agent की हर ग़लती लिख लें (किस निर्देश पर, क्या ग़लत हुआ)।
2. सरल ग़लतियों के लिए CLAUDE.md / AGENTS.md / .cursor/rules में एक line जोड़ें।
3. बार-बार होने वाली या नुक़सान पहुँचाने वाली ग़लतियों को Hooks, linters या tests से यांत्रिक रूप से रोकें — और error message में सुधार का तरीक़ा लिखें।
4. Agent से वही काम दोबारा करवाएँ और पुष्टि करें कि ग़लती ख़त्म हो गई।

Q3. क्या harnesses LangChain जैसे frameworks के समान हैं?

क़रीब, लेकिन एक नहीं। Framework एक implementation toolkit है; harness एक design discipline और मानसिकता है। LangChain, LlamaIndex, Claude Agent SDK इत्यादि harnesses बनाने के औज़ार हैं।

Q4. ख़ुद का harness बनाएँ या मौजूदा का इस्तेमाल करें?

अधिकांश मामलों में, एक मौजूदा harness (Claude Code, Cursor, इत्यादि) और customization काफ़ी है। शून्य से बनाना सिर्फ़ enterprise आवश्यकताओं, niche domains या अति cost optimization के लिए ही समझदारी है।

Q5. क्या "Harness Engineer" वास्तविक job title बनेगा?

अभी कोई तय job title नहीं है। ख़ुद Hashimoto ने लिखा कि उन्हें नहीं पता कि उद्योग में कोई व्यापक रूप से स्वीकृत शब्द है या नहीं। लेकिन OpenAI की Codex टीम बताती है कि इंजीनियर का मुख्य काम environment डिज़ाइन करने, इरादा स्पष्ट करने और feedback loops बनाने की ओर खिसक गया है — title तय होने से पहले ही काम की विषय-वस्तु बदल रही है।