SaaS Metrics
GitHub Issue
SSH、Linux、远程服务器、云 GPU、长期运行任务与计算资源管理生态链
考虑到tui主要面向专业用户，在科研侧，tui需要集成的功能：
- Autodl/远程服务器适配，SSH与Linux命令行端一建部署，开包即用，win/apple/Linux图形化端ssh控制，提供多种远端无需上传Key的运行方式，保证信息安全
- 长期仿真任务值守，多CPU，多GPU计算资源管理，调度与可视化
- dsh-agent插件链，workplace，workflow，提示词配置文件一建克隆到远端，自动增量合并
- ※tui本体做好一键部署，接口注册，克隆到远端，自动增量合并的基础设施，其余增强功能由tui插件实现，做好与dsh本体插件的兼容性和处理
- tui定位是dsh的远程ssh生态链的底层
此功能目前暂无开发者负责，欢迎有兴趣的开发者认领，避免重复工作。
View Raw Thread
Developer & User Discourse
T-Auto • Aug 15, 2026
@ccch1mneyyy @CikeSeven @makoMakoGo @TYCT-0926 @FUSU123fusu @Hariketsu @ybh618618 你们怎么看
T-Auto • Aug 15, 2026
ssh远端部署本就依托tui进行，此issue是希望依托tui形成一个远端部署，插件克隆，工作区迁移的生态链，而非把tui本身做的臃肿，生态链的插件挂在在组织仓库
T-Auto • Aug 15, 2026
这个概念的终极成果是类似conda之于python。dsh生态是一直更新的个不稳定的混乱状态，而workplace，workflow，prompt迁移本身需要依赖链可追溯，从而形成稳定生态
FUSU123fusu • Aug 15, 2026
支持「tui 做基础设施、增强功能走插件」的分层，补几个来自 Windows 重度使用者的具体观察：
1. **一键部署/克隆的技术核心其实是 profile 同步**：dsh 的 profile 天然就是声明式的（package.json + cordis.patch.yml + settings.yaml），「克隆到远端」约等于 `dsh plugin` 导出/导入 + 增量合并策略。建议先在 dsh 本体做 `profile export/import`（含 git 依赖 pin 成本地 tgz，否则每次 install 拉 HEAD 会出各种解析事故——我在自己 profile 上踩过三次），tui 再做 GUI 封装。
2. **免上传 Key 的运行方式**：SSH agent forwarding 比下发密钥安全且模型可解释，但需要 tui 侧把「远端执行」抽象成和本地 bash/pwsh 平级的 executor，这层最好留在 dsh 本体（terminal/subprocess 服务已有抽象），tui 只接展示与控制。
3. **长期任务值守**：dsh 已有 jobs/schedule 服务的雏形，tui 缺的主要是可视化（任务列表面板、日志跟随）。这个插件化没问题，但事件订阅的稳定 API 需要先在本体定下来，否则插件会跟着内部事件结构一起碎。
4. 一个现实优先级建议：跨平台稳定性（Windows 渲染/子进程）还有不少存量 issue，基建先做扎实的收益大于先铺远端生态。
需要人手的话，我可以认领「profile export/import + git 依赖固定」这一块。
1. **一键部署/克隆的技术核心其实是 profile 同步**：dsh 的 profile 天然就是声明式的（package.json + cordis.patch.yml + settings.yaml），「克隆到远端」约等于 `dsh plugin` 导出/导入 + 增量合并策略。建议先在 dsh 本体做 `profile export/import`（含 git 依赖 pin 成本地 tgz，否则每次 install 拉 HEAD 会出各种解析事故——我在自己 profile 上踩过三次），tui 再做 GUI 封装。
2. **免上传 Key 的运行方式**：SSH agent forwarding 比下发密钥安全且模型可解释，但需要 tui 侧把「远端执行」抽象成和本地 bash/pwsh 平级的 executor，这层最好留在 dsh 本体（terminal/subprocess 服务已有抽象），tui 只接展示与控制。
3. **长期任务值守**：dsh 已有 jobs/schedule 服务的雏形，tui 缺的主要是可视化（任务列表面板、日志跟随）。这个插件化没问题，但事件订阅的稳定 API 需要先在本体定下来，否则插件会跟着内部事件结构一起碎。
4. 一个现实优先级建议：跨平台稳定性（Windows 渲染/子进程）还有不少存量 issue，基建先做扎实的收益大于先铺远端生态。
需要人手的话，我可以认领「profile export/import + git 依赖固定」这一块。
T-Auto • Aug 15, 2026
> 支持「tui 做基础设施、增强功能走插件」的分层，补几个来自 Windows 重度使用者的具体观察：
>
> 1. **一键部署/克隆的技术核心其实是 profile 同步**：dsh 的 profile 天然就是声明式的（package.json + cordis.patch.yml + settings.yaml），「克隆到远端」约等于 `dsh plugin` 导出/导入 + 增量合并策略。建议先在 dsh 本体做 `profile export/import`（含 git 依赖 pin 成本地 tgz，否则每次 install 拉 HEAD 会出各种解析事故——我在自己 profile 上踩过三次），tui 再做 GUI 封装。
> 2. **免上传 Key 的运行方式**：SSH agent forwarding 比下发密钥安全且模型可解释，但需要 tui 侧把「远端执行」抽象成和本地 bash/pwsh 平级的 executor，这层最好留在 dsh 本体（terminal/subprocess 服务已有抽象），tui 只接展示与控制。
> 3. **长期任务值守**：dsh 已有 jobs/schedule 服务的雏形，tui 缺的主要是可视化（任务列表面板、日志跟随）。这个插件化没问题，但事件订阅的稳定 API 需要先在本体定下来，否则插件会跟着内部事件结构一起碎。
> 4. 一个现实优先级建议：跨平台稳定性（Windows 渲染/子进程）还有不少存量 issue，基建先做扎实的收益大于先铺远端生态。
>
> 需要人手的话，我可以认领「profile export/import + git 依赖固定」这一块。
感谢认领，考虑到向后兼容，生产稳定，以及dsh本身接口多变的特点，profile export/import + git 依赖固定要尽可能的谨慎和前瞻性
>
> 1. **一键部署/克隆的技术核心其实是 profile 同步**：dsh 的 profile 天然就是声明式的（package.json + cordis.patch.yml + settings.yaml），「克隆到远端」约等于 `dsh plugin` 导出/导入 + 增量合并策略。建议先在 dsh 本体做 `profile export/import`（含 git 依赖 pin 成本地 tgz，否则每次 install 拉 HEAD 会出各种解析事故——我在自己 profile 上踩过三次），tui 再做 GUI 封装。
> 2. **免上传 Key 的运行方式**：SSH agent forwarding 比下发密钥安全且模型可解释，但需要 tui 侧把「远端执行」抽象成和本地 bash/pwsh 平级的 executor，这层最好留在 dsh 本体（terminal/subprocess 服务已有抽象），tui 只接展示与控制。
> 3. **长期任务值守**：dsh 已有 jobs/schedule 服务的雏形，tui 缺的主要是可视化（任务列表面板、日志跟随）。这个插件化没问题，但事件订阅的稳定 API 需要先在本体定下来，否则插件会跟着内部事件结构一起碎。
> 4. 一个现实优先级建议：跨平台稳定性（Windows 渲染/子进程）还有不少存量 issue，基建先做扎实的收益大于先铺远端生态。
>
> 需要人手的话，我可以认领「profile export/import + git 依赖固定」这一块。
感谢认领，考虑到向后兼容，生产稳定，以及dsh本身接口多变的特点，profile export/import + git 依赖固定要尽可能的谨慎和前瞻性