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

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

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

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

---

لماذا تهم البنية

الوكيل التحاوري الذي يبدو أنه يعمل في العرض التوضيحي ولكنه ينهار في الإنتاج عادة ما يكون لديه واحدة من هذه المشاكل الأربع:

1. زمن انتقال مرتفع — ينتظر العميل 8 ثوانٍ للرد، تموت المحادثة.
2. هلوسة غير مضبوطة — يخترع الوكيل السعر، الوقت، السياسة.
3. سياق مفقود — يعود العميل بعد يومين والوكيل "ينسى" كل شيء.
4. تكلفة غير مضبوطة — كل محادثة طويلة تملأ الموجه وتدفع ثروة في الرموز.

الأربعة هي خيارات بنية، وليست قيود النموذج. تم بناء OpenClaw لتجنب الأربعة — والطريق للفهم هو النظر إلى دورة الدورة.

---

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

تخيل أن العميل أرسل للتو الرسالة "أريد الحجز ليوم السبت صباحًا". ماذا يحدث بين "تم الاستلام" ورد الوكيل؟

المرحلة 1 — الاستيعاب (عامل الحافة، <50 مللي ثانية)

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

يقوم العامل بثلاثة أشياء:

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

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

المرحلة 2 — حل السياق (D1 + KV، ~80 مللي ثانية)

يحتاج الوكيل إلى 3 أجزاء من السياق قبل اتخاذ القرار:

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

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

النقطة الأساسية: نحن لا نحمل المحادثة بأكملها في الـ prompt. يقوم Memory Manager v2 من OpenClaw (الموصوف في وثائقنا الداخلية) باختيار الدورات ذات الصلة فقط للدورة الحالية (آخر N + N ذات صلة دلالية عالية). هذا يحافظ على تكلفة الـ token قابلة للتنبؤ حتى في المحادثات التي تزيد عن 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 بالتصفية:

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

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

المرحلة 4 — القرار (LLM call، 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. إرسال الرسالة مرة أخرى عبر واجهة برمجة تطبيقات 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 دورًا) تكون: