Harness engineering क्या है: AI एजेंट को काम का उपकरण कैसे बनाएँ

Harness engineering सरल भाषा में

Harness engineering एक इंजीनियरिंग अनुशासन है, जो बताता है कि भाषा मॉडल के आसपास ऐसा वातावरण कैसे बनाया जाए जहाँ वह असली काम भरोसे के साथ करे। शब्द harness का अर्थ है "जीन" या "साज़-सामान"। मॉडल शक्तिशाली है, लेकिन अपने-आप उसे नहीं पता होता कि कहाँ जाना है, कौन-सा उपकरण इस्तेमाल करना है और कब रुकना है। हार्नेस उसी शक्ति को दिशा देता है।

सबसे छोटा सूत्र यह है:

एजेंट = मॉडल + हार्नेस

मॉडल वे weights हैं जो तर्क करते हैं और टेक्स्ट या कोड लिखते हैं। हार्नेस बाक़ी सब कुछ है: सिस्टम निर्देश और CLAUDE.md या AGENTS.md जैसी फ़ाइलें, उपकरणों का समूह (shell, फ़ाइल संपादन, MCP सर्वर), sandbox जिसमें एजेंट कमांड चलाता है, सत्रों के बीच की स्थिति की फ़ाइलें, और टेस्ट, linter व hooks जो एजेंट को गलतियों के बारे में बताते हैं। अगर हार्नेस हटा दें, तो बचता है सिर्फ़ एक चैट, जो केवल टेक्स्ट में जवाब दे सकती है।

एजेंट कभी "सीनियर", कभी "जूनियर" क्यों लगता है

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

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

ख़राब हार्नेस के आम लक्षण

• हर नया सत्र वातावरण ठीक करने से शुरू होता है: अलग dependencies, database नहीं चलता, variables नहीं हैं।
• एजेंट वे समाधान दोहराता है जो पहले ख़ारिज हो चुके थे, क्योंकि उसे पिछला सत्र याद नहीं।
• नियम निर्देशों में साफ़ लिखा है, फिर भी एजेंट उसे नज़रअंदाज़ करता है।
• "टेस्ट हरे हैं", पर फ़ीचर टूटा है, क्योंकि टेस्ट कुछ और जाँच रहे थे।
• एजेंट एक साथ तीन काम उठाता है और एक भी पूरा नहीं करता।

हार्नेस किन पाँच हिस्सों से बनता है

आम गलती है हार्नेस को सिर्फ़ एक prompt वाली फ़ाइल मान लेना। असल में यह पाँच तंत्रों का मेल है, और हर एक अपने तरीक़े से टूटता है।

निर्देश

निर्देश इस सवाल का जवाब देते हैं: क्या एजेंट को सही नियम मिलेगा? अच्छी प्रवेश फ़ाइल एक नक्शे जैसी होती है: छोटी विषय-सूची, जाँच की कमांड और सख़्त सीमाएँ, जबकि विवरण अलग दस्तावेज़ों में होते हैं जिन्हें एजेंट ज़रूरत पड़ने पर खोलता है। अच्छे निर्देश invariants बताते हैं ("सभी SQL queries parameterized हों"), न कि हर पंक्ति का तरीक़ा।

उपकरण

एजेंट सिर्फ़ उसी चीज़ की जाँच कर सकता है जिस तक उसकी पहुँच है। अगर वह linter नहीं चला सकता, तो "commit से पहले linter चलाओ" वाला नियम काम नहीं करेगा। उपकरण एजेंट की अंतर्निहित क्षमताओं (फ़ाइल पढ़ना-लिखना, कमांड चलाना) और MCP के ज़रिए जुड़ते हैं, जो एजेंट को database, ब्राउज़र और task trackers तक पहुँच देने वाला प्रोटोकॉल है।

वातावरण

वातावरण वह जगह है जहाँ एजेंट कमांड चलाता है। उसे एक कमांड से चालू होना चाहिए, हर सत्र में एक-सा रहना चाहिए और गलती के नुक़सान को सीमित रखना चाहिए: ऐसा sandbox जिसकी production तक पहुँच न हो, अलग branch या कार्यकारी प्रति, और एक मिनट में सब कुछ पहली स्थिति पर लौटाने की क्षमता।

स्थिति

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

फ़ीडबैक

फ़ीडबैक लूप सबसे महत्वपूर्ण हिस्सा है। इसके बिना एजेंट अपना ही जज होता है और ईमानदारी से मान लेता है कि काम पूरा हो गया। टेस्ट, type checking, linter, हर बदलाव के बाद चलने वाला hook, browser में E2E परिदृश्य, ये सब एजेंट को लाल संकेत देते हैं, जब गलती सस्ती होती है।

हार्नेस एक सूची नहीं, एक चक्र है

पाँचों हिस्से एक बंद चक्र की तरह काम करते हैं। मॉडल निर्देश लेता है, उपकरणों से वातावरण में काम करता है, रिपॉज़िटरी में बदलाव करता है, और जाँच परिणाम परखती है। लाल परिणाम सुधार के लिए मॉडल के पास लौटता है, हरा परिणाम स्थिति में दर्ज होता है। स्थिति अगले सत्र के निर्देश भी अपडेट करती है।

निर्देश → मॉडल → उपकरण → वातावरण → बदलाव
                ↑                              ↓
                └──── लाल ── जाँच ─────────────┘
                                     ↓ हरा
                                 स्थिति → (अगला सत्र)

कोई भी एक तीर हटाएँ, और चक्र वहीं टूट जाता है। जाँच न हो, तो एजेंट गलती नहीं देखता। स्थिति न हो, तो अगला सत्र काम के बजाय पुराने सुराग़ खोजने में समय लगाता है। इसलिए एक हिस्से में निवेश दूसरे की खामी की भरपाई नहीं करता: पाँच पन्नों की AGENTS.md लापता टेस्ट की जगह नहीं ले सकती।

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

ये अवधारणाएँ एक-दूसरे के भीतर हैं, एक-दूसरे की प्रतिस्पर्धी नहीं।

Prompt engineering निर्देशों के हिस्से का काम है। Context engineering निर्देश और स्थिति दोनों को छूता है: हर पल एजेंट क्या देखता है। Harness engineering वह जोड़ता है जो window में आ ही नहीं सकता: पहुँच, sandbox, टेस्ट, hooks, काम की प्रक्रिया। अच्छा लिखा prompt भी किसी काम का नहीं, अगर एजेंट टेस्ट चला ही न सके।

लंबे कामों का गणित: हार्नेस क्यों ज़रूरी है

सहज लगता है कि जो मॉडल 95% कदम सही करता है, वह लगभग परिपूर्ण है। लेकिन एजेंट का काम कई कदमों से बना होता है, और गलतियाँ जमा होती हैं। अगर कदम स्वतंत्र हों, तो बिना एक भी गलती के सभी कदम पार करने की संभावना संभावनाओं का गुणनफल होती है:

0.95 ^ 10 ≈ 0.60
0.95 ^ 20 ≈ 0.36
0.95 ^ 50 ≈ 0.08

दसवें कदम तक बिना एक भी गलती के लगभग 60% रन पहुँचते हैं, पचासवें तक दस में से एक से भी कम। मॉडल को 97% तक बेहतर बनाना महँगा है और आपके हाथ में नहीं। लेकिन गलती को उसी कदम पर पकड़ना और एजेंट को लौटाना हार्नेस का काम है। फ़ीडबैक लूप "एक गलती अगली गलती खींचती है" की शृंखला को छोटे, सुधारे जाने योग्य कदमों की शृंखला में बदल देता है।

उदाहरण: एक ही एजेंट, दो रिपॉज़िटरी

काम: FastAPI वाले payment backend में promo code से छूट जोड़नी है।

हार्नेस के बिना

एजेंट कुछ फ़ाइलें पढ़ता है, छूट गणना का फ़ंक्शन और एक unit test लिखता है, जो उसे अलग से जाँचता है। Test हरा है, एजेंट लिखता है "तैयार है"। उसे नहीं पता था कि कुल राशि की गणना दूसरे module में होती है, और वह database उठाकर पूरा order flow नहीं चला सका। एक दिन बाद पता चलता है कि cart में छूट लागू ही नहीं होती।

हार्नेस के साथ

रूट में AGENTS.md है, जिसमें कुछ दर्जन पंक्तियाँ हैं: वातावरण कैसे चलाएँ, कौन-सी जाँच अनिवार्य है, payments की architecture कहाँ लिखी है। वातावरण docker compose up -d से चलता है। रिपॉज़िटरी में योजना की फ़ाइल है जिसमें तैयार होने की शर्त लिखी है: "promo code वाला order flow का E2E परिदृश्य पास होता है"। हर बदलाव के बाद hook linter और type checking चलाता है, और पूरा होने से पहले एजेंट को E2E test चलाना ज़रूरी है।

# AGENTS.md (अंश)
## जाँच — "तैयार" कहने से पहले अनिवार्य
make lint        # ruff + mypy
make test        # pytest, unit और integration
make e2e         # order flow परिदृश्य

## MUST
- पैसे की गणना पैसों (int) में होती है, कभी float में नहीं
- सभी SQL queries parameterized हों
- पहले से लागू (production) migrations न बदलें

मॉडल वही है। पर अब एजेंट project map से राशि वाला module खोजता है, E2E test पहली कोशिश में गिरता है, एजेंट देखता है कि छूट cart तक नहीं पहुँच रही, उसे ठीक करता है और केवल हरे परिणाम के बाद रिपोर्ट देता है। फ़र्क पूरी तरह हार्नेस की वजह से है।

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

1. लिखें कि एजेंट अपना काम कैसे जाँचता है: एक से तीन कमांड जो उसे ज़रूर चलानी हैं। फ़ीडबैक सबसे ज़्यादा असर डालता है, इसलिए शुरुआत यहीं से करें।
2. वातावरण को दोहराने योग्य बनाएँ: एक कमांड से चालू हो, और जल्दी पीछे लौटने का तरीक़ा हो।
3. स्थिति की फ़ाइल बनाएँ: लक्ष्य, किया गया काम, फ़ैसले और बंद रास्ते, अगला कदम।
4. निर्देशों को नक्शे जितना छोटा रखें: जाँच की कमांड, सख़्त नियम, विस्तृत दस्तावेज़ों के लिंक।
5. एजेंट की असफलताओं का लॉग रखें: हर विफलता पर लिखें कि कौन-सा हिस्सा उसके लिए ज़िम्मेदार था। लॉग बताएगा कि आगे क्या सुधारना है।

एक उपयोगी अभ्यास: पाँचों हिस्सों को 1 से 5 के पैमाने पर आँकें, सबसे कमज़ोर हिस्से पर आधा घंटा लगाएँ, और उसी तरह के कुछ काम पहले और बाद में चलाएँ। इस तरह हार्नेस के सुधार मापने योग्य बनते हैं, केवल "लगता है" नहीं रहते।

निष्कर्ष

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