企业官网建设流程全解析

Docker 部署 DeepSeek Harness，这个词组拆开看，每个单词你都认识，但合在一起到底是个什么东西，我第一次看到的时候也愣了几秒。简单说，它就是一套帮你在本地把 AI Agent 运行时平台跑起来的环境容器。装好以后，你不光能通过网页和 DeepSeek 模型对话，还能给它配工具、配记忆、让它按流程干活，甚至同时调度好几个 Agent 协作完成同一个任务。

我看这段时间社区里问 AI Agent 怎么落地、Docker 部署怎么搞的人特别多，每天都有新入坑的朋友在各种群里贴报错日志。这篇文章就是把我自己搭建 DeepSeek Harness 的整个过程，从环境准备、镜像选择、部署踩坑到第一个 Agent 真正跑起来，完整地梳理一遍。适合谁看？手头有 DeepSeek API Key、想跳过各种 Python 依赖地狱、直接体验 Agent 编排的人；也适合团队想快速搭一套内部可复用的 AI Agent 实验环境的同学。

1. DeepSeek Harness 到底是什么，为什么值得用 Docker 来跑

1.1 从“能回答”到“能干活”，中间差了一个运行时平台

很多人第一次接触大模型，都是先用网页聊天框或者 API 调几个接口，问两句“你是谁”“今天天气怎么样”。但真正到项目里用的时候，你会发现光有对话能力远远不够。你要让模型记住上下文，要让模型去调用数据库、执行代码、查外部接口，还要把多次操作的中间结果保存下来，最后按一个流程把任务跑完。这些能力组合在一起，才叫 Agent。而 DeepSeek Harness 干的正是这件事：把模型、工具、记忆、任务编排这些东西装到一个统一的环境里，让你不用从零开始写调度框架。

用一个生活化的类比，代码仓库里的模型接口相当于一个手艺人，手艺虽然好，但你需要给他一个工作台，上面摆好工具箱、材料盒、图纸架，他才能真正产出东西。Harness 就是那个工作台。它解决的核心痛点是，让“模型能力”和“业务使用”之间那道工程鸿沟变浅，你不用再自己维护一大堆 Agent 状态、上下文窗口、工具注册表之类的底层逻辑了。

1.2 为什么选择 Docker，而不是直接在宿主机上跑服务

一开始我也嫌 Docker 麻烦，觉得多一层封装没必要。但实际跑了几次之后，我彻底改变了看法。直接在这个领域做 Agent 开发，依赖环境非常容易把机器搞乱。Python 版本、Node 环境、向量数据库依赖、模型服务 SDK，每一层都有各自的版本怪癖。装到最后，经常出现“在我机器上明明是好的”这种经典场景。

所以我最终选了 Docker Compose 这个方案。理由很简单：第一，环境隔离。镜像把运行时依赖全固化在里面，宿主机哪怕是个刚装的系统，也能一条命令拉起来。第二，可重复。团队里任何一个人拿到 compose 文件和环境变量样例，都能复现出和我完全一致的运行环境。第三，重置成本低。Agent 场景下实验性很强，配置改坏了、数据写乱了，直接把容器删了重建就行，不用怕把宿主机的文件搞坏。这套思路，在做 AI 相关的私人项目或者小团队内部平台时非常实用。

提示：如果你对容器基础还不太熟，先分别理解两个概念就够用了：镜像相当于一个打包好的运行环境模板，容器是这个模板的一次运行实例。后面所有的操作都是围绕实例展开。

2. 部署前必须想明白的三件事

2.1 模型从哪来：官方 API 还是本地模型方案

DeepSeek Harness 本身不生产模型，它需要连接一个模型服务。这里有三条路可以走，我用表格列一下，方便你根据自己的情况选：

