प्रभावी AI एजेंट बनाना
(anthropic.com)- जिन टीमों ने LLM-आधारित एजेंट सफलतापूर्वक लागू किए हैं, वे जटिल framework की बजाय सरल और composable patterns का उपयोग करती हैं
- workflow और agent के बीच के संरचनात्मक अंतर को समझना ज़रूरी है, और सर्वोत्तम समाधान के लिए हमेशा न्यूनतम आवश्यक जटिलता ही अपनाने की सिफारिश की जाती है
- विभिन्न agent patterns (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer loop आदि) वास्तविक production environment में उपयोग किए जाते हैं, और हर pattern के अपने use cases, फायदे और सीमाएँ हैं
- agent लागू करते समय सरलता, पारदर्शिता, interface design मुख्य सिद्धांत हैं, और tool design तथा prompt engineering पर ध्यान देना चाहिए
- customer support और software development environment में ऐसे कई उदाहरण बढ़ रहे हैं जहाँ agent वास्तविक मूल्य प्रदान कर रहे हैं
अवलोकन
पिछले एक वर्ष में Anthropic ने विभिन्न उद्योगों की टीमों के साथ मिलकर large language model (LLM) आधारित agents बनाए हैं। व्यवहारिक रूप से सफल agent adoption के उदाहरणों में यह प्रवृत्ति दिखी कि वे जटिल frameworks या विशेष libraries की तुलना में सरल और composable patterns पर आधारित थे। यह पोस्ट ग्राहकों के साथ सहयोग और स्वयं के विकास अनुभव से प्राप्त insights तथा प्रभावी agents बनाने के लिए व्यावहारिक सलाह साझा करती है।
agent क्या है
agent को कई तरीकों से परिभाषित किया जा सकता है
- कुछ लोग इसे पूर्णतः autonomous system के रूप में परिभाषित करते हैं, जो external tools का उपयोग करके जटिल tasks को स्वतंत्र रूप से पूरा करता है
- कुछ लोग इसे सीमित workflows या पूर्वनिर्धारित processes का पालन करने वाले prescriptive implementation के रूप में समझते हैं
Anthropic इन दोनों को agentic systems की श्रेणी में रखता है, लेकिन workflow और agent के बीच एक महत्वपूर्ण architectural अंतर मानता है
- workflow: ऐसी संरचना जिसमें LLM और tools को पहले से परिभाषित code path के अनुसार orchestrate किया जाता है
- agent: ऐसी संरचना जिसमें LLM tools के उपयोग और process को स्वयं dynamically तय करता है, और task पूरा करने के तरीके पर उसका नियंत्रण होता है
यह पोस्ट इन दोनों प्रकार की systems को विस्तार से समझाती है, और व्यावहारिक उपयोग के उदाहरण परिशिष्ट 1 में दिए गए हैं
कब agent का उपयोग करना चाहिए, और कब नहीं
application development में न्यूनतम जटिलता को सिद्धांत मानना चाहिए, और केवल आवश्यकता होने पर ही जटिलता को धीरे-धीरे बढ़ाना चाहिए
- agentic systems latency/cost का कुछ त्याग करके task performance बेहतर कर सकते हैं
- यदि जटिलता अनिवार्य न हो, तो कई बार एकल LLM call, few-shot examples, और retrieval integration से ही समस्या हल हो जाती है
- workflow वहाँ उपयुक्त है जहाँ predictability और consistency महत्वपूर्ण हो, जबकि agent वहाँ बेहतर है जहाँ flexibility और scale चाहिए
framework कब और कैसे उपयोग करें
agentic systems के implementation को आसान बनाने वाले कई frameworks उपलब्ध हैं
- LangGraph (LangChain)
- Amazon Bedrock AI Agent framework
- Rivet, Vellum आदि
ये frameworks LLM call, tool definition/parsing, और call chain composition जैसे low-level कार्यों को सरल बनाते हैं। लेकिन अत्यधिक abstraction के कारण वास्तविक prompt-response flow अस्पष्ट हो सकता है, या अनावश्यक जटिलता बढ़ सकती है
- developers को जहाँ तक संभव हो सीधे LLM API के उपयोग से शुरुआत करने की सिफारिश की जाती है
- framework का उपयोग करें तो भी उसके अंदरूनी कामकाज को ठीक से समझना चाहिए
उदाहरण implementation anthropic-cookbook में देखे जा सकते हैं
building blocks, workflows, और agent patterns
Anthropic उन agentic system patterns का परिचय देता है जो वास्तविक production environment में अक्सर उपयोग होते हैं
building block: augmented LLM
agentic systems का मूल retrieval, tools, memory जैसी क्षमताओं से augmented LLM है
- model स्वयं search query generation, उपयुक्त tool selection, और information storage कर सकता है
- implementation का मुख्य ध्यान यह होना चाहिए कि use case के अनुरूप capabilities को customize किया जाए और LLM को स्पष्ट और documented interface दिया जाए
हाल ही में घोषित Model Context Protocol के माध्यम से विभिन्न third-party tools के साथ सरल integration संभव है
workflow प्रकारों का विवरण
prompt chaining
- task को कई चरणों में विभाजित किया जाता है, और हर LLM call पिछले परिणाम को लेकर आगे बढ़ती है
- प्रत्येक चरण में programmatic validation gate जोड़कर process को नियंत्रित किया जा सकता है
- उपयोग उदाहरण: marketing copy बनाकर उसका translation, document outline design → validation → content writing आदि
routing
- input को classify करके उपयुक्त follow-up task की ओर branch किया जाता है
- प्रत्येक category के लिए विशेष prompts और tools का उपयोग किया जा सकता है
- उपयोग उदाहरण: customer query routing (refund, technical support आदि), difficulty के अनुसार model selection
parallelization
- task को छोटे हिस्सों में बाँटकर parallel में process किया जाता है, फिर परिणाम aggregate किए जाते हैं
- Sectioning: प्रत्येक भाग को स्वतंत्र रूप से process करना
- Voting: एक ही task को कई दृष्टिकोणों या prompts से दोहराकर majority vote आदि का उपयोग करना
- उपयोग उदाहरण: user question filtering और response separation, automated evaluation, code review आदि
orchestrator-workers
- एक केंद्रीय LLM task को dynamically तोड़कर assign करता है, और कई worker LLM अलग-अलग हिस्सों को process करके अंत में जोड़ते हैं
- यह उन sub-tasks के लिए उपयुक्त है जो पहले से तय नहीं होते और input के अनुसार बदलते हैं
- उपयोग उदाहरण: कई files में बदलाव वाला coding task, जटिल information retrieval आदि
evaluator-optimizer loop
- response LLM और evaluator LLM को एक iterative loop में उपयोग किया जाता है
- जहाँ स्पष्ट evaluation criteria और feedback-आधारित improvement उपयोगी हो, वहाँ यह उपयुक्त है
- उपयोग उदाहरण: literary translation में सूक्ष्म nuance का मूल्यांकन, कई rounds की information search आदि
agents
-
LLM की प्रगति के साथ अब वास्तविक सेवाओं में ऐसे agents उभर रहे हैं जो जटिल input, reasoning/planning, tool use, error recovery संभाल सकते हैं
-
प्रक्रिया user command या conversation से शुरू होती है → task clarification के बाद autonomous execution → बीच के checkpoints पर feedback संभव → completion या stop condition पर समाप्ति
-
वास्तविक implementation में LLM environment feedback (tool results, code execution) का संदर्भ लेकर iterate करता है, और tool set तथा documentation अत्यंत महत्वपूर्ण होते हैं
-
उपयोग उदाहरण: SWE-bench tasks हल करने वाले coding agents, Claude-आधारित computer use automation
-
उपयोग का दायरा: open-ended समस्याएँ जहाँ निश्चित path या step prediction संभव न हो, या जहाँ decision-making पर भरोसा आवश्यक हो
-
अधिक autonomy के कारण cost और compound errors की संभावना पर ध्यान देना चाहिए; sandbox testing और guardrails आवश्यक हैं
patterns का संयोजन और customization
- यहाँ बताए गए building blocks कोई कठोर नियम नहीं हैं; इन्हें अलग-अलग परिस्थितियों के अनुसार मिलाकर उपयोग किया जा सकता है
- महत्वपूर्ण बात है performance measurement और iterative improvement के माध्यम से उपयुक्त संरचना चुनना और जटिलता को क्रमिक रूप से बढ़ाना
सारांश और अनुशंसित सिद्धांत
LLM systems की सफलता जटिलता या नई तकनीक पर नहीं, बल्कि उद्देश्य के अनुकूल सही approach चुनने पर निर्भर करती है
-
सरल prompts से शुरुआत करें, performance का मूल्यांकन करें, iterative optimization करें, और फिर चरणबद्ध तरीके से जटिलता बढ़ाएँ
-
agent design के 3 प्रमुख सिद्धांत
- सरलता बनाए रखें
- पारदर्शिता (planning stage की स्पष्टता) को प्राथमिकता दें
- tools/interface की documentation और testing को महत्व दें
-
frameworks से जल्दी शुरुआत की जा सकती है, लेकिन व्यवहार में abstraction layer को न्यूनतम रखना और direct implementation capability ही reliability और maintenance तय करती है
परिशिष्ट 1: व्यावहारिक कार्य में agent के उपयोग के उदाहरण
customer support
customer support ऐसा क्षेत्र है जहाँ chatbot interface और tool integration का संयोजन agent adoption के लिए स्वाभाविक रूप से उपयुक्त है
- conversational interface और external data/operational processing की आवश्यकता साथ-साथ मौजूद रहती है
- tools के माध्यम से customer information, order history, knowledge base आदि को जोड़ा जा सकता है
- refund/ticket processing जैसे कार्य automated किए जा सकते हैं
- resolution criteria को स्पष्ट रूप से परिभाषित किया जा सकता है
सफल उदाहरणों में usage (successful resolution criteria) आधारित pricing model के माध्यम से agent effectiveness सत्यापित की गई है
coding agents
software development environment में भी समस्याओं के स्वचालित समाधान जैसे उपयोगों में agent की उपयोगिता काफी बढ़ी है
- code के परिणाम को automated tests के माध्यम से verify किया जा सकता है
- test results का उपयोग करके iterative improvement किया जा सकता है
- problem definition स्पष्ट होती है, और output quality को वस्तुनिष्ठ रूप से मापा जा सकता है
Anthropic का अपना implementation उदाहरण: SWE-bench Verified benchmark में वास्तविक GitHub issues को केवल pull request description के आधार पर हल किया गया। automated tests के अलावा भी यह जाँचने के लिए human review महत्वपूर्ण है कि system समग्र requirements को पूरा करता है या नहीं
परिशिष्ट 2: tool prompt engineering कैसे करें
सभी agentic systems में tools एक मुख्य तत्व हैं
- Claude जैसे LLM API में सटीक structure और definition के अनुसार external services के साथ interact कर सकते हैं
- response में tool use block शामिल हो सकता है
- tool definitions और specifications को भी prompt engineering जितनी ही बारीकी से design करना चाहिए
tool format design tips
-
model को writing traps में फँसने से बचाने के लिए पर्याप्त tokens उपलब्ध कराएँ
-
इंटरनेट पर व्यापक रूप से दिखने वाले natural format का उपयोग करने की सिफारिश की जाती है
-
अनावश्यक formatting overhead (जैसे code line counting, string escaping आदि) को कम करें
-
जिस तरह human-computer interface (HCI) को design करने में निवेश किया जाता है, उसी तरह agent-computer interface (ACI) पर भी पर्याप्त ध्यान देना चाहिए
-
model के दृष्टिकोण से tools को समझना और उपयोग करना स्पष्ट होना चाहिए; इसमें usage examples, edge conditions, input format specification आदि शामिल हों
-
parameter names और descriptions भी intuitive terms में रखकर documentation (docstring) की तरह design करें
-
विभिन्न input values के साथ वास्तविक उपयोग का परीक्षण करें और iterative improvement करें
-
argument design को ऐसा बनाएँ कि गलतियाँ कम हों (Poka-yoke)
वास्तविक SWE-bench agent बनाते समय पूरे prompt की तुलना में tool design optimization पर अधिक समय लगाया गया। उदाहरण: root folder से बाहर जाने के बाद file path errors कम करने के लिए tool को केवल absolute paths स्वीकार करने लायक बदला गया, और उसके बाद वह पूरी तरह सही काम करने लगा।
1 टिप्पणियां
Hacker News की राय
इस पोस्ट की खास बात यह लगी कि यह "AI agents" की परिभाषा साफ़ करके शुरू होती है। यहाँ इस्तेमाल की गई परिभाषा है: "ऐसा सिस्टम जिसमें LLM खुद process और tool usage को dynamic तरीके से manage करता है और task को कैसे पूरा करना है, इस पर स्वयं नियंत्रण रखता है।" ‘agent’ और ‘workflow’ के बीच किया गया अंतर, और कई व्यावहारिक workflow patterns को पेश करने का तरीका भी पसंद आया। जब यह लेख पहली बार आया था, तब इस पर एक खुद का summary note भी लिखा था building-effective-agents नोट. और हाल में Anthropic का multi-agent research system बनाने का लेख भी दिलचस्प लगा, जिस पर अतिरिक्त नोट्स भी हैं multi-agent research system नोट
मुझे लगता है कि इस लेख में दी गई workflow की परिभाषा सटीक नहीं है। आजकल workflow engines अक्सर पहले से तय code path का पालन नहीं करते और व्यवहार में agents की तरह ही काम करते हैं। लेखक ने शायद फर्क दिखाने के लिए workflow को नए तरीके से परिभाषित किया है, लेकिन वास्तव में agent भी बस एक loop-style workflow ही है जो LLM response के आधार पर dynamically calls करता है। मेरा मानना है कि आधुनिक workflow engines भी बहुत dynamic होते हैं
Building Effective Agents के सह-लेखकों में से एक ने AIE में इसी लेख पर एक talk भी दी थी, और प्रतिक्रिया बहुत अच्छी रही थी YouTube वीडियो
multi-agent research पर लिखा गया लेख वाकई बहुत अच्छा है, लेकिन Building Effective AI Agents वाले लेख में जो यह दावा है कि "framework के बिना scratch से system बनाना educational point of view से अच्छा है", उससे मैं सहमत नहीं हूँ। अच्छी frameworks का पहला फायदा यह है कि उनसे अलग-अलग (और vendor-neutral) LLMs को आसानी से experiment किया जा सकता है
जिज्ञासा है कि Anthropic कौन-सा AI agent framework इस्तेमाल करता है। लगता नहीं कि उन्होंने कभी अपना internal framework सार्वजनिक किया है
अतिरिक्त नोट्स के लिए धन्यवाद, यह विषय हाल में मेरे लिए भी बहुत महत्वपूर्ण रहा है
AI में आधा साल बहुत लंबा समय लगता है। मैंने कुछ महीने पहले इस लेख को बार-बार पढ़ा था, लेकिन अब साफ़ लग रहा है कि agent development एक bottleneck पर पहुँच गया है। यहाँ तक कि नया Gemini भी उलटे performance regression जैसा लग रहा है
कई agents को साथ चलाना महँगा पड़ता है, जिससे RoI कम हो जाता है। उदाहरण के लिए, stock DeepSearch agent 6 agents का इस्तेमाल करता है और हर query पर लगभग 2 डॉलर खर्च होते हैं। multi-agent orchestration को control करना मुश्किल है, और जब model ज्यादा powerful होता है तो multi-agent की जरूरत घट जाती है। उल्टा, model जितना कमजोर हो, उतना ही specialized narrow AI की business value बढ़ती है — यह मेरा व्यावहारिक अनुभव है
यह जानने की जिज्ञासा है कि agents के regression जैसा महसूस होने की वजह क्या है। वे बस अपने कई clones बनाकर 24/7 parallel में काम, verification और self-improvement क्यों नहीं कर पाते?
prompt injection की समस्या को हल करना बहुत कठिन है, और यही एक गंभीर bottleneck बन गया है
जिज्ञासा है कि agents task queueing, race condition, और बाकी concurrency समस्याओं को कैसे handle करते हैं। multi-agent workflow बनाने वाले लेखों में अक्सर orchestrator agent के सब कुछ manage करने की बात होती है, लेकिन मुझे हमेशा लगता है कि व्यवहार में इससे ज्यादा जटिल design और smart glue code की ज़रूरत पड़ती होगी। या क्या यह सब सच में किसी “automatic magic” की तरह चलता है?
agents में सामान्य रूप से tools sequentially execute होते हैं, इसलिए concurrency issues की चिंता नहीं करनी पड़ती। अब कई models parallel tool calling support करते हैं, इसलिए अगर model कहे “इन तीन tools को चलाओ”, तो harness उन्हें parallel या sequential तरीके से चलाकर results अगले step में दे सकता है। Anthropic multi-agent setup को और आक्रामक तरीके से इस्तेमाल कर रहा है, जहाँ एक top-level agent नीचे के agents को parallel में काम सौंपता है। यही trick Claude Code में इस्तेमाल हो रही है, और इसका reverse-engineering note (claude-trace) तथा Claude Research कैसे काम करता है इस लेख (multi-agent-research-system) में इसे और विस्तार से समझाया गया है। LLM tool-use patterns को खोजने का यह चरण अभी बहुत शुरुआती है, और models ने tools को वास्तव में अच्छी तरह इस्तेमाल करना भी पिछले 6 महीनों में ही शुरू किया है, इसलिए आगे काफी प्रगति संभव है
इसी वजह से मैं हर चीज़ को JSON में संभालने के बजाय यह पसंद करने लगा हूँ कि LLM खुद code बनाकर tool calls को handle करे। Huggingface की smolagents library में LLM python function-calling code generate करता है। अगर parallel tool calling चाहिए, तो prompt में साफ़ लिख सकते हैं, और synchronization भी LLM को ही handle करनी होगी। बेशक LLM द्वारा बनाए गए code को execute करने के अपने मुद्दे हैं, लेकिन उनके कई समाधान मौजूद हैं
Codex web interface के इस्तेमाल का एक अनुभव। एक refactoring plan इतना लंबा था कि उसे एक बार में खत्म नहीं किया जा सकता था, इसलिए “ask” feature से उसे कई tasks में बाँटा गया और जो parallel हो सकते थे उन्हें group किया गया। LLM ने इसे लगभग वैसे ही विभाजित किया जैसे कोई वास्तविक टीम काम बाँटती है, लेकिन tasks के बीच communication की कोई मान्यता न होने से context loss बहुत बड़ा था। यह खुद करने से भी ज्यादा समय लेने वाला निकला, फिर भी मैंने कोशिश की — कई sessions बनाकर हर task के लिए detailed prompts दिए गए (goal, method, verification, documentation आदि) और उन्हें sequentially चलाया गया। संक्षेप में, orchestrator agent बहुत simple tasks में काम आ सकता है, लेकिन इसका practical scope उम्मीद से ज्यादा सीमित है
कुछ भी जादू की तरह अपने-आप काम नहीं करता। जो operational characteristics पुराने systems में ध्यान रखनी पड़ती हैं, वही AI agents में भी बनानी पड़ेंगी। अगर कोई सिर्फ AI agent demos देखकर यह सोच ले कि “spaghetti code team” के code को कुछ साफ़-सुथरे AI prompts से replace किया जा सकता है, तो वह भ्रमित हो सकता है। कुछ सीमित मामलों में यह चल सकता है, लेकिन आखिरकार system में हर code किसी वजह से होता है, और अगर आप उस सारे code को LLM में translate करके भरने लगें, तो यह दिशा खो देने जैसा है
coding agents के लिए एक emerging pattern यह है कि containers का इस्तेमाल करके काम को isolate किया जाए, और git से output को review व merge किया जाए। उदाहरण के तौर पर container और MCP का एक उपयोग मामला है (container-use), जो parallel code work में उपयोगी है। बाकी कामों में n8n, Zapier, CrewAI जैसे workflow builders अब भी अक्सर इस्तेमाल होते हैं
यह लेख फिर याद दिलाता है कि शुरुआत “सबसे सरल चीज़” से करनी चाहिए, और असली complexity की ज़रूरत पड़ने पर ही उसे जोड़ना चाहिए। साफ़ परिभाषित LLM calls और थोड़े से simple glue logic से अधिक reliable, debug करने में आसान और कम लागत वाले systems बनाए जा सकते हैं। इसके उलट, दिखने में चमकदार agent systems कई बार ज्यादा समस्याएँ पैदा कर देते हैं
उम्मीद है कि AI लोगों के लिए सचमुच उपयोगी मददगार बने
Anthropic का इस तरह की तकनीकी जानकारी साझा करना अच्छा है, लेकिन उन्हें non-experts के लिए आसान guide version भी देना चाहिए। उदाहरण के लिए, अगर marketing department agents अपनाना चाहे, तो उन्हें basic level पर specs define करने वाली guide चाहिए। लेख के आखिरी हिस्से और appendix में इससे जुड़ी कुछ बातें हैं, लेकिन फिर भी “कैसे बनाएं” का फोकस implementation तक ही सीमित लगता है
(दिसंबर 2024 - अब पीछे मुड़कर देखें तो बहुत पुराना समय लगता है)
यह लेख बहुत अच्छी तरह टिक कर खड़ा है। मैं व्यक्तिगत रूप से इसे लगातार reference material की तरह इस्तेमाल कर रहा हूँ, और समय बीतने पर भी यह पुराना नहीं लगता। यह लेख Anthropic को "व्यावहारिक AI tools development partner" के रूप में एक नई छवि देने वाला लगा
अब ऐसा लगता है कि Agent को लेकर जो अतिरंजित hype थी, वह काफी हद तक शांत हो गई है
जानकारी के लिए, इस लेख पर उस समय भी चर्चा हुई थी मूल HN चर्चा
इस लेख की बात अच्छी लगी कि यह बढ़ा-चढ़ाकर या trend के पीछे भागकर नहीं, बल्कि यथार्थवादी तरीके से बात करता है। बहुत से लोग trend के पीछे agent systems बना रहे हैं, बिना यह सोचे कि उस काम के लिए सच में agent की ज़रूरत भी है या नहीं — इस प्रवृत्ति पर यह आलोचनात्मक नज़र डालता है