插件、技能和 MCP 有什么区别？DeepSeek Harness 扩展能力选择指南

插件、技能和 MCP 可以在用户「怎么扩展能力」的层面放在一起比较；但在 DeepSeek Harness 的内部实现里，它们不是三个完全平级的底层原语。

当前 DSH（DeepSeek Harness 的简称）本身采用「一切皆插件」的架构。例如：

• 本地 skill（技能）发现由插件提供；
• 面向模型的 skill loader 也是插件能力；
• MCP Client 本身就是 @deepseek-ai/dsh-mcp-client 插件；
• MCP Server 暴露的工具最终会被桥接进 DSH 的工具系统。

把这两种视角画成一张图：

示意图点击放大

Learn 这一篇主要站在「用户该怎么选」的角度讲。底层为什么这样实现，放到 Architecture 板块讨论。

skill（技能）最适合解决的问题是——智能体不缺工具，但缺一套稳定的做事方法。

例如你已经有文件工具、Shell、网页检索、MCP 工具，但希望智能体每次都按一套固定流程工作：先检查资料 → 再判断风险 → 再输出指定格式。这类需求很适合技能。

技能更像「方法说明书」

一个技能通常会告诉智能体：

• 什么时候使用；
• 任务应该按什么步骤执行；
• 有哪些注意事项；
• 输出应该是什么结构；
• 可以参考哪些资源。

所以技能的核心不是新增一个外部 API（应用程序接口），而是让智能体更稳定地使用已经拥有的能力完成某类任务。

当前本地技能可以通过 SKILL.md 或平铺 Markdown 文件提供。具体怎么创建、放在哪里、怎么验证，见《Skills 技能教程》（/deepseek-harness/skills/）。

一个技能例子

假设你希望智能体帮你做网站 SEO（搜索引擎优化）审计。智能体本身已经拥有文件读取、网页检索，可能还有浏览器或其他工具。你缺的不是「搜索工具」，你缺的是一套 DSHOPC SEO 审计流程。

例如技能里规定：

1. 先确认页面目标搜索意图；
2. 检查 Title / Description；
3. 检查 H1 与正文结构；
4. 检查 canonical（规范链接标签）；
5. 检查内部链接；
6. 区分事实问题和优化建议；
7. 最后输出 P0 / P1 / P2。

这就是典型的「缺方法 → 技能」。

MCP 更适合的场景是——外部已经存在一套工具或服务，你希望智能体能调用它。

当前 DeepSeek Harness 的 MCP Client 可以连接外部 MCP Server，并把服务器暴露的 Tools 注册成 DSH 工具。当前支持的主要传输方式包括 stdio（标准输入输出）和 streamable-http（流式 HTTP）。

例如 GitHub MCP Server 提供仓库工具。连接以后，智能体可以看到类似 mcp__github__... 这样的工具。

MCP 更像「接外部工具」

典型场景包括 GitHub、数据库、CRM（客户关系管理系统）、浏览器自动化、企业内部系统、文件服务和搜索服务。

如果这些系统已经有可用的 MCP Server，你通常不需要为了接入 DSH 重新开发一套原生插件，可以先评估直接通过 MCP 接进来是否足够。具体连接、配置和验证，见《MCP 教程》（/deepseek-harness/mcp/）。

MCP 不是「方法」

假设你接入一个 CRM MCP。它可能提供查询客户、创建记录、更新商机、写跟进日志这些工具，解决的是「智能体能不能操作 CRM」；但它并不会自动规定一个销售智能体应该先查什么、如何判断商机、什么时候更新 CRM、怎样输出下一步计划。这套「销售方法」更像技能。

CRM MCP
→ 提供工具

销售技能
→ 规定如何使用这些工具

它们不是互相替代。

插件更适合你需要扩展 DeepSeek Harness 自身运行能力的场景。当前 DSH 的大量能力本身就是由插件组成的。

插件可以参与：

• 工具；
• 服务；
• 事件；
• 配置；
• 智能体能力；
• UI；
• 模型适配；
• 会话能力；
• 其他 Harness 生命周期。

所以插件的扩展深度通常比单纯增加一份技能说明更高。

什么场景更像插件？

给 DSH 增加新的原生工具

不是连接一个现成 MCP Server，而是直接把新工具注册进 Harness。

改变 Harness 行为

例如新增的服务、新的事件处理、新的智能体能力、新的模型适配方式。

做深度 DSH 集成

如果能力明显依赖 Cordis（DSH 的插件框架）、DSH 服务、上下文、工具注册表或生命周期，那更接近插件问题。

具体怎么安装、卸载和验证，见《Plugins 插件教程》（/deepseek-harness/plugins/）。

第一个问题：我缺的是「方法」还是「能力」？

如果你已经有工具，只是不知道怎样稳定完成某类任务——先用技能。

第二个问题：这个能力在外部已经存在吗？

如果已经有对应的 MCP Server，而你只是希望智能体能调用它——先评估 MCP。

第三个问题：我要改的是 DSH 自己吗？

如果你需要注册 Harness 原生能力、使用 DSH 服务、深度参与 Cordis、修改智能体运行时（Agent Runtime）或构建新的内部能力——考虑插件。

如果三个问题你都答「不是」，先回到需求本身重新拆解，再按同样的问题走一遍。

示意图点击放大

场景一：我要一个内容 SEO 智能体

你已经有文件和网页检索，真正缺的是 SEO 检查步骤、判断标准和输出格式——先选技能。

如果以后需要连接 Search Console，再加相应 MCP 或其他工具能力。

场景二：我要让智能体操作 GitHub

如果已经有合适的 MCP Server，先评估 MCP。因为核心需求是把 GitHub 的外部能力暴露给智能体。

然后你还可以增加一个 GitHub PR Review 技能，告诉智能体应该怎样审 PR（Pull Request，合并请求）。最终就是：

MCP → 能操作 GitHub
技能 → 知道怎样审 PR

场景三：我要给 DSH 增加一种原生运行能力

例如你正在开发一个深度参与 Harness 工具注册、服务或运行时的新能力，这时插件通常更符合问题本质。

之后插件也可以继续提供工具、技能来源、MCP Client 和其他服务。

成熟的智能体往往不是插件、技能、MCP 三选一，而是组合。例如一个客户运营智能体：

技能
→ 规定客户跟进 SOP（Standard Operating Procedure，标准操作流程）

MCP
→ 连接 CRM / 邮件 / 数据服务

插件
→ 提供 DSH 内部需要的自定义运行能力

所以选型真正的问题不是「哪一个最好」，而是这个需求的哪一部分应该放在哪一层。

为什么不要一上来就写插件？

因为插件通常意味着更深的 DSH 集成、更多代码、更多生命周期问题、更高维护成本和更强的版本耦合。

如果需求只是「让智能体每次都按这个步骤工作」，写插件通常过重，先用技能更合理。

为什么也不要什么都塞进技能？

反过来也一样。如果你希望智能体真正查询数据库，仅仅在 SKILL.md 里写一句「请查询数据库」，不会凭空产生数据库工具。

它仍然需要 MCP、插件、已有 Shell / API 工具或其他真实执行能力。

所以：技能告诉智能体怎么做，不会凭空创造它没有的工具。

为什么不是所有外部 API 都必须用 MCP？

MCP 是很有价值的工具接入方式，但不是「只要有 API 就必须包装 MCP」。判断还要考虑：

• 是否已经有 MCP Server；
• 是否需要跨不同智能体 / Client 复用；
• 接口是否稳定；
• 权限与凭据如何管理；
• 是否值得维护 Server。

三者的风险来源不同，需要分开评估。

技能

MCP

MCP 的主要风险包括：stdio 方式会在本机启动程序、引入第三方 MCP Server、保管 API Token 等凭据、开放外部数据访问，以及对 GitHub / CRM / 数据库等的真实写入操作。

插件

插件可以深度进入 DSH。安装第三方插件尤其需要注意包来源和安装阶段的代码执行。

如果你判断自己缺「方法」

继续阅读《DeepSeek Harness 技能教程：创建、发现与使用》（/deepseek-harness/skills/）。技能路线不要求你先学 Profile。

如果你判断自己需要深度扩展 DSH

先阅读《DeepSeek Harness Profile 使用指南》（/deepseek-harness/profile/），再进入《DeepSeek Harness 插件教程：安装、更新、卸载与恢复》（/deepseek-harness/plugins/）。

如果你准备连接 MCP Server

建议先看《DeepSeek Harness Profile 使用指南》（/deepseek-harness/profile/），再进入《DeepSeek Harness MCP 教程：连接外部工具》（/deepseek-harness/mcp/）。因为当前 DSH 的 MCP Client 本身通过插件和 Harness 组合配置接入。

怎样算你已经会选了？

只需要能判断下面四种情况：

• 已经有工具，只缺稳定执行流程 → 技能；
• 已经有合适的外部 MCP Server → 优先评估 MCP；
• 需要深度扩展 DSH 自身能力 → 插件；
• 一个真实智能体同时需要方法和外部工具 → 技能 + MCP 可以组合。

如果你已经不会再问「插件、技能、MCP 哪个功能最强」，而开始问「我的需求到底缺方法、缺外部能力，还是缺 Harness 原生扩展」，这篇就达到目的了。

如果某个环节没有按预期工作，进入《DeepSeek Harness 常见问题与报错排查》（/deepseek-harness/troubleshooting/），按故障层级定位。

证据来源：DeepSeek Harness 插件、skill（技能）与 MCP Client 官方文档及源码核验。