كيفية جدولة وكلاء الذكاء الاصطناعي للعمل ليلاً على خادم VPS

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

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

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

النسخة المختصرة

• تأتي كل واجهة سطر أوامر رئيسية لوكلاء البرمجة بوضع غير تفاعلي موثّق ينفّذ موجّهًا واحدًا حتى النهاية ثم ينتهي. في Claude Code هو claude -p، وفي Codex CLI هو codex exec، وفي Gemini CLI هو gemini -p. هذا ليس حلاً بديلاً، بل ميزة رسمية من المطوّر نفسه.
• يمتلك Claude Code جدولته الخاصة أيضًا: Routines، والمهام المجدولة في Desktop، و /loop. بالنسبة لبعض القرّاء يكفي ذلك فعلاً، وهو أقل صيانة من خادم VPS.
• يؤدي cron مهمته جيدًا لوظيفة ليلية. أما مؤقت systemd فهو الخيار الافتراضي الأفضل على جهاز قد يُعاد تشغيله، لأن Persistent=true يلتقط تشغيلاً كان cron سيتخطاه بصمت.
• واجهة سطر الأوامر نفسها خفيفة لأن الاستدلال يجري على واجهة برمجة المزوّد. حدّد حجم خادم VPS بحسب الأوامر التي سينفّذها (الاختبارات، عمليات البناء، الحاويات، المهام المتوازية)، لا بحسب النموذج.
• الضوابط (أدوات محدودة النطاق، وسقف لعدد الجولات، والتفرّع حسب رمز الخروج) هي ما يجعل ترك الجدولة تعمل وحدها أمرًا آمنًا. الجدولة بحد ذاتها ليست آلية الأمان.

ما الذي ستحتاجه

جهّز هذه الأشياء الخمسة قبل كتابة أي سطر في crontab أو أي ملف وحدة:

• خادم VPS يمكنك الاتصال به عبر SSH ويعمل بتوزيعة Linux قائمة على systemd.
• واجهة سطر أوامر الوكيل مثبّتة على ذلك الخادم: Claude Code أو Codex CLI أو Gemini CLI.
• بيانات اعتماد غير تفاعلية لواجهة سطر الأوامر التي تختارها. لا يقرأ وضع bare في Claude Code أي تسجيل دخول للحساب، لذا يحتاج إلى ANTHROPIC_API_KEY في بيئة التشغيل، أو apiKeyHelper في إعداداته. أما التشغيل العادي في وضع الطباعة و Codex و Gemini فيمكنها أيضًا استخدام بيانات اعتماد الحساب الموثّقة.
• مستودع أو مجلد مهام سيعمل عليه الوكيل.
• وصول إلى الطرفية بصلاحية تعديل crontab أو كتابة ملف وحدة systemd.

تشغيل وكيل دون جلسة متصلة

تأتي كل واجهة سطر أوامر رئيسية لوكلاء البرمجة بوضع غير تفاعلي مصمّم لهذا الغرض بالضبط. يقبل Claude Code الخيار -p، ويُكتب أيضًا --print. ويقبل Codex CLI codex exec. ويقبل Gemini CLI -p، ويُكتب أيضًا --prompt. يقبل كل منها موجّهًا وينفّذه حتى النهاية ثم ينتهي. لا حلقة محادثة، ولا طرفية يجب إبقاؤها مفتوحة، ولا شيء تعود للاتصال به.

هل يمكن تشغيل Claude Code دون جلسة نشطة؟ نعم. تمرير -p يشغّل الموجّه في وضع غير تفاعلي: ينفّذه Claude Code حتى النهاية، ويطبع النتيجة، ثم ينتهي. لا توجد حلقة محادثة ولا شيء يجب إبقاؤه حيًا، وهو يعمل على نفس Agent SDK الذي يشغّل الواجهة التفاعلية، وفق توثيق Anthropic الخاص بالوضع بلا واجهة.

أعلام Claude Code نفسها هي الأهم هنا، لأنها ما ستكتب حولها سكربتاتك فعليًا. اثنان منها يسمحان للتشغيل بالمضي دون التوقف لطلب إذن لا يوجد أحد مستيقظ ليمنحه: --allowedTools، الذي يوافق مسبقًا على أدوات محددة، و --permission-mode، الذي يحدد المستوى الأساسي للتشغيل بأكمله. --max-turns يحدّ عدد الجولات التي يمكن أن يأخذها التشغيل قبل أن ينتهي بخطأ.

--bare يتخطى الـ hooks والمهارات والإضافات وخوادم MCP وتعليمات المشروع مثل CLAUDE.md، من أجل تشغيل مبرمج أسرع وأكثر حتمية. وهذا يعني أيضًا أن كل تعليمة تعتمد عليها المهمة يجب أن تكون حاضرة في الموجّه أو في الأمر. كما أن وضع bare لا يقرأ تسجيل دخول حسابك، لذلك تنصّ وثائق Anthropic على ضبط مفتاح واجهة برمجة في بيئة التشغيل قبل تشغيله. يرفض Claude Code الخيار --bg تمامًا عند دمجه مع -p، ويرفض --cloud بالطريقة نفسها عندما تعطيه وصف مهمة. يذكر التعارض ويتوقف بدلاً من القيام بشيء غامض.

مثال تشغيل كامل، عدّل الموجّه وقائمة الأدوات بما يناسب مهمتك:

claude --bare -p "Review open PRs in this repo and summarize any blockers in NOTES.md" \
  --allowedTools "Bash(gh pr list *),Bash(gh pr view *),Bash(gh pr diff *),Read,Edit" \
  --permission-mode dontAsk \
  --max-turns 8 \
  --max-budget-usd 5.00 \
  --output-format json

اضبط الميزانية وأنماط الأوامر بما يناسب المهمة؛ كما يفترض هذا المثال أن مصادقة GitHub CLI مُعدّة مسبقًا للحساب الذي يشغّله.

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

وضع exec في Codex CLI، الموصوف في توثيق OpenAI للوضع غير التفاعلي، ويقبل --sandbox لاختيار سياسة. read-only هو الوضع الافتراضي، workspace-write يسمح للوكيل بالكتابة داخل مساحة عمله، و --json يحوّل stdout إلى تدفق أحداث قابل للتحليل آليًا بدلاً من نص عادي. تجنّب danger-full-access في مهمة بلا إشراف إلا إذا كانت العملية معزولة وكان ذلك الخطر مقصودًا.

وضع Gemini CLI بلا واجهة، الموثّق في توثيق المشروع نفسه للوضع بلا واجهة، يُفعَّل تلقائيًا في بيئة بلا TTY، أو صراحةً عبر -p. ينتهي برمز غير صفري محدد لكل من الخطأ العام وخطأ الإدخال وبلوغ حد الجولات، بدلاً من رمز فشل عام واحد.

أين ينبغي أن تعيش الجدولة

قبل كل أعمال الإعداد هذه: قد يوفّر لك مزوّد الوكيل الجدولة أصلاً. يقدّم Claude Code ثلاثة خيارات مدمجة، وقد يكون أحدها بالفعل أنسب من خادم VPS تديره بنفسك.

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

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

يستحق خادم VPS الذي تديره بنفسك مكانه عندما تحتاج المهمة إلى وصول كامل لنظام الملفات المحلي وللأدوات، أو عندما تريد الآلية نفسها تعمل بالطريقة ذاتها عبر Claude Code و Codex CLI و Gemini CLI، أو عندما يكون الفاصل الزمني الذي يسمح به Routines خشنًا أكثر من اللازم. عادةً ما تكون دالة serverless التقليدية غير ملائمة هنا، لأنها مضطرة لاستعادة بيانات الاعتماد واستنساخ المستودع والانتهاء ضمن حدود زمن التشغيل في المنصة. ويظل مشغّل CI مؤقت مثل GitHub Actions مسارًا ثالثًا صالحًا عندما يكون checkout جديد في كل تشغيل مقبولاً. وإذا كان لديك عتاد يعمل دائمًا وغير مستغل، فجهاز في مختبرك المنزلي يفي بالغرض أيضًا؛ المقايضة هنا هي الاعتماد على موثوقية شبكتك المنزلية ووصولك عن بُعد بدلاً من موثوقية مزوّد.

cron أم مؤقت systemd؟

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

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

# /usr/local/bin/agent-nightly
#!/usr/bin/env bash
set -euo pipefail
export PATH=/usr/local/bin:/usr/bin:/bin
export ANTHROPIC_API_KEY="$(
  cat "$HOME/.config/agent-nightly/anthropic_api_key"
)"
cd /srv/myrepo
exec /usr/local/bin/claude --bare -p \
  "Run the nightly dependency audit and write the findings to NOTES.md" \
  --allowedTools "Bash(npm audit *),Read,Edit" \
  --permission-mode dontAsk \
  --max-turns 8 \
  --max-budget-usd 5.00 \
  --output-format json

# crontab -e
0 2 * * * /usr/bin/flock -n "$HOME/.local/state/agent-runs/nightly.lock" /usr/local/bin/agent-nightly >> "$HOME/.local/state/agent-runs/nightly.log" 2>&1

أنشئ مجلدي بيانات الاعتماد والسجلات مرة واحدة، ثم اجعل سكربت الغلاف قابلاً للتنفيذ:

