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

DeepSeek Harness 对比 Claude Code：架构、插件、MCP

从许可协议、插件架构、MCP、hooks、子代理委派对比 DeepSeek Harness 与 Claude Code——dsh 是不是一个真正靠谱的、开源的 Claude Code 替代方案？

DeepSeek Harness（dsh）是一个 MIT 协议、完全开源的 agent harness，其核心只有一种扩展机制——一切皆 Cordis 插件。Claude Code 则是 Anthropic 官方的闭源 coding agent，把扩展拆成 skills、commands、hooks、MCP server 四套独立体系，并配有官方插件市场。但两者并非纯粹的竞品关系：dsh 可以把 Claude Code 当作子代理来委派任务，也可以直接复用一份 Claude Code 的 hooks.json 文件。

本文是基于事实的对比——不编造 benchmark 数字，不编造价格——素材来自 dsh 自己的文档与包结构，以及 Claude Code 广为人知的公开事实。完全开源的许可协议、与 Claude Code 同构的 MCP 工具命名，再加上能原生把 Claude Code 本身当子代理调用的桥接机制，正是 dsh 常被当作一个开源的 Claude Code 替代方案来讨论的原因——下文列出的就是支撑这个说法的具体事实。

许可协议与架构对照

维度DeepSeek Harness（dsh）Claude Code
许可协议MIT，完全开源Anthropic 官方分发的闭源 CLI
核心架构Cordis 插件框架——工具、命令、skill、hook、MCP 桥接、模型适配器全部是同一种插件skill（SKILL.md）、命令、hook（hooks.json）、MCP 配置分别是独立机制，另有官方插件市场
主要交互界面本地 Web UI（npx @deepseek-ai/dsh web，127.0.0.1:3080）+ headless CLI 模式以终端 CLI 为主，配有 IDE 扩展
版本状态developer preview（截至撰稿时 npm 版本为 0.1.0-rc.6），无 SemVer 承诺，无 GitHub Releases已公开发布、有官方文档的产品

架构上的分歧是最核心的差异。在 dsh 里，一个 hook、一个 Skill、一个 MCP server 桥接、一个工具，全部是注册在同一个 Cordis Context 上的插件——没有各自独立的 manifest 格式。Claude Code 则把 skill、命令、hook、MCP server 当作四种不同的扩展类型分别处理，各有自己的文件格式，再在上面叠加一层市场机制（这一点可以从 dsh 自己的 Claude Code 子代理测试套件里出现的测试开关 CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALL 得到旁证——一个虽小但具体的信号，说明 Claude Code 的市场及其自动安装行为是真实存在的）。

MCP：命名同构，但 dsh 桥接范围更窄

两者都支持桥接 Model Context Protocol server，dsh 的文档还特意点出了这一相似性：dsh 把桥接进来的工具命名为 mcp__<serverName>__<rawName>——与 Claude Code、Codex 采用的是同一套"server 限定"命名形状。如果你之前给 Claude Code 配过 MCP server，这套心智模型可以直接搬过来。

两者的差异在于覆盖范围。dsh 的 @deepseek-ai/dsh-mcp-client 明确只桥接 MCP 的 Tools——Resources 和 Prompts 在文档里被明确列为"延后实现"，目前 harness 侧没有任何消费者。而 Claude Code 的 MCP 客户端据其公开文档，除了 Tools 之外还会把 Resources（以 @ 提及的形式）和 Prompts（以斜杠命令的形式）暴露出来。如果你依赖的某个 MCP server 更多是靠 Resources 或 Prompts 而不是 Tools，这是切换前需要认真核实的一个真实功能缺口。

一份 dsh 的 MCP server 配置长这样（stdio 传输，一个插件实例对应一个 server）：

- id: mcp-github
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: github
    transport: stdio
    command: npx
    args: ['-y', '@modelcontextprotocol/server-github']
    env:
      GITHUB_TOKEN: !!js process.env.GITHUB_TOKEN

编辑这一行会触发热重载——dsh 断开并重连该 server，而不需要重启整个进程。streamable-http 配置、重连策略、超时限制的完整说明见我们的MCP 配置指南。

Hooks：dsh 能直接跑你已有的 Claude Code hooks.json

这是本次对比里比较令人意外的事实之一：dsh 提供了一个官方桥接包 dsh-hooks-claude-code，能把已有的 Claude Code hooks.json 文件翻译成 dsh 自己的扩展点监听器（agent/session-start、tools/pre-execute 等）。如果你的团队已经在 Claude Code 的 hook 脚本上投入了不少工作，尝试 dsh 时不一定需要重写它们。类似地，还有一个 dsh-hooks-codex 桥接包对应 Codex CLI 的 hooks。桥接如何映射事件的细节见《DeepSeek Harness 中的 Hooks 与斜杠命令》。

子代理：dsh 可以把 Claude Code 本身当子代理调用

对于纠结"到底哪个更强"的读者来说，最有意思的一个事实是：dsh 的子代理系统原生支持把 Claude Code 作为其中一个子代理 provider（dsh-subagent-claude-code，通过 Claude Code 官方 Agent SDK 驱动），与之并列的还有一个 Codex provider、一个 Agent Client Protocol provider，以及若干进程内 provider。子代理分"一次性"和"可续接"两种模式，一次性委派支持 outputSchema、depthLimit、toolFilter、persona 四项能力——provider 必须显式声明支持哪些，不支持的请求会直接报错，而不是静默降级。

实际意义是：dsh 严格来说并不是 Claude Code 的替代品——它可以是一层编排系统，把 Claude Code 当作自己的执行后端之一来调用，与 DeepSeek 自家模型以及其他子代理类型并存。完整的 provider 表见《DeepSeek Harness 子代理》。

Skills：不能直接互换

dsh 的 Skill 体系（ctx.skills，一个合并文件系统与内置来源的 provider 注册表）在架构上是它自己的一套东西——不是 Claude Code 那种 SKILL.md 目录约定的同一格式。有一条社区讨论（Discussion #88）专门问过 dsh 能否复用"传统"Skill，而官方文档目前并没有记录直接兼容的说明。一些社区插件用自己的方式弥合了这个缺口——比如 dsh-skillport 能在 Claude Code、Codex、Cursor、Gemini 的路径下发现已有的 SKILL.md 库并加载进 dsh。但这是社区的变通方案，不是官方兼容性保证。

模型、沙箱与成熟度

  • 模型 provider：dsh 原生支持 DeepSeek，同时内置了 Anthropic、OpenAI、Bedrock、Vertex、Azure、Codex 原生鉴权的目录，再加上任意 OpenAI 兼容自定义端点。Claude Code 围绕 Anthropic 的 Claude 模型构建，其公开文档也说明了可以通过 Amazon Bedrock、Google Vertex AI 访问。
  • 沙箱：dsh 有三档明确的沙箱模式（read-only、workspace-write、danger-full-access），配有平台后端——Linux 用 bwrap/Landlock，macOS 用 Seatbelt，Windows 用 ACL 受限令牌方案，再加一个 E2B 云沙箱选项。Claude Code 用的是自己的审批式权限模型，可配置自动批准行为；其沙箱内部实现细节不在本文独立核实的范围内。
  • 成熟度：dsh 明确处于 developer preview 阶段——没有 SemVer 承诺，没有 GitHub Releases 页面，GitHub Issues 已被禁用，反馈渠道改为 Discussions。Claude Code 是 Anthropic 已公开发布、有文档支撑的产品。

该选哪个？

如果你是…可以考虑
已经深度使用 Claude Code，手上有能跑的 hooks.json 脚本和 Claude Code 子代理工作流试试 dsh 的 dsh-hooks-claude-code 桥接和 dsh-subagent-claude-code provider——你也许根本不需要二选一，因为 dsh 可以帮你调用 Claude Code
正在搭建一层编排系统，需要从同一个地方调用多个 coding-agent 后端（Claude Code、Codex、进程内 agent）dsh 的子代理 provider 注册表正是为此设计的
想要一个第一方产品，配有官方市场和统一的扩展格式Claude Code 把 skill/命令/hook/MCP 拆开处理的模式更有主张，按扩展类型分别推理反而更简单
想要扩展面本身足够可改造——写一个插件，它既能是工具，也能是 hook 监听器，也能是 MCP 桥接dsh"一切皆插件"的 Cordis 架构是更灵活的基座
需要一个当下就能用于生产、版本稳定的工具要仔细权衡 dsh 的 developer preview 状态（预期有破坏性变更、无 SemVer）与 Claude Code 已发布产品状态之间的差异

对大多数工作负载来说，两者并不是非此即彼——子代理桥接这个机制本身就意味着你可以两个一起用。

FAQ

DeepSeek Harness 开源而 Claude Code 不开源，这个说法对吗？

对。dsh 是 MIT 协议，源码在 GitHub 上公开。Claude Code 是 Anthropic 以闭源 CLI 工具的形式分发的。

dsh 真的能不改代码就跑我已有的 Claude Code hooks 吗？

dsh-hooks-claude-code 桥接包正是为此设计的——它把一份已有的 hooks.json 翻译成 dsh 自己的扩展点监听器。我们没有对每一种 hook 类型逐一独立测试过，安装后建议对你自己用到的具体 hook 做一次验证。

我在 Claude Code 上用的 MCP server，dsh 也能用吗？

大多数情况下可以，前提是那个 MCP server 暴露的是 Tools——命名形状（mcp__<serverName>__<rawName>）是一样的。如果那个 server 依赖的是 MCP 的 Resources 或 Prompts，dsh 的客户端目前还没有桥接这两类能力。

我可以同时用 Claude Code 和 dsh，而不是二选一吗？

可以——这正是 dsh-subagent-claude-code provider 存在的意义。dsh 可以把一个任务（通过 Claude Code 官方 Agent SDK）委派给 Claude Code，作为多个子代理后端之一。

谁的插件更多？

FindHarness 目前收录了跨十二个分类的数百个 dsh 插件。Claude Code 有自己的官方市场和插件目录，我们没有在本站追踪与之可比的数字。

Next steps