شغّل وكيل ذكاء اصطناعي 24/7 على VPS.
بعيدًا عن حاسوبك المحمول، وعلى عتاد لا ينام.
لتشغيل وكيل ذكاء اصطناعي 24/7 على VPS، تحتاج إلى أربعة أشياء، لا شيء منها معقّد: جهاز يبقى قيد التشغيل، ومُشرِف (supervisor) يعيد تشغيله، وأسرار لا تدخل الصورة أبدًا، وسقف إنفاق — بالإضافة إلى مستضيف لا يطلب هويتك.
- 01
معظم الوكلاء هم مجرد «غراء» مقيّد بالإدخال/الإخراج حول واجهة برمجة تطبيقات لنموذج مستضاف. الاستدلال ليس على جهازك، لذا يكون الجهاز صغيرًا: 2 vCPU و4 GB تكفي لوكيل بحلقة واحدة.
- 02
زمن التشغيل المتواصل (uptime) مشكلة مُشرِف (supervisor)، لا مشكلة عتاد. وحدة systemd أو سياسة إعادة تشغيل في Docker — مُفعّلة، ومُختبرة بإعادة إقلاع فعلية — هذا كل ما في الأمر.
- 03
الشيئان اللذان يسببان المشاكل فعلًا: سرّ مخبوز داخل طبقة صورة، ووكيل بلا سقف إنفاق يدور طوال الليل مقابل واجهة API مقيسة الاستهلاك.
لماذا حاسوبك المحمول ليس نشرًا (deployment). أربعة أنماط فشل، كلها مملّة.
الوكيل الذي يعمل على جهازك هو وكيل يعمل، وليس وكيلًا منشورًا. الفجوة بينهما هي أربع مشكلات غير برّاقة، لا علاقة لأي منها بهندسة التعليمات (prompt engineering).
السُّبات. أغلق الغطاء وتتوقف العملية مؤقتًا (suspended). إدارة الطاقة تُقيّد العمل في الخلفية قبل إغلاق الغطاء بوقت طويل، ما يعطي أسوأ نسخة من هذا الفشل: وكيل يعمل، لكن متأخرًا وبشكل غير متوقع.
تبدّل عنوان IP. يمنحك اتصال المنزل أو المقهى عنوانًا جديدًا عند كل إعادة اتصال. أي شيء مقيَّد بمعدل حسب IP، وأي webhook يحتاج إلى نداء عودة (callback) ثابت، وأي قائمة سماح (allowlist) سجّلتها، كل ذلك ينكسر بشكل متقطع.
إعادات الإقلاع. تُعيد تحديثات نظام التشغيل تشغيل الجهاز وفق جدولها الخاص. وما لم يكن الوكيل مسجَّلًا لدى مدير خدمات، فإنه يعود إلى سطح مكتب، لا إلى حلقة تعمل. يلاحظ معظم الناس ذلك بعد أسبوع.
الانتقال. تسافر، تُبدّل الأجهزة، تُعيد التثبيت. أي شيء موجود فقط في سجلّ أوامر الصدفة (shell history) لا يمكن إعادة إنتاجه — وكيل أُعدّ في عصر أحد أيام مارس ليس له أي إجراء نشر على الإطلاق.
الخادم يُصلح هذه الأشياء الأربعة فحسب، ولا شيء غيرها — لا الصحة، ولا التكلفة، ولا السلامة. إنه يمنحك بيئة تشغيل (runtime) تكون إصلاح أعطالها من مسؤوليتك. كن حذرًا من أي من يسوّقه على أنه أكثر من ذلك.
تحديد حجم الجهاز. أي فئة VPS تناسب أي شكل من أشكال الوكلاء.
الغريزة الأولى هي المبالغة في التوفير، لأن «الذكاء الاصطناعي» يبدو ثقيلًا. لكنه ليس كذلك ما دام النموذج يعمل على عتاد طرف آخر: الوكيل الذي يستدعي واجهة API مستضافة يقضي وقته منتظرًا إدخال/إخراج الشبكة. أما الشكل الثالث — تشغيل النموذج نفسه محليًا — فخارج نطاق هذا الدليل؛ فذلك الحِمل يحتاج إلى GPU أكثر مما يحتاج إلى آلة افتراضية.
الشكل الأول — الحلقة الواحدة. عملية واحدة، حلقة استطلاع أو مجدولة، واجهة API لنموذج مستضاف، وحالة (state) في SQLite. هذا ما عليه معظم الوكلاء المستقلين وروبوتات المراقبة، وهو صغير فعلًا.
الشكل الثاني — المجموعة الصغيرة (stack). الوكيل بالإضافة إلى Postgres، وطابور مهام (queue) مدعوم بـRedis، ووحدة معالجة (worker)، ومخزن متجهات (vector store). الذاكرة هي الآن القيد الحاسم — نموذج تضمين (embedding) مُحمَّل داخل العملية يحتاج غيغابايت أو اثنين لنفسه.
بمقارنة الكتالوج: Sentinel (NB-V1 — 2 vCPU، 4 GB RAM، 120 GB NVMe، 1 Gbps، نطاق ترددي غير محدود، $3.90/month) يغطي الشكل الأول بهامش مريح. Garrison (NB-V2 — 4 vCPU، 8 GB، 240 GB، $7.90/month) هو الحد الأدنى الصادق للشكل الثاني بمجرد دخول Postgres وطابور المهام في الصورة. Ravelin (NB-V3 — 8 vCPU، 16 GB، 480 GB، 2.5 Gbps، $16.90/month) مخصّص لعدة وكلاء يتشاركون جهازًا واحدًا. الاستدلال المحلي مكانه العتاد المخصص (dedicated).
المدد شهرية، مع خصم عند الالتزام لفترات أطول — 10% عند ثلاثة أشهر، و20% عند ستة، و30% عند اثني عشر. وإذا كان وكيلك عميل تداول يعمل على Windows فقط وليس عملية Python، فإن فئات سطح المكتب البعيد (remote-desktop) موجودة لهذه الحالة.
مسار النشر — شغّل وكيل ذكاء اصطناعي على VPS في نحو خمس عشرة دقيقة.
جهّز الجهاز بنظام Ubuntu 24.04 LTS أو Debian 13 — وكلاهما متاح وقت الطلب، إلى جانب Ubuntu 22.04 وDebian 12 وAlmaLinux 9 وRocky Linux 9. تحصل على بيانات اعتماد root؛ وأول ما ينبغي فعله بها هو التوقف عن استخدامها. وإذا كان التوثيق بمفتاح SSH أرضًا غير مألوفة، فاقرأ أولًا دليل التحصين المرتبط أدناه.
1 — أنشئ مستخدم خدمة (service user). adduser --system --group --home /srv/agent agent. لا ينبغي أن يعمل الوكيل بصلاحية root ولا أن يملك صدفة (shell) تفاعلية. أمر واحد الآن، ونطاق الضرر (blast radius) يبقى صغيرًا لاحقًا إذا استُغلّت أداة يستدعيها ضده.
2 — انقل الشيفرة إلى الجهاز. استخدم git clone إلى /srv/agent، أو rsync إن كنت تفضّل عدم ترك مفتاح نشر (deploy key) على الخادم. ثبّت التبعيات (pin the dependencies): فملف القفل (lockfile) هو الفرق بين إعادة نشر تُعيد إنتاج النتيجة ذاتها وأخرى تفاجئك.
3 — ابنِ البيئة. نفّذ python3 -m venv /srv/agent/.venv، ثم ثبّت من ملف القفل باستخدام pip الخاص بتلك البيئة الافتراضية (virtualenv). أو ثبّت uv ودعه يتولى إدارة كل من المُفسِّر (interpreter) وملف القفل. كلا الخيارين جيد؛ لكن الجمع بينهما ليس كذلك.
4 — شغّله مرة واحدة يدويًا. sudo -u agent /srv/agent/.venv/bin/python -m agent --once. لا تتخطَّ هذه الخطوة للانتقال مباشرة إلى وحدة خدمة. تسعة من كل عشرة أعطال هنا سببها متغيّر بيئة (environment variable) مفقود أو مسار نسبي لحاسوبك المحمول، وكلاهما يظهر بوضوح أكبر في الطرفية (terminal) منه في journald.
5 — سلّمه إلى مُشرِف (supervisor). الفصل التالي. هذا ما يحوّل نصًّا برمجيًا بدأتَه إلى خدمة يملكها الجهاز. وإذا استغرق التسلسل وقتًا أطول بكثير من خمس عشرة دقيقة، فالسبب في الغالب تبعية ضمنية على جهاز التطوير الخاص بك — ثنائي (binary) عام، أو بيانات اعتماد في ملف تعريف الصدفة (shell profile) الخاص بك، أو مسار خارج المستودع (repository).
إبقاؤه يعمل 24/7. systemd، وDocker، وفخّ حلقة الأعطال (crash-loop).
العملية التي تبدؤها عبر جلسة SSH تموت عند انتهاء الجلسة، ولا تعود بعد إعادة الإقلاع. الإشراف (supervision) ليس اختياريًا، ولديك خياران معقولان.
systemd، لعملية واحدة. وحدة في /etc/systemd/system/agent.service بـUser=agent وWorkingDirectory=/srv/agent وExecStart يشير إلى مُفسِّر البيئة الافتراضية، مع Restart=always وRestartSec=5. ثم systemctl daemon-reload، ثم systemctl enable --now agent. عملية enable هي ما يصمد أمام إعادة الإقلاع؛ والتشغيل دون enable هو الطريقة الأكثر شيوعًا لفقدان وكيل بعد ثلاثة أسابيع.
Docker، لمجموعة من الأشياء. عندما يكون للوكيل «إخوة» — قاعدة بيانات، طابور مهام، متصفح بلا واجهة (headless) — صِفهم في ملف Compose واحد مع restart: unless-stopped على كل خدمة. يختلف unless-stopped عن always في نقطة مهمة: الحاوية التي أوقفتها عمدًا تبقى متوقفة عبر إعادة تشغيل daemon.
فخّ حلقة الأعطال. يحدّ systemd من معدل إعادة التشغيل افتراضيًا. تعطّل بشكل متكرر بما يكفي خلال الفاصل الزمني، وتدخل الوحدة الحالة failed وتتوقف عن المحاولة — وكيل يبدو وكأنه مات بصمت بينما ملف الوحدة ينص صراحة على Restart=always. اضبط StartLimitIntervalSec=0 لإعادة المحاولة إلى ما لا نهاية، وارفع قيمة RestartSec حتى لا يستهلك وكيل معطوب نواة معالج كاملة طوال الليل.
البقاء حيًا (liveness) ليس سلامة (health). حلقة عالقة في قراءة socket لتسع ساعات هي عملية «تعمل» بكل المقاييس التي يستطيع systemd رؤيتها. اعرض نبضة حياة (heartbeat): حارسًا (watchdog) بـWatchdogSec، أو HEALTHCHECK في Docker، أو ملف طابع زمني يلمسه الوكيل في كل دورة مع مؤقّت (timer) ينبّه عند تقادمه.
الأسرار. ملف البيئة الذي يجب ألا يصل إلى الصورة أبدًا.
يحمل الوكيل موادّ أخطر مما يحمله تطبيق ويب. مفتاح API لنموذج هو أداة إنفاق؛ ومفتاح تداول هو أداة برافعة مالية؛ ومفتاح محفظة هو الأموال نفسها. وبخلاف تطبيق الويب، يتصرف الوكيل بناءً على نص لم يكتبه هو، ما يجعل الحد الفاصل بين وكيل يحمل مفتاحًا ومهاجم يحمله رفيعًا للغاية.
أبقها خارج الصورة. تُكتب قيم ENV وARG في Dockerfile داخل طبقات الصورة، ويمكن قراءتها عبر docker history من قِبل أي شخص يحصل على الصورة. استخدم env_file: في Compose، أو EnvironmentFile= في وحدة systemd، وأبقِ الملف خارج سياق البناء (build context).
أبقها خارج المستودع (repository). .gitignore و.dockerignore منذ أول commit، لا الخمسين. المفتاح الذي وقع يومًا في commit يُعدّ مخترقًا حتى بعد إعادة كتابة ذلك الـcommit، لأن الكائن (object) يبقى موجودًا في النُّسخ (clones) والتفريعات (forks). دَوِّره (rotate) بدلًا من إعادة كتابة التاريخ.
قيّد ما يمكن للملف الوصول إليه. اجعل ملف البيئة مملوكًا لمستخدم الخدمة واضبط الصلاحية 600. وبالجمع مع مستخدم خدمة غير root، فإن تبعية مخترقة في مكان آخر من الجهاز لا يمكنها ببساطة قراءة مفاتيحك من القرص.
حدّد نطاق كل مفتاح عند جهة إصداره. مفتاح واحد لكل وكيل، بأضيق الصلاحيات التي يتيحها المزوّد — قراءة فقط حيث تكفي القراءة، وتعطيل السحب على مفاتيح المنصّات (exchange)، وتقييد الوصول بعنوان IP الخادم (IP-allowlist). عنوان IP ثابت هو ميزة هادئة للانتقال من الحاسوب المحمول: تقييد الوصول بقائمة سماح يصبح ممكنًا أخيرًا. وإذا احتاج عدة أشخاص إلى بيانات الاعتماد نفسها، ضعها خلف الخزنة ذاتية الاستضافة في الدليل المرافق.
الجدولة. الحلقات، والمؤقّتات، والمنطقة الزمنية التي تفاجئك.
«العمل باستمرار» يصف في الواقع ثلاث معماريات مختلفة، واختيار الخطأ منها مصدر شائع للعمل المكرر والتشغيلات الفائتة.
الحلقة المقيمة (resident loop). عملية واحدة طويلة العمر تنام بين الدورات. الأبسط للتفكير فيها، والخيار الافتراضي الصحيح. نقطة ضعفها هي الحالة (state): كل ما في الذاكرة يُفقد عند إعادة التشغيل، لذا فأي شيء يجب أن ينجو من عطل ينبغي أن يكون في SQLite أو Postgres، لا في متغيّر.
التشغيلة المجدولة. عملية تبدأ، وتنجز وحدة عمل واحدة، ثم تخرج. مؤقّت systemd مع OnCalendar هو الأداة الأفضل هنا، أساسًا بفضل Persistent=true: فبعد فترة توقف، يُطلق المؤقّت الدائم (persistent) التشغيلة التي فاتته، بينما cron يتخطاها ببساطة.
الطابور (queue). منتِج (producer) يضع مهامًا في الطابور، وعمّال (workers) يستهلكونها. هذا ما تريده لحظة تصل فيها المهام أسرع مما تُنجز. كما يمنحك إعادة محاولات (retries)، ومعالجة الرسائل الميتة (dead-letter)، وسقفًا للتزامن (concurrency).
قاعدتان أيًّا كان اختيارك. اجعل كل مهمة قابلة للتكرار دون أثر جانبي (idempotent) — فالمُشرِف الذي يعيد التشغيل عند العطل سيعيد محاولة المهام، والمهمة المُعاد تنفيذها يجب ألا تنشر مرتين أو تطلب مرتين. واترك ساعة الخادم على UTC، ولا تُحوّلها إلا عند الأطراف (edges): فجدول ينزاح بساعة مرتين في السنة عطل مزعج يصعب تعقّبه.
منح الوكيل أدوات. خادم أدوات على الجهاز نفسه.
الوكيل بلا أدوات هو مجرد حلقة محادثة. الأدوات هي ما يتيح له قراءة مستودع، أو استعلام قاعدة بيانات، أو تقديم طلب، أو فتح تذكرة (issue) — وبمجرد أن يعيش الوكيل على خادم، ينبغي أن تعيش الأدوات هناك أيضًا.
أصبح Model Context Protocol (MCP) الطريقة الشائعة لعرض تلك الأدوات، وخادم تُشغّله بشكل خاص يسهل وضعه إلى جانب الوكيل: نفس الجهاز، نفس الواجهة الخاصة، دون حاجة لأي تعريض عام. الأدلة المرافقة تغطي الأمر بتفصيل كافٍ — استضافة خادم MCP بعيد يستعرض TLS، ونقل streamable-HTTP، وOAuth، وبطاقة الوكيل (agent card)، بينما زاوية الاستضافة دون هوية تغطي المكدّس نفسه من جانب الهوية.
اربطه بـlocalhost أولًا. إذا كان المستهلك الوحيد هو الوكيل على الجهاز نفسه، فلا داعي لأن يحجز خادم الأدوات منفذًا (port) عامًا. اربطه بعنوان loopback وتخطَّ الشهادة. لا تعرضه للعامة إلا حين تحتاجه آلة ثانية — وعندها يحتاج إلى TLS ومصادقة معًا، لا إلى أحدهما فقط.
امنح الأدوات أقل صلاحية تفي بالغرض. يقرر الوكيل أي أداة يستدعي بناءً على نص، وبعض ذلك النص يأتي من الخارج. حقن التعليمات (prompt injection) ليس افتراضًا نظريًا لوكيل يقرأ صفحات ويب أو صناديق بريد: إنه الحالة المتوقعة. الأداة التي لا تستطيع سوى القراءة لا يمكن إقناعها بالكتابة. وحيثما يجب أن تكتب أداة، اجعل المسارات المُدمِّرة تتطلب تأكيدًا بشريًا.
إذا كنت تبني أدوات لوكلاء أشخاص آخرين لا لوكيلك أنت، فإن واجهة API الآلية (machine API) والواجهة الموجَّهة للوكلاء توثّقان كيف تعرض هذه المنصة عملية التزويد (provisioning) لوكيل مباشرة.
قابلية الملاحظة (observability) والتكلفة. ما يجب تسجيله، وزرّ الإيقاف الطارئ للانفلات.
نمطا فشل يهيمنان على عمليات نشر الوكلاء الحقيقية، وليس أي منهما عطلًا. الأول هو الوكيل الذي يعمل بشكل مثالي ولا ينتج شيئًا مفيدًا. والثاني هو الوكيل الذي يعمل بشكل مثالي وينتج فاتورة API من أربعة أرقام خلال ليلة واحدة.
سجّل الشكل، لا المحتوى. الطابع الزمني، معرّف المهمة، عدد الخطوات، أسماء الأدوات المُستدعاة، إجمالي الرموز (tokens)، المدة، والنتيجة. هذا يجيب عن كل سؤال تشغيلي ستطرحه فعلًا. أما التعليمات والنتائج الكاملة فهي نسخة كاملة لكل ما طُلب من الوكيل فعله على الإطلاق، بنص صريح، على قرص في مبنى شخص آخر.
حدّد سقفًا للاحتفاظ (retention). يستمر journald في النمو حتى تخبره بالتوقف. يضع SystemMaxUse وMaxRetentionSec في journald.conf سقفًا على كل من الحجم والعمر. وإلا فإن وكيلًا ثرثارًا يملأ القرص خلال أسابيع، والقرص الممتلئ يتعطل بطرق أصعب في القراءة بكثير من عطل نظيف.
ثلاث طبقات للتحكم في الإنفاق. عند المزوّد، سقف صارم على مفتاح API — وهو الحد الوحيد الذي لا يمكن لأي خلل في شيفرتك تجاوزه، وهو ما يتخطاه الناس غالبًا. داخل الوكيل، عدّاد رموز (tokens) لكل تشغيلة مع عتبة إيقاف. حول الوكيل، عدد أقصى للخطوات ومهلة زمنية فعلية، بحيث يتوقف نموذج يجادل نفسه بعد عشرين تكرارًا لا بعد أربعة آلاف.
ابنِ زرّ الإيقاف الطارئ قبل أن تحتاجه. أمر واحد يوقف كل شيء: systemctl stop agent، أو docker compose down. تأكد من أنه لا يتطلب حاسوبًا محمولًا يحمل مفتاحًا معينًا. الفرق بين ليلة سيئة وشهر سيء هو ما إذا كان إيقاف وكيل منفلت يستغرق عشر ثوانٍ أو ساعة.
الحدّ الأدنى للهوية. ما يعرفه المستضيف — وما لا يمكنه حمايتك منه.
الوكيل عملية طويلة العمر تحمل بيانات اعتماد، وتتصرف نيابة عنك من عنوان ثابت، باستمرار. هذا يجعل سجل الإيجار أكثر أهمية مما هو عليه بالنسبة لموقع ويب ثابت: فهو يقوم بأمور تُنسب إليك، كل ساعة، لأشهر.
الحد الأدنى هنا هو عنوان بريد إلكتروني وكلمة مرور للتسجيل، ودفع بثمانية أصول — Bitcoin وEthereum وTether على سلسلتين وMonero وLitecoin وTRON وSolana — ودون أي وثيقة هوية في أي مرحلة. تقع مراكز البيانات في أربعة أنظمة دستورية إسكندنافية: Stockholm وHelsinki وOslo وReykjavík. عقيدة التشغيل (operating doctrine) تحدد ما يُحتفظ به؛ وصفحة الشبكة تغطي التوجيه (routing).
والآن الحدّ، وهو أهم من العرض التسويقي. مستضيف لا يطلب هوية يزيل سجل الإيجار. لكنه لا يمسّ طبقة الاستدلال: وكيلك يوثّق هويته لدى مزوّد النموذج بمفتاح مرتبط بحساب، من عنوان IP ثابت، في كل استدعاء. وإذا كان ذلك الحساب باسمك القانوني — وهو الحال بالنسبة لمعظم الناس — فإن الهوية تُثبَت هناك بصرف النظر عمّن يستأجر العتاد. طبقة الاستضافة تزيل حلقة واحدة: حلقة حقيقية، وواحدة فقط.
وما يترتب على ذلك غير برّاق. جزّئ الأمور (compartmentalise): وكيل واحد، خادم واحد، مفتاح واحد، محفظة واحدة. حصّن الجهاز في اليوم الأول لا في اليوم الثلاثين — قائمة الساعة الأولى ساعة تُستثمر جيدًا على جهاز يعمل دون مراقبة لأشهر. وإذا كان على الوكيل الوصول إلى شبكة خاصة، فأنهِ الاتصال على الخادم عبر نفق (tunnel) بدلًا من تعريض الخدمات — دليل الأنفاق يغطي الإعداد. وادفع بالعملات المشفرة من محفظة ليست تلك التي يتداول منها وكيلك.
لا شيء من هذا غريب، ولا شيء منه ضمانة. إنه الانضباط العادي لتشغيل شيء يتصرف نيابة عنك بينما أنت نائم — وهذا هو كل ما يعنيه «التشغيل المتواصل». بقية المجموعة موجودة على فهرس الأدلة.
أسئلة، أجوبة.
سبعة أسئلة يطرحها المطورون قبل نقل وكيل من localhost — وخلال الشهر الأول بعد ذلك.
ما حجم VPS الذي أحتاجه لتشغيل وكيل ذكاء اصطناعي 24/7؟
أقل مما يتوقعه الناس، لأن الاستدلال (inference) يجري على عتاد المزوّد، لا على عتادك أنت. الوكيل الذي يستدعي واجهة برمجة تطبيقات (API) لنموذج مستضاف ويُشغّل حلقة استطلاع (polling loop) هو عملية مقيدة بالإدخال/الإخراج (I/O-bound): فئة Sentinel (2 vCPU، 4 GB RAM، 120 GB NVMe، $3.90/month) تفي بالغرض بارتياح. انتقل إلى Garrison (4 vCPU، 8 GB، $7.90/month) بمجرد إضافة Postgres وطابور مهام (queue) ونموذج تضمين (embedding) محلي.
هل يجب أن أستخدم systemd أم Docker لإبقاء الوكيل يعمل؟
كلاهما يعمل؛ لكن أنماط الفشل تختلف. وحدة systemd مع Restart=always هي أقصر طريق لعملية واحدة، وتمنحك journald وحدود الموارد وترتيب الإقلاع مجانًا. أما Docker مع restart: unless-stopped فأفضل حين يكون للوكيل «إخوة»، لأن Compose يصف المجموعة كاملة في ملف واحد. الأهم من كل هذا هو أن تُفعّله (enable) فعلاً، وأن تختبر إعادة إقلاع قبل أن تترك الأمر.
لماذا يتوقف وكيلي عن إعادة التشغيل بعد بضعة أعطال؟
لأن systemd يحدّ من معدل إعادة التشغيل. يسمح كل من StartLimitBurst وStartLimitIntervalSec بعدد صغير من إعادات التشغيل ضمن نافذة زمنية قصيرة؛ وتجاوزهما يجعل الوحدة تدخل الحالة failed وتبقى فيها، وهو ما يبدو تمامًا كموت صامت. إما أن تصلح العطل الجذري — وهذا هو الجواب الصحيح — أو تضبط StartLimitIntervalSec=0 لتعطيل المحدِّد وRestartSec=10 حتى لا يستهلك وكيل عالق في حلقة أعطال نواة معالج كاملة وهو يعيد المحاولة.
أين أضع مفاتيح API؟
في ملف لا تراه صورة الحاوية أبدًا. احتفظ بملف بيئة (environment file) خارج سياق البناء (build context)، يُشار إليه عبر EnvironmentFile= في وحدة systemd أو env_file: في Compose، ومملوك لمستخدم الخدمة بصلاحية 600. لا تستخدم أبدًا ENV أو ARG في Dockerfile لسرّ ما: فهذه القيم تُخبز داخل طبقات الصورة ويمكن قراءتها عبر docker history. أضف الملف إلى .gitignore و.dockerignore قبل أول commit.
كيف أمنع الوكيل من إنفاق كامل ميزانية API خلال ليلة واحدة؟
ثلاث طبقات، وتحتاجها كلها. عند المزوّد: سقف إنفاق صارم على مفتاح API، وهو الحد الوحيد الذي لا يمكن لأي خلل في شيفرتك تجاوزه. داخل الوكيل: عدّ الرموز (tokens) أو الاستدعاءات لكل تشغيلة وأوقفها عند تجاوز عتبة معينة. حول الوكيل: سقف لعدد الخطوات لكل مهمة ومهلة زمنية فعلية (wall-clock timeout). لا يستطيع أي مستضيف القيام بهذا نيابة عنك — فـ VPS هو سعة مستأجرة، لا حارس ميزانية على واجهة API تابعة لطرف آخر.
ما الذي لا يجب أن تكتبه أبدًا في سجلات الوكيل؟
التعليمات (prompts) والنتائج الكاملة، ووسائط الأدوات الخام، ومفاتيح API، ومواد المحفظة، وأي شيء كتبه مستخدم. سجّل بدلًا من ذلك «شكل» التشغيلة: الطابع الزمني، معرّف المهمة، عدد الخطوات، أسماء الأدوات، إجمالي الرموز، المدة، والنتيجة. سجل الوكيل المُسهب هو نسخة كاملة لكل ما طُلب من الوكيل فعله على الإطلاق، بنص صريح، على قرص لا تتحكم فيه ماديًا.
هل يجعل المستضيف الخالي من KYC وكيلي مجهول الهوية؟
لا، ويستحق الأمر أن نكون دقيقين. التسجيل دون وثيقة هوية والدفع بالعملات المشفرة يعنيان أن المستضيف لا يملك هوية قانونية يربطها بالخادم. لكن هذا لا يغيّر شيئًا تجاه مزوّد النموذج: وكيلك يوثّق هويته لدى تلك الواجهة بمفتاح مرتبط بحساب، من عنوان IP ثابت للخادم، في كل استدعاء. طبقة الاستضافة تزيل حلقة واحدة من السلسلة — سجل الإيجار — وهذا كل ما تزيله.
استأجر VPS بدون KYC، وادفع بالعملات المشفرة، وانقل الوكيل من حاسوبك المحمول الليلة.
Sentinel — 2 vCPU، 4 GB RAM، 120 GB NVMe، نطاق ترددي غير محدود، $3.90/month — يحمل وكيلًا بحلقة واحدة مع متسع لخادم أدواته بجانبه. عنوان بريد إلكتروني وكلمة مرور للتسجيل؛ دون أي وثيقة في أي مرحلة.
آخر مراجعة · 2026-08-24 · المصادر · صفحات دليل systemd.service وsystemd.timer وjournald.conf، وتوثيق Docker restart-policy وCompose، ومواصفة Model Context Protocol، وكتالوج NordBastion · الدورية · سنوياً
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Docker Compose، وPostgreSQL، وwebhooks تعمل — أتمتة تملكها أنت.
Ollama على CPU بلا GPU — ما يلائم 4 أو 8 أو 16 أو 32 GB.