Multica 多机运行避坑指南

ps: 在家1年多深受AI毒害的，信息安全人。
如果有在招人的老板可以联系我~
root@secbig.com

什么是 Multica？

Multica 是一个面向开发者的多智能体协作平台，可以把 Claude Code、Codex、Hermes 等 AI Coding 工具接入到统一的工作流中，通过 Workspace、Project、Issue、Agent、Squad 等概念来组织自动化开发任务。

简单理解：

Workspace = 协作空间
Project   = 项目容器
Issue     = 具体任务
Agent     = 执行任务的智能体
Squad     = 多个 Agent 组成的协作小队
Daemon    = 本机运行时进程
Runtime   = daemon × 某个 AI Coding Tool

Multica 的任务不是直接在云端执行，而是由你本机或服务器上的 multica daemon 接收任务，再调用本机安装的 Claude Code、Codex、Hermes 等工具完成开发、测试或分析任务。

所以在使用 Multica 时，真正执行任务的关键不是 Workspace 本身，而是：

本机 daemon 是否在线
Agent 是否绑定到可用 runtime
当前 profile 是否正确
workspace / project / issue 是否指向正确上下文

这也是本文要讨论的问题：当我在两台 WSL 上分别管理两个项目时，如果没有正确隔离 profile，两个 daemon 会互相影响，导致“后启动的在线，先启动的离线”。

一、问题背景

最近在使用 Multica 管理两个项目时，遇到了一个非常典型的问题：

我有两个项目：项目A 和项目B。

它们分别在两台 WSL 里。

我希望两个项目都能使用 Multica Agent 跑任务。

但实际操作时发现：一个 WSL 启动 daemon 后，另一个 WSL 就离线；后启动的正常，先启动的掉线。

一开始我以为是 workspace 配置问题，后来排查后发现，真正的问题不是 workspace，而是 Multica daemon 的 profile 没有隔离。

二、问题现象

我的环境大概是这样：

WSL 1：
  hostname: 项目A-WSL
  project: 项目A

WSL 2：
  hostname: 项目B-WSL
  project: 项目B

我希望：

项目A workspace → 项目A-WSL runtime
项目B workspace → 项目B-WSL runtime

但是实际情况是：

先启动 项目A-WSL：
  项目A-WSL 在线

再启动 项目B-WSL：
  项目B-WSL 在线
  项目A-WSL 离线

反过来也一样：

先启动 项目B-WSL：
  项目B-WSL 在线

再启动 项目A-WSL：
  项目A-WSL 在线
  项目B-WSL 离线

看起来像是两台机器不能同时在线。

三、第一轮误判：以为是 workspace 问题

一开始我尝试了几种组合。

方案 1：两个项目，两个 workspace

Workspace 1: 项目A
Workspace 2: 项目B

结果不稳定。切换或重启 daemon 后，另一个 workspace 的 runtime 仍然可能离线。

方案 2：两个项目，一个 workspace

Workspace: security-workspace
Project 1: 项目A
Project 2: 项目B

这样虽然能把 issue 放在同一个 workspace 下，但仍然不能解决 runtime 互相顶掉的问题。

方案 3：两个 WSL 各自启动 daemon

仍然不行。后启动的 daemon 会把先启动的 runtime 顶掉。

当时的判断是：

Multica 是不是不支持多台机器？

后来发现这个判断是错的。Multica 是支持多台机器和多 runtime 的，真正的问题在于 两个 WSL 使用了同一个默认 profile。

四、关键日志：daemon 被关闭时会注销 runtime

某次任务被取消时，daemon 日志里出现了这些关键信息：

agent_error="task cancelled by upstream context (server cancel or daemon shutdown)"

deregistering runtimes on shutdown
deregistered runtimes

这说明：

daemon shutdown
  ↓
注销 runtime
  ↓
正在运行的 task 被 cancelled

也就是说，如果有任务正在运行，执行：

multica daemon restart

或者：

multica daemon stop

会直接影响当前 daemon 管理的任务。

所以第一条经验是：

只要 active_task_count > 0，就不要 restart / stop daemon。

可以先看：

multica daemon status --output json

如果看到：

{
  "active_task_count": 1
}

那就不要重启。

五、真正的根因：两个 WSL 使用了同一个默认 profile

排查时，我在两个 WSL 分别执行：

multica daemon status --output json

结果发现两个终端显示的是同一个 daemon：

{
  "daemon_id": "019e4b**-****-****-****-********e9a8",
  "device_name": "项目A-WSL",
  "pid": 33671
}

但在项目B的 WSL 里查看这个 pid：

cat /proc/33671/cmdline

却提示：

No such file or directory

这说明：

项目B-WSL 本机并没有真正运行这个 daemon；
它只是通过 Multica 服务端看到了 项目A-WSL 的 daemon 状态。

进一步看 multica -h，发现了关键参数：

--profile string
Configuration profile name — isolates config, daemon state, and workspaces

这句话非常关键：

--profile 可以隔离 config、daemon state 和 workspaces。

也就是说，如果两个 WSL 都直接使用：

multica daemon start

它们都在使用默认 profile，自然会互相影响。

六、正确方案：为两个项目使用不同 profile

最终方案是：

项目A：
  profile = project-a
  workspace = 项目A
  device = 项目A-WSL

项目B：
  profile = project-b
  workspace = 项目B
  device = 项目B-WSL

七、项目A WSL 初始化

multica --profile project-a setup

检查登录状态：

multica --profile project-a auth status

切换到项目A workspace：

multica --profile project-a workspace switch project-a

检查：

multica --profile project-a workspace list

应看到类似：

* 项目A
  项目B

启动 daemon：

multica --profile project-a daemon start

检查状态：

multica --profile project-a daemon status --output json

期望看到：

{
  "device_name": "项目A-WSL",
  "status": "running"
}

八、项目B WSL 初始化

multica --profile project-b setup

切换到项目B workspace：

multica --profile project-b workspace switch project-b

检查：

multica --profile project-b workspace list

应看到类似：

  项目A
* 项目B

启动 daemon：

multica --profile project-b daemon start

检查状态：

multica --profile project-b daemon status --output json

期望看到：

{
  "device_name": "项目B-WSL",
  "status": "running"
}

九、最终验证结果

修复后，两个 WSL 的状态分别是：

项目A

{
  "daemon_id": "019e4b**-****-****-****-********e9a8",
  "device_name": "项目A-WSL",
  "status": "running",
  "active_task_count": 1
}

项目B

{
  "daemon_id": "019e4b**-****-****-****-********f905",
  "device_name": "项目B-WSL",
  "status": "running",
  "active_task_count": 3
}

关键点是：

daemon_id 不同
device_name 不同
profile 不同
workspace 默认值不同

这就说明两个 WSL 已经真正分离。

十、为什么 status 里仍然显示两个 workspace？

即使使用了不同 profile，daemon status 里仍然可能显示多个 workspace：

"workspaces": [
  {
    "id": "33a4****ba99"
  },
  {
    "id": "e044****dc66"
  }
]

这不一定是问题。

重点不是 workspaces 里有几个 workspace，而是：

当前 profile 的默认 workspace 是否正确；
device_name 是否正确；
daemon_id 是否不同。

例如：

project-a profile:
  default workspace = 项目A
  device_name = 项目A-WSL

project-b profile:
  default workspace = 项目B
  device_name = 项目B-WSL

这样就可以正常使用。

十一、强烈建议设置 alias

为了避免以后忘记带 --profile，建议给两个 WSL 分别设置 alias。

项目A WSL

echo "alias mca='multica --profile project-a --workspace-id 33a4****ba99'" >> ~/.bashrc
source ~/.bashrc

以后使用：

mca daemon status --output json
mca daemon logs -f
mca issue list

项目B WSL

echo "alias mca='multica --profile project-b --workspace-id e044****dc66'" >> ~/.bashrc
source ~/.bashrc

以后使用：

mca daemon status --output json
mca daemon logs -f
mca issue list

以后尽量不要再直接用：

multica daemon start
multica daemon restart
multica workspace switch

因为这会使用默认 profile，容易再次混乱。

十二、最终推荐结构

我的两个项目最后采用这样的结构：

WSL 1：项目A-WSL
  profile: project-a
  workspace: 项目A
  project: 项目A
  local path: /home/***/code/project-a

WSL 2：项目B-WSL
  profile: project-b
  workspace: 项目B
  project: 项目B
  local path: /home/***/code/project-b

每个 issue 都必须写清楚本地路径。

项目A issue 示例：

Project: 项目A
Local repo path: /home/***/code/project-a

Required first commands:
cd /home/***/code/project-a
pwd
git status

项目B issue 示例：

Project: 项目B
Local repo path: /home/***/code/project-b

Required first commands:
cd /home/***/code/project-b
pwd
git status

这样可以避免 Agent 进入错误目录工作。

十三、使用 Multica 多项目时的经验总结

1. 不要在任务运行时重启 daemon

如果：

{
  "active_task_count": 1
}

就不要执行：

multica daemon restart
multica daemon stop

否则任务会被取消。

2. 多 WSL / 多项目必须使用不同 profile

错误方式：

multica daemon start

正确方式：

multica --profile project-a daemon start
multica --profile project-b daemon start

3. profile 初始化要用 setup

如果新 profile 提示：

No server configured. Run 'multica setup' first.

不要直接 login，先执行：

multica --profile project-a setup

4. 一个 workspace 不等于一个 runtime

workspace 是协作空间。

daemon / runtime 才是真正执行任务的地方。

5. Project 也不是强隔离边界

Project 只是 issue 容器。

Agent 具体在哪个目录执行，还是要靠 issue 和 Agent 指令明确约束。

6. 每个 issue 必须写清本地路径

例如：

Local repo path: /home/***/code/project-b

并要求 Agent 先执行：

cd /home/***/code/project-b
pwd
git status

十四、最终结论

Multica 是支持多机器、多 workspace、多 runtime 的。

我之前遇到的问题，不是 Multica 不支持多机，而是两个 WSL 都在使用默认 profile，导致 daemon state 没有隔离。

最终正确解法是：

不同项目
  ↓
不同 WSL
  ↓
不同 profile
  ↓
不同 default workspace
  ↓
不同 daemon_id / device_name

最终运行方式：

# 项目A
multica --profile project-a daemon start

# 项目B
multica --profile project-b daemon start

再配合 alias 固定 workspace：

mca daemon status --output json

这样两个项目就可以在两台 WSL 上同时运行，而不会互相顶掉。

Comments

Multica 多机多项目运行避坑指南