
ليس مجرد عرض توضيحي. وليس إثباتاً لمفهوم. هذا هو الإعداد الذي أستخدمه كل يوم. إنه يكتب مقالات مدونتي،، ويجيب على أسئلتي المهنية. لديه ذاكرة تحتفظ بالمعلومات عبر الجلسات. يبحث في الويب. ويتحدث معي على تيليجرام (Telegram).
يكلف أقل من شطيرة فلافل في الغرب. لنقل ثمانية يورو. أو تسعة دولارات.
وعندما أتوقف عن التحدث إليه، يقوم بإيقاف تشغيل نفسه.

لم أجلس وأصمم هذه البنية المعمارية على سبورة بيضاء. بل وصلت إليها من خلال حل مشكلة تلو الأخرى.
المشكلة الأولى كانت تشغيل هيرميس (Hermes) على الإطلاق. لم أكن مستعداً لمنح وكيل ذكاء اصطناعي صلاحية الوصول (shell) على هذا الجهاز. لذا قمت بتشغيله في حاوية (container). حلّ العزل المشكلة الأمنية ولكنه خلق مشكلة جديدة. تحتاج الحاويات إلى مضيف. كان يجب أن يظل حاسوبي المحمول قيد التشغيل. كان ذلك جيداً لفترة ما بعد الظهيرة. لكنه لم يكن جيداً طوال الليل.
كان الحل الواضح هو استخدام جهاز افتراضي سحابي (cloud VM). اخترت AWS EC2 لأن مثيل t2.micro كان أرخص من أي خادم استضافة مُدار تمكنت من العثور عليه. لا إضافات. لا يوجد عنوان IP مرن (Elastic IP). مجرد جهاز.
ثم جاءت مشكلة النماذج اللغوية الكبيرة (LLM). بدأت أصطدم بحدود معدل الاستخدام (rate limits) من مزودي الخدمة المعتادين. لا أريد أن يتم تقييدي في منتصف محادثة بينما يكون الوكيل في منتصف مهمة متعددة الخطوات. بحثت، واختبرت، واستقر بي المطاف على ديب سيك (DeepSeek). نموذج V4 Pro الخاص بهم يضاهي مستوى تفكير GPT-4 بجزء بسيط من التكلفة وبدون أي احتكاك بحدود معدل الاستخدام لاستخدامي. هذا التبديل الوحيد فتح الباب للنمط بأكمله. حوسبة رخيصة، واستدلال رخيص.
جاءت الواجهة بعد ذلك. قمت بتوصيل هيرميس بتيليجرام باستخدام رمز بوت مجاني. الآن يمكنني مراسلة وكيلي من أي مكان. لا توجد شاشة طرفية (terminal). لا يوجد SSH. مجرد دردشة.
عند هذه النقطة، كانت الحزمة تعمل. لكنها كانت تستنزف الأموال أيضاً وأنا نائم. تشغيل مثيل t2.micro لمدة 24 ساعة يومياً، 30 يوماً في الشهر، بالإضافة إلى حجم تخزين EBS. هذا يكلف حوالي عشرة دولارات قبل أن ترسل رسالة واحدة. كنت نشطاً لمدة أربع أو خمس ساعات فقط في اليوم. والباقي كان إهداراً.
لذلك قمت ببناء نظام الإغلاق التلقائي.
تتكون الحزمة من أربعة أجزاء متحركة.

يعمل وكيل هيرميس على مثيل EC2 من نوع t2.micro. إنه يحتفظ بسجل جلساتي، ومهاراتي المخصصة، وذاكرتي الدائمة. لديه حق الوصول إلى الشاشة الطرفية (terminal) الخاصة بي، ونظام الملفات الخاص بي، وحسابي على جيت هب (GitHub)، والويب. يُحكم هذا الوصول من خلال أمان أدوات هيرميس نفسه، وليس من خلال AWS IAM. لا يوجد دور IAM مرتبط بهذا المثيل.
تدير دالتان من AWS Lambda دورة حياة المثيل. وتعملان خلف عنوان Function URL واحد يقبل هيكل JSON مع حقل action. أرسل {"action": "stop"} وتقوم دالة Lambda باستدعاء واجهة برمجة تطبيقات StopInstances في EC2 ضد هذا المثيل بالذات. أرسل {"action": "start"} وتقوم بتشغيله مرة أخرى. دور IAM الخاص بدالة Lambda يمتلك صلاحيتين فقط بالضبط: ec2:StartInstances و ec2:StopInstances. لا يمكن استدعاء أي شيء آخر. لا يمكن الوصول إلى أي شيء آخر.
يتم تشغيل مؤقت systemd كل خمس دقائق على مثيل EC2. يقوم بتشغيل برنامج نصي (bash script) يستعلم عن الطابع الزمني لآخر رسالة عبر جميع قواعد بيانات ملفات تعريف هيرميس. على مرحلتين: أولاً، هل أرسل أي مستخدم رسالة في العشرين دقيقة الماضية؟ ثانياً، هل كان الوكيل نفسه نشطاً؟ بكتابة مخرجات الأدوات، أو الرد، أو تشغيل مهام في الخلفية، في العشرين دقيقة الماضية؟ فقط عندما تعود كلتا المرحلتين بصمت (لا يوجد نشاط)، يقوم البرنامج النصي بإرسال إشعار تيليجرام ثم يستدعي نقطة نهاية إيقاف Lambda.
تدفق بدء التشغيل عبارة عن رابط. أحتفظ به في المفضلة على هاتفي. نقرة واحدة، انتظار لمدة ثلاثين ثانية ريثما يبدأ الجهاز ويتم تهيئة هيرميس، وبعدها أقوم بمراسلة وكيلي على تيليجرام وكأن شيئاً لم يكن.
تدفق الإغلاق عبارة عن إشعار. تصلني رسالة تيليجرام. "إغلاق هيرميس الخامل. لا توجد رسائل منذ 25 دقيقة." يوجد رابط إعادة تشغيل في الرسالة. إذا تجاهلته، يتوقف الجهاز. إذا نقرت عليه، تبدأ الدورة مرة أخرى.
تحتوي معظم الخوادم السحابية على أثر من بيانات الاعتماد. أدوار IAM ذات صلاحيات واسعة. متغيرات بيئة مليئة بمفاتيح الوصول. سلاسل اتصال قواعد البيانات في ملفات التكوين. مفاتيح SSH مشتركة عبر الأجهزة.
هذا الجهاز لا يحتوي على أي من ذلك.

لا يوجد دور IAM. لا يوجد مفتاح وصول أو مفتاح سري لـ AWS في أي مكان على نظام الملفات. لا توجد كلمة مرور لقاعدة البيانات. لا يوجد مفتاح SSH يؤدي إلى أي مكان آخر. مجموعة الأمان (security group) تحتوي على منفذ وارد واحد فقط مفتوح. منفذ SSH. هذا كل شيء. جميع المنافذ الأخرى مغلقة على مستوى جدار حماية AWS.
بيانات الاعتماد الوحيدة الموجودة على هذا الجهاز هي مفاتيح واجهة برمجة التطبيقات (API) لمزودي النماذج اللغوية (LLM). DeepSeek و Kimi و Mistral. وأنا أتعامل معها كما تستحق أن تُعامل. رصيد مدفوع مسبقاً. أرصدة صغيرة. إذا قام شخص ما باختراق هذا الجهاز واستخرج كل مفتاح، فإن نصف قطر الانفجار يُقاس بالفكة. سيستنزفون رصيدي في DeepSeek. سأخسر ربما خمسة دولارات. هذا هو كامل سطح الهجوم.
لا يوجد مسار للتمحور (pivot path). لا يمكنك الانتقال من هذا الجهاز إلى حساب AWS الخاص بي. لا يمكنك الوصول إلى بنيتي التحتية الأخرى. لا يمكنك تصعيد الصلاحيات لأنه لا توجد صلاحيات لتصعيدها. يتحدث الجهاز إلى واجهات برمجة تطبيقات LLM. ويتحدث إلى تيليجرام. ويتحدث إلى دالة Lambda لإيقاف التشغيل. أي شيء آخر محظور.
هذا ليس مجرد موقف نظري. لقد راجعت هذا السيناريو. إذا حصل شخص ما على صلاحيات الجذر (root) على هذا المثيل، فماذا سيمتلك؟ بضعة دولارات من رصيد النماذج اللغوية المدفوع مسبقاً، وسجل محادثة لأسئلتي المهنية ومسودات مدوناتي. الضرر مالي ومقتصر على الرصيد المدفوع مسبقاً. أما التعرض للخصوصية فهو محدود بما اخترت مشاركته مع وكيلي. هذه المقايضة مقبولة بالنسبة لي. قد لا تكون كذلك للجميع. لكنها واقعية وشفافة.
إليك التفصيل الفعلي للتكاليف.

