第 2 卷

我们可以看到，dsh 并不是简单堆砌的插件包，所有插件在运行时身份对等，没有固定不可改动的特权内核，它们必须依靠依赖关系组成一棵有机的插件树。整体构建在 Cordis 微内核调

度层之上——Cordis 负责插件的生命周期管理与动态重组，不介入具体业务逻辑，形成了一套逻辑自洽、可以动态重组的完整 Agent 运行系统。

依托开放的插件机制，你可以复用社区插件，也可以开发并发布自己的插件，共建开源生态。

同时我们也需要客观认清现状：dsh 当前还处在开发者预览阶段，代码与功能都在高速迭代，距离稳定可用的生产级框架仍有一段距离。

这里我特别说明一下，dsh 本身暂时并不具备完整的自动进化能力，但它的两项底层设计，恰好为自进化提供了最稀缺的工程条件。具体是哪两项设计？我们接下来详细拆解。

dsh 的独特设计

第一，极致的全插件化，靠一套可组合的时空撑起来。大多数框架里，工具、模型是可插拔的，但核心循环基本都是写死的，你想修改它的行为，只能去改源码。dsh 反其道而行：模型

适配器、工具、会话存储、权限策略，甚至连 Agent Loop 本身，全都是可替换的插件，整个系统没有特权插件。

制。一个插件注册的资源，会在它卸载时被自动、完整地回收；一个服务出现或消失，依赖它的插件会自动联动处理。

正是这套时空可组合性，让“全插件化”不再只是口号，而是真实可用的工程能力。你既能像搭积木一样自由拼装，又不会留下任何“垃圾”或悬挂状态，热替换、动态组合这些高级玩法才有

了真正的地基。

第二，Append-Only 会话日志：一条完整的“黑匣子”轨迹。dsh 有一条贯穿始终的铁律—— 模型所见等效于日志记录（Model-visible means logged）。任何进入模型请求的内容，都

必须能从会话日志里完整重建出来。基于这条铁律，dsh 把 Agent 的每一步思考、工具调用、策略决策、状态变化，都用追加唯一的（append-only）日志完整记录并投影出来。

这意味着 Agent 的一次完整运行，就是一条可回放、可追溯的“飞行轨迹”，出了事故能还原现场，复盘时有据可查。而这，恰恰是 Agent 审视自己的能力，因为一个系统要进化，光能

改还不够，还得能看清自己走过的每一步。

dsh 的四种用法

理解了 dsh 是什么、新在哪儿，接下来的问题就是：它该怎么用？

dsh 并不是只有一种用法。我把常见的几种方式都讲给你，你可以对号入座。

第一种：把它当 Agent 工具用。你直接跑 dsh，用官方预设（preset）组合出一套能用的 Agent，接上自己的模型，让它帮你干活。这是成本最低的用法，适合我就想先有个能跑的

Agent。

第二种：把它当插件平台用。你可以安装自己感兴趣的插件，或者在它的扩展点上写自己的插件，比如加一个工具、接一个模型，装进自己的插件配置 (cordis.yml)/ bundle。这是大多数

开发者最常用的层次。

第三种：把它当二次开发平台用。你可以深度融合自己的业务逻辑到 dsh 中，这一种较为复杂，需要对自己的业务逻辑，需求，dsh 的能力有全面深入的理解。这对开发者有一定的技术

要求。

第四种：把它当自进化基础框架用。这是 dsh 最有难度，也是最有野心的用法，你利用它的时空组合特性和 Append-Only 日志等能力，去构建能自我改进、能持续进化的系统。我们这

门课的实战篇，就会带你探索这第四种用法。