最近看到不少朋友在折騰本地部署大模型Docker一拉、Ollama一跑模型是起來了可那個默認(rèn)界面怎么看怎么不順眼。尤其是一堆歷史會話摞在一起想用手機(jī)在外部網(wǎng)絡(luò)翻聊天記錄體驗基本等于零。今天要說的這個Star Office UI解決的就是這個“面子”問題同時也順帶把“里子”——部署和公網(wǎng)訪問——一起收拾了。Star Office UI是一個開源的AI對話前端項目基于Next.js構(gòu)建整體風(fēng)格走的是清爽的辦公套間路線還挺像一間像素風(fēng)格的線上辦公室。裝上之后你可以把本地跑的Ollama、各種OpenAI兼容API、Dify等后端接到這個界面上得到一個多會話、帶代碼高亮、支持Markdown和文檔上下文的聊天工作臺。更重要的兩點是它走Docker容器化部署一條命令就能跑起來配合公網(wǎng)訪問方案人在外面用手機(jī)也能打開你自己的AI辦公室。這篇文章我會從完整部署角度把流程過一遍先講整體思路再講實操接著解決公網(wǎng)訪問最后把踩過的坑和排查思路整理成速查表。適合剛接觸本地部署、已經(jīng)跑通了大模型但想要一個更好用界面的朋友也適合想給團(tuán)隊內(nèi)部搭一個AI對話入口的運維和開發(fā)。1. 先搞清楚Star Office UI到底是個什么東西1.1 它不是模型是替你把桌面收拾整齊的那雙手很多人第一眼看到“Star Office UI”這個名字會誤以為它是一個大模型。其實它只是一個前端一個瀏覽器里運行的對話工作臺。你可以把它理解成一家公司的前臺——大模型是坐在辦公室里干活的人Star Office UI就是那個替你敲門、遞話、整理會議記錄的助理。當(dāng)前本地部署大模型的方案已經(jīng)非常成熟Ollama、vLLM、llama.cpp、Dify這些工具滿天飛但它們的默認(rèn)界面往往側(cè)重于調(diào)試和實驗不是面向日常使用的。跑通一個模型只完成了三成剩下七成是“怎么舒服地用它”。Star Office UI恰恰補(bǔ)上了這塊多會話管理、模型切換、上下文管理、文檔導(dǎo)入把零散的AI能力整合成一個可以日常辦公的入口。1.2 像素辦公室這個說法是怎么來的標(biāo)題里的“像素辦公室”其實是個很形象的描述。Star Office UI的界面風(fēng)格偏簡潔、明快側(cè)邊欄用來管理會話中間是聊天主區(qū)域右下角是模型和參數(shù)設(shè)置整體布局特別像一間方方正正、格子分明的辦公室。把AI當(dāng)成你的員工給它配一間辦公環(huán)境這就是這個項目最直觀的產(chǎn)品隱喻。我實際用下來的感受是它比單純的黑底終端舒服多了尤其是長時間使用的前提下深色模式加代碼高亮視覺負(fù)擔(dān)小很多。更重要的是它把多個后端服務(wù)的對話歷史集中在一處不需要反復(fù)切換標(biāo)簽頁這一點在排查問題、寫代碼、整理文檔的時候尤其省心。1.3 適合誰來用已經(jīng)在用Ollama或各類OpenAI兼容API但不想每次都在終端里敲命令的人。想在公司內(nèi)網(wǎng)或家庭局域網(wǎng)里搭一個AI對話入口讓團(tuán)隊、家人一起用的人。想通過公網(wǎng)訪問自己的AI服務(wù)但又不希望暴露原始API端口的人。折騰過Dify、FastGPT這類可視化平臺但覺得太重、只想用輕量對話界面的朋友。我建議把Star Office UI理解為一個輕量級前門。如果你的訴求是搭復(fù)雜的知識庫、自動化工作流那直接上Dify如果只是想要一個好看的、能多端訪問的聊天界面那Star Office UI比很多方案都輕巧部署成本也更低。2. 部署前的準(zhǔn)備環(huán)境和方案選型2.1 硬件要求其實很低先給個結(jié)論部署Star Office UI本身不吃性能只要是能跑Docker的設(shè)備就行1核CPU、512MB內(nèi)存都能跑起來。真正吃性能的是你后端的模型推理服務(wù)。所以部署之前先想清楚一件事你的模型跑在哪。常見組合有幾種本機(jī)跑Ollama通過宿主機(jī)網(wǎng)絡(luò)暴露的11434端口連接。內(nèi)網(wǎng)另一臺機(jī)器跑vLLM或OpenAI兼容API通過局域網(wǎng)IP加端口暴露。直接用云廠商的API服務(wù)填公網(wǎng)API地址和Key。用Dify平臺Star Office UI可以連接Dify生成的API。部署前先確認(rèn)后端服務(wù)的連通性如果是Ollama方案可以先用curl http://localhost:11434/api/tags確認(rèn)接口有返回如果是OpenAI兼容API確認(rèn)你有base_url和api_key并且這個地址在容器內(nèi)也能訪問。2.2 Docker Compose是最省心的部署方式Star Office UI有源碼部署和容器部署兩條路。源碼部署需要Node.js 18環(huán)境還要裝依賴、編譯升級版本也要手動處理對新手來說沒必要。容器方案里我更推薦docker compose而不是裸docker run因為要看配置、持久化、重啟策略寫進(jìn)一個文件遠(yuǎn)比一長串命令容易維護(hù)。容器部署的本質(zhì)是把整個運行環(huán)境封裝起來宿主機(jī)只需要一個docker和compose插件。數(shù)據(jù)通過卷掛載到宿主機(jī)即使容器刪了重建會話記錄和配置也不會丟。這也是之后升級版本最舒服的做法拉新鏡像、docker compose up -d服務(wù)自動重建數(shù)據(jù)還在。2.3 先想清楚三個角色訪客、前端、模型后端我把整個服務(wù)拆成三個角色訪客瀏覽器、前端容器Star Office UI、模型后端Ollama或兼容API。瀏覽器通過HTTP訪問前端容器的端口前端容器再代理請求到模型后端。理解這一點后面所有配置都不容易亂。比如常見的502錯誤八成是前端容器拿不到后端服務(wù)的IP常見的會話丟失八成是卷沒掛對或者容器重建時把老數(shù)據(jù)覆蓋了。網(wǎng)絡(luò)層面有一個點必須提前注意如果你用Docker運行Ollama負(fù)責(zé)跑模型的容器和Star Office UI容器最好在同一個docker網(wǎng)絡(luò)里互相用容器名訪問不要依賴localhost。如果你是讓Ollama直接跑在宿主機(jī)上沒有容器化那Star Office UI容器里需要用host.docker.internal指向宿主機(jī)而不是localhost。這個區(qū)別是新手最容易踩的坑。3. 從零開始Star Office UI完整部署實操3.1 第一步準(zhǔn)備好目錄結(jié)構(gòu)和基礎(chǔ)配置以Linux服務(wù)器為例先做兩件事新建目錄、準(zhǔn)備compose文件。我習(xí)慣把項目放到/opt/star-office-ui下這樣比較規(guī)整也方便做目錄授權(quán)。實際操作中不需要從源碼構(gòu)建直接拉官方鏡像就行。官方鏡像會帶一套默認(rèn)配置啟動后首次進(jìn)入會引導(dǎo)你配置模型提供商。我建議在啟動之前就把基礎(chǔ)配置寫好少走彎路。3.2 寫一個夠用的docker-compose.yml這里給出一份經(jīng)過驗證的、比較穩(wěn)妥的compose配置你可以直接復(fù)制使用version: 3.8 services: star-office: image: sugarforever/star-office-ui:latest container_name: star-office restart: unless-stopped ports: - 8868:3000 environment: - TZAsia/Shanghai volumes: - ./data:/app/data解釋幾個關(guān)鍵點鏡像名以官方為準(zhǔn)我這里寫的是比較常見的鏡像名實際使用建議去GitHub Release頁面或Docker Hub頁面確認(rèn)當(dāng)前tag。用latest在早期省事但正式使用建議固定到具體版本號避免鏡像更新帶來的不可控變化。端口映射8868:3000的意思是宿主機(jī)8868端口轉(zhuǎn)發(fā)到容器內(nèi)3000端口。對外暴露的是左邊這個8868后面Nginx反代、防火墻規(guī)則都要用這個端口判斷。環(huán)境變量TZ設(shè)置時區(qū)避免日志和時間顯示對不上。volumes把容器內(nèi)的數(shù)據(jù)目錄映射到宿主機(jī)這是持久化的關(guān)鍵。容器重建之后配置和會話還能回來。啟動命令cd /opt/star-office-ui docker compose up -d啟動完成后執(zhí)行docker ps查看容器狀態(tài)確認(rèn)STATUS是Up再看日志有沒有報錯docker logs -f star-office日志里出現(xiàn)類似“Ready”或“started server on 0.0.0.0:3000”的內(nèi)容說明前端已經(jīng)起來了。瀏覽器訪問http://服務(wù)器IP:8868應(yīng)該能看到初始配置頁面。注意如果服務(wù)器有防火墻云服務(wù)器的安全組或本機(jī)的firewalld/ufw記得先放行8868端口。這步不做頁面永遠(yuǎn)打不開排查起來還特別容易忽視。3.3 首次配置把模型接進(jìn)來Star Office UI的首次啟動會有一個配置向?qū)П举|(zhì)是讓它知道“你背后有哪些AI服務(wù)”。這一步比部署本身更重要因為界面再好看接不上模型都是白搭。先看Ollama方案的配置提供商類型選擇Ollama或者選擇OpenAI兼容取決于當(dāng)前版本。API Base URL填寫http://host.docker.internal:11434。這行的意思是讓容器內(nèi)的服務(wù)訪問宿主機(jī)的11434端口。Model Name填寫你已經(jīng)在Ollama里拉取好的模型名稱比如qwen2.5:7b或llama3.1:8b。保存后回到對話頁如果模型列表能出現(xiàn)你配置的模型說明連接成功。再看OpenAI兼容API方案的配置API Base URL填寫例如http://192.168.1.50:8000/v1。API Key填寫對應(yīng)的Key沒有Key的后端可以隨便填一個非空字符串。Model Name填寫后端暴露的模型名。提示很多本地推理服務(wù)雖然不強(qiáng)制鑒權(quán)但對Key字段為空會直接拒絕。這是一個容易踩的坑填一個占位Key能繞過去。3.4 關(guān)于持久化數(shù)據(jù)的一個建議首次啟動配置好之后最好回到宿主機(jī)看一眼data目錄下的內(nèi)容。正常情況下會有配置文件和數(shù)據(jù)文件。把這些文件納入定期備份清單和你的模型權(quán)重一樣重要。界面配置丟了可以重新點一遍但聊天記錄和團(tuán)隊使用的配置丟了想找回只能靠記憶那個成本很高。我還建議在compose配置文件里固定版本號比如把latest改成你確認(rèn)過穩(wěn)定的版本。少數(shù)情況鏡像更新會改數(shù)據(jù)結(jié)構(gòu)把老配置字段替換掉固定版本能顯著降低這種風(fēng)險。4. 公網(wǎng)訪問讓手機(jī)、同事都能連上你的AI辦公室4.1 先想清楚你的服務(wù)器到底有沒有公網(wǎng)IP公網(wǎng)訪問這件事不少人卡在第一步?jīng)]有公網(wǎng)IPv4。要么是家寬大內(nèi)網(wǎng)要么是云服務(wù)器帶寬太小。我的處理原則是有公網(wǎng)IP直接Nginx或Caddy反代加域名干凈利落。沒有公網(wǎng)IP用Cloudflare Tunnel不需要公網(wǎng)IP也能穩(wěn)定訪問。只限內(nèi)部設(shè)備訪問用Tailscale或ZeroTier組網(wǎng)只在成員設(shè)備間互通不對外暴露。下面我把最常用的兩條路分別講透。4.2 方案一有公網(wǎng)IP用Caddy做反向代理Caddy最大的優(yōu)勢是自動申請和續(xù)期HTTPS證書配置也短適合不想折騰Nginx的人。先安裝Caddy然后寫一個Caddyfileai.example.com { reverse_proxy 127.0.0.1:8868 }把域名解析到服務(wù)器IP然后啟動Caddy它會自動申請證書。訪問https://ai.example.com就能進(jìn)入Star Office UI。有幾點實操經(jīng)驗更穩(wěn)妥的做法是先在本機(jī)curl http://127.0.0.1:8868確認(rèn)前端正常再放Caddy上去避免代理層和后端問題混在一起難以排查。域名建議用一個單獨的二級域名不要拿主域名直接跑。以后想換服務(wù)、做遷移DNS記錄動一下就行。Caddy的日志要開起來特別是排查503、404之類的問題日志里能直接看到后端連接失敗的具體原因。如果非要用Nginx無非就是多寫一個server塊server { listen 80; server_name ai.example.com; location / { proxy_pass http://127.0.0.1:8868; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }注意反向代理場景里Host頭、X-Forwarded-For這些頭必須傳對否則頁面會出現(xiàn)資源加載不正常或登錄態(tài)異常的問題。4.3 方案二沒有公網(wǎng)IP用Cloudflare TunnelCloudflare Tunnel的核心思路很簡單你家的服務(wù)器主動向Cloudflare邊緣節(jié)點發(fā)起一條出站連接用戶訪問你的域名時請求經(jīng)Cloudflare邊緣節(jié)點轉(zhuǎn)發(fā)到這條隧道里最終到達(dá)你本地的Star Office UI。全程不需要公網(wǎng)IP也不需要端口映射。操作步驟大概是這樣在服務(wù)器上安裝cloudflared不同系統(tǒng)安裝方式不同Debian系可以直接下載deb包。登錄你的Cloudflare賬號創(chuàng)建一個隧道會生成一個token。用token啟動cloudflared服務(wù)cloudflared service install token在Cloudflare控制臺為隧道綁定一條DNS記錄比如ai.example.com指向本地服務(wù)http://localhost:8868。綁好之后等幾十秒訪問https://ai.example.com就能打開界面。即使你的服務(wù)器在NAT后面這條隧道也完全夠用因為出站方向只用到443端口一般不會觸發(fā)家寬或公司網(wǎng)絡(luò)的出站限制。注意Cloudflare Tunnel只是把你的服務(wù)暴露到公網(wǎng)不等于不用做訪問控制。因為它本質(zhì)上是把本地服務(wù)搬到公網(wǎng)上更要把下面的安全配置做扎實。4.4 公網(wǎng)訪問前的安全加固清單在我看來把AI服務(wù)暴露到公網(wǎng)至少要做三件事第一禁止直接暴露原始API端口。原始API端口比如11434、8000、3000都不要直接映射到公網(wǎng)更不要開成0.0.0.0。中間必須隔一層Star Office UI或者反代復(fù)用這套界面做訪問控制。第二給前端加訪問控制。Star Office UI如果支持分享鏈接或訪客模式務(wù)必確認(rèn)默認(rèn)狀態(tài)是關(guān)閉的同時在反代層加basic auth。Caddy的基本認(rèn)證模塊可以給整個站點套一層密碼幾行配置就能擋住大部分亂訪問的人。第三不要在后端配置文件里硬編碼真實的API Key。把密鑰放到環(huán)境變量或?qū)ｉT的secret文件里即使有人拿到界面配置也看不到明文密鑰。如果團(tuán)隊多人使用還可以用Cloudflare Access這類方案讓每一個訪問者都必須通過郵件或身份認(rèn)證沒有賬號的人連登錄頁都看不到。這套做法的效果比單純依賴前端密碼要好得多。5. 部署和訪問中常見的坑我把自己和身邊朋友實際踩過的問題整理成一個速查表先直接看表再往下看細(xì)節(jié)?，F(xiàn)象可能原因排查方法頁面打不開端口沒放行或防火墻規(guī)則攔截先curl http://127.0.0.1:8868再查安全組和firewalld規(guī)則502 Bad Gateway反代連不上前端端口檢查反代配置里的proxy_pass地址和端口確認(rèn)服務(wù)狀態(tài)前端能打開但模型列表是空的后端API地址或Key配置不對在服務(wù)器上直接curl后端API地址先確認(rèn)后端連通性模型對話一直轉(zhuǎn)圈模型推理時間過長超過代理層超時調(diào)大反代層超時時間或換更小參數(shù)量的模型重啟容器后會話丟失卷沒掛載或掛錯目錄用docker inspect確認(rèn)掛載路徑更新compose配置docker pull拉取超時鏡像源不穩(wěn)定或網(wǎng)絡(luò)波動配置鏡像加速源或換一個時段再試公網(wǎng)訪問速度慢服務(wù)器上行帶寬小或隧道節(jié)點遠(yuǎn)換就近的Cloudflare節(jié)點或改用帶寬更高的服務(wù)器上傳文檔后對話沒反應(yīng)上下文窗口溢出或格式不支持減小文檔體積換成TXT或PDF再試以上這些坑多數(shù)都遵循同一個排查路徑從瀏覽器到反代從反代到前端容器從前端容器到后端模型服務(wù)逐段定位用curl在每一層做驗證。不要一上來就懷疑代碼先把網(wǎng)絡(luò)鏈路走一遍。5.1 一個典型的排查過程舉個實際例子。有朋友反映公網(wǎng)訪問頁面能打開但發(fā)消息一直不回復(fù)。我先讓他在服務(wù)器本機(jī)執(zhí)行curl http://127.0.0.1:8868頁面正常再執(zhí)行curl http://127.0.0.1:11434/api/tagsOllama也正常進(jìn)一步檢查發(fā)現(xiàn)容器內(nèi)訪問host.docker.internal:11434時超時原因是新版本Docker默認(rèn)沒有開啟host-gateway特性需要在compose里加上extra_hosts: - host.docker.internal:host-gateway改完重啟容器問題就沒了。這就是典型的分層定位思路每一層都驗證不靠猜。6. 進(jìn)階玩法讓你的辦公室真正“辦公”起來6.1 把Dify和Star Office UI放在一起如果你已經(jīng)用了Dify來編排復(fù)雜的助手但想讓用戶通過一個更統(tǒng)一的界面來訪問可以把Dify的API地址填進(jìn)Star Office UI的配置里。這樣底層流程仍在Dify里控制外層體驗統(tǒng)一到這個像素辦公室。很多團(tuán)隊就是這么干的Dify負(fù)責(zé)業(yè)務(wù)邏輯Star Office UI負(fù)責(zé)給用戶一個干凈的前門。6.2 多會話、多模型、多用戶的管理建議進(jìn)去之后你會發(fā)現(xiàn)它支持多個會話并行。我建議按項目或按任務(wù)拆分會話而不是在一條線上一直聊。比如“寫作助手”一個會話“代碼排查”一個會話“日常問答”一個會話這樣既方便回溯也不容易混。多模型支持還有一個實用場景把多個后端API地址都配好日常切換模型來對比回答質(zhì)量。比如跑同一批測試問題分別用不同模型回答對比速度、格式、準(zhǔn)確率能明顯幫你選出最合適的那個。6.3 一個小技巧用系統(tǒng)提示詞把AI“固定工位”Star Office UI一般是支持系統(tǒng)提示詞的你可以給每個會話配置不同的角色設(shè)定。我的習(xí)慣是把每個會話預(yù)設(shè)成不同的“工位”文檔分析崗只處理文檔代碼審查崗只回答代碼運營崗只輸出中文文案。為了讓模型不跑偏系統(tǒng)提示詞里要寫清楚職責(zé)邊界和輸出格式要求這樣多個會話互不干擾用起來非常順手。另外如果你打算長期使用建議每天看一眼后端服務(wù)的資源占用。模型推理是CPU和內(nèi)存的大戶前端本身占用很低真正的瓶頸在模型側(cè)。如果發(fā)現(xiàn)響應(yīng)越來越慢優(yōu)先看是不是后端推理隊列堆積了而不是急著給Star Office UI加資源。7. 寫在最后的一點體會部署本身只花半小時真正決定體驗的是你是否有清晰的訪問路徑和取舍。我現(xiàn)在手里的這套組合拳是一臺跑Ollama的小機(jī)器加上一個Star Office UI容器再通過Cloudflare Tunnel把服務(wù)掛在二級域名下。無論在公司、在地鐵、在家打開手機(jī)瀏覽器就能進(jìn)入自己的AI辦公室聊天記錄、多會話、接入的模型都在同一個地方這種確定感比單純看模型參數(shù)更讓人安心。最后再分享一個容易被忽略的細(xì)節(jié)給服務(wù)器配好時間同步很重要NTP沒同步好會導(dǎo)致日志錯位而且用Cloudflare Tunnel時偶爾會觸發(fā)證書校驗失敗看到這類報錯先date看一下時間對不對。別折騰半天最后發(fā)現(xiàn)是服務(wù)器時鐘慢了五分鐘這種事我碰到過兩次。