एजेंट डिज़ाइन अब भी मुश्किल है

 (lucumr.pocoo.org)
20 पॉइंट द्वारा GN⁺ 2025-11-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एजेंट बनाने की प्रक्रिया अब भी जटिल है, और SDK abstraction अक्सर वास्तविक tool usage चरण में टूट जाता है
  • Caching management हर platform पर अलग है, इसलिए manual management ज़्यादा predictable और efficient रहती है, और Anthropic SDK का explicit cache point तरीका अधिक पसंद किया जाता है
  • Reinforcement loop task state tracking और failure recovery में अहम भूमिका निभाता है, और loop के collapse को रोकने के लिए failures को अलग isolate करना ज़रूरी है
  • Shared state management के लिए file system जैसी hierarchy महत्वपूर्ण है, और इसे code execution तथा reasoning tools के बीच data exchange की आधार संरचना के रूप में इस्तेमाल किया जाता है
  • Output tools और model selection अब भी कठिन हैं, और Haiku, Sonnet, Gemini models जैसे प्रमुख विकल्प बने रहने से agent design की जटिलता जारी है

एजेंट SDK का चयन

  • एजेंट बनाते समय यह चुनना पड़ता है कि OpenAI, Anthropic जैसे base SDKs को सीधे इस्तेमाल किया जाए या Vercel AI SDK और Pydantic जैसे high-level abstraction layers का उपयोग किया जाए
    • लेखक बताते हैं कि उन्होंने पहले Vercel AI SDK की provider abstraction का उपयोग किया था, लेकिन अब वे वही चुनाव दोबारा नहीं करेंगे
  • models के बीच अंतर इतना बड़ा है कि अपनी agent abstraction layer खुद बनानी पड़ती है, और मौजूदा SDK abstractions इसके लिए उपयुक्त नहीं हैं
    • cache control, reinforcement requirements, tool prompts आदि में सूक्ष्म अंतर मौजूद हैं
  • Vercel SDK में provider-side tool handling से जुड़ी समस्याएँ आती हैं
    • Anthropic के web search tool द्वारा message history को खराब कर देने के मामले सामने आए हैं
    • Anthropic SDK को सीधे इस्तेमाल करने पर cache management और error messages अधिक स्पष्ट मिलते हैं
  • निष्कर्ष यह है कि फिलहाल abstraction layer के बिना सीधे SDK इस्तेमाल करने का तरीका अधिक फायदेमंद माना गया है

Caching management से मिली सीख

  • हर platform का caching approach अलग है, और Anthropic caching के लिए शुल्क लेता है तथा explicit management की मांग करता है
    • manual management को इसलिए पसंद किया जाता है क्योंकि इससे cost और cache utilization अधिक predictable हो जाते हैं
  • explicit caching से conversation branching या context editing संभव हो जाता है
    • system prompt के बाद, बातचीत के शुरुआती हिस्से आदि में कई cache points सेट किए जा सकते हैं
  • cache बनाए रखने के लिए system prompt और tool selection को static रखा जाता है, जबकि समय जैसी dynamic जानकारी बाद के messages में दी जाती है
  • cache के साथ reinforcement loop का सक्रिय उपयोग करके cost predictability और control बढ़ाया जाता है

एजेंट loop के भीतर reinforcement

  • tool execution के दौरान केवल result लौटाने के बजाय goal, task state, failure reason जैसी जानकारी भी loop में फिर से डाली जा सकती है
  • Claude Code के todo write tool की तरह self-reinforcement tools loop को आगे बढ़ाने में मदद करते हैं
  • environment change या failure recovery के समय state change information inject करके loop की स्थिरता सुनिश्चित की जाती है
    • उदाहरण: corrupted data के आधार पर retry करते समय, पिछले चरण पर लौटने के लिए message insert करना

Failure isolation

  • जिन tasks में बार-बार failure की आशंका हो, उन्हें subagent में अलग चलाकर केवल सफल result को ही ऊपरी loop में report किया जाता है
    • failed attempts का summary अगले task के लिए learning material की तरह इस्तेमाल किया जा सकता है
  • Anthropic SDK में context editing feature के जरिए failure records हटाए जा सकते हैं
    • पूरी failure information को रखने के बजाय केवल ज़रूरी हिस्से छोड़े जाते हैं
    • हालांकि context editing से cache invalidation हो सकती है, जिससे cost बढ़ सकती है

Subagents और shared file system

  • अधिकांश agents code execution और generation पर आधारित होते हैं, इसलिए एक common data store की ज़रूरत होती है
    • इसके लिए virtual file system (VFS) का उपयोग किया जाता है
  • image generation, compression, inference जैसे कई tools को एक ही file path साझा करना चाहिए
    • ExecuteCode और RunInference tools को उसी file system तक पहुंच होनी चाहिए
  • यह संरचना data exchange के bottleneck हटाने और loop के भीतर लगातार tasks संभालने के लिए आवश्यक है

Output tool

  • एजेंट chat session के रूप में नहीं बल्कि private internal message loop के रूप में काम करता है, और बाहरी दुनिया से संवाद output tool के ज़रिए होता है
    • output tool ईमेल भेजने जैसी बाहरी communication संभालता है
  • output tool का tone और writing style नियंत्रित करना मुश्किल है, और सहायक LLM (Gemini 2.5 Flash) का उपयोग करने पर quality गिर सकती है और latency बढ़ सकती है
    • sub-tool के पास पर्याप्त context नहीं होने से inaccurate results बन सकते हैं
  • अगर loop के अंत में output tool call नहीं होता, तो reinforcement message inject करके उसे call करने के लिए प्रेरित किया जाता है

Model selection

  • Haiku और Sonnet tool calling performance में अच्छे हैं, इसलिए इन्हें मुख्य loop models के रूप में उपयोग किया जाता है
  • Gemini 2.5 बड़े दस्तावेज़ों के summary, PDF processing और image information extraction के लिए उपयुक्त है
    • Sonnet model का एक नुकसान यह है कि वह अक्सर safety filters में फँस जाता है
  • GPT series models ने main loop में कोई खास परिणाम नहीं दिया
  • केवल token cost के आधार पर कुल लागत का आकलन नहीं किया जा सकता
    • बेहतर tool-calling model कम tokens में वही काम कर सकता है

Testing और evals

  • agent testing और evaluation automation को सबसे कठिन समस्या बताया गया है
    • prompts के विपरीत, इसे बाहरी सिस्टम में सीधे सरल तरीके से evaluate नहीं किया जा सकता
    • वास्तविक execution data पर आधारित observability या instrumentation की आवश्यकता होती है
  • लेखक कहते हैं कि उन्हें अभी तक कोई संतोषजनक evaluation method नहीं मिला है

Coding agent updates

  • coding agents से जुड़ा बदलाव बहुत बड़ा नहीं है
    • हाल में वे Amp agent को आज़मा रहे हैं, और Oracle subagent तथा main loop के interaction structure की काफ़ी सराहना करते हैं
  • Amp और Claude Code को देखकर लगता है कि वे वास्तव में अपने tools इस्तेमाल करने वाले developers के लिए डिज़ाइन किए गए हैं

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

1 टिप्पणियां

 
GN⁺ 2025-11-23
Hacker News राय

  • करीब 2 साल पहले मैंने इस क्षेत्र में कंपनी शुरू की थी। अब यह अच्छी तरह चल रही है
    पिछले 2 वर्षों में मैंने यह सीखा है कि कई तकनीकें LLM की मौजूदा सीमाओं को पूरा करने के लिए अस्थायी optimization हैं। तकनीक बहुत तेजी से आगे बढ़ रही है, इसलिए आज की समस्या कल तक गायब हो सकती है
    पहले AWS में disk encryption फीचर नहीं था, तो हमारी टीम ने उसे खुद implement करने में 3 महीने लगा दिए, लेकिन तुरंत बाद AWS ने एक बटन से होने वाला standard encryption लॉन्च कर दिया। आखिरकार वह समय की बर्बादी निकला
    इसलिए मैंने सीखा कि कभी-कभी कुछ भी न करना ही सबसे अच्छा होता है

    • मुझे लगता है कि यही सबसे अहम insight है। आजकल कंपनी के सहकर्मी AI workshop चलाकर कहते हैं कि उन्होंने नए pattern “ईजाद” कर लिए, लेकिन उनमें से ज्यादातर अगले हफ्ते तक पुराने हो जाते हैं
      पहले की तरह common language में pattern सीखने का दौर खत्म हो गया है, और अब AI pattern की half-life एक हफ्ता भर है। यहां तक कि “agent” क्या है, यह 10 experts से पूछो तो 10 जवाब मिलेंगे
    • AI की प्रगति की रफ्तार देखें तो, पर्याप्त इंतजार करने पर अंत में बात शायद OpenAI को सीधे इस्तेमाल करने पर आकर खत्म हो सकती है
    • जानना चाहता हूँ कि क्या आपका बिजनेस मुनाफे में है, यानी revenue operating cost से ज्यादा है। मुझे लगा था कि agent से कमाई करना मुश्किल है। राज क्या है, यह जानना चाहूँगा
    • ‘कुछ न करना’ अच्छी तरह जानना, इस क्षमता से जुड़ा है कि टीम जिस समस्या पर काम कर रही है वह core problem है या peripheral problem, इसका आकलन कर सके
    • सहमत हूँ। आजकल इंतजार करना भी एक strategy हो सकती है। लेकिन बहुत ज्यादा इंतजार करने पर हम उस जाल में फंस सकते हैं जहाँ AGI आने तक कुछ भी नहीं करते

  • पिछले 2 साल में मैंने कई agent SDK इस्तेमाल किए, लेकिन खुद बनाकर देखा तो यह उम्मीद से कहीं ज्यादा जटिल निकला
    Claude Code SDK (अब Agent SDK) शानदार है, लेकिन अभी भी Claude Code के साथ इसका coupling पूरी तरह अलग नहीं हुआ है। उदाहरण के लिए skills को सीधे filesystem में रखना पड़ता है
    OpenAI SDK में platform के साथ मजबूत coupling होने की वजह से dashboard पर automatic tracking और evaluation संभव है, लेकिन third-party models को जोड़ना मुश्किल है
    Google Agent Kit में अभी Typescript SDK नहीं है, और Mastra में server चलाना पड़ता है, इसलिए असुविधाजनक है
    अभी मैं SmythOS SDK टेस्ट कर रहा हूँ, जिसमें model provider चुनने और architecture define करने की काफी आजादी है
    जानना चाहता हूँ कि आपकी मौजूदा संरचना Agent → SubAgents → SubSubAgents है, या Planner-Executor प्रकार की

    • ज्यादातर SDK बुनियादी फीचर्स से आगे बढ़ते ही बुरे सपने बन जाते हैं। इसलिए मैंने OpenRouter client library लेकर खुद implement किया
      कोड की मात्रा बढ़ जाती है, लेकिन mental model सरल रहता है, इसलिए समझना बहुत आसान हो जाता है। ReAct तरीके से loop चलाते हुए reasoning और tool call दोहराता हूँ
      आखिरकार SDK के बिना भी agent handoff या workflow सीधे implement किए जा सकते हैं
    • मुझे लगता है ‘sub-agent’ शब्द लगभग बेकार है। आखिर में यह बस tool calling का abstraction है, और main loop के बाहर सिर्फ एक साधारण input-output contract मायने रखता है
    • कहा गया था कि Claude Code सिर्फ Anthropic models को support करता है, लेकिन Claude Code Router का इस्तेमाल करें तो दूसरे models भी जोड़े जा सकते हैं
    • मैं Google ADK का Go version इस्तेमाल कर रहा हूँ। यह अभी अपरिपक्व है, लेकिन workflow composition और vendor compatibility अच्छी होने से मैं संतुष्ट हूँ
    • मैंने AWS का Strands Agents SDK भी इस्तेमाल किया है। यह Bedrock के बिना भी बड़े vendor APIs को support करता है और इसका API design काफी flexible है (मैं AWS कर्मचारी हूँ, लेकिन यह निजी राय है)

  • हमने सीखे हुए कुछ agent design principles साझा कर रहा हूँ

    1. अगर code generation ज्यादा है, तो Claude Code / Agent SDK सबसे efficient है
    2. Vendor lock-in से भी बड़ा जोखिम ChatGPT से खराब product बनाना है
    3. Claude Code की self-awareness बहुत अच्छी है, इसलिए अपने बारे में सवाल पूछो तो यह तुरंत और सही जवाब देता है
    4. अगर agent को असली computer दे दिया जाए, तो वह बहुत ज्यादा शक्तिशाली हो जाता है। हम e2b.dev इस्तेमाल करते हैं, लेकिन Modal भी अच्छा है
      संदर्भ के लिए, हमारी कंपनी Definite एक data platform है, जिसे Heroku की तरह AI data engineers चलाते हैं
    • Claude रचनात्मक है, लेकिन जटिल codebase में यह झूठे जवाब और reward hacking भी कर सकता है। ऐसे मामलों में Codex ज्यादा स्थिर है
    • मुझे लगता है समस्या यह है कि बहुत से products, ChatGPT web से भी खराब quality में लॉन्च हो रहे हैं
    • अपना agent system बनाने पर जोर देने के बजाय, Claude Code जैसे तैयार tools का उपयोग करके वास्तविक value बनाने पर ध्यान देना चाहिए
    • बेशक, “सब कुछ big tech पर छोड़ दो” भी खतरनाक है। खुद बनाना, सीखना और साझा करना महत्वपूर्ण प्रक्रिया है। मैं भी ADK और VS Code extension के साथ तेजी से आगे बढ़ रहा हूँ

  • मैं कई सालों से agent बना रहा हूँ, और सबसे अच्छा फैसला यह था कि अपना framework खुद बनाया
    कई open source abstraction layers, SDK बदलने के साथ maintain नहीं रह पातीं और आखिरकार ढह जाती हैं

    • मैं भी यही सोचता हूँ। Agent का मूल है structured input-output, tool registration और call loop, और agents के बीच delegation
      मैंने PydanticAI आधारित OpusAgents बनाया है, जो MCP server से सरल है, लेकिन फिर भी scalable open source framework है
    • लेखक के रूप में मैं सहमत हूँ। मैंने इससे जुड़ी अपनी सोच इस पोस्ट में लिखी है
    • हमने भी customer support chatbot बनाते समय, पुरानी संरचना की जगह chatroom आधारित architecture अपनाया। Frontend सिर्फ message भेजता है, और backend में features को धीरे-धीरे बढ़ाया जाता है
    • हालांकि पूरा framework खुद बनाना बहुत बड़ा काम है। लंबे समय में agent platform के game engine की तरह standardize होने की संभावना है

  • आजकल LangChain/RAG के शुरुआती दौर की तरह अत्यधिक abstraction और complexity फिर दोहराई जा रही है
    आखिरकार agent को साधारण REPL संरचना (Read, Eval, Print, Loop) की तरह समझा जा सकता है।
    इसी विचार से खुद बनाया गया lightweight version, भारी SDK से कहीं ज्यादा स्थिर निकला

    • लेकिन वास्तव में जटिल use cases में विशेषीकृत subagent और data sharing structure की जरूरत पड़ती है। सिर्फ एक साधारण loop की भी सीमाएँ हैं

  • agent की testing और evaluation (evals) सबसे कठिन समस्या है।
    बाहरी सिस्टम से evaluate करना मुश्किल है, क्योंकि input बहुत ज्यादा होते हैं और execution के दौरान data observe करना पड़ता है
    कौन-सा approach प्रभावी है, इस पर अभी भरोसा नहीं है

    • मुझे चिंता है कि ज्यादातर AI agent deployments औपचारिक testing के बिना सिर्फ ‘अंदाज़’ पर निर्भर लगते हैं
    • Google के ADK evaluation docs देखें तो, हर run में नतीजे बदल जाने की वजह से pass/fail criteria तय करना मुश्किल बताया गया है। आखिर में फिर किसी दूसरे LLM से evaluate किया जाता है

  • agent development में बुनियादी बातों तक के लिए भी स्पष्ट guidelines की कमी है
    उदाहरण के लिए function tool के input-output types संभालते समय, number ID पास करने पर serialization errors या precision loss हो जाता है
    आखिर में इसे string में बदलकर हल किया
    OpenAI docs (लिंक) और Google ADK issue (लिंक) देखें,
    तो वे कहते हैं “result string होना चाहिए”, लेकिन असली examples में dict या number return किया जाता है। ऐसी असंगतियाँ भ्रम पैदा करती हैं

  • मैं एक खास agentic coding company का product इस्तेमाल करता हूँ (नाम नहीं बताऊँगा)
    model release, evaluation, sub-agent management, billing—सब कुछ वही संभाल लेते हैं, और मैं बस काम पर ध्यान दे पाता हूँ, इसलिए संतुष्ट हूँ

    • शायद वह कंपनी Sourcegraph का Amp होगी। शुरुआत में यह थोड़ा कच्चा था, लेकिन अब काफी polished लगती है

  • पिछले दो महीनों में मैंने अलग-अलग कामों के लिए कई agents implement किए। शुरू में Claude Code इस्तेमाल किया, लेकिन vendor lock-in और usage limits की वजह से खुद runtime बनाया
    फिलहाल यह सिर्फ OpenAI को support करता है, लेकिन Claude और Gemini को भी जोड़ा जा सके, इस तरह design किया है
    इसे open source किया है, चाहें तो देख सकते हैं → agent-composer

  • मेरी टिप सीधी है: SDK मत इस्तेमाल करो, खुद while loop चलाओ और JSON संभालो
    context size और errors पर खुद control होना चाहिए, तभी सच में flexible agent बनाया जा सकता है