توجيه الوكيل الذكي: كيف تكتب تعليمات فعّالة لوكلاء الذكاء الاصطناعي

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

توجيه الوكيل: ما الذي ستتعلّمه

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

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

السياق هو أساس توجيه الوكيل

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

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

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

الفئات الأربع للسياق

يمكن تصنيف السياق الذي تقدمه لأي وكيل ضمن أربع فئات متكاملة:

١. الخلفية (Background)

من أنت؟ ما طبيعة عملك أو منتجك أو مشروعك؟ هذه الجملة أو الجملتان تضعان الوكيل في الصورة الكبرى وتُقلّلان من التفسيرات العشوائية. مثال: «أنتَ وكيل تحليل تنافسي يعمل لصالح شركة SaaS ناشئة في مجال إدارة المشاريع، مستخدموها الأساسيون فرق هندسة البرمجيات.»

٢. الهدف (Goal)

ما النتيجة الوحيدة التي تُعدّ هذه المهمة ناجحة إذا تحققت؟ ليس قائمة أمنيات، بل هدفٌ واحد واضح. حين تُعدد الأهداف بلا ترتيب أولويات، يتصرف الوكيل كأنها متساوية في الأهمية فيتراجع أداؤه في جميعها.

٣. القيود (Constraints)

ما الذي لا يجوز فعله؟ ما الأدوات المتاحة وما المحظورة؟ ما الحد الزمني أو حد التوكن أو حد التكلفة؟ القيود ليست عوائق بل هي خارطة الطريق السلبية التي تُحدد أين تنتهي صلاحيات الوكيل.

٤. صيغة المخرجات (Output Format)

هل المخرج تقرير PDF؟ جدول JSON؟ رسالة بريد قصيرة؟ قائمة نقطية؟ بدون تحديد الصيغة، سيختار الوكيل ما يناسبه هو، لا ما يُدمج بسلاسة في سير عملك.

تحديد نطاق الوكيل وحدوده

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

نطاق الوصول (Access Scope)

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

نطاق القرار (Decision Scope)

ضع خطاً فاصلاً بين القرارات التي يُنفذها الوكيل فوراً، والقرارات التي يُقترحها فقط. مثلاً: وكيل تسويقي قد يُصيغ التغريدات باستقلالية تامة، لكن يجب أن ينتظر الموافقة البشرية قبل نشرها. كلما كانت عواقب القرار أكبر (مالية، قانونية، علنية)، كان يجب أن يكون دور الوكيل أكثر اقتراحاً وأقل تنفيذاً.

نطاق الموضوع (Topic Scope)

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

بروتوكول التصعيد — متى يتوقف الوكيل ويستشير إنساناً؟

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

حالات التصعيد الإلزامي

ضمّن في تعليمات النظام قائمة صريحة بالسيناريوهات التي يجب فيها على الوكيل أن يتوقف ويُرسل تنبيهاً بدلاً من المتابعة:

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

صياغة رسالة التصعيد

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

التوجيه بالأمثلة القليلة مع النماذج السلبية

الأمثلة القليلة (Few-Shot Examples) أداة قوية لتوضيح ما لا تستطيع الكلمات وحدها وصفه. لكن الممارسة الأكثر تأثيراً والأقل شيوعاً هي إضافة نماذج سلبية صريحة: أمثلة على ما لا تريده مع شرح لماذا.

مثال على مخرج جيد (Positive Example)

«عند تحليل منافس، أخرج قائمة من خمسة نقاط تغطي: الميزة التنافسية الرئيسية، الشريحة المستهدفة، نقطة الضعف الأبرز، استراتيجية التسعير، وآخر تحديث منشور.»

مثال على مخرج سيئ (Negative Example) + السبب

«لا تُخرج فقرات سردية مطوّلة بلا هيكل — السبب: الفريق يحتاج بيانات يمكن مسحها بصرياً في ثلاثين ثانية، لا مقالاً يحتاج قراءة.»

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

مثال شامل على تعليمات النظام لوكيل تحليل المنافسين

فيما يلي مثال على تعليمات نظام احترافية يمكنك تكييفها مباشرةً لوكيل تحليل تنافسي:

## الدور والهوية
أنتَ وكيل تحليل تنافسي لشركة ProjectFlow (SaaS لإدارة المشاريع).
مستخدمك هو فريق المنتج المؤلف من ٤ أشخاص.

## الهدف الأساسي
تتبّع منافسي ProjectFlow الرئيسيين الثلاثة (Asana, Linear, Notion)
وتُنتج تقارير أسبوعية موجزة قابلة للمسح البصري في أقل من دقيقة.

## المصادر المتاحة
- بحث الويب (web_search) — للأخبار والمدونات العامة
- قاعدة بيانات CRM الداخلية (crm_read) — للقراءة فقط، لا كتابة
- جدول بيانات المنافسين (sheet_read) — للقراءة فقط

## القيود الصريحة
- لا تكتب مباشرةً في أي قاعدة بيانات دون موافقة صريحة.
- لا تُدرج أسعاراً من مصادر غير موثّقة بتاريخ أقل من ٩٠ يوماً.
- لا تُوجّه أسئلة للمستخدم أكثر من سؤال واحد في الجلسة الواحدة.

## صيغة المخرجات
جدول Markdown يتضمن الأعمدة: المنافس | الجديد هذا الأسبوع | التأثير المحتمل | الإجراء المقترح.
أسفل الجدول: فقرة خلاصة تنفيذية بحد أقصى ٥٠ كلمة.

## بروتوكول التصعيد
توقّف وأرسل تنبيهاً إذا:
- كانت البيانات متناقضة بين مصدرين مختلفين.
- اكتشفتَ خبراً قد يستلزم قراراً استراتيجياً فورياً (استحواذ، إغلاق، شراكة كبرى).
- طُلب منك تعديل البيانات أو التحيز في التحليل لصالح جهة معينة.

## مثال مخرج مقبول
| Asana | أطلقت ميزة AI لتوزيع المهام تلقائياً | متوسط | مراجعة خارطة طريق AI لدينا |

## مثال مخرج مرفوض (مع السبب)
"قامت Asana في الأسبوع الماضي بإطلاق ميزة جديدة رائعة تساعد الفرق..."
السبب: نص سردي غير منظّم لا يتيح المسح السريع.

مثال عملي

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

الخطوة ١ — تعريف الخلفية: «أنتَ وكيل إدارة بريد إلكتروني لمدير تنفيذي في شركة تقنية. يستقبل ٢٠٠ رسالة يومياً ويريد أن يرى فقط ما يستوجب تدخله الشخصي.»

الخطوة ٢ — تعريف الهدف: «صنّف كل رسالة ضمن ثلاث فئات: (أ) تتطلب رداً اليوم، (ب) يمكن تفويضها، (ج) للأرشيف فقط.»

الخطوة ٣ — تعريف القيود: «لا تحذف أي رسالة. لا تردّ أوتوماتيكياً. لا تصل إلى المرفقات.»

الخطوة ٤ — تعريف صيغة المخرجات: «أنتج قائمة يومية مرتبة حسب الأولوية تتضمن: رقم الرسالة، المُرسِل، سطر الموضوع، الفئة، وسبب التصنيف في جملة واحدة.»

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

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

مراجعة أداء الوكيل وتكييف تعليماته عبر الوقت

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

بعد كل خمس عمليات تشغيل، راجع سجل الوكيل وسجّل: أين تصرّف بشكل مثالي؟ أين احتاج تصحيحًا؟ هل واجه موقفًا لم تُغطِّه التعليمات؟ هذه المراجعة الخماسية تُشكّل دورة تعلّم عملية تُبقي الوكيل محاذيًا لاحتياجاتك المتطورة.

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

أخطاء شائعة يجب تجنبها

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

تكييف أسلوب توجيه الوكيل مع أنواع المهام المختلفة

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

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

للمهام الإبداعية، أعطِ أمثلة على الأسلوب المطلوب (few-shot examples) بدلًا من وصف الأسلوب بالكلمات. الوكيل يُكيّف أسلوبه من المثال أسرع وأدق من تعليمة “اكتب بأسلوب احترافي غير رسمي” — إذ تعني هذه العبارة أشياء مختلفة لأشخاص مختلفين.

أفضل الممارسات

• ابدأ بنسخة مسودة ثم اختبر: اكتب تعليمات النظام، شغّل الوكيل على ١٠ حالات تمثيلية، لاحظ أين يُخطئ، ثم عدّل السياق بدلاً من نموذج الذكاء الاصطناعي نفسه — التعليمات أرخص وأسرع في التعديل من ضبط النموذج.
• استخدم نسخة الوكيل (Versioning): احتفظ بسجل لكل تغيير تُجريه على تعليمات النظام مع تاريخ التغيير والسبب. هذا يُمكّنك من العودة لنسخة سابقة إذا تراجع الأداء.
• فصل التعليمات الثابتة عن الديناميكية: تعليمات الدور والقيود دائمة — ضعها في system prompt. أما سياق المهمة المحددة (البيانات، التواريخ، الأسماء) فيجب حقنها في الرسالة الأولى من المستخدم أو كمتغيرات، لا دمجها في تعليمات النظام.
• اختبر الحالات الحدية (Edge Cases): ما الذي يحدث لو جاء مُدخل فارغ؟ أو مُدخل بلغة مختلفة؟ أو طلب يخرج عن نطاق الموضوع؟ كل سيناريو يجب أن يكون له مسار محدد في التعليمات.
• راقب وحسّن بانتظام: الوكيل في بيئة الإنتاج يواجه بيانات لم تتخيلها وقت الكتابة. ضع آلية لمراجعة مخرجاته أسبوعياً في البداية، ثم شهرياً حين تستقر الجودة، واضبط التعليمات بناءً على الأنماط الفعلية لا الافتراضية.

توجيه الوكيل: الأسئلة الشائعة

ما الفئات الأربع التي يجب أن تتضمنها تعليمات توجيه الوكيل الجيدة؟

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

كيف تُحدَّد صلاحيات الوكيل عند كتابة تعليماته؟

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

ما هو بروتوكول التصعيد ولماذا هو جزء أساسي من توجيه الوكيل؟

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

هل تُكتب تعليمات الوكيل مرة واحدة فقط أم تحتاج تحديثاً مستمراً؟

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

ما أكثر خطأ شائع يقع فيه من يكتب تعليمات لوكيل ذكاء اصطناعي لأول مرة؟

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

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