Multica：把人和 Agent 放到同一块看板上

我为什么会认真看 Multica

最近被安利去试了下 Multica。老实说，一开始我并没有把它当成什么“下一代 AI 协作平台”来看，我的预期其实很低：大概率又是一个把聊天、任务、自动化脚本揉在一起的壳。

但真正跑起来之后，我对它的判断变了。

它最吸引我的地方，不是“能调很多模型”，也不是“能派很多 Agent”，而是它把人和 Agent 放进了同一块任务看板。这个抽象听起来非常普通，甚至有点不性感，可它恰好踩中了一个现实问题：今天我们用 Agent 干活，最麻烦的往往不是模型能力，而是协作界面。

人怎么提需求，Agent 怎么接任务，结果怎么回流，谁来做最终判断，出错以后怎么留痕。这些东西如果没有统一界面，最后还是会退回到一堆聊天窗口、一堆脚本和一堆“你帮我看下这个”的手工协作。

我把它部署到了家里的 Mac mini M4 上，认真跑了几轮之后，越来越觉得：Multica 现在未必已经很好用，但方向可能是对的。

它到底是什么

如果只用一句话来概括，Multica 是一个让人类和 AI Agent 共享同一块看板的协作平台。

它的工作流很直接：

1. 人创建一个 Issue。
2. 把 Assignee 指给某个 Agent。
3. Agent 在绑定的 Runtime 上自动领活、拉仓库、执行任务。
4. 结果和过程回写到同一个 Issue 里。
5. 状态最后推进到 In Review，而不是直接 Done。

这个 In Review 细节我很喜欢。它几乎在产品层面写死了一个原则：Agent 可以负责执行，但最终判断必须保留给人。

如果你平时更习惯命令行，这套流程用 CLI 其实非常顺：

multica issue create --title "写一篇 Multica 体验文章"
multica agent list --output json
multica daemon status
multica issue comment add <issue-id> --content "文章初稿已完成"

这也解释了为什么我会觉得它不是简单的“AI 看板”。它更像是在尝试定义一层 Agent 协作的基础接口。

部署体验：整体顺，但有两个坑

从部署角度说，它的技术栈并不复杂：Go 后端、Next.js 前端、PostgreSQL，基础设施很常规，docker compose 也足够友好。我这边配的是 OrbStack 加 Cloudflare Tunnel，前后端分别挂两个子域名，整体流程不算折腾。

但有两个坑，值得提前说。

第一个坑是官方 compose 默认更偏向预构建镜像。单域名没什么问题，但如果你和我一样用双域名部署，又想自定义 WebSocket 地址，那很快就会发现默认方案不太够用。这个时候最省时间的做法不是继续硬改配置，而是直接切回源码构建。

第二个坑是 APP_ENV=production。一旦进生产环境，万能验证码 888888 会被禁掉。如果这时候你还没有提前配好 Resend 邮件 API，就有概率把自己锁在系统外面。这个问题不严重，但第一次部署时确实挺容易踩。

即便如此，我对部署体验的结论还是偏正面。因为真正跑起来之后，它的工作路径很清楚，尤其是 CLI 的可用性，比很多只强调“控制台体验”的 Agent 工具顺不少。

真正让我决定继续用的，是 Runtime

Multica 的概念模型其实很清晰：

Workspace -> Project -> Repo -> Issue -> Agent -> Runtime

前面几层大家都熟，真正让我停下来多看一眼的是最后一层：Runtime 绑定的是机器，而 Agent 绑定的是 Runtime。

这意味着你不是在抽象地说“让一个 Agent 干活”，而是在明确地说“让这个 Agent 在这台机器上干活”。

这个设计非常实用。因为现实里的开发环境根本不是均质的。

我自己手头就有几台 Mac。有些任务只能在公司电脑上跑，因为依赖内网、证书、特定代理或者本地缓存环境。过去这种需求很难优雅自动化，最后通常都会退化成一句话：这个任务你只能上那台机器手动做。

