كيفية استضافة OneCLI ذاتيًا: Agent لكل شخص

ما تحصل عليه عند الاستضافة الذاتية لـOneCLI

عند الاستضافة الذاتية لـOneCLI، يحصل كل شخص في فريقك على agent خاص به. يعمل كل agent داخل sandbox مستقل. وتُحفظ مفاتيح API في gateway لا يستطيع agents قراءتها. يتكوّن التثبيت من مكدس Docker Compose مع PostgreSQL خلفه، ويمكن الوصول إليه على http://localhost:10254. خطط لاستخدام خادم فعلي مناسب. الإعداد الافتراضي الموثّق هو 2 GiB من الذاكرة لكل sandbox خاص بـagent، لذلك لا تناسب هذه المنظومة VPS بسعة 1 GB.

يتكوّن هذا المكدس من سبعة مكونات. ومعرفة وظيفة كل مكوّن تجعل قراءة بقية هذا الدليل أسهل.

• لوحة التحكم على الويب (Next.js)، على المنفذ 10254. إنشاء agents، والمحادثات، وتحرير الذاكرة والمهارات، وإدارة الاتصالات والأسرار.
• خادم API، على المنفذ 10256. مستوى التحكم: قاعدة البيانات، ومعالجة المحادثات، وقوائم العمل.
• بوابة Rust، على المنفذ 10255. تعترض الطلبات الصادرة من agents وتحقن بيانات الاعتماد.
• Runner. يصفه README بأنه المكوّن الذي «يبدأ sandboxes الخاصة بـagents ويوقفها وينهيها. وهو مخصّص للاتصالات الصادرة فقط، ولا يتعامل مطلقاً مع قاعدة البيانات».
• Sandbox Supervisor. يصفه README بأنه يعمل «داخل كل sandbox، ويتواصل عبر واجهة harness محايدة تجاه المورّد، بحيث يمكن تبديل runtime الخاص بـagent».
• محوّل القنوات. خدمة daemon تتصل بتطبيق Slack، بحيث يجيب agent في القنوات والرسائل المباشرة باسمه الخاص.
• PostgreSQL. يشغّل ملف compose المرفق postgres:18-alpine مع volume باسم pgdata.

الاسم يوحي بأنه CLI، لكن المنتج خادم

OneCLI منصة خادم. يوحي الاسم بأداة سطر أوامر تثبّتها على حاسوب محمول، لكن هذا التصور لا ينطبق على المنتج المشروح في هذا الدليل. يوجد عميل منفصل لسطر الأوامر في مستودع onecli/onecli-cli، وهو يمرّر حركة وكيل برمجي محلي عبر بوابة. أما ما تنشره هنا فهو تطبيق ويب متعدد المستخدمين: نظام حسابات يملك فيه الحساب الأول المثيل، وقاعدة بيانات للمحادثات والأسرار، ومشغّل يبدأ الحاويات.

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

ما يحتاجه الخادم قبل البدء

• Docker، مع Compose plugin بإصدار 2.19 أو أحدث. يستخدم ملف compose خدمة migrations تُشغَّل مرة واحدة وينتظرها API، ويتطلب شكل التبعية هذا الإصدار 2.19.
• الذاكرة، وهي القيد الفعلي. اقرأ قسم تحديد الحجم أدناه قبل اختيار الخطة.
• منافذ loopback شاغرة هي 10254 و10255 و10256 و5432.

لا تحتاج إلى تثبيت PostgreSQL بنفسك، لأن ملف compose يشغّله كخدمة. ولا تحتاج إلى Node.js أو Rust أيضاً. يُستخدم هذان البرنامجان فقط في مسار البناء من المصدر، حيث يثبّت mise toolchain.

كم عدد بيئات العزل الخاصة بالوكيل التي يمكن أن تستوعبها VPS لديك؟

تقدّم وثائق المشغّل أرقاماً فعلية بدلاً من التخمينات. تحصل كل بيئة عزل على 2048 MB من الذاكرة (RUNNER_SANDBOX_MEMORY_MB)، ووحدة CPU واحدة (RUNNER_SANDBOX_CPUS)، و512 عملية (RUNNER_SANDBOX_PIDS). يبلغ حد التزامن 4 (RUNNER_MAX_SANDBOXES)، وتوصي الوثائق بتوفير نحو 10 GiB من الذاكرة الحرة فوق الحزمة الأساسية لخدمة هذا الحد.

[
  {
    "plan": "2 GB box",
    "ram_gb": 2,
    "sandbox_slots": 0
  },
  {
    "plan": "4 GB box",
    "ram_gb": 4,
    "sandbox_slots": 1
  },
  {
    "plan": "8 GB box",
    "ram_gb": 8,
    "sandbox_slots": 3
  },
  {
    "plan": "16 GB box",
    "ram_gb": 16,
    "sandbox_slots": 7
  },
  {
    "plan": "32 GB box",
    "ram_gb": 32,
    "sandbox_slots": 15
  }
]

هذه الأعداد حسابية وليست نتيجة اختبار أداء: إجمالي الذاكرة، بعد طرح نحو 2 GB لـPostgreSQL والخدمات الأربع طويلة التشغيل، مقسوماً على حد 2 GiB لكل بيئة عزل. بناءً على ذلك، تستوعب 2 GB box عدد 0 من بيئات العزل، ولذلك لا تستطيع أرخص خطة تشغيل وكيل مستضاف على الإطلاق. تترك 16 GB box مساحة لـ7، وهو عدد يتجاوز بشكل مريح حد 4 الافتراضي، ويتجاوز أيضاً نحو 10 GiB من الذاكرة الحرة التي تطلبها وثائق المشغّل. تنقلك 32 GB box إلى 15.

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

ثبّت OneCLI باستخدام Docker Compose

يوثّق دليل الاستضافة الذاتية upstream هذا التسلسل الدقيق. يكتب ثلاثة أسرار في docker/.env بجانب ملف Compose، ثم يشغّل الـstack.

git clone https://github.com/onecli/onecli.git && cd onecli/docker
cat > .env <<EOF
SECRET_ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
GATEWAY_INTERNAL_SECRET=$(head -c 32 /dev/urandom | base64)
BETTER_AUTH_SECRET=$(head -c 32 /dev/urandom | base64)
COMPOSE_PROFILES=runner
EOF
chmod 600 .env
docker compose up -d --wait

اقرأ هذه الكتلة قبل تشغيلها. علامة heredoc غير مقتبسة، لذلك ينفّذ shell كل head -c 32 /dev/urandom | base64 ويكتب الناتج بدلاً من النص الحرفي. SECRET_ENCRYPTION_KEY هو مفتاح AES-256-GCM لكل سر في قاعدة البيانات. GATEWAY_INTERNAL_SECRET يصادق على البوابة مع API. BETTER_AUTH_SECRET يوقّع ملفات تعريف ارتباط الجلسات. COMPOSE_PROFILES=runner هو السطر الأهم، لأن خدمة runner تعمل خلف Compose profile: إذا حذفته، يبدأ الـstack بحالة سليمة، لكن لا يبدأ أي agent sandbox.

يُبقي --wait الـshell قيد الانتظار حتى تبلغ كل خدمة الحالة السليمة، لذلك يكون الخروج بقيمة غير صفرية أول إشارة إلى وجود مشكلة. بعد ذلك، افحص ما بدأ فعلياً.

docker compose ps
docker compose logs migrations

ثبّت الإصدار. يضبط ONECLI_VERSION الوسم لجميع الخدمات دفعة واحدة، وتتبع صورة agent sandbox هذا الوسم ما لم يشير RUNNER_AGENT_IMAGE إلى مكان آخر. في 19 August 2026، الإصدار الحالي هو v2.0.1، وقد نُشر في 18 August 2026. أضفه إلى الملف نفسه، ثم شغّل الـstack من جديد.

echo 'ONECLI_VERSION=v2.0.1' >> .env
docker compose up -d --wait

