DSH发布两周，它成了评价最两极分化的产品

作者｜董道力
微信 ｜ddl941110

DeepSeek Harness（DSH）发布之后，热度很高，争议更大。

8 月 13 日公开发布，到 8 月 26 日，上线仅 13 天，DSH 已经在 GitHub 积累约 19 万颗 Star、超过 2.1 万次 Fork，Discussion 编号越过。

但 Star 数量并没有带来共识。

夸 DSH 的人，往往夸得很夸张。有人把它称为“Agent 时代的操作系统”，有人在社媒上写道：用过之后“有点想抛弃 Codex 了”。还有开发者准备停掉自己做了两年的 Agent 客户端，把积累下来的能力改造成 DSH 插件。

不喜欢它的人，态度同样直接。先不论，DSH 的权限判定异常、插件安装后启动崩溃等一系列问题。现在市场上已经有一堆成熟的工具，为什么还要重新学习 Cordis、Profile、Bundle，以及一整套插件配置？

同一个项目，一边被看成 Agent 平台的雏形，一边被视作尚未完工的开发者玩具。

这种分裂并不完全来自 DSH 做得好不好。原因在于两批人想要的，根本不是同一种产品。

1

DSH 没有替所有人决定 Agent 最终应该长成什么样

DSH 的拥护者反复提到一句话：“一切皆插件。”

在 Codex、Claude Code 这样的产品里，新需求通常要等官方开发。DSH 换了一种做法：模型接入、工具、Skills，甚至默认的 Agent loop，都通过插件和公共接口组合起来。官方不再是新能力进入产品的唯一入口。

由此带来的第一个好处，是过去的积累更容易留下。

不少创业公司和个人开发者都吃过同一种苦。底层模型升级，系统提示词、工具定义和工作流便要跟着调整。更换模型供应商，往往不只是修改一个 API 地址，而是重新调试整套 Agent。

DSH 试图把这种绑定拆开。模型作为 provider 可以替换，工具、Skills 和工作流则留在 Harness 层。模型换了，之前搭建的能力不必全部重做。客户端发生变化，自己的插件仍有机会继续使用。

模型不断贬值，工作流需要升值。“一切皆插件”的意义，就是让开发者的积累尽量摆脱单个模型和客户端的更新周期。

第二个吸引力，是 Agent 的工作方式也能扩展。

Agent 并不是调用一次模型就结束。它会读取环境和上下文，决定下一步行动，调用工具，再根据工具返回的结果继续判断，直到任务结束。驱动这一过程不断向前运行的机制，就是 agent loop。工具决定 Agent 能做什么，loop 决定这些能力怎样被组织、何时进入下一步，又在什么条件下停止。

常见的扩展方式，是给 Agent 增加搜索、写文件等工具。DSH 更进一步：默认 agent loop 本身也是一个插件。开发者既可以不修改 loop，直接挂载新的工具；也可以介入循环的关键节点，甚至通过配置替换默认 loop。

更激进的想象是，Agent 可以根据任务为自己生成插件。现有工具解决不了问题，它便临时制作一个，再接入自己的运行环境。

yage.ai 的鸭哥用一句话概括了这种期待：自进化这碟醋，目前只有 DSH 预留了“物理插槽”，至于饺子好不好吃，可以以后再说。

它没有替所有人决定，Agent 能长成什么样，这就是“一切皆插件”最吸引人的地方。但同时也把产品怎样生长的问题交给了整个生态。

1

DSH 把选择权交给用户，也把麻烦交给了用户

不喜欢 DSH 的人要求很简单：一个好用的 Agent 产品。

他们并不反对开源，也不排斥插件。对于日常工具来说，Claude Code 和 Codex 把内部机制藏起来，未必是坏事。模型怎么接，工具怎么注册，本来就是产品团队应该处理的问题。用户只需要发出任务、检查 Diff，再决定是否接受修改。

到了 DSH，这些问题重新回到用户面前。

想用好它，往往要先弄明白 Cordis、Profile 和 Bundle，再选择模型、安装插件、调整配置、处理版本兼容。

DSH 给了开发者更大的控制空间，也增加了许多需要自行维护的麻烦。

哪怕抛开普通用户，DSH 的生态管理也存在问题。

DSH 没有官方插件市场，由社区形成的多个插件市场，各自使用不同的元数据，也没有统一的发布前检查和故障诊断。插件数量增长很快，但谁来检查权限，谁来验证兼容性，谁来处理恶意插件，旧版本如何迁移，项目停止维护后怎么办，都还缺少统一规则。

插件生态真正困难的地方，从来不是有没有人做插件，而是有没有人长期维护秩序。

开发者们的热情可以生成很多功能，却无法代替平台治理。生态规模越大，版本管理、安全审核、权限隔离和故障追踪就越不能依靠插件作者各自为战。

更何况，DSH 进入的并不是一片空白市场。Claude Code、Codex 和 OpenCode 已经能够读取代码、修改文件、运行命令和展示 Diff。要让用户放弃成熟的默认体验，重新学习一套概念，DSH 需要提供足够明确的回报。

DSH 已经证明，社区愿意围绕它创造东西。它接下来需要证明的是，它值得开发者们的期待。

1

DSH 是一个天生两极分化的产品

高度自定义的产品，几乎都会遇到同一个问题：开发者把空白看成接口，普通用户把空白看成缺陷。

DSH 尤其如此。模型、工具、loop 和 UI 都可以替换，意味着它的上限很高，默认体验却很难同时照顾所有人。

争议之所以迅速放大，还因为它来自 DeepSeek。

如果 DSH 由一个普通开源团队发布，关注它的大概主要是 Agent 开发者。大家会把它当作一项有趣的架构实验，接受“开发者预览版版”的粗糙，然后等待它慢慢成熟。

DeepSeek 的热度却把大量普通用户和许愿用户带了进来。他们自然把 DSH 当成 Claude Code、Codex 的直接竞争者。一个面向 Agent 开发者的预览项目，就这样承受了大众主力工具的评价标准。

DSH 的目标用户和 DeepSeek 的品牌受众，出现了错位。

很长一段时间里，DeepSeek 更像一间极客研究室。梁文锋早期说过，公司的目标是“不做垂类和应用，而是做研究，做探索”。发布模型权重、公开技术报告、开源训练和推理基础设施，构成了外界对 DeepSeek 最熟悉的印象。

但随着行业竞争越来越残酷，DeepSeek 又很难继续只做研究室。App 进入大众市场，模型被国内外云平台接入，融资、上市和商业化的讨论也随之而来，人们开始用一家公司的标准要求它。

就像有开发者吐槽，一个面向开发者的项目，居然只有webui。这刚好印证了 DSH 恰好站在两种身份的交界处的尴尬。而这种尴尬很可能会持续下去，甚至进一步影响DeepSeek在模型和AI产业接下来的竞争里的位置。

点个“爱心”，再走 吧