install -d -m 700 \
  "$HOME/.config/agent-nightly" \
  "$HOME/.local/state/agent-runs"
touch "$HOME/.config/agent-nightly/anthropic_api_key"
chmod 600 "$HOME/.config/agent-nightly/anthropic_api_key"
"${EDITOR:-nano}" \
  "$HOME/.config/agent-nightly/anthropic_api_key"
sudo chmod 755 /usr/local/bin/agent-nightly

الصق مفتاح واجهة البرمجة وحده في ملف بيانات الاعتماد. لا تضعه مباشرةً في crontab.

يتطلب مؤقت systemd إعدادًا أكثر، لكنه يمنحك شيئين لا يوفّرهما cron: التسجيل عبر journald دون إعادة توجيه يدوية، و Persistent=true. يفترض المثال أدناه أن حسابًا مخصصًا باسم agent-runner يملك /srv/myrepo. خزّن مفتاح واجهة البرمجة في ملف بيانات اعتماد متاح لـ root فقط بدلاً من تضمينه داخل الوحدة.

وفقًا لـ دليل systemd.timer، فإن ضبط Persistent=true يعني أن «وحدة الخدمة تُشغَّل فورًا إذا كان من المفترض أن تُشغَّل مرة واحدة على الأقل خلال الفترة التي كان فيها المؤقت غير نشط». وهكذا فإن تشغيلاً كان سينطلق بينما يعيد خادمك تشغيل نفسه لتحديث النواة ينطلق فور عودته، بدلاً من أن يختفي بصمت حتى الموعد التالي.

أنشئ ملف بيانات الاعتماد المتاح لـ root فقط الذي تستخدمه الخدمة:

sudo install -d -m 700 /etc/agent-nightly
sudo touch /etc/agent-nightly/anthropic_api_key
sudo chmod 600 /etc/agent-nightly/anthropic_api_key
sudoedit /etc/agent-nightly/anthropic_api_key

الصق مفتاح واجهة البرمجة وحده في الملف.

# /etc/systemd/system/agent-nightly.service
[Unit]
Description=Nightly scoped agent run
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent-runner
Group=agent-runner
WorkingDirectory=/srv/myrepo
Environment=HOME=/home/agent-runner
Environment=PATH=/usr/local/bin:/usr/bin:/bin
LoadCredential=anthropic_api_key:/etc/agent-nightly/anthropic_api_key
ExecStart=/bin/sh -c 'export ANTHROPIC_API_KEY="$(cat "$CREDENTIALS_DIRECTORY/anthropic_api_key")"; exec /usr/local/bin/claude --bare -p "Run the nightly dependency audit and write the findings to NOTES.md" --allowedTools "Bash(npm audit *),Read,Edit" --permission-mode dontAsk --max-turns 8 --max-budget-usd 5.00 --output-format json'
StandardOutput=journal
StandardError=journal
UMask=0077

# /etc/systemd/system/agent-nightly.timer
[Unit]
Description=Run agent-nightly.service at 2am daily, catching up missed runs

[Timer]
# Uses the VPS's configured local timezone
OnCalendar=*-*-* 02:00:00
Persistent=true
Unit=agent-nightly.service

[Install]
WantedBy=timers.target

أعد تحميل systemd، وفعّل المؤقت، وشغّل الخدمة مرة واحدة فورًا، حتى تظهر مشكلات بيانات الاعتماد والأذونات والمسارات الآن لا في الثانية صباحًا:

sudo systemctl daemon-reload
sudo systemctl enable --now agent-nightly.timer
sudo systemctl start agent-nightly.service
systemctl list-timers agent-nightly.timer
sudo journalctl \
  -u agent-nightly.service \
  -n 100 \
  --no-pager

Persistent=true هو الفارق الحاسم: يتذكّر المؤقت التشغيل التقويمي الفائت بدلاً من إسقاطه بصمت.

ما يحتاجه خادم VPS فعلاً

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

اعتبر من 1 إلى 2 vCPU ومن 2 إلى 4 غيغابايت من الذاكرة مع تخزين NVMe نقطة انطلاق لمهمة مجدولة خفيفة واحدة. أما المستودعات الكبيرة والمُصرِّفات وعمليات بناء Docker ومجموعات الاختبارات أو التشغيلات المتزامنة فقد تحتاج إلى أكثر من ذلك بكثير. ما يدفعك للترقية هو أثقل أمر محلي سينفّذه الوكيل، لا النموذج خلف واجهة البرمجة. وإذا كنت تشغّل أعباء Docker على هذا الخادم بالفعل وتريد صورة أوضح لما ينبغي رصده، تحديد حجم جهاز البناء وتأمينه يستعرض المقايضة نفسها لعبء عمل آخر يعمل بلا إشراف.

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

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

