MCP 和 Agent Skill 解决的是两个不同层次的问题：MCP 让 Agent 发现并调用外部数据与工具，Agent Skill 把一类任务的步骤、业务规则、参考资料和验收标准封装成可复用方法。前者回答“能不能连接”，后者回答“应该怎样完成”。
两者不是替代关系。一个能稳定完成企业任务的 Agent，往往既需要 MCP 提供受控工具，也需要 Skill 规定调用顺序、分析方法和交付标准。
| 对比维度 | MCP | Agent Skill |
|---|---|---|
| 核心问题 | Agent 怎样连接并调用外部能力 | Agent 怎样把一类任务稳定做完 |
| 主要载体 | Host、Client、Server、协议消息与能力定义 | SKILL.md、脚本、参考资料与模板 |
| 提供内容 | Tools、Resources、Prompts 等外部能力 | 工作流、领域知识、约束、示例和质量标准 |
| 典型动作 | 查数据库、读文件、创建工单 | 确认口径、拆解任务、套用规范、验收结果 |
| 是否必须联网 | 取决于 Server 形态 | 不一定，可以只处理本地文件和知识 |
| 主要风险 | 认证、越权、数据泄露、工具副作用 | 误触发、过时规则、恶意脚本、流程偏差 |
| 更接近什么 | 接口、连接器和一双手 | SOP、操作手册和岗位方法 |
如果只记一句话：MCP 让 Agent 够得着，Skill 让 Agent 知道怎样做。
MCP 与 Skill 都在扩展 Agent 的能力，而且都可能涉及工具、外部资源和多步骤任务。因此，人们容易把它们看成两种“插件”，甚至认为新出现的 Skill 会替代 MCP。
可以用新员工入职来理解。
IT 部门为新员工开通数据库、代码仓库、工单系统和企业网盘，相当于解决“能够访问什么”。这更接近 MCP。
但员工拿到权限后，仍需要知道代码审查先检查什么、销售月报采用什么口径、哪些动作必须审批、报告按照什么格式交付。这些组织经验更接近 Skill。
权限不会自动变成工作方法，工作方法也不会自动产生系统连接。
MCP（Model Context Protocol，模型上下文协议）定义 AI 应用与外部能力之间的连接方式。兼容的 Host 可以发现 MCP Server 提供的工具和资源，再在权限范围内发起调用。
例如，代码仓库 MCP Server 可以提供：
到这里，Agent 已经“能够操作代码仓库”。但 MCP Server 不一定知道这个团队怎样判断风险、什么问题应当阻塞合并、评论应该写在行内还是总结区。
这些不属于连接协议要解决的任务。
Agent Skill 通常由 SKILL.md 和可选的脚本、参考资料、模板组成。它可以规定：
仍以代码审查为例，一个 Skill 可以要求：
Skill 提供的是程序性知识：不是“能调用哪个工具”，而是“怎样把工具组织成可靠任务”。
假设用户要求：
分析上个月销售额下降的原因，并生成一份管理层简报。
完整过程可以这样分工：
用户目标 → Skill 确认时间、销售额口径和交付格式 → Skill 把问题拆成趋势、区域、产品、渠道和客户 → MCP 调用受控问数工具获取数据 → Skill 检查口径、样本和异常，决定是否继续下钻 → MCP 按需获取补充数据 → Skill 按企业模板组织事实、分析、边界和建议 → Host 对发送或写入等动作进行权限判断与用户确认
在这个流程中：
这四层不能互相替代。
只有 MCP 的 Agent 可能拥有很多工具，却没有稳定方法。
例如，给 Agent 一个 SQL 查询工具，再问：“哪些客户最有价值？”工具可以执行 SQL，却不会替企业定义“客户价值”。它可能按收入排序，也可能按利润、复购、增长潜力或合同规模排序。
常见表现包括：
这不是 MCP 的缺陷，而是因为它本来就不负责完整工作流。
一个 Skill 可以把流程写得很专业，却不一定能访问外部系统。
它可以规定“查询当前有效薪资时要排除历史记录”，也可以附带分析模板。但如果真实薪资数据位于受控数据库，Agent 仍需要 MCP、API、CLI 或宿主内置工具获得访问能力。
常见边界包括：
Skill 可以调用 MCP 工具，但“调用 MCP”不等于 Skill 把 MCP 取代了。
MCP Server 提供能力描述，是为了让 Host 和模型知道“有哪些外部工具可以调用、需要什么参数”。
Skill 提供元数据和正文，是为了让 Agent 知道“什么任务应该加载哪套方法、加载后怎样执行”。
两边都需要控制上下文：
不能简单断言 MCP 一定更耗上下文，或 Skill 一定更轻。实际取决于 Host 怎样筛选工具、Skill 怎样拆分资源，以及任务同时加载了多少无关信息。
更清楚的企业 Agent 架构可以分成四层：
| 层次 | 主要职责 | 例子 |
|---|---|---|
| 应用与交付层 | 承接用户目标与最终产物 | 对话、报告、PPT、工单 |
| Skill 方法层 | 沉淀流程、规则、模板和验收标准 | 销售复盘、代码审查、合同检查 |
| MCP 工具层 | 发现、连接和调用外部能力 | 问数、文件、GitHub、CRM |
| 数据与系统层 | 保存真实业务数据并执行操作 | 数仓、数据库、API、SaaS |
权限与审计不是单独放在某一格，而应贯穿每一层。Skill 不能因为写了“必须执行”就突破 MCP 和 Host 的权限；MCP 提供了写工具，也不代表 Agent 可以跳过用户确认。
如果需要，并且同一能力要被多个 AI 应用复用，可以优先考虑 MCP。如果只处理本地文件和固定模板，Skill 可能已经足够。
存在分析口径、审批规则、审查清单和固定交付模板时，适合沉淀为 Skill。一次简单工具调用不一定需要专门建设 Skill。
高风险任务需要同时加强两层：MCP 侧限制权限、认证和副作用；Skill 侧规定前置检查、禁止项、失败处理和验收标准。
格式转换、数据校验和命名检查适合放进 Skill 的脚本；访问远程业务系统的动作适合交给受控工具或 MCP Server。
两种扩展都可能引入供应链风险：
企业应建立来源审核、版本记录、最小权限、执行隔离、用户确认和日志审计。评估能力时，不应只数接入了多少工具、安装了多少 Skill，更要看真实任务能否以可解释步骤和可控边界完成。
两者不是按技术或非技术人群划分。非技术用户可以直接使用已配置好的 MCP 和 Skill；开发、部署和治理通常仍需技术团队参与。
可以。Skill 可以规定何时调用哪个工具、怎样处理结果以及是否继续下一步，但真实调用仍受 Host 与工具权限约束。
Server 可以提供说明、提示和组合能力，但复杂业务方法、组织规范和交付标准通常更适合放在 Skill 或应用工作流层，以便独立维护。
不一定。如果 Host 已有稳定查询工具，且任务没有重复流程，直接调用即可。只有出现跨应用复用或可重复方法时，MCP 与 Skill 的价值才更明显。
YiAsk MCP 可以向兼容 Agent 提供亿问 Data Agent 的问数能力；数据分析 Skill 再规定查询哪些指标、怎样下钻、如何核验和按什么模板输出。
本文比较的是 MCP 与 Agent Skill 的通用职责。不同平台可能把提示模板、插件、工具、Skill 和 MCP 组合成自己的产品形态，名称和安装方式不完全一致。
涉及真实业务系统时，应按目标 Host、Server 和 Skill 的当前实现逐项验证。任何一层的文字说明都不能代替身份认证、权限控制、执行确认和安全审计。