1960 年代，MIT 的 Project MAC 拉上通用电气和贝尔实验室，造了一台野心极大的机器，Multics。它想干一件当时看来很疯的事，让几十个人同时用一台电脑，每个人还以为自己独占整机。这就是分时。后来贝尔实验室退出，Ken Thompson 在一台闲置的 PDP-7 上把这套思想砍到只剩骨架，取名 Unix。
60 年后，有个项目把这段历史又翻了出来。Multica，Multiplexed Information and Computing Agent 的缩写，VISION 文档里大方承认就是在致敬 Multics。只不过这次被分时的不是一台电脑，是一个团队，共享它的也不只是人，还有一堆 AI 编码 Agent。
一句话定位，它是个可自托管的任务看板，你把 issue 派给 Agent，就像派给同事。Agent 自己领任务、在你的机器上跑、边干边留言、干完把分支递回来等你审。
这个 2026 年 1 月才建仓的项目，8 个月攒了 50178 个 Star，6491 个 Fork，最近一次发版是两天前的 v0.4.44。今天拆一下它凭什么。
痛的不是没有 Agent，是 Agent 太多
你想想看现在的日常。Claude Code 开一个终端 tab，Codex 开一个，Cursor 再来一个。每个 Agent 活在自己的会话里，会话一关上下文全蒸发，下午三点你还在给第三个 Agent 重新解释早上八点讲过的背景。README 对这个场景的描述挺扎心，你加的 Agent 越多，花在看娃上的时间越长。
Multica 的解法是把 Linear 式的看板做成控制面。issue 板、指派人、评论区、状态流转，全是给人和 Agent 混编团队设计的。指派下拉框里 Agent 和人并排出现，Agent 领了任务会自己在 issue 里评论进度，卡住了会喊你，干完把 issue 拖进 review 列。
注意一个关键取舍，它不造模型也不内置 Agent。你想用 Claude Code 就得自己装好 claude CLI，想用 Codex 就得装 codex。Multica 只负责驱动它们，README 的说法是，切换供应商是下拉框的事，不是迁移工程。
这个取舍决定了它的整个架构。
26 个 CLI，一个接口
后端 Go 写的，Chi 路由加 WebSocket，PostgreSQL 17 存数据，前端 Next.js 16，桌面端 Electron 直接复用 Web 的包。技术栈本身不稀奇，稀奇的是它怎么把 26 个五花八门的 Agent CLI 拧成一个统一抽象。
核心在 server/pkg/agent/agent.go 的 Backend 接口。每个 Agent 一个适配文件，claude.go、codex.go、cursor.go、kimi.go，各自把自家 CLI 的输出流翻译成统一的 Message 事件，text、tool-use、tool-result、thinking。上层看到的永远是一个 Session，一个 Messages channel 加一个 Result channel。
但真正聪明的不是「一个 CLI 一个适配器」，是协议族这层抽象。SupportedTypes 里注册的并不是 26 个平级后端，而是 25 个协议族。qoder 和 qoderclicn 国际版国内版共用同一个 ACP 后端，oh-my-pi 走的是 pi 的 JSON 协议。server/pkg/agent/builtin_runtimes.go 里管这个叫 BuiltinRuntime 描述符，注释写得很直白，加一个已有运行时的兼容 fork，就是加一条描述符的事，不是一次跨栈改动。
这个白名单还焊死在数据库层。runtime_profile 表的 protocol_family 列带 CHECK 约束，migration 120 建的，之后每加一个协议族就扩一次，一路到 migration 441 加 codearts。适配器、数据库约束、前端展示三处永远锁步。
顺带挖到一个彩蛋。代码里其实已经有第 26 个后端 zeroclaw，migration 403 加进去的，但 README 的运行时表格里没有它，grep 一遍零结果。也就是说那句「26 agent CLIs」对着代码数是对的，对着文档数就少一个。无伤大雅，但能看出迭代有多快，代码跑在文档前面。
还有个出身细节挺有意思。agent.go 的包注释自己招了，这套 Backend 模式「mirrors the happy-cli AgentBackend pattern, translated to idiomatic Go」。happy 是那个给 Claude Code 做手机遥控的项目。开源世界的染色体就是这样流动的。
任务即 worktree
第二个值得拆的是交付模型，在 server/internal/daemon/execenv/local_worktree.go。
Agent 在你机器上干活，最怕的就是它把你正在编辑的目录搞乱。Multica 给每个任务发一个独立的 git worktree，建在 daemon 自己的环境目录里。文件开头列了三条保证，写得相当漂亮。
一，Agent 看到的就是你看到的。直接 git worktree add 会检出 HEAD，你未提交的改动就全被藏起来了，所以他们把你工作目录的快照重放进 worktree，连未跟踪文件都带上。
二，你的目录一个字节都不写。所有中间产物，包括 per-task 的上下文文件，全落在一次性的 worktree 里，最后留在你仓库里的只有那个分支，外加一个隐藏 ref 记录这分支是谁的、装了什么。
三，什么都不许悄悄扔。Agent 留下的未提交内容，会在 worktree 销毁前替它提交进分支。
翻译成人话，交付物不是截图不是聊天记录，是一条你直接 git branch 就能查到的真分支。
环境准备本身也上了强度。execenv 的 Prepare 和 Reuse 不在 daemon 进程里跑，而是 fork 一个 multica 自己的子进程，靠 __multica_execenv_prepare 这个私有参数进入 helper 模式。原因写在注释里，文件系统调用要是卡死，子进程可以直接杀掉，进程内的 goroutine 杀不干净，任务重试之后它可能还在写。
服务端和 daemon 之间走 WebSocket，server/internal/daemonws/hub.go 里每个连接持有 RuntimeLease，连接建立时一次性批量授权，之后心跳只更新存活状态。整套东西透着一股被真实故障教育过的味道。
一套超时分类学，全是学费
说真的，读 agent.go 的 ExecOptions 是这次拆解里我最想贴给你的部分。一个执行选项结构体，塞了六七种超时。
SemanticInactivityTimeout 管「跑着的 turn 是不是哑了」，FirstTurnNoProgressTimeout 管「第一 turn 到底有没有开始产出」，HandshakeTimeout 管启动 RPC，TurnInterruptTimeout 管取消之后 app-server 多久必须回应，ThreadHandshakeTimeout 又给更重的 thread/start 单独放宽预算。注释里专门强调这几个参数回答的是不同问题，所以独立移动。每个字段后面都挂着 issue 编号，#3262、MUL-4424，不是拍脑袋写的。
会话恢复的语义细到可怕。Result 里 ResumeRejected 和 ResumeRejectedTransient 是两个不同的布尔，前者表示会话永久废了只能重开，后者表示暂时续不上但会话还健康。哪些后端根本检测不了拒绝，单独有一张 resumeRejectionUndetectable 名单，注释写着新后端默认落进「不会报告」那一档，fail closed。
连记账都抠到了位。TokenUsage 的成本字段不用浮点，用 int64 存 1e-10 美元单位的 tick。注释解释了为什么，xAI 的计费在 prompt 超过 200K token 后翻倍，一次 turn 聚合多个模型调用，token 数乘费率根本还原不了单个请求命中哪档价格，只有供应商自己报的数是准的。
这种细节骗不了人，是拿生产事故喂出来的。
还有个更硬的实锤。贡献者榜第五名 multica-eve，442 次提交，干的是「给高频查询路径加索引」「把 disabled capabilities 归类为不可重试」这类正经工程活。翻它的 commit message，每一段 squash 后面都跟着一行 Co-authored-by: multica-agent。他们真的在用 Multica 开发 Multica，Agent 的代码直接进 main。
仓库根目录的 AGENTS.md 也值得一看，给 agent 贡献者写满了包边界纪律，packages/core 不许碰 localStorage，packages/views 不许 import next/*，改了 SQL 记得 make sqlc。管 agent 跟管实习生一个管法。
免费开给你看，开给别人要谈
坦白讲，这一节是我建议你动手前最该看的。
README 的口号是 open-source and self-hostable，但 GitHub 页面上 license 一栏显示的是 Other。翻 LICENSE 文件，它确实是完整的 Apache 2.0 文本，前面加了一段 Part I 附加条款。
条款 1a，没有商业授权，不能拿这份源码对第三方提供托管服务。注意它连免费都管，一个对组织外用户开放的公开实例，哪怕不收费不放广告，也要商业授权。组织内部自用不受限，fork 后公开源码也不算托管。
条款 1b 是品牌锁。apps/web、apps/desktop、apps/mobile、packages/views、packages/ui 这些目录衍生的界面，不许动 LOGO 不许改产品名，除非拿到书面豁免。纯跑后端、daemon、CLI 不受这条管，但落到条款 1c，你的用户文档里得声明产品基于 Multica 并附仓库链接。
商业授权和品牌豁免是两本证，拿了一本不送另一本。
讲道理，内部用和二次开发都没障碍，条款写得明明白白。但严格说这不是 OSI 意义上的开源，是 open-core 味道很浓的源可得。你要拿它做对外平台，先发邮件谈授权。
它站在哪，和谁打
| 维度 | Multica | Copilot coding agent | Devin / Jules | happy |
|---|---|---|---|---|
| 定位 | 人加 Agent 混编看板 | issue 派给 Copilot | 单兵云端干活 | Claude Code 手机遥控 |
| 执行位置 | 你的机器 | GitHub 云 | 厂商云 | 你的机器 |
| 供应商 | 26 个 CLI 随便换 | 仅 Copilot | 仅自家 | 基本仅 Claude |
| 自托管 | Docker / Helm | 不支持 | 不支持 | 部分 |
| 形态 | 看板加运行时 | issue 原生 | 独立产品 | 聊天壳 |
GitHub 的 Copilot coding agent 跟 Multica 最像的一点是「指派 issue」，但它锁死在 GitHub 生态和自家模型。Devin 和 Jules 是云端单兵，开箱即用是真的，你的代码得出门也是真的。happy 解决「人不在电脑前」，Multica 解决「团队怎么协作」。同赛道的正面竞争者其实还没几个，这个品类今年才算成型。
上车前想清楚的三件事
898 个 open issue 不是摆设。#4072 是 Agent 一直排队、task claim 超时，#3262 是 Codex app-server 卡在 running 没输出，调度层和适配层的毛刺，日常用到的概率不低。26 个后端乘上各家 CLI 的怪癖，测试矩阵是天文数字。
版本还停在 0.4.x。半个月发了 8 个版，README 自己都提醒 main 跑得快要勤 pull。追新很爽，追着追着 schema 变了也是真的。
还有那个前提，跑 Agent 的机器上得装好至少一个受支持的 CLI 并完成登录。Multica 驱动它们，不附赠。云版注册即用，但 Agent 跑在他们那儿，想要「代码不出门」的完整叙事就得自托管，代价是伺候 Docker 和 Postgres。
塔台模式
我一直觉得 Multica 最值得抄的不是某个功能，是一个位置选择。
Agent 生态现在最不缺的就是执行器。Claude Code、Codex、Cursor 每家都在拼命变强，下个月可能又冒出仨，你数数它适配表里那些名字，qodercli、qoderclicn、traecli，好些 CLI 你可能都没听说过。去造第 27 个 CLI 是死路。Multica 选了当塔台，自己永远不起飞，只管把 26 架飞机的起降、载荷、油耗、事故记录统一管起来，把「谁在干什么」变成团队共享的结构化事实。
执行层越繁荣，控制层的座位越值钱。这个判断在任何执行器正在爆炸的领域都能复用，编辑器如此，模型网关如此，Agent 更是如此。
至于 Multics 的回环，当年分时是为了让贵的机器不闲着，现在分时是为了让贵的人不被 Agent 拖着空转。VISION 里那句「两个工程师加一队 Agent，能干出二十个人的活」，是个值得盯半年的赌注。
想自己翻代码的，仓库链接在开头，本地跑一遍 make dev，比 README 里那十张截图都有说服力。
