Multica | 进击之路 - Alan的个人博客

Multica Go 使用指南：你可能还不知道的实用技巧

Thu, 09 Jul 2026 09:41:42 +0800

Multica AI 是一个很不错的 AI Agent 管理平台。但真正用起来后，你很快会遇到一个现实问题：人不可能一直坐在电脑前。

Multica Go 就是为这些移动场景准备的非官方 iOS 客户端。它不是简单套一层网页，而是使用 SwiftUI 重写的原生 App，可在 iPhone 和 iPad 上管理 Agent、Chat、Inbox、Issue、Project 和用量数据。

这篇不打算把每个按钮都讲一遍，而是结合 App 当前已经实现的功能，介绍几个真正能提高移动端使用效率的技巧。

移动端有哪些选择？

目前在移动设备上使用 Multica，大致有三种方案：

网页版：Multica 官方网页有一定的移动端适配，打开浏览器就能使用，适合偶尔查看。
官方 App：官方仓库中有移动端实现，但如果尚未通过 App Store 公开提供，普通用户的安装门槛会比较高。
Multica Go：非官方原生客户端，已上架 App Store，支持 iPhone 和 iPad，可连接官方 API，也可连接兼容的自定义或私有部署服务。

下载地址：Multica Go - App Store

注意：Multica Go 是非官方客户端，使用前需要已有 Multica 账号，或者一个可连接的兼容 Multica 服务。App 要求 iOS 18 或更高版本。

技巧一：用语音快速创建 Issue、评论和聊天

真正的移动场景里，语音往往比键盘更有用。比如我在路上突然想到一个需求，可以直接新建 Issue，点击麦克风后说出描述，转成文字后检查一遍即可提交。

Multica Go 的语音输入不只用于新建 Issue，也已经接入：

Issue 描述；
Issue 评论和回复；
与 Agent 的 Chat 消息。

可以在「我 → 偏好设置」中选择语音识别语言。如果你经常口述 Agent 名、项目名或专有术语，还可以结合下面的自定义语音词汇使用。

技巧二：用自定义语音词汇纠正专有名词

语音识别最容易出错的，往往不是普通句子，而是产品名、Agent 名、项目名、英文缩写和团队内部术语。比如你明明说的是「Multica」，识别结果却可能变成发音相近的其他词。

Multica Go Pro 提供了「自定义语音词汇」，每条词汇可以配置：

正确词汇：你最终希望得到的写法，例如 Multica Go、AOL-909 或某个 Agent 的名字；
误识别别名：语音识别经常产生的错词，同一个正确词汇最多可添加 5 个；
启用状态：可以暂时停用某条规则，不必直接删除。

它实际上做了两层优化：正确词汇会作为提示词提供给语音识别引擎；如果转写结果仍然出现了你设置的误识别别名，App 会将完整匹配的错词替换为正确词汇。它不是对整段文字进行模糊的 AI 改写，因此替换结果更可控。

编辑词汇时还可直接点击麦克风进行「测试识别」，当前正确词和别名会立即用于这次测试，不需要先保存。确认效果没问题后再存入词典即可。

设置路径为「我 → 偏好设置 → 识别方案 → 自定义语音词汇」。最多可保存 100 条词汇，对经常用语音给 Agent 下达任务的用户来说，这个功能比单纯换一个识别语言更有针对性。

技巧三：把多服务器和多 Workspace 当成一个入口

如果你同时使用官方 Multica、测试环境和自己私有部署的服务，反复退出登录会很麻烦。Multica Go 支持保存多个服务器账号，切换时会重新加载该服务器下的项目、Agent 和 Inbox；同一服务器内的多个 Workspace 也可以在同一个面板中切换。

操作入口有两个：

在首页向右滑出侧边抽屉；
点击首页顶部的服务器标识。

免费版可连接 1 个服务器；添加更多服务器属于 Pro 功能。所以“支持多服务器”和“免费版可无限添加”是两件事，这一点需要区分。

技巧四：用链接或二维码迁移服务器配置

换新 iPhone、给 iPad 添加同一服务，或帮团队成员配置私有服务时，没必要手动重新输入地址。

在服务器列表中长按某个服务器，可以：

分享服务器导入链接；
生成服务器邀请二维码；
通过 iOS 系统分享面板发送给另一台设备。

接收端可直接打开链接，也可在登录页扫码。更快的做法是长按桌面上的 Multica Go 图标，选择「扫描二维码」。扫码后 App 会先解析配置，再进入添加服务器流程，而不是不经确认就直接登录。

