← 返回

把 Multica 部署到阿里云 VPS,调度公司电脑上的 OpenClaw

把 Multica 部署到阿里云 VPS,调度公司电脑上的 OpenClaw

最近在折腾 Multica,想把它做成一个集中的 AI agent 任务调度中心。目标很明确:Multica server 自己跑在阿里云 VPS 上常驻,真正干活的 OpenClaw 留在公司那台常开的 Windows 电脑上(WSL2 里)。这样我在任何地方打开 Multica 都能派发任务,代码和 API key 不离开本地。

记录一下整个方案,顺便把几个我自己一开始想反了的地方写清楚。

一个常见的认知反转

我最早的想法是"Multica 要去连接我公司电脑上的 OpenClaw"。看完文档发现完全反了。

Multica 的架构是这样的:VPS 上的 server 只是个协调中心,负责存 issue、给 task 排队。真正干活的不是 server,是装在你本地机器上的一个叫 daemon 的小程序。daemon 主动连回 server,每 3 秒轮询一次任务,每 15 秒发一次心跳。所有连接都是 daemon 出站发起,公司内网不需要开任何入站端口。

这个模式有个好处:你的代码、API key、AI 工具链全在本地,Multica server 永远看不到。坏处也很直接——只要本地这台 daemon 机器掉线,所有任务都跑不了。

整体架构

阿里云 VPS 上跑 Multica server(Docker Compose 起 Postgres + Web),通过域名暴露。公司电脑 WSL2 里装 Multica CLI,启动 daemon,daemon 自动扫描 PATH 上能找到的 AI 工具,把每个工具注册成一个 runtime。OpenClaw 就是其中一个 runtime。

链路是这样的:我在浏览器打开 Multica → 创建 issue 并指派给 OpenClaw agent → server 把任务放进队列 → 公司电脑的 daemon 下一次轮询拿到任务 → daemon 在本地 WSL2 里调起 OpenClaw 执行 → 结果回传到 server。

VPS 端的部署

前置就两样东西:Docker + Docker Compose,以及一个公网入口。

公网入口我选了域名 + Caddy 反代,因为 Caddy 自动签 Let's Encrypt 证书,什么都不用配。一个最小的 Caddyfile 长这样:

multica.yourdomain.com {
    reverse_proxy localhost:3000
}

阿里云这边有一个特别容易忘的步骤:安全组要放行端口。控制台 ECS → 安全组 → 入方向规则,加上 443(走 Caddy)或者你直接暴露的应用端口。这一步漏了的话表现是"本地 curl 没问题,外网连不上",我已经被坑过一次。

Multica 自托管走的是官方仓库的 docker-compose,clone 下来填 .env 然后 docker compose up -d。.env 里最关键的是 MULTICA_PUBLIC_URL,要填成你公网能访问的完整地址。这个值会被用在 daemon 注册、邮件链接、OAuth 跳转里,填错了 daemon 能登录但后续交互全乱。

验证 server 起来了:VPS 本地 curl http://localhost:3000 有响应,然后从外部浏览器打开域名能看到登录页。

公司电脑端:daemon 接入 OpenClaw

我的开发环境是 Windows 11 + WSL2,OpenClaw 装在 WSL2 里。

这里有个关键决策:daemon 也必须装在 WSL2 里,不能装在 Windows 宿主机。原因是 daemon 启动时只会扫描自己进程 PATH 上的可执行文件,Windows 宿主机的 daemon 看不见 WSL2 里的 openclaw。

完整流程:

wsl
# 装 Multica CLI(按官方文档)
which openclaw          # 确认能找到
openclaw --version      # 确认能跑

multica login --server https://multica.yourdomain.com
multica daemon start
multica daemon status   # 看到 online 就成
multica daemon logs -f  # 应该能看到 "Detected providers: openclaw"

然后到 Multica Web UI 的 Runtimes 页面,会看到一行 OpenClaw runtime 是 online 状态。链路就通了。

让 daemon 在公司电脑上长期常驻

"电脑常开"和"daemon 一直在跑"是两件事。三个常见的掉线场景:

WSL2 实例被自动停掉。Windows 默认在没人用 WSL2 的时候会把虚拟机停掉释放内存。解法是在 %UserProfile%\.wslconfig 里加:

[wsl2]
vmIdleTimeout=-1

电脑睡眠。控制面板 → 电源选项 → 改成"从不睡眠"。

daemon 进程本身挂了。我用 WSL2 systemd 解决。先在 /etc/wsl.conf 里启用 systemd:

[boot]
systemd=true

然后写一个 unit 文件 /etc/systemd/system/multica-daemon.service:

[Unit]
Description=Multica Daemon
After=network-online.target

[Service]
Type=simple
ExecStart=/home/你的用户名/.local/bin/multica daemon start --foreground
Restart=always
RestartSec=10
User=你的用户名

[Install]
WantedBy=multi-user.target

systemctl enable --now multica-daemon 之后,daemon 挂了会自动拉起。

Multica 也有 desktop app,自带 daemon 开机自启,但 desktop app 是 Windows 原生应用,装它会撞上"看不见 WSL2 里 openclaw"的问题。所以我没走这条路。

我这套环境的几个特殊坑

OpenClaw 的 agent 必须提前注册。OpenClaw 的模型是在 agent 层绑定的,Multica 不能在单个 task 里改模型。所以要先在 WSL2 里跑:

openclaw agents add my-agent --model 模型名 [其它参数]
openclaw agents list

然后在 Multica Web 里建 agent 的时候选 OpenClaw 作为 provider,选你刚注册的这个 my-agent。

MCP 配置在 OpenClaw 下会失效。这是看文档才发现的:Multica 支持 11 个 AI 编码工具,但 mcp_config 字段只有 Claude Code 真的会读,其他 10 个(包括 OpenClaw)接收这个字段但完全忽略。这对我之前那套 OpenClaw + InsForge MCP 的玩法有影响——如果继续走 OpenClaw,InsForge 接入得在 OpenClaw agent 内部自己处理,不能依赖 Multica 的 mcp_config 注入。

skill 注入路径是 fallback 的。Multica 给 OpenClaw 注入 skill 走的是通用 fallback 路径 .agent_context/skills/,不是 OpenClaw 原生路径。我之前做的飞书表单 skill 是按 OpenClaw 原生方式放的,迁过来后大概率不会自动生效,需要单独验证。

数据流向的合规边界。代码和 key 留在本地没错,但 task 的 prompt、issue 描述、agent 回复会回传到 VPS 上的 server 存起来。考虑到我在的环境,issue 文本里不能塞业务敏感内容,这条得自己把握。

最小验证清单

按这个顺序走,卡哪步处理哪步:

  1. VPS 上 docker ps,Multica 容器都健康
  2. 浏览器打开公网域名能看到 UI
  3. WSL2 里 multica login 成功
  4. which openclaw 有输出
  5. multica daemon start 之后 status 显示 online
  6. Multica UI → Runtimes 看到 OpenClaw runtime online
  7. 建一个最简单的 issue(比如"在 README 末尾加一行字"),指派给 OpenClaw agent,看 task 是否被派发执行
  8. task 跑完后看 issue 里的回复和代码变更是否符合预期

第 7 步通了,整条调度链路就算搭起来了。之后接复杂的 vibe coding 流程,就只是 OpenClaw 那边的配置工作了。

一点感受

Multica 这种"server 协调 + 本地 daemon 执行"的模式我挺喜欢的。它把"任务流转的协作面"和"代码执行的安全面"分开了——团队可以共享一个 Multica 实例做任务调度,但每个人的 API key、代码、本地工具链都不出本地。比纯云端的 agent 平台更适合我现在这种"有点合规边界、又想要协作调度"的场景。

编辑