LLM एजेंट लूप और टूल उपयोग की अव्यावहारिक रूप से प्रभावशाली दक्षता

 (sketch.dev)
1 पॉइंट द्वारा GN⁺ 2025-05-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI प्रोग्रामिंग सहायक Sketch को विकसित करने के अनुभव के माध्यम से LLM और टूल उपयोग को जोड़ने वाली लूप संरचना के संक्षिप्त implementation पर ज़ोर दिया गया है
  • केवल 9 पंक्तियों के लूप कोड से Claude 3.7 Sonnet जैसे आधुनिक LLM वास्तविक समस्याओं को तेज़ी से हल कर देते हैं
  • सिर्फ़ bash जैसे एक सामान्य-उद्देश्य वाले टूल से भी डेवलपर के दोहराव वाले और जटिल कामों का बड़ा हिस्सा automate किया जा सकता है
  • समस्या समाधान के अलावा, अतिरिक्त टूल जोड़कर text editing या विशेषीकृत कार्यों की गुणवत्ता और दोहराव की गति बढ़ाई जा सकती है
  • धीरे-धीरे अधिक custom LLM agent loops डेवलपर्स की रोज़मर्रा की automation में शामिल हो रहे हैं

परिचय: डेवलपमेंट अनुभव और Sketch प्रोजेक्ट

  • फिलिप ज़ेलिगर और उनके सहयोगियों ने AI-आधारित programming assistant Sketch बनाते समय LLM और टूल उपयोग को मिलाने वाली एक सरल agent loop संरचना की उच्च दक्षता देखकर आश्चर्य व्यक्त किया
  • मुख्य संरचना केवल 9 पंक्तियों के लूप कोड की है, जो system prompt, conversation history और नवीनतम message को LLM API तक भेजती है
  • LLM output बनाता है और ज़रूरत पड़ने पर tool_calls (टूल कॉल अनुरोध) वापस करता है

LLM और टूल उपयोग का एकीकरण

  • "टूल उपयोग (tool use)" का अर्थ है कि LLM पहले से परिभाषित schema के अनुरूप output लौटाता है, और system prompt तथा tool description prompt के माध्यम से LLM को bash जैसे सामान्य-उद्देश्य वाले टूल तक पहुँच मिलती है
  • आधुनिक LLM (जैसे Claude 3.7 Sonnet) केवल एक सामान्य-उद्देश्य वाले टूल से भी विभिन्न समस्याओं को जल्दी automate कर देते हैं, और कुछ मामलों में एक ही रन ("one shot") में समाधान संभव होता है
  • पहले जटिल git कमांड खोजकर copy-paste करनी पड़ती थीं और merge का काम हाथ से करना पड़ता था, लेकिन अब Sketch से कहकर वही काम तुरंत कराया जा सकता है
  • type बदलने के बाद उत्पन्न होने वाली कई type check errors को भी Sketch ने पहली बार अपने-आप संभाला
  • agent loop सतत और अनुकूलनशील तरीके से काम करता है, इसलिए टूल इंस्टॉल न होने पर उसे अपने-आप इंस्टॉल कर लेता है और कमांड विकल्पों के फ़र्क के अनुसार भी अनुकूल प्रतिक्रिया देता है
  • उपयोग के दौरान कभी-कभी LLM test fail होने पर "test skip करो" जैसी अप्रत्याशित सलाह देता है, लेकिन कुल मिलाकर workflow automation की गुणवत्ता बेहतर हुई है

टूल्स की विविधता और विशेषीकरण

  • Sketch ने bash के अलावा अतिरिक्त टूल्स (जैसे text editing tools) का उपयोग करने पर काम की गुणवत्ता बढ़ने और डेवलपमेंट workflow के और अधिक कुशल होने का अनुभव किया
  • sed आदि के ज़रिए टेक्स्ट को सटीक रूप से संशोधित करना LLM के लिए अपेक्षा से अधिक कठिन होता है, और visual editor शैली के टूल अधिक बेहतर साबित होते हैं

भविष्य की दिशा और workflow में बदलाव

  • agent loop संरचना उन दोहराव वाले कामों में बढ़ते हुए इस्तेमाल होने की संभावना रखती है, जिन्हें पारंपरिक general-purpose automation tools से संभालना कठिन था और जो डेवलपर के रोज़मर्रा के काम का हिस्सा हैं
  • उदाहरण के तौर पर, stack trace और git commit के सहसंबंध का विश्लेषण जैसे झंझट वाले और दोहरावपूर्ण कामों में भी LLM तेज़ी से शुरुआती प्रोसेसिंग कर सकता है
  • आगे चलकर और अधिक custom-built, one-off LLM agent loops डेवलपर्स की bin/ directory जैसी जगहों पर इस्तेमाल होते दिख सकते हैं
  • उपयोगकर्ता अपनी पसंद का bearer token तैयार करके अपने environment में इसे आसानी से आज़मा सकते हैं

संदर्भ लिंक

  • यह सामग्री philz.dev ब्लॉग पर भी प्रकाशित है
  • प्रोजेक्ट और संबंधित जानकारी sketch.dev, merde.ai, pi.dev पर देखी जा सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-16
Hacker News राय
  • मैं इस ब्लॉग पोस्ट की भी ज़ोरदार सिफारिश करना चाहता हूँ। यह उसी बात को कहीं ज़्यादा विस्तार और अधिक ठोस तरीके से समझाती है। लेखक ने सचमुच शुरू से अपना coding agent बनाया है। देखें: https://ampcode.com/how-to-build-an-agent. यह वाकई चकित करने वाला अनुभव है कि जब LLM को tools call करने वाले loop में रखा जाता है, तो वह कितने तरह के काम अच्छी तरह संभाल सकता है। बेशक यह परफेक्ट नहीं है, और 100% reliability तक न पहुँच पाने जैसी समस्याएँ हैं। फिर भी, कम-से-कम इसमें थोड़ा विस्मय पैदा करने वाली बात तो है। अगर आप इसे खुद आज़माएँ, तो 30 मिनट के अंदर साथ-साथ कर सकते हैं। यह AI के किसी खास उपयोग में सचमुच प्रभावी होने को लेकर स्वस्थ संदेह बनाए रखते हुए भी आश्चर्य महसूस करने वाला क्षेत्र है। LLM को loop में रखने का यही "असामान्य प्रभाव" है कि आज इतने सारे code-generation agents आ रहे हैं: Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex वगैरह, और इनके clone projects भी बहुत हैं। कोई खास गुप्त नुस्खा न होने का यही कारण है; जादू का 95% हिस्सा आखिरकार खुद LLM और उसे tool calling के लिए fine-tune करने में ही है। Claude Code के एक मुख्य developer ने हाल की interview में इसे ईमानदारी से माना भी है। हाँ, इन tools को अच्छी तरह काम कराने में काफी मेहनत लगती है, लेकिन बुनियादी तौर पर इनका core structure लगभग यही सीधा-सादा है
    • मैं बहुत लंबे समय से ऐसी पोस्ट ढूँढ रहा था, इसलिए इसके लिए सचमुच आभार जैसा महसूस हो रहा है। बहुत से लोग Agents को देखकर कहते हैं, "शायद ये सचमुच जटिल समस्याएँ अच्छी तरह हल नहीं कर पाएँगे?" लेकिन मेरे हिसाब से agent का मुख्य बिंदु वह नहीं है। LLM बहुत अधिक context में बेहद अच्छा काम करते हैं, और agents ऐसी संरचना हैं जो LLM को और context ढूँढने देते हैं ताकि सवालों के जवाब की गुणवत्ता बेहतर हो सके
    • मेरे अनुभव में LLM अपने आप loop के भीतर बिना निर्देश के कुछ बार से ज़्यादा बहुत कम काम ठीक से कर पाते हैं। कुछ iterations के बाद ऐसी स्थिति आ ही जाती है जहाँ मुझे बीच में आना पड़ता है
    • pocketflow नाम की graph abstraction library का इस्तेमाल करके कुछ ऐसा ही बनाने वाला एक tutorial है। मैंने इसे वास्तव में इस्तेमाल किया और यह काफी simple लगी, इसलिए मैं बहुत संतुष्ट था। https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
    • अब जाकर ध्यान गया कि लेखक Thorsten Ball हैं। उनकी "interpreter बनाना" वाली चीज़ मुझे याद है कि बहुत मज़े से पढ़ी थी। लगता है अब मैं भी agent बनाकर देखूँगा
    • ऊपर वाला लिंक खोलने से पहले ?utm_source=hn&utm_medium=browser जोड़ना चाहिए या नहीं, यही सोच रहा हूँ
  • आज पहली बार मैंने GPT-4o और 4.1 के साथ सीधे "vibe-coding" आज़माया। तरीका यह था कि compile errors, warnings और suggestions को canvas interface के ज़रिए loop में manually डालता गया। फ़ाइल छोटी थी, लगभग 150 lines की। मैंने 4o से शुरू किया, लेकिन उसने पुराने packages इस्तेमाल किए। मैंने यह बताने के बाद भी उसने हर उपयोग को update नहीं किया, और मुझे खुद हाथ से ठीक करना पड़ा। जब मैंने logic change सुझाया, तो syntax पूरी तरह टूट गई और फिर वह कभी recover नहीं कर पाया। मैं बार-बार compile errors डालता रहा, लेकिन वह syntax problem समझने के बजाय code के random हिस्से बदलता रहा। फिर मुझे उम्मीद थी कि 4.1 बेहतर करेगा, लेकिन 4.1 ने canvas इस्तेमाल करने से ही मना कर दिया और सिर्फ explanation देता रहा। मतलब खुद edit करो वाली शैली। बहुत मनाने पर उसने canvas में code निकाला भी, तो बीच का हिस्सा // omitted for brevity जैसा काटा हुआ था, इसलिए इस्तेमाल लायक नहीं था। यहीं मैंने हार मान ली। सोच रहा हूँ कि क्या agents इस समस्या को हल करते हैं। फिलहाल तो मुझे यह अनुभव पूरी तरह टूटा हुआ लगता है, और ऐसी हालत में इसे bash access देना बहुत खतरनाक लगता है
    • "उसने पुराने packages इस्तेमाल किए" — यह model के training data cutoff का मामला है। LLM इस्तेमाल करते समय यह ज़रूर ध्यान रखना चाहिए। मैं ChatGPT में अक्सर o4-mini-high पर switch करता हूँ। यह model search feature के ज़रिए नई documentation भी ढूँढ सकता है। अगर आप कहें "X library का latest version देखकर उसका इस्तेमाल करो", तो यह अक्सर ठीक कर देता है। हाल ही में मुझे JavaScript code के कुछ हिस्सों को Google की नई recommended libraries में बदलना था। मैंने पुराना code सीधे paste किया और नई library पर port करने को कहा, तो इसने docs भी देखीं और सही port भी कर दिया। https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
    • GPT 4.1 और 4o का Aider coding benchmark में score बहुत कम आता है। मेरे practical experience में output को उपयोगी होने के लिए 70% से ऊपर होना चाहिए। फिर भी जटिल चीज़ों में अच्छी-खासी मदद चाहिए होती है। इस्तेमाल करते-करते अंदाज़ा हो जाता है कि क्या अच्छा चलता है और क्या नहीं। https://aider.chat/docs/leaderboards/
    • "skill issue" सुनना शायद अच्छा न लगे, लेकिन LLM इस्तेमाल करना सचमुच एक अलग skillset है। अलग-अलग tools की ताकत और कमज़ोरियाँ समझनी पड़ती हैं, कई techniques आज़मानी पड़ती हैं, और practice ज़रूरी हिस्सा है। अगर मैं bash access दूँ, तो मैं भी उसे सिर्फ container environment (docker) में ही इस्तेमाल करूँगा
    • उसे vibe coding नहीं कहेंगे। vibe coding के लिए ऐसा tool चाहिए जिसमें code changes अपने-आप apply हों। अगर हर feedback manually देना पड़े, तो आप errors में फँसकर रुक जाएँगे। vibe coding का सार यह है कि आप आसानी से undo कर सकें, फिर से चला सकें, और अलग-अलग approaches को फेंक-पकड़ सकें। इसके लिए tooling चाहिए
    • कुछ समय पहले मैंने VSCode में Cline plugin और Claude के साथ Android app prototype को "zero-base" से बनाया था। Android Studio के default template से शुरुआत की, और इसने हज़ारों lines का code generate किया जिसमें एक भी compile error नहीं था। App उम्मीद के मुताबिक चला, और जो कुछ bugs मिले भी, वे LLM की गलती नहीं बल्कि Android API के अजीब व्यवहार की वजह से थे। मैंने LLM को bug बताया और debug message output दिया, तो उसने खुद ठीक कर दिया। शुरुआत में fixes थोड़ी भद्दी थीं, लेकिन कुछ rounds feedback के बाद काफ़ी ठीक हो गया। मुझे लगता है कि अगर code-writing agent और code-review agent को loop में चलाया जाए, तो यह चीज़ और सामान्य रूप से अच्छी तरह संभल सकती है
  • Claude Code, यानी Sonnet 3.7 का terminal interface, मैं launch के पहले दिन से इस्तेमाल कर रहा हूँ। इससे मैंने काफी बड़े CLI apps, full-stack web systems, और बहुत सारे utilities भी लिखे हैं। इससे मैं फिर से वैसे ही ज़्यादा ambitious challenges लेने लगा हूँ जैसे पहले programming team lead करते समय लेता था। संरचनात्मक रूप से यह शायद दूसरे tools से बहुत अलग न हो, लेकिन Anthropic ने इसमें बहुत उपयोगी features जोड़े हैं। कुछ भी परफेक्ट नहीं है, और अच्छी code quality के लिए आज भी लगभग उतनी ही मेहनत चाहिए जितनी तब लगती थी। काफी जटिल चीज़ें भी काम कर जाती हैं, लेकिन अक्सर अगला feature जोड़ना मुश्किल हो जाता है। इसे चलाने का अनुभव बढ़ने पर refactoring और सुधार का काम बहुत कम हो गया है। पूरी तरह खत्म होने वाली चीज़ नहीं है। kgeist को जो समस्याएँ आईं, उन्हें ईमानदारी से कहूँ तो मैं कल्पना भी नहीं कर सकता। Claude भी कभी-कभी मेरी पसंद से अलग या बेवकूफी भरा काम करता है, लेकिन इतना कभी नहीं कि छोड़ देने का मन हो। लगभग हमेशा यह ठीक-ठाक नतीजे देता है, और दिमाग पर से बहुत काम उतार देता है। ऊपर से यह refactoring बहुत शानदार करता है। अगर समय-समय पर code देखते रहें और Claude से समझवाएँ कि बेहतर तरीका क्या हो सकता है, तो complexity बहुत कम हो जाती है। "data structure बदलो" जैसे अनुरोध भी यह सीधे कर देता है। यह बहुत शानदार feature है। और मज़े के लिए मैंने code नहीं बल्कि इधर-उधर की चीज़ों से भरी 30 साल पुरानी archive directory भी खोलकर देखी। "इस directory में क्या है?", "मेरा पुराना resume पढ़कर नया लिखो", "मेरे बच्चों के नाम क्या हैं?" जैसी बातें पूछीं, और यह सचमुच हैरान कर देने वाला था। अभी शुरुआती दौर है, फिर भी मैं इससे बहुत खुश हूँ
    • हाल ही में ऐसी स्थिति थी जहाँ remote data structure definition, API spec, parsing और storage implementation, और फिर user को दिखाने तक सब कुछ एक साथ संभालना था। Claude ने यह सब एक साथ अच्छी तरह manage किया, इसलिए मैं तुरंत देख पा रहा था कि दोनों सिरों पर छोटे बदलावों का बीच की layers पर क्या असर पड़ता है। मैंने कई ideas पर तेज़ी से iterate किया और बेहतर समाधान ढूँढ लिया। इस तरह की कई high-complexity layers को तेज़ iteration speed के साथ explore कर पाना सचमुच चौंकाने वाला था, और इससे productivity बढ़ने के साथ पूरे system की structural understanding भी बेहतर हुई
    • ऊपर बताया गया refactoring वाला हिस्सा वाकई बहुत मज़ेदार है। जो features पहले sprint में शामिल करना भी मुश्किल होता था, वे अब 5 मिनट में हो जाते हैं। ऐसा लगता है जैसे एक तैयार team हर समय सिर्फ मेरे कहने का इंतज़ार कर रही हो। अगर result पसंद न आए तो तुरंत reject भी कर सकता हूँ, और बेकार की review व scheduling की चिंता भी जैसे गायब हो गई है
  • जब LLM कभी-कभी कहता है, "अरे, यह test नहीं चल रहा... चलो इसे छोड़ देते हैं," तो यह बहुत परेशान करने वाला होता है। मेरे पास एक विचार है। मुख्य LLM के साथ एक स्वतंत्र, parallel policy-enforcement LLM चलाया जाए जो उसे निर्देशों के अनुसार काम करने पर मजबूर करे। उदाहरण के लिए, सहायक LLM output probability को इस तरह tweak करे कि "let's just" के बाद "skip" शब्द आ ही न सके। यानी "skip" पर रोक लगाकर LLM को अवांछित व्यवहार से हटाकर दूसरी राह पर धकेला जा सकता है। यह कुछ-कुछ JSON mode या structured output की तरह काम करेगा, लेकिन इसमें सहायक LLM real time में policy control करेगा। अगर यह काम करे, तो इसे आगे बढ़ाकर test pass कराने के लिए test code delete करना, बेकार comments लिखना वगैरह जैसे कई policy violations को सहायक LLM के prompt में डालकर, उससे real-time monitoring और control कराया जा सकता है। जानना चाहूँगा कि Outlines team इस architecture के बारे में क्या सोचती है
    • अगर एक LLM दूसरे LLM के output को check कर सकता है, तो क्या "mixture of experts" LLM में किसी एक expert algorithm को monitoring/auditing की भूमिका भी दी जा सकती है? या फिर अलग thinking thread बनाकर model को अपने ही output की जाँच करने दी जाए, और ज़रूरत पड़े तो उस verifier को verify करने के लिए एक और thread रखा जाए — इससे पूरी व्यवस्था और मजबूत हो सकती है
    • इसी संदर्भ में यह भी सोचा जा सकता है कि अगर मुख्य LLM गलत दिशा में जाने लगे, तो monitoring LLM उस बिंदु तक model को "rewind" कर दे। जैसे अगर "let's just skip the test" पकड़ में आए, तो "just " के बाद तक rollback कर दे और कुछ शब्द इस्तेमाल न होने देने के लिए bias लगाए रखे। हालाँकि ऐसा करने के लिए model provider पर निर्भरता सीमित हो सकती है, और खासकर OpenAI हाल में ऐसे power-user features के प्रति कुछ शत्रुतापूर्ण रुख दिखाता लगता है
  • आज सुबह cursor के साथ मैंने game prototype के main loop से एक जटिल हिस्सा अलग निकाला, और उस हिस्से के लिए test code का एक set अपने-आप generate कराया। कुल 341 tests हैं, जो core math और मुख्य components को cover करते हैं। कभी-कभी यह cat-herding जैसा लगता है, लेकिन जितनी ज़्यादा constraints आप देते हैं — कौन-से functions इस्तेमाल करने हैं, कहाँ इस्तेमाल करने हैं, template files कौन-सी हैं, क्या avoid करना है — उतना result बेहतर होता जाता है। कुल 3500 lines के test code मुझे खुद लिखने की ज़रूरत नहीं पड़ी, और कोई दिक्कत होने पर मैं उन्हें कभी भी delete करके फिर से generate कर सकता हूँ। difficulty curve tuning, mission variations वगैरह कई चीज़ों में भी मदद मिली
    • मेरे अनुभव में tests का auto-generation, LLM का सबसे बेहतरीन use case है। यह बोरिंग और repetitive मेहनत को, जो कई घंटे या कई दिन ले सकती थी, एक झटके में खत्म कर देता है। यह बहुत से edge cases भी खुद cover कर देता है जिनके बारे में मैं सोच भी न पाता, और code safety भी बढ़ती है। हर तरफ़ से यह बहुत शानदार feature है
  • इन दिनों LLM की tool-using capability को लेकर मैं बहुत उत्साहित हूँ। असल में यह trick नई नहीं है; मैंने इसे पहली बार 2 साल पहले ReAcT paper में देखा था। बाद में ChatGPT plugins, MCP वगैरह में इसका इस्तेमाल हुआ, और अब ज़्यादातर models को tool-call/function-calling को ध्यान में रखकर train किया जाता है। फिलहाल दिलचस्प बात यह है कि performance कितनी सुधर गई है। o3/o4-mini की शानदार search performance भी इसी tool-calling क्षमता पर टिकी है। Qwen3 4B (Ollama 2.6GB, Mac पर भी बढ़िया चलता है) भी यह काम अच्छी तरह करता है। कल मैंने PyCon US में LLM-based software बनाने पर workshop ली, और उसी बहाने अपने LLM command-line tool में tool-use feature जोड़ दिया। देखें: https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html. अब मैं अपने LLM package के साथ "strawberry में R कितनी बार आता है" जैसी चीज़ shell one-liner के ज़रिए भरोसेमंद तरीके से कर सकता हूँ
    • इस feature की जो अजीब-सी मज़ेदार और ताकतवर मिली-जुली भावना है, वह मुझे बहुत पसंद है
    • क्या workshop रिकॉर्ड की गई थी?
  • मैं जानना चाहता हूँ कि कौन-सा agent सबसे ज़्यादा tokens इस्तेमाल करता है। लगता है cline इस list में ऊपर है, और roo शायद cline से कम इस्तेमाल करता है। क्या कोई ऐसा agent है जिसमें interaction style को सीधे configure किया जा सके? और Claude code दूसरे agents की तुलना में कैसा है, यह भी जानना चाहता हूँ
  • "ज़रूरी tool न हो तो उसे install कर लो" — यही वह डरावनी बात है। LLM बहुत ज़्यादा 'आज्ञाकारी' होते हैं, और कोई कह दे तो तुरंत चला देते हैं। यह SQL injection से भी बड़ा security concern है
    • कभी-कभी सोचता हूँ कि पहला agent-based disaster कब होगा। (खासकर इस जल्दीबाज़ AI market माहौल में) डर है कि समय के साथ कोई ऐसा irreversible disaster ज़रूर होगा
  • लगता है शीर्षक Eugene Wigner के पेपर "The Unreasonable Effectiveness of Mathematics in the Natural Sciences" से प्रेरित है
    • वह paper मूल स्रोत हो सकता है, लेकिन मुझे लगता है यह वाक्यांश बहुत पहले से meme-जैसा idiom बन चुका है। https://scholar.google.com/scholar?q=unreasonable+effectiveness
    • मुझे तो पहले लगा था कि यह Karpathy की 2015 की "Unreasonable Effectiveness of RNNs" से लिया गया है। हालाँकि यह भी माना जा सकता है कि Karpathy ने भी Wigner के paper से ही इसे उधार लिया था। https://karpathy.github.io/2015/05/21/rnn-effectiveness/
    • जब भी "unreasonable effectiveness" वाला headline देखता हूँ, मेरा अनुभव होता है कि मैं लेखक के निष्कर्ष से अक्सर पूरी तरह सहमत नहीं होता। Wigner के paper में भी। अब यह कुछ-कुछ Betteridge law जैसा लगने लगा है
  • हमने अपने product के embedded AI chatbot को और context देने के लिए tools बनाए हैं। हाल की activity logs, current object definitions, search, और help articles browsing जैसी कई सुविधाएँ जोड़ी हैं। कई महीने बाद भी chatbot की quality अब तक हैरान करती है। अगर chatbot कुछ गलत जवाब दे, तो हम process के तहत संबंधित help article को और अधिक specific बना देते हैं