特别之处不只是插件数量
很多系统允许增加工具或回调。DSH 的不同之处在于，Cordis 插件机制贯穿整个 Harness：核心 service、provider、policy、UI glue 和 agent loop 都服从同一套 Context、inject、event 与 effect 生命周期。
因此 Plugin 不是一个附加功能槽位，而是应用的基本组合单位。新增行为和替换基础实现使用同一种机制。
配置不是参数清单，而是可执行的架构
cordis.patch.yml 描述要挂载哪些 rows、使用哪些实现，以及每个 Plugin 接收什么配置。稳定 row id 和分层 precedence 让一套 Harness 可以被局部改写，而不必 fork 整个应用。
最终树可以 dump、比较、验证和重建。作者调试的不只是源代码，也是在打磨一个明确的运行时拓扑。
可替换与可逆来自同一套所有权模型
Service injection 让 Consumer 与 Provider 解耦，Context scope 让不同 Agent 获得不同实现，effect disposer 则确保切换或卸载时能回收注册和资源。
这三者组合后，模块化不再只是代码目录的组织方式，而成为运行时能够真正执行的隔离、替换与回滚语义。
Profile 把架构选择变成可分发成果
Cordis 解决的是如何安全组合运行时，Bundle 解决的是如何封装组合层，Profile 和 Plugin Hub 进一步解决如何把已经调好的结果交给别人。
真正的 differentiator 不是把几个文件压缩在一起，而是让专家只承担一次 provider 选择、Plugin 组合、顺序、配置和验证的复杂度。产品、运营、研究或客户团队随后可以通过明确版本使用同一套 Agent Harness，而不需要成为 Cordis 专家。
Cordis Plugin
-> Bundle patch layer
-> Profile composition
-> versioned Hub Release
-> one-command applicationHub 放大生态，但不复制 Runtime
Plugin Hub 的职责是发现和索引 Bundle、验证 manifest、展示兼容性与来源、生成安装路径，并把 Profile 固化成可验证的 Release。真正的依赖解析、patch composition 和 lifecycle 仍由本机 DSH 完成。
这个边界很重要：Hub 让分发更可信、更易用，却不引入第二套组合语义。作者看到的运行时与接收者实际启动的运行时仍是同一个 DSH/Cordis 系统。
这套机制不替你隐藏信任和环境
可组合并不等于任何组合都安全或兼容。Release 仍应锁定 runtime 与依赖版本、记录来源和验证证据，并让用户检查需要的本地输入。Secret、账号权限和外部服务状态继续留在接收者环境中。
DSH + Cordis 的价值不是消灭这些现实约束，而是让代码、配置、所有权和分发边界足够明确，使团队能够检查并管理它们。