Every few months, the industry mints a new term for software that supposedly thinks on its own. Right now that word is "

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

حان الوقت للتوقف عن قراءة قوائم الميزات والبدء في قياس القدرات.

مشكلة المسمى

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

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

خمسة اختبارات للقدرات تهم حقاً

أقوم بتقييم كل ادعاء حول القدرات الوكيلة مقابل خمس قدرات محددة. لكل منها، أطرح سؤال فرز (triage) بسيط: هل السلوك موثق، أم تم التحقق منه في مشروع تجريبي، أم لا يزال غير معروف؟ "غير معروف" هو الوضع الافتراضي. يقع عبء الإثبات على المنتج لإثبات خلاف ذلك.

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

الأدوات. هل يعمل على أنظمة حقيقية ضمن نطاق محدد؟ استدعاء API وهمي (mock API) في عرض توضيحي مصقول أمر سهل. أما المصادقة على نظام CRM الخاص بالإنتاج باستخدام صلاحيات الحد الأدنى من الامتيازات (least-privilege credentials)، وكتابة سجل، وتسجيل المعاملة، فهو أمر صعب. أنت بحاجة إلى معرفة الأنظمة التي يلمسها بالضبط، والمفاتيح التي يحملها، وأين ينتهي نطاق التأثير (blast radius). يجب أن يكون النطاق محدوداً. إذا كان للوكيل صلاحية الكتابة في بيئة الإنتاج بشكل افتراضي، فأنت لا تملك وكيلاً، بل تملك عبئاً ومخاطرة.

التصحيح. هل يغير خطوته التالية بعد الفشل؟ هنا تموت معظم النماذج الأولية. عندما تعيد الخطوة الثالثة خطأ 503 أو عدم تطابق في المخطط (schema mismatch)، هل يدخل الوكيل في حلقة مفرغة، أم يهلوِس برسالة نجاح، أم يعدل مساره؟ التصحيح الحقيقي يعني ملاحظة الفشل، وإعادة تخطيط ما تبقى من سير العمل، وتنفيذ مسار جديد دون التخلي عن القيود. حلقة إعادة المحاولة المغلفة بالتفاؤل ليست تصحيحاً.

السياق. هل يحافظ على القيود نشطة عبر كل خطوة؟ الذاكرة ليست كافية. إذا وضعت الخطوة الأولى قاعدة صارمة مثل "عدم تجاوز ميزانية قدرها خمسمائة دولار" أو "استبعاد بيانات العملاء في الاتحاد الأوروبي"، فلا يمكن للخطوة السابعة تجاهل هذا السقف بسبب تغير سياق الأمر (prompt context). ينطبق هذا على قواعد الامتثال، ونبرة العلامة التجارية، وهياكل الموافقة، وضوابط الوصول. الحفاظ على السياق هو المكان الذي يجب أن تلتقي فيه النماذج ذات السياق الطويل (long-context models) مع إدارة الحالة الكلاسيكية (classical state management).

الإشراف. هل يمكن للإنسان إيقاف العملية أو استئنافها؟ أنت بحاجة إلى قواطع دائرة (circuit breakers) دقيقة، وليس مجرد مفتاح إيقاف للآلة الافتراضية. هل يمكن لشخص ما فحص الخطة بعد الخطوة الثانية والموافقة على الخطوة الثالثة؟ إذا فشل اعتماد خارجي، هل يمكن للإنسان إصلاحه واستئناف سير العمل دون فقدان الحالة؟ الإشراف ليس سجل تدقيق تقرأه بعد وقوع الكارثة، بل هو آلية حية للتدخل.

الأدلة تتفوق على مربعات الاختيار

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

تستبدل بطاقة الأدلة مربع الاختيار بالتحديد. وتبدو كما يلي:

• القدرة: التصحيح
• الادعاء: يراجع نفسه بعد فشل الاختبار
• الدليل: قيد الاختبار في بيئة محكومة
• المسؤول: فريق تجربة المطورين
• التوقف في حال: تغيير المراجعة لواجهة معتمدة

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

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

كيفية استجواب ادعاءات الموردين

تقترح OpenAI أن الوكلاء يتطلبون خمسة مكونات: النماذج (models)، والأدوات (tools)، والتعليمات (instructions)، وحواجز الأمان (guardrails)، والتدخل البشري (human intervention). يمكنك التعامل مع هذه القائمة كمصطلحات لطرح الأسئلة على الموردين دون تبني بنيتهم التحتية المحددة.

اسأل عن النموذج الذي يتولى التخطيط مقابل مجرد التوليد. اسأل عن أذونات الأدوات التي تم برمجتها بشكل ثابت (hardcoded) وتلك الديناميكية. اسأل أين يتم فرض حواجز الأمان، هل هي في طبقة الأوامر (prompt layer) أم في محرك التنسيق (orchestration engine). اسأل عما إذا كان التدخل البشري عبارة عن نقطة تفتيش مدمجة أم مجرد بريد إلكتروني يُرسل بعد وقوع الكارثة (post-mortem) بعد أن يكون الوكيل قد تسبب بالفعل في تخريب قاعدة بياناتك. أنت لا تتسوق من أجل مجموعة أدوات OpenAI، بل تستخدم إطار عملهم لكشف الثغرات في أنظمة الآخرين.

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

قاعدة شراء توفر الميزانية

قاعدتي لتوسيع المشروع التجريبي للوكلاء (agentic pilot) إلى التزام بالإنتاج هي قاعدة بسيطة: أنا لا أزيد النطاق والميزانية إلا عندما تتوفر أدلة على القدرات الحرجة ووجود مسؤول واضح عن حالات الفشل. ليس مجرد شريحة في خارطة طريق، وليس مجرد طابور تذاكر دعم. الدليل يعني سجلات (logs) من بيئتك الخاصة. والمسؤول يعني شخصاً محدداً يتولى مسؤولية التعامل مع نمط الفشل المحدد ذلك.

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

ما يجب تذكره: كلمة "Agentic" هي بمثابة طلقة البداية لتقييمك، وليست خط النهاية. تعامل معها كمحفز لطرح أسئلة أصعب، وإجراء تجارب أكثر صرامة، والمطالبة بأدلة تهمك داخل مؤسستك. إذا لم يتمكن المنتج من اجتياز اختبارات القدرات الخمسة في ميدانك، ومع حالات الفشل الخاصة بك، فهو ليس "Agentic" حقاً، بل هو مجرد عرض توضيحي (demo) آخر.

المصدر: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h

مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi