كيفية استضافة Octop ذاتياً لعدة مستخدمين

ما هو Octop، ولماذا تستضيفه ذاتياً

Octop هو مساعد ذكاء اصطناعي مستضاف ذاتياً لمنزل أو فريق صغير. والسبب في استضافة Octop ذاتياً بدلاً من استخدام واجهة دردشة بسيطة هو أنّه يفصل المستخدمين عن بعضهم. يوفّر Open WebUI واجهة متصفح أمام نموذج. ويضيف Octop حسابات تتضمن دور admin، ومساحة عمل خاصة ومجموعة بيانات اعتماد لكل مستخدم، ومكتبة من الوكلاء المتخصصين الذين يمكن لكل مستخدم التبديل بينهم حسب المهمة. هذا هو الفرق الذي يتيح لخادم VPS واحد خدمة خمسة أشخاص بدلاً من شخص واحد.

يوجد المشروع في github.com/TencentCloud/Octop. وهو عبارة عن عملية واحدة توفّر لوحة ويب، وواجهة سطر أوامر، وقنوات دردشة (Feishu وDingTalk وQQ وDiscord وWeCom)، ومهام مجدولة، وكل ذلك مدعوم بقاعدة بيانات SQLite واحدة ضمن ~/.octop/. كُتب كل ما يلي استناداً إلى الوسم v0.9.19، الذي صدر في 5 August 2026. إذا كنت لا تزال تقرر بين المنصات، فإن مقارنة بدائل Open WebUI التي يمكنك تشغيلها على VPS تغطي الخيارات الأوسع.

هناك أمر يجب توضيحه قبل أن تقضي مساءً في إعداده. Octop برنامج سابق للإصدار 1.0، منشور من مؤسسة GitHub تابعة لأحد الموردين، وكان لديه نحو 900 نجمة حتى August 2026. يتطور بسرعة، وتؤكد أرقام الإصدارات ذلك، ولا يوجد هنا ما يضمن مسار ترقية مستقراً. ثبّت استخدام وسم محدد، واقرأ سجل التغييرات، واحتفظ بنسخ احتياطية.

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

• VPS يعمل بنظام Ubuntu 24.04، مع Docker Engine وCompose plugin. إذا كنت جديداً على Compose، فابدأ بـ أساسيات Docker Compose على VPS.
• git، لأنك ستسحب release tag بدلاً من سحب image.
• اسم نطاق يشير إلى VPS، لأنك تريد وضع TLS (أمان طبقة النقل) أمام هذه الخدمة.
• Backend لنموذج يتحدث عبر OpenAI API: Ollama محلي، أو gateway مستضاف ذاتياً، أو مفتاح مدفوع.

Octop خفيف بحد ذاته. فهو عبارة عن عملية Python وملف SQLite. يأتي الحجم الفعلي من Backend النموذج. لذلك، إذا كنت تخطط لتشغيل النموذج على الخادم نفسه، فاختر مواصفات الخادم بما يناسب النموذج.

لماذا لا نوصي بمثبّت curl

يبدأ ملف README بأمر تثبيت من سطر واحد:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

لا نوصي باستخدامه على خادم مهم بالنسبة إليك لسبب واضح: هذا البرنامج النصي ليس موجوداً في المستودع. يُقدَّم من حاوية Tencent Cloud Object Storage. ولا يغطيه أي وسم git أو commit، لذلك لا يمكنك مقارنة البرنامج النصي الحالي ببرنامج الأسبوع الماضي، ولا يوجد سجل يوضح سبب أي تغيير. وقد تعرض الحاوية محتوى مختلفاً غداً، من دون أن يسجّل المشروع ذلك. كما أن تمرير الناتج مباشرة إلى bash يعني أن الجهاز ينفّذ البرنامج النصي قبل أن تقرأ منه سطراً واحداً.

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

هناك خياران أفضل. اجلب البرنامج النصي واقرأه ثم شغّله، وهذا يستغرق ثلاثين ثانية: curl -fsSL <url> -o install.sh، ثم less install.sh، ثم bash install.sh. أو استخدم Docker، وهو موضوع بقية هذا الدليل. أما حزمة PyPI (pip install octop) فهي على الأقل artifact مرتبطة بإصدار، ويمكنك تثبيتها على release محدد.

نشر Octop باستخدام Docker Compose مع تثبيته على الإصدار v0.9.19

لا توجد صورة منشورة يمكن سحبها حتى August 2026. يبني ملف Compose المرفق الصورة من المستودع، لذلك يعني تثبيت إصدار التحقق من git tag.

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

هذه هي الخدمة التي يعرّفها الملف، بعد اختصارها إلى الأجزاء المهمة:

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

لاحظ كتلة build:. إنّ image: octop:latest هو اسم البناء الذي تنشئه أنت، وليس مرجعاً إلى registry، لذلك تعني latest هنا أي إصدار قمت بتجميعه مؤخراً. حدّد مسار البيانات صراحةً بدلاً من تركه للقيمة الافتراضية، واضبط كلمة مرور حقيقية لحساب الإدارة قبل الإقلاع الأول. ضع ذلك في docker/.env:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

هناك نقطة مهمة هنا تتفوق في أثرها على بقية الملف. يقرأ Compose ملف docker/.env فقط لاستبدال العناصر النائبة ${...} في YAML. لا تصل أي قيمة تضيفها إلى ذلك الملف إلى الحاوية ما لم تُدرج أيضاً ضمن environment: في ملف Compose. إضافة OCTOP_ACCESS_TOKEN_TTL إلى .env وحده لا تفعل شيئاً إطلاقاً، من دون أي رسالة. البديل هو كتابة المفاتيح نفسها في ~/.octop/env داخل دليل البيانات المركّب، حيث يحمّلها Octop عند الإقلاع. يشرح دليل ملفات البيئة والأسرار في Docker Compose سبب اختلاف هاتين الآليتين.

أنشئ الصورة وشغّلها:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

تستجيب النسخة السليمة لفحص الصحة بالقيمة {"status":"ok","version":"..."}. إذا ظهرت أي قيمة أخرى، اقرأ docker compose -f docker/docker-compose.yml logs -f octop قبل فتح المتصفح.

سمِّ الآن الصورة التي أنشأتها باسم واضح، لأن --build التالي سيستبدل octop:latest، ولن تتمكن من تمييز الصورتين:

docker image tag octop:latest octop:0.9.19

يشغّل الإقلاع الأول octop init ويكتب بيانات الاعتماد الأولية في volume البيانات:

docker exec -it octop cat /data/.octop/credential.txt

القيم الافتراضية هي admin / octop، ولا تُطبَّق إلا عند التهيئة الأولى. وهذا يفسر سؤالاً يتكرر كثيراً: تغيير OCTOP_DEFAULT_PASSWORD بعد تشغيل الحاوية مرة واحدة لا يغيّر شيئاً، لأن الحساب يكون قد أُنشئ بالفعل. غيّر كلمة المرور من لوحة المعلومات بدلاً من ذلك.

لا تنشر المنفذ 8088

يربط السطر ports: أعلاه كل واجهات الشبكة على VPS. وبمجرد بدء الحاوية، تصبح لوحة المعلومات متاحة على الإنترنت العام دون تشفير، مع كلمة مرور افتراضية. القيمة الافتراضية لـOCTOP_BIND_HOST في Octop هي 127.0.0.1؛ ويتجاوزها ملف Compose إلى 0.0.0.0 لأن العملية يجب أن تقبل حركة الشبكة من خارج مساحة أسماء الشبكة الخاصة بها. هذا التجاوز صحيح. أما المنفذ المنشور فهو الجزء الذي يعرّضك للخطر.

عدّل السطر ports: في docker/docker-compose.yml بحيث يستمع الربط على loopback فقط:

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

لا تحاول معالجة ذلك باستخدام ملف override عادي. يضم Compose قوائم ports من عدة ملفات بدلاً من استبدالها، لذلك سينتهي بك الأمر إلى نشر كلا الربطين، وسيفشل الربط الثاني. إذا أردت إبقاء الملف المقدم من upstream دون تعديل، فاستخدم الوسم !override مع التسلسل، فهذه هي الطريقة الموثقة للاستبدال بدلاً من الإلحاق. يشرح شرح كيفية دمج Compose لعدة ملفات بقية قواعد الدمج هذه.

يحل الربط على loopback أيضاً مشكلة ستواجهها بخلاف ذلك مع جدار الحماية. يكتب Docker قواعد المنافذ المنشورة في جدول nat قبل السلاسل التي يديرها ufw، لذلك لا يمنع ufw deny 8088 منفذ حاوية منشوراً. لا يمكن الوصول إلى منفذ مربوط بـ127.0.0.1 من خارج الخادم، بصرف النظر عما يعتقده ufw، ولهذا فهو الحل الصحيح وليس حلاً ثانوياً.

ضع TLS أمام التطبيق باستخدام Reverse Proxy

يُعدّ Caddy أقصر مسار، لأنه يطلب الشهادة تلقائياً عبر ACME (بيئة إدارة الشهادات التلقائية)، ويتعامل مع WebSockets دون إعداد إضافي:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

يتطلب nginx عناية أكبر، لأن Octop يمرر المحادثة عبر WebSocket:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

كل سطر هنا يؤدي وظيفة محددة. تعمل المحادثة عبر WS /agents/{id}/chat/ws، لذلك يرد nginx على محاولة الترقية بالخطأ 400 Bad Request عند غياب proxy_http_version 1.1 ورأسي الترقية. في هذه الحالة، تُحمّل لوحة التحكم بشكل طبيعي، لكن كل رسالة ترسلها تبقى معلّقة إلى الأبد من دون ظهور خطأ في الصفحة. يُعدّ proxy_buffering off مهماً لأن نقطة نهاية الاستئناف human-in-the-loop تُرجع text/event-stream، ولأن أحداث SSE (الأحداث المرسلة من الخادم) المحتجزة في ذاكرة التخزين المؤقت للـproxy تصل دفعة واحدة في النهاية بدلاً من تدفقها تدريجياً. يغطي proxy_read_timeout عمليات تشغيل الأدوات الطويلة، لأن المهلة الافتراضية البالغة 60 ثانية توقف الوكيل في منتصف المهمة وتُسجّل upstream timed out (110: Connection timed out).

سلوك مصادقة JWT خلف الـproxy

يصادق Octop باستخدام bearer token، وليس باستخدام cookie. يعيد POST /api/auth/login القيمة {access_token, role, user, ...}، وتحمل الطلبات اللاحقة Authorization: Bearer <access_token>. هذا خبر جيد بالنسبة إلى reverse proxy: فلا يوجد نطاق cookie، ولا يكون عليك ضبط الراية Secure أو قاعدة SameSite بشكل صحيح. لذلك تتصرف الجلسة التي نجحت على http://127.0.0.1:8088 بالطريقة نفسها على https://octop.example.com.

هناك نتيجتان تجدر معرفتهما قبل إتاحة الخدمة للمستخدمين الفعليين.

يحمل WebSocket الرمز المميز في عنوان URL. نقطة النهاية هي WS /agents/{id}/chat/ws?token=<jwt>، لأن JavaScript في المتصفح لا يستطيع ضبط Authorization header أثناء مصافحة WebSocket. يحمي TLS هذا الرمز أثناء النقل. لكنه لا يحميه من سجلاتك: يكتب nginx سطر الطلب الكامل، بما في ذلك query string، في access_log تلقائياً. لذلك ينتهي token صالح لمستخدم فعلي في ملف نصي عادي على الخادم. سجّل المسار من دون الوسائط. يمثّل $uri المسار المطبّع بعد إزالة query string، لذا ضع ما يلي في كتلة http، ثم أشر إليه من الخادم:

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

لا توجد آلية لتسجيل الخروج من جلسة واحدة. تكون قيمة OCTOP_ACCESS_TOKEN_TTL الافتراضية هي 86400، لذلك يظل token صالحاً لمدة 24 ساعة بعد تسجيل الدخول. والطريقة الوحيدة الموثقة لإبطال token هي octop admin rotate-jwt-secret. فهذا يدوّر مفتاح التوقيع المخزّن في ~/.octop/secrets/jwt_secret، ويبطل فوراً كل token صالح، لجميع المستخدمين. لذلك، عندما يغادر شخص الفريق، يكون الترتيب كما يلي: احذف المستخدم، ثم دوّر السر، ثم اطلب من المستخدمين الباقين تسجيل الدخول مرة أخرى. إذا بدا ذلك مرهقاً، فقصّر مدة الصلاحية، وتذكّر إضافة المتغير إلى قائمة environment: وكذلك إلى .env:

OCTOP_ACCESS_TOKEN_TTL=28800

تتم معالجة هجمات التخمين بالقوة الغاشمة: القيمة الافتراضية لـOCTOP_LOGIN_MAX_ATTEMPTS هي 5 محاولات فاشلة، والقيمة الافتراضية لـOCTOP_LOGIN_LOCKOUT_SECONDS هي 900. لذلك ينتظر المستخدم المقفل 15 دقيقة بدلاً من اعتقاد أن التثبيت معطّل. لدى Octop مخزن مستخدمين خاص به، ولا يوفّر دعماً موثقاً لـOIDC في الإصدار v0.9.19. إذا كنت تحتاج إلى تسجيل دخول موحّد فعلي، فضع proxy للمصادقة أمامه. وهذا هو الغرض من خادم Authentik مستضاف ذاتياً.

وجّه Octop إلى واجهة خلفية للنموذج

تُضبط الموفرات لكل وكيل من لوحة التحكم، ويعرض لك octop provider list الإعدادات الحالية. يتضمن Octop إعدادات مسبقة لواجهات OpenAI المتوافقة، وDashScope (Qwen)، وOllama، وتُخزَّن بيانات الاعتماد في جدول providers ضمن قاعدة بيانات SQLite الخاصة بك. يغيّر هذا الاختيار ما تدفعه وما يغادر الخادم.

نموذج محلي باستخدام Ollama. لا يغادر أي شيء الخادم، وتدفع مقابل استخدام RAM بدلاً من الرموز. توجد نقطة إعداد تسبب الالتباس: لا يستطيع container الوصول إلى Ollama على المضيف عبر 127.0.0.1:11434، لأن هذا العنوان يشير إلى loopback الخاص بالـcontainer نفسه. أضف إدخال بوابة المضيف إلى الخدمة:

    extra_hosts:
      - "host.docker.internal:host-gateway"

بعد ذلك، اضبط عنوان base URL للموفر على http://host.docker.internal:11434/v1، وهو مسار Ollama المتوافق مع OpenAI، وضع أي سلسلة غير فارغة في حقل API key، لأن Ollama يتجاهلها، بينما ترفض عملاء OpenAI إرسال قيمة فارغة. يجب أيضاً أن يستمع Ollama خارج loopback حتى ينجح ذلك، وهذا يعني ضبط OLLAMA_HOST=0.0.0.0:11434 في وحدة systemd الخاصة به. هذا هو الجزء الخطِر: لا يوفّر Ollama مصادقة، ولذلك يصبح المنفذ 11434 المفتوح على عنوان IP عام خادم نماذج مجانياً لأي جهة تفحصه أولاً. اسمح فقط بالنطاق الخاص بـDocker، sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp، وارفض بقية النطاقات. يشرح تشغيل Ollama على VPS تحديد حجم النموذج، بينما تشرح مقارنة Ollama وvLLM متى يتوقف Ollama عن كونه الخادم المناسب.

تحذير إضافي بشأن النموذج المحلي، لأنه يبدو كأنه خطأ في Octop لكنه ليس كذلك. تعمل الوكلاء باستدعاء الأدوات، ويكون system prompt مع تعريفات الأدوات والسجل السابق prompt كبيراً. يقدّم Ollama النماذج باستخدام نافذة سياق افتراضية محدودة، ولذلك يخرج الجزء الأول من prompt، حيث توجد تعريفات الأدوات، من النافذة. يتوقف النموذج عندئذ عن استدعاء الأدوات أو يخترع أدوات غير موجودة. ارفع num_ctx إلى 16k أو 32k، واختر نموذجاً يجيد فعلياً استدعاء الدوال.

بوابة مستضافة ذاتياً. ضع بوابة LiteLLM مستضافة ذاتياً بين Octop وبقية المكونات، لتحصل على base URL واحد، ومفتاح منفصل لكل مستخدم، وحدود للإنفاق، وسجل واحد. يمكنك أيضاً تبديل النموذج خلف البوابة دون تعديل أي شيء في Octop.

واجهة API مدفوعة. تحصل على أفضل جودة، مع مقايضة واضحة: يغادر محتوى المحادثة خادمك ويصل إلى الموفر، وهو جزء كبير مما يهدف إليه الاستضافة الذاتية. يوضع المفتاح في docker/.env على شكل OPENAI_API_KEY، ويمرره ملف Compose من خلاله مسبقاً.

أيّاً كان اختيارك، ينقل ملف Compose أيضاً OCTOP_LANGFUSE_ENABLED وLANGFUSE_PUBLIC_KEY وLANGFUSE_SECRET_KEY وLANGFUSE_BASE_URL، ولذلك يمكنك إرسال التتبعات إلى مثيل Langfuse الخاص بك ومعرفة ما تفعله الوكلاء فعلياً بدلاً من التخمين من نافذة الدردشة.

المستخدمون والأدوار ومكتبة الوكلاء المشتركة

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

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

ترقية مشروع يصدر إصدارات بهذه السرعة

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

هذه تواريخ الوسوم في المستودع، محسوبة حتى 7 August 2026. وصلت 4 إصدارات موسومة خلال تسعة أيام، وكان أقصر فاصل بينها 1 يوماً، بينما وصل v0.9.19 بعد 3 يوماً من الوسم السابق. هذا الإيقاع مؤشر جيد على المشروع، لكنه سبب سيئ لتشغيل latest. اقرأ التغييرات قبل تثبيتها:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

أنشئ نسخة احتياطية أولاً في كل مرة، لأن عمليات ترحيل قاعدة البيانات تُنفَّذ عند بدء التشغيل، وفشل عملية ترحيل في مشروع بإصدار أقل من 1.0 مشكلة سيتعين عليك حلها:

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

بعد ذلك، انتقل إلى الوسم الجديد وأعد البناء باستخدام docker compose -f docker/docker-compose.yml up -d --build. إذا حدث خطأ، فإن الانتقال إلى الوسم القديم وإعادة البناء يعيدان الشيفرة، لكن ملف tarball وحده يعيد قاعدة البيانات.

يحتوي ملف tarball على octop.db وconfig.json وJWT signing secret وcredential.txt، ولذلك يجب التعامل معه باعتباره حساساً بقدر حساسية الخادم نفسه. اضبط صلاحياته على mode 600 واحتفظ بنسخة منه خارج الخادم. وللتثبيتات الأكبر، يوفّر المشروع أيضاً docker/docker-compose.postgres.yml، الذي يشغّل PostgreSQL مع pgvector بدلاً من SQLite.

أنماط الفشل، مع النصوص التي ستظهر لك

لا يستجيب فحص السلامة مطلقاً. يتعطل curl http://127.0.0.1:8088/api/health أو يرفض الاتصال. اقرأ docker compose -f docker/docker-compose.yml logs -f octop. الحاوية التي تخرج أثناء التهيئة الأولى لا تستطيع عادةً الكتابة إلى دليل البيانات، لذلك تحقّق من مالك المسار الذي عيّنته في OCTOP_DATA.

تُحمّل لوحة المعلومات، لكن المحادثة تتعطل. لا يظهر أي خطأ في الصفحة، ولا يصل أي رد. افتح وحدة تحكم المتصفح وابحث عن اتصال فاشل بـ wss://octop.example.com/agents/.../chat/ws. الوكيل العكسي لا يمرّر ترقية الاتصال. أضف رأسي proxy_http_version 1.1 وUpgrade وConnection.

يظهر الرد بأكمله دفعة واحدة بعد تأخير عدة ثوانٍ. يعمل البث، لكن التخزين المؤقت مفعّل. اضبط proxy_buffering off.

bind: address already in use. هناك شيء آخر يستخدم 8088 مسبقاً. يحدّد sudo ss -tlnp | grep 8088 اسمه. ويحدث ذلك أيضاً إذا أضفت إدخال ports ثانياً في ملف override بدلاً من تعديل الإدخال الأصلي.

يُرفضَلكلمة المرور الصحيحة. تؤدي 5 محاولات فاشلة إلى قفل لمدة 900 ثانية. انتظر انتهاء المدة بدلاً من إعادة التثبيت.

لم تُفعّل كلمة المرور الجديدة في .env. تُطبَّق بيانات الاعتماد هذه أثناء التهيئة الأولى فقط. غيّرها من لوحة المعلومات.

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

FAQ

هل يُعد Octop بديلاً عن Open WebUI؟

فقط إذا كنت تحتاج إلى الميزات التي يضيفها. Open WebUI واجهة محادثة أمام نموذج، ويؤدي هذه المهمة جيداً لشخص واحد أو لأسرة موثوقة. يضيف Octop حسابات بدور مسؤول، ومساحات عمل وبيانات اعتماد لكل مستخدم، ومكتبة قابلة للتبديل من الوكلاء المتخصصين، بحيث يمكن لعدة أشخاص مشاركة خادم واحد دون مشاركة سجل محادثة واحد. إذا كان حساب واحد مناسباً لك، فإن Open WebUI هو الخيار الأبسط والأكثر نضجاً بكثير.

لماذا ينبغي ألا أستخدم نص تثبيت Octop عبر curl؟

يُقدَّم النص من حاوية Tencent Cloud Object Storage بدلاً من المستودع، ولذلك لا تغطيه أي وسم أو عملية إيداع في git. لا يمكنك مقارنة ما يفعله اليوم بما كان يفعله الأسبوع الماضي، كما أن تمريره إلى bash يشغّله قبل أن تقرأه. ويثبّت أيضاً بيئته الخاصة من Python 3.12 على المضيف، خارج مدير الحزم لديك. نزّله واقرأه أولاً، أو انشره باستخدام Docker Compose من وسم تم سحبه إلى نسخة محلية.

هل يستطيع Octop استخدام نموذج محلي بدلاً من API مدفوع؟

نعم. يتعامل Octop مع APIs المتوافقة مع OpenAI، ويأتي بإعداد مسبق لـOllama، ولذلك يعمل توجيهه إلى http://host.docker.internal:11434/v1 بعد إضافة extra_hosts: ["host.docker.internal:host-gateway"] إلى الحاوية وضبط OLLAMA_HOST=0.0.0.0:11434 على المضيف. قيّد منفذ الجدار الناري 11434 على نطاق عناوين Docker، لأن Ollama لا يوفّر مصادقة خاصة به. توقّع الحاجة إلى رفع قيمة num_ctx في Ollama إلى 16k أو أكثر، لأن مطالبات الوكيل التي تتضمن تعريفات الأدوات تتجاوز نافذة السياق الافتراضية، وعندها يتوقف النموذج عن استدعاء الأدوات.

هل أحتاج إلى reverse proxy، أم يمكنني فتح المنفذ 8088؟

تحتاج إلى reverse proxy. ينشر ملف Compose المرفق مع Octop المنفذ 8088 على كل الواجهات دون TLS، ولذلك ستعبر كلمات المرور ورموز bearer الإنترنت بنص واضح. غيّر المنفذ المنشور إلى 127.0.0.1:8088:8088، وضع Caddy أو nginx أمامه مع شهادة. عند استخدام nginx، مرّر رؤوس ترقية WebSocket واضبط proxy_buffering off، وإلا فستُحمّل الصفحة بينما لا تستجيب المحادثة مطلقاً دون ظهور خطأ واضح.

هل أصبح Octop جاهزاً للاستخدام في الإنتاج؟

لا يزال قبل الإصدار 1.0، ويُصدر عدة إصدارات موسومة كل أسبوع حتى August 2026، لذلك اعتبره واعداً لا مستقراً بعد. يمكن استخدامه ضمن أسرة أو فريق داخلي صغير إذا ثبّتَّ وسمًا محدداً، وقرأت سجل عمليات الإيداع قبل كل ترقية، وأنشأت نسخة احتياطية من وحدة تخزين البيانات قبل كل إعادة بناء. لا تشغّله على latest، ولا تضع بيانات العملاء فيه بعد.