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

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

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

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

---

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

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

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

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

---

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

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

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

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

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

1. يتحقق من التوقيع للـ webhook (HMAC مقابل سر WABA).
2. يحدد المستأجر برقم هاتف المستقبل (متعدد المستأجرين بواسطة to_number).
3. يطبّع الحمولة — الصوت يصبح نسخاً، الصورة تصبح وصفاً، الموقع يصبح {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 دور) تكون: