2026 में REPL की तुलना में एजेंट के लिए हेरेडोक-शैली निष्पादन बेहतर क्यों है?

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

उस अंतर्दृष्टि ने सीएलआई-प्रथम सॉफ़्टवेयर की ओर व्यापक आंदोलन को बढ़ावा देने में मदद की। जटिल अनुप्रयोगों को एजेंट के लिए सुलभ बनाने के लिए कमांड-लाइन इंटरफेस मानक तरीके की तरह दिखने लगे, जिससे एक परिचित नारा सामने आया:

सीएलआई वह सब कुछ है जिसकी आपको आवश्यकता है।

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

एजेंट को जटिल शेल स्क्रिप्ट इकट्ठा करने के लिए कहने के बजाय, हम उन्हें उस प्रोग्रामिंग भाषा में कार्यों का समन्वय करना पसंद करेंगे जिसे वे पहले से ही समझते हैं। इससे थोड़ा अलग आर्किटेक्चर बनता है:

सीएलआई को सार्वभौमिक प्रवेश बिंदु के रूप में रखें, लेकिन सॉफ़्टवेयर के साथ इंटरैक्ट करने के वास्तविक तरीके के रूप में कोड का उपयोग करें।

एजेंट कोड का एक ब्लॉक सबमिट करता है जिसमें संचालन, निर्णय और डेटा प्रोसेसिंग शामिल होती है जो अन्यथा इंटरैक्शन के कई दौरों में फैल जाएगी। स्थानीय रनटाइम तब वर्कफ़्लो निष्पादित करता है।

ego-browser इसी विचार के आधार पर बनाया गया था। इसका सीएलआई एक प्रोग्राम करने योग्य वातावरण लॉन्च करता है, ब्राउज़र फ़ंक्शंस के एक छोटे सेट के माध्यम से अपनी क्षमताओं को उजागर करता है, और एजेंट उन फ़ंक्शंस को बनाने के लिए अपने मौजूदा प्रोग्रामिंग कौशल का उपयोग करता है और उन्हें व्यवस्थित करें.

इस लेख में हम तुलना करते हैं हेरेडोक और REPL, सीएलआई के माध्यम से कोड निष्पादित करने के दो तरीके, और ego-browser से प्रयोगात्मक परिणाम साझा करें। हेरेडोक के साथ, एजेंट ने समान कार्यों को 44% कम निष्पादन राउंड में, 35.5% कम टूल कॉल के साथ, 21.6% कम लागत पर पूरा किया।

"सीएलआई ही आपकी ज़रूरत है" - फिर क्या?

यह दावा कि "सीएलआई ही आपकी ज़रूरत है" मानता है कि मॉडल पहले से ही जानता है कि उस सीएलआई का उपयोग कैसे करना है।

Git, Docker और FFmpeg जैसे प्रसिद्ध टूल के लिए, यह आमतौर पर कोई समस्या नहीं है। मॉडलों ने प्रशिक्षण के दौरान अनगिनत कमांड, ट्यूटोरियल, स्क्रिप्ट और त्रुटि संदेश देखे हैं, और पहले से ही तर्क जानते हैं और कमांड एक साथ कैसे फिट होते हैं।

लेकिन जब हम एजेंट के लिए बिल्कुल नया सीएलआई बनाते हैं, तो तस्वीर बदल जाती है। प्रत्येक सीएलआई के अपने उप-आदेश, तर्क, आउटपुट स्वरूप और त्रुटि शब्दार्थ हैं। मॉडल के लिए, यह मूलतः एक नई लघु-भाषा है। पूर्ण दस्तावेज़ीकरण के बाद भी, मॉडल को पहले नियमों को सीखना होगा, फिर बार-बार कॉल के माध्यम से पता लगाना होगा कि आदेश एक साथ कैसे फिट होते हैं।

इसके बजाय JavaScript एपीआई, या किसी अन्य भाषा में एपीआई के समान क्षमताओं को उजागर करें, और मॉडल को अभी भी नई डोमेन अवधारणाओं को सीखना होगा, लेकिन इसे अब नियंत्रण प्रवाह, डेटा संरचनाओं, या संरचना को फिर से सीखने की आवश्यकता नहीं है। लूप्स, स्थितियाँ, अपवाद हैंडलिंग और डेटा प्रोसेसिंग सभी एक प्रोग्रामिंग भाषा में रहते हैं जिसे वह पहले से जानता है।

एक सरल कार्य करें: एक वेबपेज खोलें और उसका मुख्य शीर्षक पढ़ें। यदि ego-browser ने पारंपरिक कमांड-शैली इंटरफ़ेस को उजागर किया है, तो एजेंट को इसे पूरा करने के लिए कई चरणों की आवश्यकता हो सकती है:

# First call: open the page
ego-browser open https://example.com

# Tool response: the page is open

# Second call: locate the main heading
ego-browser find --role heading

# Tool response: a heading was found

# Third call: read the heading
ego-browser read --role heading

प्रत्येक चरण के बाद, एजेंट टूल की प्रतीक्षा करता है, परिणाम पढ़ता है, और निर्णय लेता है कि आगे क्या करना है।

कोड इंटरफ़ेस ego-browser वास्तव में उपयोग करने से यह संपूर्ण वर्कफ़्लो को एक ही बार में व्यक्त करने देता है:

await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);

दोनों दृष्टिकोणों से एक ही कार्य संपन्न होता है। कमांड-शैली इंटरफ़ेस प्रक्रिया को मॉडल-टूल इंटरैक्शन के कई दौरों में विभाजित करता है; कोड इंटरफ़ेस एजेंट को पूरी प्रक्रिया को एक बार लिखने और स्थानीय रनटाइम को सौंपने की सुविधा देता है।

यह बिल्कुल वही डिज़ाइन विचार है जिसका उल्लेख पहले किया गया था: सीएलआई को सार्वभौमिक प्रवेश बिंदु के रूप में रखें, लेकिन सॉफ़्टवेयर के वास्तविक इंटरफ़ेस के रूप में कोड का उपयोग करें। यह कॉल करने और एकीकृत करने में आसान होने के सीएलआई के लाभ को बरकरार रखता है, जबकि मॉडल को रचना और ऑर्केस्ट्रेशन के लिए पहले से मौजूद प्रोग्रामिंग कौशल का उपयोग करने देता है।

जब सीएलआई कोड का प्रवेश द्वार बन जाता है

एक बार जब सीएलआई कोड स्वीकार कर लेता है, तो अगला सवाल यह होता है कि एजेंट को उस कोड को निष्पादन वातावरण में कैसे सौंपना चाहिए?

कड़ाई से बोलते हुए, हेरेडोक शेल इनपुट सिंटैक्स है और REPL एक दुभाषिया का निष्पादन मोड है; दोनों एक ही अमूर्त परत पर नहीं हैं। यह लेख वास्तव में जो तुलना करता है वह ego-browser में एक हेरेडोक के माध्यम से दर्ज किए गए एक-शॉट कोड निष्पादन की तुलना है, बनाम एक REPL पर निर्मित लगातार इंटरैक्टिव सत्र की। संक्षिप्तता के लिए, हम यहां से उन्हें हेरेडोक और REPL ही कहेंगे।

एक विकल्प हेरेडोक है। ego-browser में, एजेंट एक बार में JavaScript का पूरा ब्लॉक सबमिट करता है:

ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOF

शेल कोड को ego-browser पर भेजता है, इसके समाप्त होने की प्रतीक्षा करता है, परिणाम प्राप्त करता है, और बाहर निकल जाता है। एजेंट के लिए, यह एक पारंपरिक टूल कॉल की तरह व्यवहार करता है:

Submit command → wait for process → receive result

एक REPL अलग तरह से काम करता है। दुभाषिया जीवित रहता है, जिससे एजेंट को चर और सत्र स्थिति को बनाए रखते हुए बार-बार कोड दर्ज करने की अनुमति मिलती है:

> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}

> await page.getByRole("heading").textContent()
< "Example Domain"

अभिव्यंजक शक्ति की दृष्टि से, दोनों मूलतः समकक्ष हैं। एक REPL एक ही बार में लूप, शर्तों और अपवाद हैंडलिंग के साथ एक पूरा प्रोग्राम चला सकता है, और एक हेरेडोक सिर्फ एक लाइन सबमिट कर सकता है।

स्पष्ट अंतर प्रक्रिया जीवनचक्र है। हेरेडोक के साथ, जैसे ही कोड चलना समाप्त होता है, प्रक्रिया समाप्त हो जाती है; एक REPL दुभाषिया प्रक्रिया को जीवित रखता है, आगे के इनपुट की प्रतीक्षा करता है। इसका मतलब यह भी है कि दोनों एजेंट टूल पर अलग-अलग मांग रखते हैं। एक हेरेडोक सीधे परिचित अनुरोध-प्रतिक्रिया मॉडल पर चलता है:

submit the command → wait for the process to exit → get the result

REPL टूल के बारे में अधिक पूछता है: लगातार प्रक्रियाएं, सत्र प्रबंधन, निरंतर इनपुट, रुकावट और पुनर्प्राप्ति। अधिकांश एजेंट के अंतर्निर्मित Bash टूल में ये क्षमताएं नहीं होती हैं। आज मुख्यधारा के उत्पादों में से केवल Codex ही उनका यथोचित समर्थन करता है। और REPL का उपयोग करने के लिए टूल समर्थन केवल एक आवश्यक शर्त है। यह तय नहीं करता कि मॉडल वास्तव में इसका उपयोग कैसे करेगा। यहां तक ​​कि जब दोनों वातावरण एक ही कोड चला सकते हैं, तब भी मॉडल प्रत्येक में अलग-अलग कोड लिख सकता है।

मॉडल प्रत्येक वातावरण में कोड कैसे लिखते हैं

सिद्धांत रूप में, एक मॉडल में दोनों वातावरणों में समान प्रोग्रामिंग क्षमता होती है। व्यवहार में, हमने लगातार व्यवहारिक अंतर देखा:

• REPL में, मॉडल क्रमिक रूप से कोड दर्ज करता है।
• हेरेडोक में, एक बार में पूरा कार्यक्रम तैयार करने की अधिक संभावना है।

मनुष्यों के लिए सॉफ़्टवेयर को एर्गोनॉमिक्स का ध्यान रखना चाहिए। एजेंट के लिए सॉफ़्टवेयर को एक समान अनुशासन की आवश्यकता है: इसे कॉल करें मॉडल-अनुभव इंजीनियरिंग. एक इंटरफ़ेस को प्रशिक्षण के दौरान विकसित व्यवहार पैटर्न मॉडल के साथ काम करना चाहिए।

REPL और हेरेडोक के बीच का अंतर उनके प्रशिक्षण डेटा के वितरण को दर्शाता है।

REPL उदाहरण आमतौर पर ट्यूटोरियल, डिबगिंग सत्र और प्रश्न-उत्तर आदान-प्रदान से आते हैं। उनका विशिष्ट पैटर्न खोजपूर्ण है:

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

हेरेडोक कोड ब्लॉक स्क्रिप्ट या स्रोत फ़ाइलों की तरह दिखते हैं। उनके पास स्पष्ट शुरुआत और समाप्ति सीमाएँ हैं, जो मॉडल को निरंतर वर्कफ़्लो उत्पन्न करने के लिए प्रोत्साहित करती हैं:

const page = await openPage();
const element = await findElement(page);
const text = await readText(element);

console.log(text);

इसका मतलब यह नहीं है कि REPL संपूर्ण कार्यक्रम चलाने में असमर्थ है। मॉडल एक चरण में कोड का एक ही ब्लॉक REPL को सबमिट कर सकता है।

भेद प्रासंगिक है. एक REPL प्रोत्साहित करता है निष्पादित करना, निरीक्षण करना, जारी रखना पैटर्न. एक हेरेडोक एक को प्रोत्साहित करता है पहले व्यवस्थित करें, फिर निष्पादित करें पैटर्न.

वह प्रवृत्ति यह भी निर्धारित करती है कि नियंत्रण प्रवाह कहाँ रहता है। REPL में, मॉडल द्वारा कार्य को कई चरणों में विभाजित करने और प्रत्येक परिणाम के बाद क्या करना है यह तय करने की अधिक संभावना है। हेरेडोक में, लूप, शर्तें, फ़िल्टरिंग और डेटा प्रोसेसिंग को सीधे प्रोग्राम में डालने और स्थानीय रनटाइम को उन्हें संभालने देने की अधिक संभावना है।

प्रयोगों से क्या पता चला

मुख्यधारा के एजेंट टूल के बीच हम विश्वसनीय रूप से एकीकृत कर सकते हैं, Codex ने निष्पादन क्षमताओं को प्रदान किया है जो लगातार REPL की आवश्यकता होती है। इसलिए हमने Codex SDK पर एक स्वचालित बेंचमार्क बनाया: एक ही एजेंट ने REPL और हेरेडोक दोनों के माध्यम से चार प्रकार के वास्तविक ब्राउज़र कार्यों को पूरा किया, और हमने तुलना के लिए बार-बार चलाए गए परिणामों को एकत्रित किया।