منع التشغيل بلا إشراف من الانحراف

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

علما الأذونات موجودان كي لا يتوقف التشغيل عند طلب إذن في الثانية صباحًا، لكن الوصول المفتوح إلى Bash ليس ضابطًا ضيقًا: فهو قادر على فعل كل ما يستطيع حساب الخدمة فعله تقريبًا. فضّل قواعد خاصة بأوامر بعينها مثل Bash(git status *)، واقرنها بـ --permission-mode dontAsk، وشغّل الخدمة تحت حساب مخصص غير جذري. ولكل من عدد الجولات والإنفاق سقفه الخاص: --max-turns يحدّ من مدى تجوال الوكيل، و --max-budget-usd يضع سقفًا لما يمكن أن ينفقه تشغيل واحد على استدعاءات واجهة البرمجة.

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

تجاوزات التكلفة في التشغيل بلا إشراف ليست افتراضية. في منشور على Hacker News، أبلغ مستخدم عن فاتورة إجمالية من AWS Bedrock بلغت 37,901.73 دولارًا نتيجة سير عمل يومي لوكيل برمجة كان فيه التخزين المؤقت للموجّهات فعّالًا جزئيًا فقط، ما ترك نحو 6.47 مليار رمز إدخال دون تخزين مؤقت. حدث ذلك في منظومة أخرى، لا في وضع Claude Code بلا واجهة، لكنه يوضّح لماذا ينتمي تسجيل التكاليف وميزانية صارمة لكل تشغيل إلى الجدولة نفسها.

نصيحة: ينتهي Claude Code بالرمز 0 عند النجاح وبرمز غير صفري عند الفشل. وسكربت غلاف يفحص حالة الخروج يمكنه إرسال إشعار لك عند الفشل، فتظهر الليلة السيئة في صباح اليوم التالي بدلاً من ثلاثة أيام لاحقًا حين تصادف أن تنظر.

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

الضوابط هي ما يجعل ترك الجدولة وشأنها أمرًا آمنًا: الجدولة بحد ذاتها ليست آلية الأمان.

متى يتوقف cron عن أن يكون كافيًا

موجّه واحد على مؤقت لا يحتاج إلى أكثر مما ورد هنا. أما ثلاث خطوات متسلسلة مع شرط وإعادة محاولة وإشعار Slack فتحتاج إلى شيء آخر.

ثلاثة خيارات تستحق المعرفة، كل منها خطوة أعلى لسبب مختلف:

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

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

أطر تنسيق الوكلاء المتعددين مثل LangChain أو CrewAI موضوع مختلف تمامًا: بناء أنظمة وكلاء، لا جدولة واجهة سطر أوامر موجودة أصلاً.

الأسئلة الشائعة

هل يمكن تشغيل Claude Code دون جلسة نشطة؟

نعم. تمرير -p يشغّل الموجّه في وضع غير تفاعلي: ينفّذه Claude Code حتى النهاية، ويطبع النتيجة، ثم ينتهي، دون حلقة محادثة ودون جلسة تبقى مفتوحة.

هل أحتاج إلى VPS إذا كان Claude Code يوفّر Routines أصلاً؟

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

هل أستخدم cron أم مؤقت systemd لوكيل مجدول؟

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

كم من الذاكرة يحتاج وكيل ذكاء اصطناعي مجدول على خادم VPS؟

ابدأ بحوالي 1 إلى 2 vCPU ومن 2 إلى 4 غيغابايت من الذاكرة لمهمة مجدولة خفيفة، ثم حدّد الحجم وفق أثقل أمر محلي سينفّذه الوكيل. فعمليات البناء والاختبارات و Docker والمستودعات الكبيرة والتشغيلات المتزامنة أهم بكثير من استدلال النموذج البعيد.

هل يغيّر تشغيل وكيل وفق جدول طريقة احتساب الفاتورة؟

لا تنشئ الجدولة نمط فوترة منفصلاً. فـ Claude Code -p يمكنه استخدام بيانات اعتماد الاشتراك أو مفتاح واجهة برمجة، لكن --bare يتجاهل تسجيل دخول الاشتراك، لذا يحتاج إلى ANTHROPIC_API_KEY في بيئة التشغيل، أو apiKeyHelper في إعداداته. أما Codex و Gemini فيتبعان طريقة المصادقة التي أعددتها لواجهة سطر الأوامر الخاصة بكل منهما. ولأن الأسعار وشروط الاستخدام تتغير بسرعة، راجع أسعار المزوّد الحالية وبيانات استخدامك الخاصة عند الإعداد. ولتشغيلات Claude Code عبر واجهة البرمجة، يمكنك أيضًا تسجيل حقل total_cost_usd من مخرجات JSON.