前言¶
在 DSH（DeepSeek Harness）里跑多角色协作时，常见做法是自己在会话里拆任务、再手动起子代理。若团队已经在 Guild 侧用「专家团看板」管任务，执行层仍落在 DSH，中间就需要一层桥：把看板上的任务变成 DSH 里的一次性子代理调用，并在 GUI 里能看见进展。下面介绍社区插件 dsh-guild-bridge（维护者 r-ayin），它做的就是 Guild 专家团与 DSH 执行层之间的路由与可见性。
这是什么¶
dsh-guild-bridge 的定位可以用仓库简介概括：把 guild 专家团看板桥接到 DSH，将 guild 任务路由为 DSH 的一次性（one-shot）子代理执行，专家在 GUI 中可见。
插件归类为工作流，以 MIT 许可证发布，当前 package.json 中版本为 0.0.1。工程由 dsh-super-injector 的 dev_scaffold_plugin 脚手架生成，运行时要求 Node.js >= 20，并依赖 DSH 生态中的 @deepseek-ai/dsh-llm、@deepseek-ai/dsh-tools、cordis、schemastery 等 peer 依赖（版本范围见仓库 package.json）。
核心功能¶
根据已公开的 README 与 package.json 描述，可核实的能力包括：
- 桥接 Guild 专家团看板与 DSH：任务来源在 guild 侧，执行落在 DSH。
- 任务路由：将 guild 任务转为 DSH 一次性子代理（subagent）执行，而不是在插件内重写一套执行引擎。
- GUI 可见：执行过程对专家在 DSH GUI 中可见，便于跟进子代理状态。
README 未展开具体 API、配置字段或看板字段映射；若你需要对接细节，应以仓库源码与后续文档为准。
安装与启用¶
已抓取资料中的官方流程面向开发与注入，而非独立的 dsh plugin add 一行命令。请按仓库说明操作。
构建¶
在插件目录执行：
bash scripts/build.sh
该步骤会按 package.json 中的 build 脚本完成构建，产物在 lib/（main 指向 ./lib/index.js）。
注入到 DSH¶
在 dsh-super-injector 注入器环境内，对本插件目录执行：
dev_inject_plugin <本目录>
将 <本目录> 替换为 dsh-guild-bridge 仓库的根路径。插件通过 Cordis bundle 配置（dsh.bundle.patch 指向 ./cordis.patch.yml）参与 DSH 装配。
本地校验类型可运行：
npm run typecheck
典型用法¶
当前 GitHub README 未提供端到端示例（例如看板上创建任务后在 GUI 中的操作步骤）。合理的使用路径是：完成上述构建与 dev_inject_plugin 后，在已接入 guild 专家团看板的环境里派发任务，由插件将任务路由到 DSH 子代理；具体触发条件与界面入口需结合你当前的 DSH 与 guild 部署查阅源码或向维护者提 Issue（bugs URL）。
适用场景与注意¶
适合谁
- 已在或计划使用 guild 专家团看板 做任务编排，希望执行统一落在 DSH 子代理 上的团队。
- 需要在 DSH GUI 中观察子代理执行、而不是只在终端日志里排查的开发者。
注意事项
- 插件在当前 dsh 进程的权限下运行；注入或启用前请阅读仓库源码与 MIT 许可证，确认行为符合你的安全与合规要求。
- 社区目录 SkillHub 插件页 与 GitHub 仓库由社区维护，与 DeepSeek / 幻方无官方从属关系；安装与版本以你实际使用的分发渠道为准。
- README 以开发构建与注入为主，生产环境集成方式可能随 DSH 与 super-injector 演进变化，升级 peer 依赖时注意
package.json中的版本区间。
结尾¶
dsh-guild-bridge 把 guild 专家团看板与 DSH 一次性子代理执行连在一起，并强调 GUI 可见，适合把工作流留在看板、把算力与工具留在 DSH 的集成场景。更多信息见 SkillHub 目录页 与 GitHub 仓库。
