同类产品的功能列表重叠度很高，靠勾选表几乎分不出高下。真正决定选型结果的是四个变量：许可证到底允许你做什么、部署门槛落在哪一档、你需要的治理能力属于哪个版本、以及同一口径下的三年总成本。
这四个变量的共同特点是：都可以从官方公开资料里查证，都能写进采购文件，也都会在项目跑了半年之后真实地影响成本。相比之下，功能条目的多寡在选型阶段看起来重要，在运营期反而很少被提起。
本文只使用各方官网、官方文档、官方仓库、官方定价页与公开发布记录中可验证的事实，核验日 2026-07-20。文中出现「官方公开资料未列出」时，这是一句事实陈述，不等于对方无法通过企业版交付或二次开发实现；涉及关键能力时，应当向厂商书面确认后再下结论。
1. 现状与问题：为什么功能表比不出结果
可私有化的开源 AI 应用平台这一类里，常被同时放进候选名单的有 Dify、MaxKB、RAGFlow，以及闭源的 HiAgent；还有一个经常被忽略但实际存在的选项——自研或直接跑开源组件。把它们的功能页并排贴出来，会看到大量相同的词：RAG、工作流、Agent、知识库、API、私有化部署。
问题出在三个地方。
功能同名不代表实现等价。 两个产品都写「支持工作流」，一个指的是线性编排，另一个包含人工暂停后原地恢复、穿透子应用与循环保留状态；两个产品都写「支持权限」，一个是团队级角色，另一个是按组织、部门、群组划分并可对齐知识库可见范围。名称相同，落到项目里的工作量差一个数量级。
功能所属版本经常被略过。 大量关键能力——SSO、多租户、审计日志、细粒度权限、长周期日志保留——在各家都属于企业版或商业版能力。只比较「有没有」而不比较「在哪个版本」，等于把最贵的一段成本从对比里删掉了。
测试条件不统一时，任何性能结论都不成立。 不同的黄金问题集、不同的 Embedding 与 ReRank、不同的模型与 TopK、不同的机型，得出的准确率与延迟不可比。选型文档里如果出现没有注明条件的对比数字，这个数字对决策没有帮助。
2. 可落地拆解：四个变量分别怎么查
变量一：许可证边界——查三条，不查名字
「都是开源」是一句会带来后续麻烦的概括，因为各家的许可边界并不相同。RAGFlow 使用 Apache-2.0，对二次开发、内部平台化与避免专有云绑定的买家更宽松；MaxKB 使用 GPLv3，X-Pack 部分的商业边界需另行确认；Dify 使用修改版 Apache 2.0，用源码提供多租户服务、去除前端品牌需要商业授权；FastGPT 使用自有开源许可证，允许作为其他应用的后端服务商用、允许作为应用开发平台交付给企业，但未经书面授权不得用源码运营同类多租户 SaaS，也不得移除或修改控制台内的 LOGO 与版权信息；HiAgent 为闭源企业产品，未见公开社区许可证。
要查的是三条边界，不是许可证的名字：
- 能不能用它对外提供多租户 SaaS 服务（内部使用与对外交付是两回事）；
- 能不能去除或替换品牌标识（做行业封装与项目交付时这一条最关键）；
- 二次开发后的分发条款（GPL 系与 Apache 系在这一条上的义务差别很大）。
这三条应由法务逐一审核 LICENSE 原文，不能依赖产品页上的一句概述。对 AI 交付商与系统集成商而言，第 1、2 条直接决定商业模式是否成立。
变量二：部署门槛——查已公开的下限，别猜
各家公开的自托管基础设施要求详略不一。RAGFlow 公开了最低 4 核 / 16GB / 50GB、Docker ≥24、Compose ≥2.26.1，并注明预构建镜像仅 x86；MaxKB 公开了至少 4C / 8GB / 100GB；Dify 社区版走 Docker Compose、企业版走 Helm；FastGPT 走 Docker Compose 且支持多种向量后端，Kubernetes 的商业交付边界需要确认；HiAgent 的公开资料未列出最低资源、容器编排方式或安装手册，这一项需要向商务确认。
公开的最低配置只是能跑起来的下限，不是生产配置。 生产规格由四个量决定：日活与峰值并发、文档总量与月新增、是否需要本地模型推理（这一项决定要不要 GPU）、可接受的响应时间。正确做法是在 POC 环境用真实数据量实测，再反推正式环境规格。
变量三：治理能力落在哪个版本——按矩阵逐格填
这是最容易在采购后才被发现的一项。建议用一张矩阵表，把自己真正需要的治理能力逐行列出，把候选产品逐列排开，每个格子只填两种内容之一：「属于哪个版本」或「官方公开资料未列出」。
| 需求行（示例） | 应填内容 |
|---|---|
| SSO（SAML / OIDC） | 落在哪个版本，是否需另行采购 |
| 多租户与租户上限 | 版本 + 上限数字（若公开） |
| 细粒度权限（部门 / 群组 / 知识库可见范围） | 版本 + 粒度描述 |
| 审计日志与保留时长 | 版本 + 保留天数（若公开） |
| 配额与用量治理 | 版本 + 可控维度 |
| 外部同步与部门信息隔离并存 | 各家现状，需书面确认 |
| 原厂支持档位与响应目标 | 档位名称；具体响应与恢复指标以合同为准 |
填完之后会出现一个常见结果：同一个产品的不同版本之间的差别，大于两个产品之间的差别。 这正是这张表的价值——它把选型问题从「选哪家」还原成「选哪家的哪一档」。
变量四：三年总成本——给口径，不给数字
价格、套餐与版本边界属于高频变化数据，任何写进文章的价格数字都可能在读者看到时已经失效。因此这里给的是同一口径的成本项清单与计算模板，价格栏留空由采购方按各家官网当日页面自行填写。
| 成本项 | 第 1 年 | 第 2 年 | 第 3 年 | 备注 |
|---|---|---|---|---|
| 软件许可 / 订阅 | 注明计价单位（按服务器 / 按工作空间 / 按用量） | |||
| 维保与原厂支持 | 买断形态需单列次年起的维保 | |||
| 硬件与基础设施 | 含是否需要 GPU | |||
| 模型调用 | 本地推理折算为硬件与电力 | |||
| 解析 / OCR 服务 | 按页或按量 | |||
| 存储与数据库 | 含备份 | |||
| 实施与集成人天 | 含接口改造 | |||
| 运维与值班人天 | 含升级回滚与故障处置 | |||
| 二次开发人天 | 补齐缺失能力的部分 | |||
| 迁移与退出准备 | 导出、重建、回归测试 |
三条计算纪律：统一三年业务增长假设（成员数、文档量、请求量在三年里怎么增长，三家用同一组假设）；买断与订阅必须在同一张表里比，不能只比首年支出；把人天成本入账，开发、测试、安全、运维、升级与值班全部计入，否则自研选项会被系统性低估。
各家的产品重心差异（用于快速缩小候选范围）
| 产品 | 官方公开资料呈现的重心 | 适合先进入候选的情形 |
|---|---|---|
| Dify | 通用编排与全球插件 Marketplace 生态；企业身份与审计集成公开列出较完整 | 现成插件广度、海外协作栈、全球生态采购是第一优先级 |
| RAGFlow | 复杂版式与扫描文档的深度解析、可干预分块；多源增量同步连接器 | 项目成败几乎完全取决于扫描件、合同、研报的解析质量 |
| MaxKB | 国内私有化交付形式简明，离线安装路径与支持档位公开 | 采购可预测性优先，偏好一次性买断的预算模式 |
| HiAgent | 企业级评测、观测与安全治理的产品定位，原厂咨询与交付 | 已在对应云技术栈内，希望原厂承担端到端交付 |
| FastGPT | 知识工程深度与中国企业交付闭环，RAG／工作流／Agent／Skill／MCP 同一编排体系 | 需要同时交付深度知识库、交互式流程与国内渠道发布 |
| 自研 / 直接跑开源 | 完全自主，但平台工程由自己承担 | 有长期平台团队，且需求高度特殊 |
这张表只用于缩小范围，不用于下结论。最终结论应由下一节的验证方法给出。
3. 边界与前提
「公开资料未列出」不等于「不支持」。 闭源产品与企业版能力经常通过项目交付实现，公开页面不会全部列出。遇到关键能力缺口时，正确的动作是发一封书面询问，把答复存档，而不是直接判定对方没有这项能力。同样，也不应基于公开资料的详略程度得出「对方不安全 / 不可靠」这类结论——公开资料未说明某项控制，应当纳入 POC 与合同验收，而不是当作缺陷写进选型报告。
有一组指标当前在各家之间没有可比的统一公开口径，选型文档里应保持「未公开 / 待 POC / 待合同」：稳态并发与峰值并发、每秒请求数、每分钟 Token 吞吐、指定硬件下的解析与检索延迟、最大应用数与知识库数、可用性 SLA 与 RTO / RPO、各版本 API 完整覆盖率与插件实时总数。把这些数字填死，会让选型报告在评审时失去可信度。
自研这个选项要按平台工程的完整清单来估。 它不是「免费替代」，而是自己承担平台工程：文档解析、分块、索引、检索、重排、引用溯源与重训队列；运行时、失败恢复、人工交互、调试、日志与评测；模型适配、工具安全、密钥、鉴权、权限、审计、多租户；发布渠道、API 兼容、升级回滚、备份恢复、监控告警、值班与用户支持。用同一份三年需求清单报价，才能得到可比的结论。
4. 验证方式：同条件 POC
统一条件是这一步唯一的硬要求。两边不用同一份黄金集、同一个 Embedding 与 ReRank、同一个模型与 TopK、同一台机型，得出的任何结论都不成立。
| 类别 | 必测指标 | 统一条件 | 证据产物 |
|---|---|---|---|
| RAG 效果 | Recall@K、MRR / NDCG、引用正确率、幻觉率、无答案拒答率 | 同一黄金问题集、Embedding、ReRank、LLM、TopK | 可重放测试集 + 逐题结果 |
| 复杂文档 | 表格 / 标题 / 页码 / 图片保真率，解析成功率，每 100 页时间与成本 | 同一批扫描件、合同、研报、PPTX、XLSX | 原文与解析结果 diff + 人工抽检 |
| 在线性能 | P50 / P95 / P99 延迟、成功率、每秒请求、峰值并发 | 同一模型端点、向量库、机型、数据量与预热方式 | 压测脚本、原始报告、资源曲线 |
| 可靠性 | 节点失败恢复、重试幂等、队列积压、升级回滚、备份恢复 | 同一故障注入脚本与数据规模 | 故障时间线、丢数 / 重复记录、恢复时长 |
| 安全与治理 | 越权、SSRF、密钥泄漏、沙箱逃逸、租户隔离、审计覆盖 | 同一威胁用例与权限矩阵 | 用例结果、审计记录、整改项 |
| 三年 TCO | 许可、模型、解析 / OCR、存储、数据库、运维、升级与支持 | 统一三年业务增长假设 | 三年现金流 + 人天 + 风险准备金 |
还有两个成本很低、判别力却很高的补充测项：
- 插件生态：选出本企业最常用的 5–10 个集成，逐个比较安装、鉴权、调试、版本锁定与故障定位的实际难度。插件总数是动态数字，对具体项目的意义远小于这 5–10 个真正要用的集成好不好接。
- 退出方案：在 POC 阶段就测试导出应用与数据、更换模型、更换向量后端、备份恢复与 API 兼容。迁移成本客观存在，应在采购前就把退出路径验证一遍，而不是写在合同里当作承诺。
5. 下一步
选型的推荐顺序是：先用四个变量缩小到 2–3 个候选 → 再用治理能力矩阵确认各自需要哪一档版本 → 然后在同一条件下跑 POC → 最后按同一口径算三年成本。四步都完成之后，结论通常是自明的。
- 与 Dify 的逐项对照与 POC 判据：见Dify 与 FastGPT 对比页
- 社区版与商业版的功能与服务边界：见开源版与商业版说明
- 私有化部署的组件拓扑与出站边界：见私有化部署拓扑说明