从MCP到Skill：AI Agent能力抽象的演进与Linux性能分析实战

导读：从 Function Call 到 MCP，再到 Skill，AI Agent 的能力抽象正在经历一场范式转移。本文结合 Linux 性能分析实战，揭示为什么 Skill 才是统一一切的终极形态。

引言：能力抽象的三次演进

2025 年被公认为 AI Agent 商业元年。当 Agent 从“能聊天”进化到“能办事”，一个核心问题浮出水面：如何让 AI 安全、可靠、可复用地调用外部能力？

回顾过去两年，我们见证了三次关键演进：

1.0 时代：Function Call（2023）

• 模型原生支持函数调用
• 每个工具需要单独定义 schema
• 碎片化严重，无法跨平台复用

2.0 时代：MCP（Model Context Protocol，2024）

• Anthropic 推出的标准化协议
• 统一了工具、资源、提示的接口
• 但仍然是“协议层”，不是“能力层”

3.0 时代：Skill（2025-2026）

• 能力的完整封装：代码 + 配置 + 文档 + 测试
• 可独立分发、版本管理、组合编排
• Skill 不是协议，是能力的“容器”

本文的核心观点：MCP 已死，Skill 当立。 不是 MCP 不够好，而是它生来就是中间层，而 Skill 才是能力的终极抽象。

Function Call：碎片化的起点

让我们从最基础的 Function Call 说起。

典型场景

假设你要让 AI 分析 Linux 服务器性能，需要暴露以下能力：

{
  "name": "get_cpu_usage",
  "description": "获取 CPU 使用率",
  "parameters": {
    "type": "object",
    "properties": {
      "duration": {"type": "string", "description": "采样时长，如 5s"}
    }
  }
}

每个工具都要定义一次 schema。当你有 10 个工具时，就有 10 份重复的 JSON。更糟的是：

• Claude 的 Function Call 和 OpenAI 的不兼容
• 工具逻辑散落在各个脚本里
• 没有版本管理，无法追踪变更
• 无法打包分发给其他人

Function Call 的本质缺陷：它只是“接口定义”，不是“能力封装”。

MCP：标准化的努力与局限

MCP 的设计哲学

2024 年，Anthropic 推出 Model Context Protocol（MCP），试图解决碎片化问题。MCP 的核心抽象：

┌─────────────────────────────────┐
│         MCP Server              │
├─────────────────────────────────┤
│  Tools    │  Resources  │  Prompts│
│  (执行)   │  (读取)     │  (模板) │
└─────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────┐
│         MCP Client              │
│    (Claude Desktop / Agent)     │
└─────────────────────────────────┘

MCP 通过 JSON-RPC 统一了三种能力：

• Tools：可执行的操作（如 run_command）
• Resources：可读的数据（如 file:///var/log/syslog）
• Prompts：预定义的提示模板

MCP 的进步

相比 Function Call，MCP 确实前进了一大步：
✅ 协议统一：一次定义，多处使用
✅ 资源抽象：不只是工具，还能读取文件、数据库
✅ 提示模板：可复用的交互模式
✅ 生态初现：出现了 MCP Server 市场

MCP 的致命缺陷

但 MCP 有一个根本性问题：它是协议，不是产品。

问题 1：MCP Server 仍然是“脚本集合”
一个典型的 MCP Server 目录结构：

my-mcp-server/
├── index.ts         # 入口文件
├── tools/
│   ├── cpu.ts       # CPU 工具
│   ├── memory.ts    # 内存工具
│   └── disk.ts      # 磁盘工具
└── package.json

这本质上还是代码仓库，不是可分发的“能力包”。用户需要：

1. git clone
2. npm install
3. 配置环境变量
4. 启动服务
5. 在客户端注册

问题 2：没有版本管理
MCP 没有原生的版本概念。你如何告诉用户“升级到 v2.0”？如何回滚？如何兼容旧版本？

问题 3：无法组合编排
你想把“CPU 分析” + “内存分析” + “生成报告”组合成一个工作流？MCP 没有原生支持。你需要自己写编排逻辑。

问题 4：测试与文档分离
MCP Server 的代码、文档、测试通常是分离的。用户如何验证这个 Server 是否可靠？

Skill：能力的终极容器

Skill 的定义

Skill = 代码 + 配置 + 文档 + 测试 + 版本

一个 Skill 是一个自包含的能力单元，可以独立分发、安装、升级、组合。

以 Linux 性能分析 Skill 为例：

skills/linux-performance/
├── SKILL.md           # Skill 描述（元数据 + 使用说明）
├── manifest.json      # 版本、依赖、入口
├── scripts/
│   ├── analyze-cpu.sh  # CPU 分析脚本
│   ├── analyze-mem.sh  # 内存分析脚本
│   └── generate-report.py  # 报告生成
├── references/
│   └── common-commands.md  # 常用命令参考
└── tests/
    └── basic-test.sh   # 基础测试

SKILL.md：能力的“身份证”

# linux-performance - Linux 性能分析 Skill

## 描述
自动分析 Linux 服务器 CPU、内存、磁盘、网络性能，生成诊断报告。

## 触发条件
用户提到“性能分析”、“CPU 高”、“内存不足”、“服务器卡顿”等。

## 能力列表
- `analyze_cpu` - CPU 使用率分析
- `analyze_memory` - 内存使用分析
- `analyze_disk` - 磁盘 IO 分析
- `analyze_network` - 网络流量分析
- `generate_report` - 生成综合诊断报告

## 版本
v1.2.0 (2026-03-15)

## 依赖
- bash 5.0+
- python3 3.10+
- 系统命令：top, free, iostat, netstat

SKILL.md 不是文档，是机器可读的能力描述。Agent 可以自动发现、自动加载、自动路由。

Skill vs MCP：关键差异

维度	MCP	Skill
抽象层级	协议层	能力层
分发方式	Git 仓库	可安装包
版本管理	无	语义化版本
依赖管理	手动	自动解析
测试	分离	内置
文档	分离	一体化
组合编排	手动	原生支持
发现机制	手动注册	自动发现

MCP 是“接口标准”，Skill 是“能力产品”。

实战：用 Skill 分析 Linux 性能

让我们通过一个完整案例，看 Skill 如何工作。

用户请求

“服务器 CPU 飙到 90%，帮我看看什么问题”

Skill 路由

Agent 收到请求后，自动匹配到 linux-performance Skill：

# 伪代码：Skill 路由逻辑
def route_request(user_message):
    skills = load_all_skills()
    for skill in skills:
        if skill.matches_trigger(user_message):
            return skill.execute(user_message)

Skill 执行

Skill 内部逻辑：

#!/bin/bash
# analyze-cpu.sh

echo “🔍 开始 CPU 性能分析...”

# 1. 获取 TOP 进程
echo “### 1. CPU 占用 TOP 10 进程”
ps aux --sort=-%cpu | head -n 11

# 2. 获取 CPU 使用率历史
echo “### 2. CPU 使用率趋势（过去 5 分钟）”
sar -u 60 5

# 3. 检查上下文切换
echo “### 3. 上下文切换频率”
vmstat 1 5 | awk ‘{print $11, $12, $13, $14, $15}’

# 4. 检查中断
echo “### 4. 硬件中断统计”
cat /proc/interrupts | sort -k2 -nr | head -n 10

# 5. 生成诊断建议
echo “### 5. 诊断建议”
# ... 基于规则的判断逻辑

输出结果

🔍 CPU 性能分析报告

### 1. CPU 占用 TOP 10 进程
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     12345  45.2  2.1  12345  6789 ?        R    10:00   1:23 java
root     23456  32.1  1.5  23456  7890 ?        S    10:01   0:45 python

### 2. CPU 使用率趋势
10:00:00  45%  30%  25%   0%
10:01:00  90%  75%  15%   0%
10:02:00  92%  78%  14%   0%

### 3. 诊断结论
⚠️ CPU 使用率持续高于 90%
⚠️ 主要占用进程：java (PID 12345)
💡 建议：检查 Java 应用线程堆栈，可能存在死循环或资源竞争

### 4. 下一步操作
- 运行 `jstack 12345` 查看线程堆栈
- 运行 `strace -p 12345` 跟踪系统调用
- 检查应用日志 /var/log/app.log

Skill 的优势

对比 MCP 方式，Skill 的优势显而易见：

环节	MCP 方式	Skill 方式
安装	git clone + npm install	skill install linux-performance
配置	手动编辑 config.json	自动检测环境
执行	启动 MCP Server，客户端连接	直接调用
升级	手动 pull + restart	skill update
分享	发送 Git 仓库链接	发送 Skill 包

为什么 Skill 能统一一切？

Skill 可以封装 MCP

MCP Server 可以作为 Skill 的一个子集：

skills/mcp-wrapper/
├── SKILL.md
├── mcp-server/      # MCP Server 代码
├── skill-wrapper.py # Skill 封装层
└── manifest.json

Skill 封装层负责：

• 将 MCP Tools 映射为 Skill 能力
• 处理版本兼容
• 提供统一的安装接口

MCP 成为 Skill 的实现细节，对用户透明。

Skill 可以封装 Function Call

同样，Function Call 也可以被 Skill 封装：

# Skill 内部调用 Function Call
def execute_skill(user_message):
    # 根据用户意图选择 Function
    if “cpu” in user_message:
        return call_function(“get_cpu_usage”, duration=“5s”)
    elif “memory” in user_message:
        return call_function(“get_memory_usage”)

对用户来说，只看到 Skill，看不到底层的 Function Call。

Skill 的组合编排

Skill 支持原生组合：

# workflow.yml
name: 全栈性能分析
skills:
  - linux-performance@v1.2.0
  - database-performance@v0.9.0
  - network-diagnostic@v1.0.0
steps:
  - skill: linux-performance
    action: analyze_cpu
  - skill: linux-performance
    action: analyze_memory
  - skill: database-performance
    action: analyze_slow_queries
  - skill: linux-performance
    action: generate_report

这是 MCP 无法做到的：MCP 没有工作流概念。

Skill 生态：正在发生的未来

Skill 市场

想象一个 Skill 市场（类似 npm、PyPI）：

$ skill search linux
NAME                    VERSION  DESCRIPTION
linux-performance       1.2.0    Linux 性能分析
linux-security          2.0.1    安全审计与加固
linux-backup            1.5.3    自动化备份
k8s-performance         0.8.0    Kubernetes 性能诊断

Skill 的商业模式

• 免费 Skill：社区贡献，开源
• 付费 Skill：专业服务，企业级支持
• 定制 Skill：为企业定制专属能力

Skill 开发者可以像 App 开发者一样获利。

Skill 与 Agent 的关系

未来架构：

┌─────────────────────────────────┐
│           Agent                 │
│  (理解意图、路由、编排)          │
└─────────────────────────────────┘
              │
              ▼
┌─────────────────────────────────┐
│         Skill Manager           │
│  (发现、加载、版本管理)          │
└─────────────────────────────────┘
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
┌───────┐ ┌───────┐ ┌───────┐
│Skill A│ │Skill B│ │Skill C│
└───────┘ └───────┘ └───────┘

Agent 是“大脑”，Skill 是“手脚”。

结论：MCP 已死，Skill 当立

MCP 的历史地位

MCP 完成了它的历史使命：

• ✅ 证明了标准化的价值
• ✅ 教育了市场：工具需要统一接口
• ✅ 为 Skill 的出现铺平了道路

但 MCP 生来就是中间层，不是终点。

Skill 的终极优势

优势	说明
完整性	代码 + 文档 + 测试 + 版本一体化
可分发	像 App 一样安装、升级、卸载
可组合	原生支持工作流编排
可发现	自动匹配用户意图
可商业化	独立的商业模式

行动建议

对于开发者：

• 不要只写 MCP Server，封装成 Skill
• 重视文档和测试，这是 Skill 的一部分
• 考虑版本兼容和升级路径

对于企业：

• 建立内部 Skill 市场
• 将核心能力封装为 Skill
• 优先采购 Skill 而非定制开发

对于用户：

• 学会使用 Skill 市场
• 关注 Skill 的版本和评价
• 反馈问题，帮助 Skill 改进

附录：Skill 源码示例

完整的 Linux 性能分析 Skill 已开源：

# 安装 Skill
skill install linux-performance

# 使用 Skill
“帮我分析服务器性能”

# 更新 Skill
skill update linux-performance

Skill 不是未来，Skill 是现在。

在技术社区，如云栈社区，关于人工智能和AI Agent的未来架构，以及具体的运维脚本实现，始终是开发者们热议的话题。