خمسة أنماط معمارية لا يمكن للذكاء الاصطناعي الوكيلي أن ينجو في بيئة الإنتاج من دونها

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

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

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

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

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

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

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

من المهم فهم السياق الذي ظهر فيه هذا التصنيف. ففي العام الأخير شهدت الصناعة طفرة في أطر عمل الوكلاء، من LangGraph وCrewAI إلى AutoGen من Microsoft وأدوات جديدة من Anthropic. ويقدّم كل منها مقاربته الخاصة لحل المشكلات المذكورة، لكن لا أحد منها حلٌّ سحري. واستخلاص الأنماط على مستوى تجريدي أعلى من الأطر المحددة دليل على أن القطاع بدأ يشكّل لغة هندسية مشتركة للأنظمة الوكيلية، على غرار ما فعلته «عصابة الأربعة» (Gang of Four) في زمنها للبرمجة كائنية التوجه.

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

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