Comment fonctionne un agent de IA conversational par dedans

كيف يعمل وكيل الذكاء الاصطناعي المحادثي من الداخل (مخطط 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 (المقروء في dokumentationنا الداخلية) يختار فقط الدورات ذات الصلة للدورة الحالية (الأخيرة 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 paramètres (date_range a format correct? est-ce qu'il est dans les règles du locataire?).
2. Vérifie la permission (cet agent a-t-il le droit de consulter ce calendrier?).
3. Exécute l'appel (API Google Calendar dans ce cas).
4. Retourne le résultat structuré au modèle.

Pourquoi cela est-il important? Parce que le modèle ne fabrique jamais le résultat. Si le calendrier retourne [10h, 11h], c'est exactement cela qui va à la prochaine appelle. Si la compétence échoue, le modèle sait qu'elle a échoué. Aucun risque de l'agent "inventer" qu'il a un horaire à 9h quand il n'en a pas.

Pour les cas qui impliquent des informations sensibles (prix, délai, nom du client), le pipeline force tool call — il ne laisse pas le modèle répondre du propre "connaissances". Cela élimine la classe d'alucination la plus commune dans les agents commerciaux.

Étape 6 — Réponse et persistance (~50ms)

Avec le résultat de la compétence en main, le modèle fait la deuxième appelle — maintenant pour former la réponse finale pour le client. Ex :

"J'ai samedi à 10h et 11h. Quel préfère-tu?"

Parallèlement, le worker :

1. Envoie la message de retour par l'API de WhatsApp.
2. Persiste le tour complet (utilisateur + assistant + appels de outil + durée) dans D1.
3. Met à jour la mémoire à long terme si le tour a produit un fait nouveau (ex : "le client préfère samedi").
4. Émet un événement d'observabilité (métrique de latence, coût de jeton, taux d'échelle).

Tout cela tourne en parallèle. La persistance ne bloque pas l'envoi de la message — le client n'attend pas D1.

---

Où est la défense contre l'alucination

Agent qui alucine en production perd confiance rapidement. Le OpenClaw a 4 lignes de défense :

1. Source-of-truth forçée. Données factuelles (prix, horaire, nom) semprent venir de compétence, jamais du modèle seul.
2. Vérification double en données sensibles. Agendement est confirmé avec le client avant de persister. Paiement est confirmé avant de libérer l'accès.
3. Règles négatives explicites. Persona de chaque agent inclut "n'oublie jamais X, Y, Z" — le modèle obéit.
4. Fallback pour l'humain. Lorsque aucune compétence ne couvre la question, l'agent dit "laisse-moi vérifier avec l'équipe" et ouvre un ticket — il ne chute pas.

Dans les audits que nous avons effectués ces derniers 6 mois (conversations réelles revues manuellement), le taux d'alucination factuelle est inférieur à 0,3% des tours — et la plupart des cas ont été dus à la configuration (le locataire a oublié d'activer la compétence pertinente), pas à l'erreur du modèle.

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

• 1-2 مكالمات إلى LLM: $0.006-$0.012 لكل مكالمة
• 1-2 searches في D1: $0.0005-$0.001 لكل search
• المجموع: $0.0065-$0.013 لكل دورة
• المجموع ل 10-15 دورات: $0.065-$0.195