MCP到底要不要学？跑完四种方式的真实结论

Wed, 01 Jul 2026 08:45:00 +0800

作者：varkm

“MCP已死，CLI当立。"——Perplexity的CTO一句话炸了锅。

知乎上"MCP到底要不要学"冲上热榜，评论区吵成两派：一派说MCP是未来，上万服务器的生态碾压一切；另一派说这玩意太重，写个命令行三秒搞定的事，凭什么要部署一个Server进程？

我没急着站队。而是把CLI、Function Call、Skill、MCP四种方式全部跑了一遍，用同一个场景：让AI帮你查天气，把结果写成文件，再发个消息通知。

跑完之后的结论很明确，先给你：

四种方式不是互斥关系，是不同场景的最优解。选错范式比选错工具更致命。

CLI：会写命令就行，三秒搞定

CLI是最古老的方式，也是最被低估的方式。

查天气、写文件、发通知，一行命令链搞定：

1
2
3
4


# 查北京天气 → 写入文件 → webhook发通知
curl -s wttr.in/Beijing?format=3 > weather.txt && \
curl -s -X POST https://api.example.com/webhook \
 -d "msg=$(cat weather.txt)"

AI只需要理解这些命令的含义，然后组合它们。不需要部署任何东西，不需要写schema，不需要启动进程。

优势：

零部署成本，系统自带
可组合性最强——管道、重定向、&&串联，Unix几十年的积累
调试简单，出问题直接看终端输出

劣势：

安全性继承操作系统权限，rm -rf /这种命令AI也能执行
只能操作本地环境，远程API需要自己拼URL
依赖AI对命令行的理解深度

什么时候用CLI：本地文件操作、系统管理、Shell脚本组合。AI助手帮你整理文件、批量重命名、跑测试脚本——CLI是首选。

Function Call：写个JSON，模型自己选

Function Call（函数调用）是各大模型厂商原生支持的方案。你定义函数的schema，模型根据用户意图自动选择调用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


# 定义三个函数，让模型自己选
tools = [
 {
 "type": "function",
 "function": {
 "name": "get_weather",
 "description": "查询指定城市天气",
 "parameters": {
 "type": "object",
 "properties": {
 "city": {"type": "string", "description": "城市名"}
 },
 "required": ["city"]
 }
 }
 },
 {
 "type": "function",
 "function": {
 "name": "write_file",
 "description": "写入文件",
 "parameters": {
 "type": "object",
 "properties": {
 "path": {"type": "string"},
 "content": {"type": "string"}
 },
 "required": ["path", "content"]
 }
 }
 },
 {
 "type": "function",
 "function": {
 "name": "send_message",
 "description": "发送通知消息",
 "parameters": {
 "type": "object",
 "properties": {
 "msg": {"type": "string"}
 },
 "required": ["msg"]
 }
 }
 }
]

# 模型收到"帮我查北京天气存到文件再通知我"后
# 会自动决定调用顺序：get_weather → write_file → send_message

优势：

零部署，API内置
模型自己决定调用时机和参数，灵活度高于CLI
安全边界清晰——你定义了哪些函数，模型就只能调哪些

劣势：

每个函数都要手写schema，量大时很烦
函数之间无法组合，get_weather的结果要你自己喂给write_file
绑定特定模型API，换厂商要改代码

什么时候用Function Call：单次API调用、模型平台内的工具集成。你做了一个聊天机器人，想让它能查数据库、调内部接口——Function Call最直接。

Skill：写个Markdown，流程可复用

Skill的本质是一份操作手册——你用Markdown写清楚步骤，AI按手册执行。

写一个"查天气+写文件+发通知"的Skill：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 天气报告生成器

## 触发条件
用户说"天气报告"、"每日天气"时激活

## 步骤
1. 执行 `curl -s wttr.in/{city}?format=3` 获取天气
2. 将结果写入 ~/reports/weather-{date}.txt
3. 调用通知接口发送内容

## 注意事项
- 城市名默认北京，用户指定时替换
- 天气获取失败时重试3次

把这个文件放到指定目录，AI下次遇到相关请求就会自动加载并按流程执行。

优势：

写Markdown就行，门槛最低
一旦写好可以无限复用，团队共享
AI按流程走，结果可预期、可审计
可以嵌套调用，组合复杂流程

劣势：

流程是"死"的，遇到手册没覆盖的情况就卡住
每个新流程都要写一份新Skill
执行时仍有安全风险——Skill里写rm -rf，AI也会执行

什么时候用Skill：固定流程的标准化操作。每日报告生成、代码审查流程、部署检查清单——重复性的、有标准步骤的工作。

MCP：部署一个Server，接入整个生态

