يرد المساعد بسرعة، ويتحدث بالعربية، ويعرض رقم طلب على الشاشة. المشهد مقنع، لكن السؤال التجاري لم يُحسم: هل جاء الرقم من نظام تجريبي حقيقي، وهل يخص المستخدم، وهل حدث الإجراء مرة واحدة فعلًا؟ عند اختيار شركة تطوير وكلاء ذكاء اصطناعي، اطلب دليلًا على النتيجة إلى جانب سلاسة الحوار.
ليس مطلوبًا أن يتحول اجتماع التعارف إلى تدقيق تقني كامل. المطلوب تجربة محدودة تكشف طريقة تفكير المنفذ وحدود ما عرضه، ثم اتفاق على اختبار أوسع قبل التشغيل. كلما كانت المهمة واضحة، صار من الأسهل تمييز حل مفيد عن نموذج يستعرض إجابات جميلة فقط.
اتفقوا على مهمة واحدة يمكن ملاحظتها
سنستخدم مثالًا افتراضيًا لمورد مستلزمات مكتبية يريد مساعدًا يتابع حالة الطلب ويسجل طلب تعديل عنوان للتأكيد من موظف. يقرأ المساعد بيانات مسموحة، ويتأكد من هوية العميل وفق آلية معتمدة، ثم يحيل التعديل للمراجعة. لا نفترض أنه يملك حق تعديل كل طلب أو الموافقة على أي استثناء.
اكتب بداية المهمة ونهايتها: من يسأل، وما المعلومات المسموح بها، وأين يظهر طلب التعديل، ومن يراجعه. حدد ما لا يدخل في التجربة، مثل التحصيل أو إلغاء مستندات مالية. عبارة «وكيل للمبيعات وخدمة العملاء» أوسع من أن تستخدم وحدها معيارًا للقبول.
افصل ما يقوله الوكيل عما حدث في النظام
تفرّق إرشادات Anthropic لتقييم الوكلاء بين سجل المحاولة والنتيجة النهائية في البيئة. ترجمة هذا للمشتري بسيطة: إذا قال المساعد «تم تسجيل طلبك»، اطلب رؤية السجل التجريبي الذي أُنشئ وحالته، لا الاكتفاء برسالة النجاح.
اسأل أيضًا عما إذا كان العرض يستخدم بيانات ثابتة أو ربطًا تجريبيًا أو بيئة أقرب للإنتاج. المحاكاة مفيدة في مرحلة مبكرة إذا كانت معلنة، لكنها لا تثبت جاهزية الربط الفعلي أو الصلاحيات أو قدرة النظام على معالجة الأعطال.
مجموعة صغيرة من الحالات أفضل من سؤال واحد سهل
| الحالة التجريبية | ما تريد ملاحظته |
|---|---|
| عميل يسأل عن طلبه المسموح | إجابة تستند لسجل صحيح دون إظهار بيانات زائدة. |
| سؤال لا توجد له معلومة معتمدة | توضيح النقص أو التحويل، دون اختراع إجابة. |
| طلب بيانات عميل آخر | رفض الوصول غير المصرح به، مع بقاء المهمة الأصلية سليمة. |
| تعديل يحتاج موافقة | تسجيل طلب مراجعة بدل تنفيذ التغيير مباشرة. |
| رسالة غامضة أو ناقصة | سؤال توضيح يحدد المطلوب دون افتراض خطر. |
| فشل النظام المتصل | عدم ادعاء النجاح وتقديم خطوة متابعة واضحة. |
| تكرار إرسال الطلب | نتيجة وفق قاعدة معلنة تمنع الإجراء المكرر غير المقصود. |
| العميل يطلب موظفًا | مسار تحويل ينقل السياق المناسب ويحترم الصلاحيات. |
هذه بداية مقترحة وليست شهادة كفاية من ثمانية أسئلة. أضف حالات من عملك الفعلي، بما فيها أخطاء الكتابة والأسماء المتشابهة وتغيّر المعلومة. استخدم بيانات مختلقة أو منزوعة الهوية ومصرحًا بها، ولا ترسل ملفات العملاء لمجرد اختبار عرض مبيعات.
عرّف النجاح قبل مشاهدة الإجابة
اكتب لكل حالة المدخل، وما يجب أن يحدث، وما يجب ألا يحدث، والدليل المطلوب. مثلًا: يتولد طلب مراجعة عنوان واحد مرتبط بالعميل الصحيح؛ لا يتغير عنوان الشحنة قبل الموافقة؛ ويمكن للمراجع رؤية سبب الطلب. هذا أوضح من عبارة «البوت يفهم العميل».
قيّم صحة المعلومات ونجاح المهمة وحماية البيانات والتحويل كلًا على حدة. متوسط جيد لا يمحو حالة تكشف بيانات عميل آخر. اتفق على الحالات التي تمنع الإطلاق مهما كانت بقية الإجابات مقنعة، وعلى من يراجع النتائج ويعتمد الاستثناءات.
لا تجعل محاولة واحدة حكمًا نهائيًا
قد تتغير مخرجات النظام بين المحاولات أو عند إعادة صياغة السؤال. جرّب حالات متكافئة بلغتك المعتادة، وسجل إعدادات التجربة ونتائجها. إرشادات OpenAI للتقييم تشرح دور سجلات التنفيذ ومجموعات الاختبار في مقارنة السلوك والتغييرات؛ المهم لك كمشترٍ أن تستطيع العودة إلى أدلة قابلة للمراجعة.
لا تطلب من الشركة إخفاء المحاولات الفاشلة. اطلب شرح السبب وما الذي تغير وكيف اختُبر الإصلاح. إعادة الأسئلة التي نجحت وحدها بعد التعديل قد تخفي أن إصلاحًا أفسد مهمة أخرى؛ احتفظ بمجموعة مرجعية تشمل السلوك الجيد والحدود المهمة.
اسأل عمن يدير المعرفة والأدوات
من يعتمد أسعار المنتجات أو سياسة الإرجاع التي يستند إليها الوكيل؟ كيف تُسحب معلومة قديمة؟ وما النظام المسؤول عن حالة الطلب الحالية؟ إذا كانت الإجابة موجودة فقط داخل تعليمات طويلة لا يملك الفريق تحديثها، فناقش دورة الصيانة قبل التعاقد.
بالنسبة للأدوات، اطلب وصفًا بلغة العمل لما يستطيع الوكيل قراءته أو إنشاؤه أو تغييره، وما يحتاج مراجعة. لا يكفي توجيهه نصيًا إلى التصرف بحذر إذا كانت حساباته تتيح له إجراءات أوسع مما يحتاج. اسأل المنفذ كيف يثبت حدود الوصول في الاختبار دون مطالبتك بتسليمه صلاحيات إنتاج غير لازمة للتجربة.
حوّل العرض إلى نطاق تجربة أولية
اطلب وثيقة قصيرة تشمل المهمة والقناة ومصدر المعرفة والربط والأدوار وحالات القبول، مع ما يعتمد على موافقات أو حسابات من جهات أخرى. حدد مسؤول المتابعة وطريقة إيقاف الإجراء عند مشكلة، وكيف تُصنف الملاحظات، وما البيانات التي ستستخدم لقياس النتيجة.
افصل تكلفة الإعداد عن التشغيل والاستخدام والمراقبة والتحديث. وإذا اقترح المورد نسبة توفير أو زيادة مبيعات، اطلب أساسها وطريقة قياسها في نشاطك؛ لا تتعامل مع تجربة ناجحة على بيانات افتراضية كأنها نتيجة مالية تحققت بالفعل.
لشرح الفرق بين الحوار وتنفيذ المهام، يمكنك قراءة دليل وكلاء الذكاء الاصطناعي للأعمال. وعند مناقشة تطوير وكيل ذكاء اصطناعي، أرسل المهمة ومجموعة الحالات المقترحة. أفضل نتيجة للاجتماع ليست وعدًا بأن الوكيل يفعل كل شيء، بل اتفاق قابل للاختبار على مهمة نافعة وحدودها.
مراجع ومنهج المقارنة
رُوجعت في 3 نوفمبر 2026 إرشادات Anthropic لتقييم الوكلاء وOpenAI لتقييم سير عمل الوكلاء. استُخدمت مفاهيم النتيجة وسجل التنفيذ والاختبارات المتكررة بإيجاز؛ السيناريو والجدول وإطار الشراء أصليان. لا تمثل هذه القائمة ضمان أمان أو نتيجة تجارية. أُعد المحتوى بمساعدة أدوات الذكاء الاصطناعي مع مراجعة النص ومصادره.
