Multica 把 Claude Code、Codex、Cursor Agent 等本地编码 CLI 包装成可被 Issue 指派的「数字同事」，由 Go + Chi + WebSocket 后端调度任务、Next.js 16 前端展示进度，配合本地 daemon 在用户机器上隔离执行——目标是让 2-10 人的小团队像分配人类工单一样把开发任务交给 AI 代理，并把跑通过的解法沉淀成可复用的 skill。
来源：README + docs/product-overview.md + CLAUDE.md 查看 GitHub 仓库 →Multica 在 21.9k stars 的体量上是少见的「不做 Agent 模型本身、专做 Agent 协作平台」的开源项目。它的关键差异是 polymorphic actor 模型——issue / comment / notification 里的「谁干的」字段都是 actor_type(member|agent) + actor_id，让 AI 代理在数据层和人类成员完全平权，而不是当成外挂工具。再加上 distributed execution（服务端只调度、LLM 调用全部下放到用户本地 daemon），这套架构刚好踩中两个 2026 年的真问题：团队怎么管多个并行跑的编码 agent，以及怎么避免把 API key 和私有代码全部送进集中式 SaaS。21.9k stars / 2.7k forks / 88 watchers 的分布也说明它已经从「玩具阶段」进入「被认真试用」阶段，对想做 AI 团队协作、私有化部署、自部署 agent 平台的开发者来说值得跟一跟。
来源：GitHub 元数据 + product-overview.mdissue.assignee、comment.author、notification.recipient 这些字段统一拆成 actor_type(member|agent) + actor_id，agent 和人在协作流程里完全等价：可以建 issue、可以被 @、可以收通知、可以发评论。前端用紫色背景 + 机器人图标做视觉区分。这套设计让「把任务派给 agent」不需要为 agent 单独造一套 API。
来源：CLAUDE.md（Multi-tenancy & Security 段）+ product-overview.md服务端只负责 issue 状态、任务队列和 WebSocket 推送，真正调用 Claude Code / Codex / Cursor Agent / Gemini / OpenCode 这类编码 CLI 的进程跑在用户本机的 multica daemon 里。daemon 自动探测 PATH 上已安装的 CLI、轮询 server 拉任务、在隔离工作目录里执行。结果是模型 API key、代码库、shell 环境全部留在本地，server 端不接触 LLM 流量。
来源：product-overview.md + README 安装与 setup 流程Skill 是 Markdown 文件，放在每个 provider 自己识别的位置（如 Claude Code 的 skills 目录）。agent 执行任务时会被这些 Markdown 提示约束，相当于把「上次怎么改这个模块」沉淀为可复用经验。和 Cursor rules / Claude skills 不同的是，Multica 把 skill 提到团队共享层，不是单机配置。
来源：product-overview.mdv0.2.16 重写了 autopilot modal 和调度 schema，可以按 cron 周期或 webhook 让 agent 自动跑某类 issue（如「每天扫一遍 PR 评审」「webhook 触发回归测试修复」）。这是把 agent 从「人指派一次」升级为「常驻 worker」的关键能力。
来源：Releases v0.2.16 + product-overview.mdissue 是结构化、有状态、和代码改动绑定的正式工单；chat 是不挂 issue 号的轻量探索式对话，sidebar 入口 + 主区单独页面（v0.2.16 引入）。同一个 agent 在两条流上的会话历史用 session resumption 串起来，避免反复 copy 上下文。
来源：Releases v0.2.16 + product-overview.md管理面把「本地跑的 daemon」和「自部署 server 上的 cloud runtime」放到同一个面板，可以看哪台机器在跑哪个 agent、心跳是否正常、stderr 末尾几行（v0.2.17 的改进）。对多人团队意味着可以共享一台带 GPU/大磁盘的执行机，又能保留个人 daemon 的离线兜底。
来源：Releases v0.2.17 + README前端强制走 shadcn 组件 + 语义 token（bg-background、text-muted-foreground），docs/design.md 明确禁止硬编码 Tailwind 色值、禁止 font-bold、字号只用 text-base/sm/xs。结果是 web、desktop（Electron）、docs 三端视觉完全一致，对自部署用户做二次定制门槛低。
来源：docs/design.md + CLAUDE.md（UI/UX Standards）所有 SQL 都按 workspace_id 过滤，请求头带 X-Workspace-ID 路由，membership 校验门控访问。worktree 开发模式下多个 checkout 共用一个 PostgreSQL 容器，靠数据库级隔离切环境。对小团队即可起多组项目而不用起多套实例。
来源：CLAUDE.md（Multi-tenancy & Security、Worktree Support）整体是「Go server + Next.js web + Electron desktop + 本地 daemon」四进程模型。后端用 Chi 路由、sqlc 生成类型安全 SQL、gorilla/websocket 推送实时事件，PostgreSQL 17 + pgvector 撑数据层（28 张表，含 agent / agent_task_queue / autopilot / skill / runtime 这些 agent 专属实体）。前端是 pnpm + Turborepo monorepo：apps/web（Next.js 16 App Router）、apps/desktop（electron-vite）、packages/core（无 React DOM、纯业务逻辑和 Zustand store）、packages/ui（shadcn 原子组件）、packages/views（共享页面级组件）。共享包不预编译，直接 export .ts/.tsx 让消费方 bundler 自行编译，HMR 和跳转零配置。状态管理纪律严格：TanStack Query 拥有 server state、所有 API 数据都在它里面，WebSocket 事件只触发 query invalidation 而不直接写 store；Zustand 只放 UI 选中、过滤、草稿、modal 可见性这种纯客户端态，且禁止把 server 数据拷进 store 制造漂移；React Context 只用于 platform plumbing（WorkspaceIdProvider / NavigationAdapter），不当全局状态总线。可扩展性的核心是 packages/core/platform 这层 CoreProvider，把 API client、auth/workspace store、WebSocket、QueryClient 一次性装好，apps/web 和 apps/desktop 各自包一层并提供自己的 NavigationAdapter，所以新增端（比如 VSCode 插件、移动端）理论上只要写一份 NavigationAdapter 而不用动业务逻辑。设计上的克制：项目刻意没造抽象 ORM、没做后向兼容层（CLAUDE.md 明确写「pre-launch 直接删旧路径不做 dual-write」），属于「速度优先于可回滚」的取舍——对一个还在 0.2.x 的产品合理，但意味着想 fork 之后维护私有改动的人会比较痛。
来源：CLAUDE.md + docs/product-overview.md + 仓库目录结构中心为项目本体，内环 = 核心功能模块，外环 = 关键技术依赖；按 deep.json 中的 core_features 与 tech_stack.key_deps 自动生成
PostgreSQL 17 + pgvector（向量检索）TanStack Query（server state 单一数据源）Zustand（client-only state）node-postgres pg ^8.20Playwright（e2e）Vitest（单元 / 组件测试）GoReleaser（多平台 CLI 二进制发布）1) 2-10 人的小团队想把代码审查、模板化 bug 修复、依赖升级这类标准化任务批量交给 Claude Code / Codex 跑，但又不想把代码送上集中式 SaaS——直接自部署 server + 各自本地 daemon。2) 多人共用一台带 GPU 或大磁盘的开发机，希望统一面板看每个 agent 跑到哪里、卡在哪一步、stderr 是什么——比手搓 tmux + 日志聚合务实。3) 需要把团队总结过的「上次这个模块怎么改」沉淀成可复用 skill 让每个新来的 agent 自动遵守，避免每次重写 prompt。4) 国内开发者想做私有化部署的 AI 协作平台原型，Multica 的 polymorphic actor 模型和分布式执行架构可以直接借鉴，省掉从零设计 schema 的成本。
来源：综合 product-overview.md + 实际架构推断最新版本 v0.2.18（2026-04-24 ~ 2026-04-27 区间）：核心是 P0 级改造「sharded Redis realtime relay」，把实时事件 relay 改成分片 + 隔离连接池，配合 v0.2.17 修复的 daemon 心跳探测（拆分 probe / claim 两步）和 assignee 子串碰撞，集中收敛多 agent 并发下的实时层稳定性。功能侧：issue list / board 视图新增 label chip 渲染（服务端批量取标签）、新增 labs 设置 tab、agent CLI 写文件时保留换行、agent 失败时把 stderr 末尾几行回显到错误信息。再前一版 v0.2.16（2026-04-24）重写了 autopilot modal 和调度 schema，并上线了 Chat V2（sidebar + 主区单独页）以及 agent profile card 悬浮预览、issue / 剪贴板的右键菜单，文档站重构为扁平双语树。整体节奏是「实时层稳定性 + 协作交互打磨」并行推进。
来源：GitHub Releases v0.2.16 / v0.2.17 / v0.2.18Multica 是 2026 年值得认真看的一个开源 agent 协作平台：polymorphic actor 数据模型 + 本地 daemon 分布式执行 + skill 沉淀这三件事独立看都不新，但拼在一起、用 Go + Next.js 16 + Electron 三端共享 monorepo 的工程纪律落地，目前在 21.9k stars 的同类项目里属于设计清晰度第一梯队。架构上有一处明显克制：刻意不做向后兼容、不造抽象 ORM、状态管理边界用硬规则约束，换来的是 0.2.x 阶段的迭代速度，但代价是自部署用户升级和 fork 维护成本会偏高。建议：① 2-10 人的开发团队、特别是有合规 / 国内访问 / 私有化部署需求、且日常已经在用 Claude Code 或 Cursor Agent 的，可以把它当成「issue + agent runtime」原型直接试自部署；② 想做自己的 AI 协作平台、又不想从零设计 schema 的开发者，可以重点读 docs/product-overview.md 和 CLAUDE.md，借 polymorphic actor 和分布式执行的思路；③ 暂时不建议接生产关键路径或上百人团队——0.2.x 还在收敛实时层，breaking change 政策也不友好，等 0.3 / 1.0 稳定后再评估更稳妥。
来源：综合分析