Multica 调研：开源多 Agent 协作平台的部署形态与远端 Agent 接入

实测抓取时间：2026-09-21 20:30–21:00（GMT+8）。本文星数 / fork / issue / 推送时间为该时刻 GitHub API 实测值（未认证 requests，api.github.com/repos/multica-ai/multica）。
本文遵守「不替用户下结论」原则：事实、官方原文、以及基于原文的推导分区呈现；不写”建议你装 / 不推荐”这类判断。
所有关键结论均给出原文出处（文件路径或文档页）；官方文档内部口径不一致处明确标注。

一句话定位

Multica 是一个把「人 + AI 编码 agent」放进同一个看板里协作的开源自托管平台 —— 你像给同事派活一样把 issue 指派给 agent，agent 在你自己控制的机器上领活、执行、回报、交付。

关键认知（破除一个常见误解）：Multica 本身不执行任何东西，也不自带模型。 它是一层「记录与调度」，真实执行发生在你机器上的 daemon 里 —— daemon 拉起你本机已安装并登录的 agent CLI 子进程（官方原文：“Multica drives them; it doesn’t ship them.”）。所以它的部署本质上是两个可分离的部分：服务端（Web + API + PostgreSQL）与执行电脑（CLI + daemon）。这两者可以同机，也可以跨机 —— 跨机的那条链路，正是本文要回答的核心问题。

一、项目背景（2026-09-21 实测）

项 实测值
仓库 multica-ai/multica
官方描述 Make humans and AI agents work as one team — open-source and self-hostable.
官网 https://multica.ai
Star 50,986
Fork 6,601
Watch / Subscribers 182
Open issues 1,620
创建时间 2026-01-13T17:59:46Z（约 8 个月前）
最后推送 2026-09-21T11:36:16Z（调研当日仍在推送）
主语言 Go
仓库体积 151,320 KB（约 148 MB）
默认分支 main
许可证 NOASSERTION（非标准 SPDX）→ 实为 Multica License = Apache 2.0 完整原文 + Part I 附加条款
组织 multica-ai（品牌名 Multica，官网 + Discord + X）

组织与背景：multica-ai 为项目自有组织，无其他仓库背书线索。项目名自述为 Multiplexed Information and Computing Agent，取自 1960 年代分时操作系统 Multics（README “Why Multica?” 节原文）。

发布节奏：README 原文 “We release most weekdays, so main moves quickly — pull often.” —— 官方自称工作日几乎每日发版。另有 Release badge 与 GHCR 镜像 tag 机制（见 2.2）。

端侧完备度：Web（Next.js 16）+ Desktop（Electron，macOS/Windows/Linux）+ Mobile（Expo/React Native，仅 iOS，且需从源码构建，尚未上架 App Store）+ CLI。

二、怎么用：安装 / 依赖 / 配置 / 上手难度

2.1 架构与部署全貌

官方 README “Architecture” 节的拓扑原文（示意）：

     Web  ·  Desktop (macOS/Windows/Linux)  ·  iOS
                       │
┌──────────────┐   ┌──────────────┐   ┌──────────────────┐
│   Next.js    │──>│  Go backend  │──>│   PostgreSQL     │
│   frontend   │<──│  (Chi + WS)  │<──│   (17)           │
└──────────────┘   └──────┬───────┘   └──────────────────┘
                          │  tasks over WebSocket
                   ┌──────┴───────┐
                   │ Agent daemon │  runs on your machine, next to your code
                   └──────┬───────┘
                          │  spawns
                   ┌──────┴───────────────────────────────┐
                   │  Claude Code · Codex · Cursor · …    │
                   └──────────────────────────────────────┘
层 技术栈（README 原文）
Web Next.js 16（App Router）
Desktop Electron，复用 web UI 包
Mobile Expo / React Native（iOS）
Backend Go（Chi router、sqlc、gorilla/websocket）
Database PostgreSQL 17（pgcrypto + pg_trgm）
Agent runtime 本地 daemon，执行 26 种 agent CLI 中的任意一种

口径标注：README 文字多处写 “26 agent CLIs”，但 README “Runtimes” 表与 CLI_AND_DAEMON.md “Supported Agents” 表实际各列 25 项。两处数字不一致，如实记录，以官方后续更新为准。

另一个口径澄清：SELF_HOSTING.md 与 SELF_HOSTING_ADVANCED.md 在数据库小节明确否认使用 pgvector —— “It does not use pgvector — no migration declares a vector column or runs CREATE EXTENSION vector.” 但 compose 文件里 Postgres 镜像用的是 pgvector/pgvector:pg17。第三方文章（含微信公号转载）普遍写成 “PostgreSQL 17 with pgvector”，属镜像名误读，官方原文不支持该说法。

2.2 服务端自托管部署

Docker Compose（官方推荐路径）

前置（self-host-quickstart.zh.mdx 原文）：

  • Docker Engine 或 Docker Desktop，且 docker compose 可用（Compose v2，旧的 docker-compose v1 不受支持）
  • Git、Make、curl、OpenSSL
  • 本机 3000、8080 端口未被占用
git clone --depth 1 https://github.com/multica-ai/multica.git
cd multica
make selfhost

make selfhost 首次运行会（原文四步 + 一步）：

  1. 从 .env.example 创建 .env
  2. 随机生成 JWT_SECRET、PostgreSQL 密码、MULTICA_VCS_SECRET_KEY
  3. 拉取 PostgreSQL / backend / frontend 镜像
  4. 创建持久化数据卷并启动三个容器
  5. 等待 backend 通过健康检查

就绪校验：

curl -fsS http://localhost:8080/readyz
# {"status":"ok","checks":{"db":"ok","migrations":"ok"}}

Migration 由 backend 容器每次启动时自动运行，无需手工执行。

容器与端口（docker-compose.selfhost.yml 实测）：

服务 镜像 端口绑定
postgres pgvector/pgvector:pg17 未对外发布
backend ghcr.io/multica-ai/multica-backend:${TAG} 127.0.0.1:8080
frontend ghcr.io/multica-ai/multica-web:${TAG} 127.0.0.1:3000

⚠️ compose 文件头部原文警告（对跨机部署是决定性约束）：
“Services bind to 127.0.0.1 only. For cross-machine or public access, front them with a reverse proxy (Caddy / nginx / Cloudflare Tunnel) that terminates TLS and forwards to 127.0.0.1:8080 (backend) and 127.0.0.1:3000 (frontend). Do NOT change these bindings to 0.0.0.0 — Docker bypasses host firewalls (UFW/iptables) by default, so the raw ports would be exposed to the internet while any deployment credentials remain weak.”

注意官方在这句里就已点名 Cloudflare Tunnel 作为跨机访问的合法前置手段之一。

Kubernetes / Helm（官方替代路径）

helm install multica oci://ghcr.io/multica-ai/charts/multica --version <chart-version> -n multica
  • Chart 版本 = Git tag 去掉前缀 v（v0.3.5 → chart 0.3.5）
  • 创建的资源：multica-postgres（10Gi PVC）、multica-backend（5Gi uploads PVC，配了 S3 可关）、multica-frontend、两个 Ingress（web host + backend host）、multica-config ConfigMap
  • multica-secrets Secret 不由 chart 管理 —— 官方要求用 kubectl 手工创建一次，避免真实值进 git
  • 前置：kubectl + helm（v3.13+ 用 --take-ownership，或 v4+）、Ingress Controller、默认 StorageClass；官方表述为”针对 k3s + Traefik + local-path 撰写”，其他集群需小幅调整
  • 默认域名 multica.dev.lan（web）/ api.multica.dev.lan（backend），需自行在 /etc/hosts 或本地 DNS 解析

登录（自托管特有坑）

自托管 stack 默认 APP_ENV=production，默认没有固定验证码。三条路：

  1. 配 RESEND_API_KEY（推荐，走邮件）
  2. 不配邮件 → 验证码打到 backend 容器日志：
    docker compose -f docker-compose.selfhost.yml logs backend | grep "Verification code"
  3. 私有测试环境 → 设 APP_ENV=development + MULTICA_DEV_VERIFICATION_CODE=888888

⚠️ 官方警告原文：不要在公网可达实例上设固定验证码 —— 任何人只要知道邮箱就能用固定码登录。

升级：git pull + docker compose -f docker-compose.selfhost.yml pull + up -d。官方特别澄清：“What git pull actually does” —— git pull 更新的是 compose 文件本身（新环境变量、新服务、改过的 healthcheck），不是版本；版本由 docker compose pull 向 GHCR 查询 tag 当前指向决定。一份几个月没更新的 checkout 依然会拉到当天的最新镜像。

2.3 执行电脑接入（CLI + daemon）

服务端就绪后，在真正跑 AI 编程工具的电脑上（原文强调：”不一定是运行 Docker 的服务器”）：

# macOS / Linux
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

服务端在另一台机器时：

multica setup self-host \
  --server-url https://api.example.com \
  --app-url https://app.example.com

该命令会：先 GET <server-url>/health 要求 200 → 打开浏览器完成登录 → 保存本机凭据 → 启动 daemon。

校验：

multica daemon status
# Daemon: running
# Agents: <本机已安装的 AI 编程工具>
# Workspaces: > 0

daemon 默认后台运行，状态目录（CLI_AND_DAEMON.md 原文表）：

Profile 状态目录
默认（无 --profile） ~/.multica/
命名（--profile <name>） ~/.multica/profiles/<name>/

内含 daemon.log（日志）、daemon.pid、daemon.err.log。Desktop 应用跑的是自己的命名 profile —— 同机装过 Desktop 和 CLI 时两个日志都存在，官方明确提醒”别猜，multica daemon logs 会打印它解析出的绝对路径”。

上手难度：中等。 依赖面是 Docker + Compose v2（或 k8s），配置项数量可观（.env 有数十个变量，TLS / 反代 / cookie 域需自行决策），且跨机场景有若干”静默失败”的坑（见 2.5）。

2.4 多 Agent 接入机制

Multica 的”接入”是两层嵌套，理解这一点才谈得上后续的远端接入问题：

第一层：daemon 探测本机 CLI → 注册为 runtime

daemon 启动时扫描 PATH，把每个命中的受支持 CLI 注册为一个 runtime。官方原文：“A runtime is one computer plus one AI coding tool.” 一台机器装了 3 个 CLI 且接入 2 个工作区 → 注册 6 个 runtime。重启 daemon 只更新记录，不重复创建。

实测抓取的受支持 CLI 清单（CLI_AND_DAEMON.md + providers.zh.mdx 对照），与用户自有 agent 相关的行已加粗：

CLI 检测命令 会话恢复 Multica 管 MCP Skill 注入位置
Claude Code claude ✓ ✓ .claude/skills/
OpenAI Codex codex ✓ ✓ $CODEX_HOME/skills/
Cursor Agent cursor-agent ✓ ✓ .cursor/skills/
GitHub Copilot CLI copilot ✓ — .github/skills/
OpenCode opencode ✓ ✓ .opencode/skills/
OpenClaw openclaw ✓ ✓ skills/
Hermes hermes ✓ ✓ 单次执行的 HERMES_HOME/skills/
Qoder CLI qodercli ✓ ✓ .qoder/skills/
Qoder CN CLI qoderclicn ✓ ✓ .qoder/skills/
DeepSeek Harness dsh ✓ ✓ .dsh/skills/
Qwen Code qwen ✓ ✓ .qwen/skills/
QwenPaw qwenpaw ✓ ✓ 单次执行的工作区 skills/
Kimi CLI kimi ✓ ✓ .kimi/skills/
Kiro CLI kiro-cli ✓ ✓ .kiro/skills/
Reasonix reasonix ✓ ✓ .reasonix/skills/
Trae CLI traecli ✓ ✓ .traecli/skills/
Antigravity agy ✓ — .agents/skills/
CodeBuddy codebuddy ✓ ✓ .codebuddy/skills/
CodeArts codearts ✓ ✓ .codeartsdoer/skills/
DevEco Code deveco ✓ — .deveco/skills/
Grok grok ✓ ✓ .grok/skills/
MiniMax Code mcode — ✓ .minimax/skills/
Pi pi ✓ — .pi/skills/
Oh-My-Pi omp ✓ ✓ .omp/skills/
Dim dim ✓ ✓ —

⚠️ DeepSeek Harness 的额外前置（对用户实际有影响）：官方原文要求先安装 Multica 运行时 profile bundle —— “这个 bundle 实现了 Multica 驱动的 --stdio 协议，也是单独的 dsh 无法直接使用的原因”。而该 bundle 尚未发布到公共 npm registry（官方 issue #6936）。官方给出的自托管做法是：从 multica-ai/dsh-multica-runtime 仓库自行构建，把 MULTICA_DSH_PROFILE_BUNDLE 指向构建产物（或 npm pack 的 tarball）。daemon 只有在 dsh --profile multica --probe 成功后才注册该 runtime，失败会在 /health 报告缺少 profile。另需先设 DEEPSEEK_API_KEY。

⚠️ Hermes 的隔离细节：绑定 skill 时用单次执行的 HERMES_HOME，已有本地配置仍可读，但绑定的 skill 与会话数据按运行隔离；未绑 skill 的运行使用本机原有的 Hermes 主目录。

自定义运行时配置（对付”内部 wrapper / 固定版本可执行文件 / 需要固定参数”）：

  • 仅 workspace owner / admin 可创建
  • 必须从 Multica 已有的协议族里选一个，命令须与该协议兼容
  • 命令字段接受可执行文件 + 参数，不支持管道、重定向、&&、;、反引号、变量展开；需要这些就包一层脚本
  • 参数顺序：<你的命令> <你的固定参数> <Multica 协议参数> <agent 自定义参数>
  • 冲突时 Multica 的值获胜（例：agent 上选的模型覆盖 profile 里 pin 的 --model）；-p / --output-format / --input-format / --permission-mode 这类协议关键 flag 会被忽略
  • Desktop 派生的 daemon 找不到终端能跑的命令时：multica runtime profile set-path <profile-id> --path /abs/path/to/command

第二层：workspace 内的 agent 是逻辑实体

agent = 名字 + provider + runtime + 模型 + 指令 + Skill + Access（仅自己 / 整个工作区 / 指定成员，新建默认仅自己）。官方明确：工作区 owner 和 admin 可以管理所有 agent，但不能绕过 Access 运行别人的”仅自己” agent。

runtime 侧也有对称的私有/公开设计：本地 runtime 默认私有（只有 runtime 所有者能在上面建 agent，workspace admin 也不例外 —— “运行时是别人的电脑，在上面跑智能体消耗的是对方的机器和工具凭据”）；只有所有者能改公开，公开后其他成员可以把 agent 的 run 路由过来，但不共享底层 CLI 的登录凭据。

多 agent 协作能力：Squads（一名 leader agent 协调成员，负责路由 —— 属 Manager/Hierarchy 形态）、Projects、Skills（沉淀可复用方法）、Autopilots（cron 定时 / webhook 触发）。Squads 官方定性：“它不会把多个智能体合并成一个新的智能体，也不会自动提高并发。”

2.5 ⭐ 部署形态对比：公网服务器 vs 本台云电脑

这是本次调研的侧重点。差异的根源只有一条：官方自托管 stack 只把端口绑到 127.0.0.1，跨机访问必须由一层反向代理或隧道来承担 TLS 与转发。于是”服务端放在哪”直接决定了远端执行电脑能不能连上。

维度 部署在公网服务器 部署在本台云电脑
服务端组成 同：PostgreSQL + Go backend + Next.js frontend（3 容器） 同
硬件要求 Docker + Compose v2 / k8s，3000+8080 空闲 同
端口默认绑定 127.0.0.1:3000 / 127.0.0.1:8080 同
远端可达性 有公网 IP → 配反代（Caddy/Nginx）+ TLS 即可被外部访问 云电脑无公网 IP、无法端口映射 → 反代无处落地，必须走隧道（官方点名 Cloudflare Tunnel）或另找公网出口
需要的额外组件 反代 + 证书（Caddy 可自动申请） 隧道客户端（如 cloudflared）+ 一个可解析的域名
TLS 终止位置 反代 隧道服务端（Cloudflare 边缘）
daemon 连接地址 wss://api.example.com/api/daemon/ws 隧道的公网域名 + /api/daemon/ws
域名要求 需要（COOKIE_DOMAIN / FRONTEND_ORIGIN 依赖域名；不能用 IP 字面量，RFC 6265 禁止 cookie Domain 用 IP） 同，且必须有域名才能挂隧道
数据落点 自己的服务器 自己的云电脑（但隧道流量过 Cloudflare 边缘）
对外暴露面 反代 + TLS + 登录（可加 ALLOW_SIGNUP=false、DISABLE_WORKSPACE_CREATION=true） 隧道入口，通常不直接暴露原始端口，但隧道可被公网访问
运维负担 反代配置、证书续期、防火墙、备份 隧道保活、云电脑重启后隧道是否自启、机器本身是否长期在线
失联风险 服务器宕机 云电脑关机/重启即全站不可用，且 daemon 心跳断开会把所属 runtime 判离线（约 3 分钟内），离线超 7 天且无 agent 绑定会被自动清理
资源与并发 官方未给最低配置；自托管版无人为的 agent 数量上限，并发由硬件决定（daemon 默认 20 并发 / 单 agent 默认 6，取小） 16GB 内存 4 核 8 线程的云电脑跑 3 个容器属常规负载范围，但同一台机器若同时既是服务端又是执行电脑，则 agent run 与 Docker 容器争抢同一份 CPU/内存
同机简化路径 服务端与 daemon 同机 → multica setup self-host 免传 URL 同；这是云电脑自托管时最省事的组合（全本地 localhost，但代价是远端 agent 接不进来，见下节）

与”不使用自托管”的第三条路对照：官方另提供 Multica Cloud（注册即用），此时服务端在官方、你只跑 daemon。multica setup（不带 self-host）即连 Cloud；从自托管切 Cloud 用 multica setup，命令会先提示再覆盖现有配置，本地 Docker 服务不受影响。

维度 自托管 @ 服务器 自托管 @ 云电脑 Multica Cloud
服务端归属 自己 自己 官方
需要公网 IP 是 否（但需要隧道出口） 否（官方已有）
远端 agent 可接入 是（反代 + TLS 后直连） 需隧道，否则否 是（直接连官方）
数据是否离开自有机器 否 否（隧道流量过 CF 边缘） 是
代码/凭据是否上传 否（官方原文：“Code never leaves it”、“does not automatically upload your entire working directory”） 同 同
软件许可费 无 无 有免费试用，价格未公布（官网 /pricing 2026-09-21 实测 404）
计费面 仅基础设施 + 自己的模型/CLI 额度 同 待官方公布
agent 数量上限 无（官方表述） 无 待官方公布

口径标注：Multica Cloud 的定价官方未公布。https://multica.ai/pricing 在 2026-09-21 实测返回 404；第三方站点（2026-08-26 记录）同样记 404，并称”提供免费试用但无价格页”。第三方站整理的”$0/月 开源免费（自托管）+ Cloud 免费试用”属二手口径，非官方定价承诺，仅作参考。

2.6 ⭐ 远端 Agent 接入服务器端 Multica：可行性与路径

结论先行：设计上完全支持，且这就是 Multica 的标准用法。 但”接入”的含义需要精确区分 —— 用户问的”远端 Agent 接入”，在这套架构下有两种截然不同的解读，且只有一种成立。

A. 走官方标准路径：在远端机器上装 CLI + daemon（✅ 官方支持，且是核心设计）

任何能访问到 server 地址的机器，都可以：

# 1. 装 Multica CLI（该机器上）
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash

# 2. 指向服务器端 Multica 的公开地址，登录并起 daemon
multica setup self-host \
  --server-url https://api.example.com \
  --app-url  https://app.example.com

此后 daemon 会自动探测该远端机器 PATH 上的 CLI（Hermes / Qoder CLI / dsh / OpenClaw …），逐个注册为 runtime，出现在服务器的 Settings → Runtimes 列表里。随后在服务器上创建 agent、指定这条远端 runtime，run 就会在那台远端机器上执行 —— 代码和该 CLI 的登录凭据始终留在远端机器，只有任务、评论、运行记录和 agent 写回的结果回到服务器。

B. 想把”正在运行的某个 agent 实例”直接挂进去（❌ 不支持这种形态）

官方机制里没有”连接到一个已存在的 agent 进程/服务”这条路。daemon 做的是spawn 子进程：为每次 run 建独立工作目录（~/multica_workspaces/）、拉起 CLI、回传结果。

也就是说：

想要的形态 Multica 是否支持 说明
远端机器上的同款 CLI，由 daemon 新起进程执行 ✅ 标准路径，即上面 A
接管一个已经在跑的 Hermes / dsh 进程或 web 服务 ❌ daemon 不连接已有实例；它是拉起新子进程
让远端 daemon 注册的 runtime 供服务器上的 agent 调用 ✅ 即 A 的落点，runtime 可设 public 供其他成员路由
通过 A2A / 标准协议端点把外部 agent 编入 ⚠️ 未确证 CLI_AND_DAEMON.md 出现过 “Run as an agent (inside a task, or over A2A)” 的措辞，但官方文档没有独立的 A2A 页面（已核 apps/docs/content/docs/ 全部 42 个文档页，无 a2a/mcp 专页），A2A 的实际对外形态未在公开文档中定义

C. 网络可达性前置（这是真正会卡住的地方）

远端 daemon 是主动出站连接 —— 不需要服务器为 daemon 开放任何入站端口，也不需要 daemon 侧有公网 IP。要满足的只有一条：远端机器能访问到 <server-url>。所以：

服务端所在 远端 daemon 能否接入 需要什么
公网服务器 ✅ 可 反代 + TLS，把 /health、/ws、/api/daemon/ws 路由到 backend
云电脑（无公网 IP、不能端口映射） ⚠️ 需隧道 官方点名的 Cloudflare Tunnel，或等价内网穿透；反代本身没地方落
同机 ✅ 可 直接用 localhost，multica setup self-host 免传 URL

跨机反代的三个”静默失败”坑（官方原文点名，全部会导致”看起来连上了但实时功能消失”）：

  1. daemon 拨的是 {server-url}/api/daemon/ws，不是 /ws。 单一 origin 模式下必须单独为这条路径开直通；缺了它 “握手失败后 daemon 会静默回退到轮询”（功能不报错，但实时性退化）。
  2. multica setup 会 GET <server-url>/health 并要求 200。 旧版 frontend 不转发该路径 → 报 Server not reachable。
  3. CORS_ALLOWED_ORIGINS / FRONTEND_ORIGIN 同时管 HTTP CORS 和 WebSocket 的 Origin 校验。 未列入的 origin 会被 403 拒绝（backend 日志：websocket: request origin not allowed by Upgrader.CheckOrigin），浏览器侧表现为 disconnected, reconnecting in 3s 循环，而 HTTP 请求照常（所以页面能开、数据不更新）。

daemon 侧的关键可调项（SELF_HOSTING_ADVANCED.md 原文表）：

变量 默认 说明
MULTICA_SERVER_URL ws://localhost:8080/ws daemon → server 的 WebSocket 地址
MULTICA_APP_URL http://localhost:3000 CLI 登录流程用的前端地址
MULTICA_DAEMON_SERVER_URL — 优先级最高；服务端 daemon_server_url 解析顺序为 MULTICA_DAEMON_SERVER_URL → MULTICA_PUBLIC_URL → MULTICA_APP_URL → FRONTEND_ORIGIN
MULTICA_DAEMON_POLL_INTERVAL 30s 兜底轮询（正常靠 WS wake signal）
MULTICA_DAEMON_WS_CLAIM_POLL_INTERVAL 3m 健康 WS 下的申领安全轮询上限（带抖动，常态 2m30s–2m45s）
MULTICA_DAEMON_HEARTBEAT_INTERVAL 15s 心跳

验证服务端是否给出了正确的 daemon 地址（官方给的一行命令，很实用）：

curl -fsS https://app.example.com/api/config | grep -o '"daemon_server_url":"[^"]*"'

若输出 localhost，说明 .env 还是本地默认值；若整段字段缺失，说明 MULTICA_APP_URL 和 FRONTEND_ORIGIN 都没设（此时即便设了 MULTICA_DAEMON_SERVER_URL 或 MULTICA_PUBLIC_URL 也不会输出）。

D. 远端机器的鉴权（headless 场景）

  • 标准流程：multica setup self-host ... 会打开浏览器完成登录 → CLI 自动创建 90 天 PAT 存进 profile 配置
  • 无浏览器的远端机器：先在 Web 的 Settings → API Token 建 PAT，再 multica login --token（会提示交互式粘贴，避免 token 进 shell history）；或 multica login --token=<mul_...>
  • PAT 剩余有效期 < 7 天时自动续期到 90 天；一旦过期或被吊销，需重新 multica login

2.7 多机器 / 多 agent 的组织方式小结

想做的事 Multica 里的做法
一台机器接多个 agent 工具 装多个 CLI，一个 daemon 全部探测注册
多台机器接进来 每台各装 CLI + daemon，各注册自己的 runtime
同一个 agent 定义跨机器跑 agent 绑定某一条 runtime；换机器改绑定即可
让别人也能用我这台机器的算力 runtime 改 public（仅所有者可改）
限制谁能跑某个 agent 设 agent 的 Access（仅自己 / 整个工作区 / 指定成员）
多个 agent 协作完成一件事 Squads（leader 路由）或 Projects + issue 里的 @ 提及
定时跑 Autopilots（cron 触发或 webhook 触发）
从 IM 里触发 Channels：Slack、Lark（飞书）、DingTalk、WeCom、Telegram（后三者官方标注为 community-maintained）

三、对用户的价值（分场景客观记录，非本报告立场）

场景 可对应的事实
已有 Hermes / Qoder CLI / dsh / OpenClaw 等多个 agent 四者全部在官方支持列表内（hermes / qodercli / dsh / openclaw），且都支持会话恢复与 MCP 托管。这是”多 agent 接入”最直接的落点
想给多个 agent 找统一看板而不是 N 个终端窗口 这是官方 README 开篇描述的核心痛点原文：“Each one lives in its own terminal tab, forgets everything when the session ends, and leaves you re-explaining the same context for the fourth time today.”
云电脑 + 本机跨机协作 架构天然支持：服务端一处，daemon 多处。云电脑无公网 IP 这一点由隧道补齐（官方点名 Cloudflare Tunnel）
已有 cloudflared 隧道 + 自有域名 与官方的跨机访问方案直接对齐；MULTICA_PUBLIC_URL 指向隧道域名即可让远端 daemon 接入
对数据落点敏感 官方原文：“Code never leaves it”、“does not automatically upload your entire working directory”；自托管下服务端、数据库、执行现场都在自己机器
担心 agent 跑起来乱动文件 官方明确不做文件系统沙箱（见八），需自己用专用用户/容器/VM 做边界
想复用已有 skill 资产 支持 Skill 注入到各 CLI 的原生目录（Hermes → HERMES_HOME/skills/、Qoder CLI → .qoder/skills/、dsh → .dsh/skills/）
软考/知识库等非编码任务 官方定位明确是”AI coding agents”的协作层；第三方评测也直言（非官方口径）：“如果没有编程 Agent 需求，Multica 还有用吗？几乎没用。”

四、能力边界

✅ 能做什么

  • 把已安装并登录的 25 种（官方文字称 26 种）agent CLI 注册为可调度的 runtime
  • 跨机器组队：一台服务端 + 任意多台执行电脑（每台一个 daemon）
  • issue 看板式派活：指派给 agent 或人，agent 领活、评论进展、交回 review
  • run 级可观测：执行日志（每次工具调用/命令/错误，带时间戳）、token 消耗、失败自动重试与超时
  • 时间表与事件触发（Autopilots：cron / webhook，也可手动触发）
  • 多 agent 协作（Squads，leader 路由）、Projects、Skills 复用
  • 任意 Git 宿主（GitHub / GitLab / Gitea / Forgejo，含自托管）
  • IM 触发（Slack、Lark、DingTalk、WeCom、Telegram）
  • 全表面可脚本化（CLI + API，--output json）
  • 自托管：Docker Compose 或 Helm；无 agent 数量的人为上限

❌ 不能做什么

  • 不提供模型：不替代任何 agent CLI，CLI 的账号/订阅/额度需自备（官方原文：“Multica does not ship a model.”）
  • 不接管已运行的 agent 实例：只 spawn 新子进程（见 2.6-B）
  • 不做文件系统沙箱：默认以 daemon 所属 OS 用户的完整权限执行（见八）
  • 无企业级 SSO 与细粒度权限（第三方评测口径，非官方声明；官方文档只定义了 owner / admin / member）
  • Mobile 端仅 iOS，且需源码构建，未上架 App Store
  • 文档无独立 A2A 页：A2A 只在 CLI_AND_DAEMON.md 的 autopilot 授权段落被顺带提及
  • 官方未公布 Cloud 定价（/pricing 404）

⚠️ 注意事项

  • 许可有附加条款（见八）：内部自用免费，向组织外部提供托管服务需商业许可（无论是否收费）
  • 官方自述 workday 每日发版，main 移动快 —— 跟 main 构建的产物与 GHCR 镜像可能不同版本，官方建议构建前 git checkout 到最新 release tag
  • 数据库不可用 pgvector（官方原文澄清），第三方文章的 “with pgvector” 说法不成立
  • 自托管 API 默认开启一方遥测（见八）

五、与同类对比

同目录既有调研已覆盖 20+ 个”接入自有 agent”的项目，本节只做定位对照（各项目实测数据见对应文档）：

项目 定位 与 Multica 的关系
Multica 看板式 agent 协作平台（issue 派活 + 自托管 + 25 种 CLI） —
QoderWake（阿里） 数字员工平台，”岗位 Waker”抽象，纯单体 + 单机部署 形态最接近的对照物：同样是”给 agent 派活的平台”，但 QoderWake 官方无分布式方案，Multica 的核心恰是”服务端 + 多台执行电脑”
AgentTeams（阿里 AgentScope） 团队协作，Matrix IM 房间为总线 都支持 Hermes——AgentTeams 是IM 群当总线，Multica 是看板当总线；Multica 的 Manager 侧不限 OpenClaw/QwenPaw（AgentTeams 有此限制）
Octo（明略） 官宣 Hermes adapter Octo 是适配器接入（把 agent 接进 Octo），Multica 是 daemon 探测 CLI；二者接入哲学不同
ClawTeam（港大） 任意 CLI agent 拉群 ClawTeam 是群聊协调，无看板/issue 概念；Multica 有完整任务生命周期
OpenAB IM 群 + ACP CLI，含 bot-to-bot 面向 IM 场景；Multica 面向”像给同事派活一样”的任务管理
多智能体框架（MAF/AG2/CrewAI/CAMEL） 代码级框架，需写代码定义 agent 交互 与 Multica 不冲突、可组合：框架写 agent，Multica 管任务与运行
Multica Cloud（官方） 官方托管版 同一产品的托管形态，自托管的替代路径

定位判断（客观陈述）：Multica 在既有调研谱系中补的是一个此前没有的位置 —— “以任务/看板为中心、且原生支持跨机分布式执行”的自托管平台。ClawTeam/OpenAB 偏 IM 总线，AgentTeams 偏 IM 房间，QoderWake 偏单机，框架类偏代码。Multica 的 daemon 架构是它与上述诸项最核心的结构差异。

六、社区反馈与可靠性

实测数据（2026-09-21，GitHub API）

指标 值 解读
Star 50,986 创建 8 个月即 5 万星，属高热度项目
Fork 6,601 fork/star ≈ 12.9%，偏高
Open issues 1,620 绝对数大，与日更节奏和功能广度相符
Subscribers 182 关注度相对 star 数偏低
最后推送 2026-09-21 调研当日仍在推送
发版节奏 官方自称工作日几乎每日 与 pushed_at 一致

官方背景与素材质量

  • 有完整官方文档站（multica.ai/docs，含官方中文版，apps/docs/content/docs/ 下 42 个文档页，每页有 .zh.mdx 翻译）
  • 有 VISION.md / VISION.zh.md / README.zh.md / NOTICE / CONTRIBUTING.md / AGENTS.md / CLAUDE.md / skills-lock.json
  • 有 Discord 与 X 账号；GitHub Actions CI badge；Goreleaser 发布
  • 官方文档质量显著高于同类：对”静默失败”这类坑给出成段的原文解释（如 /ws vs /api/daemon/ws 的区分、COOKIE_DOMAIN 缺失导致 CSRF 403、NEXT_PUBLIC_API_URL 误填路径导致 404）

情报污染识别（重要）

  • 搜索结果里大量AI 生成的 SEO 站点（如 codepick / aixq / intelligenttools / aicoolies / tenten 等）在复述 Multica。其共通问题：把镜像名 pgvector/pgvector:pg17 读成”使用 pgvector”（官方明确否认）；把 CLI 数量写成 8 / 12 / 23 等各异数字（官方文档表为 25，README 文字为 26）；引用”Gemini CLI”作为受支持工具（官方列表中是 Antigravity agy，未见 Gemini CLI）。这些站点只可用于了解项目方叙事，不作为能力依据。
  • 本文所有能力结论均以 github.com/multica-ai/multica 仓库内的 README.md / SELF_HOSTING.md / SELF_HOSTING_ADVANCED.md / CLI_AND_DAEMON.md / apps/docs/content/docs/*.mdx 与 GitHub API 元数据为依据。

可靠性判断（事实层）

  • 代码与文档活跃度：高（当日推送、日更发版、文档含三语）
  • 部署路径成熟度：Docker Compose 为一等公民（官方推荐路径 + Makefile 目标 + 安装脚本 + 健康检查等待脚本）；Helm 为”替代路径”，官方自述针对 k3s+Traefik 撰写
  • 已知不稳定面：main 快于 release，跟 main 构建需自行对齐 tag；1620 个 open issue；Cloud 定价未定
  • 许可证可靠性提示：LICENSE 为自定义许可（NOASSERTION），不是 OSI 认证的纯 Apache 2.0（第三方评测亦持此看法，非官方表述）

七、环境

运行时依赖

组件 要求
服务端 Docker Engine / Docker Desktop + Compose v2（docker compose）；或 k8s + Ingress + StorageClass；另需 Git、Make、curl、OpenSSL
服务端端口 3000（frontend）、8080（backend）需空闲
数据库 PostgreSQL 17（官方镜像 pgvector/pgvector:pg17；不使用 pgvector 扩展）
编排替代 Helm v3.13+（--take-ownership）或 v4+、kubectl
执行电脑 Multica CLI + 至少一款已安装并登录的受支持 agent CLI
CLI 安装 macOS/Linux：install.sh 或 Homebrew tap；Windows：install.ps1
daemon 平台 Windows / macOS / Linux 均可（Desktop 覆盖三平台）

仓库体积：约 148 MB（151,320 KB，GitHub API size）。

hook / 插件依赖：无 hook 机制；”扩展”通过 agent 绑定的 Skill 与 MCP 配置实现，注入到各 CLI 原生目录。

平台兼容：Windows 有专用 PowerShell 安装脚本；官方文档在 daemon、Codex 沙箱、DSH Desktop 路径等处均给出 Windows 特例说明（如 DSH Desktop 的 CLI shim 位于 %APPDATA%\DSH Desktop，即漫游应用数据目录而非安装目录）。

网络要求（关键）

  • daemon → server：主动出站 WebSocket（{server-url}/api/daemon/ws），无需 server 为 daemon 开入站端口
  • 浏览器 → server：HTTP + WebSocket（/ws），跨机必须走反代或隧道
  • 自托管 stack 只绑 127.0.0.1；官方禁止改成 0.0.0.0
  • CORS / WS Origin 校验需显式允许公开 origin
  • 云电脑场景（无公网 IP、不能端口映射）需自备隧道；官方文档点名 Cloudflare Tunnel

账号与密钥

变量 必需性 说明
JWT_SECRET 必需，无安全默认值 生产 backend 在为空或占位符时拒绝启动；openssl rand -hex 32
DATABASE_URL 必需 compose 自动拼装
FRONTEND_ORIGIN 必需（跨机场景） 用于 CORS；跨机必设，否则 WS 403
MULTICA_VCS_SECRET_KEY make selfhost 自动生成 自托管 Git 集成加密密钥
RESEND_API_KEY / SMTP_* 认证必需其一 都不配则验证码打到日志（仅适合一次性测试）
GOOGLE_CLIENT_ID / SECRET 可选 Google OAuth
ALLOW_SIGNUP / ALLOWED_EMAIL_DOMAINS / ALLOWED_EMAILS / DISABLE_WORKSPACE_CREATION 可选 私有实例加固
COOKIE_DOMAIN 双域名部署必需 单域名/同源必须留空；不可用 IP 字面量
DEEPSEEK_API_KEY 用 dsh 时必需 官方原文要求
MULTICA_DSH_PROFILE_BUNDLE 用 dsh 时必需 bundle 未发 npm，需自行构建

四个令牌层级

前缀 用途 生命周期
（无，HttpOnly cookie multica_auth） 浏览器会话 默认 30 天，使用中会自动续期；AUTH_TOKEN_TTL 可调
mul_ PAT，代表账号，可访问所有有权工作区 创建时选 30 天 / 90 天 / 1 年 / 永不（默认 90 天）；multica login 自动建的 PAT 剩余 <7 天时自动续到 90 天
mat_ run 级临时令牌，绑定 user + workspace + agent + run 最长 24 小时，run 结束即清理；由 server 自动创建，daemon 注入给 agent 而非用户 PAT
mcn_ / mdt_ 内部/托管场景（Cloud Node、workspace-scoped daemon auth） 常规安装不需手工创建，官方提醒不要自行构造其他前缀的令牌

备份提示：make selfhost 生成的 .env 含 JWT_SECRET、PG 密码、VCS 密钥；数据在 pgdata / backend_uploads 卷中。.env 丢失不等于服务立刻挂，但密钥重置会影响已签发的令牌与加密的 VCS 凭据。

八、安全风险评估

8.1 许可与来源

来源：github.com/multica-ai/multica（组织 multica-ai），非个人 fork。调研中另见到 dexterdeng/multica 等 fork，不是我方依据（本报告一律以 multica-ai/multica 为准）。

许可证：Multica License = Apache 2.0 完整未修改原文（Part II）+ 附加条款（Part I）。LICENSE 原文明确：“Neither part grants any rights on its own.”

Part I 关键条款摘录：

条款 内容 对本场景的含义
1a 未经商业许可，不得用源码向第三方提供托管服务，也不得作为商业分发产品的组件嵌入；向自己组织外部提供托管服务即算，无论是否收费、是否有广告、是否有付费档 单一组织内部使用（含多个工作区）明确无需商业许可
1b 未经书面品牌豁免，不得移除或修改 Multica LOGO、产品名、UI 显示的版权归属 自用不影响；二次分发界面需注意
1c 非界面部分（仅跑 backend / daemon / CLI，不发布界面）再分发时须保留源码与 NOTICE 归属，并在用户文档声明”基于 Multica”并附仓库链接 仅用 daemon 的场景有归属义务
2 贡献者提交即同意 producer 可调整许可（可更严或更宽），且贡献代码可被用于商业用途 贡献前需知情

第三方评测（intelligenttools.co，非官方）意见：“Multica calls itself ‘fully open source’, and the licence is Apache 2.0 with additional conditions rather than plain Apache 2.0.” —— 与 LICENSE 原文一致。

8.2 遥测

默认开启，且无法通过配置重定向端点。SELF_HOSTING.md 原文：

  • 自托管 API server 每个 UTC 日向固定端点 https://telemetry.multica.ai/v1/telemetry/events 发送一份部署级匿名快照
  • 端点编译进服务端，“cannot be redirected through configuration”
  • 快照内容：仅 release 版本号；过去 24 小时内的 workspace / 去重人类成员 / 活跃 agent / daemon 的分桶计数；run 的 started / completed / failed / cancelled 聚合计数
  • 官方声明不含：姓名、邮箱或域名、IP、业务 ID、主机/设备细节、仓库或组织细节、模型/插件数据、prompt 或输出、评论或聊天、路径、token/成本数据、凭据、错误、堆栈、日志
  • 不用于计费、许可、认证或安全决策
  • 关闭方式：在 API server 上设 DO_NOT_TRACK=1 或 true，然后重建/重启 backend
  • ⚠️ ANALYTICS_DISABLED 只控制另一个 PostHog 集成，不影响这项一方遥测
  • ⚠️ 官方提示：克隆生产库做 staging/测试前，先清空克隆库的 instance_telemetry_state 表（或设 DO_NOT_TRACK=true），否则两个部署共用一个身份、同日快照会静默互相去重

8.3 代码执行面（逐项核验）

这是本项目风险最高的部分，且官方主动、反复地把它写在显眼处。

security-model 文档原文要点：

项 官方表述
边界在哪 “By default a run executes with the full permissions of the operating-system user running the daemon.”
是否沙箱 “Multica makes no filesystem-sandbox guarantee.”、“Treat every run as unsandboxed and put the boundary outside the daemon.”
具体后果 “If the daemon runs as your personal user account, a run can read your SSH keys, edit your shell profile, and delete your documents.”
为什么不做 部分沙箱会破坏 agent 装依赖/跑构建/用云 CLI 的能力，且无法阻止 run 读取凭据并外发
唯一例外 Windows 上显式配置 Codex 原生沙箱（windows.sandbox = "unelevated" 或 "elevated"）时，Multica 尊重该 opt-in 并保留 workspace-write
默认路径的审批设置 Codex 以 sandbox_mode = "danger-full-access" 运行；Claude Code 以 --permission-mode bypassPermissions 运行 —— 审批提示由系统自动应答
官方推荐的边界 ① 专用 Unix 用户（给 multica 用户，只给需要的仓库与凭据）② 容器（只挂载必要的卷与密钥）③ 虚拟机（完全隔离，成本最高）

官方说”隔离了什么”（并明确这只是降低爆炸半径，不是安全边界）：

  • per-run 工作目录：每次 run 在 ~/multica_workspaces/ 下有独立工作目录，并发 run 不互相踩
  • per-run agent state：Codex run 拿到 run 级的 CODEX_HOME，不污染 ~/.codex/
  • run 级 API token：MULTICA_TOKEN 由服务端绑定到该 agent + 该 run，run 无法借它冒充你或别的 agent

官方明确列为”不是边界”的：coding tool 自身的沙箱与审批设置；HOME 目录布局（run 继承 daemon 用户的真实 HOME 与 XDG_* —— 这正是让 gh / aws / kubectl 能在 run 里正常工作的原因，也意味着 home 下一切可达）。

Linux 的变更提示（原文）：Linux 上 Codex 曾用 workspace-write + 重定向的 per-run HOME，该行为已被移除 —— 理由是它让宿主 CLI 在 run 里配置失效，且只限制写、从未阻止读取与偷传凭据。现在 Linux 与 macOS / Windows 默认行为一致。

自检命令（官方给出）：

multica daemon logs --lines 200 | grep "codex sandbox"
# 以及查看 run 的 CODEX_HOME 下 config.toml 中
# # BEGIN multica-managed … # END multica-managed 之间的区块

8.4 凭据与服务端侧的敏感信息

  • agent 的自定义环境变量与 MCP 配置保存在服务端，执行时才下发给 runtime。官方 warning 原文：“不要把’本地执行’理解为所有 secret 都只存在本机”。MCP server 的命令、参数、环境变量同样随 agent 配置存服务端
  • daemon 注入 run 的环境变量中，MULTICA_TOKEN 等 子进程默认全量继承 —— 官方提醒：“If a child should not hold the credential, strip it explicitly; do not rely on process isolation that is not there.” 反例：Codex 的 shell 工具会过滤含 TOKEN / KEY / SECRET 的名字，故 daemon 装了受管 shell policy 放行必需的任务变量
  • 官方要求：令牌只留在进程环境里，绝不写进 prompt、日志、仓库文件或持久配置
  • PAT 泄漏处理：multica auth logout 和 Web 登出都只在本地删 cookie/配置，不在服务端吊销；真吊销必须去 Settings → API Token

8.5 风险等级与使用注意

风险面 级别 依据
run 的执行权限（无沙箱） 高 官方明示以 daemon 用户全权限执行，Codex 默认 danger-full-access、CC 默认 bypassPermissions；官方要求自建边界
服务端暴露（跨机部署） 中 官方默认只绑 127.0.0.1 并禁止改 0.0.0.0；但跨机必须引入反代/隧道，暴露面随之外扩；固定验证码是官方点名的致命误配
遥测（默认开启、端点不可改） 低 内容为匿名聚合计数，官方逐项列出不含项；可用 DO_NOT_TRACK=1 关闭
许可（托管限制） 低（自用）/ 高（对外提供） 组织内部使用免许可；向外部提供托管服务（哪怕免费）需商业许可
供应链（dsh bundle） 中 官方原文点名这是供应链决策：MULTICA_DSH_PROFILE_BUNDLE 会在无二次确认的情况下装进每台 daemon 宿主的 DSH 家目录，官方建议只填自己发布或构建的产物
凭据存服务端（env / MCP） 中 自定义环境变量与 MCP 配置存服务端；官方 warning 明确提示不要把不需要共享的本地凭据写进去
数据落点 低（自托管） 代码与 CLI 凭据留在执行电脑；自托管下服务端数据在自己机器；但 Cloud 形态下数据过官方

使用注意（官方原文汇总）

  1. daemon 不要跑在个人账号下 —— 用专用用户/容器/VM
  2. 不要在公网实例设 MULTICA_DEV_VERIFICATION_CODE
  3. 不要把 compose 端口绑到 0.0.0.0
  4. COOKIE_DOMAIN 取能覆盖前后端的最窄父域（官方举例：agent.example.com + api.agent.example.com 用 .agent.example.com，不是 .example.com）—— 它同时决定会话 JWT 的发送范围；且要求该父域下所有主机都由同一可信方运营
  5. 异地/跨机部署优先用同源布局（单域名），会话 cookie 保持 host-only，规避跨域 cookie 问题
  6. 克隆生产库做测试前先清 instance_telemetry_state
  7. dsh 的 MULTICA_DSH_PROFILE_BUNDLE 只填自建产物

九、待研究清单

  • 在云电脑上实机跑一遍 make selfhost，记录三容器的实际内存/CPU 占用，与本机 daemon 同机共存时的表现
  • 实测 cloudflared 隧道把 Multica 服务端（云电脑，无公网 IP）暴露给本机 daemon：验证 /health、/ws、/api/daemon/ws 三条路径在单 origin 模式下是否都需要显式路由
  • 实测 daemon_server_url 解析链（MULTICA_DAEMON_SERVER_URL → MULTICA_PUBLIC_URL → MULTICA_APP_URL → FRONTEND_ORIGIN）在隧道域名下的实际输出
  • 实测本机 Hermes 接入：绑 skill 时的 HERMES_HOME 隔离是否影响已有 ~/.hermes 配置，以及未绑 skill 时是否会污染主目录
  • 实测 qodercli 接入：确认 Qoder CLI 的模型参数陷阱（不加 -m Qwen3.8-Flash 走扣费模型）在 daemon 拉起场景下如何配置（agent 侧选模型 vs profile 固定参数）
  • 查证 multica-ai/dsh-multica-runtime 仓库的构建产物与 npm pack tarball 的实际可用性（官方 issue #6936 状态）
  • 核实 A2A 在 Multica 中的实际对外形态（CLI_AND_DAEMON.md 提及但无独立文档页）
  • 核对官方”26 种 CLI”与文档表格 25 项的口径差（是否有新增未入表，或统计口径不同）
  • 关注 Multica Cloud 正式定价发布（multica.ai/pricing 当前 404）
  • 跟踪 Helm chart 在非 k3s 集群（尤其国产 k8s 发行版）上的兼容性
  • 评估 Squads（leader 路由）与用户既有 Hermes/WorkBuddy 协作模式的重合度
  • 若考虑对外提供托管：核对 Multica License 1a 的边界，必要时咨询商业许可

refer

  • Multica（GitHub 仓库）
  • Multica 自托管指南（SELF_HOSTING.md）
  • Multica 自托管高级配置（SELF_HOSTING_ADVANCED.md）
  • Multica CLI 与守护进程指南（CLI_AND_DAEMON.md）
  • Multica 官方文档：自托管快速上手（中文版）
  • Multica 官方文档：守护进程与运行时（中文版）
  • Multica 官方文档：认证与令牌（中文版）
  • Multica 官方文档：安全模型
  • Multica 官方文档：AI 编程工具对照（中文版）
  • Multica 官方文档：安装 AI 编程工具（中文版）
  • Multica 官方文档：环境变量
  • Multica License / NOTICE
  • multica-ai/dsh-multica-runtime
  • Multica issue #6936（dsh runtime bundle 未发布到 npm）

知识库内毗邻文档（互链）

  • Agent 互通与群聊方案调研（abbrlink 99065）：协议族 A2A/ACP、框架层群聊编排、现成 agent 互通、群聊形态横览
  • 多智能体框架 agent-team 实现方式调研（abbrlink 99067）：MAF / AG2 / CrewAI / CAMEL / Hermes 内部编排机制
  • QoderWake 调研（abbrlink 99069）：阿里 QoderWake 数字员工平台的多 agent 协作与单机部署（与本文的跨机部署形态互为对照）
  • 接入自有 Agent 的群聊与协作平台调研（abbrlink 99070）：Octo / AgentTeams / ClawTeam / OpenAB 等 20+ 项目的接入能力实测
  1. 本文如有错误，欢迎指正。
  2. blog 仅供个人记录使用。
  3. 年代久远，若引用来源不明，请联系我删除或补充出处。