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

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

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

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

---

علاش البنية مهمة

الوكيل التحاوري اللي كيبان خدام في demo ولكن كينهار في الإنتاج عادة عندو واحد من هاد 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.

بالنظر إلى الرسالة "quero marcar pra sábado de manhã"، محرك السياسات يقوم بالتصفية:

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

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

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

الآن يدخل النموذج. OpenClaw يقوم باستدعاء واحد لنموذج لغوي متقدم (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)

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

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 دورة) تكون: