人工智能AI AgentAgent 编排低代码AI 技能RAG【免费下载链接】nexentNexent 是一个开源智能体SDK和平台能够将描述流程的自然语言转化为完整的多模态服务 —— 无需编排无需复杂拖拉拽。基于 MCP 工具生态系统构建Nexent 提供灵活的模型集成、可扩展的数据处理和强大的知识库管理。我们的目标很简单将数据、模型和工具整合到一个智能中心中让任何人都能轻松地将 Nexent 集成到项目中使日常工作流程更智能、更互联。项目地址https://gitcode.com/ModelEngine/nexent点击查看免费下载本文是使用 Helm 部署的 Nexent 平台的升级操作手册覆盖升级前备份、在线/离线升级、数据库自动迁移原理与升级后检查四个阶段。读者将掌握如何借助仓库内置的 deploy/k8s/backup.sh 在不停 Pod 的前提下完成全量 PVC 备份如何通过deploy.sh完成在线快进升级或离线包升级并理解nexent-config主导的 SQL 迁移机制——这是一套可直接照做的低风险升级方案。1. 升级前的总体原则与适用前提本文仅适用于使用 Helm 部署的 Nexent 集群。执行升级前请确认以下几点业务低峰窗口建议在无人使用或业务低峰时段执行尽量缩短升级对用户的影响面。备份前必须停止业务写入包括用户操作、接口请求和定时任务等一切写路径但不需要停止 Pod也不要求缩容。备份脚本不会检测业务写入状态也不会要求输入确认因此停止写入是执行者自己的责任。一致性前提如果复制期间仍有业务写入PostgreSQL、Elasticsearch、Redis 和 MinIO 等组件的数据可能不属于同一时间点备份可能无法恢复。这正是脚本要求先停写、再备份的根本原因。环境前提执行kubectl的本地机器是备份目标必须能够访问目标集群默认 namespace 为nexent应按实际环境调整。需要说明的是本文档配套的 Docker Compose 版本升级流程见 Docker 升级指南本文只讨论 Kubernetes/Helm 场景。2. 升级前检查和备份2.1 备份命令与参数先进入当前正在使用的 Nexent 仓库根目录离线部署则进入上一版已解压部署包的根目录。执行bash deploy/k8s/backup.sh \ --backup-dir /mnt/backup/nexent \ --namespace nexent脚本支持的全部参数如下来自 backup.sh 的 usage 说明参数说明默认值--backup-dir PATH本地存放备份的目录必填无--namespace NAME目标 Kubernetes namespacenexent--help/-h显示帮助信息—脚本还支持环境变量NEXENT_BACKUP_TIMESTAMP格式YYYYMMDD-HHMMSS覆盖默认的 UTC 时间戳用于生成备份目录名k8s-timestamp。2.2 备份脚本的执行流程从源码看backup.sh 的main()依次执行五个阶段每一步失败都会以[ERROR]终止本地环境校验validate_local_environment要求本地已安装kubectl、tar、base64、du、dfkubectl客户端可用且能访问目标 namespace备份目录必须可创建、可写且目标k8s-timestamp目录不存在。发现 PVCdiscover_pvcs列出指定 namespace 中全部 PVC所有 PVC 必须为Bound否则在复制前输出[ERROR]并退出避免静默漏备份。为每个 PVC 定位数据源discover_sources/find_pvc_source为每个 PVC 选择一个完整挂载该卷的运行中容器。源码明确要求挂载点不能使用subPath或subPathExprbackup.sh否则无法保证卷内容完整性。使用自定义existingClaim时脚本按集群中的实际 PVC 名处理不依赖默认组件名称。测量数据量与空间measure_sources/check_space通过容器内du回显每个 PVC 的未压缩数据量和总量通过本地df -Pk检查备份目录可用空间。数据不会压缩因此空间检查按文件原始大小计算。出现[PASS] Pre-upgrade space check passed.表示本地空间充足脚本随后直接开始复制空间不足时会在复制前退出。复制全部 PVCcopy_all_pvcs所有 PVC 复制完成后目录k8s-timestamp.partial才会被重命名为k8s-timestamp并输出[PASS] Backup complete: path。2.3 三种数据复制路径与日志标记复制单个 PVC 时脚本按优先级尝试三种方式见 copy_pvckubectl cp默认优先路径将$pod:$source_path/.复制到本地。kubectl exec ... tar流式传输kubectl cp失败且目标容器包含tar时通过tar -C source -cf - . | tar -C target -xf -流式传输并立即在本地解包不保留 tar 文件。逐文件流式导出MinIO 等精简镜像不包含tar时脚本使用容器内的 Bash 和基础 coreutilsstat、readlink、cat、base64先枚举目录清单区分目录/普通文件/符号链接并记录权限位再通过kubectl exec ... cat逐文件流式导出最后恢复目录与文件权限该路径在文件很多时会更慢。脚本不使用sudo不创建临时 Pod也不生成压缩包或 SHA-256 文件备份内容即文件的原始拷贝。备份目录的最外层使用 PVC 原名例如nexent-postgresql/、nexent-workspace/、nexent-skills/以及已启用监控组件对应的 PVC 名。通过[INFO]查看来源与复制进度只有出现[PASS] Backup complete: path才表示指定 namespace 中的全部 PVC 已复制完成path是实际备份目录。出现[ERROR]时不要使用脚本回显的.partial未完成目录——脚本在异常退出时也会通过trap on_exit EXIT明确提示该目录Inspect but do not usebackup.sh。3. 执行升级3.1 在线升级在能够访问 GitHub 和所需镜像仓库的环境中使用当前 Nexent 仓库执行在线升级。先确认当前分支和目标版本再以快进方式更新不要用未记录的latest代替明确版本git branch --show-current git pull --ff-only bash deploy.sh k8s --defaults --version X.Y.Z--defaults会复用已保存的 Kubernetes 部署配置并跳过交互界面。升级前应确认 deploy/k8s/deploy.options 中的组件、端口策略、镜像源、持久化模式和 namespace 与原环境一致脚本升级时以保存的配置或内置默认值重新生成 Helm values。版本号X.Y.Z应替换为目标版本未显式传入--version时deploy/k8s/deploy.sh 会从backend/consts/const.py的APP_VERSION自动检测。更多在线部署说明参见 Kubernetes 安装部署。3.2 离线升级目标集群无法访问公网镜像仓库时按 Kubernetes 离线部署 下载与集群节点架构匹配的目标版本包复制到能够访问目标集群的管理节点并解压到新目录unzip nexent-version-amd64.zip -d nexent-version cd nexent-version单节点且使用 Docker 容器运行时的集群可直接加载新包镜像并升级bash deploy.sh \ --reuse-from /path/to/previous/nexent \ --load-images \ --defaults \ k8s其他单节点或多节点集群应将新包镜像推送到集群可访问的内部仓库bash deploy.sh \ --reuse-from /path/to/previous/nexent \ --push-images \ --image-registry-prefix registry.example.com/nexent \ --defaults \ k8s离线升级的两个关键参数来自根入口 deploy.sh参数说明--reuse-from DIR复用旧离线包的环境与部署选项。DIR必须是上一版已解压部署包的实际根目录且包含deploy/env/.env会复用旧包的.env、monitoring.env和 Kubernetes 部署选项导入的.env会自动补充当前.env.example中的新变量。仅离线部署包入口可用--load-images部署前从./images加载 Docker 镜像 tar 文件默认关闭--push-images部署前调用 push-images.sh 推送镜像到指定仓库需配合--image-registry-prefix--defaults复用保存配置或内置默认值跳过交互界面ARM64 集群节点应使用对应的arm64包名如nexent-version-arm64.zip。3.3 升级过程中的自动迁移升级时由nexent-config执行数据库自动迁移其他后端服务会等待迁移达到目标状态。这一机制在仓库中有完整的源码实现支撑nexent-config 的 deployment.yaml 设置了NEXENT_SQL_STARTUP_MODEmigrate其启动入口 start-backend.sh 会先执行run-sql-migrations.sh --migrate再启动服务。而 nexent-runtime、nexent-mcp、nexent-northbound、nexent-data-process 等其他后端组件的 deployment 同样注入该变量但使用等待模式由 run-sql-migrations.sh 的--wait轮询nexent.schema_migrations表直到所有迁移文件都达到目标校验和才放行服务启动。迁移执行器 run-sql-migrations.sh 的运作方式详见 deploy/sql/migrations/README.md以 SQL 文件名作为 migration ID将当前文件 SHA-256 校验和记录在nexent.schema_migrations表中包含migration_id、checksum、status、executed_at、app_version、source_file字段。文件按版本感知的文件名顺序sort -V执行无记录的文件执行并记录为applied校验和一致的文件跳过校验和变化的文件重新执行并更新记录。级联重放机制一旦某个文件因校验和变化被重放本次会话中其后的所有文件都会被强制重新执行migration_force_rerun标志见 run-sql-migrations.sh因为前面的破坏性语句如DROP COLUMN可能把 schema 回退到后续文件所补偿的状态跳过会导致数据库不一致。迁移全程通过pg_advisory_lock加锁run-sql-migrations.sh避免多实例并发迁移冲突。deploy/sql/init.sql每次启动无条件执行且不参与级联其语句必须保持幂等。因此文档强调的已合并的 SQL 文件不可修改、改名或删除是一条硬约束当前迁移文件位于 deploy/sql/migrationsv1_merged_migrations.sql、v2.0~v2.7.0各版本合并文件即使只改动注释也会触发级联并重放其后所有文件在大规模合并文件上可能耗时很长。任何变更都应新增独立版本文件如vX.Y.Z_xxx.sql。4. 升级后检查检查指定 namespace 中的 Pod 状态以下示例使用默认 namespacenexentkubectl get pods -n nexent -o wide判断标准通过所有 Nexent Pod 均为Running且 READY 数量符合预期如1/1。继续等待Pod 显示ContainerCreating——此时可能正处于镜像拉取或迁移等待阶段升级脚本本身也会对每个工作负载执行kubectl rollout status ... --timeoutK8S_WAIT_TIMEOUT_SECONDSs默认 600 秒见 deploy/k8s/deploy.sh。不通过Pod 显示CrashLoopBackOff、Error或长时间Pending。此时应结合 Kubernetes 安装部署 中的方法查看kubectl describe pod与kubectl logs定位问题若迁移失败通常需要排查nexent-config的日志与schema_migrations表状态。5. 升级失败时的处理思路如果升级后业务异常需要注意卸载与回滚操作不会自动删除备份数据。仓库的 deploy/k8s/uninstall.sh 支持--release-scope all|infrastructure|nexent精确控制卸载范围并支持--delete-local-data true|false/--keep-local-data控制是否删除本地 PV 数据仅 local 模式生效默认不删除本地数据。升级前由 backup.sh 产生的k8s-timestamp备份目录是恢复数据的唯一可信来源请妥善保管k8s-timestamp.partial目录在任何情况下都不应作为恢复数据使用。6. 升级清单速览阶段关键动作通过标志备份前停止业务写入Pod 保持运行—备份bash deploy/k8s/backup.sh --backup-dir dir --namespace nexent[PASS] Backup complete: path在线升级git pull --ff-only后bash deploy.sh k8s --defaults --version X.Y.Z部署脚本各 workload 就绪离线升级解压新包后用--reuse-from复用旧配置按需--load-images/--push-images部署脚本各 workload 就绪迁移nexent-config执行 migrate其余服务 waitschema_migrations全部达到目标校验和升级后kubectl get pods -n nexent -o wide全部Running且 READY 符合预期赞分享人工智能AI AgentAgent 编排低代码AI 技能RAG【免费下载链接】nexentNexent 是一个开源智能体SDK和平台能够将描述流程的自然语言转化为完整的多模态服务 —— 无需编排无需复杂拖拉拽。基于 MCP 工具生态系统构建Nexent 提供灵活的模型集成、可扩展的数据处理和强大的知识库管理。我们的目标很简单将数据、模型和工具整合到一个智能中心中让任何人都能轻松地将 Nexent 集成到项目中使日常工作流程更智能、更互联。项目地址https://gitcode.com/ModelEngine/nexent点击查看免费下载相关推荐Nexent Kubernetes 集群升级指南从 PVC 备份、在线/离线升级到数据库迁移的完整实战Nexent Kubernetes 集群升级指南从 PVC 备份、在线/离线升级到数据库迁移的完整实战 本文基于 Nexent 官方 KubernetesHAI AgentAI 应用后端前端大模型RAGNexent Kubernetes 升级指南备份、在线与离线升级、数据库迁移全流程Nexent Kubernetes 升级指南备份、在线与离线升级、数据库迁移全流程 本篇导读 本文是 Nexent 零代码 AI Agent 平台在 HelAI AgentAI 应用后端前端大模型RAGNexent Docker 部署升级实战备份策略、在线/离线升级与数据库迁移机制详解Nexent Docker 部署升级实战备份策略、在线/离线升级与数据库迁移机制详解 本文以 Nexent 仓库中的 Docker 升级指南为主体系统讲解从人工智能AI AgentAgent 编排低代码AI 技能RAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/15 17:48:20 · 阅读 1.2k Nexent Kubernetes 升级指南：从 PVC 备份、Helm 在线/离线升级到数据库自动迁移的完整实践
人工智能AI AgentAgent 编排低代码AI 技能RAG【免费下载链接】nexentNexent 是一个开源智能体SDK和平台能够将描述流程的自然语言转化为完整的多模态服务 —— 无需编排无需复杂拖拉拽。基于 MCP 工具生态系统构建Nexent 提供灵活的模型集成、可扩展的数据处理和强大的知识库管理。我们的目标很简单将数据、模型和工具整合到一个智能中心中让任何人都能轻松地将 Nexent 集成到项目中使日常工作流程更智能、更互联。项目地址https://gitcode.com/ModelEngine/nexent点击查看免费下载本文是使用 Helm 部署的 Nexent 平台的升级操作手册覆盖升级前备份、在线/离线升级、数据库自动迁移原理与升级后检查四个阶段。读者将掌握如何借助仓库内置的 deploy/k8s/backup.sh 在不停 Pod 的前提下完成全量 PVC 备份如何通过deploy.sh完成在线快进升级或离线包升级并理解nexent-config主导的 SQL 迁移机制——这是一套可直接照做的低风险升级方案。1. 升级前的总体原则与适用前提本文仅适用于使用 Helm 部署的 Nexent 集群。执行升级前请确认以下几点业务低峰窗口建议在无人使用或业务低峰时段执行尽量缩短升级对用户的影响面。备份前必须停止业务写入包括用户操作、接口请求和定时任务等一切写路径但不需要停止 Pod也不要求缩容。备份脚本不会检测业务写入状态也不会要求输入确认因此停止写入是执行者自己的责任。一致性前提如果复制期间仍有业务写入PostgreSQL、Elasticsearch、Redis 和 MinIO 等组件的数据可能不属于同一时间点备份可能无法恢复。这正是脚本要求先停写、再备份的根本原因。环境前提执行kubectl的本地机器是备份目标必须能够访问目标集群默认 namespace 为nexent应按实际环境调整。需要说明的是本文档配套的 Docker Compose 版本升级流程见 Docker 升级指南本文只讨论 Kubernetes/Helm 场景。2. 升级前检查和备份2.1 备份命令与参数先进入当前正在使用的 Nexent 仓库根目录离线部署则进入上一版已解压部署包的根目录。执行bash deploy/k8s/backup.sh \ --backup-dir /mnt/backup/nexent \ --namespace nexent脚本支持的全部参数如下来自 backup.sh 的 usage 说明参数说明默认值--backup-dir PATH本地存放备份的目录必填无--namespace NAME目标 Kubernetes namespacenexent--help/-h显示帮助信息—脚本还支持环境变量NEXENT_BACKUP_TIMESTAMP格式YYYYMMDD-HHMMSS覆盖默认的 UTC 时间戳用于生成备份目录名k8s-timestamp。2.2 备份脚本的执行流程从源码看backup.sh 的main()依次执行五个阶段每一步失败都会以[ERROR]终止本地环境校验validate_local_environment要求本地已安装kubectl、tar、base64、du、dfkubectl客户端可用且能访问目标 namespace备份目录必须可创建、可写且目标k8s-timestamp目录不存在。发现 PVCdiscover_pvcs列出指定 namespace 中全部 PVC所有 PVC 必须为Bound否则在复制前输出[ERROR]并退出避免静默漏备份。为每个 PVC 定位数据源discover_sources/find_pvc_source为每个 PVC 选择一个完整挂载该卷的运行中容器。源码明确要求挂载点不能使用subPath或subPathExprbackup.sh否则无法保证卷内容完整性。使用自定义existingClaim时脚本按集群中的实际 PVC 名处理不依赖默认组件名称。测量数据量与空间measure_sources/check_space通过容器内du回显每个 PVC 的未压缩数据量和总量通过本地df -Pk检查备份目录可用空间。数据不会压缩因此空间检查按文件原始大小计算。出现[PASS] Pre-upgrade space check passed.表示本地空间充足脚本随后直接开始复制空间不足时会在复制前退出。复制全部 PVCcopy_all_pvcs所有 PVC 复制完成后目录k8s-timestamp.partial才会被重命名为k8s-timestamp并输出[PASS] Backup complete: path。2.3 三种数据复制路径与日志标记复制单个 PVC 时脚本按优先级尝试三种方式见 copy_pvckubectl cp默认优先路径将$pod:$source_path/.复制到本地。kubectl exec ... tar流式传输kubectl cp失败且目标容器包含tar时通过tar -C source -cf - . | tar -C target -xf -流式传输并立即在本地解包不保留 tar 文件。逐文件流式导出MinIO 等精简镜像不包含tar时脚本使用容器内的 Bash 和基础 coreutilsstat、readlink、cat、base64先枚举目录清单区分目录/普通文件/符号链接并记录权限位再通过kubectl exec ... cat逐文件流式导出最后恢复目录与文件权限该路径在文件很多时会更慢。脚本不使用sudo不创建临时 Pod也不生成压缩包或 SHA-256 文件备份内容即文件的原始拷贝。备份目录的最外层使用 PVC 原名例如nexent-postgresql/、nexent-workspace/、nexent-skills/以及已启用监控组件对应的 PVC 名。通过[INFO]查看来源与复制进度只有出现[PASS] Backup complete: path才表示指定 namespace 中的全部 PVC 已复制完成path是实际备份目录。出现[ERROR]时不要使用脚本回显的.partial未完成目录——脚本在异常退出时也会通过trap on_exit EXIT明确提示该目录Inspect but do not usebackup.sh。3. 执行升级3.1 在线升级在能够访问 GitHub 和所需镜像仓库的环境中使用当前 Nexent 仓库执行在线升级。先确认当前分支和目标版本再以快进方式更新不要用未记录的latest代替明确版本git branch --show-current git pull --ff-only bash deploy.sh k8s --defaults --version X.Y.Z--defaults会复用已保存的 Kubernetes 部署配置并跳过交互界面。升级前应确认 deploy/k8s/deploy.options 中的组件、端口策略、镜像源、持久化模式和 namespace 与原环境一致脚本升级时以保存的配置或内置默认值重新生成 Helm values。版本号X.Y.Z应替换为目标版本未显式传入--version时deploy/k8s/deploy.sh 会从backend/consts/const.py的APP_VERSION自动检测。更多在线部署说明参见 Kubernetes 安装部署。3.2 离线升级目标集群无法访问公网镜像仓库时按 Kubernetes 离线部署 下载与集群节点架构匹配的目标版本包复制到能够访问目标集群的管理节点并解压到新目录unzip nexent-version-amd64.zip -d nexent-version cd nexent-version单节点且使用 Docker 容器运行时的集群可直接加载新包镜像并升级bash deploy.sh \ --reuse-from /path/to/previous/nexent \ --load-images \ --defaults \ k8s其他单节点或多节点集群应将新包镜像推送到集群可访问的内部仓库bash deploy.sh \ --reuse-from /path/to/previous/nexent \ --push-images \ --image-registry-prefix registry.example.com/nexent \ --defaults \ k8s离线升级的两个关键参数来自根入口 deploy.sh参数说明--reuse-from DIR复用旧离线包的环境与部署选项。DIR必须是上一版已解压部署包的实际根目录且包含deploy/env/.env会复用旧包的.env、monitoring.env和 Kubernetes 部署选项导入的.env会自动补充当前.env.example中的新变量。仅离线部署包入口可用--load-images部署前从./images加载 Docker 镜像 tar 文件默认关闭--push-images部署前调用 push-images.sh 推送镜像到指定仓库需配合--image-registry-prefix--defaults复用保存配置或内置默认值跳过交互界面ARM64 集群节点应使用对应的arm64包名如nexent-version-arm64.zip。3.3 升级过程中的自动迁移升级时由nexent-config执行数据库自动迁移其他后端服务会等待迁移达到目标状态。这一机制在仓库中有完整的源码实现支撑nexent-config 的 deployment.yaml 设置了NEXENT_SQL_STARTUP_MODEmigrate其启动入口 start-backend.sh 会先执行run-sql-migrations.sh --migrate再启动服务。而 nexent-runtime、nexent-mcp、nexent-northbound、nexent-data-process 等其他后端组件的 deployment 同样注入该变量但使用等待模式由 run-sql-migrations.sh 的--wait轮询nexent.schema_migrations表直到所有迁移文件都达到目标校验和才放行服务启动。迁移执行器 run-sql-migrations.sh 的运作方式详见 deploy/sql/migrations/README.md以 SQL 文件名作为 migration ID将当前文件 SHA-256 校验和记录在nexent.schema_migrations表中包含migration_id、checksum、status、executed_at、app_version、source_file字段。文件按版本感知的文件名顺序sort -V执行无记录的文件执行并记录为applied校验和一致的文件跳过校验和变化的文件重新执行并更新记录。级联重放机制一旦某个文件因校验和变化被重放本次会话中其后的所有文件都会被强制重新执行migration_force_rerun标志见 run-sql-migrations.sh因为前面的破坏性语句如DROP COLUMN可能把 schema 回退到后续文件所补偿的状态跳过会导致数据库不一致。迁移全程通过pg_advisory_lock加锁run-sql-migrations.sh避免多实例并发迁移冲突。deploy/sql/init.sql每次启动无条件执行且不参与级联其语句必须保持幂等。因此文档强调的已合并的 SQL 文件不可修改、改名或删除是一条硬约束当前迁移文件位于 deploy/sql/migrationsv1_merged_migrations.sql、v2.0~v2.7.0各版本合并文件即使只改动注释也会触发级联并重放其后所有文件在大规模合并文件上可能耗时很长。任何变更都应新增独立版本文件如vX.Y.Z_xxx.sql。4. 升级后检查检查指定 namespace 中的 Pod 状态以下示例使用默认 namespacenexentkubectl get pods -n nexent -o wide判断标准通过所有 Nexent Pod 均为Running且 READY 数量符合预期如1/1。继续等待Pod 显示ContainerCreating——此时可能正处于镜像拉取或迁移等待阶段升级脚本本身也会对每个工作负载执行kubectl rollout status ... --timeoutK8S_WAIT_TIMEOUT_SECONDSs默认 600 秒见 deploy/k8s/deploy.sh。不通过Pod 显示CrashLoopBackOff、Error或长时间Pending。此时应结合 Kubernetes 安装部署 中的方法查看kubectl describe pod与kubectl logs定位问题若迁移失败通常需要排查nexent-config的日志与schema_migrations表状态。5. 升级失败时的处理思路如果升级后业务异常需要注意卸载与回滚操作不会自动删除备份数据。仓库的 deploy/k8s/uninstall.sh 支持--release-scope all|infrastructure|nexent精确控制卸载范围并支持--delete-local-data true|false/--keep-local-data控制是否删除本地 PV 数据仅 local 模式生效默认不删除本地数据。升级前由 backup.sh 产生的k8s-timestamp备份目录是恢复数据的唯一可信来源请妥善保管k8s-timestamp.partial目录在任何情况下都不应作为恢复数据使用。6. 升级清单速览阶段关键动作通过标志备份前停止业务写入Pod 保持运行—备份bash deploy/k8s/backup.sh --backup-dir dir --namespace nexent[PASS] Backup complete: path在线升级git pull --ff-only后bash deploy.sh k8s --defaults --version X.Y.Z部署脚本各 workload 就绪离线升级解压新包后用--reuse-from复用旧配置按需--load-images/--push-images部署脚本各 workload 就绪迁移nexent-config执行 migrate其余服务 waitschema_migrations全部达到目标校验和升级后kubectl get pods -n nexent -o wide全部Running且 READY 符合预期赞分享人工智能AI AgentAgent 编排低代码AI 技能RAG【免费下载链接】nexentNexent 是一个开源智能体SDK和平台能够将描述流程的自然语言转化为完整的多模态服务 —— 无需编排无需复杂拖拉拽。基于 MCP 工具生态系统构建Nexent 提供灵活的模型集成、可扩展的数据处理和强大的知识库管理。我们的目标很简单将数据、模型和工具整合到一个智能中心中让任何人都能轻松地将 Nexent 集成到项目中使日常工作流程更智能、更互联。项目地址https://gitcode.com/ModelEngine/nexent点击查看免费下载相关推荐Nexent Kubernetes 集群升级指南从 PVC 备份、在线/离线升级到数据库迁移的完整实战Nexent Kubernetes 集群升级指南从 PVC 备份、在线/离线升级到数据库迁移的完整实战 本文基于 Nexent 官方 KubernetesHAI AgentAI 应用后端前端大模型RAGNexent Kubernetes 升级指南备份、在线与离线升级、数据库迁移全流程Nexent Kubernetes 升级指南备份、在线与离线升级、数据库迁移全流程 本篇导读 本文是 Nexent 零代码 AI Agent 平台在 HelAI AgentAI 应用后端前端大模型RAGNexent Docker 部署升级实战备份策略、在线/离线升级与数据库迁移机制详解Nexent Docker 部署升级实战备份策略、在线/离线升级与数据库迁移机制详解 本文以 Nexent 仓库中的 Docker 升级指南为主体系统讲解从人工智能AI AgentAgent 编排低代码AI 技能RAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考