我个人建议第一次先走官方 API，原因非常实在：省时间。本地部署模型不只是下载权重那么简单，CUDA 版本、显存占用、上下文长度限制，每个点都可能让你卡一整天。而 DeepSeek Harness 的设计核心是把中间层做得很轻，你先用官方 API 验证 Agent 流程能不能跑通，之后再考虑要不要换成本地模型。

2.2 docker run 与 docker compose，我为什么推荐后者

部署方式上，官方文档通常两种都给了，但我强烈建议用 Docker Compose。你可以理解为，docker run 相当于临时在便利店买瓶水喝完就走，docker compose 则是把整个购物清单写成固定菜单，随时可以按菜单重新上菜。

在实际部署 DeepSeek Harness 的时候，环境变量往往不止一个。模型服务的地址、API Key、超时配置、数据持久化路径，这些参数如果都在一条 docker run 命令里塞进去，阅读和修改都很痛苦。而 compose 文件把这些参数集中管理，还能统一处理端口映射、卷挂载和容器启动依赖。另一个隐藏的优点是版本管理，compose 文件可以放进 git，哪天手滑改坏了，回滚一条 commit 就恢复了。

2.3 端口和数据目录规划

很多新手在这里踩坑。Harness 默认的 Web 端口是 8080，你要是机器上已经跑了别的服务占着，端口冲突就会导致启动失败。我建议动手之前先执行一条检查命令，看端口是不是被占用。检查命令很简单，不同系统略有差别，但思路一致，先确认再动手。

# Linux / macOS lsof -i :8080 # Windows PowerShell netstat -aon | findstr "8080"

数据目录我习惯放在宿主机的一个固定位置，比如/opt/deepseek-harness下，里面再分data、config、logs几个子目录。这样容器删了重建，Agent 的配置、历史会话记录、日志都还在，不会因为容器生命周期而丢东西。别小看这一步，后面你一定会感激当初没把数据全丢容器里。

3. 完整部署流程：一行命令拉起整个环境

3.1 准备目录并编写 compose 配置

先创建目录结构，我直接用命令来演示。这段是标准的 Shell 命令，按顺序执行即可。

mkdir -p /opt/deepseek-harness/{data,config,logs} cd /opt/deepseek-harness

接着在目录下新建一个docker-compose.yml文件。我贴一个我自己在用的基础版本，里面已经做好了端口映射、数据卷挂载和基础环境变量配置。你复制的时候注意，不同版本镜像的环境变量名可能略有差异，我这是当前主流发布版的实际写法。

services: deepseek-harness: image: deepseek/harness:latest container_name: deepseek-harness restart: unless-stopped ports: - "8080:8080" environment: TZ: Asia/Shanghai DSH_MODEL_PROVIDER: "deepseek" DSH_MEMORY_BACKEND: "sqlite" DSH_AGENT_WORKERS: "4" volumes: - ./data:/app/data - ./config:/app/config - ./logs:/app/logs

这套配置解决了几件关键事情：restart: unless-stopped保证机器重启后容器能自动拉起；DSH_AGENT_WORKERS控制 Agent 的并发工作数，4 是我试下来比较均衡的值；sqlite作为记忆后端则省去了单独维护数据库的麻烦。

如果你打算用本地 Ollama 模型，可以加一个 Ollama 服务，让两个容器互通。参考配置长这样：

services: ollama: image: ollama/ollama:latest container_name: ollama volumes: - ./ollama-data:/root/.ollama ports: - "11434:11434" restart: unless-stopped deepseek-harness: image: deepseek/harness:latest container_name: deepseek-harness restart: unless-stopped ports: - "8080:8080" extra_hosts: - "host.docker.internal:host-gateway" environment: TZ: Asia/Shanghai DSH_MODEL_PROVIDER: "ollama" DSH_MODEL_BASE_URL: "http://host.docker.internal:11434/v1" volumes: - ./data:/app/data - ./config:/app/config - ./logs:/app/logs

不要小看extra_hosts那行配置，它的作用是把宿主机地址映射到容器内部，这样 Harness 才能在同一台机器上找到 Ollama 的服务。我第一次没加这行，结果一直报连接失败，折腾了半个多小时才发现是网络互通的问题。

3.2 启动容器并看懂首次启动日志

配置写好后，在目录下执行启动命令：

docker compose up -d

第一次执行会拉取镜像，网络稳定的话几分钟就能完成。启动后先用这行命令看容器状态：

docker ps

如果STATUS那一列显示Up且PORTS里有0.0.0.0:8080->8080/tcp，说明基本没问题。接着看启动日志：

docker logs -f deepseek-harness

日志里重点关注两个关键节点：一个是框架是否成功加载配置文件，另一个是模型服务连通性检测。如果一切正常，你会看到类似 “All services started successfully” 的提示。这里要提醒一句，日志打印比实际情况有延迟，别看到进程还在跑就急着按 Ctrl+C，给容器十几秒钟做健康检查更稳妥。

3.3 在 Web 面板里接入 DeepSeek 模型

浏览器访问http://localhost:8080，进入 Harness 的初始化向导。第一步通常是设置管理员账号，这个账号以后管理 Agent 和工作区都要用，密码别随便设置，丢了找回比较麻烦。

接下来是模型配置。这一步最常见的误区是只填一个 API Key 就完事，实际上还要注意模型名称和接口地址。DeepSeek 的接口兼容 OpenAI 协议，所以在 Harness 里填 base_url 的时候，我用的是官方文档里的标准地址。填完保存后，界面一般会提供一个“连通性测试”按钮，建议点一下，能省掉后续排查问题的时间。

如果你用的是本地 Ollama，base_url 要改成http://host.docker.internal:11434/v1，模型名则填你实际拉取的模型标签，比如deepseek-r1:7b之类。这里强烈建议先在宿主机上用命令行确认 Ollama 的模型真的能正常返回，再去配置 Harness，不然问题出在哪一层都搞不清楚。

3.4 验证部署：完成第一轮对话

配置完成后，回到 Harness 的对话界面，先不问复杂问题，我建议你让它做一次“工具能力自检”。怎么验证？直接让它试着你配置过的工具操作，比如让它读一个文件内容，确认工具调用的链路是通的。

我自己的验证习惯是问一句：“你用一句话说明你现在能控制哪些工具。”如果回答里列出了 csv 读取、Python 执行之类的具体能力，说明基础链路正常。如果只是一句“我是一个 AI”，很可能工具没有正确绑定，回工具配置页面排查。

4. 把 Harness 用起来：创建第一个能“干活”的 Agent

4.1 Agent 三大件：模型、工具、记忆

在动手创建第一个 Agent 之前，先花五分钟把概念理顺。这个思路看懂之后，不仅 Harness 会用，面试遇到 AI Agent 的题目也不会慌。一个可工作的 Agent 必须包含三部分：

• 模型底座：负责理解和生成内容，你可以把它理解为整个 Agent 的“大脑”。模型能力决定了 Agent 理解的深度和回复质量。
• 工具集合：让模型有机会触碰外部世界，执行代码、读取文件、调用接口、查数据库，都属于工具。没有工具的模型再聪明，也只能空谈。
• 记忆系统：把历史对话、任务中间状态、用户偏好存下来。没有记忆的话，Agent 每轮对话都像失忆了一样，根本无法完成多步骤任务。

Harness 的价值在于，这三样东西你都可以通过界面配置，不用手搓代码。模型你已经在上一步接好了，记忆系统用默认的 sqlite 后端就能跑，工具的接入才是这里面的重头戏。

4.2 实操：创建一个本地数据分析 Agent

我拿一个实际场景做示范：做一个“本地数据分析 Agent”，让它能读取 CSV 文件、执行 Python 代码做统计，最后输出一份简单分析报告。

在 Harness 的 Agent 创建页面，先给 Agent 起名字和写角色定义。角色定义也就是 system prompt，决定这个 Agent 的工作风格。我用的模板是下面这段：

