我把 Qwen3.8-27B 接进了 DeepSeek Harness
Qwen3.8-27B 开源之后，我第一反应，不是先去看跑分。
而是：能不能把它塞进 DSH 里。
模型单独跑起来，顶多算一个会说话的 API。
接进 Harness，能读文件、跑命令、调用工具，再根据结果继续往下干，才算真正长出了手和脚。
答案是：可以。
而且整个过程，比我想象中简单。
核心就两步： 
先用 vLLM 把 Qwen3.8-27B 跑起来，再把它提供的 OpenAI 兼容接口，填进 DSH。
先把 Qwen3.8-27B 跑起来
这次部署的是 Qwen3.8-27B-FP8。
Qwen3.8-27B 是一个 27B 稠密模型，原生支持 262,144 Token 上下文，也就是通常所说的 256K。官方 vLLM Recipe 还专门给出了推理解析和工具调用解析配置，这两项正好也是接入 DSH 的关键。(vLLM Recipes1)
配图：vLLM Recipes 中的 Qwen3.8-27B 部署页面
我这里直接使用 Docker 启动：
bash
docker run -itd \
--restart always \
--name llm_server \
--gpus '"device=2"' \
-e CUDA_VISIBLE_DEVICES=0 \
-v /data/pretrained_models/Qwen3.8-27B-FP8/:/models/Qwen3.8-27B-FP8 \
-p 8004:8000 \
vllm/vllm-openai:v0.21.0 \
--model /models/Qwen3.8-27B-FP8 \
--served-model-name Qwen3.8-27B-FP8 \
--gpu-memory-utilization=0.95 \
--dtype auto \
--host 0.0.0.0 \
--port 8000 \
--max-model-len=262144 \
--tensor-parallel-size=1 \
--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--max-num-seqs 512 \
--mm-encoder-tp-mode data这段命令看着挺长，真正需要注意的，其实就几个参数。
--max-model-len=262144，表示把最大上下文长度设置为 256K。
不过这只是上限，不代表每次请求都要塞满。上下文越长，KV Cache 占用也越大。如果启动时显存不够，可以先降到 65536 或者 131072，跑通之后再慢慢往上加。
--served-model-name Qwen3.8-27B-FP8 也很重要。
后面在 DSH 里填写的模型 ID，必须和这里保持一致。名字对不上，模型明明已经启动了，DSH 还是会告诉你找不到。
然后是这三个参数：
bash
--reasoning-parser qwen3
--enable-auto-tool-choice
--tool-call-parser qwen3_coder前一个负责把模型的思考内容解析出来，后两个负责识别和解析工具调用。
毕竟接入 DSH，不是为了让模型换个界面陪你聊天。
真正要看的，是它能不能正确调用 Bash、读取文件、修改代码，然后根据工具返回的结果继续干活。
还有一个看起来有点奇怪的地方：
bash
--gpus '"device=2"'
-e CUDA_VISIBLE_DEVICES=0这不是写错了。
前面的 device=2 表示使用宿主机上的第 2 号 GPU，这张卡进入容器之后，会被重新映射成容器里的第 0 号 GPU，所以后面写 CUDA_VISIBLE_DEVICES=0。
套娃了一层，但逻辑没问题。
如果不是使用已经配置好的 Docker 镜像，而是在本地 Python 环境里直接安装 vLLM，遇到模型配置或 Processor 加载错误，可以先检查一下 transformers 版本。官方 Recipe 要求 transformers >= 5.8.0。(vLLM Recipes1)
先别急着打开 DSH
模型启动以后，先检查一下接口。
bash
curl http://127.0.0.1:8004/v1/models如果返回结果里能够看到：
text
Qwen3.8-27B-FP8说明 vLLM 服务已经正常起来了。
这一步最好别省。
不然一会儿 DSH 连不上，你很容易怀疑是模型不支持、工具调用有问题，折腾半天，最后发现只是端口没通。
再把模型塞进 DSH
接下来启动 DeepSeek Harness：
bash
npx @deepseek-ai/dsh web打开 DSH 工作台以后，进入：
text
设置 → 模型 → 添加自定义提供方DSH 原生支持接入自托管的 OpenAI 兼容服务，需要填写 Provider ID、API 地址、接口协议和模型信息。保存之后，新请求就会直接使用新的配置，不需要重启 DSH。(GitHub2)
我这里的配置大概是：
text
Provider ID：qwen-local
显示名称：Qwen Local
API 地址：http://模型服务器IP:8004/v1
API 协议：openai-completions
模型 ID：Qwen3.8-27B-FP8
模型名称：Qwen3.8-27B-FP8如果 DSH 和 vLLM 在同一台机器上，API 地址可以直接填写：
text
http://127.0.0.1:8004/v1如果不在同一台机器上，就换成模型服务器的实际 IP。
本地 vLLM 没有配置 API 鉴权的话，API Key 可以留空；如果启动服务时额外设置了 Key，就按照实际值填写。
这里再强调一次：
DSH 里的模型 ID，必须和 vLLM 的 --served-model-name 完全一致。
一个字母都别差。
保存以后，回到对话页面，在模型选择器里找到刚刚添加的 Qwen3.8-27B-FP8。
到这里，模型就算正式装进 DSH 了。
接上以后，重点不是问一句"你好"
普通对话能正常返回，只能说明接口通了。
对于 Harness 来说，这还远远不够。
所以这次，我没有拿"介绍一下你自己"这种问题糊弄它，而是直接扔进去一个正在做的真实任务：WorldQuant BRAIN Alpha 研究与批量模拟。
这个任务并不简单。
它需要先阅读项目里的脚本、Skill 和参考资料，检查现有工具能不能用；然后登录 API、探测数据字段、设计候选 Alpha，再启动多组并行模拟，检查相关性、Margin、Turnover 和报错信息，最后继续做下一轮优化。
换句话说，它不只是写一段代码。
而是要围绕一个目标，连续完成「读文件---写代码---执行命令---等待结果---分析日志---发现问题---继续修正」这一整套流程。
实测下来，Qwen3.8-27B 在 DSH 里的表现，比我预想中稳。
它会自己读取项目文件，调用 PowerShell 执行 Python 脚本，生成候选配置，启动后台任务，同时维护一份任务清单，记录哪些步骤已经完成、哪些正在执行、后面还要继续做什么。
中间也不是完全没有报错。
例如批量模拟结果写入时出现了竞争问题，最终结果文件只保留了一条记录。模型发现结果数量不对之后，没有直接卡死，而是继续检查日志，判断问题来自并发写入，再换到 JSONL 日志里读取完整结果。
这点其实挺重要。
真实开发任务不可能一路绿灯，关键不是模型会不会报错，而是报错以后，它还能不能沿着目标继续往下查。
上图是 DSH 的对话视图。
可以看到，模型一边执行任务，一边汇报当前进度：前面检查了哪些工具，正在运行哪一批模拟，又发现了哪些相关性和结果文件问题。
页面下方还有一份持续更新的任务清单。
整个任务连续运行了三十多分钟，执行了接近四十个步骤。期间涉及多次文件读写、代码生成、后台进程、日志分析和结果判断，模型没有明显忘记最初目标，也没有跑着跑着突然开始干别的。
速度上不算特别快，长任务里的首 Token 等待也比较明显。
但至少从这次实测来看，写代码、执行目标和持续跑长任务，基本都没有明显问题。
更让我喜欢的，还是 DSH 的轨迹视图。
切换到轨迹页面以后，整个任务会被拆成一条完整的执行链。
哪一步是模型输出，哪一步调用了工具，什么时候注入了新的上下文，后台任务什么时候完成，全都按照时间顺序排了出来。
点开其中一条，还能继续查看具体调用了什么工具、传入了哪些参数、命令返回了什么内容，以及模型拿到结果以后做出了什么判断。
页面顶部还会把 Input、Model 和 Tools 的耗时画成一条时间轴。 
模型在哪一步想得比较久，哪条命令执行得比较慢，任务是在哪个环节开始绕路的，基本一眼就能定位。
以前跑这种长 Agent 任务，通常只能盯着终端里一行行日志猜。
现在相当于把模型整个「思考---行动---反馈---修正」的过程，直接摊开给你看。
所以这一轮测试下来，我对这套组合的判断，也从"能够接入"变成了"确实能够干活"。
Qwen3.8-27B 负责理解目标、写代码和做判断。
DeepSeek Harness 负责文件、命令、工具编排和过程记录。
两者拼在一起以后，已经不只是换了一个界面的本地聊天模型，而是一个能围绕真实目标，连续工作几十分钟的 Agent。
至少这次，它不是简单的「能跑」。
是真的把活干起来了。