Blog · 指南
DeepSeek Harness MCP：把外部 Server 接进一个插件原生的 Agent
2026 年 8 月 14 日 · dshbase
Model Context Protocol（MCP）是给 Agent 提供「住在进程外」的工具的事实标准——但把它当默认心智模型套到 DeepSeek Harness 上，是错的。dsh 不是像 Claude Code 那样 MCP 原生；它是插件原生，跑在 Cordis 内核上，插件才是扩展的基本单位。但这不代表 MCP 无关紧要。社区已经修好了干净的桥，而且有些 dsh 插件反过来对外暴露 MCP server。下面是 MCP 在 dsh 0.1.0-rc.6 里到底怎么用。
插件优先，MCP 当适配层
关键区别：在 dsh 里，你通常装的是插件（dsh plugin add …），而不是注册一个 MCP server。插件跑在 harness 内部，能做外部 server 做不到的事——读会话日志、注入上下文、钩住 UI。MCP 则相反，是给那些已经活在独立进程里的工具用的（数据库、浏览器、搜索 API）。所以正确的问题不是「怎么在 dsh 里打开 MCP」，而是「哪些外部工具该桥接进来，哪些干脆装成插件」。要判断你正想 MCP 进去的那个工具是不是早有人做成插件了，最快的方式就是查插件目录。
dsh-workspace-mcp：按项目加载 MCP server
目录里最直接的 MCP 集成是 dsh-workspace-mcp。它读取 <session-cwd>/.dsh/mcp.servers.yml 并为 Agent 加载其中的 server，作用域限定在当前 workspace、随项目自动加载 / 卸载。真正要紧的正是这个人体工学细节：你把 MCP server 声明在一个项目内的 YAML 文件里，于是每个仓库自带自己的工具——没有全局配置，也不会让 server 串到不相干的会话里。目前目录把它标成 not-on-npm（需从源码安装），所以把它当「方向对、但还早」看待。
自带 MCP server 的插件
MCP 是双向的。dsh-cowork 是个文档工具插件——doc_read / doc_write 处理 xlsx、pdf、docx、pptx、ipynb——而且它额外「附带一个 MCP server 和 CLI」。换句话说，你既能在 dsh 里把它当普通插件用，也能让另一个支持 MCP 的客户端把它当 server 连。这种双面性最清楚地说明了 dsh 在 MCP 生态里的位置：同一个工具，从哪一侧调用，它就可以是 Cordis 插件或 MCP server。
「零外部 MCP」的反例
也有作者故意走相反的路。dsh-vision-primitives 是个视觉推理插件，明确打广告「零外部 MCP」——用 Set-of-Mark 编号网格覆盖层做精确视觉定位，全部在插件内部原生完成，不需要养一个进程外 server。值得点名，是因为它抓住了社区里真实存在的一条哲学分叉：MCP 多一个进程、多一个故障域、多一个要一直开着的玩意儿，所以对自包含的能力而言，原生插件往往是更好的工程选择。MCP 桥是留给那些没法做成插件的工具的——那些本来就在别处跑着的。
什么时候用 MCP，什么时候用插件
- 选插件：能力是 dsh 专属（记忆、UI、会话钩子）或自包含（一个进程内跑代码的工具）。
- 选 MCP：工具已经活在另一个你不想重写的进程里——数据库、浏览器自动化守护进程、公司内部 API——并且你想通过
.dsh/mcp.servers.yml按项目隔离。 - 对外暴露 MCP（
dsh-cowork模式）：你在 dsh 里造的东西，非 dsh 客户端也该能用。
现状
dsh 的 MCP 支持是真的，但仍在成熟中。专门的桥（dsh-workspace-mcp）还很早期、尚未上 npm；打磨得最好的 MCP 相关插件（dsh-cowork）是把 MCP 当出口而非入口。如果你从 Claude Code 过来、期待一套成熟的 .mcp.json 式体验，诚实的答案是：dsh 的对等物就是插件系统本身，MCP 是给外部进程开的一个定向适配口。要看 MCP 相关与工具类插件当前、实测过的阵容（含确切安装命令），从插件目录开始。