ربط الذكاء الاصطناعي بالخادم: هكذا ينشر وكيل ذكاء اصطناعي على خادمكم ويديره

يستخدم معظم الناس الذكاء الاصطناعي حتى الآن كما لو كان زميلاً واسع الاطلاع على الهاتف: يصف المرء مشكلة في الخادم، فيُقترح عليه أمر، فينسخه إلى الطرفية، ثم ينسخ رسالة الخطأ ويعيدها إلى المحادثة، ويعيد الكرّة حتى يعمل كل شيء. وبمجرد أن تربطوا الذكاء الاصطناعي بخادمكم يزول هذا الالتفاف. فوكيل ذكاء اصطناعي مثل Claude Code أو OpenAI Codex CLI أو Gemini CLI يسجّل الدخول إلى الخادم بنفسه عبر SSH، ويقرأ السجلات، ويفحص الإعدادات، ويطبّق التغييرات، ويختبر النتيجة، ويدوّن ما فعله. أنتم تحددون المهمة، وتوافقون على الخطوات التي لا يمكن التراجع عنها.

هذا المقال تقرير من واقع التشغيل. فلدى KernelHost يشارك وكيل ذكاء اصطناعي منذ أشهر يومياً في العمل على بنيتنا التحتية الخاصة: بوابة العملاء، والمراقبة، وطرق الدفع، والتوثيق. نعرض كيف بُني الاتصال بين الوكيل والخادم، ووفق أي سير عمل ينشر الوكيل على الأنظمة الإنتاجية، وما القواعد التي تمنع وقوع خطأ أثناء ذلك أو تسرّب شيء إلى الخارج، وما الذي يجب أن يوفره الخادم لكي يعمل كل ذلك. وتجدون أساسيات الأدوات والبنيات في مقال خادم مُدار بالذكاء الاصطناعي: ربط وكلاء الذكاء الاصطناعي بأمان، والتثبيت على الخادم في دليل Claude Code وCodex CLI.

ربط الذكاء الاصطناعي بالخادم: ماذا يعني ذلك

ربط الذكاء الاصطناعي بالخادم يعني منح وكيل ذكاء اصطناعي وصولاً خاصاً به ومضبوطاً إلى سطر أوامر الخادم، غالباً عبر مفتاح SSH. ومنذ تلك اللحظة لا يكتفي الوكيل باقتراح الأوامر، بل ينفذها بنفسه، ويقرأ المخرجات، ويستنتج منها الخطوة التالية. أما نموذج اللغة نفسه فيبقى عاملاً لدى المزود (Anthropic أو OpenAI أو Google)، ولا يعمل على حاسوبكم أو خادمكم سوى أداة سطر أوامر خفيفة ترسل الأوامر.

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

روبوت دردشة أم وكيل: الفرق في جدول واحد

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

ما الذي ينجزه وكيل الذكاء الاصطناعي على الخادم: أمثلة من تشغيلنا اليومي

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

عمليات نشر مع نسخة احتياطية ومسار للتراجع

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

تشخيص الأعطال: من العَرَض إلى السبب في دقائق

«لا يمكن الوصول إلى الموقع من مكتبنا، لكنه متاح من خارج المكتب.» في السابق كان ذلك يعني بحثاً طويلاً. يفحص الوكيل قواعد جدار الحماية، ويبحث في سجلات برنامج الحماية عن عنوان المكتب، ويجد القاعدة التي فُعّلت، ويشرح أي طلب تسبب في تفعيلها. يبقى القرار بشأن ما يجب فعله بأيدينا، أما عمل التحري فلا. ومع أخطاء خوادم الويب المعتادة مثل 502 Bad Gateway أو امتلاء الأقراص يعمل بالطريقة نفسها: يقرأ السجلات عبر journalctl وسجلات التطبيقات، ويضع فرضية ويثبتها بالأدلة قبل أن يغيّر أي شيء.

مراقبة يبنيها الوكيل بنفسه

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

تقارير شاملة وأعمال تنظيف

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

توثيق ينمو من تلقاء نفسه

