文章

Multica：用了一圈之后，我理解它是怎样把 AI 装进一个团队里的

Multica 不是又一个 AI 聊天工具，它更像一个让 Agent 真的接单、交接、汇报的协作平台。记录我自己用下来觉得有意思的几个点。

发布于

老实说，我之前用 ChatGPT、Claude 用了很久，一直有个挺别扭的地方：单次聊天里它真的惊艳，可一旦任务变长、要分步、要换”角色”，就得我自己来回复制粘贴、换模型、记着”上一步到哪了”。

后来我开始用 Multica。它不是又一个聊天框，更像是一个让 AI 真的像团队成员一样接活、交接、汇报的平台。这篇文章就是我用下来之后觉得值得分享的几点，不打算写得太”产品介绍”，更偏我个人观察。

为什么我会想用它

我之前在做个人项目时遇到一个典型的痛点：想写一篇关于某个工具的深度测评，流程上是这样的——

  1. 让一个 AI 帮我列大纲；
  2. 切到另一个 AI 帮我查资料；
  3. 再切回第一个 AI 写初稿；
  4. 切到第三个 AI 帮我挑错。

切来切去，我中间要在 3-4 个 tab 之间手动搬运文字。最崩溃的一次，我在第 4 步里发现初稿里有个事实错误，回去查第 2 步的资料——结果发现第 2 步给的链接其实是错的，因为当时没让我附原始数据。

Multica 解决的就是这一类问题：你不再是和单个 AI 对话，而是在和一个”小团队”协作。每个 Agent 有自己的角色和工具，你能像派活一样把任务分出去，让它们互相交接。

我理解的几个核心概念

  • Issue 就是任务。我创建一个 Issue，描述清楚要做什么，分配给某个 Agent，然后它就开始动。这跟我在公司里用 Jira 的感觉很像，但干活的是 AI。
  • Agent 是干活的”人”。每个 Agent 都有自己的能力范围和可用工具——能读代码、能搜网页、能跑命令。我可以为不同场景配不同的 Agent，比如专门写代码的、专门做调研的。
  • Squad 是一组 Agent 一起做一件更大的事。比如我设过一个”内容发布”小 Squad：写作 Agent 起草，校对 Agent 挑错，发布 Agent 同步到平台。Squad 里的 Leader 负责协调谁先谁后。
  • Mention 是我最喜欢的一个设计。在 Issue 评论里 @ 某个 Agent 不只是提醒，是直接让它跑起来。这跟平时和同事在群里 @ 一个人差不多，但被 @ 之后对方是真的会”动”的。

一个我真实跑过的流程

拿”为博客写一篇关于 Multica 的文章”这个任务举例，我在 Multica 里实际的流程是这样：

  1. 开一个 Issue，把要求写清楚，分配给写作 Agent。
  2. 写作 Agent 读 Issue、检查仓库、看我以前的文章是什么风格，然后出初稿。
  3. 我在评论里 @ 校对 Agent，它过一遍逻辑和事实。
  4. 校对 Agent 把发现的问题列在评论里，写作 Agent 再来一轮。
  5. 我自己看一遍，OK 之后把状态改成 done。

整个过程里，我主要在开头写需求和最后做验收，中间那几轮都是 Agent 自己跑、自己交接。我中途没动过 tab。

它和 AutoGen、CrewAI 那种”框架”不一样

这个问题我之前也被问过几次。

框架适合那些要把 Agent 流程写到代码里的场景——你有强烈的定制需求，团队里也养得起工程师去维护那一套编排代码。Multica 走的是另一条路：它把这些做成了产品化能力，Issue 看板、评论、权限、调度都开箱即用，我不需要写任何编排代码就能用。

对我这种”想用 AI 但不想自己造一套轮子”的人来说，Multica 的定位更舒服。

用了一段时间后的一些吐槽

  • 不少任务跑起来还是有点慢，可能是因为 Agent 之间要互相等。如果你时间特别紧，会有点不耐烦。
  • 想要复杂的自定义工作流，目前还是要回到框架那种方式。Multica 更适合 80% 的常见场景。
  • 计费模型需要稍微关注一下。如果开了 Autopilot 让它自动跑，月度账单可能会比预期高一点。我后来设了预算告警。

我自己会怎么用下去

我现在的用法是：日常那些标准化的活（比如写周报、整理会议纪要）丢给 Multica 的小 Squad，能省下不少时间；比较创意、需要反复打磨的东西，我还是习惯自己先写一版，再让 AI 帮我补和改。

说到底，AI 不会让我变强，但它能让我把时间花在我更擅长的事情上。这一点，是我用 Multica 之后最明显的感受。