ایک AI گفتگو ایجنٹ اندرونی طور پر کیسے کام کرتا ہے

ایک AI بات چیت ایجنٹ اندر سے کیسے کام کرتا ہے (OpenClaw آرکیٹیکچر)

ایک AI بات چیت ایجنٹ کیسے کام کرتا ہے عملی طور پر، ٹرن بہ ٹرن؟ یہ پوسٹ OpenClaw کا بلیک باکس کھولتی ہے: جس لمحے سے کسٹمر کا پیغام WhatsApp پر آتا ہے اس وقت تک جب ایجنٹ جواب لکھتا ہے۔ یہ تکنیکی ہوگا۔ یہ اس صورت میں فائدہ مند ہے اگر آپ پروڈکٹ آرکیٹیکچر کے فیصلے کرتے ہیں، اگر آپ کوئی حل خریدنا چاہتے ہیں اور اس کی گہرائی کا جائزہ لینا چاہتے ہیں، یا اگر آپ یہ جاننا پسند کرتے ہیں کہ بات چیت کے پیچھے کیا ہو رہا ہے۔

TL;DR: ہر ٹرن 6 مراحل سے گزرتا ہے — ingest، سیاق و سباق حل کرنا، skills کا انتخاب، اگلے عمل کا فیصلہ، guard-rails کے ساتھ عمل درآمد، میموری کو محفوظ کرنا۔ پورا سائیکل Cloudflare کی edge پر <2 سیکنڈ میں چلتا ہے، بغیر کسی مقررہ سرور کے۔

---

آرکیٹیکچر کیوں اہم ہے

بات چیت کا ایجنٹ جو ڈیمو میں کام کرتا دکھائی دیتا ہے لیکن پروڈکشن میں ٹوٹ جاتا ہے، عام طور پر اس میں ان 4 مسائل میں سے ایک ہوتا ہے:

1. زیادہ تاخیر — کسٹمر جواب کے لیے 8 سیکنڈ انتظار کرتا ہے، بات چیت ختم ہو جاتی ہے۔
2. بے قابو ہیلوسینیشن — ایجنٹ قیمت، وقت، پالیسی گھڑ لیتا ہے۔
3. سیاق و سباق کا ضائع ہونا — کسٹمر 2 دن بعد واپس آتا ہے اور ایجنٹ سب کچھ "بھول" جاتا ہے۔
4. بے قابو لاگت — ہر لمبی بات چیت پرامپٹ بھر دیتی ہے اور آپ ٹوکنز پر بھاری رقم ادا کرتے ہیں۔

یہ چاروں آرکیٹیکچر کے انتخاب ہیں، ماڈل کی حدود نہیں۔ OpenClaw ان چاروں سے بچنے کے لیے بنایا گیا تھا — اور سمجھنے کا راستہ ایک ٹرن کے سائیکل کو دیکھنا ہے۔

---

ایک ٹرن کا سائیکل (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)۔
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۔

پیغام "quero marcar pra sábado de manhã" ملنے پر، policy engine فلٹر کرتا ہے:

• وہ Skills جو شناخت شدہ ارادے (شیڈولنگ) سے مطابقت رکھتی ہیں۔
• وہ Skills جو بات چیت کے اس مرحلے میں اجازت یافتہ ہیں (ہر skill ہر وقت دستیاب نہیں ہوتی)۔
• وہ Skills جو اس tenant نے فعال کی ہیں (calendar صرف اسی صورت ظاہر ہوتا ہے جب tenant نے انٹیگریٹ کیا ہو)۔

آخر میں آپ کے پاس 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 کو چلانے کی درخواست)۔

مثال "quero marcar pra sábado de manhã" میں، ماڈل عام طور پر یہ واپس کرتا ہے:

{
  "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 بجے وقت دستیاب ہے جبکہ نہیں ہے۔

ایسے معاملات میں جن میں حساس معلومات شامل ہوں (قیمت، مدت، کلائنٹ کا نام)، پائپ لائن 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 ٹرنز) کی عام لاگت یہ ہوتی ہے: