Multica——给你的Agent们找个项目经理

最近扒 GitHub 看到一个挺有意思的项目：Multica。半年时间涨到 4 万多星，到现在还在天天更新。

它想解决的问题挺具体：现在大家用 AI 写代码，基本是"打开对话框、聊一句、它答一句"。但真实工作里，活不是这么干的——你不会跟同事一句句聊，你会把任务丢给他，让他自己去做，做完汇报。Multica 就是能派活、能当监工的项目经理。

项目地址： https://github.com/multica-ai/multica

它到底怎么用

一句话：像 Jira / Linear 那样的任务看板，但看板上的活，可以指派给 AI。多个任务可以同时派给不同的 AI，各干各的，你像个项目负责人一样盯着看板就行。

我觉得它设计得聪明的地方

它没有让多个 AI"互相聊天商量着干活"。

这点反直觉，但很关键。让几个 AI 直接对话协作，听起来高级，实际很容易乱——聊着聊着跑偏，出了错也不知道错在哪，人还插不上手。

Multica 的做法是：所有 AI 都围绕那个共享的任务看板干活，不直接对话。协作这件事交给"看板"这个中间人。好处是——谁干到哪一目了然、某个任务失败了能单独重试、人随时能接管。这更像真实人类团队的协作方式。

它真正的"硬功夫"藏在看不见的地方

看板界面谁都会做。Multica 花最多力气的，其实是一个用户根本看不到的地方：一个叫 daemon 的本地常驻进程，以及围绕它建起来的整套可靠性机制。

很多人以为 Multica 的架构就是"前端看板 + 后端服务器"，其实不是。它是一个三段式架构，中间多了一层：

浏览器看板 ←→ Multica 服务器 ←→ 本地 daemon ←→ AI Agent（Claude/Codex/Gemini…）

第一层：浏览器 ↔ 服务器 — 解决"看"的问题。

你在看板上看到的任务状态变化（"执行中"→"已完成"），不是浏览器每隔几秒刷一次问服务器"好了没"，而是服务器通过 WebSocket 长连接主动推过来的。状态一变，卡片就动。断线了会自动重连，重连后从上次的事件序号继续推，中间不丢状态。这一层是纯展示层，不触碰任何 AI 执行逻辑。

第二层：服务器 ↔ daemon — 解决"调度"的问题。

这是整个架构最关键的一层，也是 Multica 和其他 AI 工具最大的区别。

为什么不能让服务器直接调用 AI？因为 AI 编程工具需要访问你的本地代码和文件系统。Claude Code 要读你的仓库、写你的文件、跑你的测试——这些东西在你的电脑上，不在云端。服务器在云上，它碰不到你的代码。

所以必须有一个东西跑在你的本地，既能被服务器远程指挥，又能操作本地文件。这就是 daemon ——后台常驻进程。

它和服务器之间的通信方式是daemon 主动拉取：每 3 秒问一次服务器"有任务给我吗？"，同时每 15 秒发一次心跳"我还活着"。为什么不用服务器主动推？因为 daemon 在用户的个人电脑上，很可能在 NAT 或防火墙后面，服务器根本连不进来。让 daemon 主动往外连，连接就不是问题了。

第三层：daemon ↔ AI Agent — 解决"执行"的问题。

daemon 本身不写代码。它是一个调度器：拿到任务后，在本地创建一个隔离的工作目录，然后启动一个 AI CLI 的子进程来干活。daemon 启动时自动扫描你电脑上装了哪些，注册为可用的"运行时"。

这层用的是最朴素的通信方式：操作系统级别的进程管理。daemon 是父进程，AI 是子进程，通过标准输入输出和文件系统交互。子进程挂了，父进程立刻知道；需要取消任务，直接发信号杀进程。没有网络、没有序列化，是整个架构里最可靠的一层。

这才是这类产品真正的门槛——不是界面好不好看，而是你敢不敢挂一堆 AI 跑一整晚，第二天回来发现活没丢、没乱。

一点自己的看法

这类"AI 协作平台"现在很火，大厂也在做。但我觉得它更像一个过渡形态：现在需要一个看板管着，是因为 AI 还不够可靠、还得人盯着。等 AI 更成熟了，协作方式可能完全变样。不过过渡期也可能很长。