---
title: "DSH 插件、Skills 与 MCP 的能力边界"
description: "从任务、权限和维护责任理解 DSH 插件、Skills 与 MCP 的分工，避免为了扩展能力而扩大不必要的访问范围。"
canonical: https://52dsh.com/plugins/skills-mcp-boundary/
authors: ["52DSH 编辑部"]
published_at: 2026-08-18
updated_at: 2026-08-18
verified_on: 2026-08-18
maintenance_status: community
verification_level: source_reviewed
risk_level: medium
---

# DSH 插件、Skills 与 MCP 的能力边界

从任务、权限和维护责任理解 DSH 插件、Skills 与 MCP 的分工，避免为了扩展能力而扩大不必要的访问范围。

## 从任务而不是名称开始

选择扩展方式前，先写出 Agent 必须完成的动作：读取什么信息、产生什么结果、是否需要调用外部系统、失败后如何停止。名称相似的插件、Skill 和 MCP 服务可能拥有完全不同的运行位置与权限。

## 检查数据流向

对于每个扩展，画出输入、处理位置和输出。文件是否离开本机、凭据由谁保存、日志是否包含业务数据、外部服务保留数据多久，都应当在启用前明确。

如果只需要生成一段可审核文本，就不应默认授权写入数据库或发送消息。如果只需要读取某个项目目录，也不应授权整个用户目录。

DSH `0.1.0-rc.5` 随附 MCP client 包，但默认不运行任何 MCP server。官方 CLI 特别说明，配置的服务器命令在 Agent 沙箱之外作为受信任可执行代码运行，因此 MCP server 的安装来源、命令和凭据边界必须单独审查。实际管理插件与 Profile 的方法见[DSH 插件安装指南](/plugins/dsh-plugin-profile-guide/)。

## 为失败准备边界

扩展可能因为网络、版本、权限或外部 API 变化而失败。为关键工作流设置超时、重试上限和人工确认点，并保留不依赖该扩展的替代路径。

团队环境还应记录负责人、安装来源、版本、最后验证日期和卸载方法。能力目录只有同时记录维护责任，才会从“可安装列表”变成可持续使用的基础设施。

## 原始来源

- https://modelcontextprotocol.io/
- https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.zh.md
- https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/cli/reference/README.zh.md