上周末 DeepSeek Harness 刚出来的时候，我发现即刻上都是吐槽的。
"这明显是个玩具，准入门槛太高了"
"这么一个灵活的玩意儿，注定是技术人的自嗨"
然而到今天，我发现 github 上的 Star 数已经超过 16w+ 。也就是说，大家开始正视它了，我好奇，这样一个"技术人的玩具"怎么就逆转了口碑呢？
怀着好奇的心理，我使用源码部署的方式在本地安装了一个 DSH。
（本身在安装之前，我也看过很多公众号的介绍。我最感兴趣的其实就是 DSH 的插件体系，所以在这里我就不装了，摊牌了------我就是奔着了解 Cordis 去的。）
动态装载插件
既然 DSH 的理念是"一切皆插件"，那我就试试它能不能把我之前做的小工具 Browser-Bridge 给安装上来。
（这里补充下，Browser-Bridge 有 server 和 local-proxy 两个进程。server 负责管理浏览器 , local-proxy 是作为本地机器的后台进程常驻的，主要为了保活和server的连接。）
我就这一句话，然后傻等10多分钟。我感觉是因为没有提前说明整个项目的结构的问题，最后我放弃了，主动告诉了它该怎么做。在我循循善诱下，最终还是搞出来了我第一个plugin。
（经过一小时，终于注册成功了一个MCP...）
如果只是简单的 MCP，那我可能潜意识里把 MCP 和 DSH 的 plugin 花了等号，事实是这样吗？我在想，我是不是走错方向了？
随后，我到处点了点，发现 DSH 自己定义的插件有这么些。
这里应该就是官网说的"一切都是插件"，如果这些地方都是可以替换的，那这个 Harness 确实也挺难得的。毕竟像 Claude Code、Codex 这种，你是只能通过 Hooks，或者事件来扩展功能，而不能替换原有的功能。
Pi 和 DSH
讲到灵活，这让我想起了 Pi。它不也是足够灵活吗？Pi 除了 Agent Loop 是固定之外，其他的地方都是可以通过事件回调来自定义的。如果 DSH 也提供了一套编程框架，那从这个角度来看，DSH 似乎和 Pi 的差别不大，所不同的只是编码风格以及编排流程的方式不一样。
难道真是这样？
社区的 Plugin
怀着疑问，我点开了 dsh-plugin 下面的项目。
我只找了几个之前在公众号看到过的，比较有名的项目，dsh-tui、dsh-web-ui、dsh-desktop。我发现他们都有类似的使用方式。
每个子模块都有一个 cordis.patch.yml。同时，package.json 里面会有 dsh 相关的配置（bundle、client等）
具体代码在使用时又会有 effect、inject等。
看到这里，我猜测整个 Cordis 做的就是加载 plugin。plugin 之间的依赖关系需要通过配置文件先声明，然后再在代码中 inject。DSH 把所有的抽象组件，通过 plugin 这个概念来组合，Cordis 可以看做管理 plugin 的 Ioc 容器。
等等，这里好熟悉。Java 中 Spring 早期的版本中不也是这样吗？只不过 Spring 是通过 xml 来约定对象之间的依赖关系，然后进行对象的生命周期管理。
而 Cordis 面向的是一个个功能模块，所以它只提供一个 Context, 把整个容器的引用（如果了解 Spring 的朋友，可以把这里理解成 ApplicationContext）提供给开发者，由开发者自己决定 inject/provide 的具体内容（可能是某个plugin中的部分共享对象）。
如果把 Agent_Loop、Context、Session、tool等都看做作抽象的 plugin，plugin 自己选择依赖谁以及如何加载、何时加载，那这一切就都说得通了。
我想起在构建 Spring 应用时，我需要按部就班地集成 web、logger、test、mybatis。但仔细回想，发现其实这些功能模块也不一定都需要，完全都是按需集成。只是因为后端的需求常常和这些模块绑定，并不是 Spring 只能这样使用。
感觉 Cordis 似乎想做和 Spring 一样的事情。提供一个统一的开源 Agent编程框架，降低 Agent 的构建门槛。
**但就目前的状况来说，DSH 的灵活性和降低 Agent构建门槛似乎完全不沾边。**项目还在很早期，底层 API 未必稳定，而且各种层出不穷的扩展实现，很容易让人摸不着头脑。
社区的力量
不过，当你使用 Spring 作为应用底座去集成时，你会发现你几乎不太需要了解底层的实现细节。比如：web 模块的实现到底使用 Tomcat 还是 Jetty ，或者是 Undertow？logger 模块到底使用了 logback，还是 log4j？
换到 Agent 构建中来看，也是如此。比如：我想解决上下文压缩的问题，但是现在上下文压缩的策略几乎都是各家各自实现，没有专门解决上下文压缩的一个包。记忆也是，各种记忆系统的使用都有各自的API，集成到Agent后，就很难替换。如果，在此之后有层抽象的中间包，能屏蔽底层的具体实现细节，那就真正地做到了可拔插。
按照这个思路来看，如果 DSH 的社区能保持活跃，这个还是很有机会的。毕竟现在做 Agent开发 的时候，几乎都是自己从头定制到尾，从来没有想到过能有一个类似中间件的模块。