بناء وكيل ذكاء اصطناعي خاص بك على خادم VPS

ما هو وكيل الذكاء الاصطناعي فعلًا

وكيل الذكاء الاصطناعي حلقة تكرار ملتفة حول نموذج لغوي. يقرأ النموذج الموقف، ويقرر إجراءً واحدًا، فينفّذ كودك ذلك الإجراء، وتعود النتيجة إلى النموذج، وتعمل الحلقة مرة أخرى حتى تنتهي المهمة. هذه هي الفكرة كلها. روبوت المحادثة (chatbot) العادي يجيب مرة واحدة ثم يتوقف. أما الوكيل فيواصل العمل، متخذًا إجراءات حقيقية بين أدواره الخاصة، حتى يبلغ الهدف الذي منحته إياه.

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

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

الأدوات: كيف يتصرف الوكيل

الأداة هي أي قدرة تمنحها للنموذج، موصوفة بدقة كافية تجعله يعرف متى يلجأ إليها. قراءة ملف، وتنفيذ أمر shell، والاستعلام عن قاعدة بيانات، وإرسال رسالة: كل واحدة منها أداة لها اسم، ووصف موجز، وقائمة من المدخلات. أنت تُعرِّف الأدوات؛ والنموذج يقرر متى يستدعيها.

الآلية واحدة في كل مكان، أيًّا كان النموذج الذي تستخدمه. يعيد النموذج طلبًا مُهيكلًا يسمّي أداة ويملأ مدخلاتها. يرى كودك ذلك الطلب، فينفّذ الدالة المطابقة، ويرسل النتيجة في الدور التالي. يقرأ النموذج النتيجة، ثم إما يستدعي أداة أخرى أو يكتب إجابته النهائية. استدعاء الدوال (function calling) هو البنية التحتية التي يقوم عليها كل وكيل، والحلقة التي تحرّكه ليست سوى بضعة أسطر من الكود العادي.

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

MCP: طريقة معيارية لربط الأدوات

كتابة تكامل جديد يدويًا لكل خدمة أمر يصبح مملًّا بسرعة. Model Context Protocol، أو MCP، معيار مفتوح يحل هذه المشكلة. فبدلًا من كتابة كود لأداة جديدة لملفاتك وقاعدة بياناتك ونظام تتبع المشكلات لديك، توجّه الوكيل نحو خادم MCP يعرض تلك الأشياء بالفعل بوصفها أدوات. الوكيل يتحدث بروتوكولًا واحدًا؛ والخادم يتولى مهمة التخاطب مع النظام الحقيقي.

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

الذاكرة والاسترجاع

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

الأول هو المفكرة (scratchpad). تمنح الوكيل ملفًا يستطيع قراءته والكتابة فيه، وتطلب منه أن يسجّل ما يتعلّمه أولًا بأول. وفي الدور التالي، أو الجلسة التالية، يعيد قراءة الملف ويكمل من حيث توقف. هذه ذاكرة في هيئة مستند عادي، وتنجح لأن الوكيل يعامل الملف بوصفه مجرد أداة أخرى.

والثاني هو الاسترجاع. حين يحتاج الوكيل إلى معلومات من كمّ هائل من المستندات لا يتسع أبدًا في طلب واحد، تخزّن تلك المستندات في هيئة قابلة للبحث، ولا تُدخِل إلى مجال رؤية النموذج سوى المقاطع ذات الصلة عند الحاجة إليها. يُسمَّى هذا النمط التوليد المعزز بالاسترجاع، أو RAG (retrieval-augmented generation). يطرح الوكيل سؤالًا، فيجد كودك حفنة المقاطع المطابقة، ولا يذهب إلى النموذج سوى تلك المقاطع. يبقى مخزن البيانات على خادمك، فلا تغادره مستنداتك الخاصة أبدًا.

وكلاء عدة، ومنسّق واحد

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

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

ذاتي الاستضافة أم مستضاف: أي نموذج يشغّل وكيلك

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

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

إن لم تتسع الأرقام، فلديك ثلاث خطوات ممكنة: اختيار نموذج أصغر، أو استخدام تكميم (quantization) أكثر صرامة لتصغيره، أو استخدام واجهة API مستضافة للاستدلال والاكتفاء بإبقاء أدواتك وبياناتك على الخادم. كثير من الوكلاء ذاتيي الاستضافة تبدأ بنموذج محلي عبر Ollama على خادم VPS ثم تلجأ إلى واجهة API مستضافة في أصعب الخطوات.

الخادم هو الجزء الخطر

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

بضع عادات تتحمل معظم العبء. شغّل الوكيل بحساب مستخدم مخصص محدود الصلاحيات، لا بحساب root أبدًا، حتى يكون للخطأ سقف؛ ونفس المنطق موجود في تشغيل الخدمات بمستخدم محدود الصلاحيات. أبقِ أسراره، مثل مفاتيح API، خارج الكود ومقروءة فقط من ذلك المستخدم. واعزل الأدوات التي تلامس النظام في بيئة معزولة (sandbox)، بحيث لا يصل الوكيل إلا إلى ما يحتاج إليه فعلًا. للاطلاع على مثال عملي لتحصين وكيل حقيقي ذاتي الاستضافة، انظر تشغيل OpenClaw بأمان على خادم VPS. وإذا فضّلت استخدام نموذج مستضاف للذكاء، فإن الدليل المرافق حول بناء وكيل باستخدام Claude على خادم VPS يأخذ الأفكار نفسها ويضع نموذجًا محددًا خلفها.

وفي مثال عملي آخر، يطبّق بناء وكيل شخصي على طراز OpenClaw هذه العناصر، وإذا فضّلت تشغيل وكيل جاهز، فابدأ بـ استضافة Hermes Agent ذاتيًا على خادم VPS أو تشغيل Agent Zero على خادمك الخاص، ويقارن أفضل وكلاء الذكاء الاصطناعي ذاتيي الاستضافة في 2026 كل خيار جاهز نغطيه، جنبًا إلى جنب.

FAQ

ما الفرق بين وكيل الذكاء الاصطناعي وروبوت المحادثة؟

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

هل أحتاج إلى GPU لتشغيل وكيل ذكاء اصطناعي على خادم VPS؟

فقط إذا استضفت النموذج ذاتيًا. حلقة الوكيل والأدوات والذاكرة كود عادي يعمل جيدًا على خادم VPS عادي بلا GPU. تصبح بطاقة GPU مهمة حين تريد تشغيل النموذج اللغوي على عتادك الخاص، لأن النموذج يجب أن يتسع في الذاكرة. أما إذا استخدمت نموذجًا مستضافًا عبر واجهة API، فالحساب الثقيل يجري في مكان آخر ويكفي خادم VPS متواضع.

ما هو MCP وهل أحتاجه لبناء وكيل؟

MCP، أي Model Context Protocol، معيار مفتوح لربط الوكيل بالأدوات ومصادر البيانات. لست بحاجة إليه بالمعنى الدقيق، إذ يمكنك كتابة كل أداة يدويًا. يوفّر عليك MCP ذلك العمل بأن يتيح لك إعادة استخدام خوادم موجودة للخدمات الشائعة وعرض أنظمتك الخاصة مرة واحدة ليستخدمها أي وكيل. إنه وسيلة راحة تصبح مجدية مع تزايد عدد التكاملات.

هل من الآمن منح وكيل ذكاء اصطناعي وصولًا إلى خادمي؟

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