DeepSeek Harness 从零搭建指南：安装、自定义模型与远程访问全攻略-二趣网

最近 DeepSeek Harness 正式发布后，社区里讨论最多的问题集中在三块：怎么安装、怎么配置自定义模型、怎么让局域网或云服务器上的其他设备也能访问。我特意把从零搭建的完整过程整理成一份可照着操作的指南，覆盖环境准备、安装初始化、配置文件拆解、自定义模型接入、远程访问与安全措施，最后附带高频报错的排查清单。不管你是刚接触 Harness 的新手，还是已经在用但被自定义模型、远程访问折腾过的开发者，这篇文章都值得收藏备用。

1. DeepSeek Harness 是什么，能解决什么问题

DeepSeek Harness 可以理解成一个面向大模型应用的“本地操作台”或“模型编排壳”。它把多个模型 API 的调用、密钥管理、对话界面、会话归档等能力集中到一个统一工具中，让你不需要在多个平台之间来回切换，也不用把 API Key 散落在各种脚本和项目里。

这里先做一层通俗解释：传统开发中，你可能会写 Python 脚本直接调用 OpenAI 兼容接口，然后自己维护对话记录、配置模型参数。当模型越来越多、密钥越来越多、团队里其他人也想用一个统一入口时，这种“手写脚本”的方式就变得很低效。DeepSeek Harness 提供的是一套更完整的封装：你只需要在配置里声明模型端点，在界面或命令行中切换模型，剩下的事由工具统一处理。

它常见的应用场景包括：

个人开发者搭建统一的 AI 对话入口，把 DeepSeek、GLM、Qwen 等多个模型放在一起管理。
团队内部提供一个共享模型网关，成员不需要各自申请和保存 API Key。
需要对模型行为做对比测试时，通过 Harness 快速切换不同模型。
在本地或内网环境搭建 AI 工具链，避免把对话数据直接放在第三方网页中。

需要注意的是，DeepSeek Harness 和 Cursor、Qoder、Trae 这类 AI 编程工具定位不同。后两者更偏向 IDE 功能集成，而 Harness 更接近一个独立部署、独立运行的模型接入与管理服务。不过它们在“自定义模型”的配置逻辑上很相似，核心都是填写 base_url、api_key、model 这三个要素，这个思路后面会展开讲。

2. 环境准备：从 Git 到 Node.js 再到 pnpm

在安装 DeepSeek Harness 之前，需要先确认本机环境是否满足要求。以下工具是这类 Node.js 项目最常见的依赖项，如果你的系统已经安装过，可以跳过对应步骤。

2.1 必需工具清单

工具	用途	检查命令
Git	拉取 Harness 源码仓库	`git --version`
Node.js	运行 JavaScript 服务	`node -v`
npm	Node.js 自带包管理器	`npm -v`
pnpm	高性能依赖管理器	`pnpm -v`

不同版本的 DeepSeek Harness 对 Node.js 版本要求可能不同。从这类项目的通用情况来看，Node.js 18 或 20 是比较常见的基础版本。具体以官方 README 中的 engines 字段说明为准，不要盲目安装最新版，也不要使用过老的版本。

查看版本时，如果提示命令不存在，说明对应工具还没安装。下面是各工具的安装思路：

# 安装 Git（Windows 可下载官方安装包，macOS 可用 brew） git --version # 安装 Node.js（建议通过 nvm 管理版本） nvm install 20 nvm use 20 # 启用 pnpm（Node.js 自带 corepack 时最简单） corepack enable pnpm --version

如果你的 Node.js 版本比较老，没有自带 corepack，可以通过 npm 全局安装 pnpm：

npm install -g pnpm pnpm --version

2.2 配置国内镜像源

国内网络环境下，直接使用官方源下载依赖可能比较慢，甚至出现超时。这里建议把 npm 和 pnpm 的 registry 切换到国内镜像，例如 npmmirror：

npm config set registry https://registry.npmmirror.com pnpm config set registry https://registry.npmmirror.com

切换之后可以验证是否生效：

npm config get registry pnpm config get registry

这一步不是必须的，但如果后续pnpm install长时间卡住不动，优先检查是否与网络源有关。

2.3 准备一个干净的目录

建议专门为 DeepSeek Harness 建立一个工作目录，不要放在系统盘的用户临时目录中，避免后续数据归档、日志文件路径混乱。

mkdir -p ~/workspace/deepseek-harness cd ~/workspace/deepseek-harness

到这里，环境准备部分基本完成。接下来进入安装阶段。

3. DeepSeek Harness 安装与初始化流程

3.1 获取源码

DeepSeek Harness 的安装方式以源码运行或构建为主。第一种方式是直接克隆官方仓库，注意不要从不明来源下载压缩包，避免代码被篡改。

# 克隆官方仓库，将仓库地址替换为官方实际地址 git clone <官方仓库地址> deepseek-harness cd deepseek-harness

如果你是通过发行包或桌面版安装，则不需要克隆源码，直接解压后找到可执行文件即可。但无论哪种方式，核心流程都类似：安装依赖、构建、初始化配置、启动。

3.2 安装依赖

进入项目目录后，安装依赖是第一步。DeepSeek Harness 这类使用 pnpm 管理依赖的项目，通常直接执行：

pnpm install

这一步会根据项目根目录下的package.json和pnpm-lock.yaml拉取所有依赖包。如果遇到权限问题或网络问题，不要直接加--force强行绕过，先排查原因。

安装完成后，可以查看一下项目目录中是否生成了node_modules文件夹，这是依赖安装成功的标志。

3.3 构建项目

很多 Node.js 项目需要先构建，再启动。常见命令是：

pnpm build

如果项目脚本里写的是pnpm run build，执行效果相同。构建过程可能会编译 TypeScript、打包前端静态资源、生成 CLI 工具，所以这一步耗时可能比安装依赖更久。

构建成功后，项目目录下通常会多出dist、build、out之类的产物目录。如果构建失败，先看一眼控制台输出的错误信息，定位到具体的编译错误，而不是盲目重试。

3.4 初始化配置

大多数同类项目提供了初始化命令，用来生成默认配置文件和目录结构。常见的初始化命令模式如下：

pnpm dsh init

执行后，项目根目录下一般会生成.env或config文件。也有的项目采用复制模板的方式：

cp .env.example .env

如果你发现目录下没有.env.example模板文件，可以查看config或docs目录中是否有示例配置。在没有明确模板的情况下，不要随意创建空白配置，避免后续启动时解析报错。

3.5 启动 Web 服务

初始化完成后，启动 Web 界面是验证安装是否成功最直接的方式。很多热词和问题反馈都指向同一个命令：

pnpm dsh web

如果你看到控制台输出类似“Server running at http://localhost:3000”的字样，说明服务已经启动。此时打开浏览器访问本机地址，应该能看到 DeepSeek Harness 的 Web 管理界面。

如果服务没有启动成功，或者页面无法访问，先不要急着删除重装，按第 7 节的排查清单逐步定位问题。高频问题集中在依赖不完整、Node 版本不匹配、端口占用这几类原因上。

3.6 启动模式说明

DeepSeek Harness 这类工具通常不是只有 Web 模式。常见的还有：

CLI 模式：直接在命令行中调用模型，适合脚本化和自动化处理。
服务模式：以守护进程方式在后台运行，适合部署到服务器。
Web 模式：提供浏览器界面，适合交互和日常管理。

具体的子命令名称以官方文档为准。建议先从 Web 模式开始体验，等熟悉了之后再研究 CLI 和后台运行。

4. 核心配置文件深度拆解

安装完成后，最关键的环节是理解配置文件。很多同学自定义模型不生效、远程访问失败，本质上都是对配置项理解不透。

4.1 环境变量文件`.env`

.env文件通常存放服务运行的基础环境变量，包括监听端口、监听地址、数据目录、日志级别等。下面是一个常见结构示例：

# 文件路径：.env（示例） PORT=3000 HOST=127.0.0.1 DATA_DIR=./data LOG_LEVEL=info

逐项解释一下：

PORT：Web 服务监听端口，默认常见是 3000，如果被占用可以改成其他端口。
HOST：服务监听地址。默认127.0.0.1表示只能本机访问；改成0.0.0.0后，局域网或者公网设备才能访问。
DATA_DIR：数据存储目录，对话记录、归档消息、日志一般都会放在这里。
LOG_LEVEL：日志级别，常见有debug、info、warn、error。排错时建议先设置成debug。

需要特别提醒：.env文件一定不要提交到 Git 仓库，尤其是里面包含 API Key 时。建议把.env加入.gitignore。

4.2 模型配置区域

自定义模型的核心配置通常在环境变量中，也会有一部分项目使用独立的模型配置文件。先看环境变量方式的通用结构：

# 文件路径：.env（示例，以官方文档字段为准） MODEL_PROVIDER=deepseek DEEPSEEK_API_KEY=sk-xxxx DEEPSEEK_BASE_URL=https://api.deepseek.com DEEPSEEK_MODEL=deepseek-chat

如果是 JSON 配置文件，常见结构可能长这样：

{ "models": [ { "name": "deepseek-chat", "provider": "openai-compatible", "base_url": "https://api.deepseek.com", "api_key": "sk-xxxx", "enabled": true } ] }

我把上面的 JSON 结构称为“OpenAI 兼容接口的通用配置模板”。不管字段叫什么名字，核心信息就是三件事：接口地址、密钥、模型标识。你只需要在 DeepSeek Harness 的配置界面或配置文件中找到对应的模型区域，把这三类信息填上即可。

4.3 数据目录：对话、归档与日志

对话历史和归档消息通常存放在DATA_DIR指定的目录下。不同版本的文件组织方式可能不同，但常见结构包括：

conversations/：正在进行中的会话。
archives/：已归档的历史对话。
logs/：运行日志。

如果你找不到“归档对话在哪里”，优先去数据目录中找archives或history相关文件夹。不要在没有备份的情况下直接删除数据目录，否则历史对话会全部丢失。

4.4 修改配置后是否需要重启

大部分配置项在修改后需要重启服务才能生效。比如启动时读取的PORT、HOST、API_KEY等，重启后才会重新加载。如果你写了.env文件但没有重启，页面一直显示旧行为，这是很常见的误判。

5. 自定义模型接入实战

DeepSeek Harness 最有价值的能力之一就是自定义模型接入。下面从 OpenAI 兼容协议开始，覆盖 DeepSeek 官方模型、国内主流模型、本地 Ollama 模型三种情况。

5.1 理解 OpenAI 兼容协议

现在国内绝大多数模型服务商都提供了“OpenAI 兼容接口”，也就是说，凡是能调用 OpenAI 官方 API 的程序，只需要换掉接口地址、密钥、模型名，就能接入其他模型。

这个协议的三个关键参数是：

参数	含义	示例
base_url	API 请求的根地址	`https://api.deepseek.com`
api_key	服务商下发的密钥	`sk-xxxx`
model	模型标识符	`deepseek-chat`

DeepSeek Harness 中的自定义模型配置，本质上就是维护这张表的多个条目。

5.2 接入 DeepSeek 官方模型

DeepSeek 官方开放平台提供了 OpenAI 兼容接口。常见接入方式如下：

DEEPSEEK_API_KEY=sk-你的密钥 DEEPSEEK_BASE_URL=https://api.deepseek.com DEEPSEEK_MODEL=deepseek-chat

DeepSeek 官方模型标识符常见的有deepseek-chat（通用对话）和deepseek-reasoner（推理场景）。具体可用模型以开放平台文档为准。

获取 API Key 的流程一般是：注册开放平台账号，创建 API Key，复制保存。注意 API Key 只会在创建时完整显示一次，务必自己保管好，不要发到公开仓库或聊天群里。

5.3 接入国内其他 OpenAI 兼容模型

如果你想把智谱 GLM、阿里 Qwen、月之暗面 Kimi 等模型也接入 Harness，配置思路完全一致：去对应开放平台创建 API Key，找到平台文档中的 base_url 和模型标识符，然后填入 Harness 配置。

下面是一个接入不同服务的通用 JSON 配置示例：

{ "models": [ { "name": "glm-4-plus", "provider": "openai-compatible", "base_url": "https://open.bigmodel.cn/api/paas/v4", "api_key": "你的智谱密钥", "enabled": true }, { "name": "qwen-plus", "provider": "openai-compatible", "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1", "api_key": "你的阿里云密钥", "enabled": false } ] }

上面示例中的base_url是公开的常见服务地址，但各平台可能调整，填写时一定要以你实际使用的开放平台文档为准。如果地址写错，最典型的报错就是 404 或者连接失败。

5.4 接入本地 Ollama 模型

如果你不想把对话数据发送到外部服务商，可以优先考虑接入本地模型，例如通过 Ollama 运行的开源模型。

Ollama 默认会在本机启动一个 OpenAI 兼容接口，地址为：

http://localhost:11434/v1

在 Harness 中新增一个模型，配置如下：

{ "models": [ { "name": "qwen2.5", "provider": "openai-compatible", "base_url": "http://localhost:11434/v1", "api_key": "ollama", "enabled": true } ] }

先确认本地 Ollama 已经拉取对应模型，再在 Harness 中调用。如果 Harness 部署在其他服务器上，localhost需要改成运行 Ollama 的服务器 IP。

5.5 和 Cursor、Qoder、Trae 的配置逻辑做类比

很多读者用 Cursor、Qoder、Trae 时也配置过“自定义模型”，会发现思路很相似：都是填一个 API 地址，填一个 Key，填一个模型名。DeepSeek Harness 本质上也是同一套逻辑，只是它把这些模型统一管理在一个独立服务中，而不是绑定在某个 IDE 里。如果你在 Cursor 中已经成功配置过自定义模型，那么在 Harness 里只需要照搬那三个参数就可以了。

5.6 验证模型是否连通

配置完成后，不要急着打开界面聊天，先用命令行验证接口是否连通。下面是通用的 curl 测试命令：

curl https://api.deepseek.com/models \ -H "Authorization: Bearer sk-你的密钥"

如果返回 JSON 数组，说明密钥有效、网络连通。如果返回 401，说明密钥错误；如果连接超时，说明网络或防火墙有问题。

对于 Ollama 本地模型，可以用：

curl http://localhost:11434/v1/models

这个命令不需要密钥，返回已安装模型列表即表示服务正常。

6. 远程访问配置：局域网、云服务器与安全

远程访问是很多读者的刚需：在办公室电脑上部署 Harness，回家后想在笔记本上访问；或者直接把 Harness 部署到云服务器，让团队成员共用。下面按安全性从低到高展开。

6.1 理解监听地址

默认配置下，Harness 只监听127.0.0.1，也就是只有本机能访问。这是因为127.0.0.1是回环地址，其他设备无法连接。

如果希望局域网内其他设备访问，需要把监听地址改为0.0.0.0：

HOST=0.0.0.0 PORT=3000

注意，0.0.0.0表示监听本机所有网络接口，这意味着局域网内所有设备都能通过你的 IP 访问服务。如果你直接把它放到公网，并且没有加任何鉴权，风险极高。

6.2 局域网访问

修改配置并重启服务后，在本机查看局域网 IP：

# Windows ipconfig # Linux / macOS ifconfig # 或者 ip addr

找到形如192.168.x.x的地址，然后在同一局域网内的另一台设备浏览器中访问：

http://192.168.x.x:3000

如果无法访问，优先检查系统防火墙是否放行了 3000 端口。Windows 系统需要在“高级安全 Windows Defender 防火墙”中添加入站规则，Linux 则检查 iptables 或 firewalld。

6.3 在云服务器上部署

在云服务器上部署时，除了把HOST设为0.0.0.0，还要在云平台的安全组中放行对应端口。不同云厂商界面不同，但逻辑一致：创建一个入方向规则，放行 TCP 端口 3000。

长时间运行时，推荐把服务放到后台，而不是一直挂着终端：

nohup pnpm dsh web > app.log 2>&1 &

使用nohup后，即使 SSH 会话断开，服务也会继续运行。你也可以用 pm2 管理：

npm install -g pm2 pm2 start "pnpm dsh web" --name deepseek-harness pm2 save pm2 startup

pm2 的优势在于进程守护、日志管理和开机自启，适合生产环境使用。

6.4 使用 Nginx 反向代理并开启 HTTPS

直接暴露端口虽然可行，但不够专业，也存在安全风险。更推荐用 Nginx 做反向代理，把域名或子路径转发到 Harness 的本地端口。

# 文件路径：/etc/nginx/conf.d/harness.conf（示例） server { listen 80; server_name your.domain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

如果 Harness 使用了 WebSocket 推送消息，还需要补充 WebSocket 支持：

proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

