结论：已有 Classic Knowledge 工作流的团队，先继续运行，不要因为 Dify 1.18.0 发布就迁移；KnowledgeFS 是可选 Beta，包含独立服务与数据库。
本周建议： Community Edition 先核实官方支持范围、镜像可获取性和显式启用条件，只做隔离试用，不把它作为生产知识库的默认迁移目标。
正在运行 Dify Community Edition 并准备升级的开发者，可据此判断是否需要改动现有部署。
维护企业知识库的技术负责人，可评估 Agent 知识空间对服务边界和数据流程的影响。
规划自托管资源的团队，可分别核算 Dify 平台、知识服务与模型推理。
最后更新于 2026 年 10 月 26 日；核实依据包括 Dify 官方 1.18.0 发布说明、部署配置及截至当日的社区 Issue。社区提问只代表用户报告，不等同于官方支持结论。
Dify Agent Knowledge Base 与原知识库的边界
Dify 1.18.0 将 Agent Knowledge Base 标为 Beta。官方说明的能力包括建立供 Agent 使用的知识空间、管理文件或连接的数据源、查看文档处理和元数据、追踪检索过程及评估质量；Agent 集成与 Knowledge Retrieval 节点可使用受访问控制的 KnowledgeFS 空间。Classic Knowledge 仍然可用，两者不是新旧版本的强制替换关系。(Dify 1.18.0 发布说明)
因此，Dify Agent Knowledge Base 和原来的知识库，主要差别在使用场景与管理方式：前者面向 Agent 的知识空间及相关检索工作流；后者是既有知识库流程。现有 RAG 链路已经稳定、没有空间管理或检索追踪方面的新需求时，升级平台并不自动构成迁移理由。
迁移决策还要看应用绑定和访问控制。新功能的空间、权限与工作流接入都需要实际验证；若把尚未验证的检索节点直接接入生产 Agent，故障影响的就不只是新界面，还可能包括已有业务问答。
⚠️ 发布说明提到 Classic Knowledge 继续可用，但这不代表每种 Edition、部署方式或 Agent 场景都能以相同方式调用旧知识库。迁移前要以对应版本的实际功能和文档为准。
KnowledgeFS 可以在 Community Edition 自托管吗？
答案要分成“配置上能否启用”和“生产上是否已有明确支持路径”。1.18.0 官方 Compose 默认不启用 KnowledgeFS；本地 Community Edition 需要显式的社区开发选项。官方还要求配置 KnowledgeFS 独立服务、数据库、迁移和验证材料，不能把它当成开启一个普通功能开关。(Dify 1.18.0 发布讨论)
镜像是另一道门槛。官方部署说明将默认镜像描述为由 CI 发布的部署分支镜像，并说明若镜像仓库为私有，需要在主机完成认证；1.18.0 的配置示例也注明默认 KnowledgeFS API 镜像为 Linux AMD64。这意味着架构兼容与镜像拉取权限都应先验证，不能只因 Compose 文件里有服务定义，就认定所在环境可以直接上线。(Dify Docker 部署说明)
社区在 2026 年 10 月 24 日提交了 Issue，报告其 Kubernetes / Helm 环境无法拉取默认镜像，并询问 Community Edition 的支持范围和版本化镜像计划。该帖是用户报告和待答疑问，不证明镜像对所有用户都不可用，也不代表官方已经宣布不支持。遇到类似情况，应向官方发布说明或部署指南核对，不要把单个用户的拉取结果写成产品结论。(社区 Issue：KnowledgeFS 镜像与支持路径问题)
第一步：先判断这次试用要验证什么
如果需求只是让已有 Agent 使用当前 Classic Knowledge，先验证现有链路能否满足要求；不要把 KnowledgeFS 当作通用的升级必选项。若新需求明确依赖知识空间管理、检索追踪或新的空间权限边界，再进入独立试用。
随后确认三个边界：企业数据能否进入对应的模型服务；Agent、知识空间和工作流的访问权限如何分配；新增服务出错时是否能切回现有应用路径。数据边界也应与组织的隐私制度一致，并分别评估 Dify、对象存储和模型 API 的数据处理方式。
独立服务与数据库会增加哪些运维责任
KnowledgeFS 不是“多占一点 Dify 内存”这么简单。官方配置要求为 KnowledgeFS 配置专用环境和数据库连接，并执行相应迁移；部署文件还将其服务配置单列。服务启动成功，不等于功能流量已经启用，也不等于恢复方案已经就绪。(官方 Docker Compose 配置)
要特别留意四种隐性成本：
- 状态拆分： Dify 应用数据库与 KnowledgeFS 数据库不是可随意混用的同一份状态。备份与恢复要分别覆盖，并演练一致性。
- 镜像和架构： 默认配置指向部署分支镜像；镜像能否拉取、是否固定到可审计版本、运行架构是否匹配，都需要现场确认。(KnowledgeFS 环境配置示例)
- 功能与运维状态不同： 服务健康检查不等于知识检索、权限绑定和工作流调用都正常。上线验收要跑实际查询与故障回退。
- 资源不能靠猜： 新服务、数据库、文档处理和向量检索会带来额外负载，但官方发布资料没有给出适用于所有生产负载的统一内存门槛。按文件量、处理并发、检索时延目标和实际监控做容量测试，不要把其他 Dify 部署的数字照搬过来。
Dify 仓库的快速启动说明给出 CPU 至少 2 核、内存至少 4 GiB，这是基础启动参考，不是 KnowledgeFS 生产配置、更不是高并发知识库容量保证。(Dify 仓库快速启动说明)
已有知识库升级后是否要迁移？
通常不需要。官方说明明确 Classic Knowledge 仍然可用；是否迁移应由需求决定，而不是由版本号决定。对既有系统，先保持原知识库与 RAG 工作流，再建立一套隔离的 KnowledgeFS 试验空间，比较检索结果、权限行为和回滚过程。
需要独立服务和数据库吗？ 需要按独立依赖来规划。Dify 的 1.18.0 部署资料要求为 KnowledgeFS 配置独立数据库与迁移；专用 worker 配置也提醒，不要把数据库连接指向 Dify 应用数据库。worker 镜像还必须包含对应引擎，标准 Dify API 镜像不包含该引擎。
这对恢复设计有直接影响：只备份 Dify 主库，并不能证明 KnowledgeFS 可完整恢复。上线前要确认两边数据库、实际文件存储和配置密钥的恢复顺序，并在隔离环境走完恢复演练。不要把这当作旧版 Weaviate 迁移教程；本篇讨论的是是否启用新的知识空间能力。
Cloud、Enterprise 与 Community Edition 不能共用一张支持结论
不同 Edition 和托管形态的可用时间、镜像权限及支持范围要分别核实。1.18.0 发布说明当时写的是 Agent Knowledge Base “即将”在 Cloud 提供；这句话不能被改写成 Cloud 已全面开放。Enterprise 部署也应向对应支持渠道确认功能、版本和运维责任，不能把 Community Edition 的开发选项当作企业生产支持承诺。
下面按决策场景对照。评分仅用于辅助排序：5 分代表更适合该场景，1 分代表较不适合；这是本文的决策评分，不是官方产品评分。
| 团队现状 | 建议路径 | 评分 | 主要依据 |
|---|---|---|---|
| Classic Knowledge 与 RAG 工作流稳定 | 保留现有知识库，暂不迁移 | 5/5 | Classic Knowledge 仍可用；新功能属可选 Beta |
| Agent 明确需要知识空间管理或检索追踪 | 建立隔离试用，验证后再定 | 4/5 | 功能目标匹配，但需要单独服务与数据库 |
| Community Edition，生产知识库不可中断 | 暂缓接入生产，先核实支持与镜像 | 2/5 | 官方要求显式启用；镜像、架构与支持路径需确认 |
| Enterprise 或 Cloud | 按 Edition 与当前公告确认 | 需确认 | 发布说明、租户可用性和部署条件可能不同 |
第二步：按模型调用方式拆开资源账
Dify 平台负责应用编排；KnowledgeFS 承载新的知识空间相关服务；模型推理则由所选模型服务承担。三类资源不应混成一个“Dify 要多少服务器”的数字。
若模型调用外部 API，服务器仍要承担 Dify 服务、数据库、文档处理与检索等任务，但不应把外部模型的推理计算量算进本机 CPU 预算。需要同时评估的是：哪些文档内容或检索片段会发送到模型服务、哪些数据留在自有存储，以及 API 调用失败时业务如何降级。
若打算在本机做 CPU 推理，则另行验证模型参数量、量化方式、上下文缓存和内存预算。NodeKVM 提供的是 AMD 物理服务器，不提供 GPU；因此它适用于平台和 CPU 能承载的服务负载，不应被当作训练或高并发大模型推理方案。
准备试用或上线时按清单逐项验收
以下清单按“需求匹配—支持确认—依赖准备—数据恢复—上线验证”的顺序执行。任一关键项无法确认，就先停在隔离试用，不要把新知识空间接入生产流量。
- [ ] 写下必须使用 KnowledgeFS 的具体功能，并确认 Classic Knowledge 无法满足的部分。
- [ ] 核对所用 Edition、部署方式和版本是否有对应官方说明；Community Edition 特别确认显式启用条件。
- [ ] 从当前官方配置核对 API 与 worker 镜像地址、标签、仓库权限和 CPU 架构，避免用未固定的镜像直接承载生产任务。
- [ ] 单独准备 KnowledgeFS 数据库、迁移计划与密钥管理；确认没有误指向 Dify 应用数据库。
- [ ] 分别备份应用数据库、KnowledgeFS 数据库与文件存储，并在隔离环境验证恢复。
- [ ] 用测试知识集检查文档处理、检索结果、Agent 绑定、权限隔离与故障回退；监控确认稳定前不切生产流量。
NodeKVM 服务器资源与方案对照
选择服务器时，应先按现有平台与检索负载估算 CPU、内存、磁盘和网络，再决定是否需要长期独享资源。官方基础启动参考的 4 GiB 内存不是生产知识库门槛；实际预算应以服务组合、文档规模、运行监控和恢复余量为准。
NodeKVM 当前产品表列出 AMD EPYC 7543P、32 核 / 64 线程，内存可选 128 GB 或 256 GB；两档均配有 2 × 1 TB NVMe 直连盘、250 Mbps 带宽及 1 个 IPv4。基础月租分别为 $465 和 $592；选配、计费周期与系统费用以当前价格表为准。
| 资源项 | 128 GB 方案 | 256 GB 方案 | 对 Dify 规划的意义 |
|---|---|---|---|
| CPU | AMD EPYC 7543P，32 核 / 64 线程 | AMD EPYC 7543P，32 核 / 64 线程 | 可规划平台服务、数据库和文档任务并行；实际容量仍需压测 |
| 内存 | DDR4-3200 ECC RDIMM，128 GB | DDR4-3200 ECC RDIMM，256 GB | 为多服务与缓存预留空间；下单时选档，不能后续加内存条 |
| 磁盘 | 2 × 1 TB NVMe 直连 | 2 × 1 TB NVMe 直连 | 两盘合计可用容量按直连盘规划，不是 RAID-1 镜像；需另做冗余与机外备份 |
| 网络与 IP | 250 Mbps、不限流量；1 个 IPv4 | 250 Mbps、不限流量；1 个 IPv4 | 适合持续拉取镜像、模型文件与服务访问；需更高带宽或额外 IP 时按产品表加选 |
| 基础月租 | $465 | $592 | 适合按实际服务组合核算，不代表包含 KnowledgeFS 部署或运维 |
| 计费与位置 | 月付、季付、半年付、年付；日本东京 | 月付、季付、半年付、年付；日本东京 | 长周期按月租乘周期月数；以当前产品表的实际应付为准 |
免费系统包含 Debian、Ubuntu、AlmaLinux、CentOS Stream 和 Proxmox VE 等产品表列出的选项；Linux 通过 SSH 接入。订购前核对当前可选版本、带宽、额外 IPv4 与计费周期，不要将服务器配置误读为 NodeKVM 预装或已验证 KnowledgeFS。
第三步：把内存预算落到实际服务组合
| 负载组合 | 预算方式 | 选型判断 |
|---|---|---|
| Dify 平台 + 现有知识库 + 外部模型 API | 以平台、数据库、向量检索、文档处理及系统余量的实测占用相加 | 没有测量数据前，不用官方启动下限代替生产估算 |
| Dify 平台 + KnowledgeFS 独立服务与数据库 | 在前项基础上，加入独立数据库、知识处理与 worker 的实测占用 | 先隔离测试并记录峰值，再判断 128 GB 是否留有运行与恢复余量 |
| 上述服务 + 本机 CPU 模型推理 | 再纳入模型权重、量化方式、上下文缓存及推理时的系统占用 | 先做模型适配与吞吐验证；训练或高并发推理不作为本方案目标 |
这张表是预算方法，不是内存保证值。若当前服务在共享 VPS 上受到资源争抢、CPU 超售或磁盘和带宽限制，新增 KnowledgeFS 还会让排障边界更复杂；而独享物理机也不会自动解决镜像、数据库迁移和权限设计问题。只有团队确实需要稳定长期运行、多服务并行及更明确的硬件资源边界时，独享 AMD 物理服务器才更值得比较。临时试用、负载很轻或需要按小时弹性伸缩的任务，继续使用现有方案往往更合适。
若已确认 KnowledgeFS 的版本、镜像、Edition 和恢复流程，且团队需要长期独享 CPU、内存与 NVMe 资源，可结合 NodeKVM 当前价格表核算适合的服务器档位；这只是硬件资源选择，不构成功能兼容承诺。需要先确认产品配置或接入事项时，可通过NodeKVM 帮助页面核对，再决定是否将试验环境迁入独享 AMD 物理机。