14 适用场景与风险提示

14 适用场景与风险提示#

⚠️ 重要风险提示：在决定是否使用 dsh 之前，请务必完整阅读本章。DeepSeek Harness 目前是 v0.1 开发者预览版，不是生产就绪的产品。理解它能做什么、不能做什么、风险在哪里，能帮你避免很多不必要的坑和失望。

工具本身没有好坏，只有适合不适合。dsh 不是银弹，它在某些场景下非常好用，但在另一些场景下完全不适合。这一章我们不讲技术细节，只帮你做「要不要用 dsh」的决策。

⚠️ 重要风险提示（必读）#

在看适用场景之前，先把最重要的风险说在最前面——这不是官样文章，是你必须知道的事实：

⚠️ DEEPSEEK HARNESS v0.1 开发者预览版风险声明

  1. 版本定位：当前是 v0.1 开发者预览版（Developer Preview），不是稳定版，不是 beta 版，更不是生产就绪版本。

  2. 接口快速演化：核心插件接口、Capability Seam API、配置格式、SDK 调用方式都会快速变化，未来版本可能引入破坏性变更（Breaking Changes），你的插件和代码可能需要修改才能在新版本运行。

  3. 会话格式不兼容：如第 13 章所述，不同预览版之间的会话日志格式不保证兼容，升级后旧会话可能无法读取。不要把会话当作长期存储。

  4. 使用范围建议：官方明确建议当前版本只用于 评估、试验、研究、插件开发 目的。不要把核心业务流程建立在预览版之上。

  5. PR 政策：v0.1 阶段主仓库暂不接受外部 Pull Request。这不是傲慢，是因为核心架构还在快速调整，外部 PR 很可能因为架构变动直接作废，浪费贡献者时间。等核心接口稳定后会开放贡献。

  6. 远程托管：dsh 是**本地优先（Local-First）**设计，官方不提供远程托管服务或 SaaS 版本。没有「dsh 云」可以直接用，所有数据都存在你本地。

  7. 没有 SLA：预览版没有任何服务水平承诺，可能有 bug，可能崩溃，可能丢数据（虽然概率不高，但你要有心理准备）。

  8. 安全边界：dsh 设计为在信任环境下由开发者本人使用，不是多用户隔离系统，不要把它当作面向终端用户的服务直接暴露出去。

如果你看完上面这些还想继续，那我们来看看哪些场景下 dsh 是非常好的选择。

适用场景决策表#

dsh 在这些场景下非常有优势，是非常好的选择：

序号

你的情况

建议

理由

1

想试用 DeepSeek 官方编程 Agent

✅ 非常推荐

dsh 就是 DeepSeek 官方推出的 Agent 运行时，是体验 DeepSeek V4 系列模型编程能力最直接、优化最好的方式，模型和运行时是深度适配的。

2

需要可控、可观测的 Agent 运行时做研究/调试

✅ 非常推荐

Trajectory 轨迹视图、完整的 SessionLog、事件瀑布、分叉回放这些能力是 dsh 的核心优势——其他 Agent 工具大多是黑盒，出错了你不知道为什么。

3

做模型评测/基准测试（Benchmark）

✅ 非常推荐

Minimal 模式提供干净、可控、完全相同的工具面，所有模型面对一样的环境；Headless 模式方便批量跑测试；完整的日志方便事后对比分析。很多模型团队内部评测首选 dsh。

4

搭建公司/团队内部的 Agent 平台

✅ 适合（注意是基于它做二次开发，不是直接用）

用 dsh 作为底座嵌入到你们自己的平台里——Python/JSON-RPC SDK 让嵌入很容易，你不用从零写 Agent 运行时、工具系统、多模型支持这些复杂的东西，可以专注在企业定制和业务逻辑上。但建议等 1.0 稳定版再上生产。

5

研究 Agent Harness 架构、做架构学习参考

✅ 非常推荐

「一切皆插件」的设计、Cordis 元框架、Capability Seam 可替换能力抽象、事件驱动的 Agent 循环——dsh 的架构设计非常干净和有启发性，是学习 Agent 运行时设计的绝佳样本。

6

想开发 Agent 插件/扩展 Agent 能力

✅ 非常推荐

Cordis 插件系统非常灵活，没有特权内核——模型、工具、循环、UI 都是插件，你可以替换一切。如果你想给 Agent 加自定义能力、做垂直领域工具、实验新的 Agent 算法，dsh 给你的自由度是最大的。

为什么这些场景适合 dsh#

总结一下，dsh 的核心优势在这些场景能发挥出来：

  • 可控性：从模型调用到工具执行到 Agent 循环，每一步都能拦截、修改、替换、调试

  • 可观测性：完整的事件流和 Trajectory 让你知道 Agent 每一步在做什么、为什么这么做

  • 可扩展性：一切皆插件，没有黑盒，你想改什么都能改

  • 多模型原生支持：不是绑死在一个模型上，灵活切换不同厂商的模型

  • 嵌入友好：Headless、Python SDK、JSON-RPC、ACP 多种嵌入方式，方便集成到你的系统里

这些特性在「做研究、做二次开发、需要深度定制」的场景下是巨大的优势，但对于「开箱即用、解决日常问题」的场景，这些灵活性你可能用不上，反而会觉得它不够简单。

不适用场景决策表#

在这些场景下，dsh 不是好的选择，你应该用更适合的工具：

序号

你的情况

建议

理由

1

想立即上生产环境，跑核心业务流程

❌ 绝对不要用预览版

v0.1 预览版有破坏性变更，可能有 bug，没有 SLA。如果你的业务流程对稳定性要求高，等 v1.0 稳定版出来再说，或者用 Claude Code、Codex 这类已经稳定的产品。

2

只是想给 Claude Code 换个便宜模型，不想要其他特性

❌ 不要用 dsh，用 CC Switch 或类似工具

dsh 是一个完整的 Agent 框架，不是「Claude Code 换皮」。如果你只是想用 DeepSeek 模型但保留 Claude Code 的体验，直接用 Claude Code 的自定义模型功能或者 CC Switch 这类小工具就够了，不用换整个工具链。

3

非技术用户，想要开箱即用、零配置的 AI 编程助手

❌ 不推荐

dsh 是面向开发者和技术人员的工具，虽然安装不复杂，但还是需要配置 API Key、理解工作区/模型/Profile 这些概念。如果你不想折腾，Cursor、GitHub Copilot、Claude Code 这类开箱即用的产品更适合。

4

想做多用户团队协作的 SaaS 服务/远程共享

❌ 当前版本完全不支持

dsh 是本地单机设计，没有用户认证、权限隔离、多租户、远程访问能力。不要试图直接把它暴露到公网做团队服务，会有严重的安全问题。等官方未来的企业/远程方案，或者基于它做大量二次开发。

5

生产环境核心流程重度依赖

❌ 不要赌在预览版上

比如你的 CI/CD 流水线核心步骤依赖 dsh，客户服务 SLA 绑定在 dsh 上——这在预览版阶段风险太高。核心流程请用稳定的、有商业支持的产品。

为什么这些场景不适合#

简单说：

  • 要稳定：用已经 1.0 以上、有商业支持的产品，不要用预览版

  • 要简单：用开箱即用的产品，dsh 的灵活性对你来说是复杂度

  • 要 SaaS/多用户：dsh 是本地单机设计，方向不一样

这不是 dsh 不好，只是定位不同——就像你不会用一辆还在路试的原型赛车去上下班通勤，不是赛车不好，是场景不对。

Windows 平台特殊限制#

第 13 章 FAQ 里提到过 Windows PTY 的问题，这里再专门说一下 Windows 平台的体验限制：

Windows 原生体验的问题#

在 Windows 原生 CMD/PowerShell/Git Bash 下运行 dsh，会有这些已知限制：

功能

Windows 原生

WSL2/Linux/macOS

Web UI 基本功能

✅ 可用

✅ 完整体验

Headless 模式

✅ 可用

✅ 完整体验

Python SDK

✅ 可用

✅ 完整体验

简单命令执行（ls、cd、npm install 等）

✅ 基本可用

✅ 完整体验

交互式 TUI 程序（vim、htop、less）

⚠️ 有问题，可能乱码/卡住

✅ 完美支持

需要实时输入的命令

⚠️ 支持有限

✅ 完美支持

ANSI 颜色/格式

⚠️ 部分程序显示异常

✅ 完美支持

复杂 shell 脚本

⚠️ 兼容性问题

✅ 完美支持

文件系统权限

⚠️ Windows 权限模型差异

✅ 标准 POSIX 权限

官方建议#

官方文档明确给出的 Windows 平台建议：

对于 Windows 用户，强烈建议使用 WSL2（Windows Subsystem for Linux 2）来运行 dsh，以获得完整体验。

WSL2 的安装非常简单（Windows 10 2004 以上版本一个命令就行）：

# 在管理员 PowerShell 里执行
wsl --install

重启后，在 WSL2 里安装 Node.js 20+，然后运行 dsh——你会获得和 Linux/macOS 完全一致的体验，Windows 浏览器直接访问 http://localhost:3080 就能用，端口转发是自动的。

如果你坚持用 Windows 原生也不是不行——大部分编程任务不需要复杂的终端交互，基本还是能用的，只是偶尔会遇到终端相关的小问题。

版本跟踪建议#

既然 dsh 还在快速迭代，你可能想知道怎么跟踪版本更新，什么时候升级比较合适：

关注 GitHub Releases#

最重要的渠道是 GitHub Releases 页面：

  • 地址：github.com/deepseek-ai/deepseek-harness/releases

  • 建议 Watch 这个仓库的 Releases，这样新版本发布时你会收到通知

  • 每个版本都会有详细的 CHANGELOG，说明新增了什么、改了什么、有没有破坏性变更

阅读 CHANGELOG#

升级前一定要看 CHANGELOG，特别注意这些部分：

  • 🔴 Breaking Changes（破坏性变更）：如果你用了相关功能，可能需要改代码或配置

  • 🟡 Deprecations（废弃提示）：告诉你什么功能在未来版本会移除

  • 🟢 New Features（新功能）：新增了什么能力

  • 🐛 Bug Fixes（Bug 修复）：修了什么问题

升级策略建议#

在预览版阶段，推荐的升级策略：

  1. 不要追最新版（除非你要测试新功能）：rc 版本发布比较频繁，不用每天升，等几天看看社区反馈没问题再升

  2. 重要项目固定版本：如果你在用 dsh 做比较重要的事，在 npx 里指定版本号，比如 npx @deepseek-ai/dsh@0.1.0-rc.6，不要自动用 latest

  3. 备份配置再升级：升级前可以备份一下 ~/.dsh/settings.yaml，万一新版本有问题也能回退

  4. 不要在 deadline 前升级：项目要上线前、赶进度的时候不要随便升级，等空闲的时候再试新版本

什么时候可以开始考虑生产使用#

官方没有给出明确的 v1.0 时间表，但你可以关注这些信号，当这些都满足时，就可以开始评估生产使用了：

  • 版本号到了 v1.0.0

  • Release Notes 里明确写了「Stable Release」「Production Ready」

  • 宣布开始保证向后兼容性（接口不随便 breaking change）

  • 会话格式有版本化和迁移工具

  • 有完整的安全审计报告

  • 接受外部 PR，有活跃的贡献者社区

在那之前，安心试用、学习、做插件、在非核心场景用就好。

一句话总结#

最后用一句话帮你做决策：

如果你想体验最先进的开源 Agent 运行时、研究 Agent 架构、需要深度定制能力、做可控的模型评测——dsh 是目前你能找到的最好的选择之一，强烈推荐。

如果你想要稳定生产可用、开箱即用、多用户 SaaS——现在还不是时候，等 v1.0，或者用 Claude Code/Codex/Cursor。

工具的选择从来不是「哪个最好」，而是「哪个最适合你当下的场景」。希望这一章帮你做出了正确的决策。

最后一章，我们整理了 dsh 相关的所有官方资源、社区文章、生态动态，方便你深入学习和跟踪最新进展。

← 13 FAQ | → 15 生态资源