跳过主要内容
全部文章
指南

从 Claude Code 迁移到 DeepSeek Harness 指南

把 DeepSeek Harness 当作开源的 Claude Code 替代方案来评估？看 CLAUDE.md、hooks.json、MCP server、Skills、子代理如何从 Claude Code 对应过去——哪些能直接沿用，哪些需要重做。

如果你打算把一个项目从 Claude Code 迁移到 DeepSeek Harness（dsh），大部分配置的迁移难度都比你想象的要低：你的 CLAUDE.md 可以原样加载，hooks.json 可以通过一个官方桥接插件跑起来，dsh 甚至可以直接把任务委派回 Claude Code 当子代理来执行。真正对不上的是 Skills 和底层的扩展模型本身——dsh 把一切都当成同一种插件，而不是分成独立的 skill/command/hook/MCP 四套系统。

这是一篇事实向的对照文章，不是任何一方工具的通用教程——默认你已经了解 Claude Code 的公开概念（CLAUDE.md、hooks.json、MCP server、Skills、斜杠命令、子代理），只是想知道 dsh 里对应的是什么。这篇文章写给正在把 dsh 当作开源的 Claude Code 替代方案来评估的读者，不是两个工具任意一个的入门介绍。

快速对照表

Claude Code 概念dsh 对应物匹配程度
CLAUDE.md 项目指令文件原生加载 AGENTS.md/CLAUDE.md，工作区根目录直接对应——dsh 自动读取
hooks.json shell 钩子dsh-hooks-claude-code 桥接插件直接对应——官方桥接负责翻译事件
MCP server每个 server 对应一个 @deepseek-ai/dsh-mcp-client 插件实例基本对应——工具命名相同，但范围更窄
Skills（SKILL.md）dsh 自己的 ctx.skills provider 注册表不能直接兼容
斜杠命令dsh 的"人类命令"（通过 ctx.commands）概念相同，注册机制不同
子代理dsh 子代理 provider 注册表，其中包含一个 Claude Code provider直接对应——可以真的调用 Claude Code
审批/权限设置dsh 沙箱模式 + 权限预设术语不同，结构可类比

你的项目指令文件不需要改

dsh 加载项目指令的方式和 Claude Code 一样：它会读取工作区根目录下存在的 AGENTS.md 或 CLAUDE.md，并自动渲染进上下文——不管是 Web UI、headless 还是 SDK 模式都一样。渲染预算固定为 65,536 字节——如果你的指令文件本来就接近这个大小，它的行为会和你在 Claude Code 里碰到类似上限时差不多：超出预算的内容不会进入上下文。如果你的 CLAUDE.md 篇幅本来就比较合理，直接把 dsh 指向同一个工作区，不需要任何转换步骤它就能读到。

Hooks：通过官方桥接插件复用 hooks.json

dsh 提供了一个官方桥接包 dsh-hooks-claude-code，能把一份已有的 Claude Code hooks.json 文件翻译成 dsh 自己的扩展点监听器——比如 agent/session-start、tools/pre-execute 这类。如果你的团队已经在提交前检查、通知触发、日志记录这类钩子脚本上投入了不少精力，试用 dsh 并不需要从零重写——把这个桥接插件装进你的 profile，指向已有的 hooks 文件就行。如果你是从 Codex CLI 迁移过来（或者同时用两者），还有一个对应的 dsh-hooks-codex 桥接插件。

dsh plugin --profile web add dsh-hooks-claude-code

我们没有逐一独立测试过每种 Claude Code hook 事件在桥接插件下的行为，所以更准确的说法是"复用你的逻辑，然后验证你实际依赖的那几个具体钩子"，而不是保证完全无缝替换。具体每个事件如何映射，见《DeepSeek Harness 的 Hooks 与斜杠命令》。

MCP server：命名方式相同，桥接范围更窄

如果你已经给 Claude Code 配置过 MCP server，这套心智模型几乎可以直接迁移过来。dsh 把桥接的 MCP 工具命名为 mcp__<serverName>__<rawName>——和 Claude Code 使用的是同一套"server-qualified"命名形状——所以一个你已经很熟悉配置方式的 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

每个 MCP server 在这里变成你 profile 的 Cordis 配置里的一个插件实例，而不是某个专用 MCP 配置文件里的一条记录。迁移前需要了解的更大差异是：dsh 的 MCP client 明确只桥接 MCP 的 Tools——Resources 和 Prompts 目前被文档列为"延后实现"，还没有接入任何消费方。如果你在 Claude Code 里依赖的某个 MCP server 主要靠 Resources（表现为 @ 提及）或 Prompts（表现为斜杠命令）而不是 Tools，这部分功能不会跟着迁移过来。迁移前请先确认每个 server 的能力清单，不要默认这是一次 1:1 的平移。完整配置细节（包括 streamable-http 传输方式和重连行为），见我们的《MCP 使用指南》。

Skills：这一块要做好重做的准备

这是最容易让人栽跟头的一块。dsh 有自己的一套 Skill 系统——一个 provider 注册表（ctx.skills），合并本地文件系统和内置来源的技能，通过一个 skill 工具消费，被调用时把内容注入上下文。它在架构上是完全独立的一套东西，跟 Claude Code 的 SKILL.md 目录约定不是同一种格式。dsh 仓库上有一条社区讨论（#88，"这个是不是还不能使用传统Skill?"）直接问过能不能复用现有的 Skills，截至撰稿时，dsh 自己的文档也没有明确说兼容还是不兼容——诚实的答案是"未确认"，而不是"能"或"不能"。

实际操作上，这意味着：不要假设你的 SKILL.md 库能原封不动搬过来。值得了解的一个社区方案是 dsh-skillport，它会在包括 Claude Code 在内的多个 agent 工具路径下发现已有的 SKILL.md 库，并以渐进式披露的索引形式加载进 dsh——但这是第三方插件在填补空白，不是官方兼容性保证。可以去 Skills 分类看看目前 skill 相关插件的现状。

子代理：你可以继续使用 Claude Code 本身

对于把这次迁移当成单向迁移的人来说，这是最意外的一个事实：dsh 的子代理系统有一个官方的 Claude Code provider，dsh-subagent-claude-code，它通过 Claude Code 自己的 Agent SDK 来驱动 Claude Code。换句话说，你不需要彻底告别 Claude Code——dsh 可以把它当成多个可选执行后端之一来调用，与 Codex provider、Agent Client Protocol provider、以及若干进程内 provider 并存。

一次性子代理委派支持四个可选能力，provider 必须显式声明支持哪些：outputSchema（结构化输出）、depthLimit（委派深度上限）、toolFilter（工具过滤）、persona（人设）。不支持的请求会直接报错，而不是静默降级。如果你的团队已经围绕 Claude Code 搭建了能跑起来的多智能体工作流，迁移的意思是把这套工作流重新定位成一个"恰好会调用 Claude Code"的 dsh 编排层，而不是把整套工作流推倒重来。完整的 provider 表见《DeepSeek Harness 子代理》，编排类插件可以看 workflow-automation 分类里的 dsh-agent-teams。

权限：把心智模型对应过去

dsh 的权限系统在结构上和 Claude Code 的审批设置不一样，但底层目标是一致的——控制 agent 在不询问的情况下能碰到多少东西。dsh 有三档沙箱模式：read-only（只读）、workspace-write（新 session 的默认值——写操作被限制在工作区根目录和平台临时目录内）、danger-full-access（完全不隔离）。这些模式会和一条审批策略打包成一个"权限预设"——默认表里只有两档：workspace-write（配合 ask 审批策略）和 danger-full-access（配合 never，也就是完全不问）。如果默认档位不适合你团队的工作流，可以在配置里自定义更多档位。完整的后端细节（Linux bwrap/Landlock、macOS Seatbelt、Windows ACL，以及 E2B 云沙箱）见《DeepSeek Harness 的权限与沙箱》。

值得调整的几个使用习惯

有几处差异不是具体某个配置文件的问题，而是两个工具的组织方式本身不同：

  • 只有一种扩展机制，不是四种。Claude Code 把 skills、commands、hooks、MCP 拆成独立的系统，各自有自己的文件格式。在 dsh 里，这些东西——再加上工具和模型适配器——底层都是同一种东西：一个注册到 Cordis Context 上的插件。习惯 dsh 之后，"我该怎么加 X"这个问题通常只有一个答案（写一个插件或装一个插件），而不是根据 X 是什么给出四种不同答案。
  • 插件是按 profile 安装的，不是全局的。dsh 把配置组织成若干个命名的 profile（web、headless，或自定义名字），每个 profile 有自己独立的已安装插件集合。尽早决定你要为每个项目建一个 profile，还是用一个共享 profile——就像你在别处考虑"按项目配置还是全局配置"一样。
  • 会话历史不必从零开始。如果你想把已有的 Claude Code 对话历史带过来，而不是从头开始，社区插件 dsh-chat-import 可以把包括 Claude Code 在内的多款 coding agent 的聊天历史，导入成可续接的 dsh session——也支持反向导出回 Claude Code 格式。这是一个第三方工具，不是官方迁移路径，建议先拿一个无关紧要的会话验证一下导入效果，再用于正式项目。

FAQ

迁移到 dsh 需要重写 CLAUDE.md 文件吗？

不需要。dsh 会直接从工作区根目录读取 AGENTS.md 或 CLAUDE.md，并自动渲染进上下文，受 65,536 字节的渲染预算限制。

我的 Claude Code hooks 在 dsh 里能直接用吗？

安装官方的 dsh-hooks-claude-code 桥接插件，并指向你已有的 hooks.json——它会把这些事件翻译成 dsh 的扩展点。我们没有验证过每一种钩子类型在桥接后行为完全一致，所以迁移后建议先测试你实际依赖的那几个钩子，不要默认它是完美匹配。

切换到 dsh 之后我还能继续用 Claude Code 吗？

可以——dsh 的 dsh-subagent-claude-code provider 能让它通过 Claude Code 自己的 Agent SDK 把任务委派给 Claude Code。你可以把 dsh 当成一个编排层，一部分任务照样调用 Claude Code，而不是彻底替换掉它。

我的 Claude Code Skills 不改动也能在 dsh 里用吗？

dsh 自己的文档对此没有给出明确说法，不要默认它们兼容。社区插件 dsh-skillport 是桥接现有 SKILL.md 库的一个选项，但它是第三方的变通方案，不是官方保证。

我的 MCP server 和 dsh 兼容吗？

如果这个 server 主要暴露 Tools，那是兼容的——命名规则（mcp__<serverName>__<rawName>）和 Claude Code 用的一致。如果它依赖 MCP 的 Resources 或 Prompts，dsh 目前还没有桥接这两类能力，迁移前请先确认你的 server 功能清单。

下一步