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

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

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

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

---

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

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

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

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

---

ایک باری کا سائیکل (6 مراحل)

تصور کریں کہ کلائنٹ نے ابھی پیغام بھیجا ہے "ہفتے کی صبح کے لیے بک کرنا چاہتا ہوں"۔ "received" اور ایجنٹ کے جواب کے درمیان کیا ہوتا ہے؟

مرحلہ 1 — Ingest (edge worker, <50ms)

WhatsApp کا پیغام Meta کے webhook کے ذریعے براہ راست جغرافیائی طور پر قریب ترین point of presence (PoP) میں Cloudflare Worker پر پہنچتا ہے۔ برازیل میں، اس کا مطلب ہے São Paulo یا Rio، نیٹ ورک کی تاخیر < 20ms۔

Worker تین کام کرتا ہے:

1. webhook کی دستخط کی تصدیق کرتا ہے (WABA کے راز کے خلاف HMAC)۔
2. وصول کنندہ کے فون نمبر سے tenant کی شناخت کرتا ہے (multi-tenant بذریعہ to_number)۔
3. payload کو معمول بناتا ہے — آڈیو transcription بن جاتی ہے، تصویر تفصیل بن جاتی ہے، مقام {lat,lng} بن جاتا ہے، متن جیسا ہے ویسا رہتا ہے۔

مرحلہ 1 کے آخر میں آپ کے پاس اگلے قدم کے لیے تیار {tenant_id, conversation_id, user_message} آبجیکٹ ہے۔

مرحلہ 2 — سیاق و سباق حل کریں (D1 + KV, ~80ms)

فیصلہ کرنے سے پہلے ایجنٹ کو سیاق و سباق کے 3 حصوں کی ضرورت ہے:

• گفتگو کی حالیہ تاریخ (آخری N متعلقہ موڑ)۔
• کلائنٹ کی طویل مدتی یادداشت (ترجیحات، خریداری کی تاریخ، نوٹس)۔
• ایجنٹ کی حالت (شخصیت، فعال مہارتیں، قواعد)۔

یہ سب D1 (Cloudflare کا تقسیم شدہ SQLite) سے آتے ہیں۔ D1 روایتی Postgres/Mongo کی جگہ لیتا ہے — برقرار رکھنے کے لیے کوئی ڈیٹا بیس سرور نہیں، ورکر سے چند ms میں رسائی، tenant_id کے ذریعے multi-tenant۔

اہم نکتہ: ہم پرامپٹ میں پوری گفتگو لوڈ نہیں کرتے۔ 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 نے فعال کی ہیں (calendar صرف اسی صورت میں ظاہر ہوتا ہے جب tenant نے انضمام کیا ہو)۔

آخر میں آپ کے پاس ماڈل کو دی جانے والی مہارتوں کا ایک چھوٹا سب سیٹ ہوتا ہے — 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 صحیح فارمیٹ میں ہے؟ کیا یہ ٹینینٹ کے قواعد کے اندر ہے؟)۔
2. اجازت چیک کریں (کیا اس ایجنٹ کو اس کیلنڈر سے رجوع کرنے کا حق ہے؟)۔
3. کال کو انجام دیں (اس صورت میں Google Calendar API)۔
4. ساختی نتیجہ واپس کریں ماڈل کو۔

یہ کیوں اہم ہے؟ کیونکہ ماڈل کبھی نتیجہ نہیں بناتا۔ اگر کیلنڈر [10h, 11h] واپس کرتا ہے، تو یہ بالکل وہی ہے جو اگلی کال میں جاتا ہے۔ اگر سکل ناکام ہو جاتی ہے، تو ماڈل کو معلوم ہوتا ہے کہ یہ ناکام ہوئی۔ ایجنٹ کے "ایجاد" کرنے کا صفر خطرہ کہ 9h پر وقت ہے جب کہ نہیں ہے۔

حساس معلومات (قیمت، مدت، کلائنٹ کا نام) پر مشتمل معاملات کے لیے، پائپ لائن tool call کو مجبور کرتی ہے — ماڈل کو اپنے "علم" سے جواب دینے نہیں دیتی۔ یہ تجارتی ایجنٹس میں فریب کی سب سے عام قسم کو ختم کرتا ہے۔

مرحلہ 6 — جواب اور استقامت (~50ms)

سکل کے نتیجے کے ساتھ، ماڈل دوسری کال کرتا ہے — اب کلائنٹ کے لیے حتمی جواب تیار کرنے کے لیے۔ مثال:

"میرے پاس ہفتہ کو 10h اور 11h ہے۔ کون سا پسند ہے؟"

متوازی طور پر، ورکر:

1. بھیجتا ہے پیغام کو WhatsApp API کے ذریعے واپس۔
2. محفوظ کرتا ہے مکمل ٹرن (user + assistant + tool calls + duration) کو D1 میں۔
3. طویل مدتی میموری کو اپ ڈیٹ کرتا ہے اگر ٹرن نے نئی حقیقت پیدا کی (مثال: "کلائنٹ ہفتہ کو ترجیح دیتا ہے")۔
4. مشاہدے کی ایونٹ خارج کرتا ہے (تاخیر کی میٹرک، ٹوکن کی لاگت، اضافے کی شرح)۔

یہ سب متوازی طور پر چلتا ہے۔ استقامت پیغام کی ترسیل کو بلاک نہیں کرتی — کلائنٹ D1 کا انتظار نہیں کرتا۔

---

فریب کے خلاف دفاع کہاں ہے

پروڈکشن میں فریب کرنے والا ایجنٹ تیزی سے اعتماد کھو دیتا ہے۔ OpenClaw کے پاس 4 دفاعی لائنیں ہیں:

1. Source-of-truth مجبور۔ حقائق پر مبنی ڈیٹا (قیمت، وقت، نام) ہمیشہ سکل سے آتا ہے، کبھی ماڈل سے اکیلے نہیں۔
2. حساس ڈیٹا میں دوہری تصدیق۔ شیڈولنگ کو محفوظ کرنے سے پہلے کلائنٹ کے ساتھ تصدیق کی جاتی ہے۔ رسائی جاری کرنے سے پہلے ادائیگی کی تصدیق کی جاتی ہے۔
3. واضح منفی قواعد۔ ہر ایجنٹ کی شخصیت میں "کبھی X, Y, Z ایجاد نہ کریں" شامل ہے — ماڈل اطاعت کرتا ہے۔
4. انسان کے لیے Fallback۔ جب کوئی سکل سوال کا احاطہ نہیں کرتی، تو ایجنٹ کہتا ہے "مجھے ٹیم کے ساتھ چیک کرنے دیں" اور ٹکٹ کھولتا ہے — اندازہ نہیں لگاتا۔

پچھلے 6 مہینوں میں ہم نے جو آڈٹ کیے (حقیقی گفتگو کا دستی جائزہ)، حقائق پر مبنی فریب کی شرح 0.3% ٹرنز سے کم رہی — اور تقریباً تمام معاملات کنفیگ کی وجہ سے تھے (ٹینینٹ متعلقہ سکل کو فعال کرنا بھول گیا)، ماڈل کی غلطی نہیں۔

---

فی گفتگو لاگت

اچھا فن تعمیر اس وقت تک نظر نہیں آتا جب تک آپ بل نہیں دیکھتے۔ یہ دیکھتے ہوئے کہ ہر موڑ 1-2 LLM کالز + D1 میں lookups کرتا ہے، مکمل گفتگو (10-15 موڑ) کی عام لاگت یہ ہے: