Nexent AI智能体部署实战：Windows Docker 与大模型环境的 D 盘配置【快速入门与环境准备】

在 Windows 上部署 Nexent，我给自己设定了三个验收目标：Docker 能运行 Linux 容器，镜像和业务数据保存在 D 盘，租户管理员可以登录工作台。最后完成了 v2.8.2 的完整部署，13 个服务处于运行状态，数据处理服务的内部端口也可以从配置服务访问。

本文从安装、拉取代码和初始化配置开始，记录完整命令及对应结果。使用的项目是魔擎社区的 Nexent AtomGit 仓库，接入 DeepSeek 大模型的过程放在系列第二篇。

一、先确定环境和存储位置

1.1 本次实际使用的环境

项目	本机配置
操作系统	Windows 11，构建号 26200.9711
物理内存	约 32 GiB
逻辑处理器	16 个
Docker Desktop	4.99.0
Docker Engine	29.9.3，Linux 引擎
Docker Compose	5.7.0
WSL	3.0.5，Docker 发行版使用 WSL 2
Nexent	v2.8.2

Nexent 官方安装文档给出的最低要求为 4 核 CPU、8 GiB 内存和 40 GiB 磁盘，推荐 8 核、16 GiB 内存和 100 GiB 磁盘。这部分资源用于平台及配套服务，本次调用在线模型 API，没有在本机加载大模型权重。

1.2 为什么程序、镜像和业务数据要分开配置

我最初以为把 Docker 安装到 D 盘就够了。实际检查后发现，安装目录与容器磁盘的位置分别受不同参数控制；Nexent 数据库的挂载目录又是第三项配置。因此，本次分别设置了以下路径：

目录	保存内容	由什么控制
D:\Docker	Docker Desktop 程序	安装参数 --installation-dir
D:\DockerData	镜像层、容器磁盘	安装参数 --wsl-default-data-root
D:\NexentData	数据库、文件存储、日志等	Nexent 参数 --root-dir
D:\NexentWorkspace	用户工作目录	NEXENT_USER_DIR 及部署脚本

这组划分也方便后续核对：程序安装到哪里，看安装路径；镜像存在哪里，看 Docker 设置；数据库数据是否进入 D 盘，看容器挂载。它们不能互相替代。

二、准备 Docker 和 Git Bash

2.1 检查 WSL 并安装 Docker

先在 PowerShell 中检查 WSL：

wsl --version
wsl --status
wsl --list --verbose

本机已经具备 WSL 环境，因此没有重复安装。新环境可按 Microsoft WSL 安装说明完成安装，随后从 Docker 官方 Windows 安装页下载安装包。

在安装包目录打开管理员 PowerShell，指定程序目录和容器数据目录：

Start-Process '.\Docker Desktop Installer.exe' -Wait -ArgumentList `
  'install', '--backend=wsl-2', `
  '--installation-dir=D:\Docker', `
  '--wsl-default-data-root=D:\DockerData'

安装完成后启动 Docker Desktop，等底部状态显示引擎运行，再新开一个 PowerShell。这里要区分客户端与引擎：docker --version 只能证明命令可用，docker info 能成功返回，才说明客户端已经联系到运行中的引擎。

2.2 用一个测试容器验证实际能力

docker --version
docker compose version
docker info --format 'Engine={{.ServerVersion}} OS={{.OSType}}'
docker run --rm hello-world

本次对应的关键输出是：

Docker version 29.9.3
Docker Compose version v5.7.0
Engine=29.9.3 OS=linux
Hello from Docker!

最后一项同时验证了镜像下载、容器创建和程序运行。确认这一步通过，再继续拉取 Nexent，能把基础环境问题和平台部署问题分开。

如果当前终端仍找不到命令，可临时补充本次安装目录：

$env:PATH = 'D:\Docker\resources\bin;' + $env:PATH
docker info

后续 Bash 脚本使用 Git for Windows 提供的 Git Bash 执行。安装入口见 Git for Windows。PowerShell 用于 Windows 检查，Git Bash 用于运行仓库中的 .sh 脚本，每个代码块的语言标签也对应这个分工。

三、从 AtomGit 获取固定版本

在 D 盘准备保存源码的位置打开 Git Bash，执行：

git clone https://atomgit.com/ModelEngine/nexent.git
cd nexent
git fetch origin tag v2.8.2
git checkout --detach v2.8.2
cat VERSION
git rev-parse HEAD

本次版本与提交号为：

v2.8.2
692fafd1c6959318a699af2039610bba8b1940ce

固定标签的理由是让配置模板、部署脚本和应用镜像使用同一版本。后续命令也明确传入 --version v2.8.2，复现时可以对照同一份仓库内容，而不是跟随开发分支持续变化。

四、初始化配置并处理 D 盘工作目录

4.1 创建当前版本的配置文件

首次克隆后，在仓库根目录创建配置：

cp deploy/env/.env.example deploy/env/.env
printf '\nNEXENT_USER_DIR=D:/NexentWorkspace\n' >> deploy/env/.env

已有部署时沿用现有 .env，只调整对应变量。这里使用正斜杠路径，是为了让同一配置在 Git Bash 和 Compose 中更直观地传递。

4.2 修正 v2.8.2 对工作目录的重新赋值

这一点是本次 D 盘部署中实际处理过的细节。在 v2.8.2 的 deploy/docker/deploy.sh 中，准备工作目录时原本会执行：

NEXENT_USER_DIR="$HOME/nexent"

这会覆盖前面配置的用户目录。我将这一行改为：

NEXENT_USER_DIR="${NEXENT_USER_DIR:-$ROOT_DIR/workspace}"

表达式的含义是：已设置 NEXENT_USER_DIR 时沿用它，否则使用持久化根目录下的 workspace。本次因此实际使用 D:\NexentWorkspace。这是针对固定版本的本地调整，不是给其他版本再叠加一套变量。

4.3 选择完整部署组件

bash deploy.sh docker --defaults \
  --components infrastructure,application,data-process,supabase \
  --port-policy production \
  --image-source general \
  --version v2.8.2 \
  --root-dir D:/NexentData

参数	本次作用
infrastructure	启动检索、数据库、缓存和文件存储
application	启动网页、配置、运行时、MCP和对外接口服务
data-process	启动文件处理服务
supabase	启动账户认证相关组件
production	使用生产端口策略，减少内部服务端口的直接发布
general	使用官方通用镜像来源
--root-dir	指定 Nexent 持久化根目录

我在国内镜像源遇到过数据处理镜像标签缺失和下载超时，核对官方同版本镜像可用后，切换到 general。这里保留 v2.8.2，只改变镜像来源，已经成功下载的镜像层也能复用。

五、用状态和挂载确认服务真的启动了

5.1 容器运行状态

docker ps --format '{{.Names}}|{{.Status}}'

本次完整运行列表包含 13 个服务：

nexent-web              nexent-config
nexent-runtime          nexent-mcp
nexent-northbound       nexent-data-process
nexent-postgresql       nexent-redis
nexent-elasticsearch    nexent-minio
supabase-db-mini        supabase-auth-mini
supabase-kong-mini

Redis、Elasticsearch 和 Supabase 相关服务还显示了健康检查结果。需要特别留意的是，日志中的 Pull complete 表示镜像层已准备好，Up 才表示容器正在运行，healthy 则表示该服务定义的健康检查已通过。

5.2 数据是否实际挂到 D 盘

我以 PostgreSQL 为例检查挂载：

docker inspect nexent-postgresql --format `
  '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}'

本次数据目录对应的输出为：

D:/NexentData/postgresql/data -> /var/lib/postgresql/data

这比只查看 .env 更直接：左侧是宿主机数据位置，右侧是数据库容器使用的位置。配置文件表达意图，容器的实际挂载则说明最终执行结果。

5.3 服务之间能否连接

宿主机可以打开网页，还要进一步确认内部服务可以互相访问。本次从配置容器连接数据处理服务的 5012 端口：

docker exec nexent-config python -c "import socket; s=socket.create_connection(('nexent-data-process',5012),5); print('Data process TCP 5012: reachable'); s.close()"

实际返回：

Data process TCP 5012: reachable

这个检查覆盖服务名解析和 TCP 连接。文件解析的业务效果则需要在配置对应模型和资料后进一步验证，两者检查的是不同阶段。

六、从超级管理员进入租户工作台

打开 http://localhost:3000，可以看到 Nexent 中文欢迎页。

首次部署的超级管理员是 suadmin@nexent.com，密码由 NEXENT_SUPER_ADMIN_PASSWORD 决定；v2.8.2 模板默认值为 Nexent@123。超级管理员登录后进入租户资源管理，这个账户负责建立租户和管理人员。

本次创建业务工作空间的顺序是：

1. 点击租户列表旁的加号，输入“魔擎博客实战”。
2. 打开“立即生成租户管理员账户”。
3. 填写租户管理员邮箱、密码和确认密码。
4. 提交后，在该租户的用户列表确认管理员条目。
5. 退出超级管理员，再使用租户管理员登录。

换成租户管理员后，浏览器进入工作台，能够看到新对话和模型选择区域。首次进入时显示“暂无可用模型”，表示平台入口已就绪，下一步是在当前租户中添加模型。

七、这次部署的验收结果和排错入口

检查项	本次结果	对应检查位置
Docker 可以执行容器	hello-world 正常输出	PowerShell
应用版本固定	v2.8.2及对应提交	VERSION、Git
服务完成启动	13个容器运行	docker ps
PostgreSQL数据位置	D盘持久化目录	docker inspect
数据处理内部端口	5012可连接	配置服务容器
账户与租户链路	创建成功并进入工作台	浏览器

后续重启或调整配置时，可以拿这张表逐项对照。故障发生在哪一层，就先检查对应服务：网页打不开先看网页服务，登录失败检查认证服务，文件处理异常再看数据处理服务。

docker logs nexent-web --tail 50
docker logs nexent-config --tail 50
docker logs supabase-auth-mini --tail 50
docker logs nexent-data-process --tail 50

本机还将 WSL 内存上限设为 12 GB，并把 WSL 交换文件和 Windows 分页文件放到 D 盘。它们与 Docker 程序目录是独立设置，分页文件位置在重启后通过系统信息核对。至此，本文开头的三个目标均已完成：容器能运行、主要数据在 D 盘、租户管理员可以进入工作台。

参考文档：Nexent官方安装部署、Nexent使用指南、Docker Windows安装。