كيف تختبر وكيل Meta للأعمال قبل إطلاقه للعملاء

تمنح Meta الفرق الآن طريقتين عمليتين لاختبار وكيل Meta للأعمال قبل فتحه لكل العملاء. استخدم Agent Test لإجراء اختبارات سريعة ومتكررة عبر خط معالجة الوكيل. ثم استخدم محادثة ضمن القائمة المسموح بها لإثبات مسار واتساب الحقيقي. لا تعتبر أي طريقة منهما قرار إطلاق كاملاً بمفردها.

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

يركز هذا الدليل على مسار Business Agent Platform. إذا كنت ما زلت تتحقق من أهلية الرقم أو من يملك كل حالة، فابدأ بدليل DripTell عن أهلية وكيل Meta للأعمال وملكية المحادثة.

مسارا الاختبار يؤديان وظيفتين مختلفتين

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

وتشرح مرجعية Agent Settings المسار الثاني. عند ضبط الجمهور على ALLOWLISTED_ONLY لا يرد الوكيل المفعّل إلا على المستهلكين الموجودين في قائمة القناة. وتقول Meta إن هذا الإطلاق المقيد لا يحتاج إلى وسيلة دفع، بينما يحتاج توسيع الجمهور إلى EVERYONE إلى وسيلة دفع.

المسار الأول مختبر سريع. والثاني بروفة تشغيلية. أما الإطلاق العام فهو الخدمة الحقيقية.

ابدأ باختبارات Agent Test المتكررة

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

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

لا تقيس النبرة والطلاقة فقط. سجّل المصدر المستخدم والحقول التي جُمعت والإجراء الذي جُرّب والمالك المختار وسبب أي توقف. تعتمد مساحة الذكاء الاصطناعي في DripTell الفكرة العملية نفسها: لا تكون الإجابة مفيدة إلا حين تبقى المعرفة المعتمدة وسياق العميل والخطوة المسؤولة التالية مترابطة.

يقبل مخطط API الحالي أيضاً conversation_id من رد اختبار سابق. لذلك يمكنك متابعة اختبار متعدد الرسائل بدلاً من افتراض أن كل استدعاء منفصل. استخدمه لاختبار التصحيحات والقيود المتغيرة والطلبات المتكررة. واحتفظ بحالات منفصلة لاختبار التراجع لأنها أسهل للمقارنة بعد كل تعديل.

استخدم القائمة المسموح بها للسلوك الحقيقي

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

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

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

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

نفذ خطة اختبار قائمة على الأدلة

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

لكل رحلة سجّل:

1. المصدر المعتمد للإجابة؛
2. الحقول التي يجوز للوكيل جمعها؛
3. الإجراء الذي يجوز له قراءته أو كتابته؛
4. الحدث الذي يفرض تدخلاً بشرياً؛
5. الفريق الذي يستلم الحالة؛
6. النتيجة التي تمنع الإطلاق العام.

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

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

اعرف ما لا يثبته الاختبار المجاني

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

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

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

الأسئلة الشائعة

هل استخدام Agent Test مجاني

تقول Meta إن الرموز المستهلكة عبر نقطة Agent Test لا تُفوتر. هذا لا يعني أن حركة الإنتاج مجانية، ولا يشمل تكاليف الأنظمة الأخرى التي قد يستدعيها الاختبار.

هل يدعم Agent Test محادثة متعددة الرسائل

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

هل أحتاج إلى وسيلة دفع للاختبار المقيد

تقول Meta إن الوكيل المقيد إلى ALLOWLISTED_ONLY يمكن تشغيله بلا وسيلة دفع. وتلزم وسيلة دفع عندما يتوسع الجمهور إلى EVERYONE.