Jinsi ya kujiendeshea Octop kwa Docker Compose

Octop ni nini, na kwa nini ujiendeshee mwenyewe

Octop ni msaidizi wa AI unayejiendeshea mwenyewe kwa matumizi ya kaya au timu ndogo. Sababu ya kujiendeshea Octop badala ya kutumia kiolesura rahisi cha mazungumzo ni kwamba huwatenganisha watumiaji. Open WebUI hukupa kiolesura cha kivinjari mbele ya model. Octop huongeza akaunti zenye jukumu la admin, workspace binafsi na seti ya credentials kwa kila mtumiaji, pamoja na maktaba ya mawakala bingwa ambao kila mtumiaji anaweza kubadilisha kati yao kulingana na kazi. Hiyo ndiyo tofauti inayowezesha VPS moja kuwahudumia watu watano badala ya mtu mmoja.

Mradi uko kwenye github.com/TencentCloud/Octop. Ni mchakato mmoja unaotoa dashboard ya wavuti, command line interface, channels za mazungumzo (Feishu, DingTalk, QQ, Discord, WeCom) na scheduled jobs, vyote vikitumia database moja ya SQLite chini ya ~/.octop/. Kila kitu hapa kimeandikwa kwa kuzingatia tag v0.9.19, iliyotolewa tarehe 5 August 2026. Ikiwa bado unaamua kati ya platforms, ulinganisho wa alternatives za Open WebUI unazoweza kuendesha kwenye VPS unashughulikia chaguo pana zaidi.

Jambo moja linapaswa kuwa wazi kabla hujatumia jioni nzima kwenye mradi huu. Octop ni software ya kabla ya 1.0 iliyochapishwa kutoka GitHub organisation ya vendor, ikiwa na takribani stars 900 kufikia August 2026. Inabadilika haraka, kama inavyoonyeshwa na version numbers, na hakuna ahadi hapa ya upgrade path thabiti. Funga tag maalum, soma changelog, na hifadhi backups.

Unachohitaji kabla ya kuanza

• VPS inayoendesha Ubuntu 24.04 ikiwa na Docker Engine na Compose plugin. Je, hujawahi kutumia Compose? Anza na Misingi ya Docker Compose kwa VPS.
• git, kwa sababu utaangalia release tag badala ya kuvuta image.
• Jina la domain linaloelekeza kwenye VPS, kwa sababu unataka TLS (transport layer security) iwe mbele ya huduma hii.
• Model backend inayotumia OpenAI API: Ollama ya ndani, gateway uliyoji-host, au key ya kulipia.

Octop yenyewe ni nyepesi. Ni process ya Python na file la SQLite. Mzigo unatokana na model backend, hivyo ikiwa unapanga kuendesha model kwenye mashine hiyo hiyo, chagua ukubwa wa mashine unaotosha model.

Kwa nini hatupendekezi installer ya curl

README inaanza na usakinishaji wa mstari mmoja:

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

Hatuipendekezi kwenye seva unayoithamini kwa sababu moja iliyo wazi: script hiyo haipo kwenye repository. Inatolewa kutoka kwenye bucket ya Tencent Cloud Object Storage. Hakuna sehemu yake inayodhibitiwa na git tag au commit, kwa hiyo huwezi kulinganisha script ya leo na ya wiki iliyopita, wala hakuna historia inayoeleza mabadiliko. Bucket inaweza kutoa bytes tofauti kesho, bila mradi kurekodi mabadiliko hayo. Kupeleka matokeo moja kwa moja kwenye bash pia kunamaanisha mashine inaendesha script hiyo kabla hujasoma hata mstari mmoja.

Installer hiyo pia huandika moja kwa moja kwenye host badala ya container. Inatumia uv kupakua Python 3.12 na kujenga environment ambayo package manager wako haijui, kwa hiyo kuiondoa baadaye ni kazi ya mikono.

Kuna chaguo mbili bora. Pakua script, isome, kisha uiendeshe. Hilo linachukua sekunde thelathini tu: curl -fsSL <url> -o install.sh, kisha less install.sh, halafu bash install.sh. Au tumia Docker, ambalo ndilo linaloelezwa katika mwongozo huu uliobaki. Package ya PyPI (pip install octop) ni artifact yenye version angalau, na unaweza kuifunga kwenye release.

Weka Octop kwa Docker Compose, ukiweka v0.9.19

Hakuna image iliyochapishwa ya kupakua kufikia August 2026. Faili ya Compose iliyotolewa hujenga image kutoka kwenye repository, kwa hiyo kuweka toleo kunamaanisha ku-checkout git tag. Hii ni hatua moja zaidi kuliko inavyohitajika na miradi mingi ya self-hosting, kwa sababu kitu kama workspace ya AFFiNE ya self-hosting huweka published image tag na hakijengi chochote kwenye VPS yako. Utaratibu wa ku-clone, ku-checkout na kujenga hapa chini ni uleule unaoelezwa katika mwongozo wa deployment wa openGym, kwa hiyo ukiwahi kuusanidi mara moja tayari unaelewa muundo wake.

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

Hii ndiyo service inayofafanuliwa na faili hiyo, ikiwa imepunguzwa hadi sehemu muhimu:

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:-}

Zingatia block ya build:. image: octop:latest ni jina la build yako yenyewe, si reference ya registry, kwa hiyo latest hapa inamaanisha chochote ulichocompile hivi karibuni. Weka data path mahali palipo wazi badala ya kuiacha itumie default, na weka password halisi ya akaunti ya admin kabla ya boot ya kwanza. Weka haya kwenye docker/.env:

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

Kuna mtego mmoja hapa ambao ni muhimu kuliko sehemu nyingine za faili. Compose husoma docker/.env kwa ajili ya ku-interpolate placeholders za ${...} katika YAML pekee. Key unayoongeza kwenye faili hiyo haifiki kwenye container isipokuwa pia iwe imeorodheshwa chini ya environment: katika faili ya Compose. Kuongeza OCTOP_ACCESS_TOKEN_TTL kwenye .env pekee hakufanyi chochote kabisa, bila kutoa error. Njia mbadala ni kuandika keys hizo hizo kwenye ~/.octop/env ndani ya data directory iliyomountiwa, ambayo Octop huipakia wakati wa startup. Mwongozo wa env files na secrets katika Docker Compose unaeleza kwa nini mifumo hii miwili si kitu kimoja.

Ijenge na uiwashe:

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

Instance iliyo katika hali nzuri hujibu health check kwa {"status":"ok","version":"..."}. Jibu lingine lolote, soma docker compose -f docker/docker-compose.yml logs -f octop kabla ya kufungua browser.

Sasa ipe image uliyotengeneza jina lenye maana, kwa sababu --build inayofuata ita-overwrite octop:latest na hutakuwa na njia ya kutofautisha hizo mbili:

docker image tag octop:latest octop:0.9.19

Boot ya kwanza huendesha octop init na kuandika credentials za mwanzo kwenye data volume:

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

Defaults ni admin / octop, na hutumika wakati wa init ya kwanza pekee. Hiyo ndiyo sababu ya swali linaloulizwa mara kwa mara: kubadilisha OCTOP_DEFAULT_PASSWORD baada ya container kuwahi kuanza hakubadilishi chochote, kwa sababu akaunti tayari ipo. Badilisha password kwenye dashboard badala yake.

Usichapishe port 8088

Mstari wa ports: hapo juu hufunga kila interface kwenye VPS. Mara tu container inapoanza, dashboard inapatikana kwenye Internet ya umma bila usimbaji, ikiwa na password ya msingi. Chaguo-msingi la OCTOP_BIND_HOST la Octop ni 127.0.0.1; faili la Compose linabadilisha hilo kuwa 0.0.0.0 kwa sababu process lazima ikubali traffic kutoka nje ya network namespace yake. Mabadiliko hayo ni sahihi. Port iliyochapishwa ndiyo inayokuweka wazi.

Hariri mstari wa ports: katika docker/docker-compose.yml ili mapping isikilize loopback pekee:

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

Usijaribu kurekebisha hili kwa faili la kawaida la override. Compose huunganisha orodha za ports kutoka kwenye faili nyingi badala ya kuzibadilisha, hivyo unaishia kuchapisha mappings zote mbili na ya pili hushindwa kufunga. Ikiwa unataka kuacha faili la upstream bila kulibadilisha, tumia tag ya !override kwenye sequence. Hii ndiyo njia iliyoandikwa kwenye nyaraka ya kubadilisha badala ya kuongeza. Maelezo ya jinsi Compose huunganisha faili nyingi yanaeleza sheria nyingine za merge.

Kufunga kwenye loopback pia hutatua tatizo ambalo ungekutana nalo kwenye firewall. Docker huandika rules zake za published-port kwenye nat table kabla ya chains zinazosimamiwa na ufw, kwa hiyo ufw deny 8088 haizuii port ya container iliyochapishwa. Port iliyofungwa kwenye 127.0.0.1 haiwezi kufikiwa kutoka nje bila kujali ufw inavyofanya kazi, ndiyo maana hii ndiyo suluhisho sahihi, si chaguo la pili.

Weka TLS mbele kwa kutumia reverse proxy

Caddy ndiyo njia fupi zaidi, kwa sababu huomba certificate kupitia ACME (automatic certificate management environment) yenyewe na hupitisha WebSockets bila kuhitaji kusanidiwa:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx inahitaji uangalifu zaidi, kwa sababu Octop hutuma chat kupitia 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;
    }
}

Kila mstari hapo una kazi yake. Chat hutumia WS /agents/{id}/chat/ws, kwa hiyo bila proxy_http_version 1.1 na headers mbili za upgrade, nginx hujibu jaribio la upgrade kwa 400 Bad Request: dashboard hupakia kawaida, lakini kila ujumbe unaotuma hubaki ukisubiri milele bila error kuonekana kwenye ukurasa. proxy_buffering off ni muhimu kwa sababu endpoint ya human-in-the-loop resume hurejesha text/event-stream, na SSE (server-sent events) inayoshikiliwa kwenye proxy buffer hufika kwa mkupuo mmoja mwishoni badala ya kutumwa kwa mtiririko. proxy_read_timeout hushughulikia tool runs ndefu, kwa sababu default ya sekunde 60 humkatiza agent katikati ya task na huandika upstream timed out (110: Connection timed out) kwenye logs.

Jinsi uthibitishaji wa JWT unavyofanya kazi nyuma ya proxy

Octop huthibitisha kwa tokeni ya bearer, si cookie. POST /api/auth/login hurejesha {access_token, role, user, ...}, na maombi yanayofuata hubeba Authorization: Bearer <access_token>. Kwa reverse proxy, hii ni rahisi: hakuna cookie domain, hakuna flag ya Secure, wala kanuni ya SameSite inayoweza kusanidiwa vibaya. Kwa hiyo, session iliyofanya kazi kwenye http://127.0.0.1:8088 itafanya kazi vivyo hivyo kwenye https://octop.example.com.

Kuna matokeo mawili muhimu ya kujua kabla ya kuwaruhusu watumiaji halisi kuitumia.

WebSocket hubeba tokeni kwenye URL. Endpoint ni WS /agents/{id}/chat/ws?token=<jwt>, kwa sababu JavaScript ya browser haiwezi kuweka header ya Authorization wakati wa WebSocket handshake. TLS hulinda tokeni hiyo wakati wa usafirishaji. Haiilindi dhidi ya logs zako mwenyewe: nginx huandika request line kamili, ikiwemo query string, kwenye access_log kwa chaguo-msingi. Hivyo tokeni halali ya mtumiaji halisi huishia kwenye faili la plaintext kwenye seva. Andika path bila arguments. $uri ni path iliyosawazishwa ambayo query string tayari imeondolewa. Weka usanidi huu kwenye block ya http, kisha uirejeze kutoka kwenye server:

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;

Hakuna logout ya kila session. OCTOP_ACCESS_TOKEN_TTL huwa na thamani ya 86400 kwa chaguo-msingi, kwa hiyo tokeni hubaki halali kwa saa 24 baada ya kuingia. Njia pekee iliyoandikwa ya kubatilisha tokeni ni octop admin rotate-jwt-secret. Amri hii huzungusha signing key iliyohifadhiwa kwenye ~/.octop/secrets/jwt_secret na hubatilisha mara moja tokeni zote ambazo bado ni halali, kwa watumiaji wote. Kwa hiyo mtu anapoondoka kwenye timu, fuata mpangilio huu: mfute mtumiaji, zungusha secret, kisha waambie watumiaji waliosalia waingie tena. Ikiwa hilo linaonekana kuwa zito, fupisha muda wa uhalali. Kumbuka kuongeza variable kwenye orodha ya environment: na pia kwenye .env:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute force hushughulikiwa: OCTOP_LOGIN_MAX_ATTEMPTS huwa na thamani ya kushindwa mara 5 kwa chaguo-msingi, na OCTOP_LOGIN_LOCKOUT_SECONDS huwa na thamani ya 900. Kwa hiyo, mtumiaji aliyefungiwa anasubiri dakika 15 badala ya kudhani kuwa usakinishaji umeharibika. Octop ina user store yake na haina support ya OIDC iliyoandikwa katika v0.9.19. Ikiwa unahitaji single sign-on halisi, weka authenticating proxy mbele yake. Hilo ndilo linalofanywa na server ya Authentik ya self-hosted.

Elekeza Octop kwenye backend ya modeli

Providers husanidiwa kwa kila agent kwenye dashboard, na octop provider list hukuonyesha mipangilio iliyowekwa. Octop husafirisha presets za API zinazooana na OpenAI, DashScope (Qwen) na Ollama, na credentials huhifadhiwa kwenye jedwali la providers la database yako ya SQLite. Chaguo hili huamua gharama utakazolipa na data itakayotoka kwenye seva.

Modeli ya ndani yenye Ollama. Hakuna data inayotoka kwenye seva, na unatumia RAM badala ya kulipia tokens. Jambo la usanidi linalowachanganya watu ni hili: container haiwezi kufikia Ollama ya host kupitia 127.0.0.1:11434, kwa sababu anwani hiyo ni loopback ya container yenyewe. Ongeza ingizo la host gateway kwenye service:

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

Kisha weka base URL ya provider kuwa http://host.docker.internal:11434/v1, ambayo ni njia ya Ollama inayooana na OpenAI, na weka string yoyote isiyo tupu kwenye sehemu ya API key, kwa sababu Ollama huipuuza lakini clients za OpenAI hukataa kutuma key tupu. Ollama lazima pia isikilize nje ya loopback ili hii ifanye kazi, jambo linalomaanisha OLLAMA_HOST=0.0.0.0:11434 katika systemd unit yake. Hii ndiyo sehemu hatari: Ollama haina authentication, kwa hiyo 11434 ikiwa wazi kwenye public IP huwa model server ya bure kwa yeyote anayeichanganua kwanza. Ruhusu tu private range ya Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, na ukatae nyingine zote. Kuendesha Ollama kwenye VPS kunaeleza ukubwa wa modeli, na ulinganisho wa Ollama na vLLM unaeleza wakati Ollama inapokoma kuwa server inayofaa.

Kuna tahadhari nyingine kuhusu modeli ya ndani, kwa sababu hali hii huonekana kama bug kwenye Octop lakini si bug. Agents hufanya kazi kwa kuita tools, na system prompt pamoja na tool definitions na history huunda prompt kubwa. Ollama huhudumia modeli zenye context window ya kawaida iliyo ndogo, kwa hiyo mwanzo wa prompt, ambako tool definitions zipo, hutoka nje ya window. Kisha modeli huacha kuita tools au hutunga tools ambazo hazipo. Pandisha num_ctx hadi 16k au 32k na uchague modeli ambayo ni nzuri kwa function calling. Jibu linalokatika katikati ya sentensi ni tatizo tofauti lenye setting nyingine, num_predict, kwa hiyo majibu yakirudi yakiwa yamekatwa, inafaa kuangalia num_predict imewekwa wapi na done_reason inasema nini kabla ya kumlaumu agent. Ukipendelea kuanza na candidate maalum badala ya shortlist, Nemotron 3.5 Lightning inafaa kujaribiwa, na maelezo hayo yana tag sahihi ya kuvuta, RAM inayohitajika na kama CPU-only inaendana kwa kasi.

Gateway ya kujihudumia mwenyewe. Weka gateway ya LiteLLM inayojihudumia mwenyewe kati ya Octop na kila kitu kingine, nawe utapata base URL moja, key tofauti kwa kila mtumiaji, mipaka ya matumizi na logi moja. Unaweza pia kubadilisha modeli iliyo nyuma yake bila kuhariri chochote kwenye Octop.

API ya kulipia. Hii hutoa ubora bora, lakini ina tradeoff ya wazi: maudhui ya mazungumzo hutoka kwenye seva yako na kufika kwa provider, jambo linalopingana na sehemu kubwa ya sababu ya self-hosting. Key huwekwa kwenye docker/.env kama OPENAI_API_KEY, na Compose file tayari huipeleka huko.

Chaguo lolote utakalochagua, Compose file pia hubeba OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY na LANGFUSE_BASE_URL, kwa hiyo unaweza kutuma traces kwenye instance yako ya Langfuse na kuona agents wanafanya nini hasa badala ya kukisia kutokana na chat window.

Watumiaji, majukumu na maktaba ya pamoja ya mawakala

Akaunti ya msimamizi kutoka kwenye boot ya kwanza huunda na kudhibiti akaunti nyingine. Kila mtumiaji hupata mawakala, workspace na credentials zake. Utengaji huo unatekelezwa na tokeni inayohifadhiwa na browser. Pamoja na hayo kuna pool ya pamoja ya skills na sub-agents ambayo mtu yeyote anaweza kutumia. Hiki ndicho kinachofanya huduma hii iwe na maana kwa familia: mtu mmoja huunda agent mzuri wa utafiti mara moja, na hakuna mwingine anayehitaji kuujenga upya.

Kuwa mwangalifu unapotumia tooling. Octop inatangaza tool approval na shell command guardrails, na zote mbili ni za kweli. Hata hivyo, agent anayeendesha shell commands huzitekeleza ndani ya Octop container yenye data volume yako ikiwa mounted. Guardrails hupunguza kile ambacho prompt isiyokuwa makini inaweza kufanya. Si mpaka wa sandbox. Kwa hiyo, acha tool approval ikiwa imewashwa kwa mtu yeyote ambaye usingempa shell moja kwa moja. Ikiwa unalinganisha huduma hii na chaguo nyingine, mapitio ya mawakala wa AI wanaojihudumia yanaeleza jinsi kila mmoja anavyoshughulikia hilo.

Kuboresha mradi unaotoa matoleo kwa kasi hii

[
  {
    "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
  }
]

Hizo ni tarehe za tag kutoka kwenye repository, zilizohesabiwa hadi 7 Agosti 2026. 4 za matoleo yaliyo na tag zilitolewa ndani ya siku tisa, huku pengo likiwa fupi kama siku 1, na v0.9.19 likitolewa siku 3 baada ya tag iliyotangulia. Mzunguko huo ni ishara nzuri kuhusu mradi, lakini ni sababu mbaya ya kuendesha latest. Soma mabadiliko kabla hujayatumia:

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"

Fanya backup kwanza kila mara, kwa sababu database migrations huendeshwa wakati wa startup, na migration ikishindwa kwenye mradi wa kabla ya toleo 1.0, ni jukumu lako kutatua tatizo hilo:

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

Kisha checkout tag mpya na ufanye rebuild kwa docker compose -f docker/docker-compose.yml up -d --build. Ikishindikana, checkout tag ya zamani na kufanya rebuild kutarejesha code, lakini tarball pekee ndiyo itakayorejesha database.

Tarball hiyo ina octop.db, config.json, JWT signing secret na credential.txt, kwa hiyo ni nyeti kama server yenyewe. Iweke kwenye mode 600 na uhifadhi nakala moja nje ya server. Kwa installation kubwa zaidi, mradi pia hutoa docker/docker-compose.postgres.yml, ambayo huendesha PostgreSQL yenye pgvector badala ya SQLite.

Aina za hitilafu, pamoja na maandishi utakayoona

Ukaguzi wa afya haujibu kamwe. curl http://127.0.0.1:8088/api/health inakwama au inakataa. Soma docker compose -f docker/docker-compose.yml logs -f octop. Container inayotoka wakati wa uanzishaji wa kwanza kwa kawaida haiwezi kuandika kwenye data directory, kwa hiyo angalia umiliki wa kile ulichoweka kwenye OCTOP_DATA.

Dashibodi inapakia lakini chat inakwama. Hakuna error kwenye ukurasa, na hakuna jibu linalokuja. Fungua browser console na utafute connection iliyoshindikana kwenda wss://octop.example.com/agents/.../chat/ws. Proxy haisambazi upgrade. Ongeza headers za proxy_http_version 1.1 na Upgrade pamoja na Connection.

Jibu lote linaonekana mara moja baada ya kuchelewa kwa sekunde kadhaa. Streaming inafanya kazi, lakini buffering imewashwa. Weka proxy_buffering off.

bind: address already in use. Kitu kingine tayari kinatumia 8088. sudo ss -tlnp | grep 8088 inakitambua. Hili pia hutokea ikiwa umeongeza entry ya pili ya ports kwenye override file badala ya kuhariri ya awali.

Password sahihi inakataliwa. Majaribio matano yasiyo sahihi husababisha lockout ya sekunde 900. Subiri lockout iishe badala ya kusakinisha upya.

Password mpya kwenye .env haikufanya kazi. Credentials hizo hutumika wakati wa uanzishaji wa kwanza pekee. Ibadilishe kwenye dashibodi.

Agent inajibu lakini haiendeshi tool kamwe. Karibu kila mara hili ni tatizo la local model: context window ni ndogo sana kwa tool definitions, au model ni dhaifu katika function calling. Ongeza num_ctx na ujaribu model iliyoundwa kwa matumizi ya tool.

FAQ

Je, Octop ni mbadala wa Open WebUI?

Ni mbadala ikiwa tu unahitaji vipengele inavyoongeza. Open WebUI ni kiolesura cha mazungumzo mbele ya model, na hufanya kazi hiyo vizuri kwa mtu mmoja au kaya inayoaminiana. Octop huongeza akaunti zenye role ya admin, workspaces na credentials za kila mtumiaji, pamoja na library inayoweza kubadilishwa ya agents waliobobea. Hivyo, watu kadhaa wanaweza kushiriki seva moja bila kushiriki history moja. Ikiwa akaunti moja inakutosha, Open WebUI ni chaguo rahisi na lililokomaa zaidi.

Kwa nini nisitumie script ya kusakinisha Octop kupitia curl?

Script hiyo inatolewa kutoka kwenye bucket ya Tencent Cloud Object Storage badala ya repository. Kwa hiyo, haifunikwi na git tag au commit yoyote. Huwezi kulinganisha inachofanya leo na ilichofanya wiki iliyopita. Pia, kuipeleka kwenye bash huifanya ianze kutekelezwa kabla hujaisoma. Aidha, inasakinisha kwenye host ikiwa na mazingira yake ya Python 3.12, nje ya package manager yako. Ipakue na uisome kwanza, au i-deploy kwa Docker Compose kutoka kwenye tag iliyotolewa kwenye checkout.

Je, Octop inaweza kutumia model ya ndani badala ya API ya kulipia?

Ndiyo. Octop hutumia API zinazooana na OpenAI na inasafirishwa ikiwa na preset ya Ollama. Kwa hiyo, kuielekeza kwenye http://host.docker.internal:11434/v1 hufanya kazi baada ya kuongeza extra_hosts: ["host.docker.internal:host-gateway"] kwenye container na kuweka OLLAMA_HOST=0.0.0.0:11434 kwenye host. Zuia port 11434 kwa firewall ili isipatikane nje ya address range ya Docker, kwa sababu Ollama haina authentication yake. Tarajia kuongeza num_ctx ya Ollama hadi 16k au zaidi, kwa sababu prompts za agent zenye tool definitions huzidi context window ya msingi, na model huacha kuita tools.

Je, ninahitaji reverse proxy, au ninaweza kufungua port 8088?

Unahitaji reverse proxy. Compose file inayosafirishwa na Octop huchapisha 8088 kwenye kila interface bila TLS. Kwa hiyo, passwords na bearer tokens zingepita kwenye Internet zikiwa cleartext. Badilisha port iliyochapishwa iwe 127.0.0.1:8088:8088, kisha weka Caddy au nginx mbele yake pamoja na certificate. Ukiwa unatumia nginx, peleka WebSocket upgrade headers na uweke proxy_buffering off. Vinginevyo, ukurasa utapakia lakini chat haitatoa jibu bila kuonyesha kosa.

Je, Octop iko tayari kwa production?

Bado iko kabla ya toleo 1.0 na, kufikia August 2026, inatoa releases kadhaa zenye tag kila wiki. Kwa hiyo, ichukulie kuwa ina matumaini lakini bado haijatulia. Hili linaweza kufaa kwa familia au timu ndogo ya ndani ikiwa utaweka exact tag, kusoma commit log kabla ya kila upgrade, na kuchukua backup ya data volume kabla ya kila rebuild. Usiendeshe kwenye latest, na usiweke data ya wateja humo bado.