Claude Sonnet وJarvis Pattern: لماذا قد يكفي وكلاء الذكاء الاصطناعي نظام تشغيل

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

يصف صاحب المفهوم، مهندس تقنية المعلومات المعماري Egor Zinoviev، Jarvis Pattern بأنه وكيل شبكي شخصي مخصص لمتخصص بعينه. ولا يعيش هذا الوكيل في المتصفح ولا على الحاسوب المحمول، بل في حاوية (container) خاصة به مع وصول إلى البنية التحتية، ويتصرف باسم الإنسان. وكمثال، يورد الكاتب وكيله umax المتخصص في DevSecOps والمبني على Claude Sonnet، والذي يغطي، بحسب قوله، مجموعة كاملة من المهام المتخصصة: من إعداد RBAC في Kubernetes والعمل مع Vault إلى نشر العناقيد (clusters) وفحص صور Docker وإعداد CI/CD وتحليل الثغرات.

والأطروحة المحورية هي أن الوكيل لا يحتاج إلى مجموعة أدوات مجمّعة مسبقًا: فإذا احتاج إلى استعلام من Prometheus استخدم curl، وإذا أراد تحويل البيانات لجأ إلى jq أو sed أو awk، وإذا لم توجد أداة مناسبة كتبها بنفسه وأضافها إلى بيئة العمل.

ويركّز الكاتب بشكل خاص على الذاكرة. فبرأيه، هي الجزء الوحيد الذي لا يزال حقًا دون حل في معمارية الوكلاء. ويقترح تقسيمها إلى ذاكرة تصريحية وإجرائية وعَرَضية (episodic)، أي الحقائق والتعليمات والخبرة. والأهم ليس التجربة الناجحة وحدها، بل التجربة السلبية أيضًا: معرفة أي مسار أوصل سابقًا إلى طريق مسدود ولماذا. وبدلًا من البحث المتجهي والنماذج الرسومية، يراهن Zinoviev على نظام الملفات وملفات markdown بوصفها خريطة مسارات طبيعية: فالمجلدات تحدد التصنيفات، وأسماء الملفات تشير إلى الاتجاه، ويكون مستند الفهرس نقطة الانطلاق للتعمق في السياق المطلوب. وبالتوازي يعمل Memory Agent منفصل يراجع بعد الجلسة ما ينبغي حفظه وما ينبغي تحديثه وما ينبغي التخلص منه.

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

ويتعلق استنتاج عملي آخر بالبرمجيات: إذا كان الوكيل يعمل عبر API وCLI، فإن المنتجات التي لا تملك API جيدة ستبدأ بالخسارة مهما كانت واجهتها جميلة.

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

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