Multica 是什么？多Agent协作平台使用指南

Tue, 26 May 2026 14:50:09 +0800

最近使用 Multica多一些，这篇文章记录下我目前对 Multica 的了解/理解。

Multica 是什么？

官方描述：The open-source managed agents platform. Turn coding agents into real teammates — assign tasks, track progress, compound skills.

Multica 不是AI模型，不是一个新的 AI Chat 工具，而是一个面向 Human + Agent Team 的 AI 团队协作平台。

它做的事情，可以理解为：把 Claude Code、Codex、OpenCode、OpenClaw 等 AI Coding CLI 接入到一个统一的项目协作流里，让 Agent 像团队成员一样被分配任务、执行任务、汇报进度、暴露阻塞，并把可复用的经验沉淀成 Skills。

Multica 解决了哪些痛点？

1. AI CLI 工具很多，但缺少统一入口

现在 Claude Code、Codex、OpenCode、OpenClaw 这类工具都很强，但它们本质上还是一个个独立的 CLI。个人临时用没问题，一旦任务变多，就容易出现几个问题：

哪个任务给了哪个 Agent？
Agent 执行到哪一步了？
中间有没有卡住？
结果在哪里看？
下次类似任务怎么复用经验？

Multica 的价值是把这些 CLI Agent 纳入一个统一入口，让它们围绕 Issue 工作，而不是散落在不同终端窗口里。

2. Agent 执行过程需要可见、可追踪、可接管

单独使用 AI CLI 时，经常是人盯着终端等结果。Multica 把任务执行过程放到 Web 界面里，让 Agent 的状态、输出、阻塞和结果都能被看到。

这对个人项目管理也有用。因为很多时候我不是缺一个更聪明的模型，而是缺一个能同时管理多个 AI 执行任务的工作台。

3. Prompt 和经验需要沉淀，而不是每次重新写

很多 AI 使用经验如果只停留在 prompt 里，很难复用。比如：

怎么做前端设计审查？
怎么做 SEO audit？
怎么按团队规范发版？
怎么把一个复杂任务拆成可执行步骤？

Multica 里 Skills 的价值就在这里。它不是简单的 prompt 收藏夹，而是把一类工作的方法、上下文、约束和执行流程沉淀下来，让 Agent 在后续任务中持续复用。

4. MCP 让 Agent 能接入真实业务系统

只会写代码的 Agent 还不够。真实工作里，Agent 往往需要读 Figma、查 TAPD、看 GitHub、调内部系统、跑搜索、读文档。

MCP 的意义是把这些外部系统变成 Agent 可以调用的工具。Multica 和 MCP 结合之后，Agent 就不只是“会说会写代码”，而是能接入已有的工作流。

Multica 的核心概念

Multica 表面上是一个 Web 平台，但它背后真正有价值的是把几类 AI 工程能力组合到一起。

Workspace / Issue / Agent

Multica 把 AI Agent 放进类似项目管理的结构里：

Workspace 管项目空间。
Issue 表示一个明确任务。
Agent 是可以被分配任务的执行者。
Runtime 表示 Agent 在哪里跑。
Daemon 负责让任务真正执行起来。

这套结构让 AI 执行不再只是“我在聊天窗口里问一句”，而是变成一个有状态、有记录、有协作入口的工作流。

Runtime

Runtime 是真正执行任务的环境。它可以是你本地电脑，也可以是一台服务器。

Multica 自己不是替你完成所有代码任务的模型平台。它更像一个调度和协作层，把任务分配给某个 Runtime 上可用的 AI CLI，比如 Claude Code、Codex、OpenCode、OpenClaw 等。

Daemon

Daemon 是 Multica 和 Runtime 之间的连接器。

它会在机器上运行，负责发现本机 PATH 里的 AI CLI，注册 Runtime，接收 Multica 分配过来的任务，然后启动对应的 Agent 执行任务，并把状态、日志、结果回传到 Multica。

所以很多问题本质上不是 Multica Web 坏了，而是 daemon 没启动、PATH 没识别到工具，或者本机的 AI CLI 没配置好。

MCP

MCP 可以理解为 Agent 连接外部工具和业务系统的协议层。

比如 Figma MCP、TAPD MCP、GitHub MCP、Firecrawl 等，它们让 Agent 能读取设计稿、查询项目管理系统、访问代码平台、抓取网页内容。没有 MCP，Agent 很多时候只能在本地代码和聊天上下文里工作；有了 MCP，它才更像一个能进入真实工作流的执行者。

Skills

Skills 是我觉得 Multica 这类方案里很关键的一层。