MCP（Model Context Protocol）是四种方式里最重的。你要写一个Server，定义资源、工具和提示，然后通过协议让AI接入。

用Python写一个最简MCP Server：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-tools")

@mcp.tool()
def get_weather(city: str) -> str:
 """查询指定城市天气"""
 import requests
 r = requests.get(f"https://wttr.in/{city}?format=3")
 return r.text.strip()

@mcp.tool()
def write_file(path: str, content: str) -> str:
 """写入文件"""
 with open(path, "w") as f:
 f.write(content)
 return f"已写入 {path}"

@mcp.tool()
def send_message(msg: str) -> str:
 """发送通知"""
 import requests
 requests.post("https://api.example.com/webhook", data={"msg": msg})
 return "消息已发送"

if __name__ == "__main__":
 mcp.run()

然后客户端配置一下就能用。Smithery、mcp.so等注册表上已有上万个现成的MCP Server，GitHub、数据库、浏览器、文件系统……生态是四种方式里最丰富的。

优势：

生态最丰富，上万现成Server开箱即用
标准协议，跨平台/跨模型通用
远程服务接入的最佳方案——数据库、SaaS API都能封装成MCP
FastMCP日均下载100万+，社区活跃

劣势：

部署复杂度最高——要管理Server进程的生命周期
认证和安全是额外负担，每个Server都要单独处理
对简单场景来说太重了，杀鸡用牛刀
调试链路长，出问题排查成本高

什么时候用MCP：远程服务接入、团队级工具共享、需要跨平台标准化的场景。你想让AI能操作GitHub、连数据库、调企业内部API——MCP的生态优势无可替代。

决策框架：什么场景选什么

跑完四种方式，我整理了一张决策表：

场景特征	推荐方式	理由
本地文件/系统操作	CLI	零部署，管道组合最强
单次API调用，模型平台内	Function Call	原生支持，零配置
固定流程，需要重复执行	Skill	写个Markdown就能复用
远程服务接入，团队共享	MCP	生态丰富，标准协议
需要AI自主决策调用时机	Function Call	模型自己选，最灵活
已有CLI工具，想快速接入	CLI	直接用，不用重新封装

更简单粗暴的决策树：

1
2
3
4
5
6
7


要不要操作本地系统？
├─ 要 → 有现成命令吗？
│ ├─ 有 → CLI
│ └─ 没有，要写代码 → Function Call
└─ 不要 → 要不要重复执行？
 ├─ 要，有标准步骤 → Skill
 └─ 不要，要接远程服务 → MCP

“不可能三角”：你只能选两个

知乎上有一篇热门文章提出了一个精准的框架——Skill、MCP、CLI构成了一个"不可能三角”：

	易用	安全	灵活
Skill	✅ 写Markdown就行	⚠️ 执行层不可控	❌ 流程死板
MCP	❌ 部署复杂	⚠️ 认证开销大	✅ 生态丰富
CLI	✅ 会写命令就行	❌ 继承OS权限	✅ 管道组合

易用、安全、灵活——三者不可兼得。每种方式都在牺牲一个维度：

Skill牺牲了灵活性——流程写死了，遇到意外就卡壳
MCP牺牲了易用性——部署、认证、进程管理，门槛最高
CLI牺牲了安全性——rm -rf人人平等，AI也不例外

Function Call可以看作这个三角的"第四维"——它在易用和灵活之间取了平衡，但牺牲了可组合性（函数之间不能串联）。

所以MCP到底要不要学？

回到最初的问题。

要学。但不应该是你学的第一个，也不应该是你唯一学的。

原因很简单：

MCP的生态壁垒是真实的。上万Server、FastMCP日均百万下载，这不是炒作出来的数字。当你要让AI接入GitHub、操作数据库、调企业API时，MCP生态能省下大量封装工作。
但MCP不是万能的。Perplexity放弃MCP不是因为MCP不好，而是因为他们的场景（搜索+推理）更适合用CLI组合。场景决定工具，不是工具决定场景。
真正的竞争力是"四件套全会"。只会MCP的人遇到本地文件操作会过度工程化；只会CLI的人遇到远程服务接入会无从下手。四种方式都跑一遍，你才知道什么场景用什么武器。

钉钉、飞书、企业微信在同一周开源了各自的CLI——这不是巧合。业界正在意识到，不是所有问题都需要一个Server进程。

选错范式比选错工具更致命。 用MCP去做CLI三秒能搞定的事，和用CLI去硬刚MCP的生态壁垒，一样是浪费时间。

工具箱里要有锤子，也要有螺丝刀。关键不是哪个更好，而是拧螺丝的时候别拿锤子砸。

Function Call on Kalend's Blog