如何在 DeepSeek-Harness 中使用 MCP 服务器（完整指南）

DeepSeek-Harness（dsh）以 client 角色支持 Model Context Protocol（MCP），通过官方插件 @deepseek-ai/dsh-mcp-client 实现。你在 cordis.patch.yml（或任意 --patch 文件）里为每个 MCP 服务器添加一个插件实例，dsh 就会把该服务器的工具以 mcp__<serverName>__<rawName> 的名字暴露给智能体。本文讲清楚精确的配置格式、工具名是如何生成的，以及你在依赖它之前需要了解的重连与启动行为。

MCP 支持是完整功能，不是实验性占位——但有一个重要限制

dsh 里的 MCP 支持不是实验性或半成品功能。dsh-mcp-client 包带有完整文档，支持两种主流 MCP 传输方式，还有明确定义的重连策略。但限制在于：dsh 只桥接 MCP 的 Tools 能力。 MCP 的 Resources 和 Prompts 能力在 harness 里没有消费者，官方文档明确把它们列为"延后实现"（deferred）。如果你评估的某个 MCP 服务器主要依赖 Resources 或 Prompts 而非 Tools，要提前规划好这个缺口——工具会出现，其他能力不会。

配置一个 MCP 服务器

每个服务器在你的 patch 文件里是一条独立的 @deepseek-ai/dsh-mcp-client 插件项。支持两种传输：stdio（拉起一个本地进程）和 streamable-http（连接一个正在运行的 HTTP 端点）。

- 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

- id: mcp-web
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: web
    transport: streamable-http
    url: http://localhost:3000/mcp
    headers:
      Authorization: !!js '`Bearer ${process.env.MCP_TOKEN}`'

stdio 传输下，你提供 command/args/env/cwd——dsh 负责拉起并管理这个子进程。streamable-http 传输下，你提供 url/headers，dsh 通过 HTTP 建立连接。dsh 运行期间编辑这段配置会触发热模块替换：这个服务器会断开重连，但 dsh 进程本身不会重启。修改配置时保持 serverName 不变——改了它，模型看到的这个服务器下所有工具的名字都会跟着变。

如果你在给 web 或 headless profile 打补丁，可以把这段代码放进该 profile 自己的 cordis.patch.yml，也可以在启动时用 --patch <path> 叠加一层。关于 patch 层是如何叠加的，参见我们的配置指南。

工具名是如何生成的

模型看不到分开的 serverName 和 rawName 字段——它看到的是一个组合好的工具名：

mcp__<serverName>__<rawName>

这种"server-qualified"命名形状是刻意与 Claude Code、Codex 保持一致的，如果你习惯了读这两者的工具调用轨迹，这一点会很有用。由于组合出的名字要满足 DeepSeek 函数名的约束，会应用几条规范化规则：

规则	说明
字符集	限定为 `[A-Za-z0-9_-]`，最长 64 字符
冲突处理	若两个服务器/工具规范化后同名，dsh 会追加一段由 `(serverName, rawName)` 派生的 12 位十六进制后缀
稳定性	名字是 `(serverName, rawName)` 的纯函数——不依赖连接顺序，因此一个工具的名字在多次重启之间保持稳定

启动与重连行为

当某个服务器响应慢、不可达，或在会话中途掉线时，有两个配置项决定接下来发生什么：

配置项	默认值	行为
`failOnStartupError`	`false`	若初始连接或工具发现失败，插件会降级为"零工具"，而不是阻塞整个 profile 的启动
`reconnect.enabled`	`true`	断线自动重连，采用指数退避
初始重连延迟	500ms	断线后第一次重试的间隔
`maxDelayMs`	30000ms	退避上限；连接存活时间超过这个值会重置失败计数预算
`maxAttempts`	10	连续失败多少次后放弃重连，直到下一次 HMR 重载或 host 重启

启动超时继承自 MCP SDK 的默认值 60 秒——dsh 目前没有暴露自己的连接/发现超时配置项，所以在初始发现阶段响应超过这个时间的服务器无论你在别处怎么设置都会超时。

还有一个值得了解的行为：MCP 工具调用返回的非文本内容（图片、音频等二进制资源）在模型看到的对话历史里会被渲染成占位符——这是展示层的"有损"处理。底层的 JSON 结果块和 structuredContent 在执行期是完整保留的，所以下游消费这些结构化数据的工具不受影响；被丢弃的具体是原始字节在模型可见历史里的渲染。

MCP 配置里的密钥

留意上面示例里的 !!js process.env.GITHUB_TOKEN 和 !!js 'Bearer ${process.env.MCP_TOKEN}' 这两行——这是 Cordis 的 YAML 标签，用于嵌入一段在加载时求值的 JavaScript 表达式，也是你从环境变量里取凭据、而不是把它硬编码进一份可能被提交或分享的 patch 文件的方式。任何引用了真实凭据的 cordis.patch.yml，都应该像对待 .env 文件一样对待它：不要纳入版本控制，只要字段支持，优先用环境变量引用而不是明文 token。如果你打算通过 $DSH_HOME/cordis.patch.yml 叠加机器级的 MCP 默认配置，这一层和 profile 本地 patch 是如何交互的，参见我们的配置指南。

用官方 memory 示例试一试

dsh 仓库在 examples/mcp-memory/ 下提供了一份可直接运行的参考实现，包含三份独立的 cordis 配置，分别接入不同的"记忆类"MCP 服务器：engram.cordis.yml、mcp-reference-memory.cordis.yml、memorix.cordis.yml。这是端到端看一份真实 dsh-mcp-client 配置最快的方式，如果你正打算用它来弥补 dsh 缺少内置长期记忆能力这个短板，这份示例会直接相关——memory 正是人们最先想到用 MCP 解决的场景之一。这些基于 MCP 的方案与插件原生记忆存储相比如何，可以参考我们的DeepSeek-Harness 记忆插件横评。

值得了解的社区 MCP 插件

除了手写 cordis.patch.yml 条目之外，MCP 与连接器分类里的一些社区插件是构建在 dsh-mcp-client 之上、而不是替代它：

dsh-mcp-manager 在 Settings 里加了一个 MCP 面板，支持 OAuth（PKCE + 动态客户端注册），让你不用手写 YAML 就能管理服务器。
dsh-mcp-panel 是一个只读的运行时面板，展示每个服务器的连接状态和已注册工具——用来调试上面说的重连行为很方便。
dsh-mcp-bridge 一次安装就带上一批精选的常用服务器（memory、filesystem、GitHub、Playwright）。
dsh-search-mcp 把 dsh 内置的网页搜索换成搜索类 MCP 服务器（Tavily/Brave/Exa/Perplexity/DuckDuckGo），这是很多人接入的第一个 MCP 集成。

如何在 DeepSeek-Harness 中使用 MCP 服务器（完整指南）

MCP 支持是完整功能，不是实验性占位——但有一个重要限制

配置一个 MCP 服务器

工具名是如何生成的

启动与重连行为

MCP 配置里的密钥

用官方 memory 示例试一试

值得了解的社区 MCP 插件

FAQ

dsh 支持 MCP 的 Resources 和 Prompts 吗？

添加 MCP 服务器后需要重启 dsh 吗？

dsh 启动时某个 MCP 服务器不可用会怎样？

可以用需要 OAuth 的 MCP 服务器吗？

dsh 的 MCP 工具命名和 Claude Code 有什么不同？

Next steps