HTTPS 建议直接配置。现在用 Let's Encrypt 或云厂商提供的免费证书非常方便，配置完成后访问地址变成https://your.domain.com，对话数据在传输过程中会被加密。

6.5 账号鉴权与访问保护

远程访问前，必须确认 Harness 自身是否开启了登录鉴权。如果版本支持账号密码或访问令牌，先把鉴权开启，再考虑暴露到公网。

如果 Harness 自身没有鉴权能力，可以在 Nginx 层加一层 Basic Auth：

# 生成密码文件 htpasswd -c /etc/nginx/.htpasswd your-username

然后在 Nginx 配置的 location 中添加：

auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/.htpasswd;

更严格的做法是配合防火墙做 IP 白名单，只允许公司出口 IP 或家庭宽带 IP 访问。最小权限原则在这里非常适用：能不开公网就不开公网，能加一层鉴权就绝不用裸奔方式。

6.6 使用 SSH 隧道做临时安全访问

如果你只是临时在外面访问一下，不打算把端口暴露到公网，SSH 隧道是最安全的选择之一。

假设你的服务器 IP 是1.2.3.4，在本地机器执行：

ssh -L 3000:localhost:3000 user@1.2.3.4

这条命令会把本地 3000 端口流量转发到服务器的 3000 端口。执行后，本地浏览器访问http://localhost:3000就相当于在服务器本地访问 Harness。关闭 SSH 后，服务就不再对外暴露。这种方式适合临时调试和少量个人使用，不适合作为团队正式入口。

7. 常见问题与排查思路

这一节整理了 DeepSeek Harness 安装配置和远程访问过程中最常遇到的问题，按“现象、原因、处理方式”的思路列出。

问题现象	常见原因	解决思路
`pnpm dsh web`长时间卡住	首次启动需要初始化数据库或构建资源；依赖未装完整	等待 1-2 分钟；检查终端是否有输出；用`pnpm install`重新安装依赖
`pnpm install`慢或超时	网络原因，官方源访问受限	切换 npmmirror 镜像源，再重新安装
Node 版本报错	Node.js 版本过低或过高，与项目要求不匹配	使用 nvm 切换到项目要求的版本
端口被占用	其他进程占用了 3000 端口	Linux/macOS 使用`lsof -i:3000`，Windows 使用`netstat -ano`查看并关闭冲突进程
局域网无法访问	`HOST`未改为`0.0.0.0`；防火墙未放行端口	修改配置并重启；检查防火墙入站规则
远程访问时 Windows 报“无法加载远程访问连接管理器服务 711”	Windows 系统服务异常，与 Harness 本身无关	打开服务管理器，检查 Remote Access Connection Manager 相关服务状态，将其启动或恢复正常
文件删错导致启动失败	删除了`node_modules`、`.env`或数据目录	分情况处理：依赖丢失就重新`pnpm install`；配置丢失则从模板恢复；数据目录丢失只能依赖备份
自定义模型调用报 401	API Key 错误或密钥已失效	去开放平台重新创建密钥，并在 Harness 中更新
自定义模型调用报 404	`base_url`或模型名不正确	核对开放平台文档中的接口地址和模型标识符
修改配置后不生效	服务没有重启	重启 Harness，或清除终端环境变量缓存后再启动
找不到归档对话	数据目录位置不明确	查看`.env`中的`DATA_DIR`，确认`archives`或`history`目录

下面单独说一下几个典型问题。

7.1 卡在`pnpm dsh web`怎么办

这个问题出现的频率最高。建议按下面的顺序排查：

看终端是否还在输出。如果长时间没有新输出，可能是依赖安装未完整。
打开另一个终端，执行ps -ef | grep dsh查看进程是否还在运行。
检查端口是否已经监听，例如lsof -i:3000。
确认是否已经执行过pnpm install和pnpm build，缺少构建产物会导致启动卡住。
如果以上都没问题，把LOG_LEVEL=debug写入.env，重启后查看详细日志。

不建议一遇到卡住就强制结束进程然后反复重装。先看日志，再动手。

7.2 文件删错了导致启动失败

这个问题比较危险，因为不同文件删错的影响范围差异很大：

删掉node_modules：问题不大，重新pnpm install即可。
删掉.env：服务可能使用默认配置启动，也可能直接报错。如果有.env.example，复制一份改名即可。
删掉data目录：对话历史和归档消息会丢失，这是最需要警惕的。

因此，修改或清理前一定要先备份。推荐把整个数据目录定期打包，或者把配置模板纳入 Git 管理。

7.3 Windows 711 服务错误

“无法加载远程访问连接管理器服务 711”这个问题本质上属于 Windows 系统服务异常，和 DeepSeek Harness 的代码没有直接关系。常见原因是 Remote Access Connection Manager 或 Remote Access Auto Connection Manager 服务被禁用或启动失败。

可以在“运行”中输入services.msc，找到相关服务，右键查看属性，启动类型设置为“自动”，然后手动启动。如果仍然报错，可能需要检查系统网络组件是否完整。这个问题对 Harness 本身的运行影响有限，更多是影响系统级远程访问功能。

8. 最佳实践与工程建议

工具安装完成只是开始，真正决定长期使用体验的是配置管理和安全习惯。下面几条建议来自实际部署中比较容易踩的坑。

8.1 密钥管理

API Key 是资产的钥匙，务必谨慎对待。

不要把.env文件提交到 Git 仓库。
不要把 API Key 写在聊天截图、群里、博客代码示例中。
如果怀疑密钥泄露，第一时间去开放平台删除并重新创建。
给不同环境使用不同的 Key，方便审计和撤销。

8.2 数据备份

对话数据在你本地，没有人替你保管。建议每天或每周执行一次备份：

tar -czf harness-backup-$(date +%Y%m%d).tar.gz data .env

把备份文件复制到独立的存储位置。对于生产环境，可以写一个定时任务自动执行。

8.3 升级流程

DeepSeek Harness 更新节奏较快，升级时不要直接删目录重装。推荐顺序：

git pull pnpm install pnpm build pnpm dsh web

升级前先备份数据目录和配置文件，升级后先验证核心功能，再决定是否让团队成员正式使用。

8.4 远程安全

再次强调：不要直接暴露公网端口。

推荐的生产部署组合是：

Harness 只监听127.0.0.1。
Nginx 作为唯一对外入口。
HTTPS 加密传输。
Basic Auth 或 Harness 自身登录鉴权。
云安全组设置源 IP 白名单。

这样做的好处是，即使 Harness 本身存在安全漏洞，攻击者也需要先突破 Nginx 层和系统层，风险大幅降低。

8.5 日志与监控

遇到问题不要只看屏幕输出。把日志级别设置成info，并定期检查日志文件。

如果部署在云服务器上，可以考虑接入简单的健康检查，定时请求 Harness 的首页地址，返回异常时发送告警。一个小脚本就能完成：

#!/bin/bash curl -fsS http://127.0.0.1:3000 > /dev/null || echo "Harness down!"

8.6 资源占用控制

本地模型和 Web 页面都会占用内存。如果服务器配置不高，避免同时启用太多模型，也不要无限增加并发会话。监控工具推荐最简单的方式：

top free -h

发现内存持续偏高时，优先检查是不是本地模型加载了过多参数，或者是否存在未被关闭的会话连接。

9. 总结与后续学习方向

如果你能从零完成 DeepSeek Harness 的安装，成功配置自定义模型，并让局域网或服务器上的其他设备正常访问，那这套工具的日常使用基本就没有障碍了。本文重点内容可以概括成三条主线：

安装链路由 Git、Node.js、pnpm 组成，卡住时优先看版本和镜像源。
自定义模型的本质是配置好 base_url、api_key、model 三要素，无论是 DeepSeek、GLM、Qwen 还是 Ollama 本地模型，思路一致。
远程访问必须重视安全，不要直接裸奔公网，推荐 Nginx 反向代理加 HTTPS，加上访问鉴权和防火墙白名单。

接下来可以继续深入学习的方向包括：OpenAI 兼容协议的更多细节、Prompt 工程、本地模型量化部署，以及使用 Docker 或 Docker Compose 将 Harness 容器化部署。容器化之后，环境一致性会更好，升级和迁移也方便很多。

建议你把这篇文章保存下来，安装或升级时按清单操作，会少踩很多坑。如果遇到文中没有覆盖的报错，最好带着完整的日志信息去官方仓库的 Issues 区查找，也可以把报错内容整理后发在评论区，大家互相交流解决办法。

企业官网建设流程全解析