القواعد أم الوكيل الذكي (AI Agent) في واتساب؟ دليل الاختيار

استخدم سير العمل القائم على القواعد (rule-based workflow) عندما تكون الشروط والنتائج ثابتة، واستخدم خطوة ذكاء اصطناعي محدودة (AI step) لمهمة لغوية واحدة مثل التصنيف أو الاستخراج أو صياغة مسودة. استخدم الوكيل الذكي (AI agent) فقط عندما يتطلب الهدف اختيار أدوات أو معلومات وخطوات متغيرة. وفي الإنتاج، اجمع بينها: الذكاء الاصطناعي للفهم والاقتراح، والقواعد للتنفيذ الحساس، والإنسان للاستثناءات عالية الأثر.

الخلط بين هذه الأنماط يجعل الشركة إما تبالغ في تعقيد مهمة بسيطة، أو تتوقع من خطوة توليد واحدة أن تدير عملية متعددة المراحل. السؤال الصحيح ليس «هل نستخدم AI؟» بل: ما الجزء الذي يحتاج استدلالًا، وما الجزء الذي يجب أن يبقى حتميًا، وما الأثر إذا أخطأ؟

ثلاثة أنماط وليست مقارنة ثنائية

كلمة «أتمتة ذكية» قد تصف ثلاثة تصاميم مختلفة جذريًا:

ليست كل عقدة ذكاء اصطناعي وكيلًا. استدعاء نموذج مرة واحدة لإنتاج JSON أو رد لا يمنحه قدرة تلقائية على اختيار واجهة برمجة تطبيقات (API) أو تكرار المحاولة أو تعديل نظام خارجي. وبالعكس، إضافة أداة إلى الوكيل لا تعني أنه يجب أن يملك كل أدوات الشركة.

متى تكون القواعد هي الاختيار الصحيح؟

اختر القواعد عندما تستطيع كتابة الشرط والنتيجة والتحقق قبل التشغيل. أمثلة:

• توجيه محادثة رقم فرع جدة إلى فريق جدة.

• منع حملة عندما لا توجد موافقة موثقة.

• إرسال طلب حالة إلى ERP بعد التحقق من بنية رقم الطلب.

• تصعيد محادثة إذا طلب العميل موظفًا صراحةً.

• رفض خصم يتجاوز حدًا ماليًا أو يحتاج صلاحية أعلى.

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

يوضح دليل تصميم سير العمل لأتمتة واتساب كيفية تنظيم المحفز (trigger) والشروط والإجراءات والفشل دون تحويل المخطط إلى شبكة غير قابلة للصيانة.

أين تناسب خطوة الذكاء الاصطناعي المحدودة؟

خطوة AI مناسبة عندما يكون المدخل غير منظم لكن المخرج المطلوب واضحًا. أمثلة عملية:

1. تصنيف الرسالة إلى sales أوsupport أوbilling أوunknown.

2. استخراج رقم طلب واسم منتج ومدينة إلى JSON ذي schema ثابت.

3. تلخيص آخر عشر رسائل للموظف من دون اتخاذ إجراء خارجي.

4. إنشاء مسودة رد تعتمد على حقائق معتمدة ليوافق عليها الموظف.

5. اكتشاف أن المعلومات غير كافية وإرجاع needs_clarification.

مثال مخرج مقيد:

{
  "intent": "order_status",
  "order_id": "SO-10482",
  "needs_human": false,
  "missing_fields": []
}

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

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

متى يستحق الوكيل الذكي التعقيد الإضافي؟

يكون الوكيل منطقيًا عندما لا يمكن معرفة تسلسل الخطوات مقدمًا لكل حالة، لكن يمكن تحديد الهدف والأدوات والحدود. مثال: «ساعد الموظف في الإجابة عن سؤال طلب معقد». قد يحتاج الوكيل إلى:

1. قراءة ملف العميل.

2. البحث عن الطلب المذكور.

3. قراءة حالة الشحنة إذا كان الطلب قد خرج.

4. مقارنة النتيجة بسياسة الإرجاع.

5. صياغة إجابة أو طلب معلومة ناقصة.

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

لا تستخدم وكيلًا لمجرد أن الرسم التقليدي يحتوي خمسة فروع. إذا كانت الفروع معروفة وثابتة، فالقواعد أبسط. استخدمه عندما يكون اختيار المعلومات أو الأدوات نفسه جزءًا من المشكلة.

جدول قرار سريع

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

النمط الهجين الأكثر عملية

يمكن أن يبدو تدفق دعم الطلبات هكذا:

رسالة واردة
  ↓ قواعد: قناة مؤهلة؟ عميل معروف؟
خطوة AI: تصنيف النية واستخراج order_id
  ↓ تحقق schema ونمط المعرف
قاعدة: order_status؟
  ├─ نعم → أداة ERP للقراءة فقط
  │          ↓
  │       خطوة AI: صياغة مسودة من الحقائق
  │          ↓
  │       قاعدة سياسة + موافقة بشرية عند الحاجة
  └─ لا/غامض → إسناد أو سؤال توضيحي

في حالة أكثر غموضًا يمكن وضع وكيل محدود في المساحة بين التحقق وصياغة المسودة، مع أدوات قراءة مسموحة. لكن تبقى قاعدة الأهلية وبوابة الإرسال خارج سلطته. وعند الربط بنظام خارجي، استخدم معرفات وعمليات لا يتغير أثرها عند التكرار (idempotent) كما يوضح دليل تكامل واتساب مع CRM وERP.

ضوابط يجب بناؤها قبل الوكيل

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

1. هدف ونطاق ضيقان

اكتب ما يستطيع الوكيل فعله وما لا يستطيع فعله. «ساعد في استفسارات الطلب» أفضل من «حل كل طلبات العملاء». اربط كل أداة بغرض معلن.

2. قائمة أدوات وصلاحيات محدودة

ابدأ بأدوات قراءة. إذا احتجت كتابة، استخدم نقطة نهاية (endpoint) مخصصة بحدود بدل رمز إداري عام. لا تمرر للوكيل سر API؛ تنفذ المنصة الأداة وتحمي بيانات الاعتماد.

3. تحقق حتمي من المدخل والمخرج

استخدم JSON schema وقوائم مسموحة وحدود طول وتحققًا من المعرفات. لا تحول نص النموذج مباشرة إلى مبلغ أو استعلام أو عنوان URL.

4. موافقة بشرية للأثر العالي

الخصم والاسترداد والإلغاء وتغيير بيانات العميل والإرسال الجماعي أمثلة تحتاج موافقة أو قواعد صارمة. اجعل المسودة قابلة للمراجعة مع إظهار الحقائق التي بُنيت عليها.

5. سقف للخطوات والوقت والتكلفة

ضع حدًا لعدد استدعاءات الأدوات، وtimeout، وحجم السياق، ومحاولات الاستعادة. في Wats يمكن تقييد عقدة ai.agent عبر maxToolSteps؛ الافتراضي الحالي أربع خطوات أدوات، ويجب ضبطه وفق الحالة لا رفعه بلا نهاية.

6. مسار فشل وتصعيد

إذا لم توجد معلومة، أو تعارضت الأدوات، أو فشل التحقق، لا تجعل النموذج يخمن. أعد نتيجة منظمة مثل needs_human مع السبب والحقائق المتاحة.

7. تتبع واختبارات تقييم

سجل نسخة سير العمل، والمدخل المنقح، والأدوات ومعاملاتها الآمنة، والمخرجات والتحقق والقرار النهائي. ابنِ مجموعة تقييم من حالات واقعية وحدية، واختبرها عند تغيير الموجّه (prompt) أو النموذج أو الأداة.

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

كيف يترجم Wats هذه الفروق؟

يفصل Wats بين عقدة الوكيل وبين خطوات توليد محدودة. عقد مثل ai.generate_reply وai.gemini_generate أو نموذج ai.model.gemini_chat تنفذ استدلالًا أو توليدًا محددًا، ويمكن تغذيتها بعقد سياق وحقائق. أما ai.agent فيستطيع العمل عبر أدوات وخطوات متعددة ضمن حد مضبوط، ويمكن ربطه بأداة HTTP عند الحاجة.

هذا الفصل يسمح ببناء سير عمل هجين: شروط حتمية، ثم استخراج أو توليد، ثم وكيل فقط في الجزء المتغير، ثم بوابة تحقق وإرسال. أسماء العقد ليست بديلًا عن تصميم المخاطر؛ حتى الخطوة المحدودة تحتاج مخططًا (schema) ومصدر حقائق، والوكيل يحتاج فوق ذلك صلاحيات وخطوات وتصعيدًا مقيدًا.

الخلاصة: أعط كل طبقة أقل استقلال تحتاجه

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