كيف يعمل وكيل الذكاء الاصطناعي المحادثاتي من الداخل

كيفاش يخدم عون الذكاء الاصطناعي التحاوري من الداخل (معمارية OpenClaw)

كيفاش يخدم عون الذكاء الاصطناعي التحاوري في الواقع، دورة بدورة؟ هذا المنشور يفتح الصندوق الأسود لـ OpenClaw: من اللحظة اللي توصل فيها رسالة العميل على WhatsApp حتى النص اللي يكتبو العون في الرد. غادي يكون تقني. يستحق إذا كنت تقرر معمارية المنتج، إذا غادي تشري حل وتبغي تقيّم العمق، أو إذا تحب تعرف شنو راه يصرا وراء المحادثة.

TL;DR: كل دورة تمر بـ 6 مراحل — الاستيعاب، حل السياق، اختيار المهارات، تقرير الإجراء التالي، التنفيذ مع الحماية، حفظ الذاكرة. كامل الدورة تخدم في <2 ثانية على حافة Cloudflare، بلا سيرفر ثابت.

---

علاش المعمارية مهمة

العون التحاوري اللي يبان خدام في الديمو ولكن يتكسر في الإنتاج عادة عندو واحد من هاد 4 المشاكل:

1. زمن انتقال عالي — العميل يستنى 8 ثواني للرد، المحادثة تموت.
2. هلوسة مش مراقبة — العون يخترع السعر، الوقت، السياسة.
3. سياق ضايع — العميل يرجع بعد يومين والعون "ينسى" كلشي.
4. تكلفة مش مراقبة — كل محادثة طويلة تعمر الـ prompt وتخلص فلوس كثيرة في الـ token.

الأربعة هوما خيارات معمارية، مش قيود النموذج. OpenClaw تبنى باش يتجنب الأربعة — والطريق باش نفهمو هو نشوفو دورة الـ turn.

---

دورة الـ turn (6 مراحل)

تخيل أن العميل توا بعث الرسالة "نبغي نحجز لنهار السبت الصباح". شنو يصرا بين "received" ورد العون؟

المرحلة 1 — الاستيعاب (edge worker, <50ms)

رسالة WhatsApp توصل عبر webhook من Meta مباشرة لـ Cloudflare Worker في نقطة الحضور (PoP) الأقرب جغرافياً. في البرازيل، هذا يعني ساو باولو أو ريو، زمن انتقال الشبكة < 20ms.

الـ worker يدير ثلاثة حوايج:

1. يتحقق من التوقيع للـ webhook (HMAC ضد سر WABA).
2. يحدد الـ tenant بواسطة رقم التليفون للمستقبل (multi-tenant بواسطة to_number).
3. يطبّع الـ payload — الصوت يولي نسخ، الصورة تولي وصف، الموقع يولي {lat,lng}، النص يبقى كيما هو.

في نهاية المرحلة 1 عندك كائن {tenant_id, conversation_id, user_message} جاهز للخطوة الجاية.

المرحلة 2 — حل السياق (D1 + KV, ~80ms)

العون يحتاج 3 قطع من السياق قبل ما يقرر:

• السجل الحديث للمحادثة (آخر N دورات ذات صلة).
• الذاكرة طويلة المدى للعميل (التفضيلات، سجل الشراء، الملاحظات).
• حالة الوكيل (الشخصية، المهارات المفعلة، القواعد).

كلها تأتي من D1 (SQLite الموزع من Cloudflare). D1 يحل محل Postgres/Mongo التقليدي — بدون خادم قاعدة بيانات للصيانة، وصول في بضعة ميلي ثانية من الـ worker، متعدد المستأجرين عبر tenant_id.

النقطة الأساسية: نحن لا نحمل المحادثة بأكملها في الـ prompt. مدير الذاكرة v2 من OpenClaw (الموصوف في وثائقنا الداخلية) يختار فقط الدورات ذات الصلة بالدورة الحالية (آخر N + N ذات صلة دلالية عالية). هذا يحافظ على تكلفة الـ token متوقعة حتى في المحادثات التي تزيد عن 100+ دورة.

المرحلة 3 — اختيار المهارات (محرك السياسات، ~20ms)

كل وكيل لديه مجموعة من المهارات المتاحة — وظائف يمكنه استدعاؤها. أمثلة: consultar_calendario، criar_evento، gerar_link_pagamento، consultar_pedido، chamar_humano.

بالنظر إلى الرسالة "أريد الحجز ليوم السبت صباحاً"، محرك السياسات يقوم بالتصفية:

• المهارات المتوافقة مع النية المكتشفة (الجدولة).
• المهارات المسموح بها لهذه المرحلة من المحادثة (ليست كل مهارة متاحة طوال الوقت).
• المهارات التي فعّلها هذا المستأجر (التقويم يظهر فقط إذا قام المستأجر بالتكامل).

في النهاية لديك مجموعة فرعية صغيرة من المهارات تُمرر للنموذج — ليس الـ 50 المحتملة، فقط الـ 4 التي تكون منطقية هنا. هذا يقلل بشكل كبير من احتمالية استدعاء النموذج لمهارة خاطئة.

المرحلة 4 — القرار (استدعاء LLM، 400-1200ms)

الآن يدخل النموذج. OpenClaw يقوم باستدعاء واحد لنموذج لغوي متقدم (Anthropic Claude، OpenAI GPT، Google Gemini — قابل للتكوين حسب المستأجر) مع:

• System prompt = شخصية الوكيل + القواعد + المهارات المتاحة.
• History = الدورات المختارة في المرحلة 2.
• User message = رسالة الدورة الحالية.

النموذج يستجيب بـ واحد من شيئين:

• استجابة نهائية (نص مباشر للعميل).
• Tool call (طلب لتنفيذ مهارة محددة مع معاملات).

في المثال "أريد الحجز ليوم السبت صباحاً"، النموذج عادةً يُرجع:

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

المرحلة 5 — التنفيذ مع الحواجز الوقائية (متغير، ~100-500ms)

المهارة لا تعمل في النموذج. إنها تعمل في كودنا الخاص، الذي:

1. التحقق من المعاملات (هل date_range بالتنسيق الصحيح؟ هل يتوافق مع قواعد المستأجر؟).
2. التحقق من الصلاحية (هل لهذا الوكيل الحق في الاستعلام عن هذا التقويم؟).
3. تنفيذ الاستدعاء (Google Calendar API في هذه الحالة).
4. إرجاع نتيجة منظمة للنموذج.

لماذا هذا مهم؟ لأن النموذج لا يختلق النتيجة أبدًا. إذا أرجع التقويم [10h, 11h]، فهذا بالضبط ما سينتقل إلى الاستدعاء التالي. إذا فشلت المهارة، يعلم النموذج أنها فشلت. خطر صفري من أن يخترع الوكيل أن هناك موعدًا في الساعة 9 صباحًا عندما لا يكون موجودًا.

بالنسبة للحالات التي تتضمن معلومات حساسة (السعر، الموعد النهائي، اسم العميل)، يفرض خط الأنابيب tool call — لا يسمح للنموذج بالإجابة من "معرفته" الخاصة. هذا يزيل فئة الهلوسة الأكثر شيوعًا في الوكلاء التجاريين.

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

مع نتيجة المهارة في متناول اليد، يقوم النموذج بالاستدعاء الثاني — الآن لتشكيل الاستجابة النهائية للعميل. مثال:

"لدي السبت في الساعة 10 و11. أيهما تفضل؟"

بالتوازي، يقوم العامل بـ:

1. إرسال الرسالة مرة أخرى عبر API الخاص بـ WhatsApp.
2. حفظ الدورة الكاملة (user + assistant + tool calls + المدة) في D1.
3. تحديث الذاكرة طويلة المدى إذا أنتجت الدورة حقيقة جديدة (مثال: "العميل يفضل السبت").
4. إصدار حدث قابلية المراقبة (مقياس زمن الاستجابة، تكلفة الرمز، معدل التصعيد).

كل هذا يعمل بالتوازي. الاستمرارية لا تحجب إرسال الرسالة — العميل لا ينتظر D1.

---

أين يكمن الدفاع ضد الهلوسة

الوكيل الذي يهلوس في الإنتاج يفقد الثقة بسرعة. لدى OpenClaw 4 خطوط دفاع:

1. مصدر الحقيقة المفروض. البيانات الواقعية (السعر، الموعد، الاسم) دائمًا تأتي من المهارة، وليس من النموذج وحده.
2. التحقق المزدوج من البيانات الحساسة. يتم تأكيد الحجز مع العميل قبل الحفظ. يتم تأكيد الدفع قبل منح الوصول.
3. قواعد سلبية صريحة. تتضمن شخصية كل وكيل "لا تخترع أبدًا X، Y، Z" — النموذج يطيع.
4. الرجوع إلى الإنسان. عندما لا تغطي أي مهارة السؤال، يقول الوكيل "دعني أتحقق مع الفريق" ويفتح تذكرة — لا يخمن.

في عمليات التدقيق التي أجريناها خلال الأشهر الستة الماضية (محادثات حقيقية تمت مراجعتها يدويًا)، كان معدل الهلوسة الواقعية أقل من 0.3% من الدورات — وكانت معظم الحالات تقريبًا بسبب التكوين (نسي المستأجر تفعيل المهارة ذات الصلة)، وليس خطأ النموذج.

---

التكلفة لكل محادثة

البنية الجيدة غير مرئية حتى تنظر إلى الفاتورة. بالنظر إلى أن كل دورة تقوم بـ 1-2 استدعاءات LLM + عمليات بحث في D1، فإن التكلفة النموذجية لكل محادثة كاملة (10-15 دورة) تكون: