架构与原理

从 Service 到完整的 Agent 能力

了解 DSH 如何用 Service Definition、Provider、Consumer、事件和作用域，把一个功能做成可替换的完整能力。

由 Plugin Hub 社区维护5 个章节

一个能力不是一个工具函数

DSH 把可替换能力称为 capability seam。完整 seam 至少包含三种角色：Service Definition 定义接口，Service Provider 提供实现，Consumer 把能力交给模型、UI 或其他运行时调用方。

例如 shell 能力不仅是 bash 工具。它还需要 shell service、local 或 remote provider，以及消费该 service 的模型工具。把三种角色分开，provider 才能在不分叉 Consumer 的情况下更换。

确定由谁完成一次操作时，Consumer 调用 service method。需要让多个 Plugin 观察、包装或施加策略时，能力通过 typed event 暴露扩展点。

DSH 区分 durable session events、运行中的 agent events 和 capability events。前者写入日志并支持重放；后两者协调当前请求、工具或策略，不被误当成持久事实。

text

Consumer -> ctx.<service> -> Provider
                    |
                    +-> typed events -> policy / telemetry / wrappers

Cordis waterfall event 是 around-middleware。Listener 调用 next() 会把控制权交给下游，并可以包装返回值；不调用 next() 则明确短路整条链。

DSH 用它承载 agent request、LLM stream 和工具执行等可拦截路径。只做观察或注释的 listener 必须委托；真正拥有拒绝或替换决定的 policy 才短路。

Context 可以为某个 service 创建隔离作用域。子 Context 中提供的实现不会污染父 Context；同一个 Agent 的注册也可以遮蔽全局默认值。

这使 DSH 能在一个 Host 内为不同 Agent 组合不同工具、prompt section、provider 或策略。差异属于明确的 Context，而不是散落在每个调用点的 if/else。

如果新功能只提供一个模型工具，却把 I/O、策略和实现全部写在工具内部，它很难被其他 UI、Agent 或 provider 重用。先定义 seam，再决定哪些 Plugin 分别承担 Definition、Provider 和 Consumer。

这个结构让 DSH 的插件生态共享可组合接口，而不只是积累彼此孤立的命令。