ஒரு AI சம்வாதா ஏஜென்ட் உள்ளே எப்படி வேலை செய்கிறது

Engenharia

12 min வாசிப்பு நேரம்

1 ஜூன், 2026

ஒரு 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, சூழலைத் தீர்மானித்தல், திறன்களைத் தேர்ந்தெடுத்தல், அடுத்த செயலை முடிவு செய்தல், guard-rails உடன் செயல்படுத்துதல், நினைவகத்தைத் தக்கவைத்தல். முழு சுழற்சியும் Cloudflare இன் edge இல் <2 விநாடிகளில் இயங்குகிறது, நிலையான சர்வர் இல்லாமல்.

கட்டமைப்பு ஏன் முக்கியம்

demo இல் வேலை செய்வது போல் தோன்றும் ஆனால் production இல் உடைந்துவிடும் உரையாடல் முகவர் பொதுவாக இந்த 4 பிரச்சனைகளில் ஒன்றைக் கொண்டிருக்கும்:

அதிக தாமதம் — வாடிக்கையாளர் பதிலுக்கு 8 விநாடிகள் காத்திருக்கிறார், உரையாடல் இறந்துவிடுகிறது.
கட்டுப்படுத்தப்படாத மாயத்தோற்றம் — முகவர் விலை, நேரம், கொள்கையை கற்பனை செய்கிறது.
இழந்த சூழல் — வாடிக்கையாளர் 2 நாட்களுக்குப் பிறகு திரும்பி வருகிறார் மற்றும் முகவர் அனைத்தையும் "மறந்துவிடுகிறது".
கட்டுப்பாடற்ற செலவு — ஒவ்வொரு நீண்ட உரையாடலும் prompt ஐ நிரப்புகிறது மற்றும் நீங்கள் token க்கு அதிக தொகை செலுத்துகிறீர்கள்.

இந்த 4 உம் கட்டமைப்பு தேர்வுகள், மாதிரியின் வரம்புகள் அல்ல. OpenClaw இந்த 4 ஐயும் தவிர்க்க கட்டமைக்கப்பட்டது — மற்றும் புரிந்துகொள்வதற்கான வழி ஒரு திருப்பத்தின் சுழற்சியைப் பார்ப்பதுதான்.

ஒரு திருப்பத்தின் சுழற்சி (6 நிலைகள்)

வாடிக்கையாளர் "quero marcar pra sábado de manhã" என்ற செய்தியை அனுப்பியதாக கற்பனை செய்யுங்கள். "received" மற்றும் முகவரின் பதிலுக்கு இடையில் என்ன நடக்கிறது?

நிலை 1 — Ingest (edge worker, <50ms)

WhatsApp செய்தி Meta இன் webhook வழியாக நேரடியாக புவியியல் ரீதியாக மிக அருகில் உள்ள Cloudflare Worker PoP (Point of Presence) இல் வருகிறது. பிரேசிலில், இது São Paulo அல்லது Rio ஐக் குறிக்கிறது, நெட்வொர்க் தாமதம் < 20ms.

worker மூன்று விஷயங்களைச் செய்கிறது:

webhook இன் கையொப்பத்தை சரிபார்க்கிறது (WABA இன் ரகசியத்திற்கு எதிராக HMAC).
பெறுநரின் தொலைபேசி எண்ணால் tenant ஐ அடையாளம் காண்கிறது (to_number மூலம் multi-tenant).
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 மூலம் பல-குத்தகைதாரர்.

முக்கிய புள்ளி: நாங்கள் prompt இல் முழு உரையாடலையும் ஏற்றுவதில்லை. OpenClaw இன் Memory Manager v2 (எங்கள் உள் ஆவணத்தில் விவரிக்கப்பட்டுள்ளது) தற்போதைய திருப்பத்திற்கு தொடர்புடைய திருப்பங்களை மட்டுமே தேர்ந்தெடுக்கிறது (கடைசி N + அதிக சொற்பொருள் தொடர்புடைய N). இது 100+ திருப்பங்கள் கொண்ட உரையாடல்களில் கூட டோக்கன் செலவை கணிக்கக்கூடியதாக வைத்திருக்கிறது.

நிலை 3 — திறன்களைத் தேர்ந்தெடுத்தல் (கொள்கை இயந்திரம், ~20ms)

ஒவ்வொரு முகவருக்கும் கிடைக்கக்கூடிய திறன்கள் தொகுப்பு உள்ளது — அவர் செயல்படுத்தக்கூடிய செயல்பாடுகள். எடுத்துக்காட்டுகள்: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

"quero marcar pra sábado de manhã" என்ற செய்தியைக் கொடுத்தால், கொள்கை இயந்திரம் வடிகட்டுகிறது:

கண்டறியப்பட்ட நோக்கத்துடன் பொருந்தக்கூடிய திறன்கள் (அட்டவணைப்படுத்தல்).
உரையாடலின் இந்த கட்டத்திற்கு அனுமதிக்கப்பட்ட திறன்கள் (எல்லா திறன்களும் எல்லா நேரத்திலும் கிடைப்பதில்லை).
இந்த குத்தகைதாரர் இயக்கிய திறன்கள் (குத்தகைதாரர் ஒருங்கிணைத்தால் மட்டுமே calendar தோன்றும்).

இறுதியில் மாதிரிக்கு அனுப்பப்படும் சிறிய துணைக்குழு திறன்களைப் பெறுவீர்கள் — சாத்தியமான 50 அல்ல, இங்கே அர்த்தமுள்ள 4 மட்டுமே. இது மாதிரி தவறான திறனை செயல்படுத்தும் வாய்ப்பை வெகுவாகக் குறைக்கிறது.

நிலை 4 — முடிவு (LLM அழைப்பு, 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 — பாதுகாப்பு-தண்டவாளங்களுடன் செயல்படுத்தல் (மாறுபடும், ~100-500ms)

திறன் மாதிரியில் இயங்காது. இது எங்கள் குறியீட்டில் இயங்குகிறது, அது:

அளவுருக்களை சரிபார்க்கிறது (date_range சரியான வடிவத்தில் உள்ளதா? tenant விதிகளுக்குள் உள்ளதா?).
அனுமதியை சரிபார்க்கிறது (இந்த agent இந்த காலெண்டரை கேள்வி கேட்க உரிமை உள்ளதா?).
அழைப்பை செயல்படுத்துகிறது (இந்த வழக்கில் Google Calendar API).
கட்டமைக்கப்பட்ட முடிவை மாதிரிக்கு திருப்பி அனுப்புகிறது.

இது ஏன் முக்கியம்? ஏனெனில் மாதிரி ஒருபோதும் முடிவை உருவாக்குவதில்லை. காலெண்டர் [10h, 11h] என்று திருப்பினால், அடுத்த அழைப்புக்கு சரியாக அதுதான் செல்கிறது. skill தோல்வியுற்றால், மாதிரிக்கு அது தோல்வியுற்றது என்று தெரியும். 9 மணிக்கு நேரம் இல்லாதபோது agent "கண்டுபிடித்து" சொல்லும் அபாயம் பூஜ்யம்.

முக்கியமான தகவல் (விலை, காலக்கெடு, வாடிக்கையாளர் பெயர்) சம்பந்தப்பட்ட வழக்குகளுக்கு, pipeline tool call ஐ கட்டாயப்படுத்துகிறது — மாதிரி தனது சொந்த "அறிவிலிருந்து" பதிலளிக்க அனுமதிப்பதில்லை. இது வணிக agents இல் மிகவும் பொதுவான மாயத்தோற்ற வகையை நீக்குகிறது.

நிலை 6 — பதில் மற்றும் நிலைத்தன்மை (~50ms)

skill இன் முடிவு கையில் இருக்கும்போது, மாதிரி இரண்டாவது அழைப்பை செய்கிறது — இப்போது வாடிக்கையாளருக்கான இறுதி பதிலை உருவாக்க. எ.கா:

"எனக்கு சனிக்கிழமை 10 மணி மற்றும் 11 மணி உள்ளது. எதை விரும்புகிறீர்கள்?"

அதே நேரத்தில், worker:

WhatsApp API மூலம் செய்தியை மீண்டும் அனுப்புகிறது.
D1 இல் முழு சுற்றையும் (user + assistant + tool calls + duration) நிலைநிறுத்துகிறது.
சுற்று புதிய உண்மையை உருவாக்கினால் (எ.கா: "வாடிக்கையாளர் சனிக்கிழமையை விரும்புகிறார்") நீண்ட கால நினைவகத்தை புதுப்பிக்கிறது.
கண்காணிப்பு நிகழ்வை வெளியிடுகிறது (தாமத அளவீடு, token செலவு, escalation விகிதம்).

இவை அனைத்தும் இணையாக இயங்குகின்றன. நிலைத்தன்மை செய்தி அனுப்புதலை தடுப்பதில்லை — வாடிக்கையாளர் D1 க்காக காத்திருப்பதில்லை.

மாயத்தோற்றத்திற்கு எதிரான பாதுகாப்பு எங்கே உள்ளது

உற்பத்தியில் மாயத்தோற்றம் கொண்ட Agent விரைவில் நம்பிக்கையை இழக்கிறது. OpenClaw க்கு 4 பாதுகாப்பு வரிசைகள் உள்ளன:

கட்டாயப்படுத்தப்பட்ட உண்மை-ஆதாரம். உண்மை தரவு (விலை, நேரம், பெயர்) எப்போதும் skill இலிருந்து வருகிறது, மாதிரி தனியாக இருந்து வருவதில்லை.
முக்கியமான தரவில் இரட்டை சரிபார்ப்பு. நிலைநிறுத்துவதற்கு முன் வாடிக்கையாளருடன் அட்டவணை உறுதிப்படுத்தப்படுகிறது. அணுகலை வெளியிடுவதற்கு முன் கட்டணம் உறுதிப்படுத்தப்படுகிறது.
வெளிப்படையான எதிர்மறை விதிகள். ஒவ்வொரு agent இன் persona "X, Y, Z ஐ ஒருபோதும் கண்டுபிடிக்காதே" என்பதை உள்ளடக்கியது — மாதிரி கீழ்ப்படிகிறது.
மனிதருக்கு Fallback. எந்த skill ம் கேள்வியை உள்ளடக்காதபோது, agent "குழுவிடம் சரிபார்க்கிறேன்" என்று கூறி ticket ஐ திறக்கிறது — யூகிப்பதில்லை.

கடந்த 6 மாதங்களில் நாங்கள் செய்த தணிக்கைகளில் (உண்மையான உரையாடல்கள் கைமுறையாக மதிப்பாய்வு செய்யப்பட்டன), உண்மை மாயத்தோற்ற விகிதம் 0.3% சுற்றுகளுக்கும் கீழ் இருந்தது — மற்றும் கிட்டத்தட்ட அனைத்து வழக்குகளும் config காரணமாக இருந்தன (tenant தொடர்புடைய skill ஐ இயக்க மறந்துவிட்டார்), மாதிரி பிழை அல்ல.

ஒரு உரையாடலுக்கான செலவு

நல்ல கட்டமைப்பு என்பது நீங்கள் பில்லைப் பார்க்கும் வரை கண்ணுக்குத் தெரியாதது. ஒவ்வொரு முறையும் 1-2 LLM அழைப்புகள் + D1 இல் தேடல்கள் செய்யப்படுவதால், முழுமையான உரையாடலுக்கான (10-15 முறைகள்) வழக்கமான செலவு:

Equipe OpenClaw

வெளியிடப்பட்ட தேதி 1 ஜூன், 2026