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

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

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

الملخص: تمر كل دورة بـ 6 مراحل — الاستيعاب، حل السياق، اختيار المهارات، تحديد الإجراء التالي، التنفيذ مع الحواجز الوقائية، الاحتفاظ بالذاكرة. تعمل الدورة الكاملة في أقل من ثانيتين على حافة 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 — اختيار المهارات (محرك السياسات، ~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 دورة) تكون: