LLM - Skills vs MCP：AI Agent 能力扩展的双螺旋

AI Agent技术栈中的Skills与MCP（Model Context Protocol）是两条关键能力路径：Skills负责固化方法论和流程（如代码审查、文案规范），通过结构化知识提升Agent的专业性；MCP则标准化外部系统连接（如GitHub、数据库），实现安全可控的工具调用。两者分别从内部心智和外部感知维度增强Agent能力，需协同使用——Skills确保执行质量，MCP扩展能力边界。

小小工匠

723人浏览 · 2026-01-03 06:30:00

小小工匠 · 2026-01-03 06:30:00 发布

文章目录

Pre
一、从“提示工程”到“能力工程”
- 1.1 一句话区分 Skills 与 MCP
- 1.2 能力栈中的位置
二、Skills：把“经验与方法”变成可执行资产
三、MCP：给 Agent 一条标准化“能力总线”
四、Skills vs MCP：多维度差异与互补
- 4.1 关键差异一览
- 4.2 为什么“只能二选一”是个伪命题？
五、实战：构建一个“端到端数据分析 Agent”
六、工程落地：决策指南与最佳实践
七、进阶模式：治理、安全与演进
八、面向未来的“能力中台”视角

在这里插入图片描述

Pre

在当前的 AI Agent 技术栈中，Skills 与 MCP（Model Context Protocol）正在迅速成为两条同样关键、却分工不同的“能力螺旋”。一条向内塑造 Agent 的方法论和行为模式，一条向外打通数据、工具与系统边界。对于想要在工程实践中落地高可用、高可控 Agent 的团队来说，理解并用好这两者，将直接决定你的智能体是“玩具 Demo”，还是能接上真实业务的大规模生产系统。

一、从“提示工程”到“能力工程”

传统的 Prompt Engineering 更像是“写一段好提示”，靠人脑临时发挥，难以系统复用。 Skills 与 MCP 则代表了一种新的范式：将知识与能力工程化，变成可版本化、可组合、可治理的基础设施。

1.1 一句话区分 Skills 与 MCP

Skills：教 Agent “怎么思考”
把流程、规范、最佳实践、输出格式等，以结构化的方式固化下来，让 Agent 在遇到某类任务时，自动采取“专业人士会怎么做”的那套方法。
MCP：让 Agent 知道“能访问什么”
它定义了 Agent 如何安全、标准化地访问数据库、API、文件系统、协作工具等外部世界，相当于给 Agent 配备统一的“能力总线”。

如果打个比方：Skills 更像“系统内建的专业模块”，MCP 更像“插在主板上的扩展接口”。

1.2 能力栈中的位置

可以把一个实用 Agent 的能力栈简单分层为：

基础模型能力：推理、生成、理解指令
Skills 层：流程、方法论、规范、输出模板
MCP 层：Google Drive、GitHub、Postgres、Slack 等外部系统接口
执行引擎：代码执行、工具调用、工作流编排等

从这个视角看，Skills 更多塑造“内在心智结构”，MCP 则负责“外部神经连接”。

二、Skills：把“经验与方法”变成可执行资产

很多团队已经积累了大量可复用的 Prompt 片段：代码审查 checklist、产品文案风格指南、数据分析 SOP、报警处理流程等。 Skills 解决的问题，就是把这些零散的 Prompt 升级为一种标准化的“知识胶囊”。

2.1 三层渐进披露：既多技能，又不炸上下文

Anthropic 的 Skill 设计，有一个非常优雅的三层结构：

元数据层
- 加载时机：Agent 启动时
- 内容：name、description 等
- 类比：目录、封面，帮助 Agent 识别“有这么一个技能”
指令层
- 加载时机：与当前任务语义匹配时
- 内容：完整 Markdown 指令、流程、示例
- 类比：具体章节内容
资源层
- 加载时机：需要额外文档/脚本时
- 内容：大体量参考文档、脚本、附录
- 类比：附录与工具书

这种设计的关键收益是：即便挂载了上百个 Skill，Agent 也不会一上来就把所有内容塞进上下文，而是按需分级加载，兼顾“能力丰富”与“Token 友好”。

2.2 一个最小可行 Skill 长啥样？

典型的 Skill 是一个文件夹 + SKILL.md 的结构，SKILL.md 里用 YAML frontmatter + Markdown 正文来描述它是谁、干什么、怎么干。以“Python 代码审查标准”为例，最小结构大致如下（示意简化）：

code-review-standard/
└── SKILL.md

SKILL.md 中通常包含：

元信息：name、description、allowed-tools、推荐模型等
操作手册：审查步骤、关注点、输出格式
示例：典型输入输出样例，帮助模型对齐风格

在更复杂的 Skill 中，还会拆出：

advanced-analyzer/
├── SKILL.md          # 总入口：概述 & 索引
├── METHODOLOGY.md    # 详细方法论
├── REFERENCES/       # 各种参考文档
└── scripts/          # 可执行脚本

通过这种结构，一个 Skill 不再只是“一段长 Prompt”，而是一个可维护的“小型知识包”。

2.3 为什么说“写 Skill”门槛很低？

对一线开发者来说，Skill 的最大优势在于：主要工作就是写 Markdown。

用你熟悉的方式整理知识：Checklist、流程图、SOP
用 Git 管理版本：代码评审流程升级、品牌规范更新都能走正常 PR 流程
通过 allowed-tools 做白名单，确保安全边界不会被随意突破

这让 Skills 成为一个非常适合团队内部推广的“轻量级工程实践”：比搭一个平台简单得多，却能把“好的 Prompt 习惯”沉淀为真正的资产。

三、MCP：给 Agent 一条标准化“能力总线”

如果说 Skills 是在“教 Agent 做事的方法”，MCP 做的是“把 Agent 接上真实世界的设备和系统”。它的目标是：用一个统一协议，打通各种工具和数据源，让不同 Agent/不同宿主都能以一致方式调用这些能力。

3.1 Client–Server 架构与 JSON-RPC

MCP 采用了经典的 C/S 架构，协议层基于 JSON-RPC 2.0。

MCP Client
- 内置在宿主（如 Claude Desktop、某些 IDE 插件）中
- 负责启动与管理 MCP Server 进程
- 负责发起工具列表、工具调用、资源读取等请求
MCP Server
- 作为独立进程运行
- 实现 tools/list、tools/call、resources/read 等接口
- 内部对接 REST API、GraphQL、SDK、数据库驱动等
传输层
- 本地场景常用 stdio（既简单又安全）
- 远程部署时可用 WebSocket

对 Agent 来说，它只需要知道“有哪些工具、怎么调用、入参 Schema、返回 Schema”，至于背后是 GitHub 还是内部 CRM，并不重要。

3.2 调用生命周期与设计要点

以“查询 GitHub 未读通知”为例，一个典型流程大致是：

Client 向 Server 请求 tools/list，拿到 get_notifications 之类的工具描述
Agent 根据自然语言任务选定工具与参数
Client 使用 tools/call 调用该工具
Server 与 GitHub 通信，拿到结果后返回给 Client
结果以结构化 JSON 返回，再注入到 Agent 的上下文中继续推理

MCP 在设计时强调了几个点：

无状态调用：每次 tool call 独立，避免复杂状态同步
结构化 I/O：参数与结果用 JSON Schema 约束，方便验证与调试
能力发现：工具列表与用法可动态查询，使得 Agent 能“自发现”可用能力

3.3 常见 Server 类型与使用场景

当前社区与官方已经提供了大量 MCP Server 示例，例如：

filesystem：本地文件读写，典型用于本地代码库分析
postgres：通过 SQL 查询结构化业务数据
github：查看 PR、创建 Issue、项目巡检
slack：读取消息、发送通知、自动化运维告警
puppeteer：网页抓取、截图、自动化测试

换句话说，MCP 正在把“写一堆 ad-hoc 工具函数”的时代，替换为“接一个统一协议，享受共享生态”的时代。

四、Skills vs MCP：多维度差异与互补

把两者放在同一张表里，对比会更直观。

4.1 关键差异一览

维度	Skills	MCP
设计哲学	知识封装：教 Agent 如何思考	能力连接：让 Agent 能访问哪些信息和系统
时间属性	持久化、版本化存储，像长期记忆	调用时临时注入结果，像瞬时感官输入
挂载位置	Agent 内部方法论层	Agent 外部工具与数据源层
交互方式	声明式 + 自动触发	命令式 + 按需调用
Token 策略	三层渐进加载，尽量减少无关内容	调用时注入，结果用完即释放
开发成本	Markdown + 少量脚本，门槛极低	需实现 Server，成本中等但可复用性强
典型场景	代码规范、SOP、写作/分析框架、品牌手册	DB 查询、GitHub/Slack 操作、文件访问、自动化任务
失败模式	推理不准、风格不统一，可靠自我纠正缓解	上游服务出错、网络波动、权限问题
管理方式	Git 仓库管理、Review、版本发布	配置文件声明、运维监控、权限治理

从时间与空间两个维度看，可以简化记忆为：

时间维度：Skills = 持久知识，MCP = 瞬时数据
空间维度：Skills = 内部心智增强，MCP = 外部感知扩展

4.2 为什么“只能二选一”是个伪命题？

很多团队在上马 Agent 工程时，常会问：“我们现在先做 Skill，还是先接 MCP？”

更合理的视角是：

没有 Skills 的 MCP Agent：
- 能调用很多工具，却缺乏统一流程与质量标准
- 不同开发者实现出来的“咨询机器人”，风格完全不一致
没有 MCP 的 Skills Agent：
- 知道怎么写一份好报告，但拿不到最新数据
- 能输出漂亮格式，却始终停留在“脱离业务一公里”的位置

真正有价值的是双螺旋——用 Skills 定义“做事之道”，用 MCP 提供“做事所需的环境与材料”。

五、实战：构建一个“端到端数据分析 Agent”

下面通过一个完整示例，把 Skills + MCP 的协作流程串起来：目标是让 Agent 能“分析销售数据，生成品牌一致的报告，并通知团队”。

5.1 项目结构设计

假设你使用的是支持 Skills 与 MCP 的宿主（例如带 .claude/ 配置的项目工作区），目录可能长这样：

project/
├── .claude/
│   ├── skills/
│   │   ├── data-analysis-framework/
│   │   │   └── SKILL.md
│   │   ├── brand-guidelines/
│   │   │   └── SKILL.md
│   │   └── notification-templates/
│   │       └── SKILL.md
│   └── config.json        # MCP Server 配置
└── data/
    └── sales_q4.csv

data-analysis-framework：定义数据分析五步法
brand-guidelines：规定配色、语气、排版
notification-templates：封装 Slack/邮件通知模版
config.json：挂载 Postgres、Slack、GitHub 等 MCP Server

5.2 用 Skills 固化“分析流程 + 品牌风格 + 通知格式”

三个核心 Skill 的角色大致是：

data-analysis-framework
- 规定分析必须依次执行：描述统计 → 趋势识别 → 异常检测 → 根因分析 → 行动建议
- 强制输出结构：执行摘要、ASCII 图表、优先级标记
brand-guidelines
- 规定配色、标题字体、用语风格（例如统一使用“我们”，避免过度夸张形容词）
notification-templates
- 封装 Slack 消息模板、邮件模板，保证通知内容风格一致

这些内容全部用 Markdown 写在各自的 SKILL.md 中，易于团队协同维护。

5.3 用 MCP 打通“数据源 + 协作工具”

在 .claude/config.json 中，可以配置多个 MCP Server：

一个 postgres-sales：连接生产或分析库
一个 slack-team：向指定频道发送消息
一个 github-project：为重要分析结果自动建 Issue

典型配置方式是为每个 Server 指定启动命令（command + args），如用 Python 模块、npx、Docker 镜像等，具体细节由各个 Server 的实现决定。

5.4 从“用户一句话”到“完整自动化链路”

当用户在终端或 IDE 中发出一句话请求：

“分析 Q4 销售数据，生成报告并通知团队”

理想中的执行链会自动完成：

Skill 自动匹配
- “分析数据” → 触发 data-analysis-framework
- “生成报告” → 触发 brand-guidelines
- “通知团队” → 触发 notification-templates
MCP 数据获取
- 调用 postgres-sales 读取 Q4 相关数据
按 Skill 执行分析与报告生成
- 严格遵守五步法与品牌规范输出
MCP 执行动作
- 通过 slack-team 把报告摘要发到指定频道
- 通过 github-project 创建带上下文的 Issue（可选）