DeepSeek Harness 认识篇：看起来像 Claude Code，为什么官方偏要叫它 Harness？
在 Windows 上执行 npx @deepseek-ai/dsh web，浏览器很快打开一个 Web UI：输入框居中，旁边能选工作区、模型和权限模式，界面上标着"预览版"。
用过 Claude Code、Codex 或 OpenCode 的人很容易得出一个结论：DeepSeek 也做了一个 Coding Agent。这个判断没错，但只说对了一半——之前几篇已经拆解过它的插件化运行时架构，也在本地把它完整跑通，这一篇退回到最基础的问题：它明明长得像 Coding Agent，官方为什么执意要叫它 Harness？
一、先承认：它就是 Coding Agent 的形态
从用户视角看，这套流程并不陌生：打开 Web UI，配置模型，选择工作区，把项目任务交给 Agent。根据官方使用指南，Agent 可以读取和修改文件、运行命令、委派任务并维护计划，再按照权限策略处理需要确认的操作。
这已经是 Coding Agent 的基本工作形态：进入项目、获取上下文、调用工具，再根据执行结果决定下一步；用户不需要先自己拼装底层组件。这也是标题里"看起来像 Claude Code"的依据，而不只是两套界面长得相似。
把 DeepSeek Harness 看成 Coding Agent 没错，但这还不能解释它为何强调 Harness——要理解这个命名，需要把一个 Agent 产品拆开看。
二、Harness 是让模型真正做事的那一层
很多 AI 编程产品把模型、执行底座和操作界面装在一起。理解 DeepSeek Harness 时，要先把三层拆开：
- 模型：负责理解输入，判断下一步可能需要什么操作——比如读取文件、修改代码或运行测试，但它自己不会真的进电脑去执行。
- Harness：负责把判断变成行动。向模型提供上下文和工具，处理文件、命令、权限、会话与结果反馈，再把执行结果送回模型。
- Agent 产品：把模型与 Harness 组合起来，再通过终端、编辑器或网页交付给用户。
也就是"模型判断下一步 → Harness 执行与反馈 → Agent 产品交付完整能力"这条链路。
DeepSeek Harness 既提供完整的产品入口，也把执行底座的组成方式开放给了开发者。但"开放执行底座"这句话本身还是抽象的，DeepSeek 用了一句更具体的话来说明设计初衷：Everything is a Plugin.
三、"Everything is a Plugin" 不是插件市场口号
通常，产品先有一个固定核心，插件只负责扩展外围功能。DeepSeek Harness 把这条边界推进到了 Agent 内部：按照官方架构文档，模型适配器、工具注册表、会话日志，甚至 Agent Loop（模型判断—调用工具—接收结果—继续判断的执行循环）本身，都是插件。
这意味着插件不只是在扩展产品，插件本身就在组成产品。底层的 Cordis 框架负责让这些插件提供服务、响应事件，并在卸载时撤回自己注册过的作用。
一个正在运行的 dsh，可以理解为启动时组装出来的一棵插件树：开发者可以替换模型，调整文件、命令、沙箱与权限的组合，而不必把所有能力推倒重写。不过这只是架构允许的方向——可组合不等于组合过程简单，可替换也不等于没有兼容和维护成本。
四、这个区别，主要对想自定义 Agent 的人有意义
如果只想完成开发任务，应该先看默认体验、任务结果和验证能力——插件化不会自动让具体任务做得更好。只有想自定义 Agent 的人，才需要关心模型、工具、沙箱和权限能否按需组合，DeepSeek Harness 的价值也主要体现在这些边界上。
截至 2026 年 8 月 16 日，官方仓库仍将项目标为 Developer Preview，并明确提醒后续会有破坏兼容性的变更。因此这篇只能确认它的产品形态与架构方向，不能证明它比其他 Coding Agent 更好，也不能证明当前版本已经适合生产——"可替换"是设计事实，"好不好替换"还得靠后续实验回答。
结语：它为什么叫 Harness？
DeepSeek Harness 看起来像 Claude Code，是因为两者都能进入项目、获取上下文、调用工具，并根据结果继续执行；官方叫它 Harness，是因为项目还把模型、工具、会话、权限和执行循环的组合方式一并开放了出来。
最值得关注的，是它把"Agent 怎样被组装"变成了一个可拆解、可验证的问题。