Multica 自部署时，server 只是协调层，真正写代码的是你本机的 daemon 和本地 AI 编程工具。部署前要想清楚三件事：数据库和 Web 服务放哪里，daemon 跑在哪台机器，各个 AI CLI 的登录和权限怎么处理。只把 server 跑起来，不等于 Multica 已经能替你干活。

Multica 自部署指南：server、daemon 和本地 AI 工具分别负责什么

Multica 的自部署文档里，最容易被忽略的是 daemon 不在服务器上替你写代码。

很多人看到 self-host，脑子里会先想 Docker、数据库、域名、反向代理。Multica 当然也有这些东西。但它和普通 Web 应用不太一样。

server 跑起来，只能说明平台能打开。

要让 AI agent 真正进仓库干活，还得有 daemon。daemon 要跑在能访问代码、能启动 Claude Code 或 Codex 的机器上。

这一步才是 Multica 自部署的重点。

server 负责协调，不负责写代码

Multica server 管的是平台数据。

workspace、agent、issue、task、runtime、用户登录，这些都在 server 这一侧。你打开网页，创建任务，看到某个 agent 正在 running，也是在和 server 交互。

可 server 不应该拿着你的本地代码直接开写。

从架构上看，Multica 更愿意把执行放到用户机器。server 把任务派出去，本地 daemon 接到任务，再调用本机已经安装好的 AI 编程 CLI。

这个设计有一个好处：你的代码、CLI 登录状态、provider 凭证，不必全塞进远端服务器。

也有一个麻烦：你不能只会部署 Web 服务。daemon 的机器、权限、目录、工具版本，全都要管。

daemon 才是干活的人

daemon 启动后，会做几件事。

它会检测本机有哪些 AI 编程工具可用，比如 Claude Code、Codex、OpenCode、Cursor Agent。检测到了，才会把对应 runtime 注册给 Multica server。

它会定时和 server 通信。哪里有任务，哪个 runtime 能接，它会不断轮询。

接到任务后，它会准备一个执行目录。Multica 的代码里有专门的 execenv 逻辑，每个 task 会有独立 workdir。仓库不是预先全拉好，而是让 agent 通过 Multica 提供的 repo checkout 命令按需取。

听着绕，落到使用上就是一句话：server 像派单系统，daemon 像本地工位。

没有 daemon，Multica 只是一个好看的任务面板。

自部署前要准备什么

我会先检查这些东西。

机器上有没有稳定的 AI 编程 CLI。你想用 Claude Code，就要先保证 Claude Code 在那台机器上能正常跑。想用 Codex，也一样。

代码仓库能不能被 daemon 访问。私有仓库的认证、SSH key、Git 凭证，这些别等任务失败了才查。

数据库和 server 是否能长期运行。Multica 不是一次性脚本，task 状态、runtime、workspace 都要落库。

还有网络。daemon 要能连 server，server 也要能被你的浏览器访问。自部署在内网可以，但别忘了你自己的使用路径。

这些准备工作不难，麻烦在它们分散在不同层。Web 服务一层，本地执行一层，AI CLI 账号又是一层。

个人用户要不要自部署

如果只是想试试 Multica，我不建议一开始就自部署。

先用最省事的方式理解它的工作流。知道 workspace、agent、daemon、issue 怎么串起来，再决定要不要把 server 拿回自己手上。

自部署适合几种情况。

你不想把团队任务数据放在别人的服务里。你有自己的机器长期在线。你也愿意处理数据库、daemon、CLI 登录这些细节。

如果只是一个人做小项目，自部署会让试用成本变高。你还没判断 Multica 是否适合自己，就先背了一套基础设施。

我自己看这类工具时，会先问一个很土的问题：我现在遇到的是“任务没人管”的问题，还是“需求没想清楚”的问题。

前者可以试 Multica。

后者自部署也救不了。