我领悟到了 DSH 的正确打开方式：用 DSH UI 把 Skill 产品化，改造成小说短剧创作工具

把 DSH UI 和 DSH Harness 当作宿主，由官方进行维护，然后进行插件边界设置。更准确的说法：基于 DSH 原生 Agent，提供类似 Cursor 的流式编辑器工作台，面向长文本创作领域。

插件边界（最关键）

模块	运行位置	核心职责
Host	DSH Node 宿主进程内（后端）	注册 Skill、Hook、Role 工具、挂载后端 `/oh-story` 路由，对接 Agent 执行、沙箱 FS
Browser	用户浏览器（前端 UI）	扩展 DSH Web 界面：文件树、编辑器、role 调用视图，数据请求转发给 Host 同源接口

更准确说法：基于 DSH 原生 Agent，提供类似 Cursor 的流式编辑器工作台，面向长文本创作领域。

DSH 小说短剧创作工作台

传统自研 Agent 应用：必须全套造轮子——Agent 主循环、会话管理、SSE 流式、模型对接、权限沙箱、前后端通信、事件分发，最后再做业务 UI 和业务能力。

基于 DSH 开发：全套 Agent 底层基础设施交给 DSH，开发者只聚焦两件事：定制前端工作台 UI、开发行业专属 Skills（小说 / 短剧创作能力）。

session events（会话事件）
DSH 会向外抛出会话生命周期事件：Agent 开始执行、开始写文件、工具调用完成、子 Agent 启动、流式输出变更等；插件可以订阅这些事件，不需要自己搭建消息推送。

对应你们场景：订阅 Agent 写入文件事件，实现编辑器流式修改、自动定位。
projection（投影）
把 Agent 内部完整会话原始数据（timeline、runningCalls、文件内容），做轻量化筛选映射，输出给前端 UI 使用；不用把完整庞大的会话原始数据全量推给浏览器，按需投影出编辑器、文件树需要的数据，减少前端负担。
enter（入口钩子）
插件在 Agent 执行进入某个阶段 / 某个工具调用前，可以注入自定义逻辑（类似你们的 pre-execute 写作门禁）。
waterfall（流水线 / 瀑布钩子）
串联式的执行管道：多个插件钩子按顺序串行执行（pre → 工具执行 → post），可以拦截、修改入参、校验输出（你们用来做大纲校验、写作规范拦截）。

如果自己从零搭建 Agent：要维护 SSE、长连接、消息序列化、会话同步、断连重连、状态一致性，前后端联动代码很重。

DSH 已经封装好上面这套事件、投影、钩子标准契约：

插件不用处理底层流式通信和会话同步，只写业务逻辑，联动代码更薄，也就是轻量。

本质是插槽式增量开发：既不是 DSH 自动生成整套创作界面，也不是从零搭建一套独立 Agent 前端；而是在 DSH 官方 Web 壳的基础上，把自研的业务 UI 插进预留插槽里，底层通信、会话同步、流式能力全部复用 DSH 原生基础设施。

相当于自带的应用框架与运行时底座，插件直接复用，不用重复造轮子：

代码集中在 packages/dsh-plugin/src/client/ 目录，只做和小说 / 短剧创作强相关的界面与逻辑：

不是另起一套前端工程，而是通过 DSH 预留的扩展插槽，把自研 UI 注入到官方界面中：

依托 DSH 开发无需自建 Agent 底层运行框架，开发者仅需实现业务 UI 与行业专业 Skills；DSH 提供会话事件、数据投影、执行入口、执行流水线等原生机制，大幅简化前端 UI 和 Agent 执行流程之间的联动开发成本。