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

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

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

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

---

لماذا يهم المخطط

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

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

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

---

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

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

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

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

العامل يفعل ثلاثة أمور:

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

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

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

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

1. السياق الحالي — ماذا كان العميل يريد؟
2. السياق السابق — ماذا كان العميل يريد قبل ذلك؟
3. السياق المستقبلي — ماذا سيكون العميل يريد بعد ذلك؟

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

جميعها تأتي من D1 (SQLite الموزع من Cloudflare). D1 يلغي Postgres/Mongo التقليدية - بدون خادم للبقاء، الوصول في بضع ميلي ثانية من العملاء، متعددة العميلين عن طريق tenant_id.

نقطة رئيسية: لا نقوم بتحميل المحادثة بأكملها في البداية. Manager الذاكرة 2 من OpenClaw (الموضحة في وثائقنا الداخلية) تحدد فقط الدورات ذات الصلة للدورة الحالية (الأخيرة N + N من الأهمية semantics). هذا يحافظ على تكلفة التokens المتوقعة حتى في المحادثات التي تزيد عن 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 يقوم ببعث استدعاء واحد إلى LLM من الأمام (Anthropic Claude، OpenAI GPT، Google Gemini - قابل للتعديل من قبل العميل) مع:

• نص النظام = الشخصية للعميل + القواعد + المهارات المتاحة.
• التاريخ = الدورات المحددة في المرحلة 2.
• رسالة المستخدم = الرسالة الحالية.

النموذج يرد أو إحدى الأشياء:

• الجواب النهائي (نص مباشر للعميل).
• استدعاء أداة (طلب لتنفيذ مهارة محددة مع معلمات).

في مثال "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. تنفيذ الدعوة (API Google Calendar في هذه الحالة).
4. إعادة النتائج بتنسيق إلى النموذج.

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

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

المرحلة 6 - الإجابة والاستمرار (~50ms)

باستخدام النتائج من المهام في يده، يؤدي النموذج الدعوة الثانية - الآن لتشكيل الإجابة النهائية للعميل. على سبيل المثال:

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

في نفس الوقت، العامل:

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

كل ذلك ي चलत في نفس الوقت. الاستمرار لا يمنع إرسال الرسالة - لا ينتظر العميل D1.

---

أين هي الدفاع ضد الخيال

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

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

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

---

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

القواعد الحرجة:

• احتفظ بجميع تنسيق markdown بالضبط (رأس ##، القوائم -، الخط العريض، الخط المائل، الروابط ، الحقول البرمجية، الخ).
• لا ترجم URLs أو الكود أو عناوين HTML
• لا أضف مقدمة أو تعليق
• أخرج فقط markdown المترجم، لا شيء آخر

المصدر markdown: هياكل جيدة هي غير مرئية حتى تطلع على الفاتورة. نظرا لان كل دورة تجعل 1-2 مكالمات ل LLM + lookups في D1، فإن التكلفة المتوسطة لكل محادثة كاملة (10-15 دورات) تظل في:

ترجمة markdown (ar-SA): هياكل جيدة هي غير مرئية حتى تطلع على الفاتورة. نظرا لان كل دورة تجعل 1-2 مكالمات ل LLM + lookups في D1، فإن التكلفة المتوسطة لكل محادثة كاملة (10-15 دورة) تظل في: