உரையாடல் 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-க்கு பெரும் தொகை செலுத்துகிறீர்கள்.

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

---

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

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

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

WhatsApp செய்தி Meta-வின் webhook வழியாக புவியியல் ரீதியாக மிக அருகிலுள்ள இருப்பிடப் புள்ளியில் (PoP) உள்ள Cloudflare Worker-க்கு நேரடியாக வருகிறது. பிரேசிலில், இது சாவோ பாலோ அல்லது ரியோ என்பதைக் குறிக்கிறது, நெட்வொர்க் தாமதம் < 20ms.

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

1. Webhook-ன் கையொப்பத்தை சரிபார்க்கிறது (WABA ரகசியத்திற்கு எதிராக HMAC).
2. பெறுநரின் தொலைபேசி எண் மூலம் tenant-ஐ அடையாளம் காண்கிறது (to_number மூலம் multi-tenant).
3. Payload-ஐ இயல்பாக்குகிறது — ஆடியோ படியெடுப்பாக மாறுகிறது, படம் விளக்கமாக மாறுகிறது, இருப்பிடம் {lat,lng} ஆக மாறுகிறது, உரை அப்படியே இருக்கிறது.

நிலை 1-ன் முடிவில் அடுத்த படிக்குத் தயாரான {tenant_id, conversation_id, user_message} என்ற பொருள் உங்களிடம் உள்ளது.

நிலை 2 — சூழலைத் தீர்த்தல் (D1 + KV, ~80ms)

முடிவு செய்வதற்கு முன் ஏஜெண்டுக்கு 3 சூழல் பகுதிகள் தேவை:

• சமீபத்திய வரலாறு உரையாடலின் (கடைசி N தொடர்புடைய திருப்பங்கள்).
• நீண்டகால நினைவகம் வாடிக்கையாளரின் (விருப்பத்தேர்வுகள், கொள்முதல் வரலாறு, குறிப்புகள்).
• ஏஜெண்ட் நிலை (பெர்சோனா, இயக்கப்பட்ட skills, விதிகள்).

அனைத்தும் D1 (Cloudflare-ன் விநியோகிக்கப்பட்ட SQLite) இலிருந்து வருகின்றன. D1 பாரம்பரிய Postgres/Mongo-வை மாற்றுகிறது — பராமரிக்க தரவுத்தள சேவையகம் இல்லை, worker-இலிருந்து சில ms-ல் அணுகல், tenant_id மூலம் multi-tenant.

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

நிலை 3 — Skills தேர்வு (policy engine, ~20ms)

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

"சனிக்கிழமை காலையில் முன்பதிவு செய்ய விரும்புகிறேன்" என்ற செய்தி கொடுக்கப்பட்டால், policy engine வடிகட்டுகிறது:

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

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

நிலை 4 — முடிவு (LLM call, 400-1200ms)

இப்போது மாடல் நுழைகிறது. OpenClaw ஒரு எல்லை LLM-க்கு (Anthropic Claude, OpenAI GPT, Google Gemini — tenant-ஆல் கட்டமைக்கக்கூடியது) ஒரே அழைப்பை செய்கிறது:

• System prompt = ஏஜெண்டின் பெர்சோனா + விதிகள் + கிடைக்கும் skills.
• History = நிலை 2-ல் தேர்ந்தெடுக்கப்பட்ட திருப்பங்கள்.
• User message = தற்போதைய திருப்பத்தின் செய்தி.

மாடல் இரண்டில் ஒன்றை பதிலளிக்கிறது:

• இறுதி பதில் (வாடிக்கையாளருக்கு நேரடி உரை).
• Tool call (குறிப்பிட்ட skill-ஐ அளவுருக்களுடன் இயக்கக் கோரிக்கை).

"சனிக்கிழமை காலையில் முன்பதிவு செய்ய விரும்புகிறேன்" என்ற எடுத்துக்காட்டில், மாடல் பொதுவாக இதைத் திருப்பி அனுப்புகிறது:

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

நிலை 5 — பாதுகாப்பு வரம்புகளுடன் செயல்படுத்தல் (மாறுபடும், ~100-500ms)

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

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. முழு சுற்றை (user + assistant + tool calls + கால அளவு) D1-ல் நிலைநிறுத்துகிறது.
3. சுற்று புதிய உண்மையை உருவாக்கினால் நீண்ட கால நினைவகத்தை புதுப்பிக்கிறது (எ.கா: "வாடிக்கையாளர் சனிக்கிழமையை விரும்புகிறார்").
4. கவனிப்புத்திறன் நிகழ்வை வெளியிடுகிறது (தாமத அளவீடு, டோக்கன் செலவு, அதிகரிப்பு விகிதம்).

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

---

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

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

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

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

---

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

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