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

كيف يعمل وكيل الذكاء الاصطناعي المحادثي من الداخل (مخطط 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} جاهز للخطوة التالية.

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

جميعها تأتي من D1 (SQLite الموزع من Cloudflare). D1 ي替ي Postgres/Mongo التقليدية - بدون خادم للبنان لصيانة، الوصول في بضع ميلي ثانية من العملاء، متعددة العميلين عن طريق 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 - قابلة للتحديد من قبل العميل) مع:

• prompt النظام = شخصية العميل + قواعد + مهارات متاحة.
• التاريخ = الدورات المحددة في المرحلة 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. حفظ الدورة الكاملة (المستخدم + المساعد + الدعوات بالtool + المدة) في 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-IQ): هياكل جيدة هي غير مرئية حتى تطلع على الفاتورة. نظرا لأن كل دورة تجعل 1-2 مكالمات ل LLM + lookups في D1، فإن التكلفة المتوسطة لكل محادثة كاملة (10-15 دورة) تظل في: