NAS 上跑 AI 服务这事我大概折腾了快两年。最早一个 Ollama 单独跑，后来加 Open WebUI 接 UI，再加 SearXNG 拼个 RAG，再堆 ComfyUI 跑图。每个服务一份 docker-compose.yml，每个服务一份 .env，每个服务自己占一个端口。改一个环境变量要在三四个文件里翻。
然后我看到了 Harbor。
这个项目是 av/harbor，Apache-2.0，3.2k stars，v0.5.6 是 8 月 29 号刚发的。它做的事情非常直白：把你想要的那一坨 AI 服务用一条命令拉起来，并且把彼此之间的连接预先接好。比如你启了 SearXNG，它会自动在 Open WebUI 里把 Web RAG 打开；启了 llama.cpp，它会自动接上 Speaches（OpenAI 兼容的 STT/TTS）。这层「预接线」是我觉得最值钱的点。
它不是新冒出来的小玩意。仓库 2024 年 7 月有第一次 commit，到现在 1,776 次提交，22 个贡献者（bus factor 1，这个我后面会提）。Python 占了 51.7%，Shell 22.3%，TypeScript 16.5%，剩下是 Rust、HTML、CSS 等。维护痕迹里有个细节我喜欢——CLAUDE.md 和 AGENTS.md 是专门写给 AI 编码 agent 看的规范，作者自己也在大量用 AI 写代码，而且专门加了 PreToolUse 钩子拦 git reset --hard，怕子 agent 误删工作。
先说它支持的规模。它有个「服务目录」的概念，里头塞了 100 多个服务，分三大类：
- 前端约 19 个，Open WebUI、LibreChat、AnythingLLM、Lobe Chat、SillyTavern、ComfyUI 这些都熟。
- 推理后端20 多个，除了大路货 Ollama / llama.cpp / vLLM，还有 Aphrodite、TabbyAPI、KTransformers、ik_llama.cpp、mistral.rs、AirLLM、Modular MAX 之类的特色货。Mac 用户特别要看的是 DMR / MLX / oMLX 三个，它们是宿主机的 Metal 加速，不进容器——理论上比容器里跑快一截（具体看模型和硬件）。v0.5.0 之后，默认后端从 Ollama 改成了 llama.cpp，作者的理由是 llama.cpp 对各种 quant 格式更宽容，对 GGUF 的支持也更直接。
- 卫星服务才是重头戏——SearXNG、Perplexica、Local Deep Research、LightRAG、Cognee、Qdrant 这些做 RAG 的；n8n、Dify、Flowise、LangFlow 这些做工作流的；Aider、Bolt.new、OpenHands、OpenClaw、OpenCode、Browser Use 这些做 agent 的。v0.5.6 又新加了 Paperless-ngx、Paperless-GPT、Whishper、Linkwarden 一组文档管理工具，开始往「本地 AI 操作系统」的方向走了。
实操部分我挑几个最有感的写。
装。一行命令。它分平台：Linux 和 macOS 直接 harbor up，Windows 走 WSL 2（install.ps1 会帮你开 WSL 并拉个 Ubuntu）。它自己用 bash + Python + Deno + Rust 拼出来的 CLI，背后是一堆写好的 Docker Compose 模板。安装脚本在 install.sh 里，没几行。
起。harbor up llamacpp webui searxng，三个服务一起拉。第一次会有镜像拉取，等几分钟。之后就是 docker compose 的事情了，但是它帮你处理了 .env 同步、端口冲突检测、跨服务网络这些琐事。v0.5.5 之后，20 多个服务的工作区文件所有权都改成宿主机用户了，之前那种「容器一重启模型文件全变 root 权限」的事没了。
接编码 agent。这是我另一个觉得真省事的——harbor launch --backend ollama --model qwen3.5:4b codex。如果你本机装了 Codex CLI，这条命令直接把它指向 Harbor 的本地后端，不用手动改 ~/.codex/config.toml。支持的 CLI 包括 Claude Code、Codex、Copilot、Grok、OpenCode、Pi、Pool 等十来个。这个「桥接器」模式比每个工具都自己配 provider 要舒服很多。我自己写代码时就是这么用的——Harbor 起着本地模型，Codex 自动接到它上面。
退出。harbor eject llamacpp webui searxng > docker-compose.harbor.yml。导出标准 docker-compose 文件，脱离 Harbor 也能跑。这个设计作者解释过——他不想做 lock-in，这套东西本来就是给喜欢折腾的人用的。
还有几个有意思的小功能。harbor qr 生成手机扫码访问的二维码，harbor tunnel <svc> 一键暴露到公网（自带 Traefik），harbor bench run 直接跑内置的 LLM 基准测试，harbor how to ping ollama from webui? 甚至能问它自己。
说了这么多好话，也得说几个坑。
bus factor 1。22 个贡献者，但大部分是早期和文档类的，主线代码基本就作者一个人。这个项目的更新很勤（v0.5.6 距离 v0.5.0 才一个多月，v0.5.5 还专门修了 20 多个服务的首启动失败），但万一作者哪天不想维护了，二次接手会比较痛。如果你打算把 Harbor 跑生产，得做好 fork + 内部维护的准备。
100 多个服务的另一面。你不会全用上，但它很容易一下给你装一堆。第一次 harbor up 不小心就拉 10 几个镜像、占十几个端口。配置前先看下 wiki 的 Services 页和 Harbor Bench 区域，哪些组合在它集成测试里跑过验证过——harbor doctor 命令可以预检你的组合。它自己还有个 gauntlet 流程跑多轮回归，但那是给维护者看的，普通用户用不到。
macOS 上的 BSD grep 坑。这项目跨平台做得很细，仓库里专门有 .gitattributes 强制 LF（修 WSL CRLF 问题），grep 的正则写法也避开了 BSD 不兼容的转义——这是它自己 lint 规则 HARBOR001 干的事。所以一般不会踩这个坑，但是你自己写 Harbor 的扩展脚本的时候要注意。
结果的话，Harbor 适合三类场景。
- 你刚折腾本地 AI，不想挨个手写 docker-compose。先 harbor 跑起来，知道自己想要哪些服务再迁移。
- 你已经在用十几份 compose，想统一管理。它有 profile 机制（
harbor profile save/use），可以一键切换「开发栈」和「跑批栈」。 - 你在 macOS 上想用 Metal 加速。MLX/oMLX 的宿主推理比容器里快一截，Harbor 把这条路封装好了，不用自己写 LaunchAgent。
不适合的也有：只有一两份 compose 的没必要上；生产环境或者 SLA 要求的，bus factor 1 是硬伤；想要超精细控制 docker compose 每行的，自己写更舒服。
我目前用 Harbor 的方式是 Mac 上跑 harbor up llamacpp webui searxng，写代码时 harbor launch --backend llamacpp --model qwen3.5:4b codex 接管。NAS 那台还是用自己原来那堆 compose 跑，因为上面挂了别的不在 Harbor 目录里的服务（Home Assistant、Vaultwarden、Music Assistant 之类），Harbor 的 pre-wiring 对它们没意义，硬迁过去反而要多写一层配置。
Harbor 不是一个「必备工具」，更像是一个「减少重复劳动的捷径」。它的核心价值是把 Open WebUI + Ollama/SearXNG 这种「典型本地 AI 组合」的 docker-compose 写得对、连得通、跨平台不出问题这层事自动化了。这层事手搓一次不难，但是每次新加机器、新加服务都要重做一次。Harbor 把这个事做成了可复用的命令。
如果你想试，harbor up <service> 一行就起，不喜欢 harbor eject 出来自己跑。