कोडिंग एजेंट के घटक
(magazine.sebastianraschka.com)- कोडिंग एजेंट एक ऐसी प्रणाली है जो LLM-केंद्रित control loop और software harness से बनी होती है, और कोड लिखने, चलाने तथा feedback के दोहराव वाले चक्र में काम करती है
- एजेंट harness context management, tool access, prompt composition और state control संभालता है, जबकि कोडिंग कार्यों के लिए विशेष coding harness repository, test और error checking को प्रबंधित करता है
- कोडिंग एजेंट live repo context, prompt cache, tool access, context management, session memory, subagent delegation — इन छह घटकों पर काम करता है
- harness design की गुणवत्ता के अनुसार, एक ही LLM होने पर भी performance और user experience में बड़ा अंतर आ सकता है, और अच्छी तरह डिज़ाइन किया गया harness अधिक सतत और context-aware development environment देता है
- Mini Coding Agent इस संरचना का pure Python में बना एक minimal example है, और OpenClaw से इसका अंतर coding specialization और operational scope में है
कोडिंग एजेंट के घटक
- कोडिंग एजेंट एक ऐसी प्रणाली है जो LLM-केंद्रित control loop और उसे घेरने वाले software harness से मिलकर बनती है, और कोड लिखने, संशोधित करने, चलाने और feedback के दोहराव वाले चक्र में काम करती है
- LLM मूल रूप से next-token prediction model है, जबकि reasoning model ऐसा LLM है जिसे intermediate reasoning और verification अधिक करने के लिए प्रशिक्षित किया गया है
- एजेंट वह control loop है जो लक्ष्य हासिल करने के लिए model calls, tool use, state updates और termination decision को बार-बार चलाता है
- agent harness इस loop को घेरने वाली software structure है, जो context management, tool access, prompt composition, state control आदि संभालती है
- coding harness इसका code work के लिए विशेष रूप है, जो repository context, code execution, testing और error checking को प्रबंधित करता है
LLM, reasoning model और agent का संबंध
- LLM को engine, reasoning model को enhanced engine, और agent harness को उस engine को नियंत्रित करने वाली system के रूप में समझा जा सकता है
- LLM और reasoning model अपने-आप में coding tasks कर सकते हैं, लेकिन वास्तविक development environment में repo exploration, function search, test execution, error analysis जैसे जटिल context management की आवश्यकता होती है
- coding harness model की क्षमता को अधिकतम करता है और साधारण chat interface की तुलना में कहीं अधिक शक्तिशाली coding experience देता है
coding harness की भूमिका
- यह model को घेरने वाली software layer है, जो prompt assembly, tool exposure, file state tracking, command execution, permission management, cache और memory storage जैसे काम करती है
- एक ही LLM होने पर भी harness design के आधार on performance और user experience में बड़ा फर्क पड़ता है
- उदाहरण के लिए, GLM-5 जैसा open-weight model भी यदि Codex या Claude Code स्तर के harness में integrate किया जाए, तो समान performance दे सकता है
- OpenAI ने GPT-5.3 और GPT-5.3-Codex जैसे harness-specific post-processing models को अलग से बनाए रखने के उदाहरण भी दिए हैं
कोडिंग एजेंट के 6 मुख्य घटक
-
1. Live Repository Context
- एजेंट को मौजूदा Git repo state, branch, documentation, test commands आदि की जानकारी होनी चाहिए
- “test ठीक करो” जैसे निर्देश repo structure और context के अनुसार बदलते हैं, इसलिए काम शुरू करने से पहले repo summary information इकट्ठा की जाती है
- इससे हर बार zero state से शुरू नहीं करना पड़ता और stable facts का आधार मिलता है
-
2. Prompt Shape and Cache Reuse
- repo summary, tool descriptions और general instructions अक्सर नहीं बदलते, इसलिए इन्हें stable prompt prefix के रूप में cache किया जाता है
- हर request पर पूरा prompt फिर से assemble करने के बजाय, केवल बदले हुए हिस्सों को update किया जाता है
- इससे repeated sessions में compute waste कम होता है और response consistency बनी रहती है
-
3. Tool Access and Use
- model केवल commands suggest नहीं करता, बल्कि harness द्वारा परिभाषित tool set के माध्यम से वास्तव में commands चला भी सकता है
- हर tool के स्पष्ट input-output formats और boundaries होते हैं, और execution से पहले validation तथा approval process किया जाता है
- उदाहरण: “क्या यह known tool है?”, “क्या arguments valid हैं?”, “क्या working path workspace के अंदर है?” जैसी जाँच
- इससे security और reliability बेहतर होती है; model की स्वतंत्रता कुछ घटती है, लेकिन practical usability बढ़ती है
-
4. Minimizing Context Bloat
- लंबी sessions में repeated file reads, logs और tool outputs के कारण prompt length overflow की समस्या आती है
- harness इसे दो रणनीतियों से संभालता है
- clipping: लंबे text, logs और notes को एक तय लंबाई तक छोटा करना
- summarization: पुराने conversation history को compressed summary में बदलना
- हाल की घटनाओं को विस्तार से रखा जाता है, जबकि पुरानी जानकारी को deduplicate और compress किया जाता है
- नतीजतन, model quality से भी अधिक context quality का वास्तविक performance पर बड़ा असर पड़ता है
-
5. Structured Session Memory
- एजेंट state को working memory और full transcript में अलग रखता है
- full transcript में सभी requests, responses और tool outputs शामिल होते हैं, जिससे session resume करना संभव होता है
- working memory वर्तमान में महत्वपूर्ण जानकारी, जैसे current task, key files और recent notes, को summary form में store करती है
- compact transcript model prompt reconstruction के लिए होता है, जबकि working memory task continuity बनाए रखने के लिए
-
6. Delegation With Bounded Subagents
- मुख्य एजेंट सहायक कार्यों को parallel में चलाने के लिए subagent बनाता है
- उदाहरण: किसी specific symbol की definition location, config file contents, या test failure का कारण अलग subtask के रूप में बाँटना
- subagent केवल ज़रूरी context inherit करता है, और read-only access, recursion depth limits जैसी constraints के भीतर काम करता है
- Claude Code और Codex दोनों subagents को support करते हैं, और task scope तथा context depth के आधार पर सीमाएँ तय करते हैं
घटकों का सार
- ये छहों घटक आपस में गहराई से जुड़े हैं, और harness design की गुणवत्ता ही model उपयोग की दक्षता तय करती है
- अच्छी तरह डिज़ाइन किया गया coding harness साधारण LLM chat की तुलना में कहीं अधिक context-aware और persistent development support environment देता है
- Mini Coding Agent(https://github.com/rasbt/mini-coding-agent) इस संरचना का pure Python में बना एक minimal example है
OpenClaw के साथ तुलना
- OpenClaw coding-only helper से अधिक general agent platform के करीब है
- समानताएँ:
- workspace के भीतर prompt और instruction files (AGENTS.md, TOOLS.md आदि) का उपयोग
- JSONL session files, conversation compression, session management जैसी सुविधाएँ शामिल
- auxiliary sessions और subagents बनाए जा सकते हैं
- अंतर:
- coding agents repo exploration, code editing, local tool execution के लिए optimize किए जाते हैं
- OpenClaw का फोकस multi-channel और cross-workspace long-running agent operations पर अधिक है
परिशिष्ट: नई पुस्तक की सूचना
- Build A Reasoning Model (From Scratch) का लेखन पूरा हो चुका है और अभी Early Access संस्करण उपलब्ध है
- publisher गर्मियों में प्रकाशन के लक्ष्य के साथ layout पर काम कर रहा है
- यह पुस्तक LLM के reasoning mechanism को स्वयं implement करके समझने वाले approach पर केंद्रित है
1 टिप्पणियां
Hacker News टिप्पणियाँ
लंबा context अब भी महंगा है, और जब उसमें गैरज़रूरी जानकारी ज़्यादा होती है तो noise पैदा होता है
इसलिए मुझे लगता है कि conversational coding की बजाय spec-आधारित generation बेहतर है
मैंने जो Ossature बनाया है, वह उल्टा तरीका अपनाता है। पहले behavior को describe करने वाली spec लिखी जाती है, फिर code generation से पहले missing points या contradictions का audit किया जाता है, और एक build plan TOML बनाया जाता है जिसमें साफ़ लिखा होता है कि हर task किस spec section और file को refer करता है
LLM सिर्फ़ ज़रूरी हिस्से देखता है, और conversation history accumulate नहीं होती। सभी prompts और responses disk पर save होते हैं, इसलिए traceability अपने-आप सुनिश्चित हो जाती है
हाल ही में मैंने इसी तरीके से CHIP-8 emulator पूरी तरह spec के आधार पर बनाया, और example projects भी हैं
पहले टीम में सबको पता होता था कि क्या बन रहा है, लेकिन अब agent हर बार फिर से शुरुआत करता है
इसलिए मुझे लगता है कि chat → spec → code flow ही भविष्य है। spec → code चरण मानव हस्तक्षेप के बिना चलना चाहिए
अगर spec अस्पष्ट हो, तो इंसान से साफ़-साफ़ सवाल पूछे जाएँ और उसी आधार पर code generate किया जाए
अभी अस्पष्ट requests बस दोहराई जाती हैं और इंसान भी यह नहीं सीखता कि ऐसा क्यों हो रहा है। “memory” या agent files सिर्फ़ अस्थायी जुगाड़ हैं
conversation की जगह code और spec के projected context को LLM को दिया जाता है, और हर चरण में context को अलग तरह से compose किया जाता है
इससे accumulated context की वजह से होने वाला drift रुकता है, और workflow को LLM नहीं बल्कि मेरा code control करता है
stages के बीच TOML को artifact की तरह pass करने का idea दिलचस्प लगा, इसे ज़रूर देखूँगा
user को सिर्फ़ Agent A द्वारा बनाया गया diff review करना होगा, और बार-बार code verify करने से छुटकारा मिलेगा
असली बात intent को हमेशा preserve करने की है। spec और context को ज्यों का त्यों store करना चाहिए
cost 2–3 गुना हो सकती है, लेकिन long term में efficiency ज़्यादा होगी
मुझे लगता है spec-आधारित approach काफ़ी बेहतर है। यह जानना दिलचस्प होगा कि human intervention कैसे होता है — क्या spec और audit edits साथ-साथ किए जाते हैं, code generation की success rate कैसी है, और क्या इसे existing code पर भी लागू करने की योजना है
Ossature उससे कैसे अलग है, यह जानना चाहूँगा
सिर्फ़ एक simple state machine और bash approach से LLM की क्षमता निकाल लेना काफ़ी हैरान करने वाला है
आजकल agent ecosystem में over-engineered features और ख़राब decisions की भरमार है
10 साल पहले तक कहा जाता था कि ऐसे tools के साथ responsibility होनी चाहिए, लेकिन अभी का दौर डर, hype और confusion का मिला-जुला समय है
model के पास knowledge पहले से है, लेकिन उसे practical action में बदलने के लिए context design बहुत अहम है
user requests को skilled developer के step-level instructions में translate करना और ज़रूरी tools को जोड़ना एक promising तरीका है
मुझे लगता है कि open-source models भी अच्छे से optimized agents और थोड़ी tuning के साथ काफ़ी competitive हो सकते हैं
एक complex harness की ज़रूरत होती है, लेकिन उसी की वजह से LLM tool की तरह deterministic ढंग से काम करता है
pipelines की जगह मनचाहा logic खुलकर बनाया जा सकता है
examples संक्षिप्त और स्पष्ट हैं
मैं coding agents इस्तेमाल नहीं करता, लेकिन यह लेख coding agents के मूल स्वभाव को समझने में मदद करता है
यह अच्छी तरह दिखाता है कि सिर्फ़ 1k LOC का उपयोगी code भी 500k LOC की अव्यवस्था में बदल सकता है
पहले से ही बहुत से लोग GLM-5 जैसे open models को Claude Code या Codex CLI से जोड़कर इस्तेमाल कर रहे हैं
GLM official docs भी इसकी सिफारिश करती हैं
लेख प्रभावशाली था। मैंने email-आधारित एक non-coding agent बनाया है, और उसका सिद्धांत काफ़ी मिलता-जुलता है
हर email loop में context नए सिरे से शुरू होता है, इसलिए context accumulation problem स्वाभाविक रूप से हल हो जाती है
शुरुआती prompt में कितना context रखना है और कितना tools में अलग करना है, यह balance अहम है
caching और token cost का भी ध्यान रखना पड़ता है
details मैंने अपने ब्लॉग पोस्ट में लिखी हैं
मुझे “harness” शब्द पसंद नहीं है। सोचता हूँ कि क्या इससे बेहतर कोई शब्द हो सकता है
tool output truncation context के फैलाव को कम करने में बहुत असरदार है
मैं SQLite के आधार पर context assemble करता हूँ, और ज़रूरत पड़ने पर message ID के ज़रिए truncated tool calls को restore कर लेता हूँ
इससे जुड़े experiments docs में लिखे हैं
Claude Code को दूसरे models के साथ चलाना आम बात है
example docs में भी यह दिखाया गया है
लेकिन मेरे अनुभव में यह Anthropic models के स्तर तक नहीं पहुँचता
Opus सिर्फ़ लगभग 5% मामलों में ही cost के हिसाब से सही लगता है
मुझे OpenCode, Claude Code से काफ़ी बेहतर लगा, इसलिए मैंने OpenRouter API credits खरीदे
OpenCode custom commands और simple agent definitions के साथ ही काफ़ी powerful है
AGENTS.md, ROADMAP.md जैसी files से workflow define कर दो, तो ज़्यादातर projects के लिए यह काफ़ी है
मुझे लगता है कि complex harness की बजाय flexible structure नवीनतम model changes के साथ बेहतर तरीके से adapt करता है
coding agents में प्रगति model से ज़्यादा आसपास की संरचना (scaffolding) में सुधार से आई है
जब tools, repository context और simple state machine मौजूद हों, तो bottleneck context quality पर आ जाता है
लेख दमदार था। मैं भी coding agents को engine/car analogy से समझाता हूँ
अगर आप basic components के साथ प्रयोग करना चाहते हैं, तो OpenHands software-agent-sdk देखना उपयोगी हो सकता है