你是一个数据分析助手。你可以读取用户上传的 CSV 文件，执行 Python 代码完成统计，并通过表格输出结论。 要求： - 每次分析先列出数据概览，再做字段说明，然后完成核心指标计算； - 给出结论时附上计算口径； - 如果遇到数据缺失，先提示用户，而不是擅自删除。

然后给这个 Agent 绑定工具。基础分析场景下，csv 读取、Python 代码执行这两个工具先勾上；如果你希望它能进一步联网查资料，再增加搜索工具。工具不是越多越好，每多一个工具，模型在任务规划时就要多一个分支判断，反而可能降低准确率。新手建议从最少工具开始，跑通了再逐步加。

记忆这块，如果你是单人使用，开个短期记忆就够了，够覆盖一次分析任务的多轮对话。如果做的是客服类 Agent，那再考虑长期记忆和知识库，那套东西单独展开写又是一篇长文。

4.3 看一次完整的 Agent 任务循环

Agent 配置完，上传一个订单数据 CSV，然后下达一个任务：“分析 3 月相比 2 月的订单量变化，并列出销量前五的商品”。

这里你可以刷新认知一下，Agent 并不像搜索引擎那样一次给出彻底答案。它的工作循环大致是：规划（将任务拆成步骤）→ 工具调用（读 CSV、执行统计代码）→ 结果解析（看输出是否符合要求）→ 再规划（还需要再算一次就再循环）→ 直到得出完整结论。整个过程会完全展示在 Harness 的执行日志面板里。

我第一次看到那个执行面板时还是挺震撼的，每个步骤清晰地陈列在界面上，模型思考了哪一步、调用了哪个工具、传入了什么参数、得到什么结果，全程可追溯。也就是说，即使推理结果不对，也能顺藤摸瓜找到出问题的环节。这也是我推荐用它来学习 Agent 工程的原因：你能亲眼看到链条，而不是黑盒。

5. 进阶玩法：多 Agent 协作与容器资源治理

5.1 多 Agent 编排的场景：Supervisor + Worker

单个 Agent 跑通之后，很快会遇到一个瓶颈：任务太复杂，一个 Agent 要兼顾规划、执行、检查三个角色，反而容易混乱。这时候多 Agent 协作就有用了。类似 Spring AI 生态里的 Multi-Agent 模式，Harness 也支持把任务拆到不同角色身上。

比较经典的是 Supervisor + Worker 模式：一个主管 Agent 负责拆解任务、派发工作、汇总结果，多个工作 Agent 分别负责具体执行，比如一个写代码、一个查资料、一个做审核。实际操作时先创建一个“任务主管”Agent，在它的编排面板里选择要调用的 worker Agent。主管的 system prompt 要写清楚派活规则：什么任务分给谁、优先级是什么、结果怎么汇总。不建议一上来就搞三层以上的协作链路，因为调试成本会翻倍，先跑两层的模型，等稳定了再加层级。

5.2 别让 Agent 把机器打满：资源限制与超时

Harness 这类平台非常吃硬件资源，尤其是并发 Agent 数量上去之后，CPU 和内存的占用会像坐火箭一样飙升。我有一次同时跑了 6 个分析 Agent，宿主机直接卡到鼠标都动不了。从那以后我老实了，必须加资源限制。

在 Docker Compose 里可以这样限制：

services: deepseek-harness: deploy: resources: limits: cpus: "2.0" memory: 4G

deploy配置在 docker compose 里是标准的资源限制写法。限制之后即使 Agent 出问题，也不会拖垮宿主机上的其他服务。超时设置同样重要，Harness 里可以为工具调用设置单次超时时间，我建议把单工具执行超时控制在 60 到 120 秒之间，短了复杂任务做不完，长了异常任务会一直占着资源。

5.3 日志、监控与配置备份

容器跑了几天之后，你会明显感觉到日志文件膨胀。长期运行前，建议在 compose 文件中加日志轮转：

logging: driver: "json-file" options: max-size: "20m" max-file: "3"

配置不要光放在容器里，我习惯每次改动完成后，把 Harness 的配置目录复制一份带日期后缀的备份。命令很简单：

cp -r /opt/deepseek-harness/config /opt/deepseek-harness/config_backup_$(date +%Y%m%d)

这套习惯成本很低，但遇到 Agent 配置被误改或者升级失败时，能让你快速回到可用状态。

6. 高频踩坑记录：这些问题十个人有九个会遇到

6.1 Docker Desktop 启动失败：虚拟化没开

Windows 上部署最容易遇到的一个问题，就是启动 Docker Desktop 时提示 “virtualization support not detected, Docker Desktop failed to start”。这个问题基本可以归因于两个原因：BIOS 里没开启 CPU 虚拟化，或者 Windows 的虚拟化相关功能没勾选。

解决办法分两步。第一步进 BIOS，找到 Intel VT-x 或 AMD-V 对应的选项，改成 Enabled。不同主板菜单名称不同，但思路一样。第二步在 Windows 控制面板里，进入“启用或关闭 Windows 功能”，把“虚拟机平台”和“Hyper-V”（如果你用 WSL2 作为后端，还要勾“适用于 Linux 的 Windows 子系统”）勾选上，重启后再试。注意如果你的机器本身比较老，CPU 不支持虚拟化，那 Docker Desktop 确实跑不了，这种情况只能用 Docker Toolbox 或换 Linux 环境。

6.2 端口冲突怎么处理

网页打不开、容器日志显示 address already in use，十有八九是端口被占了。先用前面提到的netstat或lsof找出占用进程，如果有别的服务占着 8080，最简单的办法是改 compose 文件里的宿主机映射端口，比如改成8081:8080。容器内部端口不用动，因为应用本身监听的就是 8080，外部访问入口改成 8081 即可。

6.3 容器重启后配置丢失

很多人把 API Key 直接写在容器里，结果容器删了重建，一切回到出厂状态。这个问题根因就是没做数据持久化。检查你的 compose 文件，确认volumes部分已经把config和data目录挂载到宿主机了。没挂载的话，现在加挂载还来得及，先把容器备份一下数据，再修改配置重建。别问我为什么提醒，我已经在这个坑里摔过两次了。

6.4 工具调用失败和环境差异

Harness 里跑 Python 代码或者执行 Shell 命令非常方便，但工具容器和宿主机环境并不完全一样。很多 Agent 工具运行是隔离的，可能缺依赖库。比如让数据分析 Agent 直接执行 pandas 代码，如果工具环境里没装 pandas，就会报错。这时候得在工具配置里设置预装依赖，或者把工具环境切换到包含完整数据科学库的镜像。这个问题最隐蔽，因为模型这边看起来一切正常，是执行环境“暗算”了你。

6.5 常见问题速查表

写在最后的一些经验

多跑几次这套流程之后，我自己最大的一个体会是：DeepSeek Harness 这类平台的核心价值，不是把 Agent 概念包装得多玄，而是把工程上的脏活累活替你处理掉了。你不需要先成为一个 Docker 专家、再成为一个 Agent 框架开发者，才能开始做实验。照着这篇文章的思路先跑起来，边用边理解，反而比死磕底层文档学得快。

我个人现在做 AI 项目的基本盘就是这一套：本地 Docker Compose 拉起 Harness，连接 DeepSeek 官方 API 做日常实验，需要保密的项目再切到 Ollama 本地模型。每个新 Agent 先在 Harness 的沙箱环境里快速验证流程，逻辑成熟后再拆出去单独部署。如果你想在这个方向深入，后续还可以尝试给 Harness 开发自定义工具插件、接入自己的业务数据库、把 Chroma 或 Milvus 这类向量库接进来做知识库增强。先把这篇的基础环境搭好，后面的事咱们可以慢慢聊。