adapter这个起名是不是过于笼统

[HanqingTony]

笼统的结果就是歧义，歧义对社区伤害极大。
大家都知道，dsh里本身就有个adapter插件，这个adapter是用来连接不同的llm api的。逻辑上甚至有雷同点。
到时候说起adapter不知道你在讲哪个，就更混乱了。

[Yan-Zero]

感谢指出这个痛点！在 DSH 社区的日常交流语境下，这个歧义确实非常真实。

1. 为什么容易产生混淆？

在 DSH 已有的插件生态里，大家已经习惯了用 adapter 插件来对接不同的 LLM API（模型适配器）。单说一个“adapter”，确实容易让人第一反应联想到模型连接插件。

2. 标准内部其实已经做了严格区分

在 dsh-std 的协议体系里，这两者在语义上是完全分开的：

• 对接各类 LLM 模型：标准里被严格命名为 ModelProvider（模型提供方协议），即 @dsh-std/model（models.dsh/v1alpha1），不再使用泛化的“adapter”字眼；
• 对接 DSH 宿主内核：@dsh-std/adapter-dsh 在架构上是 Host Runtime Adapter（宿主运行时适配器 / 桥接层），职责是把 DSH 内核的私有服务和内部 registry 映射转换到标准协议目录上。

3. 后续优化与改进建议

为了避免日常交流中的混淆，可以从以下两点来改进：

1. 口径与文档规范：在文档和讨论中统一使用 “宿主适配器（Host Adapter）” 或 “宿主桥接（Host Bridge）” 这种全称，避免单用一个孤立的“adapter”引发歧义；
2. 包名探讨空间：当前包名是 @dsh-std/adapter-dsh。如果大家觉得依然不够具象，未来也可以探讨更清晰的名字，比如 @dsh-std/host-dsh 或 @dsh-std/bridge-dsh。

欢迎继续提出你的建议和想法！

[Yan-Zero]

补充一个关于这套架构定位的说明（正好呼应一下 #5 提到的 Forge 式大一统疑问）：

大家之所以觉得这个名字容易混淆，很大程度是因为现在的 @dsh-std/adapter-dsh 把好几个协议支持都打包在了一起，看起来好像要做一个把所有功能全包揽的 Forge 底座。

但其实在规范设计上，协议支持的提供者（Protocol Provider）根本不需要全塞在 adapter-dsh 里：

• 目前把常用协议的宿主支持集中在 adapter-dsh 中，纯粹是为了在当前早期实验阶段方便大家一键安装、开箱即用，不需要一个一个去装零散的包；
• 在标准体系里，任何独立的插件都可以自己成为某个协议（比如 Skill、Events 等）的运行时支撑提供者（Provider），并成为下游插件的上游依赖；
• 未来完全可以根据实际需要，按领域拆成更细粒度、按需装配的独立模块，并不是非要把所有东西都绑死在同一个 adapter 插件里。

[HanqingTony]

补充一个关于这套架构定位的说明（正好呼应一下 #5 提到的 Forge 式大一统疑问）：

大家之所以觉得这个名字容易混淆，很大程度是因为现在的 @dsh-std/adapter-dsh 把好几个协议支持都打包在了一起，看起来好像要做一个把所有功能全包揽的 Forge 底座。

但其实在规范设计上，协议支持的提供者（Protocol Provider）根本不需要全塞在 adapter-dsh 里：

• 目前把常用协议的宿主支持集中在 adapter-dsh 中，纯粹是为了在当前早期实验阶段方便大家一键安装、开箱即用，不需要一个一个去装零散的包；
• 在标准体系里，任何独立的插件都可以自己成为某个协议（比如 Skill、Events 等）的运行时支撑提供者（Provider），并成为下游插件的上游依赖；
• 未来完全可以根据实际需要，按领域拆成更细粒度、按需装配的独立模块，并不是非要把所有东西都绑死在同一个 adapter 插件里。

这个想法是很好的，但是每个人都解释一遍，不如直接非描述命名了。 学习rust多好。组件都叫cargo，Trait 这种抽象的东西绝对不会有任何歧义问题。