संवादात्मक AI एजंट आतून कसा कार्य करतो

एक संवादात्मक AI एजंट आतून कसा काम करतो (OpenClaw आर्किटेक्चर)

एक संवादात्मक AI एजंट कसा काम करतो प्रत्यक्षात, प्रत्येक टर्नमध्ये? हा पोस्ट OpenClaw चा ब्लॅक बॉक्स उघडतो: ग्राहकाचा संदेश WhatsApp वर येतो त्या क्षणापासून ते एजंट परत लिहितो त्या मजकुरापर्यंत. हे तांत्रिक असेल. जर तुम्ही प्रॉडक्ट आर्किटेक्चरचे निर्णय घेत असाल, एखादे सोल्यूशन विकत घेणार असाल आणि त्याची खोली तपासायची असेल, किंवा संभाषणामागे काय चालू आहे हे जाणून घेण्यात तुम्हाला रस असेल तर हे वाचण्यासारखे आहे.

TL;DR: प्रत्येक टर्न 6 टप्प्यांतून जातो — ingest, संदर्भ resolve, skills निवड, पुढील कृती निर्णय, guard-rails सह execution, मेमरी persist. संपूर्ण सायकल Cloudflare च्या edge वर <2 सेकंदात चालतो, कोणताही फिक्स्ड सर्व्हर नाही.

---

आर्किटेक्चर का महत्त्वाचे आहे

संवादात्मक एजंट जो डेमोमध्ये काम करताना दिसतो पण प्रॉडक्शनमध्ये तुटतो, त्यात सहसा या 4 समस्यांपैकी एक असते:

1. उच्च लेटन्सी — ग्राहक प्रतिसादासाठी 8 सेकंद वाट पाहतो, संभाषण मरते.
2. अनियंत्रित हॅल्युसिनेशन — एजंट किंमत, वेळ, पॉलिसी स्वतःच तयार करतो.
3. हरवलेला संदर्भ — ग्राहक 2 दिवसांनी परत येतो आणि एजंट सगळे "विसरतो".
4. अनियंत्रित खर्च — प्रत्येक लांब संभाषण प्रॉम्प्ट भरतो आणि तुम्ही टोकनवर भरपूर पैसे खर्च करता.

हे 4 ही आर्किटेक्चरच्या निवडी आहेत, मॉडेलच्या मर्यादा नाहीत. OpenClaw हे 4 टाळण्यासाठी बनवले गेले — आणि हे समजून घेण्याचा मार्ग म्हणजे एका टर्नचे सायकल पाहणे.

---

एका टर्नचे सायकल (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 तीन गोष्टी करतो:

1. Webhook ची सिग्नेचर व्हॅलिडेट करतो (WABA सीक्रेट विरुद्ध HMAC).
2. रिसीव्हरच्या फोन नंबरवरून tenant ओळखतो (multi-tenant to_number द्वारे).
3. Payload नॉर्मलाइझ करतो — ऑडिओ ट्रान्सक्रिप्शन होतो, इमेज डिस्क्रिप्शन होते, लोकेशन {lat,lng} होते, टेक्स्ट जसे आहे तसे राहते.

टप्पा 1 च्या शेवटी तुमच्याकडे {tenant_id, conversation_id, user_message} हा ऑब्जेक्ट पुढच्या पायरीसाठी तयार असतो.

टप्पा 2 — संदर्भ Resolve (D1 + KV, ~80ms)

एजंटला निर्णय घेण्यापूर्वी संदर्भाचे 3 भाग लागतात:

• संभाषणाचा अलीकडील इतिहास (शेवटचे N संबंधित टर्न्स).
• ग्राहकाची दीर्घकालीन मेमरी (प्राधान्ये, खरेदी इतिहास, नोंदी).
• एजंटची स्थिती (पर्सोना, सक्षम केलेल्या स्किल्स, नियम).

हे सर्व D1 (Cloudflare चे वितरित SQLite) मधून येतात. D1 पारंपरिक Postgres/Mongo ची जागा घेतो — कोणताही डेटाबेस सर्व्हर मेंटेन करायची गरज नाही, worker मधून काही ms मध्ये ऍक्सेस, tenant_id द्वारे multi-tenant.

मुख्य मुद्दा: आम्ही संपूर्ण संभाषण प्रॉम्प्टमध्ये लोड करत नाही. OpenClaw चा Memory Manager v2 (आमच्या अंतर्गत दस्तऐवजीकरणात वर्णन केलेला) सध्याच्या टर्नसाठी फक्त संबंधित टर्न्स निवडतो (शेवटचे N + उच्च सिमँटिक प्रासंगिकतेचे N). यामुळे 100+ टर्न्सच्या संभाषणांमध्येही टोकन खर्च अंदाज करण्यायोग्य राहतो.

स्टेज 3 — स्किल्स निवड (policy engine, ~20ms)

प्रत्येक एजंटकडे उपलब्ध स्किल्स चा एक संच असतो — ज्या फंक्शन्स तो इन्व्होक करू शकतो. उदाहरणे: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"quero marcar pra sábado de manhã" हा संदेश मिळाल्यावर, policy engine फिल्टर करतो:

• ओळखलेल्या इंटेंट (शेड्युलिंग) शी सुसंगत स्किल्स.
• संभाषणाच्या या टप्प्यासाठी परवानगी असलेल्या स्किल्स (प्रत्येक स्किल नेहमी उपलब्ध नसते).
• या tenant ने सक्षम केलेल्या स्किल्स (calendar फक्त तेव्हाच दिसतो जेव्हा tenant ने इंटिग्रेट केलेले असते).

शेवटी तुमच्याकडे मॉडेलला पाठवण्यासाठी स्किल्सचा एक लहान उपसंच असतो — संभाव्य 50 नाही, फक्त 4 जे इथे अर्थपूर्ण आहेत. यामुळे मॉडेलने चुकीची स्किल इन्व्होक करण्याची शक्यता मोठ्या प्रमाणात कमी होते.

स्टेज 4 — निर्णय (LLM call, 400-1200ms)

आता मॉडेल येतो. OpenClaw एका फ्रंटियर LLM ला (Anthropic Claude, OpenAI GPT, Google Gemini — tenant नुसार कॉन्फिगर करण्यायोग्य) एकच कॉल करतो:

• System prompt = एजंटचा पर्सोना + नियम + उपलब्ध स्किल्स.
• History = स्टेज 2 मध्ये निवडलेले टर्न्स.
• User message = सध्याच्या टर्नचा संदेश.

मॉडेल दोनपैकी एक उत्तर देतो:

• अंतिम उत्तर (ग्राहकाला थेट टेक्स्ट).
• Tool call (विशिष्ट पॅरामीटर्ससह एक विशिष्ट स्किल एक्झिक्यूट करण्याची विनंती).

"quero marcar pra sábado de manhã" या उदाहरणात, मॉडेल सामान्यतः हे रिटर्न करतो:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

स्टेज 5 — गार्ड-रेल्ससह एक्झिक्यूशन (व्हेरिएबल, ~100-500ms)

स्किल मॉडेलमध्ये चालत नाही. ती आमच्या कोडमध्ये चालते, जो:

1. पॅरामीटर्स व्हॅलिडेट करते (date_range चे फॉरमॅट बरोबर आहे का? tenant च्या नियमांमध्ये बसते का?).
2. परवानगी तपासते (या एजंटला हे कॅलेंडर पाहण्याचा अधिकार आहे का?).
3. कॉल एक्झिक्यूट करते (या प्रकरणात Google Calendar API).
4. स्ट्रक्चर्ड रिझल्ट परत करते मॉडेलला.

हे का महत्त्वाचे आहे? कारण मॉडेल कधीही रिझल्ट तयार करत नाही. जर कॅलेंडरने [10h, 11h] परत केले, तर पुढच्या कॉलमध्ये नेमके तेच जाते. जर skill अयशस्वी झाली, तर मॉडेलला माहीत असते की ती अयशस्वी झाली. एजंट 9 वाजता वेळ उपलब्ध आहे असे "शोधून काढेल" याचा शून्य धोका — जेव्हा प्रत्यक्षात नाही.

संवेदनशील माहिती (किंमत, मुदत, ग्राहकाचे नाव) असलेल्या प्रकरणांसाठी, पाइपलाइन tool call सक्ती करते — मॉडेलला स्वतःच्या "ज्ञानातून" उत्तर देऊ देत नाही. हे व्यावसायिक एजंट्समधील सर्वात सामान्य हॅल्युसिनेशनचा वर्ग काढून टाकते.

स्टेज 6 — प्रतिसाद आणि पर्सिस्टन्स (~50ms)

Skill चा रिझल्ट हातात आल्यावर, मॉडेल दुसरा कॉल करते — आता ग्राहकासाठी अंतिम प्रतिसाद तयार करण्यासाठी. उदा:

"शनिवारी 10 आणि 11 वाजता उपलब्ध आहे. कोणता पसंत कराल?"

समांतरपणे, worker:

1. WhatsApp API द्वारे संदेश परत पाठवतो.
2. संपूर्ण टर्न पर्सिस्ट करतो (user + assistant + tool calls + कालावधी) D1 मध्ये.
3. जर टर्नमधून नवीन तथ्य निर्माण झाले असेल तर दीर्घकालीन मेमरी अपडेट करतो (उदा: "ग्राहकाला शनिवार पसंत आहे").
4. ऑब्झर्व्हॅबिलिटी इव्हेंट एमिट करतो (लेटन्सी मेट्रिक, टोकन खर्च, एस्कलेशन दर).

हे सर्व समांतरपणे चालते. पर्सिस्टन्स संदेश पाठवणे ब्लॉक करत नाही — ग्राहक D1 ची वाट पाहत नाही.

---

हॅल्युसिनेशनविरुद्ध संरक्षण कुठे आहे

प्रोडक्शनमध्ये हॅल्युसिनेट करणारा एजंट लवकर विश्वास गमावतो. OpenClaw कडे संरक्षणाच्या 4 रेषा आहेत:

1. सक्तीचा source-of-truth. तथ्यात्मक डेटा (किंमत, वेळ, नाव) नेहमी skill मधून येतो, कधीही एकट्या मॉडेलकडून नाही.
2. संवेदनशील डेटावर दुहेरी पडताळणी. अपॉइंटमेंट पर्सिस्ट करण्यापूर्वी ग्राहकाकडून पुष्टी केली जाते. ऍक्सेस देण्यापूर्वी पेमेंटची पुष्टी केली जाते.
3. स्पष्ट नकारात्मक नियम. प्रत्येक एजंटच्या पर्सोनामध्ये "कधीही X, Y, Z शोधून काढू नका" समाविष्ट आहे — मॉडेल पालन करते.
4. मानवाकडे फॉलबॅक. जेव्हा कोणतीही skill प्रश्नाचे उत्तर देत नाही, तेव्हा एजंट "मी टीमकडे तपासतो" म्हणतो आणि तिकीट उघडतो — अंदाज लावत नाही.

गेल्या 6 महिन्यांत आम्ही केलेल्या ऑडिट्समध्ये (प्रत्यक्ष संभाषणे मॅन्युअली पुनरावलोकन केलेली), तथ्यात्मक हॅल्युसिनेशनचा दर टर्न्सच्या 0.3% पेक्षा कमी राहिला — आणि जवळजवळ सर्व प्रकरणे config मुळे होती (tenant ने संबंधित skill सक्षम करायला विसरला), मॉडेलची चूक नव्हती.

---

प्रति संभाषण खर्च

चांगली आर्किटेक्चर बिल बघेपर्यंत अदृश्य असते. प्रत्येक टर्न 1-2 LLM कॉल्स + D1 लुकअप्स करतो हे लक्षात घेता, संपूर्ण संभाषणाचा (10-15 टर्न) सामान्य खर्च असा असतो: