最近接手了一个本地 AI Agent 项目代码逻辑其实不难难的是把运行环境折腾明白。Python 版本、CUDA 版本、模型推理库、Agent 框架的依赖每个都能单独写一部踩坑史。后来我把整个运行时切到 Docker 里用 DeepSeek Harness 作为 Agent 运行时平台一次性把这些问题全挡在了容器外面。这篇东西就把我完整的部署思路、配置细节和踩坑经历写出来给打算在本地跑 AI Agent 的朋友一个可以直接参考的落地路径。DeepSeek Harness 本身不是一个模型而是一个面向 AI Agent 的运行时平台它负责加载模型后端、维护对话上下文、调度工具调用、管理 Agent 生命周期。配合 Docker 部署好处是环境干净、可迁移、可复制特别适合本地开发、团队共享、以及后续想上多 Agent 架构的场景。无论你是刚接触 Agent 开发的新手还是已经在写工具调用逻辑的老手这套部署流程都能帮你省掉大量环境调试时间。1. DeepSeek Harness 到底在解决哪一类运行时问题1.1 Agent 开发中的环境债模型和代码只是第一步大多数人对 Agent 开发的理解是调用大模型 API加两轮工具调用逻辑听起来很轻量。但真到了本地部署你会发现事情远不止这些。一个完整的 Agent 运行时至少需要处理四类问题第一模型本身的加载与推理这涉及推理框架选型、显存管理、量化格式支持第二对话上下文的状态维护Agent 不是单轮问答而是多轮推理循环上下文要存在内存里还要考虑截断和压缩策略第三工具注册和调度的机制模型决定我要调用某个工具但真正去执行工具、把结果塞回上下文这是运行时层面的能力第四对外提供的访问入口不管是 Web 管理界面还是 HTTP API都需要一个常驻服务。如果这些全靠自己从零写恐怕业务逻辑还没写几行光基础设施就要耗费大半精力。DeepSeek Harness 在中间层替你把这几件事都接管了。它天然适配 DeepSeek 系列模型的推理后端也支持通用的 OpenAI 兼容接口Agent 循环、工具注册表、上下文管理、日志追踪都做了内置实现。你要做的只是把运行时跑起来然后专注在 Agent 的工具和业务逻辑上。1.2 Harness 的职责边界对话循环、工具调用与状态管理用一个容易理解的类比来说DeepSeek Harness 之于 Agent就像游戏引擎之于游戏开发。游戏引擎管渲染、管物理碰撞、管资源加载开发者只管写玩法DeepSeek Harness 管模型调度、管对话循环、管工具执行链路开发者只管定义 Agent 的行为。具体拆开看它承担的工作可以分成三层。第一层是模型抽象层。它屏蔽了底层模型文件到底放在哪、用什么框架推理这些细节。你对它说加载 /models 下的那个模型它会去处理加载、预热、tokenizer 等动作。第二层是 Agent 循环层。一次完整的 Agent 调用是这样的接收用户输入把输入和系统提示组装成上下文交给模型推理模型输出可能包含工具调用指令Harness 解析这个指令并执行对应工具拿到结果再送回模型进行下一轮推理直到模型认为任务完成。这个 while 循环看起来简单实际要做好上下文追加、轮次控制、异常恢复并不容易。第三层是工具管理层。每个工具需要有一个 name、一段描述、一个参数 schemaHarness 会把工具列表注入到模型的上下文中让模型知道当前环境里有哪些工具可以用。当模型返回一个工具调用请求时Harness 根据 name 去注册表里找到对应的执行函数并调用把结果拼接回消息历史。1.3 什么时候真正需要它什么时候用不上我的判断是如果你只是想在本地跑一个单轮聊天测试比如把模型下载下来问几句话那用现成的推理程序就够了不需要 Harness。但一旦你的目标是一个能自己决策、自己调用工具、自己完成任务的 Agent那一个稳定的运行时平台就是必需品。更进一步如果你有多个 Agent 项目要同时维护或者希望团队里每个人都在同一套运行时环境上开发那用 Docker 把 Harness 装成标准服务绝对是投入产出比最高的方案。2. 为什么我坚持用 Docker 来装这个运行时2.1 一次性把 CUDA、Python、依赖版本全部锁进镜像本地装 AI 相关的开发环境最大的痛点是版本地狱。模型推理库对 Python 版本有要求Agent 框架对依赖版本有要求CUDA 版本和显卡驱动又有一个对应关系。三者交叉组合起来问题呈指数级爆炸。比如同一个项目在 A 机器上跑得好好的换到 B 机器上因为系统里的 CUDA 版本、gcc 版本之类的差异可能怎么都起不来。遇到这种情况常规做法是花半天去排查系统环境实际经验告诉我这一步很容易把人的耐心耗尽。Docker 的解决思路是釜底抽薪把项目作者已经验证过的环境完整打包成镜像。镜像里装好指定版本的 Python、CUDA 运行时、推理库、Agent 框架代码到了任何一台装有 Docker 的机器上跑出来的环境都是一模一样的。对 DeepSeek Harness 这种运行时平台来说官方镜像本身就是经过测试的比你本地手动装靠谱得多。2.2 容器内 GPU 透传的基本原理有人会担心我的模型推理要用显卡Docker 容器是不是就访问不到 GPU 了其实现在的容器技术早就解决了这个问题原理上可以理解为在宿主机和容器之间做了一次驱动接口的映射。GPU 透传的完整链路是宿主机安装 NVIDIA 显卡驱动再安装 nvidia-container-toolkit 这个中间组件它负责把宿主机的 GPU 设备文件和驱动库注入到容器里。运行容器时加上 GPU 相关的运行参数比如通过 compose 文件声明需要 GPU 资源容器内部就能直接调用 nvidia-smi 并执行 CUDA 计算。此时容器内的进程访问的是宿主机的物理 GPU性能损耗非常小几乎可以忽略。这一步是整个方案里最关键的一环也是后面最容易出问题的地方。我见过的典型错误是驱动装好了容器也能跑但启动时没有加 GPU 参数导致模型加载时直接回退到 CPU 模式推理速度慢到令人绝望而你一开始还察觉不到。2.3 多项目共存的灵活度起一个容器不污染宿主机本地开发最怕的其实是污染两个字。今天为了项目 A 装了某个版本的依赖明天项目 B 依赖冲突你根本记不清系统里哪个包是谁装进去的。用 Docker 跑 DeepSeek Harness 之后所有依赖都留在镜像和容器里宿主机上只需要有 Docker Engine 本身。这种隔离带来的另一个好处是可以多版本共存。你可以在一个容器里跑旧版 Harness 做稳定性验证同时用新版本起另一个容器测试新功能两个服务用不同的端口映射互不干扰。等验证完了旧容器停掉即可删除也干净。对需要频繁升级框架版本的人来说这个能力非常实用。3. 部署前的环境自查与目录规划3.1 硬件底线CPU、内存、显存怎么搭配在开始拉镜像之前先评估一下你的机器到底能不能跑得动。别的不说如果硬件配置不够后面所有操作都会卡在模型加载这一步那是非常折磨人的。我这里给一个基于经验的参考表你可以对照自己的配置做个判断。表中的可用显存指 GPU 的专用显存如果用的是集成显卡或共享显存方案请直接忽略并选择更小的模型规格。模型参数量量化精度模型文件大小参考建议可用显存建议内存7BQ4约 4~5 GB8 GB16 GB14BQ4约 8~10 GB16 GB32 GB32BQ4约 18~20 GB24 GB48 GB32BQ8约 32~36 GB40 GB64 GB以上数据是包含了推理过程中的 KV Cache 和其他开销的估算实际占用因上下文长度、并发数而异。模型文件解压、加载、运行时的临时缓存都会吃内存所以内存绝对不能只看模型文件大小来配。这里要额外说明一点如果你手里的显卡显存不够又想跑更大参数量还有一个混合方案——让部分层跑在 GPU、部分层跑在 CPU。Harness 这类运行时通常支持这种 offload 配置但代价是推理速度明显下降适合能跑就行的场景不太适合实时交互。3.2 Docker 侧的准备与 GPU 运行时软件层面需要准备的无非三样Docker 本身、Docker Compose 插件、以及 NVIDIA 相关的 GPU 支持组件。如果你用的是 Linux 发行版安装 Docker Engine 之后Compose v2 插件一般会一并装上。Windows 和 macOS 用户可以用 Docker Desktop但有一点必须注意Docker Desktop 在 Windows 上依赖 WSL2 后端初次安装后如果提示 virtualization support not detected 之类的报错可以去 BIOS 里检查虚拟化是否开启同时确认 WSL2 功能已经在 Windows 系统中启用。GPU 支持组件的安装核心是一条链NVIDIA 驱动、nvidia-container-toolkit、配置 Docker 的运行时。装完 toolkit 之后可以先用下面的命令验证 GPU 透传是否正常工作docker run --rm --runtimenvidia --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到类似宿主机上 nvidia-smi 输出的显卡列表说明 GPU 透传链路已经通了一半。这个验证建议放在正式部署之前因为它能帮你把GPU 相关问题和Harness 配置问题在时间上分开排查。3.3 推荐的数据目录结构在开始部署之前先把目录规划好。我的习惯是创建一个专用的根目录并保证模型文件和配置目录都在这个根目录之下这样后面维护、迁移、备份都很方便。~/harness-workspace/ ├── config/ # Harness 运行配置 ├── models/ # 本地模型权重目录 ├── data/ # Harness 的数据文件agent 状态、日志索引等 ├── tools/ # 自定义工具代码 └── backups/ # 备份目录这个目录结构有一个好处模型目录和配置目录在容器启动时以只读或可写的方式挂载进去宿主机上可以直接访问。你不会因为容器内部发生的文件变动而失去对数据的掌控。后面升级镜像或重建容器时只要指定好挂载关系所有数据都在。4. 一步步拉起 Harness 服务4.1 准备 docker-compose.yml我推荐用 Docker Compose 而不是一条条 docker run 命令来组织部署因为 Harness 涉及的参数比较多写成配置文件之后可以版本化管理换机器时复制过去就能跑。下面是一个典型的 compose 文件示例你可以根据自己的环境和 Harness 当前版本的官方文档做微调services: harness: image: deepseek-harness:latest container_name: ds-harness restart: unless-stopped ports: - 8080:8080 - 8090:8090 volumes: - ./config:/config - ./models:/models - ./data:/data - ./tools:/tools environment: - HARNESS_MODEL_DIR/models - HARNESS_DATA_DIR/data - HARNESS_CONFIG_DIR/config - HARNESS_SERVER_HOST0.0.0.0 - HARNESS_SERVER_PORT8080 - HARNESS_UI_PORT8090 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu]需要说明的是具体镜像名称、端口号、环境变量名请以你所用的 DeepSeek Harness 版本官方文档为准。不同版本之间的命名可能会有差异但结构是通用的。4.2 环境变量与映射关系说明逐个解释一下这些配置的含义方便你按自己的需求调整。端口映射部分我给 Harness 规划了两个端口8080 作为 API 服务端口8090 作为管理界面端口。左边是宿主机端口右边是容器内部端口。如果宿主机 8080 被其他服务占了可以把左侧改成 8081不影响容器内部逻辑。目录挂载部分config、models、data、tools 四个目录一一对应。models 目录里放模型权重data 目录给 Harness 写运行时状态tools 目录挂你自己的工具代码。有一点要注意如果 tools 目录在容器启动时是空的部分工具可能不会被加载所以最好先把一个最小的工具脚本放进去再启动。环境变量部分是给 Harness 进程看的。HARNESS_SERVER_HOST 设为 0.0.0.0表示监听所有网络接口这样不仅本机能访问局域网内其他机器也能连上。如果你只希望本机访问改成 127.0.0.1 会更安全。GPU 资源声明那里capabilities 列表里写 gpu意思是容器运行时需要 GPU 设备。如果你的机器没有 NVIDIA GPU或者暂时想用 CPU 跑把这整段 deploy 配置删掉即可。4.3 启动与健康检查配置文件准备好之后进入工作目录执行docker compose up -d-d 参数让容器在后台运行。第一次启动会拉取镜像根据网络状况可能需要等一段时间。拉取完成后容器会自动创建并启动。接下来检查是否正常运行docker compose ps docker compose logs -f harness从日志里应该能看到 Harness 启动的过程。如果配置了本地模型路径启动时可能会尝试扫描模型目录并做加载这个过程耗时较长尤其是在模型文件比较大的时候。日志里出现类似 server started 或 health check passed 的信息时服务就算是起来了。然后做个快速连通性测试curl http://127.0.0.1:8080/health如果返回 200 或一个 JSON 状态体说明 API 服务已经正常监听。此时浏览器访问 http://127.0.0.1:8090 应该能看到管理界面。4.4 首次进入管理界面的调整第一次打开管理界面不需要急着做复杂配置我建议按这个顺序先确认三件事。第一检查系统状态或资源监控页面确认 GPU 是否被正确识别。如果页面里显示显卡型号和显存大小说明 GPU 透传成功。如果显示 CPU 模式或根本没有 GPU 信息回到第 3.2 节重新验证。第二检查模型列表。如果 models 目录里还没有模型列表会是空的。这正是下一节要解决的问题——把合适的模型权重放进去让 Harness 能加载它。第三看一下默认的 Agent 配置。通常 Harness 会带一个名为 default 的 Agent它的 system prompt 和启用的工具集合都可以编辑。先把这些选项的位置摸清楚后续使用时会顺手很多。5. 让 Harness 真正接上模型权重目录、量化格式与后端选择5.1 模型文件放进哪个目录在所有配置中最核心的就是让 Harness 找到模型。以我们上面的目录规划为例宿主机上的 ~/harness-workspace/models 目录会被挂载到容器内的 /models。所以模型文件应该放到宿主机的 ~/harness-workspace/models 下。~/harness-workspace/models/ └── deepseek-llm-7b/ ├── config.json ├── tokenizer.model └── *.gguf放好之后在管理界面的模型配置里指定路径 /models/deepseek-llm-7b/再触发一次加载Harness 就会在这个目录下寻找模型文件并初始化推理后端。这里有一个容易忽略的坑模型的子目录权限。容器内进程通常以非 root 用户运行如果宿主机上的 models 目录权限是 700容器内进程可能没有读取权限。遇到模型加载失败的情况先不要怀疑推理框架检查一下目录权限是否放开了。5.2 量化格式的取舍以及显存怎么算本地部署大模型绝大多数人都会用量化格式的模型文件。原因很简单全精度模型对显存的消耗太高个人电脑很难跑得动。拿一个 7B 模型来说FP16 半精度格式的文件大小大概是 14GB 左右需要接近 14GB 显存才能放进 GPU。而 Q4 量化的文件只有 4GB 左右一张 8GB 显存的消费级显卡就能装下同时还剩一些空间给上下文缓存。用 Q8 则需要约 8GB。显存和效果之间的平衡点通常选在 Q4 到 Q6 之间。精度格式7B 模型文件参考大小推理时显存开销含缓存效果保留程度FP16约 14 GB约 16 GB完整Q8约 8 GB约 10 GB很高Q6约 6 GB约 8 GB高Q4约 4.5 GB约 6 GB较好Q2约 3 GB约 4 GB明显损失我的实际体感是Q4 日常问答和工具调用都能正常处理逻辑复杂的任务偶尔会暴露出能力衰减Q8 的稳定性要好很多但代价是显存占用几乎翻倍。如果你显存比较充裕建议优先选 Q8。5.3 模型后端配置示例本地权重与 OpenAI 兼容接口DeepSeek Harness 通常支持两种模型后端一种是本地权重加载适合完全离线或数据敏感的场景另一种是接一个 OpenAI 兼容的 API 服务适合不想在本地处理推理资源的情况。本地权重的配置风格大致如下model: backend: local path: /models/deepseek-llm-7b/ quant: q8 context_length: 8192 max_tokens: 2048 gpu_layers: 40这里 gpu_layers 指将模型的前多少层放到 GPU 上计算。如果全部放到 GPU 上数值可以写成模型总层数如果显存不够减少这个值让部分层留在 CPU。这个参数是 GPU/CPU offload 的核心调它能解决很多显存不够的问题。如果你倾向使用 API 模式比如调用一个已经部署好的远端推理服务配置风格则是下面这样的model: backend: openai base_url: http://your-inference-server:8000/v1 api_key: sk-local model_name: deepseek-chat使用 API 模式时本地就不需要下载模型文件容器占用的资源会小很多但 Agent 的响应速度和可靠性完全取决于远端服务的状态。5.4 加载参数和缓存策略模型加载完成之后Harness 通常会维护一个会话缓存机制。也就是说同一个模型权重不会被重复加载多轮对话、多个 Agent 共用同一个模型时每次请求的额外开销主要在推理本身。这里我建议把 context_length 设置得保守一些。很多人习惯一口气拉满到 32K 甚至更高但上下文的长度会直接影响显存占用而且大量填充的上下文会让推理速度明显变慢。如果你目前的应用场景用不到超长上下文先用 8192 跑后续确实需要再调大。上下文设置不是越高越好适合场景才是最重要的。6. 第一个 Agent 的完整跑通流程6.1 创建工具从查天气这类简单函数开始模型加载好之后下一步就是让 Agent 具备行动能力。而工具是 Agent 行动的唯一入口。这里我拿一个最简单的查天气工具来演示工具注册的完整流程。在宿主机工具的目录下新建一个脚本文件比如 weather.py。Harness 会在启动时扫描该目录并加载工具因此新建工具之后通常需要重启 Harness 或通过管理界面的工具热加载入口刷新。具体扫描机制和格式要求以你使用的版本为准但整体流程基本一致写一个函数、声明参数 schema、标注工具名称和描述。一个典型的工具脚本核心结构如下def run(city: str): 根据城市名返回天气信息这里只是示例实现。 return f当前城市 {city} 的天气多云温度 24 摄氏度。 tool_meta { name: get_weather, description: 输入城市名返回该城市的当前天气信息。, parameters_schema: { type: object, properties: { city: {type: string, description: 城市名例如北京、上海} }, required: [city] } }工具描述写得越清楚模型就越容易在合适的时候调用它。这是 Agent 开发里一个很微妙但作用巨大的细节工具的描述文档写得好模型调用工具的命中率会提升明显。6.2 编排一次带工具调用的对话工具注册完成之后并不需要额外编写调用逻辑。模型会在推理过程中自主决定是否需要调用工具。你只需要通过 API 发起一条对话请求剩下的判断都交给模型和 Harness 的循环处理。这里我用 curl 演示一次请求。假设要问的问题是北京今天适合穿什么Agent 应该会调用 get_weather 工具拿到北京的天气再结合天气信息做回答curl -X POST http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { agent: default, messages: [ {role: user, content: 北京今天适合穿什么请根据城市天气作答。} ] }请求发出之后Harness 内部会经历这样一个过程模型读取当前上下文和工具列表判定需要调用 get_weather 工具Harness 执行工具中的 run 函数得到天气结果结果追加到上下文再返回给模型模型基于天气结果给出穿衣建议Harness 将完整响应返回给你。这个过程中间是否发生了工具调用通常在响应的元数据里可以看到也可以到日志中观察内部的工具调用记录。6.3 通过管理界面和 API 双通道验证跑通 API 之后我还建议到管理界面里再试一次。管理界面的价值在于可视化调试你能看到 Agent 每一次工具调用前后的完整消息流。如果一个任务没按预期完成界面上很快就能定位到是模型没有调用工具还是工具返回结果不符合预期这比对着日志猜测高效太多。另外管理界面里通常还有 Session会话管理功能。多个并行会话之间的上下文是互相隔离的这对调试很有用——你可以起一个测试会话在里面反复尝试不同的问法不用担心污染其他正常会话。6.4 从日志里看 Agent 的思考与调用链路最后是日志。Harness 的日志详细程度通常是可以配置的我建议把日志级别调到 debug 或 trace 观察一两轮完整对话。你会发现模型输出并不只是最终答案中间还有类似 thought、tool_call 这样的内部消息。Harness 的工作就是把这些内部的中间状态串起来哪一步调用了哪个工具、工具结果花了多久返回、是否还有下一轮推理。看懂了这条链路你对Agent 运行时这个概念的理解会有一个质的提升。后续排查问题的时候日志就是你最得力的助手。7. 实战场上的典型故障与排查思路7.1 端口冲突Harness 和已有服务打架本地开发最容易碰到的问题是端口被占用。默认端口 8080 太热门了很多开发框架都习惯用它。如果启动容器时提示 address already in use不用慌张换个宿主机端口即可。具体做法是把 compose 文件里的端口映射改成类似下面的形式ports: - 18080:8080 - 18090:8090改完重启容器docker compose up -d --force-recreate访问地址变成 http://127.0.0.1:18080 和 http://127.0.0.1:18090。这里有一个原则左侧宿主机端口可以随便改右侧容器端口保持默认除非你知道自己在调整什么。7.2 容器里看不到 GPU运行时配置失效如果你发现容器内执行 nvidia-smi 失败或者管理界面的系统状态里没有 GPU 信息问题大概率出在 GPU 运行时没有生效。先按下面的顺序排查。第一确认宿主机上 nvidia-smi 能正常输出第二确认 nvidia-container-toolkit 已经安装第三检查 compose 文件里的 deploy 配置是否被 DOCKER 正确解析第四重启 Docker 服务sudo systemctl restart docker大部分 GPU 透传失效的问题追根溯源都是 toolkit 安装后没有重启 Docker 服务导致的。这个细节非常容易忽略Docker 只有在重启之后才会重新加载 GPU 运行时的配置。7.3 显存和内存双双告急时的资源控制本地跑模型最让人头疼的问题就是资源溢出。显存溢出时推理中断日志里出现类似 CUDA out of memory 的错误。内存溢出更隐蔽可能表现为容器被系统 OOM Killer 直接杀掉docker compose ps 能看到容器不断重启。我的建议是给容器设置资源上限避免一个 Agent 进程吃掉整台机器的资源。在 compose 文件的 deploy 下面添加deploy: resources: limits: memory: 32G reservations: memory: 16G同时在模型配置里调低 context_length、减少 gpu_layers。如果是并发请求导致的资源紧张可以先从单并发开始验证逐步增加。资源问题永远是配置取舍问题没有一劳永逸的答案。7.4 模型加载成功但响应极慢的问题有一种情况特别折磨人模型能正常回答但每个问题要等一两分钟。这时候检查两件事。第一看管理界面的系统状态模型是否真的加载在 GPU 上。如果 gpu_layers 配置过小大部分层在 CPU 上跑速度会非常慢。把 gpu_layers 调大让更多层进入 GPU。第二看上下文长度。如果 context_length 设置得特别大模型每次推理都要处理巨大的 attention 矩阵即使实际对话只有几轮性能也可能被严重拖累。把 context_length 降到 4096 或 8192 试试速度往往会有明显改善。第三确认没有其他容器在抢占 GPU 显存和带宽。用 nvidia-smi 看一下当前 GPU 的使用率分配情况排除外部干扰。8. 让它长期稳定运行运维习惯与后续扩展8.1 日志、备份与一键恢复本地服务的运维不能太讲究但不能完全没有。我保持的习惯有三个。第一日志日常查看用 docker compose logs -f需要持久化分析时再配置日志驱动或挂载日志目录。第二定期把 config 和 tools 目录打包备份这些是配置资产丢了重建成本很高。模型的权重文件不建议频繁备份体积太大重新下载或重新拷贝代价更低。第三每次大版本升级前用 docker compose down 停止服务再用 docker compose start 启动如果需要重建容器先确认 data 目录里的状态文件已经备份。恢复流程也很简单把工作目录整体拷贝到新机器确保目录结构一致然后重新执行 docker compose up -d数据就回来了。这套流程我测试过多次新机器从零到服务可用半小时以内能搞定。8.2 升级 Harness 镜像时的迁移思路升级框架版本是每个项目迟早要面对的事。我的升级思路是保守迁移、旧版本保底。先把当前容器的镜像 tag 记下来确保旧版本随时可以拉回。然后修改 compose 文件里的 image 版本号执行 docker compose pull 拉取新镜像。之后先别急着启动新容器在旧容器还在运行时用新的镜像配置再起一个临时容器指定不同的端口做一轮简单验证。确认新版本的核心功能正常之后再停掉旧容器切换到新端口。这套流程虽然多花一点时间但能避免升级一时爽降级火葬场的尴尬。8.3 从单机 Demo 到多 Agent 项目的扩展最后聊一聊扩展。DeepSeek Harness 跑通之后它不只是一个单机 Demo而是一个可以继续扩展的运行时底座。最直接的扩展方式是增加多个 Agent 实例。Harness 允许创建多个 Agent每个 Agent 有独立的 system prompt 和工具集合。你可以在同一个运行时上同时维护一个负责代码任务的 Agent 和一个负责文档检索的 Agent它们共享同一个模型后端但行为边界完全分离。另一个扩展方向是把 Harness 的 API 暴露给其他应用。比如在一个聊天机器人项目中接入 Harness 的 /v1/chat/completions 接口让上层应用获得 Agent 能力或者开发一个定时任务系统定期调用 Harness 的 API 完成自动化数据处理。容器化的好处在这里再次体现出来运行时是独立服务上层应用怎么接都不影响 Harness 本身的稳定性。我个人的体感是把 DeepSeek Harness 用 Docker 部署好之后围绕它做 Agent 功能开发就变成了写工具、调 prompt、加知识库这些真正有创造性的工作而不是反复和本地环境搏斗。如果你也在本地跑过 Agent 项目估计会和我有同感环境问题解决掉的那一天才是项目真正开始有进展的一天。