• एजेंट्स को स्थिर और उपयोगी कामों में प्रभावी ढंग से इस्तेमाल करने के लिए सिर्फ अच्छा मॉडल काफ़ी नहीं है; कामों के सेट के अनुसार डिज़ाइन किया गया harness भी चाहिए
  • सबसे बुनियादी agent loop वह संरचना है जिसमें LLM को context दिया जाता है और काम पूरा होने तक tools बार-बार कॉल किए जाते हैं
  • इसके ऊपर validation loop, event-driven loop, और hill-climbing loop को stacking करके अधिक प्रभावी एजेंट बनाए जाते हैं
  • हर loop layer को LangChain primitive से instrument किया जा सकता है, और इसे एक internal documentation-writing agent के उदाहरण से समझाया गया है
  • असली क्षमता मॉडल में नहीं, बल्कि एजेंट के आसपास बनाए गए loops में है

Loop 1: एजेंट लूप

  • एजेंट मूल रूप से ऐसा मॉडल है जो काम पूरा होने तक बार-बार tools कॉल करता है
  • LangChain का create_agent यह loop देता है; मॉडल चुनकर और tools जोड़कर एक काम करने वाला agent loop तैयार हो जाता है
    • tools वह माध्यम हैं जिनसे एजेंट वास्तविक दुनिया में action ले सकता है
  • internal docs agent के उदाहरण में, पहले loop चरण में documentation improvement request ली जाती है, फिर मॉडल बदलावों की योजना बनाता है और draft तैयार करता है, तथा repo clone करने, file पढ़ने, docs लिखने, और pull request खोलने जैसे कामों के लिए tools का उपयोग करता है

Level 2: validation loop

  • agent loop काम को संभालता है, लेकिन पहली कोशिश में हमेशा सही या consistent output नहीं देता; इसलिए जहाँ consistency महत्वपूर्ण हो, वहाँ output की जाँच करने और कमी होने पर feedback वापस मॉडल तक भेजने वाला validation loop उसके ऊपर लगाया जाता है
  • validation loop में एक grader जोड़ा जाता है, जो agent output को rubric के मुकाबले परखता है और असफल होने पर feedback के साथ परिणाम वापस भेजता है
    • grader deterministic भी हो सकता है या agentic भी; LLM as a judge इसका एक सामान्य उदाहरण है
    • RubricMiddleware इस pattern को संभाल सकता है, या इसे create_agent के after_agent hook से जोड़ा जा सकता है
  • documentation-writing उदाहरण में, grader हर प्रयास के बाद tests चलाता है ताकि यह जाँचा जा सके कि सभी links काम कर रहे हैं, सभी CI checks pass हो रहे हैं, और diff केवल अनुरोधित दायरे तक सीमित है; इससे manual review के बिना error types पकड़े जा सकते हैं
  • validation जोड़ने से हर run पर latency और cost बढ़ती है, लेकिन अधिकांश production use cases में, जहाँ speed से ज़्यादा quality महत्वपूर्ण है, यह सार्थक है

Level 3: event-driven loop

  • agent development का सबसे महत्वपूर्ण हिस्सा integrations layer में से एक है, जो एजेंट को ecosystem से जोड़कर background में चलने देता है
  • event-driven loop में नया document आने, schedule trigger होने, या webhook आने जैसे events पर agent चलाया जाता है
    • एजेंट कोई ऐसी चीज़ नहीं है जिसे सिर्फ manually call किया जाए, बल्कि वह एक बड़े system के भीतर लगातार काम करने वाला component है
  • LangSmith Deployment trigger infrastructure देता है और cron schedule तथा webhooks को support करता है
    • cron के उपयोग का लोकप्रिय उदाहरण openclaw के heartbeats हैं, जो agent को हमेशा चालू रहने वाले proactive assistant में बदल देते हैं
  • docs agent को no-code agent builder Fleet से चलाया जाता है, और Fleet के channels व schedules event-driven तथा cron triggers को संभालते हैं
    • #docs-plz Slack channel में message आते ही channel के ज़रिये docs agent चलाया जाता है

Level 4: hill-climbing loop

  • अगर पहले तीन loops काम को automate करते हैं, तो चौथा loop improvement को ही automate करता है
  • हर agent run एक trace बनाता है, जिसमें मॉडल का व्यवहार, कॉल किए गए tools, grader feedback आदि दर्ज होते हैं; इन traces में यह समझने के लिए बेहद मूल्यवान signals होते हैं कि क्या काम कर रहा है और क्या नहीं
  • hill-climbing loop इन traces पर analysis agent चलाता है और उसके आधार पर harness configuration को बेहतर settings के साथ फिर से लिखता है
    • इसमें prompt/tool tuning या grader tuning शामिल हो सकती है
    • LangSmith में trace analysis agent Engine के ज़रिये इस चौथे loop को instrument किया जाता है
  • docs agent उदाहरण में, traces पर engine चलाकर समस्याएँ पहचानी जाती हैं, और जब कई traces किसी संभावित समस्या का संकेत देते हैं, तो problematic prompt या tool में बदलाव माँगने वाला issue दर्ज किया जाता है
  • मुख्य बात यह है कि return arrow केवल ऊपर वापस नहीं जाती, बल्कि अंदर जाकर सीधे agent loop को अपडेट करती है; यानी बाहरी loop का हर cycle भीतर के loop को और प्रभावी बनाता है
  • आगे की दिशा

    • prompt और tool configuration सबसे आसान सुधार बिंदु हैं, लेकिन यही एकमात्र विकल्प नहीं; open-weight models चलाने वाली टीमें hill-climbing loop को RL fine-tuning से जोड़ सकती हैं, ताकि traces या evaluation results को training signal की तरह उपयोग कर मॉडल को ही बेहतर बनाया जा सके
    • memory, retrieved skills जैसे सहायक context भी इसी तरह सुधारे जा सकते हैं; loop एक pattern है, और क्या optimize करना है यह उपयोगकर्ता पर निर्भर है

मानवीय निगरानी और विशेषज्ञता

  • automation का मतलब यह नहीं कि इंसान loop से बाहर हो जाए; हर layer में ऐसे बिंदु हैं जहाँ मानवीय निगरानी मूल्य जोड़ती है
    • auto-grader यह जाँच सकता है कि links काम कर रहे हैं या नहीं, लेकिन target audience के लिए framing गलत है यह पहचानना इंसान का काम है; context, अनुभव और सूझ-बूझ से आने वाला निर्णय ही वह जगह है जहाँ human review ज़रूरी होता है
  • कुछ विशेषज्ञता को prompt/tools में ही encode करना चाहिए, लेकिन financial transactions या DB operations जैसे sensitive actions के लिए real-time human review अनिवार्य है
  • LangChain सभी loops में इन touchpoints को instrument करना आसान बनाता है
    • agent loop: sensitive action/tool call से पहले human input की मांग
    • validation loop: sensitive workflow में इंसान grader की भूमिका निभाए
    • application loop: अंतिम उपयोगकर्ता को लौटाने से पहले इंसान output approve करे
    • hill-climbing loop: deployment से पहले harness improvements मानव review से पास हों
  • सभी LangChain open-source frameworks में human in the loop first-class primitive के रूप में उपलब्ध है

समग्र सार

  • चारों loops किस तरह stack होते हैं, उसका सार
    • agent loop: काम पूरा होने तक मॉडल बार-बार tools कॉल करता है → task automation, primitive है create_agent और LangChain-supported models
    • validation loop: output को rubric से grade किया जाता है और failure पर feedback के साथ retry कराया जाता है → task quality और accuracy सुनिश्चित, primitive है RubricMiddleware
    • event-driven loop: events ऐसे agent runs trigger करते हैं जो वास्तविक systems को अपडेट करते हैं → बड़े पैमाने पर task automation, primitives हैं cron trigger/webhook आधारित LangSmith Deployment या Fleet channels
    • hill-climbing loop: production run traces को analysis agent के माध्यम से harness configuration सुधारने में उपयोग किया जाता है → harness improvement, primitive है LangSmith Engine
  • यही swyx का loopcraft है, यानी वास्तविक loop engineering; Steipete, Boris, और Andrej जैसे leaders भी इसी निष्कर्ष पर पहुँचे हैं कि agent की क्षमता उन loops में है जो उसके आसपास बनाए जाते हैं
  • loop 1 और 2 पर लंबे समय से काम हुआ है, लेकिन अब फोकस को loop 3 और 4 पर शिफ्ट होना चाहिए, जहाँ एजेंट ecosystem में embedded रहते हैं, standards के आधार पर लगातार सुधरते हैं, और value compound होती जाती है
  • Satya ने organizational incentives की ओर इशारा करते हुए कहा कि जो कंपनियाँ जल्दी learning loop बनाती हैं—जहाँ मानव निर्णय और token capital साथ मिलकर compound होते हैं—वे ऐसी बढ़त हासिल करती हैं जिसे कॉपी करना मुश्किल होता है

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.