કન્વર્સેશનલ 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 સાથે execute કરો, મેમરી persist કરો. સમગ્ર ચક્ર Cloudflare ના edge પર <2 સેકન્ડમાં ચાલે છે, કોઈ નિશ્ચિત સર્વર વિના.
આર્કિટેક્ચર શા માટે મહત્વપૂર્ણ છે
સંવાદાત્મક એજન્ટ જે ડેમોમાં કામ કરતું લાગે છે પરંતુ પ્રોડક્શનમાં તૂટી જાય છે તેમાં સામાન્ય રીતે આ 4 સમસ્યાઓમાંથી એક હોય છે:
- ઊંચી લેટન્સી — ક્લાયન્ટ જવાબ માટે 8 સેકન્ડ રાહ જુએ છે, વાતચીત મરી જાય છે.
- અનિયંત્રિત હેલ્યુસિનેશન — એજન્ટ કિંમત, સમય, નીતિ બનાવે છે.
- ગુમાવેલો સંદર્ભ — ક્લાયન્ટ 2 દિવસ પછી પાછો આવે છે અને એજન્ટ બધું "ભૂલી" જાય છે.
- અનિયંત્રિત ખર્ચ — દરેક લાંબી વાતચીત prompt ભરી દે છે અને તમે ટોકન માટે મોટી રકમ ચૂકવો છો.
આ ચારેય આર્કિટેક્ચરની પસંદગીઓ છે, મોડેલની મર્યાદાઓ નથી. 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 ના secret સામે HMAC).
- રીસીવરના ટેલિફોન નંબર દ્વારા tenant ઓળખે છે (multi-tenant
to_numberદ્વારા). - payload ને સામાન્ય બનાવે છે — ઑડિયો ટ્રાન્સક્રિપ્શન બને છે, છબી વર્ણન બને છે, સ્થાન
{lat,lng}બને છે, ટેક્સ્ટ જેમ છે તેમ રહે છે.
તબક્કો 1 ના અંતે તમારી પાસે આગળના પગલા માટે તૈયાર {tenant_id, conversation_id, user_message} ઑબ્જેક્ટ છે.
તબક્કો 2 — સંદર્ભ Resolve કરો (D1 + KV, ~80ms)
નિર્ણય લેતા પહેલા એજન્ટને સંદર્ભના 3 ભાગોની જરૂર છે:
- વાર્તાલાપનો તાજેતરનો ઇતિહાસ (છેલ્લા N સંબંધિત વળાંકો).
- ક્લાયન્ટની લાંબા ગાળાની મેમરી (પસંદગીઓ, ખરીદીનો ઇતિહાસ, નોંધો).
- એજન્ટની સ્થિતિ (વ્યક્તિત્વ, સક્ષમ કૌશલ્યો, નિયમો).
બધા D1 (Cloudflare નું વિતરિત SQLite) માંથી આવે છે. D1 પરંપરાગત Postgres/Mongo ને બદલે છે — જાળવવા માટે કોઈ ડેટાબેસ સર્વર નથી, વર્કરમાંથી થોડા ms માં એક્સેસ, tenant_id દ્વારા મલ્ટિ-ટેનન્ટ.
મુખ્ય મુદ્દો: આપણે પ્રોમ્પ્ટમાં સંપૂર્ણ વાર્તાલાપ લોડ કરતા નથી. 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 ફિલ્ટર કરે છે:
- શોધાયેલ ઇરાદા સાથે સુસંગત કૌશલ્યો (શેડ્યુલિંગ).
- વાર્તાલાપના આ તબક્કા માટે મંજૂર કૌશલ્યો (દરેક કૌશલ્ય હંમેશા ઉપલબ્ધ નથી).
- કૌશલ્યો જે આ ટેનન્ટે સક્ષમ કર્યા છે (calendar ફક્ત ત્યારે જ દેખાય છે જો ટેનન્ટે એકીકૃત કર્યું હોય).
અંતે તમારી પાસે મોડેલને આપવામાં આવેલ કૌશલ્યોનો નાનો સબસેટ હોય છે — શક્ય 50 નહીં, ફક્ત 4 જે અહીં અર્થપૂર્ણ છે. આ મોડેલ દ્વારા ખોટા કૌશલ્યને આહ્વાન કરવાની શક્યતાને નાટકીય રીતે ઘટાડે છે.
તબક્કો 4 — નિર્ણય (LLM call, 400-1200ms)
હવે મોડેલ પ્રવેશ કરે છે. OpenClaw ફ્રન્ટિયર LLM (Anthropic Claude, OpenAI GPT, Google Gemini — ટેનન્ટ દ્વારા રૂપરેખાંકિત) ને એક જ કૉલ કરે છે:
- 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)
કૌશલ્ય મોડેલમાં ચાલતું નથી. તે અમારા કોડમાં ચાલે છે, જે:
- પેરામીટર્સ માન્ય કરે છે (date_range યોગ્ય ફોર્મેટમાં છે? તે ટેનન્ટના નિયમોમાં છે?).
- પરવાનગી તપાસે છે (આ એજન્ટને આ કેલેન્ડર જોવાનો અધિકાર છે?).
- કૉલ એક્ઝિક્યુટ કરે છે (આ કિસ્સામાં Google Calendar API).
- સ્ટ્રક્ચર્ડ પરિણામ પરત કરે છે મોડેલને.
આ શા માટે મહત્વપૂર્ણ છે? કારણ કે મોડેલ ક્યારેય પરિણામ બનાવતું નથી. જો કેલેન્ડર [10h, 11h] પરત કરે, તો તે જ બરાબર આગલા કૉલમાં જાય છે. જો સ્કિલ નિષ્ફળ જાય, તો મોડેલ જાણે છે કે તે નિષ્ફળ ગયું. એજન્ટ "શોધી કાઢે" કે 9h વાગ્યે સમય છે જ્યારે નથી તેનું શૂન્ય જોખમ.
સંવેદનશીલ માહિતી (કિંમત, સમયમર્યાદા, ગ્રાહકનું નામ) સાથે સંકળાયેલા કિસ્સાઓ માટે, પાઇપલાઇન tool call ફરજ પાડે છે — મોડેલને પોતાના "જ્ઞાન"માંથી જવાબ આપવા દેતું નથી. આ વ્યાપારી એજન્ટ્સમાં સૌથી સામાન્ય ભ્રમણાનો વર્ગ દૂર કરે છે.
સ્ટેજ 6 — પ્રતિસાદ અને સ્થિરતા (~50ms)
સ્કિલનું પરિણામ હાથમાં લઈને, મોડેલ બીજો કૉલ કરે છે — હવે ગ્રાહક માટે અંતિમ પ્રતિસાદ બનાવવા માટે. ઉદા:
"મારી પાસે શનિવારે 10h અને 11h છે. તમે કયું પસંદ કરો છો?"
સમાંતર રીતે, વર્કર:
- મોકલે છે WhatsApp API દ્વારા સંદેશ પાછો.
- સંગ્રહિત કરે છે D1માં સંપૂર્ણ ટર્ન (user + assistant + tool calls + duration).
- લાંબા ગાળાની મેમરી અપડેટ કરે છે જો ટર્ને નવી હકીકત ઉત્પન્ન કરી હોય (ઉદા: "ગ્રાહક શનિવાર પસંદ કરે છે").
- અવલોકનક્ષમતા ઇવેન્ટ ઉત્સર્જિત કરે છે (લેટન્સી મેટ્રિક, ટોકન ખર્ચ, એસ્કેલેશન દર).
આ બધું સમાંતર ચાલે છે. સ્થિરતા સંદેશ મોકલવાને અવરોધિત કરતી નથી — ગ્રાહક D1ની રાહ જોતો નથી.
ભ્રમણા સામે સંરક્ષણ કયાં છે
પ્રોડક્શનમાં ભ્રમણા કરતો એજન્ટ ઝડપથી વિશ્વાસ ગુમાવે છે. OpenClaw પાસે 4 સંરક્ષણ રેખાઓ છે:
- ફરજિયાત સત્યનો સ્રોત. તથ્યાત્મક ડેટા (કિંમત, સમય, નામ) હંમેશા સ્કિલમાંથી આવે છે, ક્યારેય એકલા મોડેલમાંથી નહીં.
- સંવેદનશીલ ડેટામાં બેવડી ચકાસણી. શેડ્યુલિંગ સંગ્રહિત કરતાં પહેલાં ગ્રાહક સાથે પુષ્ટિ કરવામાં આવે છે. એક્સેસ મુક્ત કરતાં પહેલાં ચુકવણીની પુષ્ટિ કરવામાં આવે છે.
- સ્પષ્ટ નકારાત્મક નિયમો. દરેક એજન્ટની વ્યક્તિત્વમાં "ક્યારેય X, Y, Z શોધી કાઢશો નહીં" શામેલ છે — મોડેલ પાલન કરે છે.
- માનવ માટે ફૉલબેક. જ્યારે કોઈ સ્કિલ પ્રશ્નને આવરી લેતું નથી, ત્યારે એજન્ટ કહે છે
"મને ટીમ સાથે તપાસવા દો"અને ટિકિટ ખોલે છે — અનુમાન લગાવતું નથી.
છેલ્લા 6 મહિનામાં અમે કરેલા ઓડિટ્સમાં (મેન્યુઅલી સમીક્ષા કરેલી વાસ્તવિક વાતચીતો), તથ્યાત્મક ભ્રમણાનો દર 0.3% ટર્ન્સથી નીચે રહ્યો — અને લગભગ તમામ કિસ્સાઓ કૉન્ફિગરેશનને કારણે હતા (ટેનન્ટ સંબંધિત સ્કિલ સક્ષમ કરવાનું ભૂલી ગયા), મોડેલની ભૂલને કારણે નહીં.
વાતચીત દીઠ ખર્ચ
સારી આર્કિટેક્ચર અદ્રશ્ય હોય છે જ્યાં સુધી તમે બિલ જોતા નથી. આપેલ છે કે દરેક ટર્ન 1-2 LLM કૉલ્સ + D1 માં લુકઅપ્સ કરે છે, સંપૂર્ણ વાર્તાલાપ દીઠ સામાન્ય ખર્ચ (10-15 ટર્ન્સ) આટલો રહે છે:
Equipe OpenClaw
પ્રકાશિત તારીખ 1 જૂન, 2026
