夜雨聆风如果你把 DeepSeek Harness 只理解成“一个能在浏览器里聊天的 DeepSeek”，那就低估它了。
它真正有意思的地方，是官方写在仓库首页上的那句话：Everything is a Plugin——一切皆插件。
模型适配器是插件，工具注册表是插件，会话日志是插件，Agent 循环本身也是插件。换句话说，你看到的是一套可以拆、可以换、可以重新组合的 Agent 工作台。
这篇不讲玄学。我按目前最新的 0.1.0-rc.6 版本，在 Windows 上重新跑了一遍：解读架构、安装启动、查看插件、尝试远程访问，再让它完成一个只读任务。能跑通的我写“实测通过”，暂时不能验证的我会直接说明。
本机启动后的 DeepSeek Harness Web UI
1.
“一切皆插件”，到底是什么意思
普通软件更像一台封好的机器。你可以改设置，但发动机、变速箱和仪表盘通常绑在一起。
DeepSeek Harness 更像一套乐高底座。
官方架构文档里说得很直白：模型适配器、工具、会话记录、文件系统、审批策略、Agent 循环，甚至 Web 界面，都是挂在同一个上下文上的插件。每个插件负责一块能力，启动时再按照配置把它们拼成一棵“插件树”。
这会带来三个变化。
第一，模型可以换。
DeepSeek 是默认选择，但模型层本身只是适配器。只要接入相同能力接口，就能换成别的 Provider 或兼容端点。
第二，工具可以增减。
文件读取、PowerShell、网页搜索、Skill、子 Agent，都不是写死在主程序里。某个部署不需要一项能力，可以不挂载；需要新能力，可以新增插件。
第三，权限也能组合。
工具能不能执行、什么时候弹出审批、文件可以看到哪里，这些同样由插件和配置共同决定。
所以，“一切皆插件”的重点不在数量，而在于：几乎每一层能力都可以被替换，不需要去改一个所谓的神圣核心。
我在本机打开“设置 → 插件”时，看到的是终端、Agent 循环、网页搜索等核心能力的配置入口，远不止几个装饰性扩展。
设置中的插件配置入口
切到“插件列表”，当前部署显示了 160 项。里面有模型、会话、权限、终端、文件、Skill、子 Agent、Web UI 等模块。有些已启用，有些停用，这正是插件树在界面里的直观样子。
当前部署的插件清单
2.
Windows 安装：先跑通最小闭环
安装前先准备两样东西：
Node.js； 一个用来练习的普通文件夹。
DeepSeek API Key 可以稍后在页面里填写。第一次不要选桌面根目录、整个 D 盘或公司的生产项目，先建一个只放测试文件的小目录。
打开 PowerShell，检查环境：
node -v npm -v官方给出的 npm 启动命令只有一条：
npx @deepseek-ai/dsh web正常启动后，终端会打印：
http://127.0.0.1:3080把地址复制到浏览器，就能打开 Web UI。
我这次实测的环境是：
Node.js v24.14.1npm 11.11.0DeepSeek Harness 0.1.0-rc.6127.0.0.1:3080返回 HTTP 200
如果网页突然打不开，先别急着重装。检查启动 Harness 的终端窗口是不是被关了。这个 Web 页面依赖本地 dsh 进程，进程停了，浏览器当然会报连接被拒绝。
如果 3080 被占用，可以换端口：
npx @deepseek-ai/dsh web --port 3081我也用 3081 做了验证，页面同样返回 HTTP 200。
3.
配置模型和工作区
页面打开以后，先进入：
设置 → 模型
填入 DeepSeek API Key 并保存。官方指南说明，模型配置保存后可以立即使用，不需要重启服务。
然后回到首页，点击选择工作区，选中刚才准备的测试目录。
这里有一个新手特别容易误判的地方：没有选择工作区时，输入框不可用。这不是页面卡死，而是 Harness 还不知道自己可以在哪个目录里工作。
工作区相当于给 Agent 画了一条边界。你选了哪个目录，它就围绕哪个目录读取文件、运行命令和交付结果。
我的建议是：第一次只给它一个能随时删掉的练习目录。等你看懂审批提示、工具调用和文件变化，再把它放进真实项目。
4.
先看插件，再决定要不要装插件
很多人一看到“一切皆插件”，第一反应就是去网上搜插件包。
我反而建议先做两件事。
第一件事，查看当前到底加载了什么：
dsh --profile web --dump-config这条命令不会启动页面，而是把当前 Web Profile 最终组合出来的插件树打印出来。你能看到每一层是谁提供的、哪些行被后面的配置覆盖。
第二件事，学会区分 Plugin、Bundle 和 Profile。
Plugin：一块具体能力，例如一个工具、模型适配器或界面组件； Bundle：把插件代码和配置层打包起来，方便分发； Profile：一套可启动组合，例如 web，它规定要按什么顺序叠加哪些 Bundle。
安装一个已经打包好的插件，官方命令是：
dsh plugin --profile web add <插件包名>安装后先别急着运行，先检查配置树：
dsh --profile web --dump-config确定新层出现、没有覆盖错关键配置，再启动：
dsh web如果你只是开发本地插件，也可以写一个 patch 文件，用 --patch 临时加载，不必马上打包发布。
还有一个容易被忽略的安全点：从 GitHub 安装 TypeScript 插件时，包可能需要在安装阶段执行 prepare 构建脚本。官方文档明确提醒，这段代码运行在 Agent 沙箱之外。只给可信源码授权，并尽量锁定具体 commit，不要看到“热门插件”四个字就一路确认。
5.
远程访问：不要直接暴露 3080
这一段，我专门做了反向测试。
我尝试执行：
dsh web --host 0.0.0.0 --port 3081当前版本没有启动，而是直接拒绝，并说明：这样会把远程代码执行能力暴露到网络，应该继续使用 127.0.0.1。
这个限制非常合理。
DeepSeek Harness 不只是展示网页。它背后可能连接文件系统、PowerShell、终端、浏览器和其他工具。把它当普通静态网页开放到公网，相当于把一张能操作电脑的控制台挂出去。
更稳妥的远程方法，是让 Harness 继续只监听远端机器自己的 127.0.0.1:3080，再通过 SSH 隧道访问。
先在远端机器启动：
dsh web然后在你手边这台电脑执行：
ssh -L 3080:127.0.0.1:3080 用户名@远端服务器地址SSH 连接保持运行，再在本地浏览器打开：
http://127.0.0.1:3080这条命令的意思是：把你本机的 3080 端口，通过加密的 SSH 通道，转到远端机器自己的 3080。
需要说明：本轮没有第二台远程服务器，所以我实测的是“直接开放被拒绝”和“本地端口正常监听”；SSH 跨机连接方案依据 OpenSSH 的本地端口转发机制给出，没有冒充跨机实测。
6.
实测：让它只读一个项目
为了避免拿真实文件试错，我创建了一个最小测试目录，里面只有一份 README，写着三个目录的用途：
docs/放说明； src/放演示代码； tests/放验证脚本。
然后我用 Headless 模式给它一个非常克制的任务：
dsh --profile headless 「读取当前目录的 README.md，用三句话说明项目用途和目录结构。只读，不要修改任何文件。」实际返回的内容准确概括了项目用途和三个目录，进程退出码为 0。
我随后重新检查测试目录：仍然只有原来的 README，没有新文件，也没有改写痕迹。
这个测试不复杂，但它比“让 Agent 帮我做一个网站”更适合作为第一次验收，因为它一次确认了四件事：
Harness 能正常启动； 模型配置可用； Agent 能看到正确工作区； 只读边界被任务完整执行。
第一次使用，建议你也从“读”开始，再逐步增加权限：先总结文件，再运行无副作用命令，最后才让它修改内容。
7.
最常见的五个问题
1. 执行 npx 很久没反应
第一次需要下载依赖，耐心等一会儿。不要同时开多个窗口重复执行，容易造成缓存争用。
2. 浏览器提示连接被拒绝
先检查终端里的 dsh 进程是否还在，再检查 3080 是否被占用。必要时换成 --port 3081。
3. 输入框不能打字
通常是还没选择工作区。点击“选择工作区”，先选测试目录。
4. 模型列表不能用
进入“设置 → 模型”，检查 API Key 是否保存、Provider 是否启用。不要把密钥放进截图或文章。
5. 插件装完没有生效
先跑 --dump-config，确认 Bundle 已进入对应 Profile；再检查 patch 的 id、插件路径和配置是否正确。不要只看安装命令退出码。
8.
我对它的真实判断
DeepSeek Harness 现在还不是“下载完就替所有人干活”的成熟办公软件。
它更像一套正在快速长大的 Agent 基础设施：学习成本比普通聊天工具高，但上限也高得多。
打开插件列表以后，模型、会话、终端、权限、Skill、子 Agent 和 Web 界面全被平铺在同一套组合机制里。到这里，我才真正理解仓库首页那句“一切皆插件”。
这意味着以后你想换模型、换工具、换执行环境，甚至换掉默认 Agent 循环，都不必推倒重来。
但也正因为它能碰文件、命令和远程执行，新手更应该慢一点：用测试目录，权限从低到高，插件只装可信来源，远程访问不要裸露端口。
先把第一条只读任务跑通，再谈“一切皆插件”。这一步看起来慢，实际上是在给后面真正可控的自动化打地基。