OpenCode على الخادم: كيف تجعل وكيل الذكاء الاصطناعي يعمل بينما تنام

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

لماذا هذا ممكن أصلًا

يعتمد OpenCode في بنيته الداخلية على مخطط العميل والخادم. تتواصل واجهة TUI مع خادم HTTP محلي ينشر مواصفة OpenAPI على المسار /doc. ويشغّل الأمر opencode serve الخادم نفسه بلا واجهة. يستمع افتراضيًا على 127.0.0.1:4096، ويمكن تغيير العنوان والمنفذ بالخيارين --hostname و--port. ويمكن الوصول إليه من CI أو cron أو أي سكربت آخر، كما يمكن إبقاؤه «دافئًا» كي لا تدفع ثمن البدء البارد لـ MCP وLSP.

إذا كان الخادم متاحًا من خارج localhost فعليك ضبط OPENCODE_SERVER_PASSWORD. سيُفعَّل HTTP basic auth، واسم المستخدم الافتراضي opencode. لكن كلمة المرور وحدها لا تكفي: ضع الخادم خلف nginx أو Caddy مع HTTPS، وإلا فإن basic auth عبر HTTP المكشوف لا يحمي إلا من المسح العشوائي.

أين يفيد ذلك

أبسط سيناريو هو CI/CD ومراجعة طلبات الدمج. عبر تطبيق GitHub يكفي ذكر /opencode أو /oc في تعليق، فيبدأ الوكيل في GitHub Actions runner ويقرأ السياق ويفتح PR بالإصلاح عند الحاجة. وبدون التطبيق تُكتب في workflow خطوة بالأمر opencode run --standalone: ففي CI لا توجد TUI قيد التشغيل، وسيشغّل الأمر بنفسه خادمًا خاصًا للمهمة. مخرجات النماذج غير حتمية، لذا لا ينبغي تكليف الوكيل بالتقييم وفق مقياس، لكنه مناسب تمامًا للمراجعة.

السيناريو الثاني هو المهام الليلية. يستخدم الملحق opencode-scheduler خدمة launchd على macOS وsystemd على Linux، مع cron كخيار احتياطي. يمكن جدولة تدقيق يومي للاعتماديات أو تقرير عن git log ثم نسيانه. والثالث هو خادم مشترك للفريق: ملحقات IDE أو واجهة ويب أو جسر Telegram تتصل بعملية واحدة وترى الجلسات نفسها.

Systemd أم Docker

على VPS نظيف تكفي وحدة systemd بالأمر opencode serve. الفخ الرئيسي هو PATH. خدمات systemd لا ترث PATH من الصدفة (shell) لديك، لذلك لا يُعثر على OpenCode نفسه ولا على كل ما يستدعيه الوكيل عبر bash: git وnode وrg وmake. حدّد Environment=PATH=... وHOME صراحةً.

يوفر Docker عزل نظام الملفات وقابلية التكرار. ثبّت إصدارًا محددًا للصورة، واربط workspace بوحدة تخزين (volume) منفصلة، والإعدادات والجلسات بأخرى. لكن هذا تأمين ضد rm العرضي، لا ضد هروب متعمّد.

الصلاحيات والمزوّدون والأمان

يُربط المزوّد عبر @ai-sdk/openai-compatible: يناسب أي نقطة نهاية متوافقة، من Ollama المحلي إلى بوابة سحابية. يستخدم المثال في المقال BotHub، وهو راعي المادة. الأفضل ألا تخزّن مفتاح API في الإعدادات، بل تضعه عبر opencode auth login. وللمهام المساعدة مثل عناوين الجلسات حدّد small_model رخيصًا.

لا ينبغي ترك القاعدة ask على الخادم: قد ينتظر opencode serve ساعات ردًّا لن يأتي. استخدم قواعد allow محددة فوق deny، أو الخيار --auto الذي يحوّل ask إلى allow مع الإبقاء على deny.

والأهم: ينص SECURITY.md صراحةً على أن OpenCode ليس بيئة معزولة (sandbox)، وأن نظام الصلاحيات مجرد تجربة استخدام (UX). خوادم MCP الخارجية تقع خارج حدود الثقة، وقد أكدت ذلك حادثة حديثة لخادم MCP خبيث نفّذ شيفرة عبر OAuth. ومشكلة أخرى هي Bun: فهو يقرأ HTTP_PROXY بشكل غير مستقر، ولا يفهم socks5://، وبدون NO_PROXY لـ localhost قد يدخل الوكيل في حلقة على طلباته الخاصة.

المراقبة والخلاصة

يوجد فحص صحة /global/health، وسجلات في journald أو Docker، ويرسل الملحق opencode-otel التتبعات إلى Jaeger أو Grafana Tempo أو Datadog أو Langfuse. وفي CI يفيد الأمر opencode run --format json. راقب استهلاك التوكنات: ففي الليل يعمل الوكيل دون إشراف.

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