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

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

الخلاصة السريعة

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

يتألف الحد الأدنى لتدفق عمل موثوق من ثمانية أجزاء:

1. اختر ادعاءً واحداً: القدرة، أو قوة الضوابط الوقائية، أو المقارنة.
2. دوّن حدود التفويض بلغة واضحة وفي سياسة تفرضها الأنظمة آلياً.
3. اختبر نظام الوكيل كاملاً، بما في ذلك الأدوات والذاكرة وإعادات المحاولة وإعدادات الاستدلال.
4. أنشئ نطاقاً اختبارياً مؤقتاً يمنع الوصول إلى الأنظمة الحقيقية افتراضياً.
5. استخدم بيانات اصطناعية وهويات محدودة النطاق وبيانات اعتماد تكشف سوء الاستخدام من دون تعريض الإنتاج للخطر.
6. راقب استدعاءات الأدوات ونشاط الشبكة وعمليات المصادقة والعمليات الجارية وتغييرات الملفات لحظة بلحظة.
7. افصل نجاح المهمة عن السلوك الآمن، ثم كرر الاختبار ضمن ميزانية معلنة.
8. راجع مسارات التنفيذ وانشر تفاصيل تكفي لكي يفهم مراجع آخر النتيجة.

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

ماذا يقيس تقييم أمان وكلاء الذكاء الاصطناعي فعلياً؟

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

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

يقسم دليل OpenAI لتقييمات الأطراف الثالثة المسألة إلى ثلاثة أنواع صحيحة من الادعاءات:

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

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

كيفية إجراء التقييم

1. ابدأ بالقرار، ثم صغ الادعاء

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

صغ الادعاء في جملة واحدة:

ضمن منظومة التشغيل والميزانية المحددتين بدقة، هل يستطيع هذا الوكيل إتمام هذه المهمة من دون تجاوز حدود التفويض هذه؟

تمنع هذه الجملة خطأً شائعاً: نشر نتيجة تبدو واضحة لكن معناها يتغير كلما استبدل أحدهم الأدوات أو سياسة إعادة المحاولة أو تعليمات النظام أو الميزانية.

2. عرّف النطاق مرتين: بالكلمات وبالضوابط

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

يجب أن تحدد خطة التشغيل، في حدها الأدنى، ما يلي:

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

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

3. أعد إنشاء منظومة التشغيل الحقيقية

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

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

4. أنشئ نطاقاً يُغلق بأمان عند الفشل

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

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

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

5. اجعل إساءة استخدام بيانات الاعتماد غير مؤذية

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

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

6. راقب بصورة مستقلة وأوقف التشغيل آلياً

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

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

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

7. قيّم النجاح والسلامة كلّاً على حدة

قد ينجز التشغيل المهمة ويفشل رغم ذلك في التقييم الأمني. استخدم بطاقتي تقييم على الأقل:

• نتيجة المهمة: هل حقق الوكيل الهدف المقصود ضمن الظروف المعلنة؟
• نتيجة الالتزام بالحدود: هل بقي ضمن الأنظمة والهويات والبيانات والأدوات والإجراءات المصرح بها؟

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

8. كرر الاختبار بميزانية معلنة، ثم راجع المسارات

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

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

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

سبع حالات استخدام مرتبة حسب الأكثر استفادة

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

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

ما الذي يمكن بناؤه انطلاقاً من ذلك؟

1. منصة تحكم آمنة لتقييم الوكلاء

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

الطلب ظاهر: تحقق عبارة "ai red teaming" عدد 1,000 عملية بحث شهرياً على Google في الولايات المتحدة، بصعوبة كلمة مفتاحية تبلغ 15 وتكلفة نقرة قدرها $32.16. وتحقق عبارة "ai red teaming tools" عدد 140 عملية بحث شهرياً، بصعوبة 2 وتكلفة نقرة قدرها $64.30. كما يسأل الناس مساعدي الذكاء الاصطناعي عن AI red teaming نحو 40 مرة شهرياً.

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

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

2. طبقة تقارير تقييم بمستوى الأدلة

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

تحقق عبارة "AI agent evaluation" عدد 260 عملية بحث شهرياً على Google في الولايات المتحدة بتكلفة نقرة تبلغ $23.09، بينما تحقق "AI agent evaluation framework" عدد 90 و**"AI agent evaluation metrics" عدد 30**. الطلب محدود الحجم لكنه جاد تجارياً، ولا سيما أن البحث يرتبط بقرارات نشر باهظة التكلفة.

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

3. نطاق عملي لتدريب الممارسين على الفريق الأحمر للوكلاء

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

الطلب أضيق لكنه ملموس: تحقق عبارة "ai red teaming jobs" عدد 210 عمليات بحث شهرية على Google في الولايات المتحدة، و**"ai red teaming certification" عدد 50**، بينما تحقق كل من "ai red teaming course" و**"ai red teaming training"** عدد 40. وتدل أسئلة البحث المتكررة عن الأمثلة والأدوات والوظائف والاعتماد على فجوة في المهارات، لا في البرمجيات وحدها.

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

الحدود والخلاصة الصريحة

لا يثبت التقييم أن الوكيل آمن. بل يخبرك بما فعله نظام واحد بإعداداته المحددة عبر مجموعة معلنة من المهام ومنظومة التشغيل والبيئة والميزانية. وإذا تغيّرت تلك الظروف فقد تتغيّر النتيجة.

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

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

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

ما المقصود بالفريق الأحمر في الذكاء الاصطناعي؟

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

ما مثال الفريق الأحمر في الذكاء الاصطناعي؟

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

هل سيحل الذكاء الاصطناعي محل الفريق الأحمر؟

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

ما أفضل ذكاء اصطناعي للفريق الأحمر؟

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

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