Botinok: وكيل ذكاء اصطناعي عبر سطر الأوامر للخوادم يعمل محليًا ولا يتطلب ذاكرة كبيرة

Botinok وكيل ذكاء اصطناعي يعمل عبر سطر الأوامر، موجَّه لمن يتعامل مع خوادم Linux عبر SSH ولا يريد نقل المهام بين الطرفية ودردشة الويب. صُمّم المشروع أداةً محلية بلا عمليات خلفية زائدة: تشغّله، وتعالج المشكلة، وتُجري التعديل، ثم تغلقه.

من أين جاءت الفكرة

لا تبدأ قصة Botinok من موجة الاهتمام بالوكلاء الذكيين، بل من معاناة مألوفة لمسؤول الأنظمة. على مدى خمسة عشر عامًا من العمل مع خوادم Linux، تغيّرت الأدوات المحيطة بالبنية التحتية مرات عدة: حلّ Ansible محل الإعدادات اليدوية، ثم جاء Kubernetes، ثم عاد بعض الفرق إلى حلول أبسط مثل docker-compose. لكن المهام نفسها لم تختفِ: لا بد من تحليل السجلات، وتعديل ملفات الإعداد، وتشخيص أعطال الخدمات، والاحتفاظ بحالة الجهاز الحالية في الذاكرة.

أضافت نماذج LLM طبقة مفيدة إلى هذا الروتين، إذ يمكن سؤال النموذج سريعًا عن nginx أو systemd أو خطأ ظهر في السجلات والحصول على إرشاد واضح. لكن المشكلة في مكان آخر: الطرفية والدردشة منفصلتان. فكل طلب يتحول إلى نسخ مقاطع وشرح للسياق ثم عودة إلى سطر الأوامر. نشأت فكرة Botinok من الرغبة في إزالة هذه الفجوة: وضع النموذج مباشرة داخل سيناريو SSH، ومنحه إمكانية الوصول إلى سياق العمل، دون اشتراط بطاقة رسوميات قوية أو بنية تحتية ثقيلة.

لماذا ليس OpenClaw

قبل كتابة أداته الخاصة، جرّب المؤلف OpenClaw، وهو وكيل ذكاء اصطناعي ذاتي الاستضافة (self-hosted) من الجيل الجديد، مصمَّم للعمل المستمر وأتمتة المهام اليومية. بدا كل شيء مقنعًا على الورق: وكيل بالكثير من التكاملات ومنصات المراسلة وبنية متعددة الطبقات ووضع تشغيل 24/7. لكن لمهام من نوع «ادخل إلى الخادم، افهم ما تعطّل، أصلحه واخرج»، تبيّن أن هذا النهج ثقيل أكثر من اللازم وبعيد عن سير عمل المسؤول الفعلي.

• مخطط معقد متعدد الطبقات لمهام SSH بسيطة
• تركيز على البريد والتقويم والحجوزات بدلًا من السجلات وsystemd وDocker وnginx
• عملية daemon تعمل باستمرار وتستهلك الموارد حتى في وضع الخمول
• واجهة عبر تطبيق مراسلة، بينما يحتاج المسؤول إلى الطرفية

«Botinok ليس خدمة خلفية ولا عملية تبقى معلّقة باستمرار. إنه تطبيق

عادي: تشغّله، وتعمل، ثم تغلقه.»

أداة لا خدمة

هنا يظهر الفارق الرئيسي في المشروع. لم يُصمَّم Botinok مساعدًا رقميًا شاملًا، بل أداة تطبيقية لبيئة محددة هي الطرفية وSSH. فهو لا يتطلب خادم ويب ولا خدمة نظام ولا عملية تعمل باستمرار. يقترب هذا النمط من طريقة استخدام المطورين لـ Cursor أو Windsurf داخل IDE: تفتح مساحة العمل، وتمنح النموذج السياق، وتنفّذ المهمة، وتنهي الجلسة. غير أن مساحة العمل هنا هي الخادم البعيد وحالته الراهنة.

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

ماذا يعني هذا

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