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

本文来自微信公众号： 硅星人Pro ，作者：董道力

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

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

但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产业接下来的竞争里的位置。