स्वायत्त एजेंट लूप का डिज़ाइन ── प्रॉम्प्ट से आगे की आर्किटेक्चर

※यह लेख आंतरिक दस्तावेज़ (आरेख प्रारूप) के आधार पर तैयार किया गया है (पांडुलिपि प्रारूप में पुनर्गठित)। विषय कोड लिखने, समीक्षा करने और मर्ज करने के कार्य को उस समय भी जारी रखने की डिज़ाइन है जब मनुष्य सो रहा हो – एक लचीली बहु-एजेंट "Generator-Evaluator" आर्किटेक्चर।

"मानव घड़ी" का अंत

पारंपरिक AI उपयोग "मानव घड़ी" द्वारा संचालित होता था। एजेंट इनपुट की प्रतीक्षा करते हैं, मनुष्य Enter दबाता है, टोकन उत्पन्न होते हैं, और यह रुक जाता है। यह दोहराव था। जून 2026 में एक मोड़ आया। Peter Steinberger (OpenClaw), Boris Cherny (Claude Code), और Addy Osmani (Chrome) ने एक ही सप्ताह में स्वतंत्र रूप से एक ही समझ तक पहुंचा। उपकरण एक सीमा पार कर गए हैं।

बदलाव का सार यह है: एजेंट को प्रॉम्प्ट देने वाला व्यक्ति होना बंद करें, और इसके बजाय ऐसी प्रणाली को डिज़ाइन करने वाला व्यक्ति बन जाएं जो यह करे। स्वायत्त लूप इंजन के तीन गुण हैं: (1) टाइमर द्वारा सक्रिय होता है (अनुसूची से जागता है), (2) समानांतर उप-एजेंट (सहायक) उत्पन्न करता है, (3) अपने आप को आपूर्ति करता है (कल का आउटपुट आज का इनपुट बन जाता है)।

AI प्रोटोकॉल स्टैक की 4 परतें

AI उपयोग की परतों को 4 में व्यवस्थित किया जा सकता है, और ऊपरी परतें जितनी अधिक होती हैं, विफलता के प्रभाव की पहुंच (ब्लास्ट त्रिज्या) उतनी बड़ी होती है।

परत	मूल चिंता का विषय	सीमा की इकाई	विफलता का प्रभाव क्षेत्र	मनुष्य की स्थिति
परत 1: प्रॉम्प्ट	मॉडल को क्या बताना है	एक बार की बातचीत	तुरंत स्पष्ट गलत उत्तर	टाइपिस्ट
परत 2: प्रसंग	विंडो में क्या डालना है	एक सत्र	आत्मविश्वास से भरा गलत तर्क	संपादक
परत 3: हार्नेस	एक निष्पादन को सशस्त्र करें (उपकरण/क्रिया)	एक कार्य	शिपिंग से पहले पकड़े गए खराब अंतर	समीक्षक
परत 4: लूप	हार्नेस की अनुसूची	मानवरहित पुनरावृत्ति	दिनों की इकाई में आगे बढ़ने वाला, संरचना को खाने वाला संक्षारण	आर्किटेक्ट

घूमते हुए लूप का शरीर रचना

स्वायत्त लूप 5 नोड्स से बना है।

1. खोज (Discovery) ── Skills (SKILL.md) द्वारा समर्थित। प्रोजेक्ट का स्थायी ज्ञान, और "इरादे का कर्ज" चुकाता है।

2. हस्तांतरण (Handoff) ── Worktrees द्वारा समर्थित। समानांतर निष्पादन के लिए स्वतंत्र git निर्देशिकाएं।

3. सत्यापन (Verification) ── उप-एजेंट द्वारा समर्थित। Generator-Evaluator का पृथक्करण। "नहीं कह सकने वाली इकाई।"

4. स्थायित्व (Persistence) ── कनेक्टर (MCP) और स्मृति द्वारा समर्थित। स्थिति डिस्क पर फ़ाइलों (जैसे ./state/triage.md) में रखी जाती है। एजेंट भूलते हैं, लेकिन रिपोजिटरी नहीं भूलती।

5. अनुसूचन (Scheduling) ── स्वचालन अवसंरचना (स्थानीय cron, GitHub Actions, क्लाउड रूटीन) द्वारा समर्थित। चक्र को बंद करता है।

Worktree समानांतरकरण

समस्या: दो एजेंट एक ही कार्य निर्देशिका को संपादित करना उसी तरह है जैसे दो इंजीनियर एक ही पंक्ति में प्रतिबद्ध हों। टकराव मानवरहित पाइपलाइन को तोड़ देते हैं। प्रिमिटिव: claude --worktree fix/auth-test 'draft the fix' की तरह, स्वतंत्र कार्य निर्देशिकाओं को अलग करें। प्रभाव: समानांतरकरण को "काम करता है लेकिन गड़बड़ा हुआ" से "काम करता है और स्वच्छ" में बदल देता है। एक रिपोजिटरी के भीतर कई स्वतंत्र कार्य निर्देशिकाएं उच्च थ्रूपुट मुद्दा ट्रिएज को संभव बनाती हैं।

आत्म-विश्वास बुलबुला ── Generator और Evaluator को अलग करना

एंटीपैटर्न यह है कि जनरेटर (Generator) अपने अपने होमवर्क को स्वयं चेक करता है। जनरेटर अपने कोड को नहीं देख रहा है, बल्कि अपने आत्म-विश्वास की श्रृंखला को देख रहा है। इसके विपरीत, GAN विभाजन में, जनरेटर और मूल्यांकनकर्ता (Evaluator) को अलग किया जाता है, और मूल्यांकनकर्ता को प्रतिकूल कोड समीक्षक की भूमिका दी जाती है। "यह कोड खंडित माना जाता है जब तक कि प्रतिखंडित न हो। प्रशंसा न करें। विफल होने के स्थान खोजें।"

मूल अंतर्दृष्टि: एक स्वतंत्र मूल्यांकनकर्ता को कठोर संदेह करने के लिए ट्यून करना, जनरेटर को अपने परिणामों के प्रति आलोचनात्मक बनाने की तुलना में गणितीय और व्यावहारिक दोनों रूप से बहुत अधिक संभव है।

बाहरी निष्पादन द्वारा निर्णय

दोष: यदि मूल्यांकनकर्ता केवल कोड पढ़ता है, तो निर्णय "सही दिखता है" है न कि "सही तरीके से काम करता है"। बदलाव: मूल्यांकनकर्ता को एक बाहरी निष्पादन वातावरण (उदाहरण: Playwright MCP) से जोड़ा जाता है। नया मानक: मूल्यांकनकर्ता बटन दबाता है, स्क्रीन संक्रमण को मजबूर करता है, DOM स्थिति प्राप्त करता है, और परीक्षण चलाता है। निर्णय "इरादे" से "व्यवहार" में चला जाता है। मूल्यांकन एजेंट → Playwright MCP कनेक्टर → DOM निरीक्षण/स्क्रीनशॉट/परीक्षण रनर → पास/विफल निर्णय का प्रवाह।

Maker-Checker की रोक शर्तें

लूप कब समाप्त होना चाहिए। /goal प्रिमिटिव "जब तक शर्त पूरी न हो तब तक चलाएं" को व्यक्त करता है (उदाहरण: /goal test/auth के सभी परीक्षण पास हों और lint स्वच्छ हो)। Generator (भारी मॉडल) कोड लिखता है, Evaluator (भारी मॉडल) MCP के माध्यम से परीक्षण चलाता है, Gatekeeper (तेज़, ताज़ा मॉडल) /goal का मूल्यांकन करता है। यदि पूरी होती है तो लूप बाहर निकलें, विफलता पर अस्वीकृति कारण Generator को वापस भेजें।

सिद्धांत: पूर्णता का निर्णय उस मॉडल के संदर्भ के सामान द्वारा नहीं किया जाना चाहिए जिसने काम किया, बल्कि एक ताज़ा मॉडल द्वारा किया जाना चाहिए। और याद रखने के लिए एक शब्द है: लूप का फर्श मूल्यांकनकर्ता है। जनरेटर जो बनाया जाता है उसकी छत निर्धारित करता है, और मूल्यांकनकर्ता जो नहीं बनाया जाता है उसका फर्श निर्धारित करता है।

लूप 5 तरीकों से विफल होता है

लापता तत्व	एंटीपैटर्न	लक्षण	आवश्यक सुधार
सत्यापन की कमी	केवल अनुमति देने वाला लूप	100 मोड़, अपने कचरे को मंजूरी देते रहो	Generator-Evaluator विभाजन का कार्यान्वयन
दृढ़ता की कमी	स्मृति हानि वाला लूप	हर सुबह बिल्कुल वही काम फिर से खोजता है	स्थिति फ़ाइल की डिस्क लेखन को मजबूर करें
अनुसूचन की कमी	मैनुअल लूप	जिस दिन डेमो किया गया उसके बाद से कभी नहीं चला	cron/इवेंट ट्रिगर को कनेक्ट करें
खोज की कमी	अंधा लूप	अभी भी हर बार 30 मिनट इस कोड में लगाते हुए "इस बग को ठीक करो"	अनुमानिकों को SKILL.md में एंबेड करें
हस्तांतरण की कमी	उलझा हुआ लूप	5 समानांतर एजेंट एक git निर्देशिका को नष्ट करते हैं	--worktree द्वारा विभाजन को मजबूर करें

उद्यम-स्केल निर्धारणवादी इंटरलीविंग

Stripe की "Minions" पाइपलाइन ट्रिगर (Slack) → संदर्भ आर्केस्ट्रेटर (Sourcegraph/Jira) → कोड जनरेशन (LLM) → आवश्यक लिंटर गेट → Lint फिक्स (LLM) → Git कमिट → मानव समीक्षा (सप्ताह में 1,300 PR) का प्रवाह है, सप्ताह में 1,300 मशीन-जनित PR मर्ज करता है (Goose ओपन सोर्स फ्रेमवर्क द्वारा संचालित)।

रहस्य निर्धारणवादी प्रणालियों को निर्धारणवादी काम करना है। संदर्भ संग्रह और lint कड़ाई से हार्डकोड किए गए हैं, और LLM को कठोर नियमों द्वारा गार्ड किए गए परिपत्र के अंदर पूरी तरह से बंद कर दिया जाता है। वातावरण को "पालतू नहीं बल्कि मवेशी" के रूप में माना जाता है, और EC2 पर Devbox को राज्य की भ्रष्टाचार से बचने के लिए तुरंत बदल दिया जाता है और त्याग दिया जाता है।

निष्पादन टोपोलॉजी ── लूप कहाँ रहता है

टोपोलॉजी	मशीन की स्थिति	सत्र	न्यूनतम अंतराल	क्लाउड (क्लाउड रूटीन / GitHub Actions)
मशीन ऑफ हो सकती है	आवश्यक नहीं है	1 घंटा	कोई नहीं (स्वच्छ क्लोन) → रात्रिकालीन ट्रिएज के लिए आदर्श	डेस्कटॉप (macOS cron)
मशीन चालू	आवश्यक नहीं है	1 मिनट	हाँ → नियमित रिपोजिटरी रखरखाव के लिए आदर्श	स्थानीय (/loop कमांड)
मशीन चालू	आवश्यक है	1 मिनट	हाँ → विकास के दौरान उच्च आवृत्ति जांच के लिए आदर्श	あり → विकास में उच्च-आवृत्ति जांच के लिए इष्टतम

लोकल रीएक्सीक्यूशन को "सोते हुए भी चल रहा है" कहना अतिशयोक्ति है। लोकल शेड्यूलिंग आवृत्ति खरीदती है, जबकि क्लाउड शेड्यूलिंग असली स्वायत्तता खरीदती है। एक शेड्यूलर से आप दोनों नहीं पा सकते।

निरीक्षण किए बिना लूप का दुष्चक्र

स्वायत्त लूप में चार जोखिम हैं। सत्यापन का कर्ज (परीक्षण पास होते हैं लेकिन सूक्ष्म तर्क दोष वाले कोड को मर्ज करना) → समझ का क्षरण (कोडबेस के मानसिक मानचित्र वास्तविकता से अलग होना) → संज्ञानात्मक समर्पण ("मुझे पता नहीं कि यह कैसे काम करता है, लेकिन आइए PR स्वीकार करें") → टोकन की बर्बादी (निगरानी रहित एजेंट रात भर हेल्पर्स उत्पन्न करते हैं और बेकार बग फिक्स को बार-बार करते रहते हैं)। ये चार अलग-अलग जोखिम नहीं हैं, बल्कि एकल मिश्रित विफलता का तरीका हैं। कठोर मूल्यांकनकर्ता के बिना एक लूप अपने बग को खर्च निर्णय का अधिकार सौंप रहा है।

शून्य लागत जनन की अर्थव्यवस्था

जो प्रचुर हो जाएगा: निर्माण। कोड, योजना, सुधार, और पुल अनुरोध की लागत वास्तव में शून्य की ओर बढ़ रही है, और यांत्रिक श्रम ढह जाएगा। जो दुर्लभ बना रहेगा: निर्णय। लूप 100 कार्यान्वयन उम्मीदवार उत्पन्न कर सकता है, लेकिन उनका चयन "सही दिखता है" के आधार पर है, "वास्तव में सही है" के आधार पर नहीं। एक एम्पलीफायर के रूप में लूप: लूप एक वफादार गुणन प्रतीक है। यदि आप समझ लाते हैं, तो यह समझ को बढ़ाता है; यदि आप आलस लाते हैं, तो यह आपदा को बढ़ाता है।

परिचालन सर्किट ब्रेकर

1. शिपिंग से पहले सीमा निर्धारित करें (टोकन बर्बादी के विरुद्ध रक्षा): प्रति निष्पादन बजट सीमा या अधिकतम पुनः प्रयास संख्या बचत के लिए नहीं, बल्कि खुली जोखिम को बंधी जोखिम में बदलने के लिए सर्किट ब्रेकर हैं।

2. एक दरवाजा खुला रखें (संज्ञानात्मक आत्मसमर्पण के विरुद्ध रक्षा): मानव के लिए कम से कम एक चेकपॉइंट बनाएं। हर बार हस्तक्षेप करने के लिए नहीं, बल्कि यह गारंटी देने के लिए कि आप हस्तक्षेप कर सकते हैं।

3. एक दरवाज़ा खुला रखें（संज्ञानात्मक समर्पण के विरुद्ध सुरक्षा）: मानव के लिए कम से कम एक चेकपॉइंट बनाएं जहां विराम हो सके। हर बार हस्तक्षेप करने के लिए नहीं, बल्कि हस्तक्षेप करने की क्षमता सुनिश्चित करने के लिए।

न्यूनतम弹性युक्त लूप तैनात करें

न्यूनतम कॉन्फ़िगरेशन इस प्रकार है: शेड्यूल (cron: क्लाउड स्वचालन) द्वारा शुरू किया जाता है, कौशल (morning-triage: खोज) को निष्पादित किया जाता है, और परिणाम ./state/triage.md (स्थायित्व) में लिखे जाते हैं। खोजी गई मरम्मत को वर्कट्री (fix/$finding: हस्तांतरण) में लागू किया जाता है, और "/goal (सत्यापन)" द्वारा निर्धारित किया जाता है जो "परीक्षाएं पास होती हैं और lint स्वच्छ है"। आउटपुट फ़ोल्डर ./inbox/ (सभी असत्यापित), ./state/, और ./src/ में विभाजित हैं, स्वचालित मर्ज कभी नहीं किया जाता है। असत्यापित सभी चीजें ./inbox/ में रखी जाती हैं यह मूलनीति है।

अंत में, मैं इन शब्दों के साथ समापन करता हूं।

「लूप बनाओ। लेकिन एक इंजीनियर के रूप में बने रहते हुए बनाओ। केवल बटन दबाने वाले व्यक्ति के रूप में नहीं।」