开篇引导段（1-2句，介绍项目背景，不可跳过，不可出现 # 标题）：
今天在 GitHub Trending 上看到一个有意思的项目：Multica，它想把编码 Agent 从「需要人反复粘贴 prompt 的工具」升级为「能自动认领任务、汇报进度、沉淀技能的同事」。
一、项目概述
Multica 的定位是「开源的 managed agents 平台」（The open-source managed agents platform）。它的核心主张很直白：你的下一个 10 个「招聘名额」，可能不再是人类。
传统的 AI 编程工作流里，人往往要反复复制粘贴 prompt、手动盯着每一次运行结果，Agent 与团队的协作是割裂的。Multica 的做法是：把 Agent 当作一等公民（first-class teammate）接入到项目协作中——它们拥有自己的头像和资料、出现在任务看板上、会主动评论、创建 Issue、上报阻塞，并自主推进任务生命周期。
目前 Multica 官方宣称兼容一众主流编码 Agent，覆盖面相当广：
- Claude Code、Codex、CodeBuddy、GitHub Copilot CLI
- OpenCode、OpenClaw、Hermes、Pi、Cursor Agent
- Kimi、Kiro CLI、Antigravity、Qoder CLI、Trae CLI
这让它成为一个**厂商中立（vendor-neutral）、可自托管（self-hosted）**的中间层，而不是绑定某一家大模型或某一款 IDE 的平台。
核心特性可以归纳为六点：
- Agents as Teammates：像分配任务给同事一样把 Issue 指派给 Agent，它们有独立 Profile、会出现在看板、会主动评论和上报 blocker。
- Squads（小队）：把一组 Agent（也含人类）归入一个 leader Agent 之下，把工作指派给「小队」，由 leader 决定谁接手，路由随团队扩张而保持稳定。
- Autonomous Execution（自主执行）：完整的任务生命周期管理（enqueue → claim → start → complete/fail），并通过 WebSocket 实时流式推送进度。
- Autopilots（自动驾驶）：调度周期性工作——Cron 触发、Webhook 或手动运行，每个 autopilot 自动创建 Issue 并路由给 Agent，让每日站会、周报、定期审计自行运转。
- Reusable Skills（可复用技能）：每一个解决方案都会沉淀为团队可复用的 Skill，部署、迁移、Code Review 等能力随时间复利式累积。
- Unified Runtimes / Multi-Workspace：一个仪表盘统管本地 daemon 与云端运行时，自动探测可用 CLI；按 workspace 做隔离，各自拥有独立的 Agent、Issue 与配置。
二、技术原理
2.1 架构总览
Multica 采用清晰的前后端分离 + 本地守护进程三层架构：
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Next.js │────>│ Go Backend │────>│ PostgreSQL │
│ Frontend │<────│ (Chi + WS) │<────│ (pgvector) │
└──────────────┘ └──────┬───────┘ └──────────────────┘
│
┌──────┴───────┐
│ Agent Daemon │ runs on your machine
└──────────────┘ (Claude Code, Codex, OpenClaw ...)
各层技术栈：
| 层 | 选型 |
|---|---|
| 前端 | Next.js 16（App Router） |
| 后端 | Go（Chi router、sqlc、gorilla/websocket） |
| 数据库 | PostgreSQL 17 + pgvector |
| Agent Runtime | 本地 daemon，执行 Claude Code / Codex / OpenClaw 等 CLI |
值得注意的两个选型点：
- 后端用 Go + Chi：轻量、并发友好，配合
gorilla/websocket做实时进度推送，契合「多 Agent 并发、实时流式」的场景。 - PostgreSQL + pgvector：pgvector 的存在暗示 Multica 在 skill 检索 / 语义匹配上有向量化需求，例如把沉淀下来的 Skill 做 embedding 以便按需召回复用——这正是「技能复利」的工程支点。
2.2 任务生命周期与运行时探测
Agent 真正干活发生在本地 daemon 上。daemon 启动后会自动探测 PATH 上的 Agent CLI：
claude, codex, codebuddy, copilot, opencode, openclaw,
hermes, pi, cursor-agent, kimi, kiro-cli, agy,
qodercli, qoderclicn, traecli
这种「自动探测」设计很关键：你不需要手动告诉 Multica 装了哪些 Agent，它自己就能识别可路由的运行时（Runtime）。每个 Runtime 会上报自己支持哪些 CLI，Multica 据此决定把任务派到哪里执行。这也是「Unified Runtimes」能用一个仪表盘统管本地 + 云端的底层机制。
任务侧，README 披露了完整的状态机：enqueue → claim → start → complete/fail。结合 WebSocket 实时流式，意味着前端看板能像看真人同事一样看到 Agent 的每一步推进。
2.3 配置与可自托管性
Multica 同时提供云端（Multica Cloud）与自托管两种形态。自托管走官方镜像（GHCR），依赖 Docker Compose 插件（注意：明确不支持 legacy docker-compose v1）。Makefile 里有一段很贴心的设计——selfhost 目标在 .env 缺失时自动生成随机的 JWT_SECRET、POSTGRES_PASSWORD、MULTICA_VCS_SECRET_KEY：
JWT=$$(openssl rand -hex 32); \
PGPASS=$$(openssl rand -hex 24); \
VCSKEY=$$(openssl rand -base64 32); \
并对 macOS / Linux 的 sed -i 差异做了分平台处理。此外，它对 forbidden 的远程 DATABASE_URL 做了安全拦截（db-reset 在远程库上会直接 refuse），避免误删生产数据。
三、安装与快速开始
3.1 环境要求
- 自托管需要 Docker，且需 Docker Compose 插件（非 v1）。
- 本地开发依赖：Node.js v20+、pnpm v10.28+、Go v1.26+、Docker。
3.2 安装 CLI
macOS / Linux 推荐 Homebrew：
brew install multica-ai/tap/multica
brew upgrade multica-ai/tap/multica # 更新
或使用官方安装脚本（无 Homebrew 时）：
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash
Windows（PowerShell）：
irm https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.ps1 | iex
自托管版加上 --with-server 即可拉起完整服务端：
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host
3.3 一键连接并启动
无论哪种安装方式，都可以用一条命令完成「配置 + 登录 + 启动 daemon」：
multica setup # 连接 Multica Cloud，登录，启动 daemon
四、使用方法与实战
4.1 四步走通第一个任务
- 启动 daemon：
multica setup后，守护进程在后台运行，并自动探测本机 Agent CLI。 - 验证运行时：打开 Multica Web App → Settings → Runtimes，应能看到你的机器以「Runtime」身份列出。
- 创建 Agent：Settings → Agents → New Agent，选择刚连上的 runtime 和 provider（如 Claude Code / OpenClaw），给 Agent 起个名字——它会以此名出现在看板、评论与指派中。
- 指派首个任务：从看板创建 Issue（或
multica issue create），指派给新 Agent；Agent 会自动认领、在 runtime 上执行并回报进度。
4.2 CLI 常用命令
| 命令 | 说明 |
|---|---|
multica login | 认证（打开浏览器） |
multica daemon start | 启动本地 Agent 运行时 |
multica daemon status | 查看 daemon 状态 |
multica setup | 一键配置云端（配置 + 登录 + 启动 daemon） |
multica workspace list | 列出 workspace（当前项带 *） |
multica workspace switch <id|slug> | 切换默认 workspace |
multica issue list | 列出工作区 Issue |
multica issue create | 新建 Issue |
multica update | 升级到最新版 |
4.3 进阶：Squads 与 Autopilots
当团队扩张，直接 @alice-or-bob-or-carol 式指派会变脆弱。Multica 引入 Squads：建立一个由 leader Agent 带领的小队，把工作指派给 @FrontendTeam，由 leader 决定具体谁接手，路由逻辑保持稳定。
Autopilots 则把「周期性重复劳动」自动化：用 Cron 或 Webhook 触发，每次自动创建 Issue 并路由给 Agent——每日站会纪要、周报、定期安全审计都能「自己跑起来」。
五、常见问题与解决方案
Q1：本地 daemon 启动后，Web App 的 Runtimes 里看不到我的机器？
先确认 daemon 已在运行：multica daemon status。若未运行，multica daemon start 重启；同时确保你的 Agent CLI（如 claude、codex、openclaw）已在 PATH 中，daemon 依赖自动探测来上报可用 runtime。
Q2：自托管 make selfhost 报错 unknown shorthand flag / 解析失败？
这是误用了 legacy docker-compose v1。Multica 的 compose 文件使用 compose-spec 语法（顶层 name:），需要 Docker Compose 插件：docker compose version 验证，并按官方文档安装插件版。
Q3：官方 GHCR 镜像还没发布对应 tag？
make selfhost 在 pull 失败时会给出可执行提示：改用 make selfhost-build 从当前 checkout 本地构建。
Q4：本地开发 make dev 卡在数据库 / 迁移？
make dev 会自动探测环境（主仓库或 worktree）、生成 env、安装依赖、起数据库、跑迁移并启动全部服务；若失败，先单独跑 make check 跑完整本地校验管线（typecheck / TS 测试 / Go 测试 / Playwright E2E）定位问题。
Q5：用户名里带 db-reset 误删远程库？
Multica 有意拦截：当 DATABASE_URL 指向远程主机时，db-reset 会直接拒绝执行，仅允许对 localhost 的数据库做 drop + recreate，避免误删生产数据。
六、总结
Multica 的巧思在于「命名隐喻」：Multiplexed Information and Computing Agent——向 1960 年代引入「分时复用（time-sharing）」的 Multics 致敬。Multics 让多用户共享一台机器如各拥一台；Unix 是其单线程化的精简；而 Multica 认为，AI Agent 的到来让「分时复用」再次成立——只是这次被多路复用的「用户」既是人类，也是自主 Agent。
从工程视角看，它把「Agent 调度」这件事做成了基础设施：厂商中立的运行时探测、完整的任务状态机 + WebSocket 实时流、可复用的 Skill 沉淀（配合 pgvector），以及 Squads / Autopilots 这类面向团队协作的抽象。对于想让「两个工程师 + 一支 Agent 舰队」跑出二十人产出的小团队，Multica 值得一试。
许可证说明：Multica 采用「Multica License」——完整 Apache 2.0 文本 + 附加条件。作为第三方托管服务或嵌入商业分发产品需商业授权；非界面用途（仅运行
server/ daemon / CLI）可豁免品牌条件，但须保留源码与 NOTICE 署名并声明基于 Multica 构建。