私有化 Agent 平台选型——开源背后的三层风险

这篇适用于民营、互联网、创业团队——诉求是数据不出网、成本可控、能改能定制。

不适用于有信创硬约束的政务、金融、国企：开源平台没有原厂信创兜底，国产芯片与操作系统的编译、认证、长期适配都得自己扛，建议这类单位走「大厂信创栈 + 集成商交付」的路线。

在 Agent 平台选型会上，几乎每个架构师都会先排除掉闭源商业方案，理由惊人的一致：「我们要选开源的，代码在自己手里，才不会被厂商拿捏。」这个判断大体不错 —— 但恰恰是这句话里没说完的那半截，埋着真正的坑：代码在你手里，不等于主动权在你手里。能看到源码，和能真正掌控技术栈，中间隔着 3 层风险。

一、三层隐藏风险

第 1 层：协议约束风险

约束 A：厂商限制你能做什么。 BSL、SSPL、ELv2 是「源码可见」、并非真开源；Apache 协议较为友好，但也需要特别留意特殊条款：

Dify：修改版 Apache，未经书面授权不得运营多租户；
FastGPT：同类，多租户 SaaS 需授权，且不得移除 LOGO。

约束 B：许可证要求你公开自己的代码。 GPL/AGPL 等 copyleft 要求分发（AGPL 连网络服务也算）衍生作品时开源你的修改。开源平台里 MaxKB 是 GPL-3.0，对话式 AI 框架 Rasa 是 AGPL-3.0。二开交付客户前必须过法务，否则会被迫把自研代码一同开源。

约束 C：规则可能随时被改。 厂商主导项目的协议和路线图控制权在厂商手里。先例：MongoDB 推 SSPL、Terraform 改 BSL（分叉出 OpenTofu）、Redis 2024 年改 SSPL/RSAL（分叉出 Valkey）。

第 2 层：开源的是「核心」，付费的是「服务」

能力分层（Open Core）：社区版给核心，企业级能力（多工作空间、SSO、高级安全、可扩展部署）只在商业版。
运维与支持：自托管的部署、升级、排障、补丁全是自己的事，想要 SLA 和原厂响应，得回到商业合同。

第 3 层：迁移成本

模型生态：默认深度集成自家模型/云（字节系偏火山方舟、阿里系偏通义），接其他模型技术上可行，但工具链、默认路径、文档都围着自家生态转。
数据与接口：向量索引、工作流 DSL、Agent 定义多为私有格式，换平台要重建索引、重画流程。数据可导出 ≠ 低成本迁移。 接口层可用一层 LLM 网关（LiteLLM/One-API）解耦——切换模型只改路由配置，几乎零成本对冲模型绑定。

二、候选框架横向对比

协议自由度和开箱即用程度通常成反比——协议越干净，要自己补的治理层越厚。

三、如何选？

选型不是选「最强的」，而是选「匹配你约束的」——在协议自由度、治理成本、运维能力之间找平衡。

1. 核心场景，先定方向。

文档密集、要溯源（合同、财报、项目材料）→ RAGFlow；
快速搭 Bot、低门槛落地 → Coze Studio；
多步骤 Agent、完整工作流编排 → Dify；
知识库为主、要中文和交付速度 → FastGPT / MaxKB。

2. 内部用还是对外交付，最容易被忽略、代价却最大。 内部单租户，几款平台都能选；一旦 SaaS 化或交付客户，多租户条款、GPL 的 copyleft 义务都有影响——三条出路各付代价：付授权费（买商业授权）、付工程费（退回纯 Apache 自建租户）、付架构费（copyleft 进程隔离）。真实选择题不是「要不要成本」，而是「付给律师、付给开发、还是付给架构复杂度」。

3. 运维扛不扛得住，决定版本路线。 有专人能扛 → 社区版够用，享受自由度；扛不住 → 把商业支持成本提前算进预算。平台档默认单点部署，多副本、负载均衡、故障转移要自己上 K8s；大版本升级前的数据库迁移是高频事故点，升级前必备份。

结语

开源不等于没有绑定，3层风险一层不少。 开源真正解决的，是”你能不能看到、拿到、在本地跑起来这套代码”；它没有自动解决”企业级能力是否免费、数据是否方便迁移、厂商会不会改协议、出了事谁负责”。

值得注意的是，能私有化自托管的主流平台几乎全是中国团队——中国团队在 AI 应用与工程化落地这件事上，确实走在了前列，这份成果值得骄傲。但这骄傲要放在全球分工的坐标里看：支撑它们的底层和底层创新基本来自欧美，底层创新与工程化落地互为地基。选型成熟，既要看清 3 层风险、把主动权攥在手里，也要理解自己处在全球分工的一环。

本文由 @杨衡原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Pexels，基于CC0协议