कन्भर्सेसनल एआई एजेन्ट भित्र कसरी काम गर्छ

कन्भर्सेशनल AI एजेन्ट भित्र कसरी काम गर्छ (OpenClaw आर्किटेक्चर)

कन्भर्सेशनल AI एजेन्ट कसरी काम गर्छ व्यवहारमा, टर्न-बाइ-टर्न? यो पोस्टले OpenClaw को ब्ल्याक बक्स खोल्छ: ग्राहकको सन्देश WhatsApp मा आइपुग्ने क्षणदेखि एजेन्टले फिर्ता लेख्ने पाठसम्म। यो प्राविधिक हुनेछ। यदि तपाईं उत्पादन आर्किटेक्चरको निर्णय गर्नुहुन्छ भने, यदि तपाईं समाधान किन्न जाँदै हुनुहुन्छ र गहिराइमा मूल्याङ्कन गर्न चाहनुहुन्छ भने, वा कुराकानीको पछाडि के भइरहेको छ जान्न रुचि राख्नुहुन्छ भने यो उपयोगी छ।

TL;DR: प्रत्येक टर्न ६ चरणहरूबाट गुज्रिन्छ — ingest, सन्दर्भ समाधान, skills छनोट, अर्को कार्य निर्णय, guard-rails सहित कार्यान्वयन, मेमोरी संरक्षण। सम्पूर्ण चक्र Cloudflare को edge मा <२ सेकेन्डमा चल्छ, कुनै निश्चित सर्भर बिना।

---

आर्किटेक्चर किन महत्त्वपूर्ण छ

डेमोमा काम गरेको जस्तो देखिने तर उत्पादनमा बिग्रने कन्भर्सेशनल एजेन्टमा सामान्यतया यी ४ समस्याहरू मध्ये एउटा हुन्छ:

1. उच्च लेटेन्सी — ग्राहकले प्रतिक्रियाको लागि ८ सेकेन्ड पर्खन्छ, कुराकानी मर्छ।
2. अनियन्त्रित हलुसिनेशन — एजेन्टले मूल्य, समय, नीति बनाउँछ।
3. हराएको सन्दर्भ — ग्राहक २ दिनपछि फर्कन्छ र एजेन्टले सबै "बिर्सन्छ"।
4. अनियन्त्रित लागत — प्रत्येक लामो कुराकानीले प्रोम्प्ट भर्छ र तपाईंले टोकनमा ठूलो रकम तिर्नुहुन्छ।

यी ४ वटै आर्किटेक्चर छनोटहरू हुन्, मोडेलको सीमा होइन। OpenClaw यी ४ बाट बच्नको लागि निर्माण गरिएको थियो — र बुझ्ने बाटो भनेको एक टर्नको चक्र हेर्नु हो।

---

एक टर्नको चक्र (६ चरणहरू)

कल्पना गर्नुहोस् कि ग्राहकले भर्खरै सन्देश पठाएको छ "शनिबार बिहान बुक गर्न चाहन्छु"। "received" र एजेन्टको प्रतिक्रियाको बीचमा के हुन्छ?

चरण १ — 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} बन्छ, पाठ जस्ताको तस्तै रहन्छ।

चरण १ को अन्त्यमा तपाईंसँग अर्को चरणको लागि तयार {tenant_id, conversation_id, user_message} वस्तु हुन्छ।

चरण २ — सन्दर्भ समाधान (D1 + KV, ~80ms)

निर्णय गर्नु अघि एजेन्टलाई सन्दर्भका ३ टुक्राहरू चाहिन्छ:

• वार्तालापको हालको इतिहास (अन्तिम 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)

प्रत्येक एजेन्टसँग उपलब्ध सीपहरू को सेट हुन्छ — कार्यहरू जुन उसले आह्वान गर्न सक्छ। उदाहरणहरू: 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 मात्र। यसले मोडेलले गलत सीप आह्वान गर्ने सम्भावनालाई धेरै कम गर्छ।

चरण 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 — guard-rails सहित कार्यान्वयन (परिवर्तनशील, ~100-500ms)

सीप मोडेलमा चल्दैन। यो हाम्रो कोडमा चल्छ, जसले:

1. प्यारामिटरहरू मान्य गर्दछ (date_range सही ढाँचामा छ? tenant का नियमहरू भित्र छ?)।
2. अनुमति जाँच गर्दछ (यो एजेन्टलाई यो क्यालेन्डर हेर्ने अधिकार छ?)।
3. कल कार्यान्वयन गर्दछ (यस अवस्थामा Google Calendar API)।
4. संरचित परिणाम फर्काउँछ मोडेललाई।

यो किन महत्त्वपूर्ण छ? किनभने मोडेलले कहिल्यै परिणाम बनाउँदैन। यदि क्यालेन्डरले [10h, 11h] फर्कायो भने, अर्को कलमा ठ्याक्कै त्यही जान्छ। यदि skill असफल भयो भने, मोडेललाई थाहा हुन्छ कि असफल भयो। एजेन्टले 9h मा समय छ भनेर "आविष्कार" गर्ने शून्य जोखिम जब छैन।

संवेदनशील जानकारी (मूल्य, समयसीमा, ग्राहकको नाम) समावेश गर्ने केसहरूका लागि, pipeline ले tool call लाई बाध्य पार्छ — मोडेललाई आफ्नै "ज्ञान" बाट जवाफ दिन दिँदैन। यसले व्यावसायिक एजेन्टहरूमा सबैभन्दा सामान्य भ्रमको वर्ग हटाउँछ।

चरण 6 — प्रतिक्रिया र स्थायित्व (~50ms)

skill को परिणाम हातमा लिएर, मोडेलले दोस्रो कल गर्छ — अब ग्राहकको लागि अन्तिम प्रतिक्रिया बनाउन। उदाहरण:

"मसँग शनिबार 10h र 11h छ। कुन रुचाउनुहुन्छ?"

समानान्तर रूपमा, worker:

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

यो सबै समानान्तर रूपमा चल्छ। स्थायित्वले सन्देश पठाउनलाई रोक्दैन — ग्राहकले D1 को पर्खाइ गर्दैन।

---

भ्रम विरुद्ध सुरक्षा कहाँ छ

उत्पादनमा भ्रम गर्ने एजेन्टले छिटो विश्वास गुमाउँछ। OpenClaw सँग 4 सुरक्षा रेखाहरू छन्:

1. बाध्यकारी सत्य-स्रोत। तथ्यात्मक डेटा (मूल्य, समय, नाम) सधैं skill बाट आउँछ, कहिल्यै मोडेल एक्लैबाट होइन।
2. संवेदनशील डेटामा दोहोरो प्रमाणीकरण। स्थायी बनाउनु अघि ग्राहकसँग समय तालिका पुष्टि गरिन्छ। पहुँच दिनु अघि भुक्तानी पुष्टि गरिन्छ।
3. स्पष्ट नकारात्मक नियमहरू। प्रत्येक एजेन्टको व्यक्तित्वमा "कहिल्यै X, Y, Z आविष्कार नगर्नुहोस्" समावेश छ — मोडेलले पालना गर्छ।
4. मानवमा Fallback। जब कुनै पनि skill ले प्रश्न कभर गर्दैन, एजेन्टले "मलाई टोलीसँग जाँच गर्न दिनुहोस्" भन्छ र टिकट खोल्छ — अनुमान गर्दैन।

हामीले पछिल्लो 6 महिनामा गरेका लेखापरीक्षणहरूमा (वास्तविक कुराकानीहरू म्यानुअल रूपमा समीक्षा गरिएको), तथ्यात्मक भ्रम दर 0.3% टर्नहरू भन्दा कम रह्यो — र लगभग सबै केसहरू config द्वारा थिए (tenant ले सान्दर्भिक skill सक्षम गर्न बिर्सियो), मोडेल त्रुटि होइन।

---

प्रति कुराकानी लागत

राम्रो आर्किटेक्चर अदृश्य हुन्छ जबसम्म तपाईंले बिल हेर्नुहुन्न। प्रत्येक टर्नले 1-2 LLM कलहरू + D1 मा लुकअपहरू गर्ने भएकोले, पूर्ण वार्तालाप (10-15 टर्नहरू) को सामान्य लागत यस्तो हुन्छ: