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

संवादात्मक AI एजंटची आतील कार्यपद्धती (OpenClaw आर्किटेक्चर)

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

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

---

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

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

1. उच्च विलंब — क्लायंट प्रतिसादासाठी 8 सेकंद वाट पाहतो, संवाद संपतो.
2. अनियंत्रित भ्रम — एजंट किंमत, वेळ, धोरण बनवतो.
3. संदर्भ हरवला — क्लायंट 2 दिवसांनंतर परत येतो आणि एजंट सर्व काही "विसरतो".
4. अनियंत्रित खर्च — प्रत्येक लांब संवाद prompt भरतो आणि तुम्ही token साठी मोठी रक्कम भरता.

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

---

एका वळणाचे चक्र (6 टप्पे)

कल्पना करा की क्लायंटने नुकताच "quero marcar pra sábado de manhã" हा संदेश पाठवला. "received" आणि एजंटच्या प्रतिसादादरम्यान काय घडते?

टप्पा 1 — Ingest (edge worker, <50ms)

WhatsApp वरून संदेश Meta च्या webhook द्वारे थेट भौगोलिकदृष्ट्या सर्वात जवळच्या Cloudflare Worker च्या उपस्थिती बिंदूवर (PoP) येतो. ब्राझीलमध्ये, याचा अर्थ साओ पाउलो किंवा रिओ, नेटवर्क विलंब < 20ms.

Worker तीन गोष्टी करतो:

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

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

टप्पा 2 — संदर्भ निश्चित करणे (D1 + KV, ~80ms)

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

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

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

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

टप्पा 3 — कौशल्य निवड (policy engine, ~20ms)

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

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

• शोधलेल्या हेतूशी सुसंगत कौशल्ये (शेड्युलिंग).
• संवादाच्या या टप्प्यासाठी परवानगी असलेली कौशल्ये (प्रत्येक कौशल्य नेहमी उपलब्ध नसते).
• या tenant ने सक्षम केलेली कौशल्ये (tenant ने एकत्रित केले तरच calendar दिसते).

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

टप्पा 4 — निर्णय (LLM call, 400-1200ms)

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

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

मॉडेल दोनपैकी एक गोष्ट प्रतिसाद देते:

• अंतिम प्रतिसाद (क्लायंटसाठी थेट मजकूर).
• Tool call (विशिष्ट पॅरामीटर्ससह विशिष्ट कौशल्य execute करण्याची विनंती).

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

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

टप्पा 5 — guard-rails सह execution (परिवर्तनशील, ~100-500ms)

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

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

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

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

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

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

"माझ्याकडे शनिवारी 10 आणि 11 वाजता आहे. कोणते पसंत करता?"

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

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

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

---

भ्रमाविरुद्ध संरक्षण कुठे आहे

उत्पादनात भ्रमित होणारा एजंट लवकर विश्वास गमावतो. OpenClaw कडे 4 संरक्षण रेषा आहेत:

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

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

---

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

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