AI 如何改变世界：Skill、MCP、CLI 的架构分层与协作
引言：一个看似”重复”的问题
如果你刚接触 AI Agent 的 Skill 和 MCP 机制，大概率会产生这样的疑问：
“Skill 不就是个能跑脚本的文件夹吗？和 CLI 有什么区别？MCP 不也是调远程工具吗？这三者难道不是在重复造轮子？”
这个直觉非常合理 —— 单看代码和最终执行，它们的底层确实都落在”跑一段代码”上。但把视角拉高，三者解决的是完全不同层次的问题。本文用一个极简的 Skill Demo 作为起点，逐层拆解这三者的定位、区别和共存逻辑。
一、Skill 是什么 —— 一个极简 Demo
先说清 Skill 长什么样。下面是一个完整的 project_env 技能，功能只有一句话：检查 PyTorch 项目环境是否就绪。
目录结构
project_env/
├── SKILL.md # 给 AI 看的"说明书"
└── main.py # 真正干活的脚本
SKILL.md
---
name: project_env
description: 检查本 PyTorch 项目的运行环境是否就绪
---
# 环境检查技能
一句话：检查 Python、PyTorch、CUDA、项目依赖是否就绪。
## 使用示例
**输入：** `检查环境`
**输出：**
>>> 技能 [project_env] 开始执行
Python: 3.10.x
PyTorch: 2.4.x
CUDA 可用: True
项目依赖: requirements.txt (12 个包)
>>> 技能 [project_env] 执行完毕
## 工作原理（极简解释）
用户说"检查环境"
→ AI 匹配到 project_env 技能
→ AI 读取 SKILL.md，理解技能的意图
→ AI 执行 main.py
→ 脚本输出结果
→ AI 将结果呈现给用户
## 文件结构
project_env/
├── SKILL.md ← AI 读这个文件来理解技能
└── main.py ← 技能被调用时执行这个脚本
main.py
def run():
import sys
print(">>> 技能 [project_env] 开始执行")
print(f"Python: {sys.version}")
try:
import torch
print(f"PyTorch: {torch.__version__}")
print(f"CUDA 可用: {torch.cuda.is_available()}")
except ImportError:
print("PyTorch: 未安装")
import os
req = os.path.join(os.path.dirname(__file__), "..", "..", "..", "requirements.txt")
if os.path.exists(req):
with open(req, encoding="utf-8") as f:
count = sum(1 for _ in f)
print(f"项目依赖: requirements.txt ({count} 个包)")
else:
print("项目依赖: 未找到 requirements.txt")
print(">>> 技能 [project_env] 执行完毕")
if __name__ == "__main__":
run()
实际运行结果
>>> 技能 [project_env] 开始执行
Python: 3.14.3
PyTorch: 2.11.0+cpu
CUDA 可用: False
项目依赖: requirements.txt (23 个包)
>>> 技能 [project_env] 执行完毕
到这里，你很可能觉得：”这和一个普通 Python 脚本有什么区别？”
是的，单看工具代码本身，没有任何区别。 但关键不在于工具，而在于工具被谁、以什么方式发现和调用。
二、Skill vs CLI —— “调用方式变了”本身就是革命
2.1 适配方向的反转
传统 CLI： 人 ──必须适应──→ 工具的语法和参数
↑
人做适配工作
技能模式： 人 ──说意图──→ AI ──适配──→ 工具
↑
AI 做适配工作
CLI 的调用链路是人 → 记参数 → 敲命令 → 解读输出，每一步都需要人的认知参与。
Skill 的调用链路是人 → 说意图 → AI 读说明书 → AI 执行 → AI 解读结果。适配成本的承担者从人变成了系统。
2.2 历史上每次都如此
| 时代 | 工具本质 | 交互方式 | 适配者 |
|---|---|---|---|
| DOS | 程序还是程序 | 命令行 | 人 |
| GUI 桌面 | 程序还是程序 | 鼠标点击、窗口 | 人（门槛降低但仍在） |
| 搜索引擎 | 数据还是数据 | 关键词 | 人 |
| 移动互联网 | 程序还是程序 | 触摸、语音 | 人 |
| AI Agent + Skill | 程序还是程序 | 意图表达 | AI |
每次交互方式的跃迁，驱动它的都不是”工具代码变高级了”，而是适配负担的转移。这一轮的不同在于：适配者从人变成了 AI，这是质变而不仅仅是量变。
2.3 另一个被低估的变化：工具组合的自由度
独立 CLI 工具要协作，人需要学每个工具的接口、写胶水脚本。但当 AI 同时持有多个 Skill 的说明书后，可以临场编排组合：
用户："检查环境没问题后，跑一遍所有示例脚本，把失败的列出来"
AI 内部编排：
project_env → 遍历 examples/*.py → 收集报错 → 生成报告
两个 Skill 的作者从未考虑过彼此的存在，但 AI 在现场把它们缝到了一起。这是 CLI 独立运行无法做到的。
三、Skill vs MCP —— 不同层次的分工
当理解了 Skill 之后，下一个自然的问题是：MCP 又是什么？和 Skill 有什么不同？
3.1 三者定位速览
| 维度 | CLI | Skill | MCP |
|---|---|---|---|
| 本质 | 工具的原始接口 | 工具的 AI 说明书 | 工具的标准化协议 |
| 谁用 | 人 | AI（通过读 SKILL.md） | AI（通过协议规范） |
| 作用域 | 单次执行 | 项目级、上下文绑定 | 跨项目、服务级 |
| 发现机制 | 人知道它存在 | AI 扫描目录匹配 | 协议握手注册 |
| 输入输出 | 命令行参数 | 文本流 | 结构化 JSON |
| 可组合性 | 人手动编排 | AI 自动编排 | AI 自动编排 |
| 跨项目复用 | 复制粘贴 | 需拷贝到每个项目 | 一次部署到处可用 |
3.2 核心差异
Skill（本地版）:
项目里放脚本 + 说明书
AI 看到后：读 → 跑 → 解读
MCP（协议版）:
远程服务实现标准协议
AI 看到后：通过协议调用 → 获取结构化结果
3.3 为什么不是”选一个就行”
三者解决的是不同层次的问题：
═══════════════════════════════════════════
层次 解决什么 怎么解
═══════════════════════════════════════════
CLI 工具"能不能跑" 参数定义、入口
Skill 工具"AI 会不会用" 说明书、上下文
MCP 工具"AI 能不能找到" 协议、注册、标准化
═══════════════════════════════════════════
一个比喻：
CLI 是插座（通电标准）
Skill 是电器说明书（告诉 AI 这个电器怎么用）
MCP 是物联网协议（让电器能被远程发现和控制）
你的微波炉面板（CLI）一直都在，智能家居 App（MCP）让它能被远程调用，而电器说明书（Skill）让新来的管家（AI）知道这东西是加热食物的。三样东西解决三个不同问题，不存在谁替代谁。
3.4 三者的合理共存
一个典型的 AI 编程助手架构：
MCP 层: │ GitHub MCP │ │ 数据库 MCP │ │ 自定义 MCP │
│ (远端服务) │ │ (远端服务) │ │ (本地服务) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
┌──────┴──────────────────┴──────────────────┴───────┐
│ AI 编排层 │
│ 同时持有全部 tool list，按需调度 │
└──────┬───────────────────┬─────────────────────────┘
│ │
Skill 层: ┌──────┴──────┐ ┌──────┴──────┐
│ project_env │ │ code_check │ ← 项目专属，携带项目上下文
└──────┬──────┘ └──────┬──────┘
│ │
CLI 层: ┌──────┴──────────────────┴──────┐
│ python main.py ... │ ← 最终都是执行命令
└─────────────────────────────────┘
MCP 回答”AI 能接触哪些工具”（横向扩展），Skill 回答”在这个项目里工具是什么、怎么用”（纵向深度），CLI 是它们共同的执行基础。不是重复，是分层。
四、AI 改变外部世界的完整能力矩阵
Skill 和 MCP 只是 AI 工具箱里靠上层的两个封装。AI 真正触达物理世界的方式远不止这两条路径：
4.1 六层能力
| 层级 | 方式 | 形态示例 |
|---|---|---|
| 文件系统 | 读/写/删/搜文件 | 创建 main.py、修改配置 |
| 终端命令 | 执行任意 shell 命令 | pip install、git push、docker up |
| 网络请求 | HTTP/API 调用外部服务 | GitHub API、Slack Webhook |
| 代码生成 | 制造新工具并落地 | 生成脚手架代码、创建新模块 |
| 浏览器操作 | 操作 DOM、填表单 | 自动化测试、操作无 API 的系统 |
| 数据库/OS | 读写数据、管理进程 | 查日志、启停服务 |
4.2 Skill 和 MCP 在这张图里的位置
┌─────────────┐
│ 外部服务 │
│ (GitHub, │
│ Slack, │
│ 数据库) │
└──────┬──────┘
│ HTTP / API
┌──────────┐ ┌──────┐ ┌───┴──────────┐
│ 用户 │ │ │ │ 网络请求 │
│ "检查环境"├───→│ AI ├──→│ requests │
└──────────┘ │ │ └──────────────┘
│ │
│ ├──→┌──────────────┐
│ │ │ 终端命令 │ → git, pip, docker...
│ │ │ subprocess │
│ │ └──────────────┘
│ │
│ ├──→┌──────────────┐
│ │ │ 文件系统 │ → 读/写/删/搜
│ │ │ open/fwrite │
│ │ └──────────────┘
│ │
│ ├──→┌──────────────┐
│ │ │ 代码生成 │ → 创造新文件/工具
│ │ │ Write() │
│ │ └──────────────┘
│ │
│ ├──→┌──────────────┐
│ │ │ Skill │ ← 给上面四条配说明书
│ │ │ (项目级封装) │
│ │ └──────────────┘
│ │
│ └──→┌──────────────┐
│ │ MCP │ ← 给网络请求配协议
│ │ (标准协议) │
│ └──────────────┘
4.3 各层的角色定位
| 层 | 角色 |
|---|---|
| 文件系统 / Shell / HTTP | 底层能力 — AI 真正改变世界的物理通道 |
| Skill | 项目级知识封装 — 让 AI 知道在这个项目里该怎么用底层能力 |
| MCP | 跨项目协议封装 — 让 AI 用统一方式对接外部服务 |
| 代码生成 | 创造新能力 — AI 自己造工具，改变能力的边界 |
五、一个技能的内部参数流
以 project_env 为例，从用户输入到结果显示的完整链路：
用户: "检查环境"
│
▼
AI 扫描 .trae/skills/ 目录
│
├─ 命中 project_env（SKILL.md name 匹配）
│
▼
AI 读取 SKILL.md
│
├─ 知道功能：检查 Python/PyTorch/CUDA/依赖
│
▼
AI 执行 python main.py
│
▼
脚本输出：
Python: 3.14.3
PyTorch: 2.11.0+cpu
CUDA 可用: False
项目依赖: requirements.txt (23 个包)
│
▼
AI 解读结果 → 呈现给用户
对于参数更复杂的 Skill（比如前面的 test_skill 支持 --show-hidden、--sort-by），流程一样：
用户: "技能测试 examples --sort-by size"
│
▼
AI 理解为: python main.py examples --sort-by size
│
▼
argparse 解析参数 → list_directory() 函数 → 返回结果
无论是零参数还是多参数，AI 都在中间充当了翻译官的角色——把人话翻译成脚本能懂的参数组合。
六、技能目录可以装什么
一个技能目录本质上是一个微型工作空间。除了 SKILL.md 和 main.py，常见的文件类型有：
| 文件类型 | 示例 | 作用 |
|---|---|---|
| 配置文件 | config.json / config.yaml |
技能的默认参数、开关 |
| 辅助脚本 | utils.py / helpers.py |
main.py 引用的公共函数 |
| 模板文件 | report.md / email.html |
输出格式化模板 |
| 测试脚本 | test_main.py |
技能自身的单元测试 |
| 依赖声明 | requirements.txt |
技能专属的第三方包 |
| 数据文件 | rules.csv / schema.json |
规则、映射表等参考数据 |
| 示例资源 | sample_input.txt |
演示用的输入输出样例 |
一个复杂的”代码质量检查”技能可能是这样的：
code_check/
├── SKILL.md
├── main.py
├── config.yaml
├── checks/
│ ├── pep8.py
│ ├── complexity.py
│ └── naming.py
├── templates/
│ └── report.md
├── rules/
│ └── ignore_list.txt
└── tests/
└── test_checks.py
七、结语
回到最开始的三个疑问：
“Skill 和 CLI 有何区别，是否重复？”
CLI 是工具的执行接口，Skill 是在其上加了一本 AI 可读的说明书。没有说明书，AI 不知道工具的存在和用法；没有 CLI，说明书没有可驱动的东西。它们是”方向盘”和”驾驶指南”的关系，不是重复。
“Skill 和 MCP 有何区别，为何要并存？”
Skill 解决”在这个项目里 AI 该怎么用这个工具”，MCP 解决”AI 如何发现和对接一个标准化的远程工具”。Skill 是项目级、上下文绑定的，MCP 是跨项目、协议标准化的。一个是本地说明书，一个是远程协议标准——各管一层。
“除了 MCP 和 Skill，AI 还有哪些方式改变外部世界？”
文件读写、Shell 执行、HTTP 调用、代码生成、浏览器操作——这五者是 AI 改变世界的底层物理通道。Skill 和 MCP 只是在这五个通道之上加了知识层和协议层，让 AI 知道”什么时候该走哪条通道、怎么走、走到哪里算成功”。
最终一句话：底层能力是”手脚”，Skill 是”使用手册”，MCP 是”通讯协议”，代码生成是”造新工具的能力”。四者各司其职，共同构成了 AI 与外部世界交互的完整图景。
本文基于 Trae IDE 的技能系统实际开发经验撰写。文中 demo 代码可在项目 .trae/skills/ 目录下查看。
