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

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

جهاز النداء هو مجرد البداية

عندما يتعطل نظام الإنتاج، نادراً ما يكون التنبيه هو الجزء الصعب.

يمكن لـ Grafana أن يخبرك بأن هناك شيئاً ما معطل. ويمكن للسجلات أن تخبرك بفشل شيء ما. ويمكن للوحة التحكم أن تومض باللون الأحمر بصوت عالٍ بما يكفي لإيقاظ شخص ما في الساعة 2 صباحاً.

ولكن بعد ذلك، يبدأ العمل الحقيقي.

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

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

وهو أيضاً المكان الذي وجد فيه Dawood Khan فكرة Kronos.

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

في حدث Grafana في حيدر آباد، أصبحت المشكلة أكثر وضوحاً. كان المهندسون يصفون نفس النمط: يتعطل النظام، ويتلقى شخص ما المكالمة، ثم يبدأ الفريق العمل المعتاد لتتبع الفشل يدوياً.

كان Quackathon هو اللحظة المناسبة لبناء شيء مختلف. تم بناء Kronos بواسطة WhyVenv، وحصل على المركز الثاني في Quackathon، متميزاً في تحدي Track 01: Software - The Sentient Workspace لتحويل الاستجابة لحوادث الإنتاج إلى سير عمل قائم على الوكلاء.

ما الذي بنته WhyVenv

كان مشروع WhyVenv هو Kronos، وهو وكيل مستقل للاستجابة للحوادث تم بناؤه لمسار Sentient Workspace في Quackathon.

كانت الفكرة مباشرة، ولكنها طموحة:

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

في بعض الأحيان يعني ذلك فتح مشكلة على GitHub.

وفي أحيان أخرى، وبناءً على خطورة المشكلة، يعني ذلك محاولة الإصلاح.

الهدف ليس مجرد إخطار المهندس بأن الإنتاج معطل. الهدف هو منح المهندس بداية سريعة في العمل الذي يتبع التنبيه عادةً.

على حد تعبير Dawood خلال المقابلة، سهلت تنبيهات Grafana معرفة متى كان هناك شيء معطل. كانت المشكلة تكمن في كل ما يلي ذلك: العثور على سبب المشكلة، ومكان وجود الخلل، والإجراء الذي يجب على الفريق اتخاذه.

تم بناء Kronos لأتمتة تلك الطبقة الوسطى.

الرؤية الهندسية وراء Kronos

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

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

لقد كان مرحلة الاسترجاع.

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

هذا الاختيار مهم.

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

تم تصميم Kronos بناءً على هذه الغريزة نفسها.

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

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

بناء بيئة المراقبة باستخدام Enter Pro

كان على Kronos العمل عبر أدوات لم يستخدمها الفريق بعمق من قبل.

Grafana. Prometheus. Loki. لوحات التحكم. السجلات. المقاييس. التنبيهات.

بالنسبة لفريق الهاكاثون، يعد هذا الكثير من البنية التحتية التي يجب فهمها قبل أن يبدأ المنتج الفعلي في العمل.

هنا أصبح Enter Pro مفيداً لـ WhyVenv.

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

برزت لحظة واحدة بشكل خاص.

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

عندما جربوا Enter Pro، ساعدهم في تحديد السبب الفعلي بشكل مباشر أكثر.

هذا هو نوع اللحظات المهمة في سباق البناء. ليست إجابة عرض توضيحي منمقة. ولا اقتراحاً عاماً. بل دفعة ملموسة لتجاوز عقبة حقيقية.

بالنسبة لـ WhyVenv، لم يكن Enter Pro مجرد مكان لإنشاء الكود. بل كان وسيلة للتفكير عبر أنظمة غير مألوفة بسرعة كافية لمواصلة البناء.

يومان من التركيز

كان Dawood قد خطط للمشروع قبل أن يبدأ الفريق التطوير الجدي.

كان يعرف ما يريدون بناءه. وكان قد فكر في البنية الأساسية. وكان لديه تصور تقريبي لكيفية تقسيم العمل.

ثم سيطر إيقاع الهاكاثون الفعلي.

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

بدأت البنية بسيطة:

تقرير التعطل -> الكود ذي الصلة -> تشخيص LLM -> مشكلة أو إصلاح.

ثم أصبح كل جزء أكثر دقة مع بناء الفريق.

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

ما الذي يوحي به Kronos حول وكلاء الذكاء الاصطناعي

Kronos ليس برنامج دردشة آلياً يجلس بجانب قاعدة الكود.

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

هذا التمييز مهم.

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

هذه غريزة ناضجة لشخص يبني باستخدام الذكاء الاصطناعي في عام 2026.

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

يشير Kronos، حتى كشروع هاكاثون، نحو هذا السؤال.

ماذا بعد

لا يزال لدى المشروع أسئلة للإجابة عليها قبل أن يصبح جاهزاً للإنتاج:

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

هذه ليست أسئلة صغيرة. إنها بالضبط الأسئلة التي تجعل Kronos جديراً بالاهتمام.

لأن حوادث الإنتاج لن تختفي. السؤال الوحيد هو ما إذا كان يجب أن تبدأ كل استجابة بحالة ذعر يدوي.

يتصور Kronos خطوة أولى مختلفة: خطوة يمكن للنظام الذي يرى الفشل أن يبدأ أيضاً في فهمه.

هذا هو ما وجد Enter لدعمه.

ليس فقط كوداً أسرع. بل حركة أسرع من نقطة ألم حقيقية إلى منتج يعمل.

وبالنسبة لـ WhyVenv، كانت تلك الحركة كافية لتحويل نمط هندسي مؤلم إلى أحد المشاريع الفائزة في Quackathon.

استكشف Kronos.

هذه القصة هي جزء من سلسلة Quackathon Builder Series، حيث نتناول مشروعاً تلو الآخر لفهم ما صنعه المطورون باستخدام Enter Pro، ولماذا بنوه، وما يخبرنا به عملهم عن مستقبل إنشاء البرمجيات المدعومة بالذكاء الاصطناعي. تابعونا.