AI एजेंट में मेमोरी कैसे जोड़ें: प्रोडक्शन के लिए स्टेट पर्सिस्टेंस पैटर्न

विषय-सूची

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

TL;DR: स्टेटलेस एजेंट — वे जो Worker बंद होने पर सब कुछ भूल जाते हैं — एक बार के काम के लिए ठीक हैं। जिस क्षण एजेंट को कल क्या हुआ याद रखना हो, लौटने वाले ग्राहक को पहचानना हो, या पिछले आउटपुट पर आधारित काम करना हो, आपको मेमोरी चाहिए। तीन पैटर्न हैं: वर्किंग मेमोरी (रन के दौरान का कॉन्टेक्स्ट, एक रन की अवधि के लिए KV में), एपिसोडिक मेमोरी (क्या और कब हुआ, एक क्वेरी करने योग्य लॉग) और सिमेंटिक मेमोरी (आप क्या जानते हैं, वेक्टर सर्च या स्ट्रक्चर्ड डेटा से प्राप्त)। सही पैटर्न को सही काम से जोड़ें।

[ऑपरेटर का नजरिया] मैं स्टेटलेस की दीवार से एक से अधिक बार टकराया हूँ। सोशल रिप्लाई एजेंट जो उन ग्राहकों से बार-बार अपना परिचय देता रहा जिनसे वह 20 बार बात कर चुका था। डेली ब्रीफ एजेंट जो चार दिन लगातार एक ही समस्या को फ्लैग करता रहा क्योंकि उसे याद नहीं था कि वह कल भी यही कर चुका है। सही प्रकार की मेमोरी जोड़ने से दोनों समस्याएँ हल हो गईं। यह है जो मैं उपयोग करता हूँ।

स्टेटलेस एजेंट लगातार क्यों विफल होते हैं

एक स्टेटलेस एजेंट हर रन केवल उसी से शुरू करता है जो आप उसे स्पष्ट रूप से देते हैं: सिस्टम प्रॉम्प्ट, यूज़र मैसेज, और इनवोकेशन के समय जो डेटा आप लाते हैं। उसे पिछले रन, पिछले यूज़र, या पिछले निर्णयों की कोई जानकारी नहीं होती।

एक बार की क्लासिफिकेशन टास्क के लिए — एक कमेंट पढ़ें, कैटेगरी वापस करें — स्टेटलेस सही है। यह तेज़, सस्ता और अनुमानयोग्य है।

जब आपको निरंतरता की जरूरत होती है, तब विफलता की सतह दिखाई देती है:

• एक ग्राहक-सामना करने वाला एजेंट जो ग्राहक का इतिहास नहीं पहचानता
• एक कंटेंट एजेंट जो एक लेख की सिफारिश करता है जो उसने पिछले सप्ताह भी की थी
• एक मॉडरेशन एजेंट जो एक हल किए गए केस को फिर से एस्केलेट करता रहता है
• एक डेली ब्रीफ जो हमेशा के लिए एक ही पुरानी अलर्ट दिखाता है

ये सभी एक ही समस्या के लक्षण हैं: एजेंट के पास रनों के बीच कॉन्टेक्स्ट ले जाने का कोई तरीका नहीं है।

तीन प्रकार की मेमोरी

वह फ्रेमवर्क जो मुझे प्रोडक्शन में उपयोगी लगता है:

1. वर्किंग मेमोरी — एजेंट एक ही रन के दौरान अभी क्या जानता है। इनवोकेशन के जीवनकाल के लिए KV या इन-मेमोरी में रखा जाता है।
2. एपिसोडिक मेमोरी — क्या और कब हुआ। एक स्ट्रक्चर्ड लॉग जिसे एजेंट हर रन की शुरुआत में खुद को ओरिएंट करने के लिए पढ़ता है।
3. सिमेंटिक मेमोरी — यह दुनिया, ग्राहकों, या एक नॉलेज बेस के बारे में क्या जानता है। प्रासंगिक होने पर स्ट्रक्चर्ड क्वेरी या वेक्टर सर्च के माध्यम से प्राप्त किया जाता है।

आपको हमेशा तीनों की जरूरत नहीं होती। मेरे द्वारा चलाए जाने वाले अधिकांश एजेंटों को वर्किंग + एपिसोडिक की जरूरत होती है। सिमेंटिक मेमोरी बनाना सबसे कठिन है और तभी अपनी जगह कमाती है जब नॉलेज बेस इतना बड़ा हो कि कॉन्टेक्स्ट विंडो में नहीं आ सके।

वर्किंग मेमोरी: रन-के-दौरान कॉन्टेक्स्ट

वर्किंग मेमोरी वह स्टेट है जो एक एजेंट रन की अवधि के लिए रहती है। सबसे सरल रूप फंक्शन स्कोप में वेरिएबल्स हैं। अधिक दिलचस्प रूप एक शेयर्ड KV की है जिसे एक ही रन में सबटास्क पढ़ते और लिखते हैं।

मेरा सोशल रिप्लाई एजेंट एक क्यू मैसेज में कमेंट्स का बैच प्रोसेस करते समय कॉन्टेक्स्ट जमा करने के लिए वर्किंग मेमोरी का उपयोग करता है। शुरुआत में यह KV से प्रत्येक ग्राहक की हालिया बातचीत का इतिहास पढ़ता है, प्रोसेसिंग के दौरान नया कॉन्टेक्स्ट जोड़ता है, और अंत में वापस लिखता है।

// workers/social-reply.ts

async function processComment(
  comment: SocialCommentEvent,
  env: Env
): Promise<void> {
  // इस ग्राहक का हालिया इतिहास KV से लोड करें (वर्किंग मेमोरी)
  const historyKey = `customer:${comment.userId}:history`;
  const rawHistory = await env.AGENT_KV.get(historyKey);
  const history: ConversationTurn[] = rawHistory
    ? JSON.parse(rawHistory)
    : [];

  // इतिहास से कॉन्टेक्स्ट-अवेयर सिस्टम प्रॉम्प्ट बनाएं
  const systemPrompt = buildSystemPrompt(history);

  const response = await anthropic.messages.create({
    model: "claude-opus-4-8",
    max_tokens: 512,
    system: systemPrompt,
    messages: [{ role: "user", content: comment.text }],
  });

  const reply =
    response.content[0].type === "text" ? response.content[0].text : "";

  // इतिहास अपडेट करें — आखिरी 10 टर्न रखें, TTL 30 दिन
  const updatedHistory: ConversationTurn[] = [
    ...history.slice(-9),
    { role: "assistant", content: reply, timestamp: comment.timestamp },
  ];
  await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), {
    expirationTtl: 60 * 60 * 24 * 30,
  });

  await postReply(comment, reply, env);
}

दो बातें ध्यान देने योग्य हैं। इतिहास 10 टर्न तक सीमित है — एक स्लाइडिंग विंडो इंजेक्ट करें, इसे असीमित रूप से न बढ़ने दें। TTL 30 दिन है: यदि एक ग्राहक एक महीने के लिए चुप रहता है, इतिहास समाप्त हो जाता है और एजेंट ताज़ा शुरू करता है। दोनों जानबूझकर हैं।

एपिसोडिक मेमोरी: क्या और कब हुआ

एपिसोडिक मेमोरी एजेंट का लॉग है। पिछले रनों का एक स्ट्रक्चर्ड रिकॉर्ड जिसे एजेंट हर नए रन की शुरुआत में खुद को दोहराने से बचाने के लिए पढ़ता है।

मेरा डेली ब्रीफ एजेंट हर दिन एक ही पुरानी अलर्ट दिखाता था क्योंकि प्रत्येक रन को पता नहीं था कि पहले क्या फ्लैग किया गया था। समाधान: पिछली अलर्ट का एक स्ट्रक्चर्ड लॉग जिसे एजेंट ब्रीफ जनरेट करने से पहले पढ़ता है।

// workers/daily-brief.ts

interface AlertLogEntry {
  id: string;
  surfacedAt: string; // ISO टाइमस्टैंप
  resolvedAt?: string;
  summary: string;
}

async function buildDailyBrief(env: Env): Promise<void> {
  const [emails, calendar, tasks] = await Promise.all([
    fetchOvernightEmails(env),
    fetchTodayCalendar(env),
    fetchTopTasks(env),
  ]);

  // एपिसोडिक मेमोरी लोड करें: क्या पहले फ्लैग हो चुका है
  const rawLog = await env.AGENT_KV.get("brief:alert-log");
  const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : [];

  // केवल हालिया, अनसुलझी अलर्ट फ़िल्टर करें
  const sevenDaysAgo = new Date(
    Date.now() - 7 * 24 * 60 * 60 * 1000
  ).toISOString();
  const recentAlerts = alertLog.filter(
    (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt
  );

  const brief = await synthesizeBrief(
    { emails, calendar, tasks, recentAlerts },
    env
  );

  // इस रन में फ्लैग की गई नई अलर्ट से लॉग अपडेट करें
  const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({
    id: crypto.randomUUID(),
    surfacedAt: new Date().toISOString(),
    summary: a,
  }));

  const updatedLog = [...alertLog, ...newAlerts].slice(-100); // आखिरी 100 रखें
  await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog));

  await writeToWorkspace(brief.content, env);
}

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

यह पैटर्न सामान्यीकृत होता है: कोई भी एजेंट जो निर्णय, फ्लैग, या सिफारिशें उत्पन्न करता है, लॉग से लाभ उठाता है। लॉग सस्ता है (KV में कुछ KB), भुगतान अधिक है (कोई अनावश्यक आउटपुट नहीं)।

सिमेंटिक मेमोरी: आप क्या जानते हैं

सिमेंटिक मेमोरी नॉलेज बेस है। यह क्वेरी के समय “आप X के बारे में क्या जानते हैं?” का जवाब देती है, बजाय सब कुछ सिस्टम प्रॉम्प्ट में पहले से भरने के।

सबसे सरल रूप KV या डेटाबेस में एक स्ट्रक्चर्ड लुकअप है। मेरा Pickleland बुकिंग एजेंट कन्फर्मेशन तैयार करने से पहले ग्राहक प्रोफाइल और कोर्ट प्राथमिकताएँ खोजता है:

// workers/booking-agent.ts

interface CustomerProfile {
  userId: string;
  preferredCourts: string[];
  experienceLevel: "beginner" | "intermediate" | "advanced";
  specialNotes: string;
}

async function draftConfirmation(
  booking: BookingEvent,
  env: Env
): Promise<string> {
  // KV से ग्राहक प्रोफाइल प्राप्त करें (सिमेंटिक मेमोरी — तथ्यात्मक ज्ञान)
  const profileKey = `customer:${booking.userId}:profile`;
  const rawProfile = await env.AGENT_KV.get(profileKey);
  const profile: CustomerProfile | null = rawProfile
    ? JSON.parse(rawProfile)
    : null;

  const systemPrompt = profile
    ? `आप व्यक्तिगत बुकिंग कन्फर्मेशन तैयार करते हैं। यह ग्राहक ${profile.preferredCourts.join(", ")} को प्राथमिकता देता है और ${profile.experienceLevel} स्तर का खिलाड़ी है। ${profile.specialNotes}`
    : "आप एक पिकलबॉल सुविधा के लिए बुकिंग कन्फर्मेशन तैयार करते हैं।";

  const response = await anthropic.messages.create({
    model: "claude-haiku-4-5-20251001",
    max_tokens: 256,
    system: systemPrompt,
    messages: [
      {
        role: "user",
        content: `इसके लिए कन्फर्मेशन तैयार करें: ${JSON.stringify(booking)}`,
      },
    ],
  });

  return response.content[0].type === "text" ? response.content[0].text : "";
}

बड़े नॉलेज बेस के लिए — प्रोडक्ट डॉक्यूमेंटेशन, एक सपोर्ट नॉलेज बेस, कॉन्टेक्स्ट विंडो में न आ सकने वाला कुछ भी — आपको वेक्टर स्टोर की जरूरत है। वर्कफ्लो है: क्वेरी एम्बेड करें, टॉप-k प्रासंगिक चंक्स प्राप्त करें, उन्हें कॉन्टेक्स्ट में इंजेक्ट करें। Cloudflare Vectorize इसे नेटिव रूप से हैंडल करता है यदि आप पहले से Workers पर हैं। बड़े इंडेक्स के लिए मैंने Upstash Vector का उपयोग किया है। चुनाव स्केल पर निर्भर करता है, सिद्धांत पर नहीं।

सिमेंटिक मेमोरी के बारे में ईमानदार टिप्पणी: यह तीनों में बनाना और बनाए रखना सबसे कठिन है। इंडेक्स को अद्यतन रहना चाहिए। रिट्रीवल क्वालिटी भिन्न होती है। स्ट्रक्चर्ड लुकअप से शुरू करें — KV, D1 में एक टेबल — और वेक्टर सर्च तक तभी पहुँचें जब स्ट्रक्चर्ड दृष्टिकोण आपको जरूरी ज्ञान सतह को कवर न कर सके।

मेमोरी निर्णय फ्रेमवर्क

एजेंट में कोई मेमोरी जोड़ने से पहले, तीन सवालों के जवाब दें:

1. क्या एजेंट को रनों के बीच याद रखने की जरूरत है? यदि हर इनवोकेशन वास्तव में स्वतंत्र है — एक अनुवाद, एक वर्गीकरण, एक बार की पीढ़ी — मेमोरी छोड़ें। स्टेटलेस सरल और सस्ता है।

2. क्या एजेंट खुद को दोहरा रहा है या अपने इतिहास से अंधा होकर काम कर रहा है? यदि हाँ, तो पहले एपिसोडिक मेमोरी जोड़ें। यह सबसे कम प्रयास वाला समाधान है और अधिकांश “एजेंट X करता रहता है” शिकायतों को कवर करता है।

3. क्या एजेंट हर यूज़र या इंटिटी को एक जैसा मान रहा है जबकि ऐसा नहीं करना चाहिए? यदि हाँ, तो वर्किंग मेमोरी (ग्राहक इतिहास, यूज़र प्रोफाइल) या सिमेंटिक मेमोरी (एक सर्च या रिट्रीवल सिस्टम) जोड़ें।

जो गलती मैं सबसे अधिक देखता हूँ: कोई एक विशाल नॉलेज बेस (सिमेंटिक मेमोरी) एक ऐसे एजेंट में जोड़ता है जो वास्तव में इसलिए विफल हो रहा था क्योंकि उसके पास एपिसोडिक मेमोरी नहीं थी — उसने क्या किया इसका कोई लॉग नहीं था। जटिलता समस्या से मेल नहीं खाती।

प्रोडक्शन में मैं वास्तव में क्या उपयोग करता हूँ

30+ एजेंटों में:

• सभी में कम से कम वर्किंग मेमोरी है — एक रन के भीतर कुछ न कुछ स्टेट, भले ही वह केवल कॉन्टेक्स्ट विंडो ही क्यों न हो।
• लगभग आधे में एपिसोडिक मेमोरी है — पिछले रन, निर्णयों, या फ्लैग का एक लॉग। यह लगभग हमेशा जोड़ने लायक होता है।
• तीन या चार में वेक्टर स्टोर द्वारा समर्थित वास्तविक सिमेंटिक मेमोरी है। ये वे एजेंट हैं जो एक बड़े, गतिशील नॉलेज बेस पर सवालों का जवाब देते हैं।

Cloudflare KV वर्किंग और एपिसोडिक मेमोरी के लिए मेरा डिफ़ॉल्ट स्टोर है। यह तेज़, सस्ता और Workers में नेटिव रूप से एकीकृत है — कोई अतिरिक्त क्लाइंट नहीं, कोई अलग क्रेडेंशियल नहीं। सीमा: KV अंततः consistent है और उच्च-आवृत्ति लेखन के लिए उपयुक्त नहीं है। उन एजेंटों के लिए जो प्रति सेकंड कई बार स्टेट लिखते हैं, मैं इसके बजाय Durable Objects या D1 डेटाबेस का उपयोग करता हूँ।

वेक्टर-समर्थित सिमेंटिक मेमोरी के लिए, मैं छोटे-से-मध्यम इंडेक्स (लगभग ~100K वेक्टर से कम) के लिए Cloudflare Vectorize और उससे बड़े के लिए Upstash Vector का उपयोग करता हूँ। दोनों में फर्स्ट-क्लास JavaScript क्लाइंट हैं।

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

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

संबंधित: 30+ प्रोडक्शन एजेंट चलाने के लिए मेरा एजेंट स्टैक · इवेंट-ट्रिगर्ड बनाम शेड्यूल्ड एजेंट · मैं कैसे मापता हूँ कि एक AI एजेंट वास्तव में काम कर रहा है

आपके उपयोग के मामले के लिए एजेंट मेमोरी डिज़ाइन करने में मदद चाहिए? संपर्क करें — मैं ऑपरेटर टीमों के लिए प्रोडक्शन एजेंट सिस्टम डिज़ाइन करता हूँ।