官方可以出一个功能路线图吗

[WaynePluto]

很早就跟随dsh了，我喜欢基于dsh封装自己的工具，然后就结合自己的需求写插件。
但是最近发现dsh更新好快呀，前脚我刚写一个插件，后脚官方就内置了，这样显得我很呆。
到最近的0.1.7-rc1我写的插件里被官方替代都已经有好几个了，比如目录树，文件预览，工具调用和思考折叠，子代理委派深度等等。
所以能不能出个文档或者置顶帖，介绍下官方功能路线图，这样我想开发新插件时，如果发现官方有相关计划，我就不用提前做了。

[jhc888007]

是不是违背了everything is plugin的初衷了？到底什么是框架该做的事，什么是插件该做的事。如果过于简易太难上手了，应该也是出一个默认插件库才对吧

[WaynePluto]

我很赞同你这个说法，原本我就是觉得官方就应该越简单越好，多提供接口，定位应该是harness界的emacs，让社区玩家玩出花来。
对于小白玩家，应该是推荐官方默认插件库，或者几个社区插件库，类似spacemacs， doom emacs。
这样的话， 建议官方把deepseek-harness分成两个仓，一个是核心仓库，就提供最基本的功能，比如预设只保留一个极简模式，工具就两个，只保留最核心的agent，极简版dsh。
另一个仓库就是默认插件库，小白用户也可以通过极简dsh自己去装插件库里面的插件，就像拼乐高一样。

[LaneSun]

官方出 1.0 之前插件的开发体验基本上就是这样子的，官方不可能放社区自由发展的，Emacs 是因为 Lisp 系社区开发质量比较高，且不太需要关注性能和硬边缘优化，所以才行的通的。

而 DSH 的话国内开发者的开源意识本来就有些倾向于个人主义或者说无视规则（平心而论，你看过多少国内个人开源项目不会夹带私货的，各种 ACG 和 IP 还有梗满天飞，正经开发是不太能接受这些的），再加上现在很多都是 Agent 辅助开发，因此质量进一步不可控（不是说质量一定不好，但比起 Emacs 社区更加参差不齐是肯定的），因此官方极不可能放任社区自由发展。

最有可能的路线是官方出官方插件库（目前其实就是这状态），逐渐补齐所有常见用例，然后长尾由用户自定义，因此所谓的核心稳定是必然的，DSH 的核心那个叫什么 Cordis 的对外接口确实不怎么变化，你可以看到它已经不是开发版本了。但真正的插件开发永远是依赖导向的，Cordis 支援的是 DSH 插件的热重启，而不是 DSH 整个对外接口的 Solid：你想做一个侧栏 Git Diff，你的视图怎么向侧栏嵌入？找官方的侧栏视图插件作为依赖，那么官方的侧栏视图插件的接口稳定吗？还没有。

诸如此类，考虑到 AI 行业发展的速度，我估计 DSH 插件使用的接口中总有一部分是不稳定的（如果大部分都稳定下来了，反而会让人担心 DSH 这个项目的前景，毕竟对于软件来说重构就是生命力），这与它的框架是否稳定没有关系，框架是可以很稳定的，但插件开发的依赖是会增长的，因此永远无法稳定。除非你只以稳定的部分为基础开发，但那很少见，大多数人开发插件都会修改 UI，而 UI 是必然会汰换的。

关于你说的分两个版本，我个人也比较喜欢这种模式，但客观来说我觉得这不太现实，写过代码的人应该有感觉，库代码是库代码，应用代码是应用代码，只有基于库的应用，没有基于应用再封一层的应用，因此如果是极简和标准两个版本的话，要么就是极简版本沦为基本无界面的库类型上游，不被直接使用，要么就是直接消亡。无论怎么极简，产品就是产品，只要两者的生态还是贯通的，那么对 DS 来说，这是用两个产品的维护成本去维护大家只用其中一个产品，意义不大，我个人觉得不太可能，也不太能找到前例。

[rayadesune]

一些明显看得出官方要做的就提前不做了吧

[turtle1999]

基础体验官方都会不断补齐的，但每个人的需求应该是很长尾的