MCP 解决“Agent 能调用什么工具”，Skills 解决“Agent 应该怎么完成一类任务”。比如前端设计、移动端设计、SEO audit、代码审查、发布流程、内部规范，都可以写成 Skills。

这也是我理解的“经验复用”。不是每次都重新写一大段 prompt，而是把稳定的方法沉淀为 Skill，让 Agent 在合适的时候加载这套能力。

Multica 的产品形态与授权

Multica 的迭代进度

官方自身就用 Multica 来管理 Multica 的开发，所以迭代速度非常快，功能也在不断完善中。

这就是标准的魔法打败魔法。

当前 Multica 的形态

PC 网页
iOS App未发布
PC 端 App

开源与授权

是，可以自己私有化部署，代码也都公开。但 Multica 使用的是 modified Apache 2.0，不是完全无限制的 Apache 2.0。

简单理解：组织内部使用、企业内部部署一般是 OK 的；但如果想把 Multica 包装成 SaaS、托管服务，或者作为商业产品的一部分卖给第三方，就需要看它的商业授权限制。另外，使用它的前端时，也不能随意移除或修改控制台里的 Logo 和版权信息。

所以它适合自用、团队内部试点、公司内部私有化部署；如果要对外商业化包装，就需要额外确认授权。

使用 Multica 前需要准备什么

Skills
- 比如 firecrawl、tgit(腾讯工蜂)
MCP
- 比如 TAPD MCP、Figma MCP
Claude Code / Codex / OpenCode 等 AI CLI 工具的使用
提示词

Multica 本身不是魔法。用好它的前提是，你本来就能比较熟练地使用 AI CLI，并且知道怎么把任务拆成 Agent 能执行的粒度。

我自己的经验是：任务越清晰，Multica 越好用；任务越模糊，最后还是会回到人来补上下文、拆步骤、定义验收标准。

Skills 商店

https://www.skills.sh
github
https://skillhub.cn
- 建议下载离线安装

私有化部署流程

下面这部分按一次完整 self-host 的顺序整理：先准备服务器和服务端，再配置访问地址、AI CLI、daemon 和 token。

1. 服务器要求

Docker
Git

2. 安装 Multica Server

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server

docker compose -f docker-compose.selfhost.yml -f docker-compose.selfhost.build.yml up -d --build

# 如果提示不支持compose
yum install -y docker-compose-plugin

3. 安装 Node.js

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

nvm install 26

4. 配置域名和 Caddy

想外网访问，推荐安装 Caddy，当然了，如果只是内网访问的话，可以不安装 Caddy，直接访问http://localhost:8080即可。

域名进行下 DNS 解析，解析到服务器 IP 地址上，然后安装 Caddy，安装完成后在/etc/caddy/Caddyfile中添加如下内容。

yourdomain.com {
 reverse_proxy localhost:8080
}

然后重启 Caddy 服务即可。

systemctl restart caddy

5. 配置 AI 工具

常见可以配置：

codex
opencode
claude code
openclaw
codebuddy
等等

新配置一种 AI 工具，如果 Multica 识别不到，可以进行multica daemon restart重启。关于上述AI工具，我目前主要在用的是codex/opencode。

6. 配置 Daemon

multica setup self-host --server-url https://xxx --app-url https://xxx

如果是内网访问的话，可以直接使用http://localhost:8080。如果是外网访问的话，可以使用域名地址。比如我的 Multica 服务端和 daemon 都在同一台服务器上，那么我就直接使用默认的就行。

7. 创建 Token 并登录 CLI

在设置里创建 token，然后执行：

multica login --token xxxx

常用 daemon 命令：

multica daemon status
multica daemon start
multica daemon restart

# 异常问题，查看日志
vi /root/.multica/daemon.log

8. 确认默认前后端地址

Frontend: http://localhost:3000
Backend: http://localhost:8080

常见问题和排坑

1. daemon 识别不到 AI CLI

如果你新装了 Codex、Claude Code、OpenCode 之类的工具，但 Multica 没识别到，大概率是 daemon 启动时的 PATH 里还没有这些命令。

可以先在终端里确认：

which codex
which opencode

然后重启 daemon：

multica daemon restart

如果还是不行，再看 daemon 日志。

2. 修改 env 后要重建或重启服务

Self-host 的一些配置来自 .env。修改 env 后，不要只刷新页面，需要重建，重启服务。

docker compose -f docker-compose.selfhost.yml up -d --force-recreate backend

查看日志：

tail -f daemon.log

3. 登录和 token 容易混淆

Self-host 之后需要先能登录 Web，再去设置里创建 token，然后 CLI 执行：

multica login --token xxxx

如果没有配置邮件服务，验证码可能需要从后端日志里看。这个地方第一次部署时容易卡住。