而 Runtime 把这个问题变成了一个很自然的调度问题。

只要那台机器常驻 daemon，再创建一个绑定到对应 Runtime 的 Agent，任务就只会被那台机器领走。这个能力听起来不花哨，但它解决的是 Agent 落地里一个很硬的现实约束，所以我会把它看得比“支持多少模型”更重要。

Skills 和 CLI 才是第二层价值

如果说 Runtime 解决的是“在哪跑”，那 Skills 解决的就是“怎么复用经验”。

这也是我觉得 Multica 和很多任务分发工具不一样的地方。Agent 不是一次性劳动力。一个 Agent 解决过的问题，可以沉淀成 Skill，然后在整个 Workspace 里复用。部署流程、审查规则、迁移步骤、排障清单，这些东西第一次有机会真正从“某个人脑子里的经验”变成“团队里可调用的能力”。

它不是 prompt 收藏夹，也不是文档仓库。它更接近可执行的经验模块。

再加上 CLI 足够完整，这个价值就更明显了。因为 Agent 本身并不需要浏览器，它需要的是：

• 能拆任务
• 能写评论
• 能追踪状态
• 能触发其他 Agent

而这些动作，用 CLI 比用面板自然太多了。

某种意义上，这让我意识到一件事：Multica 最适合服务的对象，可能不是人，而是 Agent。

人类确实也会用它，但它真正舒服的地方，在于 Agent 可以围绕这套接口去协作，而不是只等着人一个个地下命令。

它也暴露了一个更深的问题

不过 Multica 真正有意思的地方，恰恰不只是它现在做对了什么，而是它暴露了下一阶段的问题。

今天这类平台默认的工作方式，仍然是：

人定义任务边界 -> 人创建 issue -> Agent 执行 -> 人审核结果

这个范式在今天是合理的，因为大模型的稳定性、自主性和长期规划能力都还没有强到可以完全接手任务拆分。

但如果 Agent 再往前走一步，未来更自然的流程很可能会变成：

人描述目标 -> Agent 自己定义任务 -> 多个 Agent 自己拆分和协调 -> 人只审核关键节点

一旦进入这个阶段，Issue 驱动本身就会开始显得笨重。不是因为它错了，而是因为它代表的是一个“人类先把边界画好”的时代。

所以我现在看 Multica，会把它理解成一种过渡态产品：它一方面非常贴合今天的现实，另一方面又已经把“以后该怎么进化”的问题摆到台面上了。

它要么继续长成 Agent 的操作系统，要么未来会被更原生的 Agent 协作协议替代。

为什么我暂时把它当成一笔基础设施投资

还有一个我觉得很现实的视角，是额度利用率。

很多人现在同时订阅 Claude Code、Codex，甚至别的 Agent 工具。问题已经不是“我有没有模型能用”，而是“我怎么把已经买下来的算力真正用满”。

从这个角度看，Multica 这类工具的意义很直接：它让 Agent 在你不盯着的时候也能领活、执行、回传结果，尽量减少订阅额度的空转。

这也是为什么我会把它理解成基础设施投资，而不是立刻见效的效率神器。

它现在给我的收益还没有大到让我惊呼“必须全量迁移”，但它很像一套应该先接上、先跑着、先让数据和流程积累起来的东西。因为只要 Agent 能力继续增强，这套基础设施的边际价值就会越来越高。

写在最后

我现在对 Multica 的态度，大概可以概括成一句话：今天它已经有用，但真正大的价值，可能还没到兑现的时候。

它最打动我的，不是某一个功能点，而是它试图认真回答一个问题：当人和 Agent 都成为团队里的实际参与者时，协作界面应该长什么样。

这件事如果做对了，未来很多今天看起来还很“实验性”的 Agent 工作流，都会突然变得顺理成章。

所以我的结论不是“马上把所有工作搬上去”，而是更保守、也更长期一点的判断：

先装上，先把 daemon 跑起来，先让机器和 Agent 开始协作。

剩下的价值，也许会随着模型能力一起到来。