معظم العروض التي يشتري فيها وكيلٌ خادمًا تتوقف لحظة اكتمال الطلب. وهي أقل اللحظات إثارة. الخادم موجود، والوكيل يحمل معرّفًا مثل 47HZ7YF، ولم يقل أحد ماذا يحدث بعد ذلك.
بعد ذلك يأتي كل ما يفعله المسؤول دون تفكير: انتظار أن يستجيب SSH فعلًا، إيجاد كلمة المرور، ملاحظة امتلاء القرص، إعادة التشغيل بعد تحديث النواة، التجديد قبل نهاية الشهر، سؤال الدعم حين يبدو شيء غريبًا. إذا كان الوكيل سيملك بنية تحتية، فهذا الجزء من مسؤوليته أيضًا. إليك كيف يجري ذلك عبر خادم MCP الخاص بنا. جرّبنا كل خطوة في بيئة الاختبار قبل كتابتها.
إن لم تربط عميلًا بعد، فابدأ بـ Claude Code وCodex أو Claude Desktop وCursor.
الدقيقة الأولى: «active» لا تعني «جاهز»
يردّ order_vps فور دفع الطلب من الرصيد. يُنشأ الخادم في الخلفية، عادةً خلال دقيقة تقريبًا. الاستدعاء التالي للوكيل هو get_vps_status، ويمكنه تكراره كما يشاء: الأداة تقرأ فقط.
حقلان مهمان. يصبح status مساويًا لـ active عندما يوجد الجهاز. ويحمل access كل ما يلزم لتسجيل الدخول: المضيف والمنفذ وأمر SSH جاهز. في الخطط ذات IPv4 خاص يكون المنفذ 22. في خطط NAT يكون منفذًا معاد توجيهه خاصًا بك، والرد يذكر ذلك صراحة، مع تحذير من أن تقفل الباب على نفسك بجدار حماية يسمح بالمنفذ الخارجي فقط.
بين هاتين اللحظتين فجوة يتعثر فيها الناس. الإقلاع الأول يثبّت تحديثات النظام، وقد يستغرق ذلك بضع دقائق، وقد يرفض SSH الاتصالات خلالها. الوكيل المهذب ينتظر access.ssh_ready بدل أن يطرق المنفذ 22 بلا توقف.
إن لم يتضمن الطلب مفتاح SSH، فكلمة مرور root في الانتظار. يسلّمها reveal_password مرة واحدة بالضبط، وفقط بعد انتهاء إقلاع الجهاز الافتراضي. إن سألت مبكرًا تحصل على password_pending دون استهلاك العرض الوحيد. صممناه هكذا بعدما ظل الوكلاء يأخذون كلمة مرور لم يطبّقها الجهاز الذي لا يزال يُقلع. لكن بصراحة: مرّر ssh_key مع الطلب وتجاوز هذه الخطوة كليًا.
اليوم الثاني: المراقبة
يعيد get_vps_metrics المعالج والذاكرة والشبكة والقرص كسلاسل زمنية للساعة أو اليوم أو الأسبوع أو الشهر الأخير. الوكيل الذي يطّلع عليها مرة يوميًا يمكنه رصد النمط الذي يقتل الخوادم الصغيرة: ذاكرة تزحف صعودًا حتى يختار OOM killer ضحية. لا يستطيع إصلاح السبب من الخارج، لكنه يستطيع إخبارك أو الدخول عبر SSH للنظر.
يقوم power_vps بـ start وstop وreboot. تفصيل من الاختبارات: إذا لم يكن الخادم نشطًا (لا يزال يُنشأ، أو معلّقًا بسبب تجديد غير مدفوع)، تعيد الأداة 409 مع نصيحة بفحص الحالة أولًا. الوكيل الذي يعامل كل رد غير 200 على أنه «أعد المحاولة إلى الأبد» سيدور هنا في حلقة. الخطأ نفسه يخبره بما يفعل، فرسائل الأخطاء لدينا مكتوبة للوكلاء بقدر ما هي مكتوبة للبشر.
يغيّر set_hostname اسم الجهاز عبر الوكيل الضيف الذي يعمل داخله، لذا يسري التغيير على Linux دون إعادة تشغيل. احذف qemu-guest-agent وستتوقف الأداة عن العمل: تعيد agent_unavailable ولا تغيّر شيئًا.
اليوم الثلاثون: المال
هنا تموت البنية التحتية للوكلاء عادة. التجديد تذكير في تقويم شخص ما، وذلك الشخص مشغول، والخادم يُعلَّق.
لدينا لا يعتمد التجديد على ذاكرة الوكيل. كل خادم يتجدد كل شهر من الرصيد المدفوع مسبقًا، ويصل بريد الحساب تذكيرات قبل الموعد. على الوكيل فقط إبقاء الرصيد فوق الخصم التالي، وget_balance يخبره بالوضع.
لا توجد فترة سماح: إذا لم يغطِّ الرصيد التجديد في نهاية المدة، يُعلَّق الخادم ويعود عنوان IP المخصص له إلى المجمّع.
حين يقل الرصيد، ينشئ topup_balance رابط دفع بالعملات المشفرة: USDT أو USDC أو ETH على Base أو Ethereum أو Polygon. هذا أول موضع يحتاجك فيه الوكيل. يمكنه إنشاء الفاتورة، لكنه لا يستطيع توقيع معاملة ما لم تعطه محفظة، ونحن سنفكر مليًا قبل ذلك. عمليًا يشحن الناس الرصيد مرة لعدة أشهر ويتركون الوكيل ينفق منه. إذا بقي طلب أو فاتورة دون دفع لأن الرصيد لم يكفِ، فبعد شحنك يستدعي الوكيل pay_invoice فتُدفع من الرصيد.
ثغرة صريحة: أدوات MCP لا تجدد الخادم عدة أشهر مسبقًا عند الطلب. التجديد الشهري تلقائي، ودفع 3 أو 6 أو 12 شهرًا مقدمًا يتم من لوحة التحكم أو عبر استدعاء REST واحد. إن أردت مدة أطول من البداية، فإن order_vps يقبل months (من 1 إلى 36) عند الطلب.
التوسع يتولاه get_upgrade_options وchange_plan. تتغير الخطة في مكانها، وتبقى الملفات والنظام، ويُعاد تشغيل الخادم مرة واحدة، ويُخصم فرق السعر لبقية المدة من الرصيد. على الوكيل تمرير confirm: true، وهي طريقتنا لقول «أنت تنفق مالًا، فكن متأكدًا».
حين تسوء الأمور
الإجراءات المدمرة غير مريحة عمدًا. يتطلب كل من reinstall_vps وcancel_service الفوري اسم المضيف الدقيق للخادم في confirm، وتطلب أوصافهما من الوكيل استشارة إنسان أولًا. هذا ثاني موضع يحتاجك فيه الوكيل، وهو مقصود.
الإلغاء الآمن، end_of_period، يُبقي الخادم حتى نهاية المدة المدفوعة. ويتراجع عنه undo_cancel، وهذا أهم مما تظن: الوكلاء يغيّرون رأيهم في منتصف المهمة بقدر ما يفعل البشر.
حين يتعثر الوكيل، يفتح create_ticket تذكرة مرتبطة بالخادم، ويواصل reply_ticket المحادثة. يقرؤها إنسان من جهتنا، لا روبوت محادثة يرد على روبوت محادثة.
وحين يجب أن يتدخل إنسان، يدعوه delegate_service عبر البريد ليكون مشغّلًا لذلك الخادم وحده. يحصل على الطاقة ووحدة التحكم وإعادة التثبيت واسم المضيف. لا يحصل على الفوترة أو التجديد أو الإلغاء، ولا يرى رمز الوكيل أبدًا.
ما لا يستطيع الوكيل فعله بعد
لكي تكون الحدود واضحة:
- شحن الرصيد. يمكنه إنشاء فاتورة شحن ودفع الفواتير من الرصيد عبر
pay_invoice. أما إدخال العملات المشفرة إلى الرصيد فيتطلب محفظة، أي أنت عادة. - العمل داخل نظام التشغيل عبر MCP. الحزم والإعدادات والنشر تمر عبر SSH. يدير MCP الجهاز من الخارج.
- رفع التعليق بنفسه. إذا عُلّق خادم بسبب إساءة الاستخدام، فهذه محادثة مع إنسان، وهكذا ينبغي أن تكون.
لا شيء من ذلك يقلل من فائدة الأدوات. يعني فقط أن حلقة الوكيل يجب أن تُبنى حولها: الاستعلام عن الحالة، وإبقاء الرصيد في نطاقه، والتصعيد عبر تذكرة، وانتظارك قبل أي شيء يحذف بيانات.
إذا كان عمل الوكيل قصير الأجل، فقد لا يكون خادم كامل هو الوحدة المناسبة. يشرح VPS أم صندوق رمل؟ متى تناسب microVM تعيش دقيقة أكثر. وإلا فالخطط هنا، ومرجع MCP يسرد كل أداة مع معاملاتها.
التعليقات
لا تعليقات بعد. كن الأول.