企业官网建设流程全解析

上周我把 DeepSeek Harness 部署到了公司内网的一台服务器上，原本只是想自己测试一下，结果不到半天，隔壁组的同事就开始排队问我要账号。一周下来，这台服务器成了团队里最热闹的基础设施，有人拿它写周报，有人拿它调 SQL，还有人把它接进了自己的脚本里做批量总结。说实话，我一开始也没想到效果会这么好，但复盘整个部署过程，我发现这件事能跑通，靠的并不是某个神秘技巧，而是一套清晰的需求拆解和几个关键决策做对了。

为了让你也能顺利复现，我把从需求确认、环境准备、部署配置，到团队接入、问题排查的完整过程整理成这篇记录。里面有我实际敲过的命令、用过的配置，也有踩过坑之后才明白的原理。如果你正打算在公司或自己的服务器上部署一个大模型服务，这篇文章应该能帮你少走不少弯路。

1. 这东西到底是干什么的：先别急着装，搞清楚需求再动手

1.1 我为什么会在服务器上折腾一个“模型套件”

事情还得从一次需求说起。我们团队经常需要处理长文档、生成代码注释、整理会议纪要，之前大家各用各的网页版模型，效率不高，而且很多内部数据不方便往外部平台发。所以我一直想在内网搭一个统一的大模型服务，让同事用起来像访问一个内部网站一样简单。

当时我调研了几个方案，有的偏重对话，有的偏重 API 网关，但配置都比较重，不太适合我们这种小团队。后来我注意到 DeepSeek Harness 这个项目，它的定位很精准：把 DeepSeek 模型（也可以对接其他兼容模型）封装成一套开箱即用的服务，自带 Web 界面、API 接口、用户体系和会话管理。换句话说，它不是一个模型本身，而是一个“套在模型外面的壳”，让模型从命令行玩具变成一个团队可用的基础设施。

这个定位正好卡在我们的痛点上。我不需要从零开发前端和管理后台，也不用自己去写用户认证和接口鉴权，Harness 已经把这些都做了。我要做的，就是把它部署到服务器上，再接上模型后端，然后让同事通过浏览器访问。

1.2 DeepSeek Harness 解决了什么痛点

可能有人会问：直接用官方 API 不就行了，为什么要自己部署一个 Harness？这里有一个关键区别。官方 API 只给你了一个“接口”，你仍然需要自己去写客户端、做界面、管权限。而 Harness 解决的是“如何把模型能力变成团队公共服务”这个问题。

具体来说，它解决了三个痛点。第一是统一入口：以前每个人装不同的客户端、用不同的提示词模板，现在大家访问同一个地址，就有统一的使用体验。第二是权限与数据边界：内网部署可以控制谁能访问、能访问什么模型，敏感数据不出内网，比大家各自把数据贴到外部网页上安全得多。第三是可用性管理：模型挂了、显存满了、并发超了，都能从管理端看到，而不是等同事来抱怨“怎么又卡了”。

所以说，DeepSeek Harness 适合的不是“只想在本地跑个模型看看效果”的个人用户，而是那些想让大模型真正服务一个团队、一个部门，甚至一个小公司的人。它是把“模型能力”转化成“团队生产力”的一座桥。

2. 部署前的准备工作：硬件、系统和方案选型

2.1 服务器硬件怎么选：有卡没卡是两条路

在动手之前，我先把硬件条件摸了一遍。服务器是一台之前闲置的机器，配置大概是这样：CPU 是 16 核，内存 64GB，没有独立 GPU，硬盘还剩 1TB 不到。这个配置跑大模型其实有点尴尬，因为现在主流的大模型推理都依赖显卡，但也不是完全不能跑。

如果你手头有 NVIDIA GPU，比如 3090、4090 或者 A100，那恭喜你，可以直接跑量化后的 7B、14B 模型，体验会流畅很多，还可以支持更多人同时使用。如果是纯 CPU 服务器，也有一条路：选小参数模型，比如 DeepSeek 的量化版 7B 模型，配合足够的内存，依然能跑，只是速度会慢一些，适合对实时性要求不高的场景。

我最终选择了“CPU + 量化小模型 + 并发限制”的路线。原因很简单：不想为了一两次实验就去申请 GPU 资源。而且我们团队的实际场景是“写周报、读文档、改代码”，这类任务对延迟没那么敏感，一句话等 10 秒和等 3 秒，体验差距并没有想象中大。如果你想追求流畅的对话交互，我还是建议至少有一张 24GB 显存的显卡。

2.2 系统环境与软件依赖：我最终选了什么组合

硬件定下来，接下来是软件栈。我预期要装的东西有这么几类：容器运行环境（Docker）、模型推理后端（Ollama）、以及 DeepSeek Harness 本体。为什么用 Docker？因为 DeepSeek Harness 的官方文档提供了现成的镜像，用容器跑能隔离依赖、方便升级，也避免污染服务器上其他服务。

我用的系统是 Ubuntu 22.04 LTS，这算是服务器上最稳的选择之一。Docker 我选择安装 Docker Engine + Compose 插件，因为之后要用 docker compose 来编排 Harness 和 Ollama 两个容器。Ollama 是一个非常好用的本地模型运行工具，一条命令就能下载并启动模型，而且暴露的 API 与 OpenAI 兼容，Harness 可以直接对接。

还需要注意一个细节：服务器的防火墙和安全组要放行 Harness 和 Ollama 的端口。我们内网环境用的是 8080 端口跑 Web 界面，11434 端口留给 Ollama API。这些端口在云服务器上通常需要在安全组里配置，在公司内网则要确保防火墙规则允许访问。

3. 完整部署过程实录：从零到同事能用的每一步

3.1 第一步：安装 Docker 和 Compose 插件

所有东西都是从一个干净的服务器开始的。我先做了一点基础更新，然后安装 Docker。Ubuntu 上安装 Docker 官方源比较快，具体命令也很常规：

sudo apt update sudo apt install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

装完之后把当前用户加入 docker 组，省得每次敲 sudo：

sudo usermod -aG docker $USER newgrp docker

验证一下环境：

docker version docker compose version

这两个命令能打印出版本号，说明 Docker 和 Compose 已经就绪。这一步其实没什么难度，但很多人会忽略加入 docker 组后的重新登录问题，导致后面 docker 命令一直报权限错误。实际上你重新 SSH 连接一次，或者执行 newgrp docker，就能解决。

3.2 第二步：拉取 DeepSeek Harness 镜像并编写 Compose 编排文件

Docker 就绪后，接下来的核心任务是让 DeepSeek Harness 跑起来。我先是按文档把项目仓库克隆下来，里面有现成的 docker-compose.yml 示例：

git clone https://github.com/your-repo/deepseek-harness.git cd deepseek-harness

注意：具体仓库地址以你实际使用的版本为准，我这里用的是一个示意路径。如果你拉不到代码，也可以直接拉镜像，然后自己写 compose 文件。我的做法是参考项目里的配置模板，做了一些精简，最终的 docker-compose.yml 大致长这样：

version: "3.8" services: ollama: image: ollama/ollama:latest container_name: ollama restart: always volumes: - ./ollama_data:/root/.ollama ports: - "11434:11434" harness: image: deepseek-harness:latest container_name: deepseek-harness restart: always depends_on: - ollama environment: - MODEL_PROVIDER=ollama - OLLAMA_BASE_URL=http://ollama:11434 - DEFAULT_MODEL=deepseek-r1:7b - WEB_PORT=8080 ports: - "8080:8080" volumes: - ./harness_data:/app/data

这里有一个很关键的细节：Harness 容器内访问 Ollama，不应该是 localhost，而是服务名 ollama。因为 Docker Compose 会在内部网络里做 DNS 解析，你写 localhost 指向的是容器自己，而不是 Ollama 容器。我第一次部署时就在这里栽了跟头，后面排查了很久才反应过来。

3.3 第三步：配置模型后端，先拉一个能用的模型

在启动整个编排之前，我先把 Ollama 跑起来并下载了模型。虽然 Compose 会在启动时拉起 Ollama，但模型不会自动下载。所以我先单独启动 Ollama 容器，然后再用 docker exec 去拉模型：

docker compose up -d ollama docker exec -it ollama ollama pull deepseek-r1:7b

这条命令会从模型仓库下载 DeepSeek R1 7B 模型。如果网络状况不好，下载时间会很长，我这边大概花了几分钟到十几分钟不等，取决于服务器带宽。下载完成后，可以先用命令行验证一下模型是否正常：

docker exec -it ollama ollama run deepseek-r1:7b "你好，用一句话介绍自己"

如果能正常输出，说明本地模型后端已经通了。这一步非常重要，因为如果 Ollama 这边都不通，接上 Harness 后大概率也是一堆报错。

如果你想用官方的 DeepSeek API 而不是本地模型，那就不需要 Ollama，只需要在 Harness 环境变量里配置 API Key 和接口地址。但我个人建议在内网场景优先用本地模型，原因很简单：数据可控，不会把内部信息发到外部服务。

3.4 第四步：启动完整服务并验证 Web 界面

模型就绪后，就可以把整个栈拉起来了：

docker compose up -d

启动完成后，用 docker compose ps 查看状态。如果两个容器都是 Up，并且没有异常退出，就可以在浏览器里访问服务器的 8080 端口了。如果你是云服务器，记得先配置安全组放行 8080；如果是公司内网，确认防火墙规则没问题。

我第一次访问的时候，页面加载出来了，但输入对话后一直转圈。后来看日志才发现是 Harness 容器解析不到 Ollama 的地址，因为我写的是 localhost。改成 http://ollama:11434 后，刷新页面再试，对话就通了。那一刻还是很兴奋的，毕竟从零到能访问，完全没有写业务代码。

验证通过之后，我立刻做了一轮“自测清单”：多轮对话是否正常、会话刷新后是否还在、是否支持流式输出、并发访问会不会挂。这些都在 Harness 的管理页面或 API 里能测到。确认没问题，我才开始邀请同事体验。

4. 让同事“玩嗨了”的团队玩法：权限、分享与自动化

4.1 用户体系和权限隔离：不再互相干扰

部署完成只是第一步，真正让同事“玩嗨了”的，是 Harness 自带的用户体系。它支持创建多个账号，每个账号的会话记录互不可见。这一点太重要了，如果没有隔离，几个同事同时用，互相能看到对方的提问内容，体验会非常尴尬。

我创建账号的时候按小组来分组，每组用不同的前缀，比如 dev-xxx、ops-xxx、product-xxx。分配权限的时候，也给不同角色设置了不同的模型访问范围。比如产品同事主要用通用对话和总结功能，开发同事可以访问代码生成相关的模型，运维同事则允许调用 API 做自动化脚本。

实际使用中，用户隔离还带来一个额外的好处：每个人都有自己的历史会话，可以随时翻看之前的对话记录。这比大家挤在同一个公共网页里强太多了，更像是每个人都有一个私人的 AI 助手。

4.2 会话分享与协作：把对话变成团队资产

除了基础的用户隔离，Harness 还支持把某个会话分享给团队里的其他人。这个功能看起来不起眼，用起来却很香。产品经理写了一份很长的需求文档，让 AI 帮忙提炼出关键点，生成之后一键分享到团队群，研发同事点开就是完整的上下文，不用自己再重复一遍。

我们后来还形成了一个小习惯：每次项目复盘前，先让 AI 把这一个月的会议纪要、周报汇总起来，生成摘要，然后把摘要会话分享给项目组所有成员。这样大家看的是同一份由 AI 整理的内容，信息对称了很多。这种场景如果靠各自去外部网页提问，完全无法实现。

我觉得这就是“Harness”这个词的精髓：它把模型能力“套”进了团队协作流程里，而不是让每个人孤军奋战。

4.3 通过 API 接入现有工具：从“玩”到“用”

如果说 Web 界面让大家觉得新鲜好玩，那 API 接入就是让团队效率真正起飞的关键。Harness 暴露了一个标准的 REST API，兼容不少工具链。我们做了两件比较典型的事情。

