01 · 为什么 Multica 值得单独拆
`Multica` 之所以重要，是因为它把“多个 coding agents 如何像人类队友一样被管理”这件事做成了产品壳，而不只是一组后台 worker。
从 README 看，它最核心的动作是：把 agent 放到 board 上，让它们被分配任务、发评论、汇报阻塞、沉淀 skill。也就是说，它不是在卖某个模型，而是在卖 managed agents project platform。
02 · Multica 先拼的是哪几层
| 层次 | 关键锚点 | 解决的问题 |
|---|---|---|
| 前端层 | Next.js board / workspace | 人和 agent 如何在同一个任务面上协作 |
| 后端层 | Go backend + websocket + PostgreSQL | 任务流、状态流、runtime 注册如何统一 |
| runtime 层 | local daemon、cloud runtime、CLI auto-detect | Agent 到底在哪台机器、用哪个 provider 干活 |
| agent 执行层 | Claude Code / Codex / OpenClaw / OpenCode | 真正执行代码任务的 worker 从哪来 |
| 能力沉淀层 | successful solutions become reusable skills | 成功经验如何变成团队资产，而不是只存在一次任务里 |
03 · 它最关键的地方：Daemon 和 Runtime 被正式命名了
`Multica` 很值得我们参考的一点，是它把很多项目里“默认藏着的层”都正式命名了：`daemon`、`runtime`、`workspace`、`agent`。
这和我们现在给 `codex-loop` 补的 `connector / runtime / daemon` 三层很接近。区别是 Multica 先把这套东西产品化成了 board + daemon 的形式，让“agent 在哪台机器上跑、当前活着没有、能接什么 CLI”都变成可见状态。
04 · 它不是聊天前端，而是 Board 视角的多 Agent 协作面
如果说 Cabinet 把知识库当主壳，Multica 则明显把 board 当主壳。这里最重要的不是一个更华丽的聊天框，而是：agent 像同事一样出现在任务板上。
这意味着它的主视角不是“我和一个 agent 对话”，而是“团队里有哪些 agent、谁领了什么活、谁卡住了、谁交付了结果”。这就是 managed agents 和单 agent 工具最大的产品观差异。
05 · “成功方案沉淀成 Skill” 是最有产品味的一层
README 里这句非常关键：successful solutions automatically become reusable skills。这不是一个可有可无的小功能，而是 Multica 最像“团队系统”的地方。
它不只是把 agent 任务跑完，而是试图把团队里一次次成功的处理方式收成下一次可以复用的 skill。这个思路和我们自己的 `skills + plan + evolution` 很接近，只是 Multica 把它更明确地和 board、runtime、workspace 绑在了一起。
06 · 对 LikeCode / codex-loop 最值得学什么
第一，daemon / runtime / worker provider 要成为正式层，而不是隐形脚本。
第二，多 agent 协作的主视角更适合落在 board / assignment / blocker / status，而不是单个聊天窗口。
第三，skill compounding 很值得学，它让结果不只回到 transcript，而是回到团队长期能力里。
第四，Multica 更像 runtime-first 的 managed agents 平台，这点和 Cabinet 的 knowledge-first 形成了很好的对照。
参考与原始链接
- multica-ai/multica
- Multica 官网
reference/reference_meta(Manage)agent/multica/README.mdreference/reference_meta(Manage)agent/multica/docs/reference/reference_meta(Manage)agent/multica/cli/