ما الذي يغطيه هذا الدليل؟

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

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

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

هذا دليل حول البنية المعمارية، وليس ادعاءً بأن نموذجًا محددًا من OpenAI أو إصدارًا معينًا من SDK أو إصدارًا من Next.js أو نقطة نهاية بعينها ينفذ هذا التصميم تلقائيًا. تحقّق من تفاصيل إطار العمل وواجهات API بالرجوع إلى وثائقها الرسمية الحالية قبل كتابة الكود أو نشره.

الخطوة ١: تحديد مهمة الوكيل وحدوده

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

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

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

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

هذه متطلبات تشغيلية، وليست حيلًا لكتابة Prompt. يمكن لـ system prompt التعبير عن الحدود المقصودة، لكن يجب تنفيذ فرض الصلاحيات والموافقة عبر ضوابط خارج النص الذي يولده النموذج.

الخطوة ٢: تحويل الطلب إلى سير عمل محدد الصلاحيات

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

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

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

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

الخطوة ٣: تطبيق مبدأ أقل صلاحية وضوابط مستقلة

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

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

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

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

الخطوة ٤: اشتراط موافقة بشرية حقيقية

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

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

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

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

الخطوة ٥: اختبار السلوك قبل الإنتاج

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

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

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

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

الخطوة ٦: مراجعة التشغيل والحوكمة

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

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

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

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

سياق OpenAI Enterprise: الحضور لا يعني أن هذا الدليل يقدّم API

يصف السياق المتاح OpenAI Presence بأنه منتج مؤسسي لنشر الوكلاء وإدارتهم عبر مسارات العمل الموجهة للعملاء والداخلية. ويذكر أنه متاح من خلال برنامج محدود للتوفر العام للعملاء المؤسسيين المؤهلين، مع تولي OpenAI Forward Deployed Engineers ومتكاملين عالميين مختارين تنفيذ عمليات النشر. كما يوضح السياق أنه غير متاح بنظام الخدمة الذاتية.

لا ينبغي الخلط بين معلومات المنتج هذه ووصفة API عامة وموثّقة. فهي لا تؤكد اسم النموذج الوارد في المسودة، أو استدعاءات JavaScript SDK، أو كود Next.js، أو توفر تنفيذ بالخدمة الذاتية يطابق العينة. وعلى الفرق التي تدرس استخدام Presence التحقق من الأهلية الحالية ومعلومات النشر بالرجوع إلى مواد OpenAI الرسمية. أما الفرق التي تبني وكيلًا آخر، فعليها التحقق من تفاصيل API وإطار العمل ذي الصلة بشكل مستقل.

قائمة التحقق من جاهزية التنفيذ

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

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