🤖 أنواع وكلاء المحادثة الذكية (Types of AI Agents)

مرحبًا، في هذا الشرح سنتعرّف على أنواع وكلاء المحادثة الذكية (AI Agents) وكيف يتم تنظيم الخدمات التي يقدّمها الوكيل الذكي إلى مجموعة من أنماط عمل واضحة، بحيث يكون دور كل وكيل محدّدًا منذ البداية:

• هل الهدف أن يجيب الوكيل من ملف الأسئلة الشائعة؟
• أم يجمع بعض البيانات ثم يستعلم بها من نظام خارجي؟
• أم يحوّل المحادثة إلى نموذج (Form) يتم حفظه في نظام آخر؟
• أم يعتمد على مخزن معرفي متقدّم للبحث والاسترجاع؟

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

1️⃣ نظرة عامة على تصنيف وكلاء المحادثة الذكية

يتم تنظيم وكلاء المحادثة الذكية إلى أربعة أنماط رئيسية من العمل:

• FAQ Response – وكيل يجيب من ملف الأسئلة الشائعة ومصادر المعرفة الأخرى.
• Multi-Step Get Info – وكيل يجمع بيانات من المستخدم، ثم يستعلم بها من نظام خارجي.
• Multi-Step Post Info – وكيل يجمع بيانات من المستخدم، ثم يرسلها إلى نظام خارجي (مثل نموذج Lead).
• Data Retrieval from Storage – وكيل يصل إلى مخزن معرفي (مثل vector DB) لحالات البحث والاسترجاع المتقدّم.

هذه الأنماط لا تمثّل منتجات منفصلة، بل تعبّر عن طرق مختلفة لعمل الوكيل الذكي تبعًا لطبيعة حالة الاستخدام والتكامل المطلوب مع الأنظمة الأخرى.

2️⃣ وكيل FAQ Response – الإجابة من الأسئلة الشائعة ومصادر المعرفة 📚

التعريف

هذا النمط مخصّص للحالات التي يتوافر فيها محتوى مكتوب ومنظّم مسبقًا، مثل:

• ملف أسئلة شائعة (FAQ)،
• سياسات مكتوبة (سياسة الشحن، سياسة الاسترجاع، شروط الاستخدام…)،
• أو محتوى من موقع إلكتروني أو مستندات تم تجهيزها كمصادر معرفة.

يقوم الوكيل بالاعتماد على هذه المصادر للإجابة عن أسئلة المستخدم داخل المحادثة، بالاستناد إلى ما هو موثق ومتاح في هذه المستندات.

متى يناسب هذا النمط؟

• عند وجود نسبة كبيرة من الأسئلة المتكررة التي يمكن تغطيتها من خلال ملف FAQ أو سياسات واضحة.
• عند الرغبة في تقديم إجابات موحّدة ومتّسقة بدل اختلاف الردود بين موظف وآخر.
• عند الحاجة إلى تخفيف الضغط عن فرق الدعم في الأسئلة المعلوماتية البسيطة التي لا تحتاج تدخّلًا يدويًا في كل مرة.

3️⃣ وكيل Multi-Step Get Info – جمع بيانات ثم الاستعلام من نظام خارجي 🔍

التعريف

في هذا النمط، يقوم الوكيل بما يلي:

• جمع بيانات من المستخدم: مثل: رقم الطلب، رقم الجوال، أو أي معرّف آخر مطلوب للاستعلام عن حالة معيّنة.
• استخدام هذه البيانات مع نظام خارجي: من خلال: نقطة ربط (Endpoint) يتم توفيرها مسبقًا، و Payload محدّد من الفريق التقني أو النظام المتكامل.
• استرجاع النتيجة من قاعدة بيانات أو نظام آخر: ثم عرض النتيجة للمستخدم داخل المحادثة.

ملاحظات مهمة

• هذا النمط يعتمد على الاستعلام (Get) فقط.
• لا يقوم بإرسال أو تسجيل بيانات جديدة، بل يكتفي بجلب المعلومات المتاحة في النظام الخارجي.
• يتطلّب دائمًا توفير نقطة الربط (Endpoint) والـ Payload من الجهة المسؤولة عن النظام قبل تصميم الوكيل وتنفيذه.

4️⃣ وكيل Multi-Step Post Info – جمع بيانات ثم إرسالها إلى نظام خارجي 📝

التعريف

هذا النمط يشبه تحويل المحادثة إلى نموذج إلكتروني (Form) يتم حفظه في نظام خارجي. ينفّذ الوكيل هنا الخطوات التالية:

• جمع مدخلات من المستخدم: على مراحل متتابعة، مثل: الاسم، وسيلة التواصل، نوع الطلب، تفاصيل إضافية… إلخ.
• إرسال هذه المدخلات إلى نظام خارجي (Post): مثل قاعدة بيانات، أو نظام إدارة علاقات عملاء (CRM)، أو نظام آخر، من خلال: نقطة ربط (Endpoint) محددة، وPayload متفق عليه مسبقًا مع الفريق التقني.

حدود هذا النمط

• يتم التركيز على عملية إرسال واحدة (Post) واضحة لكل حالة استخدام.
• لا يُفضّل بناء مسارات معقّدة تحتوي على عدّة عمليات Post متتابعة في نفس التجربة، إلا بعد تقييم خاص من فريق الذكاء الاصطناعي؛ حفاظًا على استقرار التنفيذ وسهولة المتابعة.

5️⃣ وكيل Data Retrieval from Storage – البحث في مخزن معرفي متقدم 🧠

التعريف

هذا النمط يفترض وجود مخزن معرفي مهيّأ للبحث (مثل vector DB)، جرى تجهيز محتوى العمل بداخله مسبقًا. يقوم الوكيل في هذا النمط بـ: الوصول إلى المخزن المعرفي، تنفيذ عملية بحث (Search)، واسترجاع معلومات (Retrieval) اعتمادًا على السؤال الذي يطرحه المستخدم.

علاقته بالمصادر المعرفية

يمكن أن يعتمد هذا النمط على محتوى من أنواع مختلفة، مثل: ملفات PDF، مستندات DOCX، كتالوجات، محتوى من موقع إلكتروني أو قاعدة معرفة، بعد معالجة هذه المواد وتجهيزها داخل المخزن المعرفي بطريقة مناسبة للبحث والاسترجاع. هذا النمط يناسب الحالات التي تحتوي على محتوى كبير أو تفصيلي، ولا يمكن تلخيصها بالكامل في ملف أسئلة شائعة قصير.

6️⃣ استخدام هذه الأنماط في سيناريوهات خدمة العملاء والمبيعات

استنادًا إلى المواد التي توضّح قدرات وكيل المحادثة الذكي، يمكن استخدام الأنماط السابقة في سياقات متعددة، من بينها:

• أتمتة جزء من خدمة العملاء والمبيعات: حيث يمكن للوكيل، بحسب النمط المختار، أن: يجيب عن الأسئلة المتكررة بالاعتماد على مصادر المعرفة (FAQ Response)، أو يجمع بيانات من المستخدم ويستعلم من نظام خارجي (Multi-Step Get Info)، أو يجمع البيانات ويرسلها كنموذج إلى نظام خارجي (Multi-Step Post Info).
• التعامل مع مهام تتطلّب أنظمة خارجية (Cross-System Actions): مثل: مثال إنشاء حجز (Booking creation)، مثال تحديث حالة الطلب (Order status update)، وذلك عبر ربط الوكيل بنقاط ربط محددة واستخدام عمليات Get أو Post وفقًا حالة الاستخدام.
• العمل مع أكثر من وكيل صغير (Micro-Agents): يمكن توزيع الأدوار على وكلاء متخصّصين في مهام معيّنة، مثل: وكيل للإجابات من المعرفة، وكيل للاستعلام من الأنظمة، وكيل لإرسال البيانات، ويتم تنسيق عملهم من خلال طبقة تنظيمية (Orchestrator) لضبط كيفية تمرير السياق والمهام بينهم، وفق ما هو مذكور في المواد التي تصف وجود micro-agents و Orchestrator.

كل ذلك يظل مرتبطًا بما هو متاح فعليًا من نقاط ربط (Endpoints)، وPayloads، ومصادر معرفة في بيئة العمل.

7️⃣ ما الذي يجب تجهيزه قبل طلب أي نمط من الوكلاء؟ 🧷

لكي يكون تنفيذ أي وكيل محادثة ذكي من هذه الأنماط عمليًا وواضحًا، من المهم إعداد مجموعة من العناصر قبل طلب التنفيذ من فريق الذكاء الاصطناعي، كما توضّح نماذج العمل الداخلية:

• ملخص حالة الاستخدام (Use Case Summary): وصف بسيط يوضّح ما المطلوب من الوكيل أن يفعله للمستخدم داخل المحادثة.
• الهدف التجاري (Business Objective): مثل: تقليل وقت الرد، تحسين تجربة تتبّع الطلبات، تسجيل طلبات جديدة، دعم عمليات المبيعات… إلخ.
• نوع العملية (Get أو Post): إذا كانت الحالة تعتمد على الاستعلام عن معلومات موجودة ← فهي أقرب إلى Multi-Step Get Info. إذا كانت الحالة تعتمد على إرسال بيانات وتسجيلها في نظام خارجي ← فهي أقرب إلى Multi-Step Post Info.
• تفاصيل التكامل (عند وجود أنظمة خارجية): مثل: نقطة الربط (Endpoint)، مثال على الـ Payload، مع توضيح الأنظمة التي سيتم الربط معها، ويُفضّل أن تأتي هذه المعلومات من الفريق التقني المسؤول عن هذه الأنظمة.
• الالتزام بالقيود المعروفة: مثل: تجنّب بناء مسارات تحتوي على أكثر من عملية Post متتابعة في نفس التجربة، إلا بعد مراجعة متخصّصة، وعدم افتراض أي قدرات غير موثّقة صراحة في مواصفات النظام أو في المستندات الداخلية.

الخلاصة ✅

تصنيف أنواع وكلاء المحادثة الذكية إلى أربعة أنماط رئيسية يساعد على فهم كيفية توظيف وكيل المحادثة الذكي عمليًا من خلال: الإجابة من الأسئلة الشائعة ومصادر المعرفة (FAQ Response)، جمع بيانات المستخدم ثم الاستعلام من نظام خارجي (Multi-Step Get Info)، جمع بيانات المستخدم ثم إرسالها إلى نظام خارجي كنموذج (Multi-Step Post Info)، أو البحث في مخزن معرفي متقدّم (Data Retrieval from Storage). اختيار النمط المناسب لكل حالة استخدام، مع تجهيز المعلومات المطلوبة مسبقًا، يسهّل على فرق العمل الاستفادة من قدرات الوكيل الذكي ضمن الحدود الفعلية للنظام، وبأسلوب واضح ومتفق عليه مع فريق الذكاء الاصطناعي.

❓ الأسئلة الشائعة (FAQ)