एक संवादात्मक AI एजेंट अंदर से कैसे काम करता है
OpenClaw में बातचीत के एक टर्न के 6 चरण — वास्तविक लेटेंसी, प्रति वार्तालाप लागत और हैलुसिनेशन के खिलाफ 4 रक्षा स्तर।
Equipe OpenClaw · Time de Engenharia & Produto
A Equipe OpenClaw é formada por engenheiros, designers e especialistas em IA dedicados a construir a melhor plataforma de agentes conversacionais para negócios brasileiros. Combinamos expertise…
एक संवादात्मक AI एजेंट अंदर से कैसे काम करता है (OpenClaw आर्किटेक्चर)
एक संवादात्मक AI एजेंट कैसे काम करता है व्यवहार में, टर्न दर टर्न? यह पोस्ट OpenClaw का ब्लैक बॉक्स खोलती है: जिस पल ग्राहक का संदेश WhatsApp पर आता है उससे लेकर उस टेक्स्ट तक जो एजेंट वापस लिखता है। यह तकनीकी होगा। यह तब काम का है अगर आप प्रोडक्ट आर्किटेक्चर के फैसले लेते हैं, अगर आप कोई सॉल्यूशन खरीदने जा रहे हैं और गहराई से मूल्यांकन करना चाहते हैं, या अगर आपको बातचीत के पीछे क्या हो रहा है यह जानने में मज़ा आता है।
TL;DR: हर टर्न 6 चरणों से गुज़रता है — ingest, कॉन्टेक्स्ट resolve, skills चयन, अगली कार्रवाई का निर्णय, guard-rails के साथ निष्पादन, मेमोरी persist। पूरा चक्र Cloudflare की edge पर <2 सेकंड में चलता है, बिना किसी फिक्स्ड सर्वर के।
आर्किटेक्चर क्यों मायने रखता है
संवादात्मक एजेंट जो डेमो में काम करता दिखता है लेकिन प्रोडक्शन में टूट जाता है, उसमें आमतौर पर इन 4 समस्याओं में से एक होती है:
- उच्च लेटेंसी — ग्राहक जवाब के लिए 8 सेकंड इंतज़ार करता है, बातचीत खत्म हो जाती है।
- अनियंत्रित हैलुसिनेशन — एजेंट कीमत, समय, पॉलिसी गढ़ लेता है।
- कॉन्टेक्स्ट खो जाना — ग्राहक 2 दिन बाद लौटता है और एजेंट सब कुछ "भूल" जाता है।
- अनियंत्रित लागत — हर लंबी बातचीत प्रॉम्प्ट भर देती है और आप टोकन पर भारी खर्च करते हैं।
ये चारों आर्किटेक्चर के चुनाव हैं, मॉडल की सीमाएँ नहीं। OpenClaw इन चारों से बचने के लिए बनाया गया था — और इसे समझने का रास्ता एक टर्न के चक्र को देखना है।
एक टर्न का चक्र (6 चरण)
कल्पना करें कि ग्राहक ने अभी-अभी यह संदेश भेजा "quero marcar pra sábado de manhã"। "received" और एजेंट के जवाब के बीच क्या होता है?
चरण 1 — Ingest (edge worker, <50ms)
WhatsApp का संदेश Meta के webhook के ज़रिए सीधे भौगोलिक रूप से सबसे नज़दीकी point of presence (PoP) पर एक Cloudflare Worker में आता है। ब्राज़ील में, इसका मतलब साओ पाउलो या रियो है, नेटवर्क लेटेंसी < 20ms।
Worker तीन काम करता है:
- Webhook की सिग्नेचर वैलिडेट करता है (WABA सीक्रेट के विरुद्ध HMAC)।
- रिसीवर के फ़ोन नंबर से tenant की पहचान करता है (
to_numberद्वारा multi-tenant)। - Payload को नॉर्मलाइज़ करता है — ऑडियो ट्रांसक्रिप्शन बन जाता है, इमेज डिस्क्रिप्शन बन जाती है, लोकेशन
{lat,lng}बन जाती है, टेक्स्ट जैसा है वैसा रहता है।
चरण 1 के अंत में आपके पास एक ऑब्जेक्ट {tenant_id, conversation_id, user_message} अगले कदम के लिए तैयार होता है।
चरण 2 — कॉन्टेक्स्ट Resolve (D1 + KV, ~80ms)
एजेंट को निर्णय लेने से पहले कॉन्टेक्स्ट के 3 हिस्सों की ज़रूरत होती है:
- हालिया इतिहास बातचीत का (अंतिम N प्रासंगिक टर्न)।
- दीर्घकालिक मेमोरी ग्राहक की (प्राथमिकताएँ, खरीदारी का इतिहास, नोट्स)।
- एजेंट की स्थिति (पर्सोना, सक्षम skills, नियम)।
ये सभी D1 (Cloudflare का वितरित SQLite) से आते हैं। D1 पारंपरिक Postgres/Mongo की जगह लेता है — कोई डेटाबेस सर्वर मेंटेन करने की ज़रूरत नहीं, worker से कुछ ms में एक्सेस, tenant_id द्वारा multi-tenant।
मुख्य बिंदु: हम पूरी बातचीत को प्रॉम्प्ट में लोड नहीं करते। OpenClaw का Memory Manager v2 (हमारे आंतरिक दस्तावेज़ीकरण में वर्णित) वर्तमान टर्न के लिए केवल प्रासंगिक टर्न चुनता है (अंतिम N + उच्च सिमेंटिक प्रासंगिकता वाले N)। यह 100+ टर्न की बातचीत में भी टोकन लागत को पूर्वानुमानित बनाए रखता है।
स्टेज 3 — Skills का चयन (policy engine, ~20ms)
प्रत्येक एजेंट के पास उपलब्ध skills का एक सेट होता है — ऐसे फंक्शन जिन्हें वह इनवोक कर सकता है। उदाहरण: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano।
संदेश "quero marcar pra sábado de manhã" मिलने पर, policy engine फ़िल्टर करता है:
- पहचानी गई इंटेंट (शेड्यूलिंग) के साथ संगत Skills।
- बातचीत के इस चरण के लिए अनुमत Skills (हर skill हर समय उपलब्ध नहीं होती)।
- वे Skills जो इस tenant ने सक्षम की हैं (calendar तभी दिखता है जब tenant ने इंटीग्रेट किया हो)।
अंत में आपके पास मॉडल को पास करने के लिए skills का एक छोटा सबसेट होता है — संभावित 50 नहीं, बल्कि केवल वे 4 जो यहाँ सार्थक हैं। यह मॉडल द्वारा गलत skill इनवोक करने की संभावना को काफ़ी हद तक कम कर देता है।
स्टेज 4 — निर्णय (LLM call, 400-1200ms)
अब मॉडल प्रवेश करता है। OpenClaw एक फ्रंटियर LLM (Anthropic Claude, OpenAI GPT, Google Gemini — tenant द्वारा कॉन्फ़िगर करने योग्य) को एक एकल कॉल करता है जिसमें शामिल है:
- System prompt = एजेंट का पर्सोना + नियम + उपलब्ध skills।
- History = स्टेज 2 में चयनित टर्न।
- User message = वर्तमान टर्न का संदेश।
मॉडल दो में से एक चीज़ के साथ जवाब देता है:
- अंतिम उत्तर (ग्राहक के लिए सीधा टेक्स्ट)।
- Tool call (विशिष्ट पैरामीटर के साथ एक विशेष skill निष्पादित करने का अनुरोध)।
उदाहरण "quero marcar pra sábado de manhã" में, मॉडल आमतौर पर यह लौटाता है:
{
"tool": "consultar_calendario",
"args": { "date_range": "2026-04-19 06:00 to 12:00" }
}
स्टेज 5 — गार्ड-रेल्स के साथ निष्पादन (परिवर्तनशील, ~100-500ms)
Skill मॉडल में नहीं चलती। यह हमारे कोड में चलती है, जो:
- पैरामीटर्स को वैलिडेट करता है (date_range का फॉर्मेट सही है? tenant के नियमों के अंदर है?).
- परमिशन चेक करता है (क्या इस एजेंट को इस कैलेंडर को एक्सेस करने का अधिकार है?).
- कॉल एक्सीक्यूट करता है (इस केस में Google Calendar API).
- स्ट्रक्चर्ड रिजल्ट रिटर्न करता है मॉडल को।
यह क्यों मायने रखता है? क्योंकि मॉडल कभी भी रिजल्ट गढ़ता नहीं है। अगर कैलेंडर [10h, 11h] रिटर्न करता है, तो बिल्कुल यही अगली कॉल में जाता है। अगर skill फेल होती है, तो मॉडल को पता होता है कि फेल हुई। एजेंट द्वारा "बना लेने" का जीरो रिस्क कि 9 बजे स्लॉट है जबकि है ही नहीं।
जिन केसेस में संवेदनशील जानकारी शामिल होती है (कीमत, समयसीमा, क्लाइंट का नाम), पाइपलाइन tool call को फोर्स करती है — मॉडल को अपने खुद के "ज्ञान" से जवाब नहीं देने देती। यह कमर्शियल एजेंट्स में हैलुसिनेशन की सबसे आम श्रेणी को खत्म कर देता है।
स्टेज 6 — रिस्पॉन्स और पर्सिस्टेंस (~50ms)
Skill का रिजल्ट हाथ में आने पर, मॉडल दूसरी कॉल करता है — अब क्लाइंट के लिए फाइनल रिस्पॉन्स बनाने के लिए। उदाहरण:
"मेरे पास शनिवार को 10 बजे और 11 बजे उपलब्ध है। कौन सा पसंद करेंगे?"
साथ ही, worker:
- WhatsApp API के ज़रिए मैसेज वापस भेजता है।
- पूरे टर्न (user + assistant + tool calls + duration) को D1 में पर्सिस्ट करता है।
- अगर टर्न ने कोई नया फैक्ट प्रोड्यूस किया (उदा: "क्लाइंट शनिवार पसंद करता है") तो लॉन्ग-टर्म मेमोरी अपडेट करता है।
- ऑब्ज़र्वेबिलिटी इवेंट एमिट करता है (लेटेंसी मेट्रिक, टोकन कॉस्ट, एस्केलेशन रेट)।
यह सब पैरेलल में चलता है। पर्सिस्टेंस मैसेज भेजने को ब्लॉक नहीं करती — क्लाइंट D1 का इंतज़ार नहीं करता।
हैलुसिनेशन के खिलाफ डिफेंस कहाँ है
प्रोडक्शन में हैलुसिनेट करने वाला एजेंट तेज़ी से भरोसा खो देता है। OpenClaw के पास डिफेंस की 4 लाइनें हैं:
- फोर्स्ड source-of-truth। फैक्चुअल डेटा (कीमत, समय, नाम) हमेशा skill से आता है, कभी अकेले मॉडल से नहीं।
- संवेदनशील डेटा पर डबल वेरिफिकेशन। अपॉइंटमेंट पर्सिस्ट करने से पहले क्लाइंट से कन्फर्म की जाती है। एक्सेस देने से पहले पेमेंट कन्फर्म किया जाता है।
- स्पष्ट नेगेटिव रूल्स। हर एजेंट की पर्सोना में "कभी X, Y, Z मत गढ़ो" शामिल होता है — मॉडल इसका पालन करता है।
- ह्यूमन को फॉलबैक। जब कोई भी skill सवाल को कवर नहीं करती, एजेंट कहता है
"मुझे टीम से चेक करने दीजिए"और एक टिकट खोलता है — अंदाज़ा नहीं लगाता।
पिछले 6 महीनों में हमने जो ऑडिट किए (मैन्युअली रिव्यू की गई असली बातचीत), फैक्चुअल हैलुसिनेशन की दर टर्न्स के 0.3% से नीचे रही — और लगभग सभी केस कॉन्फिग की वजह से थे (tenant ने रेलेवेंट skill इनेबल करना भूल गया), मॉडल की गलती नहीं।
प्रति बातचीत लागत
अच्छी आर्किटेक्चर तब तक अदृश्य रहती है जब तक आप बिल नहीं देखते। यह देखते हुए कि प्रत्येक टर्न 1-2 LLM कॉल + D1 लुकअप करता है, प्रति पूर्ण बातचीत (10-15 टर्न) की सामान्य लागत इस प्रकार रहती है:
Equipe OpenClaw
प्रकाशित 27 मई 2026
