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

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

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

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

---

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

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

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

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

---

دورة التفاعل الواحد (6 مراحل)

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

المرحلة 1 — الاستقبال (edge worker، أقل من 50 مللي ثانية)

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

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

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 ذات صلة دلالية عالية). هذا يحافظ على تكلفة التوكنات متوقعة حتى في المحادثات التي تتجاوز 100+ دور.

المرحلة 3 — اختيار المهارات (محرك السياسات، ~20 ميلي ثانية)

كل وكيل لديه مجموعة من المهارات المتاحة — وظائف يمكنه استدعاؤها. أمثلة: consultar_calendario، criar_evento، gerar_link_pagamento، consultar_pedido، chamar_humano.

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

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

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

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

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

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

1. التحقق من المعاملات (هل date_range بالتنسيق الصحيح؟ هل يتوافق مع قواعد المستأجر؟).
2. التحقق من الصلاحيات (هل يحق لهذا الوكيل الاستعلام عن هذا التقويم؟).
3. تنفيذ الاستدعاء (Google Calendar API في هذه الحالة).
4. إرجاع نتيجة منظمة للنموذج.

لماذا هذا مهم؟ لأن النموذج لا يختلق النتيجة أبدًا. إذا أرجع التقويم [10h, 11h]، فهذا بالضبط ما ينتقل إلى الاستدعاء التالي. إذا فشلت المهارة، يعرف النموذج أنها فشلت. صفر مخاطر بأن يقوم الوكيل "باختلاق" موعد في الساعة 9 صباحًا وهو غير موجود.

في الحالات التي تتضمن معلومات حساسة (السعر، المدة الزمنية، اسم العميل)، يفرض خط الأنابيب tool call — ولا يسمح للنموذج بالإجابة من "معرفته" الخاصة. هذا يقضي على فئة الهلوسة الأكثر شيوعًا في الوكلاء التجاريين.

المرحلة 6 — الاستجابة والحفظ (~50 مللي ثانية)

مع وجود نتيجة المهارة في متناول اليد، يقوم النموذج بالاستدعاء الثاني — الآن لتشكيل الاستجابة النهائية للعميل. مثال:

"عندي السبت الساعة 10 و11. أيهما تفضل؟"

بالتوازي، يقوم الـ worker بـ:

1. إرسال الرسالة مرة أخرى عبر واجهة برمجة تطبيقات WhatsApp.
2. حفظ الدور الكامل (user + assistant + tool calls + المدة) في D1.
3. تحديث الذاكرة طويلة المدى إذا أنتج الدور حقيقة جديدة (مثال: "العميل يفضل يوم السبت").
4. إصدار حدث مراقبة (مقياس زمن الاستجابة، تكلفة التوكن، معدل التصعيد).

كل هذا يعمل بالتوازي. الحفظ لا يحجب إرسال الرسالة — العميل لا ينتظر D1.

---

أين يكمن الدفاع ضد الهلوسة

الوكيل الذي يهلوس في بيئة الإنتاج يفقد الثقة بسرعة. يمتلك OpenClaw 4 خطوط دفاع:

1. مصدر الحقيقة الإجباري. البيانات الواقعية (السعر، الموعد، الاسم) تأتي دائمًا من المهارة، وليس من النموذج وحده.
2. التحقق المزدوج للبيانات الحساسة. يتم تأكيد الحجز مع العميل قبل الحفظ. يتم تأكيد الدفع قبل منح الوصول.
3. القواعد السلبية الصريحة. شخصية كل وكيل تتضمن "لا تختلق أبدًا X، Y، Z" — والنموذج يمتثل.
4. التراجع إلى الإنسان. عندما لا تغطي أي مهارة السؤال، يقول الوكيل "دعني أتحقق مع الفريق" ويفتح تذكرة — ولا يخمّن.

في عمليات التدقيق التي أجريناها خلال الأشهر الستة الماضية (محادثات حقيقية تمت مراجعتها يدويًا)، بقي معدل الهلوسة الواقعية أقل من 0.3% من الأدوار — وكانت جميع الحالات تقريبًا بسبب الإعدادات (المستأجر نسي تفعيل المهارة المعنية)، وليس خطأ من النموذج.

---

تكلفة المحادثة الواحدة

البنية الجيدة تكون غير مرئية حتى تنظر إلى الفاتورة. بما أن كل دور يقوم بـ 1-2 استدعاءات لنموذج اللغة الكبير + عمليات بحث في D1، فإن التكلفة النموذجية لكل محادثة كاملة (10-15 دورًا) تكون: