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

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

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

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

---

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

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

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

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

---

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

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

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

الرسالة من WhatsApp تصل عبر webhook من Meta مباشرة إلى عامل في الحافة في نقطة تواجد (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. السياق المستقبلي — ماذا سوف يحدث بعد ذلك.

الوكيل يبحث عن هذه القطع من السياق في D1 (الذاكرة الأولية) و KV (الخزنة).

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

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

نقطة رئيسية: لا نقوم بتحميل المحادثة بأكملها في البداية. Manager الذاكرة 2 من OpenClaw (المقروء في وثائقنا الداخلية) يختار فقط الدورات ذات الصلة للدورة الحالية (الأخيرة N + N من الأهمية semantics). هذا يضمن تكلفة التوقيع التنبؤية حتى في المحادثات التي تزيد عن 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. Valida المعايير الأساسية (هل يحتوي date_range على تنسيق صحيح؟ هل يتوافق مع قواعد المستأجر؟).
2. يُตรวจ الفحص (هل له هذا العامل الحق في استعراض هذا التقويم؟).
3. يُجرى الإجراء (API Google Calendar في هذه الحالة).
4. يُعاد النظر في النتيجة المنسقة للموديل.

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

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

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

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

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

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

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

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

---

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

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

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

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

---

التكلفة لكل حوار

(النص المترجم لا يحتوي على أي تعليقات أو تعليقات إضافية)

Arquitetura خيالية هي غير مرئية حتى تطلع على الفاتورة. بمعرفة أن كل دورة تقوم ب 1-2 مكالمات ل LLM + عمليات البحث في D1، فإن التكلفة المتوسطة لكل محادثة كاملة (10-15 دورة) تكون في:

• 1-2 مكالمات ل LLM: 0.0001-0.0002 $/كلمة
• 1-2 عمليات البحث في D1: 0.00005-0.0001 $/كلمة
• التكلفة الإجمالية: 0.00015-0.0003 $/كلمة

ملاحظة: هذه التكلفة هي تقدير وتختلف حسب الخدمة المستخدمة وعدد الكلمات في المحادثة.