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

كيف يعمل وكيل الذكاء الاصطناعي المحادثي من الداخل (مخطط 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. السياق المستقبلي — ماذا سوف يحدث بعد ذلك؟

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

كلها تأتي من D1 (SQLite الموزع من Cloudflare). D1 يلغي Postgres/Mongo التقليدية - لا يوجد خادم لل банк لصيانة، الوصول في بضع ميلي ثانية من worker، متعدد العميل عن طريق 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. Valida المعايير الأساسية (هل يحتوي date_range على تنسيق صحيح؟ هل يتوافق مع قواعد المستأجر؟).
2. يُตรวจف الحق في الوصول (هل له هذا العميل حق الوصول إلى هذا التقويم؟).
3. يُجرى استدعاء (API Google Calendar في هذه الحالة).
4. يُعاد ترتيب النتائج لنموذج.

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

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

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

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

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

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

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

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

---

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

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

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

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

---

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

(النص المترجم فقط، بدون أي تعليق أو مقدمات)

1. Valida المعايير الأساسية (هل يحتوي date_range على تنسيق صحيح؟ هل يتوافق مع قواعد المستأجر؟).
2. يُตรวจف الحق في الوصول (هل له هذا العميل حق الوصول إلى هذا التقويم؟).
3. يُجرى استدعاء (API Google Calendar في هذه الحالة).
4. يُعاد ترتيب النتائج لنموذج.

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

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

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

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

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

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

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

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

---

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

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

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

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

---

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

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

• 1-2 مكالمات إلى LLM: $X لكل مكالمة
• 1-2 عمليات البحث في D1: $Y لكل عملية بحث
• المجموع: $X + $Y لكل دور
• المجموع ل 10-15 دور: $10X + $15Y إلى $15X + $30Y