يتوفر أيضاً مثبت، وهو curl -fsSL https://onecli.sh/install | sh، يكتب إعداده في ~/.onecli/.env وينفذ العمل نفسه. مسار Compose هو المسار الذي يمكنك فيه قراءة كل ملف قبل تشغيل أي شيء، وهو المسار المناسب لخادم يشغّل Compose stacks أخرى مسبقاً. بناء البرنامج من المصدر هو مسار ثالث، موثّق بالترتيب كـpnpm install ثم pnpm run setup في المستودع المستنسخ. يتطلب هذا المسار mise، وRust للبوابة، وDocker على أي حال، وهو مخصص لمن ينوون تعديل الشفرة.

الوصول إلى لوحة التحكم من حاسوبك المحمول

يربط كل منفذ منشور في ملف Compose المرفق بـ ${ONECLI_BIND_HOST:-127.0.0.1}. على VPS، يعني ذلك أن لوحة التحكم قيد التشغيل، ولا يمكن لأي جهة خارج الخادم الوصول إليها. هذا الإعداد الافتراضي صحيح. أبقه كما هو، وأنشئ نفقاً:

ssh -N -L 10254:127.0.0.1:10254 you@your-server

افتح الآن http://localhost:10254 على حاسوبك المحمول. يمرّ traffic عبر اتصال SSH، لذلك لا توجد لوحة تحكم غير مشفّرة على الإنترنت العام، ولا حاجة إلى فتح منفذ إضافي في جدار الحماية.

يؤدي ضبط ONECLI_BIND_HOST=0.0.0.0 إلى نشر لوحة التحكم عبر HTTP غير المشفّر، كما ينشر PostgreSQL إلى جانبها. إذا احتاج عدة أشخاص إلى لوحة التحكم، فضع reverse proxy مع TLS (أمان طبقة النقل) أمام المنفذ 10254، واترك مضيف الربط كما هو. نفّذ ذلك قبل أن يصبح للمثيل مالك. توضّح الوثائق الأولية السبب صراحةً: "إلى أن تفعل ذلك، لا يكون للمثيل مالك، ومن يصل إليه أولاً يصبح مالكه." إذا كان reverse proxy يسبق تطبيقاتك الأخرى المستضافة ذاتياً، فإن تمرير المصادقة عبر طبقة تسجيل دخول موحّد مستضافة ذاتياً يضع لوحة التحكم خلف تسجيل الدخول الذي يستخدمه فريقك بالفعل، لذلك يؤدي حذف شخص من مكان واحد إلى إغلاق هذا الباب أيضاً.

إنشاء الحساب الأول، ثم منح مفتاح نموذج

افتح لوحة المعلومات وأنشئ الحساب فوراً. يملك هذا الحساب المثيل، وبعد إنشائه يتطلب الانضمام دعوة.

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

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

كيف يُبقي البوابة المفاتيح خارج الوكلاء

البوابة هي وكيل HTTPS مكتوب بلغة Rust ويستمع على المنفذ 10255. يُوجَّه عميل HTTP لدى الوكيل إليها، ويحمل الوكيل بيانات اعتماد بديلة بدلاً من بيانات اعتماد حقيقية. تطابق البوابة الطلب الصادر مع المنح المخصصة لذلك الوكيل، ثم تفك تشفير السر الحقيقي، وتستبدله في الطلب، وتعيد توجيه الطلب. تُخزَّن الأسرار في PostgreSQL مشفّرة باستخدام AES-256-GCM (معيار التشفير المتقدم، 256 بت، نمط غالوا/العداد)، ولا تُفك شفرتها إلا وقت الطلب. يُسجَّل كل استدعاء مع هوية الوكيل والوجهة، ما يوفّر مسار تدقيق لا يمكنك الحصول عليه عندما تكون المفاتيح موجودة في ملفات shell الشخصية لعشرة أشخاص.

تحدد آليتان طريقة نشرها.

• اعتراض HTTPS هو هجوم رجل في الوسط. تنشئ البوابة هيئة إصدار شهادات محلية، ويثق بها الوكيل، ثم تنهي البوابة اتصال TLS الخاص بالوكيل وتفتح اتصالاً جديداً مع الخدمة المصدر. لذلك يفشل الوكيل الذي لا يثق عميل HTTP لديه بهيئة إصدار شهادات البوابة بسبب خطأ في التحقق من الشهادة، لا بسبب خطأ في المصادقة.
• يعرّف الوكيل نفسه باستخدام ترويسة Proxy-Authorization. في جهاز واحد، حيث يشترك الوكلاء والبوابة في شبكة Docker داخلية، لا تعبر هذه الترويسة شبكة لا تملكها. إذا وجّهت وكيلاً خارج الجهاز إلى البوابة، فيحتاج منفذ الوكيل إلى TLS خاص به، لأن هذه الترويسة رمز لحاملها.

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

لماذا لا يحتاج runner إلى منفذ وارد

يعمل runner بالاتصالات الصادرة فقط. وتذكر وثائقه ما يلي: «لا يحتفظ بأي منافذ يمكن للعالم الخارجي الوصول إليها، لذلك يعمل على حاسوب محمول أو homelab أو VPC خلف NAT من دون دخول، أو نفق، أو حاجة إلى إنهاء TLS». وNAT هو ترجمة عناوين الشبكة، وهي الوظيفة التي ينفذها موجّه المنزل. يتصل runner بطبقة التحكم من الخارج ويسحب المهام منها، لذلك لا يوجد شيء لإعادة توجيهه ولا منفذ لفتحه.

يظهر أثر هذا التصميم في شبكة sandbox. يعرّف ملف compose شبكة ثانية تحمل العلامة internal: true، ما يعني في Docker عدم وجود مسار للخروج من المضيف إطلاقاً. تنضم إليها بيئات sandbox. ويتصل gateway بالشبكتين، لذلك يكون المسار الوحيد إلى الخارج. توضّح وثائق runner هذه النقطة مباشرة: «إن وجود شبكة internal يتصل بها gateway عبر واجهتين هو ما يجعل الخروج عبر gateway فقط حدّاً فعلياً، لا مجرد اقتراح». إذا قرر agent إرسال شفرتك المصدرية إلى عنوان يختاره، فلن يجد مساراً لتنفيذ ذلك.

تحقق من ذلك على جهازك بدلاً من الاعتماد على الفقرة السابقة.

docker network ls
docker network inspect onecli-sandboxes | grep -i internal

يجب أن ترى "Internal": true. إذا كانت النتيجة false، فهذا يعني أن التحكم في الاتصالات الصادرة متوقف، وأن gateway عاد مجرد اقتراح. استخدم اسم شبكة sandbox الذي تطبعه docker network ls، لأن onecli-sandboxes هو الاسم الافتراضي فقط.

ما مدى قوة sandbox في OneCLI؟

اقرأ هذا القسم ببطء، لأن وصف المشروع نفسه يستخدم كلمة «معزول» بمعنى واسع، بينما توثّق الآلية في موضع واحد فقط.

يذكر README أن كل agent يحصل على «sandbox معزول خاص به، يتضمن نظام ملفات وshell»، ويسمي Sandbox Supervisor المكوّن الذي «يعمل داخل كل sandbox، ويتحدث عبر واجهة harness محايدة تجاه المورّد، بحيث يمكن تبديل runtime الخاص بالـagent». لا توضح أي من الجملتين مكوّنات العزل. وتوضح وثائق runner ذلك: الواجهة الخلفية الافتراضية هي Docker (RUNNER_BACKEND=docker)، وsandbox عبارة عن حاوية Docker لها حد للذاكرة، وحد للمعالج، وحد لعدد العمليات، ومتّصلة بالشبكة الداخلية. ويتضمن الكود نقطة ربط لواجهات خلفية أخرى، وتذكر الوثائق أشياء مثل Kubernetes وmicroVMs كوحدات يجب على شخص ما كتابتها. حالياً، على جهازك، sandbox هي حاوية.

ما لا تقوله الوثائق مهم بالقدر نفسه. لا يوجد threat model. ولا يوجد بيان يوضح تشغيل Docker daemon دون root، أو إعادة تعيين user namespace، أو ملفات تعريف seccomp أو AppArmor التي تتجاوز الإعدادات الافتراضية في Docker. ولا يوجد ادعاء بوجود حد على مستوى kernel مثل gVisor أو microVM. لذلك التزم بالقراءة الضيقة. حدود الموارد هي حدود للموارد. والشبكة الداخلية وسيلة حقيقية للتحكم في الاتصالات الخارجة. أما العزل بين agent والمضيف، فهو العزل الذي توفره حاوية Docker قياسية، والحاوية تشارك kernel الخاص بالمضيف.

هناك حقيقة ثانية يجب أخذها في الاعتبار. يربط runner service المسار /var/run/docker.sock، لأن هذه هي الطريقة التي ينشئ بها sandboxes. ويعادل الوصول إلى Docker socket امتلاك root على المضيف، لأن من يستطيع استدعاء تلك الواجهة يمكنه تشغيل حاوية مع تركيب نظام ملفات المضيف داخلها. وكل runner يعتمد على Docker يعمل بهذه الطريقة. والنتيجة أن عملية runner حساسة بقدر حساسية gateway.

اعتبر هذا الحد غير مثبت إلى أن يكتب upstream تفاصيله. عملياً، يعني ذلك اتباع ثلاث عادات.

1. شغّل OneCLI على جهاز لا يؤدي أي وظيفة أخرى. لا تشغّل عليه خدمة إنتاج غير مرتبطة، أو قاعدة بيانات مشتركة، أو بيانات فريق آخر.
2. افترض أن agent الذي يحصل على تنفيذ تعسفي للكود داخل sandbox قد يصل إلى المضيف، واجعل هذا السيناريو قابلاً للتعافي باستخدام نسخ احتياطية محفوظة خارج الجهاز.
3. اقرأ apps/runner/src أو اسأل upstream قبل أن تخبر زميلاً بأن agent معزول.

للاطلاع على مثال يوضح كيف يبدو حد موثّق، ومعرفة الأسئلة التي تستحق طرحها على upstream، قارن ذلك مع شكل حد sandbox حقيقي لـagent. يكمن الفرق في أن شخصاً ما وثّق الآلية وما لا تمنعه.

انقسام التراخيص، ولماذا يجب التحقق قبل البناء

يخضع المكوّن الأساسي في OneCLI لترخيص Apache-2.0، ويُسمح باستضافته ذاتياً في بيئة الإنتاج. أما المجلدات التي تحمل الاسم ee/ فتخضع لترخيص OneCLI Enterprise License منفصل: وهي مجانية للتطوير والاختبار والتقييم، لكن استخدام الإنتاج يتطلب اشتراكاً. تشير ملاحظات الإصدار v2.0.1 الصادرة في 18 August 2026 إلى استعادة ملف ترخيص Apache-2.0 الذي يمكن لـGitHub اكتشافه، ولذلك تغيّرت الشارة في صفحة المستودع مؤخراً. تحقّق من الوسم الذي ستنشره فعلياً، ولا تعتمد على ملخص كُتب في تاريخ آخر.

cd onecli && find . -type d -name ee -not -path '*/node_modules/*'

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

الترقيات، وعمليات الترحيل، والملف الوحيد الذي لا يمكنك فقدانه

الترقية هي رفع الإصدار وإعادة التشغيل. تشغّل خدمة migrations لمرة واحدة قبل API في كل up، وإذا فشلت عملية ترحيل، ترفض المجموعة التشغيل بدلاً من تقديم الخدمة باستخدام مخطط قاعدة بيانات نُفِّذت عليه عملية ترحيل جزئية. هذا هو السلوك المطلوب، لأن الترقية الفاشلة تظهر عندئذٍ كتعطل للخدمة بدلاً من أن تؤدي إلى تلف صامت للبيانات، ويوضح docker compose logs migrations السبب.

cd onecli/docker
docker compose pull
docker compose up -d --wait
docker compose logs migrations

إذا ثبّت البرنامج باستخدام install script بدلاً من ذلك، فأعد تشغيل هذا البرنامج النصي بدلاً من السحب يدوياً، حتى يظل ملف Compose متوافقاً مع الصور التي يشير إليها.

أنشئ نسختين احتياطيتين لعنصرين. يحتفظ PostgreSQL بالوكلاء والمحادثات والذاكرة والأسرار المشفرة. ويحتوي ملف docker/.env على SECRET_ENCRYPTION_KEY، ومن دون ذلك المفتاح لا يمكن قراءة الأسرار المشفرة، لذلك لا تعيد نسخة قاعدة البيانات وحدها أي شيء صالح للاستخدام.

cd onecli/docker
docker compose exec -T postgres pg_dump -U onecli onecli | gzip > ~/onecli-db.sql.gz
install -m 600 .env ~/onecli-env.backup

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

عندما لا يعمل

• لا تصبح الحزمة سليمة أبداً، ويخرج docker compose up -d --wait بحالة غير صفرية. اقرأ docker compose logs migrations أولاً، لأن API ينتظر هذه الخدمة عمداً.
• يبقى أحد الوكلاء خاملاً ولا تظهر أي sandbox. تحقّق من وجود COMPOSE_PROFILES=runner في docker/.env، ومن أن docker compose ps يسرد runner. ثم تحقّق من حصول الوكيل على مفتاح model مُنح له، لأن sandbox لا يبدأ من دونه.
• لا توجد slots متبقية. القيمة الافتراضية لـRUNNER_MAX_SANDBOXES هي 4، وتحتفظ sandbox التي تشغّل عملية في الخلفية بـslot الخاصة بها بشكل دائم. يعرض docker ps ما يعمل فعلياً.
• تختفي الحاويات أو يصبح المضيف بطيئاً جداً. نفدت الذاكرة. يسجّل dmesg -T | grep -i oom عمليات القتل التي ينفذها kernel بسبب نفاد الذاكرة، ويمكن لـsandbox واحدة أن تحجز 2048 MB بمفردها.
• تفشل استدعاءات HTTPS التي يجريها أحد الوكلاء بأخطاء التحقق من الشهادة، وليس بأخطاء المصادقة. لا يثق عميل HTTP لديه بسلطة الشهادات الخاصة بالبوابة.
• تبقى حاويات أو volumes قديمة بعد حذف أحد الوكلاء. يجري runner عملية reconciliation كل 60 ثانية، ويحذف العناصر اليتيمة الأقدم من RUNNER_ORPHAN_GRACE_SECONDS، وتبلغ قيمته الافتراضية 3600؛ لذلك انتظر ساعة قبل اعتبار الأمر تسرّباً.

هل هذا هو الخيار المناسب لتشغيله؟

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

أما لشخص واحد، فهذه بنية كبيرة بلا فائدة فعلية. ستشغّل PostgreSQL وcontrol plane وgateway وrunner لتوفير agent واحد لنفسك، بينما تكاد مشكلة بيانات الاعتماد التي يحلها gateway لا تكون موجودة عندما تكون أنت وحدك من يملك المفتاح. شغّل harness واحداً على خادم أصغر بدلاً من ذلك: harness واحد لـ agent على VPS ينفذ المهمة نفسها باستخدام جزء من الذاكرة. وإذا لم تكن قد اخترت اتجاهاً بعد، فالمقارنة الواردة في مقارنة وكلاء AI المستضافين ذاتياً هي الخطوة الأولى الأقل تكلفة.

FAQ

ما الحد الأدنى لمتطلبات الخادم لاستضافة OneCLI ذاتياً؟

تحتاج إلى Docker مع Compose plugin بالإصدار 2.19 أو أحدث، وإلى ذاكرة كافية. يأتي PostgreSQL مع ملف compose، لذلك لا تحتاج إلى تثبيته بشكل منفصل. تحدد الذاكرة الخطة: يخصص runner افتراضياً 2048 MB لكل sandbox خاص بالوكيل، وتطلب وثائقه نحو 10 GiB من الذاكرة الحرة فوق متطلبات المكدس الأساسي لتشغيل الحد الافتراضي البالغ أربعة sandboxes، بينما يستهلك PostgreSQL والخدمات الأربعة طويلة التشغيل نحو 2 GB. يمكن لخادم بسعة 4 GB تشغيل وكيل واحد في كل مرة. ويغطي خادم بسعة 16 GB الحد الافتراضي بسهولة. ولا يستطيع VPS بسعة 1 GB أو 2 GB تشغيل hosted agent إطلاقاً.

هل يحتاج OneCLI إلى PostgreSQL، أم يمكنه استخدام SQLite؟

يحتاج إلى PostgreSQL. توثّق DATABASE_URL على أنها سلسلة اتصال PostgreSQL، ويشغّل ملف compose المرفق postgres:18-alpine مع volume باسم pgdata، كما تطبّق خدمة migrations منفصلة المخطط قبل بدء API. لا يوجد خيار موثّق لاستخدام SQLite. إذا كنت تشغّل PostgreSQL في مكان آخر، فوجّه DATABASE_URL إليه وأبقِ خدمة migrations مفعّلة، لأن فشل migration يوقف المكدس بدلاً من تشغيله بمخطط مطبّق جزئياً.

هل sandbox الخاص بوكيل OneCLI يمثل حدّاً أمنياً حقيقياً؟

الآلية الموثّقة هي Docker container مع حدود للذاكرة ووحدة المعالجة المركزية وعدد العمليات، ومتصلة بشبكة تحمل الوسم internal: true، بحيث لا يخرج منها أي مسار إلا عبر gateway. التحكم في الاتصالات الصادرة فعلي ويمكنك التحقق منه باستخدام docker network inspect. يوفر العزل عن المضيف مستوى عزل الحاويات، لكن المشروع upstream لا ينشر نموذج تهديد، ولا ادعاءً باستخدام rootless أو user namespace، ولا حداً على مستوى kernel مثل gVisor أو microVM. كما يربط runner المسار /var/run/docker.sock، وهذا يعادل امتلاك root على المضيف. اعتبر الحد الفاصل بين الوكيل والمضيف غير مثبت إلى أن يوضحه upstream، وشغّل OneCLI على خادم مخصص، واحتفظ بالنسخ الاحتياطية خارج ذلك الخادم.

هل أحتاج إلى فتح أي منافذ واردة لـ OneCLI؟

لا. يعمل runner بالاتصالات الصادرة فقط ولا يحتفظ بأي منافذ يمكن للعالم الخارجي الوصول إليها، لذلك يعمل خلف NAT من دون tunnel. يربط ملف compose لوحة التحكم وgateway وAPI وPostgreSQL بالعنوان 127.0.0.1 افتراضياً. صِل إلى لوحة التحكم عبر SSH tunnel، أو ضع reverse proxy مع TLS أمام المنفذ 10254 إذا احتاج عدة أشخاص إلى الوصول إليها. المنفذ 10255 على gateway مخصص للوكلاء، وعلى خادم واحد يصل هؤلاء الوكلاء إليه عبر شبكة Docker الداخلية.

هل استخدام OneCLI داخل الشركة مجاني؟

الجزء الأساسي مرخّص بموجب Apache-2.0، ويُسمح باستخدامه ذاتياً في بيئة الإنتاج من دون ترخيص تجاري. وتخضع الأدلة التي تحمل أسماء ee/ إلى OneCLI Enterprise License، وهي مجانية للتطوير والاختبار والتقييم، لكنها تتطلب اشتراكاً في بيئة الإنتاج. يتغير هذا الفصل بين الإصدارات، وتشير ملاحظات الإصدار v2.0.1 بتاريخ 18 August 2026 إلى استعادة ملف ترخيص Apache-2.0 يمكن لـGitHub اكتشافه، لذلك تحقّق من LICENSE والأدلة ee/ في الوسم الدقيق الذي ستنشره قبل بناء سير عمل يعتمد على ميزة واحدة بعينها.