Appearance
MCP与Skills：AI Agent从聊天框到生产力系统的两块拼图
MCP让Agent有手有脚，Skills让Agent有经验有章法。真正的Agent不是会聊天，而是会接入、会执行、会复用经验。
核心问题
大模型到底怎样才能真正"干活"？
不是陪你聊天，不是写一段代码，而是：
- 能读文件、查数据库、调用API
- 理解公司内部流程
- 遵守操作规范
- 按照稳定步骤完成任务
- 在不同工具、模型、客户端之间可复用
两个关键方向：
| 方向 | 解决的问题 |
|---|---|
| MCP | Agent怎么连接外部世界 |
| Skills | Agent怎么学会稳定的做事方法 |
一、为什么需要MCP和Skills？
早期模式的局限
直接在聊天框里输入问题："帮我写一个函数"、"帮我总结这篇文章"。
问题：模型不知道你的真实环境——文件在哪、数据库结构、Git仓库状态、公司内部API、任务流程。
Tool Calling的困境
给模型提供工具后，从"只会说"变成"可以做"。
但新问题出现：
- 工具太多，怎么管理？
- 每个客户端都要重复接一遍？
- 工具输入输出格式谁来规范？
- 工具更新了，客户端怎么知道？
- 远程工具和本地工具怎么统一？
- 权限、认证、生命周期、版本兼容怎么处理？
如果每个AI产品都自己发明一套工具协议，生态就会碎成一地。
二、MCP的核心：不是工具本身，是工具协议
三层架构
| 角色 | 说明 |
|---|---|
| MCP Host | AI应用本身（Claude Desktop、Claude Code、VS Code） |
| MCP Client | Host内部连接MCP Server的组件 |
| MCP Server | 提供上下文、工具、资源、提示词等能力的程序 |
一个AI应用可以同时连接多个能力来源：
Claude Desktop
├── filesystem MCP server（读写文件）
├── GitHub MCP server（查issue、PR、仓库）
├── Sentry MCP server（分析错误日志）
├── 数据库 MCP server（查询业务数据）
└── 知识库 MCP server（读取文档）第一层价值：把外部能力从"硬编码插件"变成"可发现的服务"。
三、MCP两层结构：Data Layer + Transport Layer
数据层
关心：
- 调用什么方法？
- 参数是什么？
- 返回结果是什么？
- 有哪些能力可以被发现？
传输层
关心：
- 消息怎么送过去？
- 本地进程通信还是远程HTTP？
- 认证怎么做？
- 是否支持流式返回？
两种传输机制
| 机制 | 适用场景 |
|---|---|
| stdio transport | 本地MCP server，标准输入输出通信 |
| Streamable HTTP transport | 远程MCP server，HTTP POST + SSE，支持OAuth认证 |
意义：同一套数据层协议，可以跑在不同传输层之上。
四、MCP三大primitives：Tools、Resources、Prompts
| Primitive | 类型 | 说明 |
|---|---|---|
| Tools | 行动能力 | 可执行函数：文件操作、API调用、数据库查询 |
| Resources | 上下文能力 | 数据源：文件内容、数据库记录、API响应 |
| Prompts | 交互模式能力 | 可复用模板：代码审查模板、故障排查模板 |
Discovery机制：
tools/list发现工具tools/call执行工具- 工具列表可以是动态的（权限变化、服务可用性、项目切换）
五、MCP生命周期
Client发送initialize请求（协议版本、能力、信息）
↓
Server返回自己的能力
↓
Client发送initialized notification
↓
Client发送tools/list获取工具列表
↓
LLM决定调用工具，AI应用路由到对应MCP Server
↓
Server返回结构化结果，放回模型上下文
↓
模型继续推理和回复通知机制：notifications/tools/list_changed —— 工具列表变化时主动通知，避免轮询。
六、Skills的核心：把经验打包成可复用目录
为什么需要Skills？
即使Agent有了工具，也不一定知道"怎么正确使用"。
工具schema只能告诉模型：
- 这个函数叫什么
- 参数是什么
- 返回什么
但它很难表达：
- 处理PDF前先检查是否是扫描件
- 修改代码前先读CONTRIBUTING.md
- 生成release note时按团队固定格式
- 合并MR前必须确认pipeline通过
Skill目录结构
my-skill/
├── SKILL.md（核心：metadata + instructions）
├── scripts/（可执行脚本）
├── references/（参考资料）
├── assets/（模板和样例）
└── ...SKILL.md结构
yaml
---
name: pdf-processing
description: Extract PDF text, fill forms, merge files. Use when handling PDFs.
---
When working with PDFs:
1. Inspect the file type first.
2. Extract text using the preferred method.
3. If extraction fails, check whether the PDF is scanned.
4. Preserve layout when generating the final output.这不是API，是给Agent的"任务说明书"。
七、Skills的Progressive Disclosure：控制上下文成本
问题
100个skills，每个几千字说明，启动时全部塞给模型：
- 上下文爆炸
- 模型注意力分散
- 成本上升
- 无关规则互相干扰
解法
| 阶段 | 加载内容 |
|---|---|
| 启动时 | 只加载name和description |
| 任务匹配时 | 读取完整SKILL.md指令 |
| 执行时 | 按需运行脚本或加载引用文件 |
类似于人类工作的"目录+手册"模式。
八、MCP与Skills的区别：连接器 vs 方法论
| 维度 | MCP | Skills |
|---|---|---|
| 层级 | 协议层 | 知识封装层 |
| 关心 | 怎么连接、怎么发现、怎么调用 | 怎么做、有哪些步骤、边界情况 |
| 比喻 | USB-C接口 | 可执行的操作手册 |
案例：公司内部release assistant
MCP层提供：
- GitLab MCP server：读取MR、pipeline、commit
- Slack MCP server：发送通知
- Jira MCP server：读取ticket状态
- 内部文档MCP server：读取checklist
Skills层提供：
- release-note-writing：怎么写release note
- merge-request-review：合并前检查哪些条件
- standup-update：怎么写内部进展更新
结论：
- 没有MCP，Agent无法稳定接入真实系统
- 没有Skills，Agent做事风格混乱、流程不稳定
- 二者结合，才接近真正的生产力Agent
九、MCP + Skills + LLM Pool架构
| 层级 | 内容 |
|---|---|
| 外部系统 | 文件系统、数据库、GitLab、Slack、浏览器、内部API |
| MCP Servers | filesystem server、git server、database server... |
| Agent Runtime | 管理连接、维护tool registry、路由tool call、处理notifications |
| Skills Registry | 技能发现、按需加载、版本管理、团队共享 |
| LLM Pool | 便宜模型分类初筛、强模型复杂规划、代码模型实现、长上下文模型文档分析 |
| 用户界面 | 聊天界面、IDE插件、桌面应用、命令行工具 |
十、对开发者的意义
机会
| 变化 | 说明 |
|---|---|
| 工具提供MCP Server | "Install our MCP server, then your AI agent can use our product" |
| 内部工具更容易被Agent使用 | 包装成MCP Server，多个Agent客户端可接入 |
| Prompt变成工程资产 | Skills进Git，可版本管理、测试、审计 |
| 竞争转向系统能力 | 接入多少系统、工作流多稳定、Skills多专业 |
创业方向
- 某个垂直领域MCP Server
- 某类高质量Skills包
- 某个Agent Runtime
- 某个企业内部Agent平台
- 某个SaaS的MCP接入层
十一、风险与治理
MCP风险
Agent可读文件、写文件、调用API、执行命令 → 权限边界必须清晰。
| 问题 | 解法 |
|---|---|
| 哪些工具只读？ | 权限模型 |
| 哪些操作需确认？ | 审批机制 |
| 远程如何认证？ | OAuth + token安全存储 |
| 数据是否泄露？ | 日志审计 |
Skills风险
Skill是给Agent的指令包，可能包含不安全步骤。
| 问题 | 解法 |
|---|---|
| 步骤不安全 | 测试评估 |
| description太宽泛 | 精准触发词 |
| 多Skills规则冲突 | 版本控制、最小权限原则 |
结语
真正的Agent不是会聊天，而是会接入、会执行、会复用经验。
| 问题 | 新问题 |
|---|---|
| 它聪不聪明？ | 它能不能接入我的真实系统？ |
| 会不会写代码？ | 它能不能理解我的工作流程？ |
| 回答准不准？ | 它能不能稳定复现专家经验？ |
| 上下文多长？ | 它能不能被版本管理、测试和审计？ |
MCP把"外部能力"协议化，Skills把"操作经验"文件化。
两者结合，Agent才可能从"聪明的聊天窗口"变成"可维护、可扩展、可治理的生产力系统"。
关键词：MCP, Skills, AI Agent, Model Context Protocol, 工具协议, Agent架构
