आपका AI एजेंट प्रोडक्शन में बार-बार क्यों विफल होता है (और इसे कैसे ठीक करें)

विषय सूची

जून 2026 में अपडेट किया गया।

TL;DR: अधिकांश प्रोडक्शन एजेंट विफलताएं पांच कारणों से होती हैं: एज केस को हैंडल न करने वाले भंगुर प्रॉम्प्ट, क्षणिक API एरर के लिए रिट्राई लॉजिक की कमी, क्या टूट रहा है यह देखने के लिए ऑब्जर्वेबिलिटी नहीं, कोई एग्जिट कंडीशन न होने वाले रनअवे लूप, और पर्याप्त अस्पष्ट टूल डेफिनेशन जिससे मॉडल गलत को चुनता है। सभी पांच मॉडल या फ्रेमवर्क बदले बिना ठीक करने योग्य हैं।

[ऑपरेटर की नज़र] मेरे पास प्रोडक्शन में 30+ एजेंट हैं। मुझे ये सभी विफलताएं हुई हैं। जिन्होंने सबसे ज़्यादा समय जलाया वे विदेशी नहीं थे — वे उबाऊ इन्फ्रास्ट्रक्चर विफलताएं थीं जो मुझे लगती थीं कि मैंने संभाल ली हैं।

विफलता 1: एज केस इनपुट पर टूटने वाले भंगुर प्रॉम्प्ट

आपके टेस्ट केस पर काम करने वाला प्रॉम्प्ट उन इनपुट पर विफल होगा जिनकी आपने उम्मीद नहीं की थी। यह मॉडल लिमिटेशन नहीं है — यह इंस्ट्रक्शन लेखन समस्या है।

लक्षण: एजेंट बकवास आउटपुट उत्पन्न करता है, गलत टूल कॉल करता है, या जब इनपुट थोड़ा अलग होता है तो मलफॉर्म्ड JSON आउटपुट करता है।

मूल कारण: आपका सिस्टम प्रॉम्प्ट केवल हैप्पी पाथ का वर्णन करता है। यह मॉडल को नहीं बताता कि डेटा गायब, मलफॉर्म्ड, या अस्पष्ट होने पर क्या करना है।

सुधार: अपने सिस्टम प्रॉम्प्ट में स्पष्ट एज केस हैंडलिंग जोड़ें:

If the input data is missing a required field, return:
{ "status": "error", "reason": "missing_field", "field": "<fieldname>" }
Do NOT attempt to infer or hallucinate missing values.

If you are uncertain which tool to call, call no tool and return:
{ "status": "clarification_needed", "question": "..." }

मॉडल एज केस के लिए स्पष्ट निर्देशों का विश्वसनीय रूप से पालन करता है। गलती यह मानना है कि यह गंदे केस को संभालने के लिए हैप्पी-पाथ निर्देशों को सामान्यीकृत करेगा।

विफलता 2: क्षणिक API एरर के लिए कोई रिट्राई लॉजिक नहीं

आपका एजेंट जो भी बाहरी API कॉल करता है वह किसी न किसी समय विफल होगा। Claude API, Meta Graph API, आपका डेटाबेस — सभी 5xx एरर लौटाते हैं, टाइमआउट होते हैं, या रेट-लिमिट होते हैं। अगर आपके एजेंट में रिट्राई लॉजिक नहीं है, तो एक क्षणिक एरर पूरे रन को मार देता है।

लक्षण: एजेंट रन अलग-अलग चरणों में बेतरतीब ढंग से विफल होते हैं। लॉग 503 या 429 दिखाते हैं, कोई फॉलो-अप प्रयास नहीं।

सुधार: प्रत्येक बाहरी कॉल को एक्सपोनेंशियल-बैकऑफ रिट्राई में लपेटें:

async function withRetry<T>(fn: () => Promise<T>, retries = 3, baseDelayMs = 500): Promise<T> {
  for (let attempt = 0; attempt <= retries; attempt++) {
    try {
      return await fn();
    } catch (err: any) {
      const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET";
      if (!isTransient || attempt === retries) throw err;
      const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100;
      await new Promise((r) => setTimeout(r, delay));
    }
  }
  throw new Error("unreachable");
}

// Usage
const result = await withRetry(() => client.messages.create({ ... }));

एक्सपोनेंशियल बैकऑफ के साथ तीन रिट्राई ~99% क्षणिक विफलताओं को हैंडल करता है। इसे हर बाहरी कॉल में जोड़ें और आपकी आधी यादृच्छिक विफलताएं गायब हो जाएंगी।

विफलता 3: कोई ऑब्जर्वेबिलिटी नहीं — आप नहीं देख सकते कि क्या टूट रहा है

यह प्रोडक्शन में सबसे आम विफलता मोड है और सबसे अधिक समय डिबग करने में लगाने वाला: एजेंट चुपचाप विफल होता है या गलत आउटपुट देता है, और आपको पता नहीं होता कि चेन में कहाँ गलत हुआ।

लक्षण: आप जानते हैं कि कुछ गड़बड़ है लेकिन चरण की पहचान नहीं कर सकते। आप console.log स्टेटमेंट जोड़ते हैं और पुनः उत्पन्न करने की कोशिश में मैन्युअल रूप से फिर से चलाते हैं।

सुधार: प्रत्येक चरण पर संरचित लॉगिंग, एक रन ID के साथ जो पूरे एग्जीक्यूशन को ट्रेस करता है:

function createLogger(runId: string, agentName: string) {
  return {
    step: (step: string, data: object) =>
      console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })),
    error: (step: string, err: unknown) =>
      console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })),
  };
}

const log = createLogger(crypto.randomUUID(), "newsletter-agent");
log.step("fetch_topic", { topicId: topic.id, topic: topic.name });
// ... do work ...
log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length });

अगर आप Cloudflare Workers पर हैं, तो ये लॉग Logpush या Workers Tail में जाते हैं। अगर स्थानीय रूप से या VPS पर चल रहे हैं, तो एक लॉग एग्रीगेटर में पाइप करें। संरचित JSON का मतलब है कि आप runId द्वारा फ़िल्टर करके देख सकते हैं कि एकल रन में बिल्कुल क्या हुआ।

विफलता 4: बिना एग्जिट कंडीशन के रनअवे लूप

एजेंटिक लूप — जहां मॉडल टूल कॉल करता है और कंडीशन पूरी होने तक इटरेट करता है — हमेशा चल सकते हैं अगर वह कंडीशन कभी पूरी नहीं होती या मॉडल इसे गलत पहचानता है।

लक्षण: टाइमआउट से पहले एजेंट API लागत में सैकड़ों डॉलर खर्च करता है। या यह बिना कोई प्रगति किए बार-बार एक ही टूल कॉल चलाता है।

सुधार: हमेशा एक हार्ड इटरेशन कैप और प्रगति जांच रखें:

const MAX_ITERATIONS = 10;
let iterations = 0;
let lastToolCallName = "";
let sameToolCallCount = 0;

while (true) {
  iterations++;
  if (iterations > MAX_ITERATIONS) {
    log.error("loop", { reason: "exceeded_max_iterations" });
    break;
  }

  const response = await client.messages.create({ ... });

  // Detect stuck loops: same tool called 3x in a row
  const toolCall = response.content.find(b => b.type === "tool_use");
  if (toolCall?.name === lastToolCallName) {
    sameToolCallCount++;
    if (sameToolCallCount >= 3) {
      log.error("loop", { reason: "stuck_loop", tool: toolCall.name });
      break;
    }
  } else {
    sameToolCallCount = 0;
    lastToolCallName = toolCall?.name ?? "";
  }

  if (response.stop_reason === "end_turn") break;
}

यह “बहुत लंबे समय तक चला” और “एक ही जगह घूमता रहा” दोनों विफलता मोड को पकड़ता है। कैप हैप्पी पाथ के लिए पर्याप्त उदार होनी चाहिए लेकिन ब्लास्ट रेडियस सीमित करने के लिए पर्याप्त तंग।

विफलता 5: अस्पष्ट टूल डेफिनेशन जिसे मॉडल गलत हल करता है

अगर आप मॉडल को ओवरलैपिंग डिस्क्रिप्शन वाले दो टूल देते हैं, तो यह कभी-कभी गलत को कॉल करेगा। यह विशेष रूप से search_database बनाम get_record या send_email बनाम create_draft जैसे टूल के साथ सामान्य है।

लक्षण: मॉडल टूल की सही श्रेणी को कॉल करता है लेकिन गलत विशिष्ट को चुनता है। या यह गलत संदर्भ में टूल कॉल करता है (जब केवल पढ़ना उचित था तब राइट टूल का उपयोग करना)।

सुधार: टूल डिस्क्रिप्शन को परस्पर अनन्य बनाएं और स्पष्ट रूप से “कब इसका उपयोग न करें” जोड़ें:

const tools = [
  {
    name: "get_subscriber",
    description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.",
    input_schema: { ... }
  },
  {
    name: "search_subscribers",
    description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.",
    input_schema: { ... }
  }
];

“X होने पर उपयोग न करें” क्लॉज वह हिस्सा है जिसे अधिकांश लोग छोड़ देते हैं। यह सबसे महत्वपूर्ण हिस्सा है। मॉडल सकारात्मक डिस्क्रिप्शन से अनुमान लगाने की तुलना में स्पष्ट नकारात्मक बाधाओं का पालन करने में बेहतर है।

एक और बात: खराब इनपुट पर अपने एजेंट का परीक्षण करें

अधिकांश एजेंट केवल साफ, हैप्पी-पाथ इनपुट पर परीक्षण किए जाते हैं। प्रोडक्शन में गंदे इनपुट होते हैं: खाली स्ट्रिंग, null फ़ील्ड, Unicode एज केस, API रिस्पॉन्स जो 200 लौटाते हैं लेकिन अप्रत्याशित स्कीमा के साथ।

एक टेस्ट सूट जोड़ें जो स्पष्ट रूप से परीक्षण करे:

• खाली या null इनपुट
• अधिकतम अपेक्षित लंबाई पर इनपुट
• विशेष अक्षर या गैर-ASCII टेक्स्ट वाले इनपुट
• बाहरी API अप्रत्याशित रिस्पॉन्स शेप लौटाते हैं

अगर आपका एजेंट इनमें से किसी पर टूटता है, तो इसे लाइव होने से पहले ठीक करें। प्रोडक्शन वातावरण आपके द्वारा की गई हर धारणा को खोजेगा।

ऑपरेटर का निष्कर्ष

प्रोडक्शन में अधिकांश एजेंट विफलताएं इन्फ्रास्ट्रक्चर समस्याएं हैं जो मॉडल समस्याओं के रूप में छुपी हैं। मॉडल स्विच करने से पहले, अपने प्रॉम्प्ट में रिट्राई, संरचित लॉगिंग, लूप कैप और स्पष्ट एज केस हैंडलिंग जोड़ें। अस्पष्ट टूल डेफिनेशन ठीक करें। फिर खराब इनपुट पर टेस्ट करें। मॉडल को दोष देने से पहले यह सब करें — मेरे अनुभव में, मॉडल आमतौर पर बदलने की ज़रूरत वाली आखिरी चीज़ है।