炒冷饭与dsh

发布于 2026-08-16  486 次阅读


最近deepseek-harness发布了,同时发布的还有让人大跌眼镜的v4pro。第一时间稍微看了一下dsh的设计,原本以为会是和cc或者codex一样的设计。结果是热插拔的设计,一套完完全全不同的架构。当然,第一时间是想再折腾折腾六月份搞出来的whu-mcp,改造成一个插件试试手,这放在后面说吧。现在是16号的23:25,离ds陨落只剩半个小时。看得出来大家都在使劲蹬,ds的api一直在断连,也不知道是不是我的问题。

一些小测试

插件进化(?

那么既然dsh秉承着“一切皆插件”的理念,通过cordis实现了热插拔,就先vibe coding几个小插件来试试。

什么方面的插件好呢?当然我也不知道,以当时的信息来看,dsh的操作空间极其广阔,UI,tool,preset等等等等,都能够被自定义。其实大致有两个方向,一个是用户友好,一个是模型友好。如果是用户友好方向,那么就指向一些功能与工具的完善与创造,或者UI改造等。而如果是对于模型本身友好的,那么就可以指向一个奇特的自进化方向。

最基础的当然是优化模型的思考过程与操作难度,比如放权或验权的优化,这种设计动机可能由人在操作Agent时频繁遇到的环境问题或者其他摩擦产生;而更进一步的,插件可以由agent自行设计,在频繁遇到操作障碍后能够识别问题的泛化特征,并自发性地进行设计,然后自主地进行插件测试(热插拔属性很好地支持了这一点,当插件有问题时能够回退),从而解决问题。从这个角度上来讲,与其说是智能体的自进化,不如说是对目标环境的自适应,例如对于一个项目在不同的系统环境的兼容性问题,或者智能体自身训练环境与用户环境的差异问题,以及编码兼容等。

因而无聊的开了一个会话试了一下,当然当时还并不知道pro对Minimal模式的过拟合。

绝望的开始 image

好了,12点到了,还有40存款能撑多久呢?

回过来,当时的prompt是

#标准模式,貌似是pro max
https://github.com/deepseek-ai/deepseek-harness 先了解你的harness,然后自行选取几个有代表性的计算机领域或者其他领域的代表项目进行开发(如前后端开发,系统开发,安全开发,编译开发,AI开发,模型训练等等等领域,不限于这些),不限数量与资源,然后总结开发过程遇到的所有不便与问题以及程序员在这些领域进行vibe-coding时可能遇到的门槛与问题和难点,并根据这些开发新插件,且写下这些插件的说明,操作与功能

ds开了5个子agent,安排了任务并进行编码与测试,各个测试,问题与解决问题的插件如下 alt text alt text alt text

当然这只是一个小实验,看个乐子就好。而图上这些插件也只是部分需求而已,每个子agent其实都给出了完整的丰富的需求文档,就不一一给出了。所以从某种意义上来说,操作agent的是agent自己(哎也没什么稀奇的子代理闹麻了)。

emmm不过总体来说也许算是一个方向?

炒冷饭

没做完,等着吧,我正在用昂贵的token干着不起眼的小事

好,做了版demo出来,仓库链接

alt text alt text

很简单的vibe-coding,方便操作的同时也给了Agent操作接口,炒炒冷饭罢

一些想法

其实第一眼看到ds这个设计的时候我还是很惊喜的,同时也有种熟悉感,因为在这之前想了一个idea,然后用ai做了一个小demo,叫ai-bus(AI总线)。虽然这个demo我自己都没跑过,我连apikey都没给他,不过现在想想是个不错的想法,先传一波刚建的仓库 2026.7.27 README

时间在dsh发布之前怎么样哈哈哈,emmmm当然只是一个很随意的想法,在社区上应该也有类似的说法了

简单说一下吧。还是回到那个被我扒出来的api。当时为了把api包装成工具废了大半心思把前端交互撕了,再把人机验证撕了。对于人来说,前端的建设是服务于人的,从审美与交互上都方便于人的操作。但其对自动化并不友好,因而也对agent的操作有一些阻碍(当然另一方面过于暴露会导致网站的安全问题)。进而引申到应用程序本身。windows尤为如此,GUI占一大头,而对agent来说GUI后包装的接口才是其最好的工具。我们当然可以给agent接个视觉模型,通过不停的识别和定位来完成仿人类的操作,在我们项目最初期也是通过playwright来完成这种暴力的操作,但这并不直接。Agent更熟悉的环境应该是各类接口的调用以及自然语言说明的操作流程,包括外部引进的MCP与skill。但其实对接口的追寻无穷无尽,顶层的UI,到下层的接口,再到程序与文件在操作系统上的抽象,高级程序语言对汇编的抽象,汇编对机器码的抽象,再到系统对底层硬件的抽象与映射等等等等,而抽象层数越高,系统复杂性也越高,黑盒透明性也就越低,理解门槛也就越高。嗯计算机的系统已经抽象了无数层了,再叠一层agent抽象层也无妨。

回过头来,其实也许Agent与UI应该是同一级别,他们抽象的模块或者组成部分大抵是一样的(命令与代码?)。因而对于真正的AgentOS,所谓的应用应该是各类的工具与接口,正如人类使用应用时用的是键鼠这样的输入,然后得到相应的输出;在相同的使用场景中Agent调用的应该是纯粹的接口。那么这个时候人与电脑之间便多了一层Agent的交互,而输入也就变成了自然语言

那么Agent能不能完全代替UI呢?我想是不能的。UI本身其实已经发展出了艺术与娱乐功能,比如游戏,多媒体等等,Agent本身有些交互也需要UI来表现,因而这是完全不合适的。除非未来出现了新的革新式的更高级的娱乐模式和表现形式,就像手机对电视的革新,否则时机还未成熟,而且这样的时机也十分难以出现,在我们可预见的未来里是不怎么可能出现并迭代掉旧的形式的。哪怕是电视,或者更早的娱乐,现在的系统也没有直接剔除它,而是兼容,像是电视的影像传播,或是mp3之类的,现在都有能力复现甚至改进它们。所以AgentOS的概念最有可能用于工作,学习或者物联网等这些日常一些的方面上,所以其实Harness是个非常不错的应用,也算是一个试验吧。当然,未来的娱乐也必然会有AI的参与,不说别的,光是NPC的生成式对话就很让人期待了,但是再往里走吗,如果游戏设计也由AI操刀,那么游戏设计便可能是AI对人类的情绪引导设计。但这一切的前提是,AI的成本能降下来,像ds的成本其实已经很低了,但远没到价格能普及,性能能应用的地步,何况梁/又涨价了

哎,从人类的数据训练出来的AI,现在要反过来训练人类自己。不过话又说回来,哪个工具不是这样呢?简单的辩证关系罢了

晚了,就到这里吧。


花开堪折直须折,莫待无花空折枝