Claude के साथ एजेंट हार्नेस इंजीनियरिंग: एक एजेंट से सेल्फ-इम्प्रूविंग सिस्टम तक का 14-चरणीय रोडमैप।

हर कोई loops के बारे में बात कर रहा है। लगभग कोई भी इस बारे में बात नहीं कर रहा कि loop किस पर चलता है। 9 में से 10 डेवलपर Claude Code को डिफ़ॉल्ट harness पर चलाते हैं - बिना किसी rules, subagents, hooks, या memory के।

फिर उन्हें आश्चर्य होता है कि उनका loop घटिया आउटपुट क्यों देता है। सच्चाई सरल है: एक loop उतना ही अच्छा होता है जितना कि उसके नीचे का harness। यह harness के लिए 14-चरणीय रोडमैप है - एक agent से लेकर एक ऐसी प्रणाली तक जो खुद में सुधार करती है।

ताज़ा AI alpha पाने के लिए मेरे Substack को फॉलो करें:

movez.substack.com

Loop engineering - एक ऐसी प्रणाली बनाना जो आपके agent को एक शेड्यूल पर प्रॉम्प्ट करे - ने इस महीने सारा ध्यान खींचा। लेकिन Addy Osmani, जिन्होंने loops पर विस्तृत लेख लिखा, ने इसके नीचे क्या है, उस पर ध्यान दिलाने में सावधानी बरती:

“Loop engineering, harness से एक मंजिल ऊपर बैठता है। Harness वह वातावरण है जिसके अंदर एक एकल agent चलता है। Loop, harness ही है, लेकिन यह एक टाइमर पर चलता है, सहायकों को जन्म देता है, और खुद को फीड करता है।”

Harness engineering, उस वातावरण को डिज़ाइन करना है: model, tools, permissions, context, memory।

यह गैर-ग्लैमरस परत है - और यह वही है जो तय करती है कि इसके ऊपर सब कुछ काम करता है या नहीं। एक बुरे harness पर एक शानदार loop, बड़े पैमाने पर कचरा पैदा करने का एक तेज़ तरीका है।

14 कदम। 3 स्तर। वह नींव जिस पर बाकी सब कुछ खड़ा होता है।

भाग 1 · Harness क्या है

01. Harness वह वातावरण है जिसके अंदर एक agent चलता है।

शब्दजाल को हटा दें तो एक harness चार चीज़ें हैं: model जो सोचता है, tools जिन तक वह पहुँच सकता है, permissions उन tools पर, और context जिसे वह हर रन की शुरुआत में पढ़ता है।

यही पूरी सतह है। बाकी सब कुछ - subagents, hooks, memory - उन चार में से एक को आकार देने का एक तरीका है।

Harness लोगों के विचार से अधिक मायने रखने का कारण: agent एक while True लूप है जो एक tool चुनता है, उसे चलाता है, परिणाम देखता है, और अगला कदम तय करता है।

Harness परिभाषित करता है कि कौन से tools मौजूद हैं, agent को क्या करने की अनुमति है, और शुरू करने पर वह क्या जानता है। एक ही model, अलग harness, पूरी तरह से अलग agent।

02. पूरा harness एक फ़ोल्डर में रहता है: .claude/

आपके agent को आकार देने वाली हर चीज़ आपके प्रोजेक्ट रूट में एक एकल निर्देशिका में बैठती है। इस लेआउट को सीखें और आप एक नज़र में किसी के भी harness को पढ़ सकते हैं:

1.claude/
2├─ CLAUDE.md          # स्थायी तथ्य — हर सत्र में पढ़ें
3├─ settings.json      # permissions, model, hooks
4├─ .mcp.json          # बाहरी tool कनेक्शन
5├─ rules/             # पथ-स्कोप्ड व्यवहार
6│  ├─ tests.md
7│  └─ python-types.md
8├─ agents/            # subagent परिभाषाएँ (~30 लाइनें प्रत्येक)
9│  ├─ reviewer.md
10│  └─ eval-runner.md
11├─ skills/            # पुन: प्रयोज्य वर्कफ़्लो
12│  └─ pr-checklist/
13│     └─ SKILL.md
14└─ agent-memory/      # जो runs के बीच बचता है
15   └─ STATE.md

एक नियम जो एक साफ harness को गंदगी से अलग करता है: इसे इतना छोटा रखें कि आप समझा सकें कि हर फ़ाइल क्यों मौजूद है। यदि आप यह नहीं बता सकते कि कोई rule, hook, या subagent किस लिए है, तो उसे हटा दें।

03. Harness बनाम Loop बनाम System. तीन मंजिलें, उन्हें मिलाएँ नहीं।

अधिकांश “मेरा agent सेटअप गड़बड़ है” समस्याएँ तीन मंजिलों को भ्रमित करने से आती हैं। उन्हें अलग रखें:

• Harness वह runtime है जिसमें एक agent रहता है। स्थिर कॉन्फ़िगरेशन: model, tools, permissions, context। यह अंक।
• Loop एक टाइमर पर agent को प्रॉम्प्ट करता है, सहायकों को जन्म देता है, खुद को फीड करता है। यह harness के ऊपर चलता है।
• स्व-सुधार प्रणाली एक loop प्लस memory है जो चक्रवृद्धि करता है - हर रन अगले रन को शार्प बनाता है।

व्यावहारिक संस्करण: स्थायी तथ्यों को context में, प्रवर्तन को hooks में, प्रक्रियाओं को skills में, और अलगाव को subagents में रखें।

इन्हें मिलाना - CLAUDE.md में प्रवर्तन, context को फुलाने वाली प्रक्रियाएँ - असंगत, महंगे agents का मूल कारण है।

04. डिफ़ॉल्ट harness. आपको बॉक्स से बाहर क्या मिलता है।

Claude Code इंस्टॉल करें, एक फ़ोल्डर खोलें, और आपके पास पहले से ही एक harness है - बस एक खाली। डिफ़ॉल्ट आपको एक सक्षम model, बिल्ट-इन tools (read, write, bash, search), और हर जोखिम भरी चीज़ पर अनुमोदन प्रॉम्प्ट देता है। कोई प्रोजेक्ट context नहीं, कोई कस्टम subagents नहीं, कोई memory नहीं।

एक बार के कार्य के लिए, डिफ़ॉल्ट ठीक है। किसी भी चीज़ के लिए जो आप एक से अधिक बार करते हैं, डिफ़ॉल्ट agent को हर सत्र में आपके प्रोजेक्ट को स्क्रैच से फिर से प्राप्त करने, सुरक्षित संचालन के लिए अनुमति माँगने, और टर्मिनल बंद करने पर सब कुछ भूलने के लिए छोड़ देता है।

अगले दस कदम उस अंतर को पाटने के बारे में हैं।

05. CLAUDE.md: स्थायी तथ्य, संक्षिप्त रखे गए।

CLAUDE.md हर सत्र की शुरुआत में पढ़ा जाता है। यह आपके प्रोजेक्ट के बारे में agent का स्थायी ज्ञान है - conventions, आर्किटेक्चर, “हम ऐसा इसलिए नहीं करते क्योंकि वह घटना हुई थी।”

सबसे आम गलती: इसे एक विशाल प्रक्रिया दस्तावेज़ में बदलने देना जो हर सत्र को फुला देता है।

इसे रोज़ाना चलाने वाले चिकित्सकों का नियम: मुख्य memory फ़ाइल को ~500 tokens से कम रखें। स्थायी तथ्य यहाँ जाते हैं।

बहु-चरणीय प्रक्रियाएँ skills में जाती हैं (चरण 8)। पथ-विशिष्ट व्यवहार rules/ फ़ाइलों में जाते हैं जहाँ वे लागू होते हैं। यदि CLAUDE.md का कोई भाग एक तथ्य के बजाय एक प्रक्रिया बन गया है, तो वह कहीं और का है।

अपने CLAUDE.md को ज़ोर से पढ़ें। हर पंक्ति एक

तथ्य

होना चाहिए जिसकी agent को हर सत्र में आवश्यकता है (“हम pnpm का उपयोग करते हैं, npm का नहीं”)। यदि कोई पंक्ति एक

प्रक्रिया

है (“कोई सुविधा जोड़ने के लिए, पहले…”), तो उसे skill में ले जाएँ।

यदि यह एक फ़ोल्डर के लिए नियम है, तो इसे rules/ में ले जाएँ।

06. settings.json: permissions और model, एक बार सेट करें।

डिफ़ॉल्ट harness हर जोखिम भरी कार्रवाई से पहले पूछता है। जब आप देख रहे हों तो यह सही है और जब आप नहीं देख रहे हों तो गलत। settings.json वह जगह है जहाँ आप सुरक्षित चीज़ों को पूर्व-अनुमोदित करते हैं, खतरनाक चीज़ों को अस्वीकार करते हैं, और चुनते हैं कि कौन सा model चलता है।

1{
2  "model": "claude-sonnet-4-6",
3  "permissions": {
4    "autoApprove": [
5      "Read(*)", "Grep(*)",
6      "Bash(npm test)", "Bash(git status)"
7    ],
8    "deny": [
9      "Bash(rm -rf*)", "Bash(git push*)",
10      "Edit(.env*)", "Edit(secrets/*)"
11    ]
12  }
13}

स्वतः-अनुमोदन के लिए परीक्षण: यदि यह गलत हो जाता है, तो इसे पूर्ववत करना कितना मुश्किल है? पूर्ववत करना सस्ता → स्वतः-अनुमोदन करें।

पूर्ववत करना महंगा (force-push, फ़ाइलें हटाना, secrets को छूना) → हमेशा अस्वीकार करें या संकेत दें। मध्य मैदान स्वतः-अनुमोदन के लिए ठीक है यदि आप इसे लॉग करते हैं।

07. Subagents: गंदे काम के लिए पृथक context.

एक subagent मुख्य एक से लॉन्च किया गया एक स्वतंत्र Claude सत्र है - इसकी अपनी context window, अपनी tool सूची। बात अपने आप में समानता की नहीं है। यह मुख्य context से शोर को दूर रखने के बारे में है।

एक शोध कार्य जो 40 फ़ाइलें पढ़ता है, एक समीक्षा पास जिसे एक नए दृष्टिकोण की आवश्यकता है, एक eval रन जो लॉग की एक दीवार पैदा करता है - वे एक subagent के हैं ताकि वे मुख्य थ्रेड को प्रदूषित न करें।

GIF

किसी भी harness में सबसे मूल्यवान subagent वह है जो मुख्य agent द्वारा किए गए काम की जाँच करता है। एक model अपने स्वयं के आउटपुट की समीक्षा करने में खुद पर बहुत आसान होता है;

एक अलग reviewer एक ताज़ा context window के साथ उन चीज़ों को पकड़ता है जो लेखक ने खुद को समझा ली थीं। यह writer-vs-checker विभाजन है जो harness के ऊपर हर loop को भरोसेमंद बनाता है।

08. Skills: प्रक्रियाएँ जिन्हें agent पुन: उपयोग करता है.

एक Skill एक SKILL.md फ़ाइल है जिसे agent चलाता है - या तो जब आप इसे /skill-name से कॉल करते हैं या स्वचालित रूप से जब कार्य इसके विवरण से मेल खाता है।

एक subagent के विपरीत, यह उसी context window में चलता है। यह सिर्फ पुन: प्रयोज्य निर्देश हैं जो सत्र का हिस्सा बन जाते हैं।

एक बनाने का ट्रिगर: आप देखते हैं कि आप हर नई बातचीत में समान निर्देश चिपका रहे हैं। यह एक skill बनने वाली है। एक PR चेकलिस्ट, एक eval प्रक्रिया, एक रिलीज़ प्रक्रिया - एक बार लिखें, हमेशा के लिए उपयोग करें।

और क्योंकि skills पुन: प्रयोज्य इकाई हैं, वे ही हैं जो harness को समय के साथ सुधारती हैं: हर बार जब प्रक्रिया एक नए तरीके से विफल होती है, आप सबक skill में जोड़ते हैं, और अगला रन इसे विरासत में लेता है।

09. Hooks: नियतात्मक नियम जिन्हें model hallucinate नहीं कर सकता।

अब तक सब कुछ model पर निर्भर करता है कि वह आपके निर्देशों को समझे। Hooks नहीं करते।

एक hook एक शेल कमांड है जो agent जीवनचक्र में एक निश्चित बिंदु पर फायर करता है - एक tool चलाने से पहले, फ़ाइल बदलने के बाद, सत्र समाप्त होने पर - और इसका exit code कार्रवाई को रोक सकता है। Hooks प्रवर्तन हैं, CLAUDE.md सुझाव है।

दो hooks लगभग हर harness में अपना स्थान अर्जित करते हैं:

• एक PreToolUse गेट जो नियतात्मक रूप से खतरनाक कमांड को ब्लॉक करता है — rm -rf, .env पढ़ना, main पर push करना। Exit code 2 कॉल को होने से पहले रोक देता है। Model इसके आगे बात नहीं कर सकता।
• एक PostToolUse फ़ॉर्मेटर जो हर संपादन के बाद आपका लिंटर या फ़ॉर्मेटर चलाता है। Agent कभी भी अप्रारूपित कोड नहीं भेजता क्योंकि harness इसे स्वचालित रूप से फ़ॉर्मेट करता है।

1"hooks": {
2  "PreToolUse": [{
3    "matcher": "Bash",
4    "command": "./.claude/hooks/block-dangerous.sh"
5    // exit 2 = कॉल को चलने से पहले ब्लॉक करें
6  }],
7  "PostToolUse": [{
8    "matcher": "Edit|Write",
9    "command": "prettier --write \"$CLAUDE_FILE_PATH\""
10  }]
11}

Hooks का उपयोग किसी भी चीज़ के लिए करें जो होना चाहिए या कभी नहीं होना चाहिए - सुरक्षा, फ़ॉर्मेटिंग, ऑडिट लॉगिंग।

निर्णय कॉल के लिए उनका उपयोग न करें; उसके लिए model है। एक अच्छे harness में एक या दो तीखे hooks होते हैं, बीस नहीं।

भाग 3 · इसे चक्रवृद्धि बनाएँ

10. एक loop जोड़ें. अब harness एक टाइमर पर चलता है।

एक कॉन्फ़िगर किया गया harness अभी भी आपके टाइप करने की प्रतीक्षा करता है। एक loop इसे अपने आप चलाता है। सबसे सरल संस्करण Claude Code में /loop है - एक कैडेंस पर एक आवर्ती प्रॉम्प्ट।

इसे /goal के साथ जोड़ें और loop तब तक चलता रहता है जब तक एक उद्देश्य स्थिति सत्य नहीं हो जाती, जिसे agent द्वारा स्वयं को ग्रेड करने के बजाय एक स्वतंत्र ग्रेडर द्वारा जाँचा जाता है।

1> /loop 30m /goal सभी परीक्षण पास हो जाएँ और lint साफ हो।
2  नई विफलताओं को ट्रायेज करें, claude/ शाखाओं में फिक्स का मसौदा तैयार करें।
3
4▲ Claude आपके द्वारा बनाए गए harness का उपयोग करता है:
5  - conventions के लिए rules/
6  - प्रत्येक फिक्स की जाँच करने के लिए reviewer subagent
7  - PreToolUse hook मुख्य पर pushes को ब्लॉक करता है
8✓ Looping। स्वतंत्र ग्रेडर "हो गया" का फैसला करता है।

ध्यान दें कि अभी क्या हुआ: loop ने बुद्धिमत्ता नहीं जोड़ी। इसने harness में सब कुछ पुन: उपयोग किया - rules, reviewer subagent, सुरक्षा hook। एक अच्छा harness एक loop को तुच्छ बना देता है। पहले नींव बनाने का यही पूरा उद्देश्य है।

11. डायनामिक वर्कफ़्लो जोड़ें. Harness अपना स्वयं का ऑर्केस्ट्रेशन लिखता है।

एकल loop के लिए बहुत जटिल कार्यों के लिए - बड़े पैमाने पर समानांतर, अत्यधिक संरचित, प्रतिकूल - Claude मक्खी पर अपना स्वयं का JavaScript harness लिख सकता है।

यह एक डायनामिक वर्कफ़्लो है: स्पॉन करने के लिए agent(), फैलाने के लिए parallel(), स्ट्रीम करने के लिए pipeline()। यह आपके harness द्वारा परिभाषित subagents को फैन-आउट-एंड-सिंथेसाइज़ या विरोधी सत्यापन जैसे पैटर्न में संयोजित करता है।

Harness engineering से संबंध: एक डायनामिक वर्कफ़्लो उतना ही अच्छा होता है जितने कि वह subagents और skills जिन्हें वह कॉल कर सकता है।

यदि आपके harness में एक तेज reviewer subagent और एक अच्छी तरह से लिखित eval skill है, तो वर्कफ़्लो के पास ऑर्केस्ट्रेट करने के लिए अच्छे टुकड़े हैं। यदि harness खाली है, तो वर्कफ़्लो के पास काम करने के लिए कुछ नहीं है।

वर्कफ़्लो कंडक्टर है, आपका harness ऑर्केस्ट्रा है।

12. Memory जोड़ें. Agent जो भूलता है, harness याद रखता है।

यह वह कदम है जो एक कॉन्फ़िगर किए गए harness को एक ऐसी प्रणाली में बदल देता है जो वास्तव में सुधार करती है। Agent runs के बीच सब कुछ भूल जाता है। Harness को नहीं भूलना है।

एक state फ़ाइल - agent-memory/ में एक मार्कडाउन फ़ाइल, या एक Linear बोर्ड - रिकॉर्ड करती है कि क्या प्रयास किया गया, क्या काम किया, क्या विफल रहा, कौन से नियम बच गए।

पैटर्न जो memory को चक्रवृद्धि बनाता है, सबसे मजबूत agents द्वारा इसका उपयोग करने से लिया गया:

• दूर जाने से पहले लिखें। हर रन state फ़ाइल को अपडेट करके समाप्त होता है - सीखे गए सबक, सत्यापित तथ्य, आगे क्या है।
• शुरुआत में पढ़ें। हर रन state फ़ाइल और प्रासंगिक skills को पढ़कर शुरू होता है, ताकि यह पुनः आरंभ करने के बजाय फिर से शुरू हो।
• Skills में आसवित करें। जब कोई सबक सामान्य होता है (“Windows runners को bash चाहिए, PowerShell नहीं”), यह state फ़ाइल से एक skill में स्नातक होता है, जहाँ यह हर भविष्य के प्रोजेक्ट पर लागू होता है।

1# Project memory
2
3## Verified facts # इनके बारे में अनुमान लगाना बंद करें
4- prc डॉलर में है, सेंट में नहीं (SELECT MIN/MAX के माध्यम से जाँचा गया)
5- auth मिडलवेयर ऑर्डर: rate_limit -> jwt -> rbac
6
7## Lessons learned # सामान्य को skills में आसवित करें
8- Windows CI runners PowerShell में TLS 1.2 विफल करते हैं — bash का उपयोग करें
9- 1M पंक्तियों से अधिक तालिकाओं पर माइग्रेशन को 10k चंक्स में बैच करना चाहिए
10
11## Last session # पुनः आरंभ न करें, फिर से शुरू करें
122026-06-11 · 3 फिक्स मर्ज, 2 एस्केलेटेड। आगे: rate-limit फिक्स सत्यापित करें।

13. Loop को बंद करें. आउटपुट → सबक → skill → बेहतर आउटपुट।

यहाँ वह जगह है जहाँ तीन मंजिलें एक साथ बंद होती हैं जो खुद में सुधार करती हैं। हर रन आउटपुट पैदा करता है। Reviewer subagent (चरण 7) इसकी जाँच करता है।

परिणाम - क्या पास हुआ, क्या विफल हुआ, क्या सीखा गया - memory में लिखा जाता है (चरण 12)। सामान्य सबक skills में आसवित होते हैं (चरण 8)।

अगला रन तेज skills और समृद्ध memory प्राप्त करता है।

यह पूरा स्व-सुधार लूप है, और ध्यान दें कि यह पूरी तरह से harness भागों से बनाया गया है:

• Subagent काम को ग्रेड करता है - उद्देश्य जाँच, ताज़ा context।
• Memory फैसले को रिकॉर्ड करता है - runs के बीच बचता है।
• Skills आसवित सबक रखते हैं - हर रन पिछले रन से सीखता है।
• Loop इसे फिर से चलाता है - अब पिछले रन ने जो कुछ सीखा, उसके साथ।

Model कभी नहीं बदला। इसके चारों ओर का harness तेज हो गया। "स्व-सुधार" का ईमानदारी से यही मतलब है - एक model जो सीखता है नहीं, बल्कि एक harness जो संचित करता है।

14. Harness को शिप करें. इसे पैकेज करें। साझा करें। पुन: उपयोग करें।

एक harness जो एक प्रोजेक्ट पर काम करता है, एक संपत्ति है।

Skills, subagents, और rules को एक plugin में बंडल करें और आपकी पूरी टीम एक कदम में समान सेटअप इंस्टॉल करती है - समान conventions, समान सुरक्षा hooks, समान reviewer।

Harness आपकी व्यक्तिगत सेटअप होना बंद कर देता है और साझा बुनियादी ढाँचा बन जाता है।

बनाने का क्रम, एक आखिरी बार, क्योंकि क्रम ही सबक है: **एक साफ harness पर एक मैनुअल रन को विश्वसनीय बनाएँ।।

Context और permissions जोड़ें। एक reviewer subagent जोड़ें। Memory जोड़ें। फिर और तभी इसे एक loop में लपेटें। एक अच्छे harness पर एक loop चक्रवृद्धि करता है। एक बुरे harness पर एक loop बस तेजी से खून बहाता है।

§ वे harness गलतियाँ जो हर loop को बदतर बनाती हैं

• डिफ़ॉल्ट पर चलाना। कोई context नहीं, कोई rules नहीं, कोई memory नहीं - agent हर सत्र में आपके प्रोजेक्ट को फिर से प्राप्त करता है।
• एक फूला हुआ CLAUDE.md। स्थायी context में ठूँसी गई प्रक्रियाएँ, हर रन को फुलाती हैं। उन्हें skills में ले जाएँ।
• CLAUDE.md में hooks के बजाय प्रवर्तन। Model एक सुझाव को अनदेखा कर सकता है। यह एक hook को अनदेखा नहीं कर सकता जो 2 से बाहर निकलता है।
• एक agent अपना काम लिखना और ग्रेड करना। एक ताज़ा context window के साथ एक reviewer subagent जोड़ें।
• कोई memory नहीं। हर रन शून्य से पुनः आरंभ होता है। State फ़ाइल वह है जो कल को फिर से शुरू करने में सक्षम बनाती है।
• एक बुरे harness के चारों ओर एक loop लपेटना। Loop बस तेजी से घटिया आउटपुट पैदा करता है। पहले नींव बनाएँ।
• बीस hooks। एक या दो तीखे hooks एक ढेर को हराते हैं जिसे कोई नहीं समझता।
• बिना स्कैन किए एक harness शिप करना। लीक हुए रहस्य और अत्यधिक व्यापक permissions उन सभी में फैल जाते हैं जो इसे इंस्टॉल करते हैं।

निष्कर्ष:

Loop को महिमा मिलती है। Harness काम करता है।

Loop engineering रोमांचक हिस्सा है - agent खुद को प्रॉम्प्ट कर रहा है, जब आप सो रहे हों तब चल रहा है। लेकिन एक loop सिर्फ एक टाइमर पर एक harness है।

सब कुछ जो तय करता है कि आउटपुट अच्छा है या कचरा, एक मंजिल नीचे रहता है, उस model में जिसे आपने चुना, उन tools में जिनकी आपने अनुमति दी, उस context में जो आपने लिखा, उस reviewer में जिसे आपने जोड़ा, उस memory में जिसे आपने रखा।

उस मंजिल को अच्छी तरह से बनाएँ और इसके ऊपर सब कुछ चक्रवृद्धि करता है: loop आपके subagents का पुन: उपयोग करता है, वर्कफ़्लो आपकी skills को ऑर्केस्ट्रेट करता है, memory हर रन को पिछले एक से तेज बनाती है।

स्व-सुधार कभी model का गुण नहीं था। यह उस harness का गुण है जिसे आप इसके चारों ओर बनाते हैं।

एक चीज़ चुनें जो आप नहीं कर रहे हैं - शायद एक reviewer subagent, एक सुरक्षा hook, या एक state फ़ाइल — और इसे आज जोड़ें। Harness को इतना छोटा रखें कि समझाया जा सके। फिर शीर्ष पर एक loop लगाएँ, और नींव को काम करते देखें।