dsh deepseek-harness 官方消息汇总

20260813-2136



暂未开放 issue



讨论需前往 discussions

https://github.com/deepseek-ai/deepseek-harness/discussions/128

Bug：/api/host.listDirectory 报 HTTP 403

answer：deepseek 的神人开发，你换成 http://localhost:3080/一下就对了，不能用 http://127.0.0.1:3080/

https://www.deepseek.com/harness/

项目官网

审美和主站差异还挺大的

这个官网感觉也就。。。还行吧😐 感觉像是用 Claude 5 分钟生成的（逃

DeepSeek 插件 Awesome 列表：
https://github.com/awesome-dsh-plugin/awesome-dsh-plugin

个人感觉目前 dsh 是为了 cordis 这个醋包的饺子，用户体验上跟 codex 、cc 相比并没有特别明显的提升（主观体验）

把目光放回 cordis

https://github.com/cordiverse/paper

这篇论文系统性地描述了 cordis 插件系统，前 50p 大部分是逻辑论证。文章反复强调一点，时空可组合性，时间维度上，插件激活要可逆，空间维度上，插件激活要符合依赖条件。

实际用下来，确实是实现了无需重启的插件开关、自动撤销插件注册的 effect 、热重载、依赖检查。

但也有明显局限，论文 6.1 很明确地指出当前设计只能实现系统内的可逆，而什么是系统内的呢？

- 系统可以独占地修改某个位置，并且能把这个位置恢复到修改前的状态
- 以上任一条件不满足即是系统外



（英文原文，ai 生成翻译图，符号没对齐）

所以可以做一个实验，增加插件 a 和插件 b ，共同读写同一个 sqlite ，b 依赖 a ，a 依赖 sqlite 。



1 、同时加载 a 和 b ，正常，并且 a 给数据库加记录，b 审计正常
2 、关闭 a ，依旧加载 b ，b 被插件系统检测到依赖消失，b 变成 pending 状态
3 、重新开启 a ，a 读数据库发现之前记录（模拟一个冲突的情况），因为冲突，a 报错。此时磁盘上 a 是 enable ，但由于 a 报错，运行时自动回滚上面 2 中 a 被 disable 的状态。

实验说明一旦插件涉及到系统外，就很难保证可逆了，当然，系统也给了 disposer 操作，让开发者自己补充对系统外操作的补偿。论文 5.1.1 也提到了可逆的问题：



开发者自己应该保证插件可逆，因为系统并不会保证（尤其是涉及系统外的）

暂时还没想到这个插件系统会有哪些花活

昨天在 x 站看了一篇， 不要站在模型能力增长前方的文章。今天在看 dsh 就觉得，发出来的这个框架和插件还是挺保守的。