ينتهي كل تغيير بإدخال في سجل التغييرات، وعند الحاجة بإضافة إلى دليل التشغيل. يكلّف ذلك الوكيل ثواني معدودة، ويوفر علينا لاحقاً ساعات، لأن السؤال «لماذا هو على هذا النحو أصلاً؟» تكون له إجابة مكتوبة.

المزايا عندما يعمل الذكاء الاصطناعي مباشرة على الخادم

• السرعة: يقرأ الوكيل في ثوانٍ ما يحتاج الإنسان إلى دقائق لقراءته، ويجرّب الفرضية فوراً بدلاً من أن يصفها أولاً.
• الدقة: يقرأ الإعدادات كاملة مع الملفات المضمّنة، وأسطر السجل المحيطة بالخطأ، لا المقتطف الذي ظنه أحدهم مهماً فحسب.
• سير عمل ثابت: النسخ الاحتياطي وفحص الصياغة والتحقق تجري في كل مرة، حتى مساء الجمعة، وحتى عند التغيير الصغير العشرين.
• توثيق دون جهد إضافي: كل تغيير موصوف، مع سببه ومكان النسخة الاحتياطية ومسار التراجع.
• أتمتة دون تعلّم كتابة السكربتات: تنشأ سكربتات الفحص ومهام cron والتقارير من وصف بلغة عادية، وتُختبر قبل استخدامها.
• التعلّم أثناء العمل: يشرح الوكيل ما يفعله ولماذا. ومن يتابع ذلك يفهم خادمه بعد بضعة أسابيع أفضل بكثير.

ثلاث بنيات وأيها نستخدم

هناك ثلاث طرق مجرَّبة لربط وكيل بخادم. وتختلف فيما بينها في مكان تشغيل الأداة ومكان حفظ بيانات الدخول.

اختيارنا: الوكيل على محطة العمل، والخوادم عبر SSH

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

دليل: ربط وكيل ذكاء اصطناعي بالخادم عبر SSH

تعمل الخطوات السبع التالية مع Claude Code وCodex CLI وGemini CLI على حد سواء. تستخدم الأمثلة عنوان IP المخصص للتوثيق 203.0.113.10 واسم المستخدم deploy، فاستبدلوا كليهما بقيمكم. والمتطلب المسبق خادم يتيح تسجيل الدخول بمفتاح SSH، كما هو موضح في مقال تأمين SSH وإعداد تسجيل الدخول بالمفتاح.

الخطوة 1: إنشاء مفتاح SSH مستقل للوكيل وحده

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

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

يتميز Ed25519 بالقِصَر والسرعة، ويُعدّ آمناً. ويظهر التعليق ki-agent لاحقاً في ملف authorized_keys على الخادم، فيجعل المفتاح سهل التمييز من النظرة الأولى.

الخطوة 2: إيداع المفتاح العام على الخادم

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

ومن يريد تقييد الوصول أكثر، يضيف في الملف ~/.ssh/authorized_keys على الخادم خيارات قبل المفتاح. يسمح from= بتسجيل الدخول من عنوان محدد فقط، ويمنع no-agent-forwarding وno-port-forwarding استخدام الاتصال كنقطة انطلاق:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

وإذا أظهر الخادم بعد ذلك الرسالة Permission denied (publickey)، فسيساعدكم مقال حل خطأ SSH Permission denied (publickey).

الخطوة 3: إنشاء اسم مستعار للمضيف في إعدادات SSH

يضمن الاسم المستعار أن يحتاج الوكيل إلى معرفة اسم قصير فقط، وأن يستخدم دائماً المفتاح الصحيح:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

بعد ذلك يكفي الأمر ssh web-prod "systemctl status nginx". ويمنع IdentitiesOnly yes برنامج SSH من تجربة مفاتيح أخرى من حلقة مفاتيحكم. أنشئوا لكل خادم إضافي قسماً خاصاً به، ويُفضَّل أن تحمل أنظمة الاختبار والإنتاج أسماء مختلفة مثل web-test وweb-prod، حتى يُكشف أي خلط بينها من الاسم وحده.

الخطوة 4: تثبيت الوكيل وتسجيل الدخول

يعمل Claude Code وCodex CLI وGemini CLI على Linux وmacOS وWindows، ويُسجَّل الدخول إليها بحساب لدى المزود أو بمفتاح API. التثبيت وتسجيل الدخول دون متصفح موضحان في الدليل خطوة بخطوة. وفي خيار محطة العمل ثبّتوا الأداة على حاسوبكم، لا على الخادم.

الخطوة 5: وضع القواعد التي يلتزم بها الوكيل

تقرأ الأدوات الثلاث عند بدء التشغيل ملف قواعد في مجلد العمل: يقرأ Claude Code الملف CLAUDE.md، وCodex CLI الملف AGENTS.md، وGemini CLI الملف GEMINI.md. في هذا الملف يُحدَّد كيف يجري العمل على خوادمكم. وهذه بداية مجرَّبة:

# قواعد العمل على الخوادم

- إنشاء نسخة احتياطية مؤرخة قبل كل تغيير، خارج مجلد الويب.
- فحص الصياغة قبل تطبيق التغيير (nginx -t, php -l, apachectl configtest).
- فحص الخدمة والسجل والوظيفة بعد تطبيق التغيير، والإبلاغ عن النتيجة.
- عدم عرض كلمات المرور ومفاتيح API ورموز الوصول أبداً، وعدم نسخها إلى ملفات أبداً.
- الحذف وتعديلات قواعد البيانات وكل ما لا رجعة فيه: فقط بعد موافقة صريحة.
- عدم التعديل المباشر للملفات التي تديرها لوحة التحكم.
- إزالة ملفات الاختبار بعد انتهاء الاختبار.

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

الخطوة 6: ضبط الموافقات والقائمة المسموحة

افتراضياً تسأل الأدوات قبل كل أمر يغيّر شيئاً. وهذا هو الصواب في البداية. أما أوامر القراءة التي توافقون عليها مراراً، فيمكنكم السماح بها مسبقاً. في Claude Code يتم ذلك في الملف .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

كل ما ليس في هذه القائمة يظل بحاجة إلى موافقتكم. أما الخيارات التي تعطّل جميع طلبات التأكيد، فمكانها في أقصى الأحوال جهاز اختبار مؤقت يُتخلَّص منه بعد التجربة.

الخطوة 7: المهمة الأولى: القراءة فقط

ابدؤوا بمهام لا يمكنها تغيير أي شيء، وراقبوا طريقة عمل الوكيل:

افحص على web-prod أخطاء nginx خلال آخر 24 ساعة، واذكر الأسباب الثلاثة
الأكثر تكراراً مع دليل واحد من السجل لكل سبب. لا تغيّر شيئاً.

ولا تأتي تغييرات صغيرة إلا حين تكون التحليلات صحيحة، مثل إعداد جديد لتدوير السجلات أو خدمة systemd، ولا تأتي عمليات النشر على النظام الإنتاجي إلا بعد ذلك.

هكذا ينشر الوكيل: سير عملنا لكل تغيير على النظام الإنتاجي

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

1. فحص الحالة الراهنة. يُقارَن الملف الموجود على الخادم بآخر نسخة معروفة. وإذا كان شخص آخر قد غيّره في الأثناء، يتوقف الوكيل ويستفسر، بدلاً من الكتابة فوق تغيير لم يُجرِه هو.
2. إنشاء نسخة احتياطية. تُحفظ الملفات المعنية مع التاريخ في مجلد نسخ احتياطي خارج مجلد الويب. فالنسخة الاحتياطية داخل مجلد الويب قد تكون في ظروف معينة متاحة للعموم.
3. تجهيز مسار التراجع. يُكتب قبل التغيير سكربت صغير يعيد الحالة القديمة بأمر واحد، لا حين تقع حالة طارئة.
4. فحص الصياغة. يُفحص الملف الجديد قبل تطبيقه، في PHP بالأمر php -l، وفي nginx بالأمر nginx -t. وبذلك لا يصل خطأ الصياغة إلى النظام الإنتاجي أصلاً.
5. التطبيق بالصلاحيات الصحيحة. يُنقل المالك والمجموعة وصلاحيات الملف من النسخة القديمة. فالصلاحيات الخاطئة هي، بعد أخطاء الصياغة، السبب الأكثر شيوعاً للأعطال بعد التحديث.
6. الاختبار دون آثار جانبية. يجري الاختبار بالقراءة فقط، أو ببيانات اختبار وهمية، أو في بيئة معزولة، ولا يجري أبداً بطلبات شراء حقيقية أو ببيانات عملاء حقيقية.
7. التحقق على النظام الحي. بعد التطبيق تُفحص حالة HTTP وسجل الأخطاء والوظيفة التي تغيّرت.
8. التوثيق. يُستكمل سجل التغييرات ودليل التشغيل، بما في ذلك مكان النسخة الاحتياطية وأمر التراجع.

وعلى هيئة تسلسل أوامر، مع عناصر نائبة بدلاً من المسارات الحقيقية، يبدو ذلك تقريباً كما يلي:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

لماذا يُجهَّز مسار التراجع قبل التغيير

عند وقوع خطأ لا يكون أحد في أفضل حالاته ليفكر في مسار تراجع نظيف. أما إذا كان السكربت جاهزاً مسبقاً، فالتراجع مسألة ثوانٍ، ويستطيع الوكيل أيضاً تنفيذه بنفسه إذا فشل الفحص بعد التطبيق. وهذا هو الفرق الأكبر بين وكيل يغيّر شيئاً «على عجل» ووكيل يُؤتمَن على نظام إنتاجي.

اختبارات لا يمكنها أن تُفسد شيئاً

كثير من الوظائف لا يمكن اختبارها دون أن يحدث شيء: طلب شراء، أو دفعة، أو رسالة بريد إلكتروني. وهنا تساعد ثلاث تقنيات. أولاً التشغيل التجريبي (dry run) الذي توفره الأداة نفسها. ثانياً معرّفات مختلَقة يُضمن أنها غير موجودة في أي مكان. ثالثاً بيئة معزولة: فالعملية التي تعمل في مساحة أسماء شبكية خاصة بها دون شبكة (unshare -n) لا تستطيع الوصول إلى أي واجهة خارجية ولا شراء شيء عن طريق الخطأ، لكنها تظل ترى قاعدة البيانات المحلية عبر مقبس Unix. وبعد الاختبار تُزال جميع ملفات الاختبار.

الإجراءات التي تكلّف مالاً تحتاج إلى قفل

إذا كان سير عمل ما يطلب شيئاً أو يُصدر فاتورة أو يحذف، فلا يجوز أن يعمل مرتين في الوقت نفسه، ولا حتى عندما ينقر أحدهم نقرة مزدوجة أو يكرر الوكيل أمراً. وأبسط حل على Linux هو flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "قيد التشغيل بالفعل"

وفي تطبيقات قواعد البيانات يؤدي قفل مُسمّى (GET_LOCK في MySQL وMariaDB) الغرض نفسه، وفي الواجهات البرمجية يؤديه Idempotency-Key، والمزيد عن ذلك في قسم KernelHost API أدناه.

الأمان: وصول للوكيل دون تسرّب أي شيء

القلق الذي نسمعه أكثر من غيره هو: «وماذا عن بياناتي؟» والإجابة الصادقة: كل ما يقرؤه الوكيل يرسله للمعالجة إلى نموذج اللغة لدى المزود. لذلك تقررون بالقواعد التالية ما الذي يراه أصلاً.

لا مكان للأسرار في المحادثة

لا تُكتب كلمات المرور ومفاتيح API ورموز الوصول في أي مهمة أبداً، ولا يعرضها الوكيل أبداً. تقرؤها السكربتات من ملفات بالصلاحيات 600، ولا يحتاج الوكيل إلى عرضها كي يستخدم السكربت. وإذا وصل مفتاح إلى المحادثة رغم ذلك، يُعطَّل فوراً لدى المزود ويُستبدل بمفتاح جديد. ولا مكان في المحادثة حتى لأجزاء المفاتيح: فالأحرف الأولى من مفتاح لا تساعد أحداً في تشخيص الأعطال، لكنها تختصر عمل المهاجم.

مفاتيح خاصة وصلاحيات خاصة قابلة للإلغاء في أي وقت

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

الموافقات: ما لا يحدث أبداً دون إنسان

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

قابلية التتبع: السجلات، وقائمة التغييرات، والنسخ الاحتياطية

تترك كل جلسة آثاراً يستطيع الإنسان قراءتها: النسخ الاحتياطية المؤرخة، وسكربت التراجع، والإدخال في سجل التغييرات، وعمليات تسجيل الدخول في سجل النظام. ومن يدير /etc إضافة إلى ذلك في Git عبر etckeeper، يرى كل تغيير في الإعدادات على هيئة diff. وما لا يمكن تتبعه لا يمكن التراجع عنه أيضاً. ويبقى الأساس استراتيجية نسخ احتياطي فعّالة، لأن الوكيل لا يغني عن النسخة الاحتياطية.

أي خادم يناسب وكيل الذكاء الاصطناعي؟

يحتاج الخادم الذي يُدار بمساعدة الذكاء الاصطناعي إلى وصول جذري كامل، وتسجيل دخول بمفتاح SSH، واتصالات صادرة دون قيود، وحماية DDoS دائمة، ويُفضَّل أن تتوفر له واجهة برمجة تطبيقات يمكن من خلالها طلب الخوادم والتحكم فيها آلياً. ولا يحتاج إلى GPU، لأن نموذج اللغة يعمل لدى المزود.

لماذا KernelHost للخوادم المُدارة بالذكاء الاصطناعي

من حيث المبدأ يستطيع وكيل الذكاء الاصطناعي العمل مع أي خادم يحصل فيه على صدفة (shell). لكن البيئة المحيطة هي التي تحدد عملياً مقدار العمل الذي يمكنكم فعلاً تسليمه إليه. فعلى خادم جذري KVM أو خادم مخصص من KernelHost لا توجد حسابات مقيّدة، ولا عوائق أمام اتصالات HTTPS بمزودي الذكاء الاصطناعي، ولا التزام تعاقدي يجعل التجربة مكلفة. وحماية DDoS الدائمة مفعّلة على كل خادم دون تكلفة إضافية، وللمهام كثيفة الحوسبة تتوفر خوادم جذرية احترافية (Professional) بأنوية مخصصة. وتتم المحاسبة بنظام PrePaid: بلا عقد، وبلا حد أدنى للمدة، وبلا رسوم إعداد. ومن يريد التجربة أولاً، يمكنه البدء باستخدام خادم الاختبار المجاني.

واجهة KernelHost API: وكيلكم يطلب الخوادم ويتحكم فيها بنفسه

أما أكبر رافعة فتقع على مستوى أعلى من الخادم المفرد. فعبر KernelHost API يستطيع الوكيل الاستعلام عن المنتجات والأسعار، وطلب الخوادم، وقراءة حالة خدماته، وتشغيل الخوادم وإيقافها وإعادة تشغيلها، إضافة إلى تقديم طلبات الإلغاء وسحبها. وبذلك تتحول عبارة «جهّز لي خادم اختبار» إلى مهمة واحدة: يطلب الوكيل الجهاز، وينتظر التجهيز، ويتصل عبر SSH، ويثبّت التطبيق، ويعيد إليكم العنوان.

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

كم يكلّف خادم يديره الذكاء الاصطناعي؟

هناك بندان من التكاليف. أولاً الخادم نفسه: لوكيل يعمل عبر SSH لا يحتاج الخادم إلى أي تجهيزات خاصة، ويكفي أي خادم جذري يعمل عليه تطبيقكم أصلاً. وإذا كان الوكيل يعمل مباشرة على الخادم، فالأداة نفسها لا تحتاج إلا إلى بضع مئات من الميغابايتات من الذاكرة، ويكفي خادم جذري يضم 2 vCPU و4 GB RAM إذا لم يكن يعمل عليه الكثير غير ذلك. ثانياً نموذج اللغة: إما اشتراك لدى المزود يشمل استخدام أداة سطر الأوامر، أو مفتاح API مع محاسبة حسب الاستهلاك. عند الاستخدام اليومي المكثف يكون الاشتراك غالباً أرخص، أما للمهام المؤتمتة التي لا يجلس أمامها إنسان فمفتاح API هو الطريق النظيف، لأنه يمكن تحديد سقف له بميزانية شهرية. تجدون أسعار الخوادم الحالية في صفحة استئجار خادم جذري.

أخطاء شائعة وكيف تتجنبونها

• الوكيل يعمل بالمفتاح الشخصي لمدير النظام. عندها لا يمكن سحب وصوله بشكل منفصل، ولا تمييزه في السجلات. الحل: مفتاح خاص به مع تعليق خاص به.
• جميع طلبات التأكيد معطّلة. يوفر ذلك في اليوم الأول بعض النقرات، ويكلّف في يوم ما خادماً. الحل: قائمة مسموحة لأوامر القراءة، وموافقة على كل ما يتدخل في النظام.
• لا نسخة احتياطية قبل التغيير. الحل: النسخة الاحتياطية وسكربت التراجع كقاعدة ثابتة في CLAUDE.md أو AGENTS.md.
• نسخ احتياطية داخل مجلد الويب. ملف مثل config.php.bak في جذر الويب قد يكون متاحاً للعموم، ومعه كلمة مرور قاعدة البيانات. الحل: مجلد نسخ احتياطي خارج مجلد الويب بالصلاحيات 700.
• أسرار في الموجّه (prompt). الحل: بيانات الدخول فقط في ملفات بالصلاحيات 600 تقرؤها السكربتات، وإنشاؤها من جديد فوراً عند أي خطأ غير مقصود.
• التنفيذ المزدوج. نقرة مزدوجة أو طلب مكرر يؤدي إلى الشراء مرتين. الحل: قفل عبر flock أو Idempotency-Key.
• تعديل الملفات التي تديرها لوحة التحكم مباشرة. تكتب اللوحة فوقها عند التحديث التالي، أو تتعطل بسببها. الحل: استثناء هذه الملفات في القواعد، وإجراء التغييرات عبر اللوحة أو واجهتها البرمجية.
• قبول المخرجات دون فحص. الوكيل الذي لا يفهم مخرجات ما يلجأ إلى التخمين. الحل: طلب الأدلة («أرني سطر السجل») وجعل النتائج تُفحص على النظام الحي.

الخلاصة باختصار

• ربط الذكاء الاصطناعي بالخادم يعني منح وكيل مثل Claude Code أو Codex CLI أو Gemini CLI مفتاح SSH خاصاً به وقواعد واضحة.
• يقرأ الوكيل السجلات، ويطبّق التغييرات، ويتحقق من النتيجة ويوثّقها، أما الخطوات التي تتدخل في النظام فلا تجري إلا بموافقة.
• تتبع كل عملية نشر سير عمل ثابتاً: فحص الحالة الراهنة، والنسخ الاحتياطي، وتجهيز مسار التراجع، وفحص الصياغة، والتطبيق، والاختبار، والتحقق على النظام الحي، والتوثيق.
• لا مكان للأسرار في المحادثة أبداً، والإجراءات التي تكلّف مالاً تحتاج إلى قفل يمنع التنفيذ المزدوج.
• يحتاج الخادم إلى وصول جذري، ومفاتيح SSH، واتصالات صادرة حرة، وحماية DDoS، لكنه لا يحتاج إلى GPU.
• تلبي خوادم KernelHost جميع المتطلبات منذ البداية، بنظام PrePaid ودون التزام تعاقدي، وعبر KernelHost API يستطيع الوكيل حتى أن يطلب الخوادم ويتحكم فيها بنفسه.