Multica（multica.ai）是一个 100% 开源的”人 + agent 混合团队项目管理平台”（Project Management for Human + Agent Teams），提供两种使用形态：官方维护的云端版（hosted cloud version）和完全自托管。云端版免运维，开箱即用；自托管数据不出自己网络，无厂商锁定，agent 数量无人为上限。截至 2026-09，云端版的价格尚未公开【待补：官方定价页】；自托管有三条官方路线：Docker Compose、单二进制和 Kubernetes（K8s）。本文面向正在评估 Multica 落地方式的团队，从数据主权、成本、运维和团队规模四个角度给出决策框架。
场景与需求
把 Multica 引入团队时，第一个需要回答的问题是：平台的运行数据——包括任务状态、事件日志、agent 技能资产——放在谁的服务器上。这个问题没有通用答案，取决于你的团队画像：
- 个人开发者或 2~3 人初创团队：最大的约束是时间和运维能力。让 Multica 跑在别人的服务器上，把精力集中在 agent 和代码上，通常是最优解。
- 10 人左右开发团队，涉及客户代码：数据主权成为第一优先级。代码不能过第三方服务器的审计要求，即使可以接受自托管增加运维成本。
- 中大型团队（20 人以上），有平台治理诉求：需要完整的数据控制权、审计能力和基础设施集成（SSO、密钥管理、已有 K8s 集群），自托管几乎是唯一选项。这个规模下，Skills 的可复用能力变得关键——示例技能 write-migration v1.2.0 定义了完整的数据库迁移流程（分析 schema → 生成迁移 SQL → sqlc 校验 → 空库跑测试）。
候选方案
| 方案 | 一句话描述 |
|---|---|
| 云端版 | 官方托管，免运维，开箱即用【待补：价格与限额】 |
| 自托管 - Docker Compose | 小团队最平衡的选择：组件编排清晰，升级回滚可控 |
| 自托管 - 单二进制 | 依赖最少，适合个人试用或迁移路径起点【待补：下载与启动命令】 |
| 自托管 - Kubernetes（K8s） | 复用集群治理体系，适合已有基础设施的中大型团队 |
以下的分析集中在”云端版 vs 自托管”这一对核心抉择上，三条自托管路线之间的选择已在另一篇教程中详述（Multica 自托管教程）。
数据主权：代码在哪里执行
这是自托管最核心的理由。Multica 官方网站对自托管的数据主权有明确表述，这些信息在评估时可以直接引用：
- 代码不经过 Multica 服务器：agent 的执行发生在你的机器（本地 daemon）或你自己的云基础设施上，平台只负责协调任务状态和广播事件。
- 无厂商锁定：自带 LLM provider（bring your own LLM provider）、可换 agent backend、可扩展 API，整条栈归你。
- 透明可审计：每行代码可审计，能看清 agent 怎么决策、任务怎么路由、数据流向哪。
- 规模无上限：agent 数量取决于硬件；每个 agent 有可配置并发上限；可接多台机器当 runtime；开源版无人为数量限制。
云端版的数据流向官方没有详细披露【待补：云端版数据存储与隐私说明】。如果你的团队受合规框架约束（客户数据不外传、代码审计要求），自托管是目前唯一可选的方案。
版本对比：自托管的真实账本
成本对比目前缺少云端版的价格数据，只能做定性分析【待补：官方定价页补全后更新】。
| 成本项 | 云端版 | 自托管 |
|---|---|---|
| 平台许可费 | 【待补】 | 0（完全开源） |
| 基础设施 | 由官方承担 | 自行承担（服务器/云主机费用） |
| 运维人力 | 0（官方维护） | 首次部署 + 持续升级/备份/监控成本 |
| LLM 调用费 | 各自承担 API 费用 | 各自承担 API 费用 |
| 扩展成本 | 【待补】（按席位或用量的定价模型未知） | 硬件扩容 + 数据卷扩展 |
自托管的真实成本不在软件许可——开源版是免费的——而在三件事：基础设施（一台云主机或内网服务器，配置要求见官方文档【待补：最低硬件要求】）、运维时间（部署、升级、备份、排障）、以及你放弃的”免运维”溢价。如果团队里没有能处理 Docker Compose 或 Kubernetes 的人，自托管的隐性成本会比看起来高。
三档团队画像与推荐
画像 A：个人开发者 / 2~3 人初创团队
- 约束：运维能力弱，预算有限，时间宝贵
- 评估：自托管的学习曲线可能超过它带来的收益
- 推荐：优先选择云端版。如果团队没有自托管经验，不要为了”开源免费”这个理由去维护一套部署——你的时间更值钱。等团队规模增长到需要数据控制权时再迁移。
- 自托管切入点：如果确实需要自托管，从单二进制起步，一台机器跑通最小闭环。
画像 B：10 人左右开发团队，有数据敏感业务
- 约束：需要数据主权，有基本运维能力
- 推荐：自托管，Docker Compose 路线。这是一条工作量可接受的折中路线：单台服务器的维护成本远低于 K8s 集群，但已经满足”代码不经过第三方服务器”的承诺。升级策略参考官方文档【待补：官方升级步骤】。
- 迁移路径：如果在试用阶段用了云端版，迁移到自托管时需要确认数据导出机制【待补：数据导出与迁移支持】。
画像 C：20 人以上团队，有平台治理诉求
- 约束：数据审计、SSO、密钥管理、与已有基础设施集成
- 推荐：自托管，Kubernetes 路线。复用现有的发布、扩缩容、密钥管理和审计体系。Multica 的开源设计允许深度定制 agent backend 和 LLM provider 选择。
- 多环境需求：可以部署多套（开发/预发/生产），这对 agent 任务测试尤为关键。
决策框架
以下按优先级排序的 if-then 规则，你可以根据团队实际情况逐条对照：
- 团队有无运维能力？ 没有 → 选云端版（或先试用再决定）。
- 数据是否受合规约束（客户代码不外传、内网隔离要求）？ 是 → 选自托管。
- 团队规模是否快速扩张（预期 3 个月内 agent 数量翻倍）？ 是 → 选自托管（复制一份跑在新机器上即可，无人为上限）。
- 是否依赖已有 K8s 基础设施？ 是 → 自托管，Kubernetes 路线。
- 只是想先试用 Multica 评估是否适合团队？ → 选云端版或单二进制。两条路线都能在 30 分钟内跑通”建工作区 → 建 agent → 派 issue”的闭环。
最终选择
云端版和自托管不是非此即彼——它们是同一个开源平台的不同部署形态。起步阶段用云端版验证产品价值、自托管落地数据合规需求，是一个常见的演进路线。真正的决策变量只有一个：你的数据能不能出你的网络。