技巧五：从剪贴板快速打开 Issue

在电脑上复制了一条 Multica Issue 链接，切到 iPhone 后不用再手动搜索 Issue 编号。「剪贴板链接检测」默认开启，App 在回到前台时会识别剪贴板中的 Issue 链接。

这里有几个重要的实际行为：

该功能默认开启；
可以随时在「我 → 偏好设置 → 剪贴板链接检测」中关闭，关闭后 App 回到前台时不再读取剪贴板；
只识别与已登录服务器地址匹配的 Issue 链接；
识别成功后会弹出确认，不会静默自动跳转；
如果链接属于其他服务器或 Workspace，确认框会说明即将切换上下文。

这个设计既省去搜索步骤，也把是否读取剪贴板的控制权留给用户，并避免 App 突然切换工作区。不过，有些人会觉得回到 App 时出现链接提示很烦，或者本身就不希望 App 读取剪贴板。这种情况下直接关闭「剪贴板链接检测」即可，不会影响搜索、深度链接等其他功能。

技巧六：分享一条既能打开网页、也能打开 App 的 Issue 链接

在 Issue 详情页右上角点击分享按钮，Multica Go 会生成一条通用的 Issue 分享链接。它不是只有安装了 App 才能识别的自定义 Scheme，而是一条普通的 HTTPS 链接，所以可以直接发到微信、邮件或者其他聊天工具中。

这条链接同时兼容网页和 App，而不是强制自动跳转。在新设备的浏览器中打开后，页面会给出可用的打开方式，由用户自己选择：

在网页中打开：继续访问该 Issue 的原始 Web 页面，没有安装 Multica Go 也可以使用；
打开 Multica Go：如果设备已安装 App，可以主动选择跳转到 App；
已安装 App 且已配置对应服务器：选择在 App 中打开后，Multica Go 会根据链接中携带的服务器、服务器 ID 和 Workspace 信息定位上下文，需要时先引导切换服务器或 Workspace，再进入对应 Issue。

这样的好处是，分享者不需要先问对方“你有没有安装 App”，也不需要分别发送 Web 链接和 App 链接。同一条链接既可以作为浏览器入口，也可以在新设备上引导用户回到 Multica Go 继续处理。

分享链接只是负责定位 Issue，不会绕过 Multica 本身的登录和访问权限。接收者仍然需要拥有相应服务器和 Workspace 的访问权限。

技巧七：用 Handoff 把 Issue 接力到 Mac

有些 Issue 在手机上看到后，只需要回一句就能处理；但如果涉及大段代码、复杂日志或者要同时对照多个文件，还是回到 Mac 更高效。Multica Go 支持 Apple Handoff（接力），可以把 iPhone 或 iPad 上正在查看的 Issue 继续到附近的 Mac。

使用时，在 Multica Go 中打开某个 Issue 详情页，Mac 的程序坞或应用切换器中会出现接力入口。点击后，Mac 会通过该 Issue 的网页链接继续打开当前内容。它不是把整个 App 界面复制到 Mac，而是精确接力当前正在阅读的 Issue。

开启入口在「我 → 偏好设置 → Issue 接力」。这项功能需要 Multica Go Pro，同时需要在 iPhone、iPad 和 Mac 的系统设置中开启「接力」，并满足 Apple 连续互通的设备条件。

我觉得这个功能最适合这样的工作流：通勤时在手机上通过 Inbox 快速筛选 Issue，到电脑前后直接接力到 Mac 继续深入处理，中间不需要重新搜索或复制链接。

技巧八：把 Inbox 当成移动端的待办入口

Multica 的 Inbox 不只是“消息列表”，更适合当成移动端的任务分流器。Multica Go 支持未读状态、下拉刷新、点击标记已读和左滑归档，也提供批量操作：

全部标记已读；
归档所有已读项；
归档已完成项；
全部归档。

点进某条通知后，App 会直接进入对应的 Issue 或评论上下文。我的习惯是：在外面先用 Inbox 完成“看一眼、回一句、归个档”，需要长时间处理的任务再留到电脑端。

技巧九：开启云端通知，但先了解它的边界

如果 App 没有启动，或已经长时间处于后台，本地客户端无法自己持续查看 Inbox。Multica Go 因此提供了「云端通知」，新消息到来后可通过 iOS 推送提醒，点击通知还能跳到对应 Issue。

不过，这项功能有三个需要明确的边界：

云端通知是单独按月订阅，不包含在 Multica Go Pro 中。
由于 Multica 官方目前没有提供相应 webhook，推送服务需要托管你专门创建的 API token，并轮询新消息。
通知不是绝对实时，最多可能有约 1 分钟延迟。服务端会加密存储 token，但如果你不希望将 token 托管给推送服务，就不建议开启。

开启入口在「我 → 偏好设置 → 云端通知」。建议为推送单独创建 token，以后不再使用时也更容易撤销。

技巧十：别忽略全局搜索

Multica Go 的搜索不只能找 Issue，也能找 Project，还可以当成 App 内的快速导航入口。输入“用量”、“云端通知”、“语音识别”、“外观”等关键词，可以直接进入对应页面，不必在多层菜单中翻找。

搜索还有一个适合重度用户的用法：先搜 Issue 关键词，进入详情后直接修改状态、优先级、日期、负责人或标签，并可上传图片和文件、回复评论。这样就不只是“在手机上看一看”，而是真正能完成一次完整的 Issue 处理。

技巧十一：用小组件随手看 Agent 和用量

Multica Go 的 Usage 页可以查看 token 用量、费用、运行时长和 Agent 排名。如果你只想快速看一眼，可以把小组件加到主屏或锁屏：

主屏用量摘要和 Token 趋势，可在编辑小组件时选择统计周期；
锁屏显示正在工作的 Agent 数量；
锁屏显示本周或本月的 Token 用量；
Pro 用户还可使用周度和月度费用锁屏组件。

点击小组件可直接打开 App 内的 Agent 或 Usage 页面。对于同时跑多个 Agent 的用户，这比每次打开网页再找统计页快得多。

基础功能也不只是“查看”

除了上面这些容易被忽略的技巧，Multica Go 目前已经覆盖了一套比较完整的移动端工作流：

与 Agent 聊天，查看相关任务动态，并保留 Chat 草稿；
创建、编辑、删除 Issue，编辑属性，查看时间线并发表评论；
为 Issue 和评论上传图片或文件；
创建、编辑、删除 Project，管理项目资源；
查看 Agent Office，了解哪些 Agent 正在工作；
管理 Squad 和 Automation，查看 Automation 运行记录；
置顶常用的 Issue 或 Project；
使用浅色、深色模式以及自定义强调色。

长按 App 图标时，除了扫码，还可以直接「新建 Chat」或「新建 Issue」。如果你经常在移动端给 Agent 派任务，这是一个很值得养成的操作习惯。

总结

Multica Go 最适合的定位，不是要把桌面端的每一个复杂操作都搬到手机上，而是让你在离开电脑时，仍然能快速完成几件高频的事：

用语音给 Agent 派一个任务；
用自定义词汇纠正专有名词的语音识别结果；
处理 Inbox 里的新消息；
修改 Issue 状态或回复一条评论；
分享一条同时适用于网页和 App 的 Issue 链接；
查看 Agent 运行状态和用量；
把手机上正在阅读的 Issue 接力到 Mac；
在不同服务器和 Workspace 之间快速切换。

如果你已经在使用 Multica，尤其是还有自建服务、多 Workspace 或多 Agent 并行工作的需求，Multica Go 会比单纯在手机浏览器中打开网页更顺手。

Multica 是什么？为什么我又写了一个 iOS 客户端 Multica Go

Fri, 12 Jun 2026 10:30:00 +0800

玩 Multica 有一阵子了，从 Skills、MCP、Claude Code 一路走过来，越发觉得 Multica 这种"把 Agent 当成同事"的产品形态是目前落地/真正能跑起来的方向。玩的越多发现其实也有移动端需求，核心需求点其实跟玩Codex/Claude移动端一样，需要在移动场景下继续玩AI。查询发现官方 iOS App 还没上架，同时自己部署尝试了下，发现体验上目前没能满足我，于是干脆动手做了个非官方客户端 Multica Go，目前也已经上架AppStore。

这篇文章先讲清楚 Multica 是什么、为什么值得用，再聊聊 Multica Go。

Multica 是什么

简单一句话：Multica 是开源的 Managed Agents 平台，把 Claude Code、Codex、Gemini、Cursor Agent 这类编码 Agent 变成可以被分配任务的真正队友。

它的核心理念是——

你的下一批员工，不是人类。

听上去有点夸张，但用过一段时间就知道这不是文案：

Agent 有自己的头像和身份，出现在看板上、参与评论、主动报告阻塞。
你像分配给同事一样把 Issue 指派给某个 Agent，它会自己接手、写代码、推 PR、回复进度。
不需要每次复制粘贴 prompt，也不需要盯着终端看它跑。
Agent 的"经验"会沉淀成 Skills，团队里所有 Agent 都能复用。

它解决了什么问题

如果你已经在用 Claude Code、Codex 写代码，应该深有体会：

上下文丢失：每开一个新窗口都要重新交代项目背景。
任务管理缺失：跑了什么、跑成什么样、谁负责跟进，全靠记忆。
多 Agent 切换累：Claude Code 适合做这件事，Codex 适合另一件，手动切换非常碎。
重复劳动：同样的部署/迁移/审查流程，每个项目都要重新教一遍 Agent。

Multica 把这套流程产品化：

Issue 是一等公民——所有任务都以 Issue 的形式存在，有状态、有评论、有时间线。
Agent 即队友——指派 Issue 时，Agent 出现在 Assignee 下拉里，和人类成员并列。
Squads 路由——团队大了之后，可以把任务分给一个由 Leader Agent 带队的小队，Leader 自己决定让谁干。@FrontendTeam 比 @小张或小李或小王 稳定得多。
Skills 复用——每解决一个问题，就沉淀一个 Skill，下次直接调用，不用从零教起。
Autopilots——Cron / Webhook 触发的定时任务，日报、周报、代码巡检都能让 Agent 自己跑起来。

架构和技术栈

后端是 Go 写的，整体很干净：

┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Next.js │────▶│ Go 后端 │────▶│ PostgreSQL │
│ 前端 │◀────│ (Chi + WS) │◀────│ (pgvector) │
└──────────────┘ └──────┬───────┘ └──────────────────┘
 │
 ┌──────┴───────┐
 │ Agent Daemon │ 跑在你自己的机器上
 └──────────────┘

支持的 Agent CLI 矩阵很全：Claude Code、Codex、GitHub Copilot CLI、OpenClaw、OpenCode、Hermes、Gemini、Pi、Cursor Agent、Kimi、Kiro CLI。

怎么开始用

看官网
看看我之前总结的自部署指南，作为补充。
还有问题，看官方repo源码。

然后是 Multica Go

正如一开始聊到的，移动端我有强烈需求，我希望能在手机上像看 GitHub iOS App 一样自然地刷 Inbox、回评论、改状态、尤其是创建Issue，所以就有了 Multica Go。

它是什么

非官方 iOS App，用 SwiftUI 原生重写，体验/功能源于官方网页版及个人实际使用中产出的需求。
名字叫 Multica Go。
关键差异化：支持自定义服务地址——可以连接官方云、也可以连接自部署 Multica 实例，支持多Server连接，方便切换，比如我自己需要连接3个Multica服务，支持语音输入，支持更丰富的交互细节/功能，当然核心功能是看Multica 服务端，有多少API就决定了App的能力上限，客户端只是一种调用方式。

当前已经能用的能力

Keychain 安全存储 token 和 workspace
工作区选择 / 切换
Inbox：列表、未读样式、点击已读、左滑归档、批量标记/归档
Issues：我的 Issue 列表、详情、Timeline、评论、状态/优先级/日期编辑、创建/编辑/删除
Chat：会话列表、消息发送、Agent task 状态、草稿持久化
Projects：列表、详情、资源管理、增删改
Search：全局搜索 Issue / Project
语音输入：在 Issue 评论和 Chat 消息输入框里都可以切换到语音输入，利用 iOS 的系统语音识别，支持普通话和英语，识别结果会实时显示在输入框里，识别结束后自动发送。
国际化：支持中/英/韩/日。

还在路上

一直在路上，持续迭代中，毕竟我自己就是深度用户，需求驱动。

体验地址

目前 Multica Go 已上架，感兴趣可以试试：

👉 https://multica.1991421.cn/

写在最后

Multica 是我最近最舍不得放下的一个工具。它不只是又一个 AI Wrapper，而是把"AI 协作"这件事真正做成了产品形态——有看板、有 Issue、有 Squad、有 Skill 沉淀。再加上完全开源、可自部署，对于个人开发者和小团队都是非常友好的方案。

至于 Multica Go，是我用自己的产品热情给 Multica 投的一票。如果你也在用 Multica，又对官方 App 不太满意，不妨上 TestFlight 试一下，欢迎反馈。

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。
祝玩好🚀。