直接上实操。Deepseek Harness 这个工具说白了一句话把你平时折腾 AI 工作流、跑批处理任务、管理提示词、串联各种插件的这套东西统一封装成一个能在服务器上常驻运行的服务。我最初是在本地电脑上用后来发现几个问题特别明显——电脑一关任务就断、想在外面用手机连不上、插件越装越多之后本地环境越来越乱。于是动手把它搬上云服务器顺便把公网访问和鉴权这套东西一并解决掉。整个过程踩了不少坑这里把完整流程、配置逻辑和排查思路一次性写清楚。适合正在用或者准备用 Harness又不想整天开着电脑的人参考。1. 部署前思路为什么非要把 Harness 放到云服务器上1.1 本地跑和云端跑的本质区别先说本地方案的痛点。你在自己电脑上装好 Deepseek Harness用得挺顺手但本质上它还是一个“跟着人走”的本地进程。一旦你的笔记本合上盖子、网络切换、系统休眠任务就断了。更麻烦的是如果你用手机或者其他设备想临时看结果、调参数本地服务根本没暴露到公网连都连不上。上云之后Harness 变成一个 7x24 小时常驻服务不依赖你个人电脑的状态。你唯一需要管的是服务器本身是否正常运行。相当于把原来“你人在哪任务就在哪”的模式改成了“服务器在哪任务就在哪”。这个转变对实际使用体验的影响是巨大的尤其是当你的任务要跑几个小时或者需要定时触发的时候。还有一个容易被忽略的点本地电脑的性能是有限的尤其当你同时跑多个任务、启用大型模型推理插件、或者做批量文本处理时几碰下来本机内存和 CPU 就顶不住了。云服务器的好处是资源独立、可扩展即便入门款配置不够升级配置也就是控制台里点几下的事不用换电脑。1.2 公网访问为什么一定要配鉴权把 Harness 暴露到公网之后很多人第一反应是“我只要能把端口映射出去就行”。这个想法非常危险。Harness 这种工具一旦能被公网访问就意味着任何知道你服务器 IP 和端口的人都有可能尝试连接你的服务接口。如果接口没有做任何鉴权轻则别人可以白嫖你的推理额度重则第三方通过接口操作你的模型流程、读取你的配置信息。更不用说扫描全网 IP 的脚本和工具到处都是你的服务端口开在公网上被扫到只是时间问题。所以我在整个部署流程里把“公网鉴权访问”当作一个独立的必做环节而不是可选项。简单说就是服务可以暴露但必须做到两点一是传输层要加密HTTPS二是应用层要有身份验证Token 或基本认证。这两条都搞定才算是能拿到生产环境用的部署方案。1.3 整体架构与流量路径部署完之后整个访问链路是这样的你的浏览器/客户端 ↓ HTTPS带鉴权头 Nginx反向代理监听 443 ↓ 内部转发 Harness 服务监听 127.0.0.1:某个端口 ↓ 调用 后端模型 API / 插件这个架构里Nginx 干了两件事一是把公网进来的 HTTPS 请求解密后转发给本机的 Harness 服务二是拦截未授权的请求只有通过认证的请求才能到达 Harness。Harness 服务本身只监听本地回环地址不对公网直接开放端口这样即便你忘了开防火墙服务也不会被公网直接摸到。这是很朴素但很管用的一层纵深防御。2. 云服务器与环境准备2.1 服务器选型的几个硬指标部署 Deepseek Harness 并不需要多贵的服务器但有几个硬指标必须注意。首先是系统内存个人使用场景建议至少 2GB如果同时要跑插件和本地模型建议 4GB 起步。我在腾讯云和阿里云都试过入门款2GB 内存跑 Harness 本体加几个轻量插件吃得消但如果启用本地大模型推理类的插件2GB 直接捉襟见肘建议直接上 4GB。其次是 CPU主流的两核就够因为 Harness 本身的逻辑编排不重重的是推理环节而推理大都在远端 API 完成。再次是带宽公网访问如果只是自己用1Mbps 到 3Mbps 带宽足够但如果想让多个协作者同时访问建议 5Mbps 以上不然加载插件列表和页面资源会很卡。磁盘方面系统盘 40GB 起步不要选太小。因为 Harness 的插件、日志、缓存数据会逐渐积累。尤其是日志文件如果不做定期清理几个月下来能吃掉好几个 GB。我踩过一次坑服务器磁盘被日志填满Harness 直接无法写入新数据界面报错还看不出来是磁盘问题排查了半天才发现 df 一看 100%。2.2 系统镜像与基础环境系统选型上Ubuntu 22.04 LTS 是我比较推荐的选择。原因很简单一是 Python 环境和各种依赖包的版本兼容性稳二是社区资料多遇到问题搜得到答案。CentOS 7 也能用但 Python 版本偏老后面装某些插件可能因为依赖版本问题抓狂。Debian 12 也可以用本质区别不大看个人习惯。服务器到手之后先把基本环境刷新一遍。我用的是这套命令sudo apt update sudo apt upgrade -y sudo apt install -y curl git python3 python3-pip python3-venv nginx注意用 python3-venv 而不是直接 pip install --user因为 Harness 的依赖较多直接用系统 Python 环境容易污染而且一旦系统自带的 Python 包被覆盖可能出现意想不到的连锁问题。虚拟环境是隔离风险最简单的手段。2.3 域名解析与防火墙规划如果你只是用 IP 访问可以跳过域名这块。但我强烈建议至少准备一个域名原因不是“好看”而是 HTTPS 证书的签发和管理需要域名。用 IP 也可以签证书但流程繁琐不少而且一些公共 CA 对 IP 证书支持有限。我在实际操作中用的是自己的一个子域名比如 harness.example.com然后在 DNS 服务商那里加一条 A 记录指向服务器 IP。防火墙和资源安全组要在部署前规划好。云服务商的控制台里通常有一个“安全组”或者“防火墙”配置建议只放行以下端口端口用途说明22SSH可用密钥登录不改默认端口的话建议把密码登录关掉443HTTPS公网访问 Harness 的唯一入口80HTTP签发证书时临时使用证书签完可以重定向到 HTTPS不要把 Harness 的原始服务端口比如 3000 或者 8000直接暴露到公网后面我会解释为什么以及怎么把服务做得更安全。3. 安装 Deepseek Harness 的详细步骤3.1 拉取代码并创建虚拟环境官方推荐的安装方式一般是直接拉取 Git 仓库然后通过启动脚本运行。我实际操作时先把仓库克隆到/opt/deepseek-harness这个目录。这样做的目的是把服务和普通用户文件分开路径清晰后续排查日志、备份配置都比较方便。sudo git clone https://github.com/yourname/deepseek-harness.git /opt/deepseek-harness sudo chown -R $USER:$USER /opt/deepseek-harness cd /opt/deepseek-harness python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt这里有个细节如果你在国内服务器上执行 pip install速度可能会很慢甚至超时。可以临时换用国内镜像源比如清华源或者阿里源安装完成后不需要改回。命令示例如下pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple实测下来镜像源能把安装时间从十几分钟压缩到几分钟。但是注意不要全局把 pip 的默认源替换掉因为某些插件依赖的私有包可能在默认源里才有全局替换后反而会有问题。3.2 配置模型接入与初始化安装完依赖之后最核心的步骤是配置模型 API。打开项目根目录下的配置文件比如config.yaml找到模型接入相关的字段。这里以接入 OpenAI 兼容接口为例我们需要填写 base_url 和 api_key。Deepseek Harness 支持很多免费模型基本上只要你想用的模型提供 OpenAI 兼容的 API 格式就可以通过这种方式接入。配置示例model: provider: openai-compatible base_url: https://your-model-endpoint.example.com/v1 api_key: sk-xxxxxxxxxxxxxxxx model_name: deepseek-chat填完之后先做一次本地启动测试确认模型能正常调用再继续往下配置公网。我在第一次配置时因为没有仔细看文档把 base_url 结尾多写了一个/v1导致接口地址变成/v1/v1报了一串 404后来才发现是路径拼接问题。配置模型接入后务必先用命令行测试接口连通性再启动服务不然跑到 Nginx 那一步才发现模型调不通排查范围会扩大好几倍。3.3 以系统服务方式运行 Harness本地测试通过后不要让 Harness 在终端直接前台运行而是注册成 systemd 服务这样即使 SSH 断开服务也能保持运行而且服务器重启后能自动拉起。这是我的 systemd 服务描述文件/etc/systemd/system/deepseek-harness.service[Unit] DescriptionDeepseek Harness Service Afternetwork.target [Service] Useryourusername WorkingDirectory/opt/deepseek-harness ExecStart/opt/deepseek-harness/.venv/bin/python -m app.main Restartalways RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target写好后执行sudo systemctl daemon-reload sudo systemctl enable deepseek-harness sudo systemctl start deepseek-harness这里重点说说Restartalways这个配置。Harness 跑久了偶尔会因为网络波动或者外部依赖超时导致进程退出如果没有自动重启服务就是静默挂掉你人还傻乎乎地以为任务在正常跑。加了自动重启之后即使进程崩溃几秒钟内就会自动拉起来稳定性和感知完全不一样。注意启动时设定绑定地址一定是127.0.0.1不要用0.0.0.0。因为前面的架构设计里公网入口统一交给 Nginx本地服务没必要暴露在所有网卡上。4. 公网访问与鉴权配置4.1 Nginx 反代配置与 HTTPS 证书Nginx 的安装前面已经做了这里直接贴一份我使用的核心配置。先通过 certbot 签发证书。执行sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d harness.example.com证书签发完成后把默认站点配置改成下面这样的反代配置。核心目的有两点一是终止 TLS二是把请求转发给本机的 Harness 端口。server { listen 80; server_name harness.example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name harness.example.com; ssl_certificate /etc/letsencrypt/live/harness.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/harness.example.com/privkey.pem; # 鉴权部分 auth_basic Restricted Access; auth_basic_user_file /etc/nginx/.htpasswd; 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需要额外配置 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }4.2 鉴权方式选型与实操鉴权方式我在实际项目中试过两种一种是 Nginx 的 Basic Auth另一种是应用层的 Token 校验。两种可以配合使用。先说 Basic Auth它其实是 HTTP 协议自带的一种身份验证方式在请求头里带上Authorization: Basic base64(username:password)Nginx 在转发前先检查这个头是否合法。它的优点是配置简单几乎不会有兼容问题缺点是明文传输密码当然配上 HTTPS 后密码是被加密的而且浏览器会弹出原生登录框界面丑但对个人使用完全够用。生成密码文件用下面的命令sudo apt install -y apache2-utils sudo htpasswd -c /etc/nginx/.htpasswd admin执行后会提示输入两次密码然后会在指定路径生成一个包含加密密码的文件。后面如果要加新用户去掉-c参数再执行一遍避免覆盖已有用户。如果要求更精细的权限控制推荐在 Harness 应用层再做一道 Token 校验。很多这类工具都会支持配置一个 access_token 或者类似机制启动时读取环境变量。比如在启动命令前加HARNESS_ACCESS_TOKENyour-random-secret-token然后在 Nginx 里用proxy_set_header Authorization Bearer your-random-secret-token;固定带上这个内部 Token双重保险。外部的浏览器访问时先过 Basic Auth过了之后 Nginx 带上应用认可的 Token 去访问后端后端也校验一次。就算有人绕过了 Nginx 直接访问内网端口因为没有 Token照样被拒。4.3 防火墙细节与端口收敛做完反代和鉴权之后有一个动作经常被忽略就是防火墙的“端口收敛”。云服务商安全组应该只放行 80/443而服务器本机的防火墙如果有 ufw 开着也要做对应配置sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable这里有个细节需要注意Harness 服务的端口 3000在安全组里没放行在 ufw 里也没有放行。但 Nginx 在服务器内部转发请求到 127.0.0.1:3000 是不受 ufw 影响的因为这是发往本机回环地址的流量不经过网络接口。这正是整个架构里“服务不暴露只有 Nginx 出口”的实现原理。我用ss -tlnp验证过监听状态正常情况下会看到类似下面的结果LISTEN 0 4096 127.0.0.1:3000 0.0.0.0:* users:((python,pidxxxx,fd3)) LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:((nginx,pidxxxx,fd6))看到 443 端口监听在所有地址而 3000 端口只监听在回环地址这个状态就是对的。5. 常见问题与排查技巧实录5.1 端口通但页面打不开这个问题我遇到不止一次很多人的第一反应是 Nginx 配置错了或者 Harness 没启动。但实际排查下来最常见的原因其实很简单安全组忘了放行 443 端口。云服务器厂商的控制台安全组规则和服务器内部防火墙是两套独立的机制你在 ufw 里放行了安全组没放行也一样访问不了。排查步骤建议按顺序来先在服务器本机执行curl -k https://127.0.0.1/如果返回正常说明 Nginx 和 Harness 都正常问题出在外部到服务器的路上。再在本地电脑执行telnet harness.example.com 443看网络能否连通。最后登录云厂商控制台检查安全组入站规则确认 443 端口是0.0.0.0/0或者你指定范围内的 IP。按这个顺序排查绝大多数“打不开”问题可以在五分钟内定位。5.2 Basic Auth 弹窗重循环配置了 Basic Auth 之后浏览器访问经常出现一直弹登录框、输对了密码还是继续弹的情况。这个问题一般不是 Nginx 配置的问题而是 HTTPS 和 Basic Auth 混合下浏览器缓存了错误凭据或者 Nginx 返回了 401 但浏览器在刷新时丢失了 Authorization 头。排查方法是在浏览器开发者工具里看 Network 请求的 Response Headers如果看到WWW-Authenticate: Basic realmRestricted Access说明 Nginx 没有收到有效的 Authorization 头。快速解决方案是在 Harness 的响应里加一行头禁用浏览器的缓存这在 Nginx 的 location 里加上proxy_hide_header Cache-Control; add_header Cache-Control no-store, no-cache, must-revalidate;不过大多数情况下我试验后发现是浏览器同一个 base URL 下既有 Basic Auth 又有应用自身的 Cookie导致认证信息冲突。最简单的解决方式就是把应用自身的 Cookie 设置改到子路径或者换个域名比如访问地址用harness.example.com而应用的内部回调用api.harness.example.com让两套认证互不干扰。5.3 日志管理与磁盘占满前面提过磁盘占满的问题这里说说怎么避免。Harness 的日志通常写在项目目录下的logs/文件夹如果你用 systemd 方式运行journald 也会记录一些输出。我在实践中用 logrotate 定期轮转配置文件放在/etc/logrotate.d/deepseek-harness内容如下/opt/deepseek-harness/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }copytruncate这个参数很关键它保证在日志文件还在被进程写入时也能安全轮转先复制内容再截断原文件不会导致进程崩溃。如果你不配置 logrotate那就需要自己写定时任务清理日志但说实话容易忘还是老老实实用 logrotate 一次配好。5.4 插件安装失败或乱码报错Harness 的插件机制比较灵活但正因为灵活插件依赖经常出问题。我常用的几个插件包括 llm-wiki、提示词优化器、AnySearch 搜索插件。这些插件装的时候常见的报错有两类一是 Python 包版本冲突二是 Node 相关依赖没装。前者通常让你所在虚拟环境重建然后逐个安装插件依赖后者需要额外安装 nodejs 和 npm。如果你在安装插件时遇到一串看起来像乱码的编码错误不要慌多半是环境影响变量导致 Python 没有正确识别字符集。在启动 Harness 的 systemd 服务文件里加上EnvironmentLANGen_US.UTF-8 EnvironmentLC_ALLen_US.UTF-8改完执行sudo systemctl daemon-reload sudo systemctl restart deepseek-harness一般就能解决。5.5 免费模型接入后的超时问题接入免费模型虽然成本为零但时常碰到接口响应慢甚至超时的问题。Harness 如果默认请求超时时间很短一个慢响应很容易被判定为失败导致任务中断。我在配置里把超时时间调大了一些比如在模型请求部分设置timeout: 120。同时对于需要调用外部搜索插件的任务务必在本地配置好代理或者确保网络能直连目标搜索引擎不然插件一调用就超时整个任务都会卡死。6. 一些经验总结与进阶建议6.1 部署层面的几个“我踩过坑才懂”的事第一件不要在 root 用户下直接跑 Harness。虽然服务器上为了方便很多人直接用 root但一旦服务有底层漏洞整个系统就被掌控了。我在部署时专门建了一个普通用户然后用 systemd 以该用户身份运行权限隔离非常必要。第二件不要把密钥文件提交到 Git 仓库里。这点听着很基础但我在自己的早期实验项目里就把 API key 直接写进了 config.yaml后来推到远端才发现吓得马上轮换密钥。正确的做法是用环境变量或者独立的.env文件并且把.env加入.gitignore。第三件改动配置之前先把原文件备份。一个cp命令的事但真出了事能省下几小时恢复时间。6.2 后续可以扩展的方向服务跑稳之后可以考虑做几件事来提升体验。一是给服务器挂上定时任务让 Harness 能定时跑一些重复性工作比如每天固定时间生成摘要或执行一次信息搜集任务二是把数据目录挂载到云硬盘方便迁移和扩容腾讯云服务器扩展空间其实就是这个思路把存储独立出来三是配合 AnySearch 插件把搜索能力接入工作流把工具链从“单一对话助手”扩展成“可主动获取信息的工作引擎”。最后再分享一个小技巧把 Harness 的 Web 界面加到手机桌面。用 Chrome 或 Safari 打开你配置好的 HTTPS 地址在菜单里选择“添加到主屏幕”之后就能像打开原生 App 一样快速进入控制台OAuth 和 Basic Auth 的凭据在移动端浏览器里也会被记住。实际用下来这个做法让“出门在外也能查看任务状态”变成了完全无感的操作很方便。
