لماذا تتعثر وكلاء الذكاء الاصطناعي من دون سياق للبنية السحابية؟

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

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

ضريبة واجهات برمجة التطبيقات

تحتاج الوكلاء إلى الاستعلام المستمر من واجهات برمجة التطبيقات السحابية كي تستكشف الحالة الحالية. لكن هذا النمط يفرض ما تسميه المادة «ضريبة API»: حدود معدل الطلبات، وفشل سلاسل الاستعلام، وزيادة الكمون والتكلفة، إضافة إلى احتمال التأثير في عمليات حساسة مثل خطوط CI/CD أو التوسع التلقائي عندما تتنافس الأدوات على السعة نفسها.

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

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

من النية المعلنة إلى الواقع التشغيلي

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

وتوضح حالة افتراضية أن أداة مثل Wiz قد تفرض سياسة توافر عالٍ تتطلب عدة مثيلات، بينما يرى الوكيل الذي يعتمد على IaC وحده مثيلاً منفرداً، فلا يدرك المخالفة. ربط هذه البيانات بسياق التطبيق والسياسة يتيح للوكيل تقييم الأثر قبل اقتراح المعالجة.

حلقة تحكم كاملة

تقترح env zero نموذجاً يبدأ بالتقاط النية المعلنة، ثم اكتشاف الحالة الفعلية، ومطابقة الحالتين، وفحص السياسات، واقتراح تغييرات على شكل طلبات دمج للمراجعة والتنفيذ، وأخيراً إجراء فحص جديد للتحقق من زوال الانحراف أو المشكلة. ويمكن أن تصل طبقة البيانات إلى أدوات التنفيذ مثل Terraform وOpenTofu وPulumi.

وتشير الشركة إلى EZ Control بوصفه حلقة تحكم ذاتية تربط الحالة المعلنة بالمكتشفة، وتقترح المعالجة أو تنفذها ضمن ضوابط السياسات، ثم تتحقق من نجاح التغيير. المنتج في مرحلة الوصول المبكر، وتستهدف الشركة إتاحته عموماً بحلول نهاية ديسمبر 2026؛ لذلك فإن بعض عناصر الحلقة الموصوفة ما زالت قدرات تعمل env zero على بنائها.

لماذا يهم هذا النموذج؟

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

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