DeepSeek Harness 实践：模型之外的那一层

发表于 更新于 分类于 ， 阅读次数： Waline： 本文字数： 3k 阅读时长 ≈ 3 分钟

第一次看到 DeepSeek Harness，我以为它只是给 DeepSeek 模型套了一层 Web UI。真正跑起来以后，我才发现重点不在模型，而在模型之外的那一层：它决定 Agent 能看到哪些文件、可以调用什么工具、怎样执行命令，以及每次行动如何被记录和约束。

DeepSeek Harness（命令名 dsh）就是这层执行框架。官方把它概括为 “ 一切皆插件 “：模型适配器、工具、会话、沙箱、存储、调度和 UI 都可以替换或重组。

可以先这样理解：

1
2
Agent = 模型 + Harness
Harness = 工作区 + 工具 + 权限 + 会话 + 执行循环 + UI

1. 从一个空目录开始

项目仍处于开发者预览阶段，版本之间可能发生不兼容。本文固定使用 0.1.0-rc.7，并在一个可丢弃的 Git 目录中练习，避免 Agent 直接接触重要代码或私人笔记。

1
2
3
4
mkdir -p "$HOME/dsh-playground/lesson-01"
cd "$HOME/dsh-playground/lesson-01"
printf '# DSH Playground\n' > README.md
git init

1.1 启动 Web UI

1
npx @deepseek-ai/dsh@0.1.0-rc.7 web

默认地址是 http://127.0.0.1:3080。第一次打开后，需要在 “ 设置 → 模型 “ 中填写 API Key，再选择刚才创建的工作区。模型配置保存后立即生效，不必重启。

凭据默认保存在 $DSH_HOME/.credentials.yaml，通常就是 ~/.dsh/.credentials.yaml。

1.2 先只读，再修改

我先让 Agent 做了一次只读检查：

1
请只读检查当前工作区：列出文件，解释 README.md 的内容，并告诉我这是一个什么目录。不要修改文件，不要安装依赖，也不要运行网络请求。

确认它没有产生额外文件后，再给第二个任务：

1
请在 README.md 末尾增加一个“Learning Notes”章节，写三条我今天学到的 DeepSeek Harness 基础知识。只修改这个文件。完成后告诉我改了什么，并显示 diff 摘要。

这两个任务只差一句 “ 允许修改 “，Agent 的行为却完全不同。模型负责判断下一步做什么，Harness 负责把判断变成受约束的文件操作和命令调用。workspace-write 会限制写入范围，审批策略则决定哪些动作需要用户确认。单靠提示词不够，真正限制写入范围的是权限配置。

image-20260819123855684

2. 进阶

2.1 一次性任务

不需要交互界面时，可以用 headless profile 执行一次任务。它不会启动 Web 服务器，完成后把最终回答输出到终端。

1
2
npx @deepseek-ai/dsh@0.1.0-rc.7 \
  --profile headless "只读总结 README.md 的内容，不要修改任何文件。"

来源：CLI 行为参考。

2.2 安装插件

DSH 的插件不是几段提示词，而是会在本机运行的程序。安装前要看仓库、依赖和构建脚本，不要把 “ 社区市场收录 “ 当成安全审计。

我先安装了 dsh-better-sidebar。它给 Web UI 增加文件树、编辑器、终端、Git 面板和浏览器工作台。

1
2
npx -y --package @deepseek-ai/dsh@0.1.0-rc.7 \
  dsh plugin --profile web add dsh-better-sidebar@0.13.1

第一次安装停在了 ERR_PNPM_IGNORED_BUILDS。原因是终端依赖 node-pty 带有本机构建脚本，pnpm 默认不让陌生依赖直接执行。此时进入 profile 目录，明确批准 node-pty：

1
2
3
4
cd "$HOME/.dsh/profiles/web"
pnpm approve-builds
# 按空格选中 node-pty，再按回车确认
pnpm rebuild node-pty

第一次安装已经下载了依赖，但 DSH 还没有完成 bundle 注册，所以批准构建后要重跑安装命令。不要按照 pnpm peers check 的警告手工补装一串 @deepseek-ai/* 包；这些 peer 由 DSH 宿主提供，重复安装反而容易引入版本冲突。

1
2
npx -y --package @deepseek-ai/dsh@0.1.0-rc.7 \
  dsh plugin --profile web add dsh-better-sidebar@0.13.1

重启 DSH 并硬刷新浏览器后，可以在 “ 设置 → 插件 → 插件列表 “ 中看到 better-sidebar 显示 “ 已挂载、已启用 “。页面右侧会多出一个工作台入口，” 新建标签页 “ 中有文件、源代码管理、任务管理、终端和浏览器。

2.3 Plugin 与 Skill

第二个扩展是 Archify：

1
2
npx -y --package @deepseek-ai/dsh@0.1.0-rc.7 \
  dsh plugin --profile web add @tt-a1i/archify-dsh@0.1.0

它是一个 Skill-only Plugin：插件只负责把 Archify Skill 接入 DSH，真正的工作流程仍由 Skill 指导 Agent 使用现有的 Shell 和文件工具。安装后在输入框键入 /arch，能看到 archify 候选项就说明加载成功。上游把这套 DSH 适配标为实验性集成；我在 rc.7 中确认了 Skill 可以被发现，但这不代表后续版本一定兼容。

这次安装也把 Plugin 与 Skill 的区别讲清了：Plugin 改变 DSH” 能做什么 “，Skill 约束 Agent” 应该怎样做 “。Plugin 可以带来终端、界面或新的工具；Skill 更像一份按需加载的操作手册。两者可以一起交付，但不是同一种东西。

2.4 卸载与恢复

1
2
3
4
5
npx -y --package @deepseek-ai/dsh@0.1.0-rc.7 \
  dsh plugin --profile web remove dsh-better-sidebar

npx -y --package @deepseek-ai/dsh@0.1.0-rc.7 \
  dsh plugin --profile web remove @tt-a1i/archify-dsh

我这次还遇到了 EADDRINUSE。检查后发现不是插件树损坏，而是旧的 DSH 进程仍占用 127.0.0.1:3080。找到原来的终端并按 Ctrl+C，再重新启动即可。排错时要盯住第一条真正的错误，不必被后面重复包装的调用栈带走。

3. 我现在怎样理解 Harness

同一个模型放进不同 Harness，表现会很不一样。差别不只来自系统提示词，还来自可用工具、权限范围、会话记录和失败恢复方式。模型给出意图，Harness 把意图接到真实环境上，并决定哪些动作可以发生。

这也是我愿意继续折腾 DSH 的原因。它目前还不稳定，插件兼容和安装流程都有毛边。” 一切皆插件 “ 已经落实到具体结构里：文件系统、工具、UI、Skill 甚至 Agent 循环都能被重新组合。理解这一层之后，再看 Codex、Claude Code 或其他编码 Agent，就不会只比较模型榜单了。

4. 参考资料