Haystack والوكلاء المتعددون: كيف تتوقف عن المناوبات الليلية وتعود إلى حياتك
قدّم مطورو Haystack بنية لنظام متعدد الوكلاء يتولى الجزء الشاق من عمل مهندس SRE. فبدلاً من روبوت واحد بطيء الحركة، يعمل هنا فريق كامل: وكيل يراقب الشذوذات، وآخر يتعمق في السجلات، وثالث يطابق المقاييس، ورابع يكتب التقرير النهائي. وهذا انتقال نوعي من أنظمة RAG البسيطة إلى سير عمل مستقل في البنية التحتية الحرجة. لا تكمن القيمة الأساسية هنا في النموذج نفسه، بل في التنسيق (orchestration) والتحكم في الحالات. وهذا ما يحوّل الذكاء الاصطناعي من محاور طريف إلى زميل موثوق لا يخطئ في الثالثة فجراً.
معالج بواسطة الذكاء الاصطناعي من MarkTechPost؛ بتحرير Hamidun News
تخيّلوا الساعة الثالثة فجراً، وصوت جهاز النداء (pager) الحاد يعلن أن بيئة الإنتاج لديكم قررت أخذ إجازة غير مخطط لها. يعرف كل مهندس SRE هذا الشعور: عليك أن تتابع Grafana، وتبحث في السجلات عبر grep في Kibana، وتحاول في الوقت نفسه ألا تغفو على لوحة المفاتيح. لفترة طويلة كنا نأمل أن تخلّصنا النماذج اللغوية الكبيرة من هذا الروتين، لكن الأمر عملياً اصطدم بالهلوسات وعدم القدرة على التعامل مع السياقات المعقدة. غير أن فريق Haystack قرر إثبات أن زمن الأمثلة «اللعبة» قد انتهى، وقدّم تصوراً لنظام متعدد الوكلاء قادر على إغلاق دورة التحقيق في الحوادث من البداية إلى النهاية.
يقوم هذا التوجه على الانتقال من المساعدين المتجانسين (monolithic) إلى وكلاء متخصصين. في السابق كنا نحاول تغذية النموذج بكل السجلات دفعة واحدة وننتظر المعجزة. أما الآن فيقترح Haystack بنية يمتلك فيها كل وكيل دوراً ضيقاً ومحدداً ومجموعة أدوات واضحة. يعمل أحد الوكلاء بدور «الكاشف»، فيمسح النظام باستمرار بحثاً عن الانحرافات. وحين يحدث خلل، يمرّر المهمة إلى «المحققين». وهؤلاء لا يكتفون بقراءة النص، بل يتفاعلون فعلياً مع واجهات API، ويستخرجون مقاييس محددة، ويصفّون السجلات ويستبعدون الضجيج الزائد الذي يشلّ عادةً عمل الإنسان.
والأكثر إثارة للاهتمام هنا هو التنسيق (orchestration). فـ Haystack يركّز على إدارة الحالات وعلى تدفق تحكم منظّم. وهذا يعني أن الوكلاء لا يتبادلون الرسائل فحسب، بل يعملون ضمن عملية أعمال صارمة. فإذا عثر وكيل على خطأ في قاعدة البيانات من خلال السجلات، فلن يكتفي بالإبلاغ عنه، بل سيبدأ فحص الخدمات المرتبطة به. وهذا يحاكي سلوك المهندس المتمرس الذي يدرك أن جدولاً واحداً متعطلاً ليس سوى قمة جبل الجليد. ويقلّل هذا النهج احتمال أن يفوّت الذكاء الاصطناعي تفصيلاً مهماً أو أن يعلق عند أمر واحد.
ما حاجة الأعمال إلى هذا، بخلاف الرغبة الواضحة في منح المهندسين قسطاً من النوم؟ الجواب في الأرقام. فمتوسط زمن استعادة النظام (MTTR) يعتمد مباشرة على سرعة تحديد موضع المشكلة. ويفعل النظام متعدد الوكلاء ذلك في ثوانٍ، ولا يقدّم في النهاية عبارة من قبيل «يبدو أن كل شيء تعطّل»، بل تقريراً متكاملاً بمستوى بيئة الإنتاج (production-grade) يتضمن تحليلاً للأسباب الجذرية وتسلسلاً زمنياً للأحداث. وبعد أن يهدأ الغبار، يولّد النظام بنفسه مسودة وثيقة post-mortem لا يبقى على الإنسان سوى مراجعتها واعتمادها. وها نحن نرى أخيراً الذكاء الاصطناعي ينشغل بعمل حقيقي، لا بإعادة صياغة مقالات من الإنترنت.
وبالطبع يبرز سؤال مشروع: هل نحن مستعدون لتسليم مفاتيح البنية التحتية إلى مجموعة من السكربتات والشبكة العصبية؟ حتى الآن يقدّم Haystack هذا النظام بوصفه أداة لدعم اتخاذ القرار، لا مسؤول نظام مستقلاً يملك صلاحيات المستخدم الخارق (superuser). لكن اتجاه التطور واضح. نحن نتحرك نحو عالم تصبح فيه إدارة الأنظمة المعقدة مؤتمتة إلى حد يقتصر معه دور الإنسان على الإشراف رفيع المستوى على جيش من المساعدين الافتراضيين. وإذا ساعد ذلك على تفادي سقوط الخدمات الكبرى بسبب خطأ مطبعي واحد في ملف الإعدادات، فأنا معه تماماً.
الخلاصة: عصر روبوتات الدردشة المنفردة في DevOps ينتهي رسمياً، ويفسح المجال لأنظمة منسّقة معقدة. فهل سيتمكن نظام المراقبة لديكم من منافسة فريق من الوكلاء الذين لا ينامون أبداً من حيث السرعة؟
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.