कार्य थे:

• एक्स ट्रेंडिंग-पोस्ट विश्लेषण: पिछले सात दिनों से OpenAI की मूल पोस्ट एकत्र करें, पिन किए गए पोस्ट, रीपोस्ट और उत्तरों को बाहर करें, दृश्यों के आधार पर शीर्ष पांच को रैंक करें, और उनकी सहभागिता दर और समग्र औसत की गणना करें।
• OpenAI नौकरी आवेदन: सैन फ्रांसिस्को में सही क्लाउड इन्फ्रास्ट्रक्चर स्थिति ढूंढें, एक बायोडाटा अपलोड करें, आवेदन पत्र पूरा करें, और अंतिम सबमिशन से पहले रुकें।
• Redfin बंधक गणना: ऑस्टिन में संपत्तियों को घर के प्रकार और कीमत के आधार पर फ़िल्टर करें, सॉर्ट करने के बाद पहला परिणाम खोलें, डाउन पेमेंट को 20% में बदलें, और अद्यतन अनुमानित मासिक भुगतान पुनः प्राप्त करें।
• Expedia उड़ान खोज: जेएफके से एमआईए के लिए एकतरफ़ा, नॉनस्टॉप उड़ान ढूंढें, निर्दिष्ट एयरलाइन से सबसे सस्ता विकल्प चुनें, यात्री की जानकारी दर्ज करें, और भुगतान से पहले रुकें।

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

दोनों दृष्टिकोणों ने अधिकांश कार्य पूरे कर लिए। REPL के लिए 75.0% की तुलना में हेरेडोक ने 77.5% सफलता दर हासिल की। विश्वसनीयता में अंतर मामूली था.

बड़ा अंतर दक्षता का था:

• औसत पूरा होने का समय गिर गया 35.0%.
• औसत पूरा होने का समय गिर गया 30.7%.
• टूल कॉलें कम हो गईं 35.5%.
• टोकन खपत में गिरावट आई 29.8%.
• औसत लागत में गिरावट आई 21.6%.

हालाँकि एक REPL रनटाइम स्थिति का पुन: उपयोग कर सकता है, लेकिन उस लाभ से कम इंटरैक्शन उत्पन्न नहीं हुई। व्यवहार में, हेरेडोक एजेंट ने कम टूल कॉल किए।

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

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

हमने ओडिसी डेटासेट पर समान REPL-आधारित ब्राउज़र ऑटोमेशन उत्पाद के साथ ego-browser की तुलना करके यह भी जांच की कि क्या समान पैटर्न बड़े पैमाने पर कायम है। उपरोक्त नियंत्रित प्रयोग के विपरीत, इस तुलना में दो इंटरफेस के माध्यम से संचालित होने वाले एक ही मॉडल के बजाय दो पूर्ण उत्पाद शामिल थे। इसलिए यह समग्र दक्षता तुलना के रूप में उपयोगी है, लेकिन इसके अंतर को पूरी तरह से हेरेडोक बनाम REPL के लिए जिम्मेदार नहीं ठहराया जा सकता है।

यह हेरेडोक के लिए स्थायी जीत नहीं है

हम नहीं मानते कि हेरेडोक स्वाभाविक रूप से REPL से बेहतर है।

हमारा निष्कर्ष मॉडलों की क्षमताओं, उनके प्रशिक्षण डेटा के वितरण और एजेंट टूल के डिज़ाइन पर निर्भर करता है क्योंकि वे 2026 में मौजूद हैं।

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

वे स्थितियाँ शीघ्रता से बदल सकती हैं।

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

यदि ऐसा होता है, तो REPL अधिक मॉडल कॉल की आवश्यकता के बिना राज्य के पुन: उपयोग और तत्काल प्रतिक्रिया के लाभों को संरक्षित कर सकते हैं। वे महंगी आरंभीकरण, लंबे समय तक चलने वाली स्थिति, या वास्तव में खोजपूर्ण वर्कफ़्लो वाले कार्यों के लिए भी बेहतर विकल्प बन सकते हैं।

इसीलिए शीर्षक निर्दिष्ट करता है 2026. हम कोई स्थायी कानून खोजने का दावा नहीं कर रहे हैं। यह आज उपलब्ध मॉडलों और एजेंट टूलींग के आधार पर एक पॉइंट-इन-टाइम इंजीनियरिंग निर्णय है।