第一件事是接了一个内部的小助手机器人。因为我们企业 IM 支持自定义机器人回调，我在机器人后台配置了 Harness 的 API 地址，同事在群里艾特机器人提问，消息就会转发到 Harness，再把模型回复推回群里。整个过程大概只花了一个下午。第二件事是写了一个简单的 Python 脚本，批量处理历史工单的分类和摘要。以前需要人工读一遍的工单，现在先让 AI 打上标签，再做关键词统计，效率提升非常明显。

需要注意的是，API 接口一定要加访问控制。Harness 本身支持 API Token 认证，我在调用脚本里都配置了 Token，并且把 Token 的有效期设置得比较短，到期再换。千万不要把没有认证的 API 暴露到不可信的网络里，否则别人可以直接调用你的模型服务刷爆资源。

5. 部署过程中的坑：排错与优化实录

5.1 常见问题速查表：这些我都替你踩过了

部署过程中遇到的坑，我整理了一个速查表，希望能帮你省下排查时间。

这张表看着简单，每一条背后都是我实际碰到过的问题。尤其是“重启后数据丢失”这个问题，刚开始我没挂载数据卷，结果容器一删，所有用户会话全没了，同事立刻来找我“讨说法”。后来我加了挂载卷，再配合定时备份，才算安心。

5.2 性能优化：并发、流式输出和显存控制

因为没有 GPU，我一开始对 CPU 推理并发是没什么底气的。16 核 CPU 跑 7B 量化模型，单次请求最快也要几秒，如果多人并发，很容易直接把 CPU 打满，然后大家集体超时。我的解法分两层：外层在 Harness 里设置了最大并发数，比如最多 4 个请求同时处理，多余的排队等待；内层在 Ollama 环境变量里设置 OLLAMA_NUM_PARALLEL 为 2，限制单个模型实例的并行度。

还有一个很实用的优化是开启流式输出。Harness 支持 Server-Sent Events 或 WebSocket 流式响应，这样用户看到的是打字机一样的效果，首字延迟会大幅降低。虽然总耗时没有减少，但体感快了很多，同事普遍反馈比“转圈半天再一次性输出”好太多。

如果你有 GPU，还可以关注一下显存控制。Ollama 默认会根据模型大小占用显存，你可以在启动时设置 OLLAMA_MAX_LOADED_MODELS 控制同时加载的模型数量，避免多模型互相挤占显存。我们目前只有一个小模型，暂时没这个烦恼，但等以后增加模型，这个参数很有用。

5.3 安全加固：访问控制与数据隐私

最后说安全。大模型服务一旦开放给团队使用，就必须认真对待访问控制和数据隐私。我在部署完成后做了一次安全自查，主要包括四件事。

第一，所有服务都绑定在内网地址或经过反向代理，不直接暴露公网。如果确实需要远程访问，我建议在 Harness 前面加一层反向代理并启用 HTTPS，而不是把裸端口映射出去。第二，开启 Harness 的认证功能，所有用户必须登录才能访问，不能让未认证请求直接打到底层模型。第三，限制 API Token 的权限范围，只给脚本需要的模型和接口权限，而不是一把万能钥匙。第四，明确告知同事不要在服务里提交高密级敏感数据，因为虽然模型部署在内网，但数据的存储和日志记录仍然需要管理。

这些措施说起来不难，但它决定了这个服务能走多远。毕竟模型能力再强，如果安全和隐私没有保障，团队管理一关就过不去。

最后再分享一个小技巧

如果你也想在公司内部复刻这件事，我建议你部署完成之后，先不要急着宣传，而是找两三个对 AI 工具感兴趣的同事小范围试用，让他们提需求和反馈。我这次就是因为先让一位产品同事和一位开发同事用了一下午，他们提出“希望会话能分享、希望能接机器人”其实是很真实的需求，我按优先级排好了功能，之后才大规模开放。这样既不会因为一上来就所有人都用导致服务被打爆，也能根据真实反馈优化使用体验。

根据我这一周的观察，DeepSeek Harness 现在已经是团队里使用频率最高的内部服务之一。每天早上打开后台，都能看到昨晚还有人半夜在跑批处理任务。虽然我只是做了一个“搬运”和配置的工作，但看到同事用它节省了大量的重复劳动，还是很有成就感的。如果你也在考虑把大模型能力带到自己的团队里，希望这篇记录能给你一个清晰的路标。