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

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

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

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

---

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

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

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

الـ4 هوما اختيارات بنية، موش قيود تاع النموذج. OpenClaw تبنى باش يتجنب الـ4 — والطريق باش نفهمو هو نشوفو دورة الـ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 دورًا) تكون: