跳过主要内容
全部文章
对比

DeepSeek Harness 对比 OpenCode（附与 Claude Code 的对比）

OpenCode 对比 Claude Code 对比 DeepSeek Harness：两个开源、支持多模型 provider 的 agent harness 正面对比，外加二者各自与 Claude Code 的差异。

DeepSeek Harness（dsh）和 OpenCode 都是开源的 agent harness，都能让你把 agent 指向不止一个模型 provider——但二者的默认交互界面正好相反。dsh 默认是本地浏览器里的 Web UI；OpenCode 则是围绕终端 UI（TUI）构建的。两者的插件生态也是各自独立、互不通用的，不过有一个社区桥接插件能把 OpenCode 的配置搬进 dsh。

两者的共同点

两个项目在基本定位上是一致的：完全开源、不绑定单一模型厂商、允许开发者自己配置想用的 provider，而不是被锁定在某一家公司的模型上。两者发布以来都吸引了自己的插件/扩展生态，也经常被开发者在评估"开放、provider 无关的 coding agent"作为闭源单一厂商工具的替代方案时相提并论。

交互界面：Web UI 对比终端优先

这是日常使用中最直观的差异。dsh 的主要界面是本地 Web UI，用 npx @deepseek-ai/dsh web 启动，服务在 http://127.0.0.1:3080——你在 Settings → Models 里配置模型，选择一个工作区目录，然后通过浏览器里的聊天界面交互，需要权限的操作会弹出审批提示。dsh 确实有一个 headless CLI 模式（dsh --profile headless "任务"）用于一次性、非交互式场景，但开箱即用的默认形态是一个 Web 优先的工具。

相比之下，OpenCode 的产品定位是围绕终端 UI 构建的——它是较知名的、TUI 优先的开源 agent harness 之一，直接在终端里运行，不需要浏览器这一步。

如果你恰好想要 dsh 的插件生态和模型灵活性，又更喜欢在终端里工作，社区已经填上了这个缺口：dsh-TUI 是一个 Claude Code 风格的全屏终端 UI 插件，dsh-tianshu-tui 是另一个终端 UI 选项。两者都不是在复刻 OpenCode 本身——它们是 dsh 原生的 TUI 前端。更完整的列表见《DeepSeek Harness TUI 插件盘点》。

扩展机制：各自独立的生态，一座社区桥梁

dsh 的插件系统建立在 Cordis 框架之上——一个插件就是一个代码模块，它可以注册一个工具、一个 hook 监听器、一个 MCP 桥接、或者一个模型适配器，全部走同一套机制。OpenCode 有自己独立的插件和配置系统，与 Cordis 无关，是独立开发的。两者开箱即不兼容：dsh 插件不能在 OpenCode 里跑，反过来也一样。

不过，至少有一个社区插件专门瞄准了这个缺口：dsh-plugin-opencode-bridge，把 OpenCode 的 skill 和配置桥接进 DeepSeek Harness。和任何桥接类插件一样，安装前先审查其源码——具体检查项见我们的插件安全检查清单。

社区反馈：把 OpenCode 和 dsh 搭配使用来控制成本

在 dsh 发布后的社区讨论里，至少有一位开发者描述过把 OpenCode 的模型访问能力和 dsh 的插件生态结合起来，作为一种相比单一厂商订阅更省钱的方式——这是一个社区反馈的用法，不是任何一个项目官方文档正式描述的功能，我们也没有独立做过复测。如果成本是你的主要考量，把这个当作一个值得自己动手验证的思路，而不是一个有保证的结果；dsh 自身的许可协议和 API 成本模型拆解见《DeepSeek Harness 免费吗？》。

插件生态的广度

由于 dsh 把每一种扩展类型都当作同一种 Cordis 插件来处理，它的社区插件目录覆盖的类别远不止"工具"——FindHarness 目前追踪的插件跨越十二个分类，从UI 增强、主题，到记忆、工作流自动化、MCP 连接器。这种广度是"一切皆插件"设计的直接结果：插件作者不需要因为自己发布的是一个 UI 微调、一个后台任务、还是一个模型适配器，就要用不同的 manifest 格式。

我们没有条件在这里独立核实 OpenCode 逐分类可比的插件数量，所以不会断言哪个项目插件"更多"——但如果插件多样性对你的决策重要，理解 dsh 目录为何能铺得这么开的结构性原因是有意义的。

治理与成熟度

两个项目都在积极开发中。dsh 的维护者明确把它标注为 developer preview——没有 SemVer 承诺，没有 GitHub Releases 页面，GitHub Issues 已被禁用，反馈渠道改为 Discussions。如果你是在为生产工作流而不是为了实验选工具，这是一个有实际意义的信号：预期版本之间会有破坏性变更，也要预期通过 Discussions 而不是 changelog 来追踪变化。我们没有针对 OpenCode 做过独立核实、可直接对比的成熟度信号，所以在把它用于任何"不能出错"的场景之前，请自行评估该项目自己的发布实践。

对照表

维度DeepSeek Harness（dsh）OpenCode
许可协议MIT，开源开源
默认交互界面本地 Web UI（浏览器）+ headless CLI终端 UI（TUI）
扩展机制Cordis 插件——工具、hook、MCP 桥接、模型适配器统一为同一机制自己的插件/配置系统，与 Cordis 无关
模型 provider 灵活度原生 DeepSeek + 内置目录（Anthropic、OpenAI、Bedrock、Vertex、Azure、Codex 原生鉴权）+ 任意 OpenAI 兼容自定义端点设计上支持跨多个模型后端、provider 无关
跨向兼容社区桥接插件（dsh-plugin-opencode-bridge）导入 OpenCode 配置—
版本状态developer preview，无 SemVer，GitHub Issues 已禁用活跃开发中的开源项目

哪个更适合你？

  • 你想要一个基于浏览器的会话，配上一个可以随意扩展的插件生态（工具、hook、MCP、模型适配器统一为一种机制）：dsh 是更开放、插件优先的选择，在 FindHarness 上可以浏览一个庞大且快速增长的社区插件目录。
  • 你常年生活在终端里，希望它是主要的、一等公民的体验，而不是叠加在上面的一个插件：OpenCode 的 TUI 优先设计更自然；如果你想要 dsh 的插件生态但又不想用 Web UI，也可以搭配一个社区 TUI 插件，比如 dsh-TUI。
  • 你想把两者结合起来用：社区维护的 dsh-plugin-opencode-bridge 能把 OpenCode 的配置导入 dsh，也有开发者反馈过出于成本考虑把两者搭配使用——在真正依赖这个方案之前，值得自己在实际工作负载上先测一遍。

OpenCode 对比 Claude Code：两者的差异在哪里（以及 dsh 处在什么位置）

由于 dsh 经常被拿来和这两个项目分别对比，这里直接把 OpenCode 和 Claude Code 放在一起比一比，而不只是各自和 dsh 比。OpenCode 对比 Claude Code 最明显的差异在于许可协议和 provider 锁定：OpenCode 完全开源，从一开始就设计成 provider 无关；Claude Code 则是 Anthropic 分发的闭源 CLI，主要围绕 Anthropic 自家的 Claude 模型构建。界面形态是另一个大分歧——OpenCode 是终端优先，直接在 shell 里以 TUI 运行；Claude Code 同样以终端为主，但在 CLI 之外还配有官方 IDE 扩展，而不是一个基于浏览器的 UI。

那 dsh 相对这两者处在什么位置？像 OpenCode 一样，dsh 完全开源（MIT），设计上 provider 无关——不会被锁定在某一家的模型上。像 Claude Code 一样，dsh 日常默认的交互界面也偏向一个更丰富的前端，而不是纯 TUI 体验，只不过 dsh 这一层是本地 Web UI，而不是 Claude Code 那种"终端 + IDE"的组合。在扩展机制上，三者的做法真的各不相同：OpenCode 有自己独立的插件/配置系统；Claude Code 把 skill、命令、hook、MCP 拆成独立系统，再配一个官方市场；dsh 则把这一切统一成同一套 Cordis 插件机制。三者都作为 client 支持 MCP，但覆盖范围和配置格式各项目并不相同——具体见下表。

维度OpenCodeClaude CodeDeepSeek Harness（dsh）
开源与否是否——闭源 CLI是，MIT
主要交互界面终端 UI（TUI）终端 CLI + 官方 IDE 扩展本地 Web UI + headless CLI
模型 provider 选择设计上 provider 无关主要围绕 Anthropic 的 Claude 模型原生 DeepSeek + 内置目录（Anthropic、OpenAI、Bedrock、Vertex、Azure、Codex 原生鉴权）+ 自定义 OpenAI 兼容端点
扩展机制自己独立的插件/配置系统，与 Cordis 无关skill、命令、hook、MCP 各自独立系统 + 官方市场统一的 Cordis 插件机制——工具、hook、MCP 桥接、模型适配器都是同一种构造
MCP 支持本文未独立核实支持——桥接 Tools、Resources、Prompts支持——只桥接 Tools，Resources 和 Prompts 文档标注为延后实现

FAQ

OpenCode 和 dsh 一样是开源的吗？

是的——两个项目都是开源的，这也是为什么它们经常被拿来作为闭源单一厂商 coding agent 的替代方案相提并论。

我能在 OpenCode 里跑 dsh 插件，或者反过来吗？

不能，不能直接互通。两者有各自独立的插件/扩展生态。社区插件 dsh-plugin-opencode-bridge 可以把 OpenCode 的 skill 和配置导入 dsh，但这是一个单向的社区集成，不是原生的跨兼容。

dsh 有像 OpenCode 那样的终端 UI 吗？

默认没有——dsh 开箱即用的界面是本地 Web UI。有若干社区插件在 dsh 之上加了一层终端 UI，包括 dsh-TUI 和 dsh-tianshu-tui。

把 OpenCode 和 dsh 搭配使用真的能省钱吗？

这是开发者讨论中一个社区反馈的用法，不是两个项目文档里正式描述的功能，也不是我们独立核实过的结论。把它当作一个值得在自己的用量模式上测试的思路，而不是一个有保证的结果。

谁内置的模型 provider 更多？

dsh 自带一个更宽的内置 provider 目录（Anthropic、OpenAI、Bedrock、Vertex、Azure、Codex 原生鉴权，再加任意 OpenAI 兼容自定义端点）。OpenCode 在设计上同样是 provider 无关的，但我们没有独立核实过它内置 provider 的可比清单。

Next steps