DeepSeek Harness（命令行名 dsh）由 DeepSeek AI 开源，定位不是又一个聊天框，而是一个可以拆装的 agent 运行台。仓库副标题写得很直接：Everything is a Plugin。模型接入、工具、界面与会话都围绕 Cordis 插件体系组织，官方把它归类为 agent harness。
一条命令进入工作台
装好 Node.js 后，最省事的启动方式是：
npx @deepseek-ai/dsh web |
默认在 http://127.0.0.1:3080 起一个本地 Web UI，并在本机启动时用默认浏览器打开。通过 SSH 远程运行时，命令只打印访问地址，因为本地端口转发由 SSH 客户端或编辑器负责。不想自动开浏览器，加 --no-open 即可。
想改源码，则从仓库构建：
git clone https://github.com/deepseek-ai/deepseek-harness.git |
pnpm run build 负责准备构建产物，pnpm dsh web 直接使用这些产物，不会每次重新构建。仓库另提供 pnpm run dev:web，在同一个终端里完成构建、启动，并在源码改动后重建客户端包；make help 会列出 Web 与桌面端对应的 Make 目标。要改插件或界面，官方建议先读 docs/development.md 与 docs/architecture.md，仓库还为 agent 准备了 AGENTS.md。两条启动路径最终都落到同一个 Web 界面，区别只在后续升级和改代码的便利程度。
插件化的实际含义
“一切皆插件”描述的是结构，不是营销口号。DSH 把功能注册交给 Cordis，官方论文称这种设计面向“时空可组合性”。对使用者来说，同一套界面里可以替换不同层次的部件，不必等主程序把每个需求都做进去。第三方插件仓库可以打上 dsh-plugin 话题，方便在 GitHub 上被检索；仓库同时维护 GitHub Discussions 与 Discord，用于反馈和讨论。
插件化也带来一个直接后果：DSH 的能力边界不是由官方一家决定的。模型接入、工具和界面都可能来自社区，装什么、信什么需要自己判断。官方没有承诺所有插件都经过同一套审计，插件作者能拿到的权限也取决于宿主开放了哪些接口。
一个具体的使用场景
假设你在一台开发机上维护几个仓库，希望 agent 能读文件、跑命令、保留多轮会话，又不想在终端、编辑器和聊天窗口之间来回切换。DSH 的本地 Web UI 把这些入口收在同一个页面里，会话与工具调用共享同一份工作目录。一个常见的流程是让 agent 先读 README 与目录结构，再运行测试命令，最后把修改点写回文件，上下文始终留在同一个会话里。远程开发时也可以把 DSH 起在服务器上，通过 SSH 把端口转发到本机浏览器，web 子命令对两种启动方式都适用。
与聊天客户端的分工
普通聊天客户端以消息为中心，工具调用是附加能力；DSH 把会话、文件、终端和工具放在同一层，插件还能替换界面与模型接入。代价是配置面更大。想要开箱即用的问答体验，直接用现成客户端更省事；愿意维护插件清单和版本的人，才会用到它的可组装性。它也不等同于 IDE：代码编辑和调试仍应交给专门的编辑器。已经习惯终端型 agent 的用户，增量价值主要在统一界面和插件组合，而不是模型能力本身。
开发预览期的限制
README 用大写提醒项目处于 developer preview，会有兼容性破坏，升级前应查看变更说明；运行前还应阅读仓库的 SAFETY.md。插件来自不同作者，权限、质量和维护状态差异很大，涉及文件写入和命令执行的插件要先看清它要求的能力。本文按官方 README 与仓库元数据整理，未在本机完整实测。
适合谁
适合把 agent 当日常工作台、愿意自己挑插件并承担升级成本的重度用户，以及需要把内部工具接进同一套会话的人。只需要稳定聊天窗口、不打算改工作流的用户，不必为插件体系付出学习成本。
官方入口
- 仓库：deepseek-ai/deepseek-harness
- 文档：deepseek-harness.github.io
- 许可证：MIT