DSH 插件、Skills 与 MCP 的区别

三种不同的扩展点

因为三者都能让 agent 变得更强，它们经常被混用。真正的区别在于行为放在哪里：插件是由 DSH profile 管理的运行时包；Skill 是指导 agent 如何完成任务的说明；MCP 是 MCP client 与外部 server 之间的工具和资源协议。

一个实用规则是先选择能够承载行为的最小边界：判断和流程用指令，多个 client 共享的服务用协议，DSH 本身需要新的运行时能力时才用插件。

边界影响的不只是安装方式，还包括谁负责版本、凭据放在哪里、如何观察失败，以及其他 client 能否复用能力。动手前先写清 owner，可以防止一段本地指令悄悄变成没人维护的服务。

插件：打包的运行时能力

DSH 插件安装到 profile，并通过 dsh.bundle 清单发现。它可以注册模型 Provider、工具、记忆后端、界面或生命周期钩子。由于它位于 Harness 边界内，它可以参与启动、配置和 agent loop。

当你需要带版本、依赖边界和明确启用步骤的可复用实现时，选择插件。插件适合 profile 中所有任务都应该具备的能力，而不是只有出现某条指令时才需要的知识。

插件还给 DSH 提供了报告兼容性和启动状态的位置。当能力有依赖或需要初始化钩子时，这一点很有用。代价也很明确：运行时代码可以看到 profile 获得的权限，因此包审查必须成为安装流程的一部分。

• 适合 运行时集成、打包界面、模型适配器、记忆，以及需要生命周期钩子的能力。
• 代价 代码会成为运行中 Harness 的一部分，因此安装和权限范围更大。

Skills：可复用的指令

Skill 是 agent 可以用于任务的一组指令、示例和决策规则。它通过上下文改变行为，而不是加载新的运行时代码。Skill 可以教 agent 如何审查 Pull Request、生成报告，或安全地调用已有工具。

当能力主要是流程或编辑规范时，选择 Skill。它通常以文本形式版本化和审查，权限面也更小；但 Skill 自己不能创建网络服务，也不能替换运行时实现。

可以先暂时移除 Skill，再问自己运行时是否仍有完成任务所需的工具。如果答案是有，只是决策过程改变了，那么 Skill 通常是更好的起点。把指令写具体：说明工具、输入、审批规则，以及应该返回的证据。

• 适合 工作流指导、领域约定、检查清单和可重复的推理模式。
• 代价 agent 仍然只能使用运行时或已连接工具中已有的能力。

MCP：协议边界

Model Context Protocol（MCP）为 agent 提供标准方式，用来发现和调用工具、读取资源，以及使用外部 server 提供的 prompts。MCP server 负责集成，client 负责对话，并决定何时暴露某项能力。

当一个服务应该被多个 agent 或编辑器共享，或者你希望集成运行在 DSH 进程之外时，选择 MCP。协议边界可以提升隔离性，但也带来了 server 生命周期、认证、网络和兼容性等运维面。

当数据或动作已经有明确的服务 owner 时，MCP 最有价值。server 可以为每个 client 执行授权、限流和审计，DSH profile 只决定是否连接。前提是 endpoint、传输方式和凭据轮换都按正式服务来运维。

• 适合 共享服务、远程数据、外部系统，以及多个支持 MCP 的 client 都要使用的集成。
• 代价 需要运维另一个进程或 endpoint，并保护它的传输和凭据。

并排比较

如何做选择

按下面的顺序回答问题。第一个明确的答案通常就指向合适的边界。

例如，审查 Pull Request 的清单属于 Skill；共享 issue tracker 集成属于 MCP server；必须在 DSH 启动时加载的记忆后端属于插件。如果仍然无法判断，先写出数据流和失败时由谁负责，再选择包。

• 缺的是一段指令吗？ 如果 agent 已经有工具，只是需要更好的流程或领域规则，就从 Skill 开始。
• 其他 client 也要使用吗？ 如果能力属于共享服务，而不是单个 DSH profile，优先考虑 MCP。
• DSH 需要新的运行时行为吗？ 如果集成必须参与启动、配置或 agent loop，就使用插件。
• 两个边界可以组合吗？ 可以有意识地组合：插件提供本地能力，MCP server 提供远程数据，Skill 说明何时以及如何调用它们。

它们可以一起工作

三者不是互斥技术。例如，DSH 插件可以安装 MCP client，MCP server 可以提供数据库工具，Skill 则可以规定调用工具前的审批步骤。即使组合使用，每一层也应该只有一个清晰的 owner。

当系统开始变复杂时，先画出边界再添加扩展。写清楚代码由哪个进程负责、跨边界传递什么数据、需要哪些凭据，以及如何验证失败。这个小设计动作可以防止 Skill 变成没有文档的插件，也能防止 MCP server 变成隐藏的单体。

可以渐进式落地：先用 Skill 验证流程，再把稳定的运行时工作放入插件，只有在其他 client 也需要时才通过 MCP 暴露共享依赖。每一步都保留最小可用边界，并记录发生了什么变化。

目录中的插件页面适合查找运行时层，安装指南适合确认 profile 和 bundle，MCP server 自己的文档则负责传输和认证。只要交接点对操作 agent 的人可见，这三种技术就能很好地组合。