4. 外网访问要处理 HTTPS 和域名

内网可以直接用 localhost，外网访问就建议上 Caddy，至少把 HTTPS、反向代理、域名解析处理好。

5. Skills 和 MCP 不是装上就自动好用

Skills 和 MCP 只是能力层，最终效果还是取决于任务描述是否清楚、上下文是否足够、验收标准是否明确。

我的建议是：先从小任务开始，比如修一个明确 bug、做一次 SEO 检查、补一个组件样式，再逐步扩大到复杂任务。

6. agent finished without creating an issue

该错即创建issue失败，比如AI额度不足，登录失效了都有可能，因为issue实际运行中有错，可以在issue详情或者执行日志中查看，但是创建issue环节，目前是不能直观的看到错误的，因此遇到这类报错，重试下或直接切换智能体。

7. AI 生成附件的限制

Chat模式下目前无法直接突出附件，点击下载是会报错
Issue模式目前让AI生成附件到评论中测试是可以，但是在Issue内容中作为附件添加，测试发现不行。

当前Multica版本表现如上述，后续版本可能会修复，可以先按如上方式绕开解决该问题。

8. AI 额度不足等异常导致的任务无法继续推进

可以利用自动化进行定时查询作为补偿方案，因为Agent有权限可以获取所有的issue信息，因此可以定时扫描，如果查到这类状态，进行评论，通过这样添加comment的方式是可以触发Agent处理的。

9. multica服务自动更新

我个人是通过封装脚本并配置 systemd timer 解决的。

1. 创建更新脚本

vi /home/ubuntu/multica/update.sh

按 i 进入编辑模式，粘贴以下内容：

#!/bin/bash

set -e

exec 9>/tmp/multica-update.lock
flock -n 9 || exit 0

cd /home/ubuntu/multica

echo "===== $(date) ====="

docker compose -f docker-compose.selfhost.yml pull
docker compose -f docker-compose.selfhost.yml up -d --force-recreate

multica update

docker ps
multica daemon status

按 Esc，输入 :wq 保存退出，然后赋予脚本执行权限：

chmod +x /home/ubuntu/multica/update.sh

2. 创建 Service

sudo vi /etc/systemd/system/multica-update.service

按 i，输入：

[Unit]
Description=Multica Auto Update

[Service]
Type=oneshot
WorkingDirectory=/home/ubuntu/multica
ExecStart=/home/ubuntu/multica/update.sh

按 Esc，输入 :wq 保存退出。

3. 创建 Timer

sudo vi /etc/systemd/system/multica-update.timer

输入：

[Unit]
Description=Run Multica Update Daily

[Timer]
OnCalendar=*-*-* 04:00:00
Persistent=true

[Install]
WantedBy=timers.target

按 Esc，输入 :wq 保存退出。

4. 使配置生效

sudo systemctl daemon-reload
sudo systemctl enable multica-update.timer
sudo systemctl start multica-update.timer

查看 Timer 是否启动成功：

systemctl status multica-update.timer

查看下一次执行时间：

systemctl list-timers

手动测试一次更新服务：

sudo systemctl start multica-update.service

查看执行日志：

journalctl -u multica-update.service -n 100 --no-pager

如果只是想每天执行一次脚本，systemd timer 是目前 Ubuntu 更推荐的方案；如果只是图省事，也可以使用 crontab。

Agent智能体排队中

并发量可以调整下，看看是不是Agent手上的issue满了。
daemon服务没启动，处于离线状态，那么daemon上的所有智能体都是排队状态，此时就需要启动服务，比如multica daemon start，然后再去查看智能体状态。
daemon版本没升级或没重启服务，因为issue分派和接是server跟daemon交互的，如果daemon版本没升级或没重启服务，那么就会出现智能体排队状态。比如重启下服务multica daemon restart，然后再去查看智能体状态。

运维与升级

查看当前版本号

更新 AI CLI

比如更新 Codex、Claude Code，并不需要去登录目标机器进行安装，直接通过 Multica 运行时，进行更新即可。

升级 Multica 版本

docker compose -f docker-compose.selfhost.yml pull

docker compose -f docker-compose.selfhost.yml up -d --force-recreate

# 升级 daemon
multica update

进阶理解

Agent 协作的三种基本角色

AI Agent 团队协作的本质，可以先拆成三种角色：协调者、工作者、验证者。

该观点来自于multica作者

协调者负责“做什么”：理解目标、拆任务、制定计划，并决定任务应该交给谁。

工作者负责“怎么做”：根据上下文执行具体任务，比如写代码、查资料、改配置、生成文档。

验证者负责“做对了没”：独立检查结果是否满足要求，发现问题后把反馈交回给协调者或工作者继续迭代。

Multica 的价值就在于，它不是只让一个 Agent 在聊天窗口里单点执行，而是把这些角色放进一个可管理、可追踪、可复用的协作流程里。

从源码结构看 Multica

如果从源码层面看，Multica 不是一个单纯的 Next.js 项目，也不是一个只负责启动 CLI 的小工具。它更像一个 monorepo：前端、后端、桌面端、移动端、共享包、部署脚本都放在同一个仓库里，通过 pnpm workspace 和 Go 服务端组合起来。

当前仓库大致可以这样理解：

multica/
├── apps/
│ ├── web/ # Web 控制台，Next.js App Router
│ ├── desktop/ # 桌面端，Electron
│ ├── mobile/ # iOS 移动端，Expo + React Native
│ └── docs/ # 文档站
├── packages/
│ ├── core/ # 前端共享业务能力：API、issues、agents、skills、runtimes 等
│ ├── ui/ # 共享 UI 组件
│ ├── views/ # 可复用视图层
├── server/
│ ├── cmd/ # Go 程序入口，包含 server / CLI / daemon 相关命令
│ ├── internal/ # 后端核心业务实现
├── deploy/ # Helm 等部署配置
├── docker/ # Docker 相关配置
├── scripts/ # 安装、构建、辅助脚本

这个结构里最关键的是三层：

apps/web 是协作界面。用户在这里创建 Issue、配置 Agent、查看 Runtime、管理 Skills、看执行日志和状态。它本身不直接执行 AI 任务，而是通过 API 和 WebSocket 跟后端交互。
server 是调度和状态中心。README 里也明确写了后端是 Go，使用 Chi、WebSocket、PostgreSQL/pgvector。Issue、Workspace、Agent、Runtime、Autopilot、Skill 这些对象最终都要落到后端的数据模型和任务生命周期里。
multica daemon 是真正落到机器上的执行层。它会检测本机 PATH 中的 Claude Code、Codex、OpenCode、OpenClaw 等 CLI，注册 Runtime，轮询任务，然后为任务创建隔离工作目录、启动对应 CLI，并把输出和状态回传给 server。

所以一次 Agent 执行任务，大概是这样的链路：

Web 创建 Issue
 -> server 保存任务和分配关系
 -> daemon 注册 Runtime 并轮询可执行任务
 -> daemon 在本机工作目录中启动对应 AI CLI
 -> AI CLI 修改代码、输出日志、汇报进度
 -> daemon 把状态和结果回传 server
 -> Web 实时展示进度、阻塞、结果

packages/core 也很值得注意。它不是普通工具函数集合，而是把前端多端共享的业务概念抽出来，比如 agents、issues、runtimes、skills、workspace、realtime、permissions 等。这样 Web、Desktop、Mobile 不需要各自重复实现一套业务访问逻辑。

这也是为什么 Multica 的源码结构和它的产品定位是对应的：apps/web 负责人机协作界面，server 负责状态、权限和任务调度，daemon 负责接入真实执行环境，packages/core 则负责把这些业务概念复用到多个端。理解这层结构之后，再看前面说的 Runtime、Daemon、Issue、Skills，就不会只是几个产品名词，而是能对应到源码里的边界。

用 Multica 固化 AI SOP

场景示例

收到 Bug
 ↓
分析原因
 ↓
修改代码
 ↓
运行 npm test
 ↓
如果失败继续修
 ↓
通过后 git commit
 ↓
push
 ↓
创建 PR
 ↓
通知你 Review

Multica 在这里扮演什么角色？

Multica 本身不是 SOP。

它更像是：

执行 AI SOP 的平台。

好比：

SOP = 菜谱 Multica = 厨房大模型（Claude、Codex、GPT）= 厨师

没有菜谱，厨师每次都可能做得不一样。

有了 SOP，再配合 Multica，AI 就能按照固定流程执行。

OPC(One Person Company)

OPC（One Person Company）
 │
 ▼
 需要一个 AI 团队
 │
 ▼
 Multica
 │
 ▼
多个 AI Agent + 多个模型 + 各种工具

Multica 同类产品

Paperclip MIT协议
vibe-kanban

写在最后

我的感受是，它是一个把 AI Coding Agent 接入项目协作流程的平台，并非一个新的AI技术产物，而是AI技术缝合的产物。无论是个人项目管理，还是团队研发协作，Multica 都适合用来管理一批可执行任务的 AI Agent：把需求拆成 Issue，分配给不同 Agent 执行，过程中跟踪进度、查看阻塞，并把稳定的做法沉淀成 Skills。
祝玩好🚀。

AI代理 | 进击之路 - Alan的个人博客