كل فريق هندسي يعرف هذه الطقوس، ولم تكن Rescale استثناءً. تفشل مجموعة اختبارات ليلية، فيسحب مهندس المناوبة السجلات، ويصنّف السبب الجذري، ويوجهه إلى الفريق المناسب، ليعيد العملية نفسها في صباح اليوم التالي. وعند هذا الحجم، عبر الخدمات الموزعة وعشرات المستودعات، تتحول هذه الطقوس إلى وظيفة بدوام كامل تختبئ داخل دورة مناوبة.
Rescale هي منصة الهندسة الرقمية المبنية لعصر الذكاء الاصطناعي. تستخدم فرق البحث والتطوير والهندسة في قطاعات الطيران والسيارات والطاقة وعلوم الحياة وأشباه الموصلات والتصنيع منصة Rescale لتسريع الابتكار، من خلال الجمع بين الحوسبة عالية الأداء الذكية (HPC) والنمذجة والمحاكاة المتقدمة والهندسة الرقمية الوكيلية وفيزياء الذكاء الاصطناعي على منصة واحدة.
وإلى جانب كتابة الشيفرة، تستخدم Rescale الذكاء الاصطناعي عبر دورة الحياة الهندسية بأكملها، من التخطيط والتصميم مرورًا بالتنفيذ والاختبار والمراجعة والتشغيل، مع إبقاء المهندسين مسؤولين عن النتيجة. يمكن للذكاء الاصطناعي الاقتراح والتنفيذ، لكن البشر هم من يحددون النطاق ويتحققون من العمل ويوافقون على تغييرات الإنتاج. وبهذا يستطيع المهندسون التركيز على المعمارية والحكم على المنتج والسياق اللازم لتشغيل الأنظمة الموزعة المعقدة.
في هذه التدوينة، نعرض كيف استخدمت Rescale إطار عمل AI-Driven Development Lifecycle (AI-DLC) على AWS لبناء وكيل فرز ذكي. انتقل الفريق من تعريف المشكلة إلى النشر في بيئة الاختبار المسبق خلال خمسة أيام، وإلى الإنتاج خلال أسابيع. تغطي التدوينة أيضًا كيف توسّع Rescale في تطبيق AI-DLC عبر مؤسستها الهندسية.
التحدي
مع نمو منصة Rescale، ازداد أيضًا العبء التشغيلي اللازم لإبقائها تعمل. كان المهندسون يقضون وقتًا كبيرًا في مهمة متكررة لكنها بالغة الأهمية: تصنيف حالات فشل الاختبارات الآلية الشاملة من طرف إلى طرف. تُشغَّل مئات حالات الاختبار في المجموعة، وعند ظهور إخفاقات، كان لا بد من تصنيف كل تنبيه وتقرير خطأ وتصعيد وترتيب أولوياته وتوجيهه إلى الفريق المناسب. وبعد التوجيه، كان على المهندسين جمع الأدلة من عدة أنظمة تسجيل ومراقبة، إضافة إلى عدة مستودعات مصدرية، قبل أن يبدأ تصحيح الأخطاء أصلًا. وكان نجاح الاختبارات الشاملة شرطًا لنشر الخدمات إلى الإنتاج، وبالتالي كان تصحيح هذه الأعطال في المسار الحرج للوصول بالتغييرات الجديدة إلى الإنتاج.
في سير العمل اليدوي، كان المهندسون ينتقلون من تقرير الاختبار إلى السجلات والأنماط التاريخية وشيفرة المصدر لتصنيف الإخفاقات وتحديد الفريق المالك المحتمل. ولأن اختبارات التكامل هذه تشترط قبل الإصدارات الأسبوعية للإنتاج، كان الإخفاق غير المحلول قد يستلزم تنسيقًا يمتد لساعات بين عدة فرق قبل السماح بمتابعة النشر.
كان لدى الفريق فكرة واضحة عن شكل الحل: وكيل ذكي قادر على تصنيف المشكلات وتوجيهها تلقائيًا. وكان ما يبحثون عنه هو طريقة منظمة للانتقال من هذا الفهم إلى نظام عامل في الإنتاج، ببنية كافية لتوسيع هذا النهج لاحقًا إلى حالات استخدام أخرى.
لماذا اختارت Rescale إطار AI-DLC
كان وكيل الفرز لدى Rescale مشكلة محددة النطاق بجدول زمني ضيق. احتاج الفريق إلى منهجية تطوير قادرة على السير وفق هذا الإيقاع دون إغفال القرارات المعمارية التي تحدد ما إذا كان النظام سيعمل في الإنتاج.
إن إطار عمل AI-Driven Development Lifecycle (AI-DLC) هو منهجية مفتوحة المصدر تتمحور حول الذكاء الاصطناعي لتطوير البرمجيات، مبنية على فكرتين:
- الذكاء الاصطناعي ينفّذ والبشر يقررون: يولّد الذكاء الاصطناعي خطط العمل ويكتب الشيفرة ويقترح المعمارية، لكنه يبرز نقاط القرار ويطرح أسئلة توضيحية بدل التخمين. ويتحقق البشر ويوجهون العملية في كل خطوة.
- جلسات الفريق تحلّ محل التسليمات غير المتزامنة: بدلًا من أن يبني شخص واحد بمفرده ثم يطلب المراجعة لاحقًا، يستخدم AI-DLC جلسات جماعية مركزة: Mob Elaboration (تحديد المتطلبات معًا) وMob Construction (البناء معًا بينما يتولى الذكاء الاصطناعي التنفيذ). وتُتخذ القرارات في الوقت الفعلي.
ناسب AI-DLC الموقف لأن الجزء الصعب لم يكن كتابة الشيفرة، بل التأكد من أن الذكاء الاصطناعي يفهم ما أراد الفريق بناءه. في الجلسات الجماعية، أجاب مهندسو Rescale معًا على أسئلة الذكاء الاصطناعي ووافقوا على كل خطة قبل أن ينتقل الذكاء الاصطناعي إلى ما بعدها، فلم يُترك شيء للافتراضات.
نظرة عامة على الحل
يقوم وكيل الفرز لدى Rescale بأتمتة تصنيف وتوجيه إخفاقات الاختبارات الشاملة الليلية من طرف إلى طرف. ويعمل كخطوة ضمن مسار التكامل والتسليم المستمر (CI/CD) القائم لدى Rescale عبر Argo Workflows على Amazon Elastic Kubernetes Service (Amazon EKS). عندما تُنتج مجموعة Playwright الليلية المكونة من مئات حالات الاختبار إخفاقات، يطلق المسار حاوية وكيل الفرز.
ينفّذ الوكيل الخطوات التالية:
- يستدعي Claude Opus 4.8 على Amazon Bedrock لتصنيف كل إخفاق ضمن فئة سبب جذري: مشكلة بنية تحتية، أو خطأ في الشيفرة، أو اختبار متقلب (flaky test)، أو مشكلة في البيئة.
- يسترجع أنماط الإخفاق التاريخية ذات الصلة من قاعدة معرفة لتوفير سياق إضافي.
- يستعلم عن سجلات الحاويات (pod logs) عبر Model Context Protocol (MCP) للحصول على أدلة تشغيلية تدعم التصنيف.
- يولّد تقرير معالجة منظّمًا يتضمن مراجع ملفات محددة وأسماء دوال وإصلاحات موصى بها لمراجعة المهندسين قبل اتخاذ أي إجراء.
يُكمل الوكيل سير العمل هذا في ثوانٍ ويُخرج النتائج مباشرة إلى مسار التقارير القائم لدى الفريق. يوضح المخطط التالي كيف تتناغم هذه المكونات معًا:
الشكل 1: بنية وكيل الفرز الذكي لشركة Rescale، يعمل على Amazon EKS مع استخدام Amazon Bedrock للتصنيف، وقاعدة معرفية لأنماط الفشل التاريخية، واسترجاع السجلات المعتمد على MCP من خلال تكامل Amazon CloudWatch
تجربة ورشة عمل AI-DLC
تم تنظيم التعاون في شكل ورشة عمل حضورية استمرت خمسة أيام. قام مهندسو AWS بتوجيه عملية البناء بينما عمل مهندسو Resale مباشرة على لوحات المفاتيح، متعاونين في البناء في الوقت الفعلي.
مرحلة البدء (الأيام 1–2): من الرؤية إلى المتطلبات المُحقَّقة
بدأ الفريق بتحديد نطاق المتطلبات، وتوثيق النية في وثيقة رؤية ووثيقة بيئة تقنية أرسَتا أساس العمل قبل أن يبدأ أي بناء. بدأت تلك النية كعبارة واحدة: "نريد فرز اختبارات مدعوم بالذكاء الاصطناعي يصنّف الإخفاقات ويوصي بالإصلاحات". وبالعمل التعاوني بصيغة الموب، أجاب الفريق على أكثر من 20 سؤال توضيحي وُلِّدت بواسطة الذكاء الاصطناعي. وأسفر ذلك عن وثيقة متطلبات محدودة النطاق مع تحديد حدود المرحلة 1 صراحةً وتأجيل بنود المرحلة 2. تم دمج خمس قصص مستخدم في أربع وحدات عمل:
- قاعدة معرفية لأنماط الأعطال التاريخية.
- وكيل الفرز الذكي كمحرك التصنيف والمعالجة الأساسي.
- تكامل Argo Workflow للمشغّلات والبنية التحتية والنشر.
- منصّة التقييم لقياس الدقة وبوابة الرجوع (regression gating).
كانت القرارات البشرية هي من حددت الحدود الحرجة: ما ينتمي إلى المرحلة 1 مقابل المرحلة 2، وترتيب الأولويات، والميزات المؤجلة مثل التوليد الآلي لطلبات السحب (PR).
مرحلة البناء (الأيام 2–4): من التصميم المعماري إلى الكود العامل
حدد الفريق عقود الواجهة ومخططات البيانات، وأنجز أسئلة التصميم الوظيفي وغير الوظيفي، واعتمد المعمارية. ظهرت محورتان معماريتان أثناء البناء، وتحقق الفريق من كل محور منهما قبل تغيير المسار.
أولاً، خطط الفريق لاستضافة الوكيل على Amazon Bedrock AgentCore، ثم نقله إلى Amazon EKS، حيث يشغّل Rescale بالفعل مسار CI/CD الخاص به عبر Argo Workflows. إبقاء الوكيل في المجموعة الحالية يعني عدم وجود بيئة تشغيل جديدة لإدارتها ومسارًا مباشرًا للتفعيل من Argo. ثانيًا، في البناء المبكر كان الوكيل يسحب أدلة السجلات من خدمة تسجيل تابعة لطرف ثالث عبر MCP. نقل الفريق استرجاع السجلات إلى Amazon CloudWatch، مما بسّط سلسلة الاعتماديات. ظل نمط MCP كما هو. تغيّر فقط المصدر خلفه. ولأن AI-DLC يحفظ المتطلبات وقرارات التصميم في مستندات مشتركة، حدّثها الفريق في مكانها وواصل البناء دون فقدان السياق.
تم بناء الوكيل باستخدام Strands SDK، ويدعم تحليل الأعطال المتزامن بمخرجات مهيكلة بصيغتي JSON و HTML، وهو مُحاوَط (containerized) على Amazon EKS.
بحلول اليوم 4، كان خط المعالجة الكامل يعمل في بيئة التدريب (staging): تشغيل سير عمل Argo، وحاوية (pod) وكيل الفرز، واستعلام سجلات MCP، واسترجاع قاعدة المعرفة، ومخرجات الفرز المهيكلة.
مرحلة العمليات (اليوم 5): التقييم والتسليم
بنى الفريق إطار تقييم قائمًا على PyTest مع وضعي اختبار مباشر ومحاكى، مؤسسين خط أساس أوليًا لتوافق التصنيف لقياس الأداء against الوكيل والتحسين منه. تم عرض الوكيل مباشرة أمام المدير التقني ونائب رئيس الهندسة في Rescale، حيث صنّف بشكل صحيح كل من عطلًا في البنية التحتية وخطأً حقيقيًا في الكود مع توصيات محددة للإصلاح على مستوى الملفات.
كيف وسّع AI-DLC الصرامة لتناسب التعقيد
ليست كل وحدة عمل تحظى بالمعاملة نفسها. قاعدة المعرفة احتاجت تصميمًا بسيطًا ونُشرت باستخدام Terraform في غضون ساعات. أمّا وكيل الفرز (Triage Agent) فقد حصل على صرامة كاملة: مراجعة معمارية، وعقود واجهات، و12 سؤالًا تصميميًا، ومراجعة كود تكرارية. وركز تكامل Argo على عقود البنية التحتية وIAM. واستخدمت منصة التقييم (Evaluation Harness) تصميمًا خفيفًا لكن تنفيذًا ثقيلًا. لقد طابق AI-DLC العمق مع التعقيد تلقائيًا.
بحلول نهاية اليوم 5، كان الوكيل يعمل مباشرة في بيئة الاختبار التجريبية، يعالج إخفاقات اختبار حقيقية بمستوى دقة مقاسbaseline واضح ومسار واضح نحو الإنتاج.
نتائج الإنتاج
يعمل وكيل الفرز في الإنتاج منذ ورشة العمل. فهو يصنّف تلقائيًا حالات فشل اختبارات النهاية إلى النهاية الليلية، ليحلّ الفرز اليدوي الأول بمرحلة أولى آلية يتحقق منها المهندسون. ولكل حالة فشل، يُنشئ الوكيل تقرير إصلاح منظّمًا يتضمن خطوات تالية قابلة للتنفيذ بدلًا من السجلات الخام. ارتفعت نسبة توافق تصنيف الوكيل مع الفرز البشري من 44% عند النشر الأولي إلى 68% اليوم. ويواصل التحسن مع استمرار الفريق في تطوير مجموعة البيانات الذهبية وهندسة الأوامر التوجيهية.
منذ دخول وكيل الفرز حيز الإنتاج، قاس الفريق انخفاضًا بنسبة 20% في الوقت الذي يُعطَّل فيه نشر الإنتاج أثناء تحليل إخفاقات الاختبارات. ولأن هذه الاختبارات تُوجّب إصدارات Rescale الأسبوعية للإنتاج، فإن هذا الانخفاض ينعكس مباشرة على سرعة وصول التغييرات إلى الإنتاج. كما يقضي المهندسون وقتًا أقل من نوبات المناوبة على المكالمات في التصنيف المتكرر.
الحياة بعد الورشة: من وكلاء فرديين إلى ممارسة تقودها الذكاء الاصطناعي
قدّم الورشة العملية وكيل إنتاجياً واحداً، لكن أثرها الأكبر كان على الطريقة التي تتعامل بها Rescale مع الأعمال الهندسية. وكيل الفرز هو جزء من دفع أوسع لدى Rescale لتقديم قدرات الهندسة الرقمية لعصر الذكاء الاصطناعي. داخلياً، تطبّق Rescale هذه الفوائد نفسها المتحققة من الذكاء الاصطناعي عبر مؤسستها الهندسية الخاصة. ومنح الذكاء الاصطناعي الموجَّه بدورة الحياة (AI-DLC) مهندسي Rescale طريقة منظمة وقابلة للتكرار لوضع هذا التوجه موضع التنفيذ.
توسيع نطاق AI-DLC في المؤسسة
تقوم Rescale بتقييم AI-DLC داخلي مركز التميزمجموعة صغيرة تُدوّن أفضل الممارسات وتساعد الفرق الأخرى على تبنّي المنهجية بشكل مستقل.
المهندسون الذين شاركوا يطبقون بالفعل ما تعلموه. وأشار أحد المهندسين إلى أن العملية "ستصبح جزءًا من سير عملي المستقبلي"، ليس فقط لبناء الوكلاء، بل لأي عمل تطويري معقد يمكن أن تساهم فيه الذكاء الاصطناعي.
تطوير أوسع قائم على الذكاء الاصطناعي
تدمج Rescale الآن AI-DLC في دورة تطوير البرمجيات القياسية لمنتجات المحاكاة الهندسية الجديدة. يجلب هذا الإطار الخبرة في مجال المحاكاة ومتطلبات المنتج وبنية المنصة والتحقق والتشغيل في عملية تصميم واحدة منظمة. تحل الفرق الأسئلة الرئيسية مبكرًا، وتوثق القرارات المُراجَعة في مواصفات قابلة للتنفيذ، وتمنح وكلاء البرمجة أعمالًا مركزة مع معايير قبول واضحة. وهذا يقصّر المسار من فكرة المنتج إلى التنفيذ المتحقق منه مع بقاء المهندسين مسؤولين عن صحة المنتج.
وقد عُيِّن النهج نفسه بالفعل في أعمال تمكين المنتجات على المنصة وفي أنظمة الوكلاء:
- إدارة كتالوج تطبيقات محاكاة HPC.
- تتبع ثغرات الحاويات ومعالجتها لتلبية متطلبات الامتثال الحكومية.
- وكلاء برمجة سحابيون قائمون على سير العمل.
الخلاصة
بالنسبة لوكيل الفرز، لم يكن الناتج الأكثر فائدة من AI-DLC هو الشيفرة البرمجية نفسها، بل كان المسار المنظم من فكرة أولية إلى تصميم نظام مُراجَع: أسئلة توضيحية، ومتطلبات محددة النطاق، ومعايير تقييم.
منحت تلك المواصفات وكلاء البرمجة مشكلة أضيق وأكثر تحديدًا لحلها. فبدلاً من مطالبة الوكيل باستنتاج البنية أثناء تنفيذها، تمكن الفريق من استخدام الوكلاء في بناء مركز استنادًا إلى قرارات كان البشر قد راجعوها مسبقًا. وكانت النتيجة ناتجًا أكثر تركيزًا وقابلية للمراجعة وأسهل في التكامل والتحسين. بالنسبة إلى Rescale، هذا هو النمط القابل للتكرار: استخدم AI-DLC لهيكلة حوار التصميم، ثم حوّل القرارات إلى مواصفة، ثم استخدم وكلاء البرمجة لتسريع التنفيذ.
الخلاصات الرئيسية
- ابدأ بمشكلة حقيقية. نجح وكيل الفرز في Rescale لأنه حل تحديًا هندسيًا. المشكلة هي التي قادت الحل، لا العكس.
- الإشراف البشري يسرّع ولا يُبطئ. كل تحوّل في البنية حسّن النظام جاء من التحقق البشري لمقترحات الذكاء الاصطناعي. وصيغة الموب حيث يولّد الذكاء الاصطناعي ويحقق البشر أسرع من العمل المنفرد.
- وفّرت حزمة AWS كل طبقة يحتاجها الوكيل. وفّرت Amazon Bedrock الوصول إلى النماذج الأساسية للتصنيف في بيئة كانت Rescale تستخدمها بالفعل، فتمكن الفريق من بناء سير عمل الفرز دون تحمّل أعباء إضافية لبنية النماذج التحتية. وقد وفّرت حزمة Strands SDK إطار الوكيل، واستضافت Amazon EKS الوكيل المُحوّل إلى حاويات ضمن خط أنابيب Rescale القائم.
ابدأ مع AI-DLC
- افهم المنهجية: اقرأ مدونة مقدمة AI-DLC و الاستكشاف المعمّق لسير العمل التكيفي.
- استكشف الخدمة: تعرّف على المزيد حول Amazon Bedrock.
- جرّبها الآن: انسخ قواعد سير عمل AI-DLC مفتوحة المصدر من github.com/awslabs/aidlc-workflows.
- شاهدها عمليًا: تتبّع بناء عملي بـ AI-DLC باستخدام Amazon Q Developer.
- تواصل: اتصل بفريق حسابك في AWS لمناقشة كيفية تكييف AI-DLC مع سير العمل الهندسي المحدد لمؤسستك.