关键词日报里突然出现了“deepseek harness”。若只看名字，很容易以为 DeepSeek 发布了一个新模型；可 DeepSeek 官方仓库 把它定义为开源的 Agent harness，即用来装配模型、工具、会话和用户界面的运行框架，命令行程序叫 dsh。模型负责生成下一步建议，harness 则负责把建议放进能够读文件、调用工具、请求审批和继续对话的工作流程。换模型不等于换 harness，反过来，安装 harness 也不等于已经取得模型的 API 额度。

配图来自 DeepSeek Harness 官方仓库的 Web UI 文档，不是本站本机运行截图。

官方 README 目前明确写着 developer preview，并提醒可能出现破坏兼容性的更新。下面的安装命令和界面操作均来自项目文档，我没有在这台博客环境里运行 DeepSeek Harness，也没有拿自己的项目测试插件的稳定性。这种区别看似啰唆，却能避免把“官方说明支持”写成“本站已经验证”。

#先从本地 Web UI 走通

中文 README 给出的最短启动方法，是在已安装 Node.js 的环境中运行：

1

npx @deepseek-ai/dsh web

命令默认在 http://127.0.0.1:3080 启动本地 Web UI，本机运行会尝试打开浏览器；加 --no-open 可只起服务，不自动弹出浏览器。通过 SSH 运行时，文档说程序仅打印访问地址，端口转发归 SSH 客户端或编辑器处理。127.0.0.1 是本机回环地址，不能因为它默认只在本机访问，就把未加固的开发预览版直接开放到公网。要对外发布须先看项目的 公开部署说明，不要随手将端口映射到 0.0.0.0。

若不愿通过 npx 运行当前 npm 包，README 另给出从源码构建的方法，适合打算检查源码或开发插件的人：

1
2
3
4
5

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

这两种方式的版本未必一致：npm 发布包有自己的版本，克隆仓库则拿到当时分支上的代码；在快速迭代的预览期，照着新文档操作旧包而找不到入口，先确认版本与文档对应关系，比盲目更换 API Key 更有效。pnpm dsh web 使用前一步构建出的产物，不能跳过 pnpm run build 再把缺文件归咎于模型。

Web UI 启动后仍不能马上让 Agent 干活。按 官方 Web UI 指南，先到“设置 → 模型”填写 DeepSeek API 密钥并保存，模型路由随即生效，不需要重启服务；使用其他模型供应商或 OpenAI 兼容端点，则需对照 模型配置指南。API Key 是敏感信息，别塞进示例仓库、截图、聊天记录或提交到 Git。设置好模型后，点击“选择工作区”，添加并选中要操作的项目目录；未选择工作区时会话输入框不可用。dsh 启动所在的目录会成为默认文件系统位置，这一点值得提前留意：不宜从存有密钥或个人资料的上级目录随手启动。

工作区选好后，官方示例任务是“概述仓库并指出主要包”。我也会先选这类只需读取的任务，观察它读了哪些文件、给出了哪些引用，再逐步尝试改文件和运行测试。根据项目文档，Agent 可以读取与编辑工作区、执行命令、委派工作、维护计划；操作是否先请求审批，取决于当前权限策略。看到一次审批弹窗，也不能推断其他操作都必然弹窗，测试新工具时应使用可丢弃的仓库和不含真实凭证的环境。

#“一切皆插件”到底意味着什么

我觉得这个项目更值得看的地方并不是聊天框，而是 架构文档 对扩展位置的划分。DeepSeek Harness 基于 Cordis，模型适配器、工具注册表、会话日志和 Agent 循环都以插件参与共享上下文；插件贡献服务、事件及可撤销的注册效果。想接一个模型供应商，可以在 ctx.llm 注册适配器；想让模型用一个新工具，可在 ctx.tools 注册；想改变文件访问策略则看 ctx.fs，要在请求、工具或回合边界插入行为则使用相应事件。这里的“插件”有明确接入点，不是把任意脚本丢进目录就会自动变成安全的 Agent 功能。

运行配置另有 profile 概念。官方列出的 Node 应用入口包括 web、headless、sdk、sdk-minimal 和 acp 等；同一套能力可以由不同 profile 装配给浏览器、无界面运行或外部集成使用。普通读者先用 web 就够了，开发者要理解某项行为究竟从哪里来，可沿 profile、插件配置、服务注册和会话事件逐层追踪。相较于只会聊天的模型，harness 的价值在于把工具使用与运行状态组织起来；相较于一份简单的“Agent 提示词”，它多出了进程、文件系统、权限和配置的工程责任。

这也解释了为什么它与本站写过的 Ponytail 规则技能 和 Cloudflare Security Audit Skill 不是同一层东西。技能侧重告诉现有 Agent 如何完成特定任务；Harness 负责提供运行任务的环境、模型适配、工具和会话。至于后两篇所述的技能能否在 dsh 中直接安装、行为是否一致，必须按 DeepSeek Harness 的插件与技能兼容文档逐项验证，不能因为都叫 Agent 就推断互通。

#安全说明比安装命令更重要

官方 SAFETY 文件 写得很直接：项目处于实验性开发预览阶段，尚未完成安全审计，也不应被当作可直接投入生产的安全产品。它可能执行模型生成的代码和命令、加载第三方插件，并访问当前环境允许的网络、进程、文件和凭证。模型输出错误、恶意输入、配置失误或不可信插件都可能造成文件损坏、凭证泄露和其他意外。沙盒、审批与权限控制能降低风险，却不能保证隔离，尤其不能保护那些本来就允许 Agent 访问的资源。

如果只想了解它，不必一开始就在长期使用的工作目录安装所有插件。我会准备一个没有密钥的样例仓库，限制系统账户权限并保留备份；先让它只读概述目录，检查模型路由和审批，再决定是否开放编辑或命令执行。第三方插件应分别审查来源、它注册了哪些工具和事件、是否向网络发送数据，以及更新后权限是否变化。开发者预览版更新很快，配置和插件兼容性也可能改变，遇到教程失效时最好先对照当前仓库文档与版本，而非相信页面上的“免配置一键运行”。

日后要做真正的效果评测，还需要固定同一个仓库与任务，记录模型、版本、插件集合、权限策略、执行命令、修改的文件和测试结果，比较成功率和返工量。没有这些记录，写“比某个 Agent 强”或“能自主完成复杂项目”，不过是把 README 的愿景改写为本站结论。我现在能确认的是安装入口、工作区步骤、架构和项目方明确承认的安全限制；想实际采用它，还得在自己的隔离环境里验。

资料：官方仓库与中文 README · Web UI 入门 · 架构文档 · 安全说明