مثيل EC2 t2.micro، التسعير حسب الطلب يبلغ تقريباً 0.0126 دولار للساعة. أستخدمه من أربع إلى خمس ساعات يومياً. هذا يعني 1.50 إلى 1.90 دولار شهرياً للحوسبة. يضيف حجم تخزين EBS gp3 عشرين سنتاً أخرى. بضعة سنتات لعمليات الإدخال والإخراج. لنقل أن جانب EC2 يكلف دولارين.
نموذج DeepSeek V4 Pro. هذا هو نموذجي الرئيسي. أستخدمه لإنشاء المحتوى، ومراجعة الكود، والبحث، ومهام الوكيل متعددة الخطوات. في الشهر النموذجي أنفق ما بين دولارين إلى ثلاثة دولارات على مكالمات واجهة برمجة التطبيقات. أسعارهم رخيصة بشكل استثنائي ولم أصل قط إلى حد معدل الاستخدام.
نموذج Kimi. أحتفظ بملف تعريف منفصل لمهام معينة. تكلفة مماثلة. من دولارين إلى ثلاثة دولارات.
نموذج Mistral Medium. لدي ملف تعريف مُعد، لكن عملياً أستخدم الفئة المجانية ولم أتجاوزها قط.
دالتي Lambda. تعمل دالة البدء مرة أو مرتين يومياً. وتعمل دالة الإيقاف مرة أو مرتين يومياً. معاً تولدان ربما ستين استدعاءً شهرياً. تغطي الفئة المجانية من AWS مليون استدعاء. تكلفتها صفر.
بوت تيليجرام. صفر. رمز البوت المجاني هو كل ما تحتاجه.
المجموع. دولاران للجهاز. خمسة دولارات للنماذج اللغوية. بضعة سنتات لـ EBS وعمليات الإدخال والإخراج. أقل من ثمانية دولارات. أقل من ثمانية يورو. شطيرة الفلافل في روتردام تكلف بين سبعة وتسعة يورو حسب المكان الذي تذهب إليه. حزمة وكيل الذكاء الاصطناعي الخاصة بي تكلف أقل.

يعمل الإغلاق التلقائي بشكل جيد. لكنه ليس فورياً. هناك حد أقصى للخمول يبلغ عشرين دقيقة قبل توقف الجهاز. هذا الحد موجود لسبب وجيه. إذا كان الوكيل في منتصف مهمة، عملية بناء طويلة (build)، دورة بحث متعددة الخطوات، وكيل فرعي يعالج الكود، فإن فحص النشاط الكلي يمنع الإغلاق. يتوقف الجهاز فقط عندما أصمت أنا والوكيل معاً لمدة عشرين دقيقة.
الجانب السلبي يمكن التنبؤ به. أدخل لمحادثة مدتها خمس دقائق. أحصل على إجابتي. أغلق تيليجرام. يستمر الجهاز في العمل لمدة عشرين دقيقة أخرى قبل أن ينغلق. تلك عشرون دقيقة من الحوسبة دفعت ثمنها دون استخدامها.
اضرب ذلك في جلستين أو ثلاث جلسات قصيرة يومياً وقد تضيف ضريبة الخمول هذه ما بين عشر إلى خمس عشرة ساعة أخرى من وقت التشغيل شهرياً. على مثيل t2.micro يكلف ذلك ربما أربعين سنتاً. ليس بلا شيء. ولكنه ليس سبباً للتخلي عن هذه البنية المعمارية.
السؤال الحقيقي هو ما إذا كان ينبغي أن يكون الحد أقصر. هل يمكنني خفضه إلى عشر دقائق؟ ربما. فحص المرحلتين يحمي من الإغلاق في منتصف المهمة بغض النظر عن المدة. الحد الأقصر يعني فقط توفيراً أكثر قوة في التكاليف وبدايات تشغيل باردة (cold starts) أكثر تواتراً. إنه مقبض ضبط، وليس عيباً في التصميم. لقد تركته عند عشرين دقيقة لأن تكلفة بضع دقائق إضافية لكل جلسة كانت أقل من إزعاج إيقاف تشغيل الجهاز بينما كنت لا أزال أفكر في رسالتي التالية.
عندما يكون الجهاز نائماً، لا يمكنك التقاط هاتفك وكتابة "مرحباً أيها الوكيل، لخص صندوق الوارد الخاص بي." لا يمكنك أن تطرح عليه سؤالاً من السرير وتحصل على رد فوري. يجب النقر على رابط البدء أولاً. ثم تمر ثلاثون ثانية بينما يقلع مثيل EC2، ويتم تهيئة هيرميس، ويعيد بوت تيليجرام الاتصال. ثم يمكنك التحدث.

هذه هي المقايضة. تشتري لك هذه البنية فاتورة شهرية تقل عن عشرة دولارات مقابل تأخير لمدة ثلاثين ثانية في بداية كل جلسة. بالنسبة لأنماط استخدامي، هذه المقايضة سهلة. أنا عادة على مكتبي عندما أحتاج إلى الوكيل. أنقر على الرابط، أرتشف بعض الرشفات من قهوتي، وبحلول الوقت الذي أكون فيه مستعداً، يكون الوكيل مستعداً أيضاً.
ولكن هذا يعني أن الوكيل ليس حاضراً بشكل دائم. إنه ليس وجوداً في الخلفية يمكنك الاتصال به في أي لحظة. إذا كانت حالة الاستخدام الخاصة بك تتطلب توفراً دائماً (always-on availability)، وإذا كنت تريد أن يقوم الوكيل بمراقبة الخلاصات، أو الإجابة على الأسئلة عند الطلب، أو تشغيل المهام المجدولة، فإن هذه البنية ستصيبك بالإحباط. بداية التشغيل الباردة هي تكلفة عدم الدفع مقابل الخمول. لا توجد طريقة للتغلب على ذلك دون ترك الجهاز قيد التشغيل.
هذه البنية تناسبني. قد تناسبك. لكنها لن تناسب الجميع.

إنها تناسبك إذا كنت منشئاً فردياً يستخدم وكيل ذكاء اصطناعي على فترات متقطعة. تفتحه لبضع ساعات من العمل المركز. ثم تغلقه. ويتبعه الجهاز. فاتورتك تتنفس مع استخدامك.
إنها لا تعمل مع الفِرَق. الوكيل مرتبط بمستخدم واحد على بوت تيليجرام واحد. لا يوجد تعدد للمستأجرين (multi-tenancy). لا توجد سيطرة على الوصول (access control) بخلاف تلك الدردشة الفردية.
إنها لا تعمل للأتمتة المجدولة (scheduled automation). تتطلب وظائف Cron بوابة قيد التشغيل (running gateway). عندما يتم إيقاف الجهاز، لا يعمل أي شيء. ليس لدي تدفقات عمل مجدولة أعتمد عليها. ربما لديك أنت. إذا كنت بحاجة إلى الوكيل للتحقق من تقويمك كل صباح أو مراقبة الخلاصة كل ساعة، فإن هذه البنية ستفوت كل حدث أثناء نومك.
إنها لا تعمل للوصول الفوري. البداية الباردة لمدة ثلاثين ثانية حقيقية. إذا كنت تريد وكيلاً يجيب في غضون ثانيتين من شاشة القفل، فسيتعين عليك إبقاء الجهاز قيد التشغيل. ودفع ثمن ذلك.
الموقف الأمني مناسب لنموذج التهديد الخاص بي. مفاتيح LLM مدفوعة مسبقاً. لا توجد بيانات اعتماد AWS. منافذ مغلقة. IMDSv2. أنام جيداً. إذا كان نموذج التهديد الخاص بك يتضمن جهات فاعلة حكومية أو بيانات خاضعة للتنظيم، فلديك مشاكل مختلفة وهذا المنشور ليس دليلك.
هذه البنية مبنية على رأي قاطع (opinionated). تفترض أنك منشئ أصيل بالذكاء الاصطناعي (AI-native builder) يفهم الأدوات ويمكنه تصحيحها عند تعطلها. وتفترض أنك مرتاح للبرامج النصية bash، ومؤقتات systemd، وروابط دوال Lambda. وتفترض أنك على استعداد لمقايضة الراحة بالتكلفة والأمان. تلك الافتراضات ليست عالمية. إنها محددة. وهي خاصة بي.