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

كيف يعمل وكيل الذكاء الاصطناعي المحادثي من الداخل (مخطط 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 التقليدية - بدون خادم للبقاء، الوصول في بضع ميلي ثانية من العملاء، المتعددين من قبل 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 - قابل للتعديل من قبل العميل) مع:

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

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

• الجواب النهائي (نص مباشر للعميل).
• 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. Valida المعايير الأساسية (هل يحتوي date_range على تنسيق صحيح؟ هل يتوافق مع قواعد المستأجر؟).
2. يُตรวจف الحق في الوصول (هل له هذا العميل حق الوصول إلى هذا التقويم؟).
3. يُجرى استدعاء API Google Calendar (في هذه الحالة).
4. يُعاد ترتيب النتائج لنموذج.

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

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

المرحلة 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: Arquitetura boa é invisível até você olhar a fatura. Dado que cada turno faz 1-2 chamadas de LLM + lookups em D1, o custo típico por conversa completa (10-15 turnos) fica em:

• 1-2 مكالمات LLM + بحث في D1 لكل دورة
• 10-15 دورة لكل محادثة
• التكلفة المتوسطة لكل محادثة تتراوح بين 10-15 دورة هي: