Multica：让人类与 AI Agent 像一支团队那样协作的…

一、Multica 是什么

（一）它想解决什么

README 开篇就点出现状：你已经同时跑着 Claude Code、Codex 和另外几个 Agent，但它们各自待在不同的终端标签页里，会话一结束就忘光，你一天里第四次给同一个 Agent 重述上下文。Agent 越多，你花在「带娃」上的时间越多。Multica 把这些 Agent 和你的队友放进同一个工作空间——一个 issue 被认领、运行、决策与 diff 都挂在同一条线索上，谁都不用重建上下文，也没有任何东西能在没有被人类确认前合并进主干。

（二）核心主张：Agents that show up on the board

项目标语是「Agents that show up on the board」（Agent 要上板子）。每个 Agent 被起个名字、配个 provider 和 runtime，就会像任何人一样出现在看板上；它领任务、报进度、提 blocker、交回 review。官方还补了一句戳心的：Your next 10 hires won’t be human. 它要的不是再换一个更强的模型，而是把一群异构 Agent 组织成一支可管理的团队。

二、组建团队：26 个 Agent CLI 当同事

（一）支持的运行时

Multica 自己不训练模型，它驱动你已经装好并登录的 Agent CLI，所以切换 provider 只是个下拉框，不是一次迁移。README 列出的 26 种运行时涵盖 Claude Code（claude）、OpenAI Codex（codex）、Cursor Agent（cursor-agent）、GitHub Copilot（copilot）、OpenCode、Kimi、CodeBuddy、Grok、Qwen、DeepSeek、MiniMax 等。下面是其中一部分：

正因为 Multica 不绑死任何模型，你今天用 Claude Code、明天换 Codex，工作空间里的 issue、运行记录与历史都不用动——这是它口号里「无锁定（no lock-in）」最实在的体现。对同时评估多个编程 Agent 的团队，这点尤其省心：工具可以换来换去，协作上下文始终留在 Multica 一侧。

• Claude Code：claude；OpenAI Codex：codex；
• Cursor Agent：cursor-agent；GitHub Copilot CLI：copilot；
• OpenCode：opencode；Kimi：kimi；
• CodeBuddy：codebuddy；Grok：grok；Qwen Code：qwen。

（二）Squads、Skills 与自托管运行时

除了单个 Agent，README 还给出三层组织能力：Squads 把 Agent 和人编进同一支队伍，由 leader 路由工作；Skills 把一个已解决的问题固化成每个 Agent 都能复用的 playbook；Daemon runtimes 让你的机器就是 Agent 的「工位」——一个守护进程跑在你的笔记本或云主机上，代码从不离开它。换句话说，你雇的不是某一个模型，而是把一整排 CLI 当成人来排班。

这三层里最值得细说的是 Skills：它把「某类任务怎么做才不出错」沉淀成可共享的 playbook，新 Agent 接入时直接复用，而不是每个都重新踩坑。配合 Squads 的 leader 路由，你可以让一个擅长写测试的 Agent 当 reviewer、一个擅长重构的 Agent 当执行者，人只需要在 review 环节拍板。这种「把经验变成资产」的思路，正是它和单纯「多开几个终端」的本质区别。

三、把活派出去：从一句话 issue 到 PR

（一）指派 issue 与 Autopilots

派活的方式很轻：开一个 issue，把某个 Agent 设为 assignee，它就像同事一样接走任务、在运行时里跑、边做边评论，做完把 issue 挪到 review。更进一步，Autopilots 可以按 cron 跑 standup、审计和报告，不需要人提醒。这种「粗糙三句话 → 一个 PR」的闭环，是 Multica 最核心的使用姿势。

（二）Projects 与 Chat

Projects 把工作和 Agent 需要的仓库、文档作为上下文绑在一起；Chat 让你直接问工作空间一个问题，或在不建任何单据的情况下就地开工。它既承接结构化的 issue 流，也承接临时的对话式任务。Projects 的关键不在「建文件夹」，而在把上下文固化——Agent 领到任务时，相关仓库和文档已经挂在项目上，不用你每次口头复述「看那个 repo 的某份文档」，从而把「第四次重述上下文」彻底省掉。

四、始终在环：执行日志、成本与人工门禁

README 把「Stay in the loop」单列一节，强调可观测与可控：

• Execution log：回放每一次工具调用、命令和报错，都带时间戳；
• Token usage：看到每次运行花了多少，按 Agent 和按 issue 分别统计；
• Review gates：活儿落在 review 里，不落在 main 上，由你决定什么能上线；
• Inbox：Agent 需要你拍板时才 ping 你，而不是每步都打扰；
• Retries & timeouts：失败的运行自己重试，或停下来告诉你原因。

这一节的潜台词是「可控」。Execution log 让每一次运行都可回放、可审计；Token usage 把成本摊到每个 Agent 和每个 issue，避免「跑了一晚上不知道花了多少」；Review gates 则把「能不能上线」这个决定权始终留在人手里——Agent 再能干，也只是把活交到 review 栏，而不是自己合进主干。对团队而言，这比「全自动」更关键。

五、架构：前端 / Go 后端 / 本地 Agent 守护进程

README 用一张架构图讲清了数据流向：Web / Desktop / iOS 在前端，向下连 Go 后端（Chi + WebSocket），后端落到 PostgreSQL 17；关键的一层是 Agent daemon——它跑在你的机器上、紧挨你的代码，再通过 WebSocket 接收任务，就地拉起你装好的 26 种 Agent CLI 之一。各层技术栈是：Web 用 Next.js 16（App Router），桌面端 Electron 共享 Web UI 包，移动端 Expo / React Native，后端 Go（Chi、sqlc、gorilla/websocket），数据库 PostgreSQL 17（pgcrypto + pg_trgm）。这条链路决定了「代码从不离开你的机器」是架构层面的承诺，而非口头保证。对很多企业来说，这不只是安全偏好，更是合规硬约束——生产仓库本就不允许出内网，本地守护进程恰好让「Agent 能跑活、代码不出域」这两条同时成立。

六、私有化与安全模型

Multica 强调「Your machines, your Git host, your rules」。自托管用 Docker Compose 或 Helm 跑在你自己的基础设施上；Git 主机支持 GitHub、GitLab、Gitea、Forgejo（含自托管）。权限分为 owner、admin、member 三级，并能精确控制每个成员能运行哪些 Agent；Security model 文档专门说明一个 Agent 能触达什么、不能触达什么。通知渠道还接了 Slack、Lark、DingTalk、WeCom、Telegram，其中后三者由社区维护。权限分级不只是标签——它决定谁能在哪台 runtime 上启动哪些 Agent，配合 Security model，企业可以把「能碰生产仓库的 Agent」严格限制在少数审批人手里，这对多人共用一个 Multica 空间的团队尤其关键。

七、五分钟跑起第一个 Agent

README 的「Your first agent in five minutes」给了四步：

1. 登录：浏览器打开 multica.ai，或打开 Multica Desktop；
2. 连一台电脑：Desktop 自动把所在机器注册为 runtime 并探测已装的 Agent CLI；网页端则点 Runtimes → Add a computer，把给出的两条命令粘到目标机器的终端；
3. 建一个 Agent：选 runtime、选 provider、起个名字，或让 Build with AI 从描述生成配置；
4. 派点活：建个 issue 把 Agent 设为 assignee，它就会认领、运行、评论，做完把 issue 挪到 review。

唯一前置条件：运行 Agent 的那台机器至少装好并登录一个受支持的 Agent CLI。Multica 驱动它们，但不打包它们。

八、开源协议与「Multica License」

仓库采用的是 Multica License：完整的 Apache License 2.0 文本，外加针对托管服务、商业内嵌与品牌使用的附加条件。你可以自托管、修改、在其之上构建，具体条款写在 LICENSE 里，署名声明在 NOTICE 里。它既不是纯 Apache-2.0，也不是强制开源的 copyleft，而是一种「开源但品牌与托管受限」的自定义许可，商用前建议细读附加条款。如果你的产品要把 Multica 作为托管服务对外提供，或做商业内嵌，通常就触发了附加条件——自托管自用、内部协作一般不受限，但边界以 LICENSE 原文为准。

九、为什么叫 Multica

README 专门解释命名：Multiplexed Information and Computing Agent——致敬 Multics，那套在 1960 年代用时间片共享让多人像独占机器一样使用一台主机的操作系统。软件团队此后一直单线程：一个工程师、一个任务、一次上下文切换。Multica 认为 Agent 让「时间共享」重新有意义，只是这次复用系统的是人和机器两类用户。一支小团队，不该显得小。

从工程节奏看，README 在 Development 一节提到贡献者前置是 Node.js 22、pnpm 10.28.2、Go 1.26.6 与 Docker，本地用一条 make dev 就能自动探测环境、装依赖、建库、跑迁移并起全部服务；官方「most weekdays」都会发版，main 分支移动很快，拉取要勤。iOS 客户端（apps/mobile/）目前只能从源码自签构建到自己的 iPhone，尚未上 App Store——想用移动端的读者要有心理准备。

十、总结

Multica 解决的是一个被多数人忽略的瓶颈：不是「模型够不够强」，而是「一堆强模型怎么像团队一样被管」。它用一块看板、一个本地守护进程、一套 review 门禁，把异构 Agent 的意图、运行、决策与代码 diff 串到同一条 issue 线索上，既保住「代码不出本机」的安全底线，又让你从「带娃」回到「拍板」。对已经在同时折腾多个编程 Agent 的团队，它值得作为编排层一试。

在撰写本文的过程中，我主要参考了以下来源：GitHub 仓库 multica-ai/multica 的 README、官方文档（multica.ai/docs）、架构说明与 VISION.md。文中数据（Star 数、支持的 Agent CLI 数量、技术栈等）以仓库公开信息为准，可能随版本更新而变化。