MCP（Model Context Protocol）是 Anthropic 在 24 年 11 月发布的开放协议，发布之后迅速成为 AI 开发者圈子里的热门话题，一度被称为 AI 应用的 USB-C 接口。不过上周开始因为某些硅谷大 V 的言论，似乎风向又变了。

具体来说，我先是看到 Y Combinator 的 CEO Garry Tan 在 X 上发帖说 MCP 在实际使用中体验很差，上下文窗口占用太高；好巧不巧，紧接着当天 Perplexity 的 CTO Denis Yarats 在 Ask 2026 大会上公开宣布，内部正在从 MCP 迁移回传统 API 和 CLI。这俩人的观点，也引发了更大范围的 MCP 到底行不行的讨论。

从企业大模型落地的视角看，我自己过去一年多做的 20 多个项目里，CLI 脚本写过、MCP Server 搭过、OpenClaw 上的 Skill 近期也在陆续开发中。三条路全走了一遍后的体感是，选型这件事并没有非黑即白的答案，核心还是场景导向。MCP 确实有 Token 开销高、认证体验差等问题，但在需要实时数据流和跨系统联动的场景里，私以为它目前还是最合适的选择。说它不行的人，多半是什么场景都想往 MCP 上堆。

这篇试图说清楚：

CLI、MCP、Skills 这三种方式到底各自适合什么场景、MCP 的 Token 成本到底有多高（有数据）、怎么用三个问题快速判断该选哪种方式、以及用同一个设备预测性运维场景，分别通过纯 CLI 脚本、MCP Server、OpenClaw Skill 三种原生方式实现后的真实对比。

以下，enjoy：

1、先搞清楚：CLI、MCP、Skills 到底是什么

在正式展开之前，老规矩，我先把几个核心概念快速和各位做个对齐。这三个词在不同文章里的定义经常混着用，为了防止理解偏差，先快速统一一下口径。另外，为了简化对比这三个概念之间的区别和联系，下面会以厨房场景作为对比。

1.1、CLI——直接伸手拿食材

CLI 就是命令行工具，这个开发背景的盆友应该都比较熟悉。在 AI Agent 的语境下，含义稍微扩展了一点：Agent 通过 bash/shell 直接调用命令来完成任务。比如 git push、curl、python analyze.py，也包括 claude-code、gemini-cli 这类 AI 编码工具。

核心特点就四个字：简单直接。一条命令，一个响应，没有协议开销，Token 消耗极低（通常不到 50 tokens）。为了好理解，用厨房的比喻来说，CLI 就是你直接伸手去抓食材和工具，不需要规范化的摆放，拿起来就用。

1.2、MCP——标准化的厨房

而 MCP 核心解决的问题是让 LLM 和外部工具之间有一个统一的通信接口。标准化的工具发现、统一的认证机制、实时数据流、有状态的交互，这些都是 MCP 的设计目标。

依然用厨房的比喻来说，MCP 就是一个标准化的厨房。刀具、锅、食材怎么摆放都有规范，不管谁来做菜都能快速上手。听起来很好，但代价也很直观。就是每个工具定义要常规消耗 400-800 tokens 的 JSON Schema，一个 GitHub MCP Server 初始化就要吃掉大约 50,000 token。这就是 Garry Tan 吐槽的根源，如果厨房太豪华了，光摆设就占了一半空间。

为了方便不熟悉 MCP 的盆友理解，这里举个栗子说明。下面是一个"查询 IoT 传感器数据"的 MCP 工具定义，仅仅这一个工具注入到上下文里就长这样：

{
  "name": "get_iot_status",
  "description": "查询指定泵设备的 IoT 实时传感器数据。返回最新的传感器读数，包括：振动（轴向/径向）、温度（电机/轴承）、出口压力、流量、电流消耗、功率因数和噪音水平。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "pump_id": {
        "type": "string",
        "description": "设备编号，如 PUMP-CNC-001 或 PUMP-CNC-002"
      }
    },
    "required": ["pump_id"]
  }
}

一个工具就这么一大堆，下面要演示的 Demo 一共 5 个工具，全部注入后光 Schema 就占了上千 token，而这还没具体开始干活。

1.3、Skills——食谱

最后是当前最火的 Skills，它和 MCP 的设计哲学其实有本质区别。MCP 的关键词是"连接"，换句话说，是为了建立 Agent 和外部系统之间的通道；而 Skills 的关键词是"教学"，也就是教 Agent 如何完成特定类型的任务。

这里我要多说两句，因为很多盆友第一次听到 Skill 会觉得这不就是一个 Markdown 提示词嘛？这个理解其实有失偏颇。

事实上，一个真正能用的 Skill，核心设计原则是渐进式披露，也就是 Agent 初始只看到 30-100 tokens 的元数据（名称、描述），知道有这么个能力；需要用的时候才展开完整指令。但关键在于，展开之后的内容远不止提示词，它可以包含领域知识表、CLI 脚本绑定、工作流程定义，甚至可以调用 MCP 服务作为底层执行方式。

用下面要演示的预测性运维 Skill 为例，截取其中几个关键部分看：

# SKILL.md（节选）

## 关键监测参数与阈值
| 参数 | 正常范围 | 警告阈值 | 危险阈值 |
|------|---------|---------|---------|
| 轴向振动 | < 3.0 mm/s | 3.0-5.0 mm/s | > 5.0 mm/s |
| 轴承温度 | < 65°C | 65-70°C | > 70°C |
| 出口压力 | 2.8-3.0 Bar | 2.5-2.8 Bar | < 2.5 Bar |

## 常见故障模式
1. 轴承磨损退化: 振动↑ + 温度↑ + 噪音↑ → 更换轴承 (CFP5K-BRG01)
2. 机械密封泄漏: 流量↓ + 压力↓ → 更换密封件 (CFP5K-SEAL01)

## 可用工具（CLI 脚本）
python scripts/check_pump.py --pump PUMP-CNC-001
python scripts/query_cmms.py --pump PUMP-CNC-001
python scripts/query_erp.py --part CFP5K-BRG01

## 工作流程
1. 调用 check_pump.py 获取 IoT 最新数据
2. 根据阈值表判断是否异常
3. 如有异常 → 调用 query_cmms.py 获取维护历史
4. 如需换件 → 调用 query_erp.py 查询库存
5. 综合所有信息，生成诊断报告

这个 skill 示例中，阈值表属于领域知识，故障模式是专家经验，而 CLI 脚本是执行工具，工作流程是编排逻辑。这些东西加在一起，才是一个完整的 Skill。它不是写段提示词让 AI 猜，而是把一个老师傅脑子里的决策链条结构化地写下来，然后让 Agent 照着执行。

这里多说一句我自己的判断。Anthropic 提过一个观点，未来不会有越来越多的 Agent，而是会有越来越多的 Skills。我非常认同，从企业大模型应用落地的视角看，真正有价值的事情不是造更多的 Agent，而是把企业里那些已经跑了很多年的成熟人工工作流程（比如报价、巡检、质检流程等）做一次业务逻辑的抽象和封装，变成一个个 Skill。交互入口可以是飞书、钉钉、企微这类办公协同软件，底层则是越来越多的 Skills 在支撑。

继续用厨房的比喻来说，Skill 就是食谱，不光告诉你放多少盐、炒多久，还附上了食材清单和厨具使用说明。

1.4、它们之间的关系

总结来说，这三者不是互相替代的关系，而是分层配合：

Skills 在最上层做路由调度，决定该用什么工具、按什么流程 CLI 和 MCP 在底层做具体执行——CLI 处理本地、无状态、快速的任务；MCP 处理远程、有状态、需要持久连接的任务

再补充一个很多人忽略的角色：Agent 编排平台。比如我最近在给过去已经部署过的几个企业大模型项目追加OpenClaw，部署在 Mac mini 和 VPS 上 7x24 运行，定时调度 Gemini CLI / Claude Code 执行开发任务。在这个架构里，Skills 定义任务该怎么做，CLI 工具负责执行，MCP 负责连接飞书等IM通知、日历提醒等需要一直在线的服务。OpenClaw 不是 CLI、MCP 或 Skill 的竞品，而是把三者编排在一起的调度中枢。

继续用厨房的比喻来说，OpenClaw 好比厨师长，决定今天做什么菜、安排几点开始、分配谁负责哪道工序。

2、数据说话：MCP 到底有多贵

前面和各位统一了概念认识，这一章用数据说话。关于 MCP 的 Token 成本问题，网上已经有不少人测过了，这里汇总几组有据可查的数据（附来源）：

来源	数据	说什么
Apideck 博客 (https://www.apideck.com/blog/cli-ai-agents )	3 个 MCP Server 消耗了 200K token 中的 143K（72%）	上下文污染的最直观案例
GitHub MCP	初始化消耗约 50,000 token	还没开始干活就花了这么多
CircleCI 基准测试 ( https://circleci.com/blog/mcp-vs-cli/ )	CLI 方案 token 效率高 33%，任务得分 77 vs 60	CLI 和 MCP 的正面对决
Cloudflare Code Mode ( https://blog.cloudflare.com/mcp-code-mode )	实现了 99.9% 的 token 减少	说明 MCP 的优化空间是巨大的

数据的指向很明确，MCP 在 Token 消耗上确实是硬伤。但话说回来，从企业大模型应用落地视角来看，Token 成本其实只是选型的一个维度。如果只看这个表，可能会觉得 CLI 和 Skills 完胜，MCP 没用，但把对比维度拉开来看，三种方式实则各有适用情形：

维度	CLI	MCP	Skills
Token 成本	🟢 极低	🔴 高	🟢 极低
实时数据	🟡 需自建	🟢 原生支持	🔴 不适合
标准化程度	🔴 无标准	🟢 统一协议	🟡 SKILL.md
企业安全	🔴 需自建	🟢 内建认证	🟡 依赖底层
多 Agent 协作	🔴 困难	🟢 共享上下文	🟡 间接支持
离线能力	🟢 完全离线	🔴 需网络	🟢 完全离线
学习成本	🟢 低	🔴 高	🟡 中等
适合环节	内循环	外循环	通用抽象层

虽然 MCP 在 Token 成本上吃了大亏，但在实时数据、标准化、企业安全、多 Agent 协作这几个维度上，它是目前相对成熟的选择。所以问题不是 MCP 行不行，而是你的场景到底需不需要这些能力。

3、不是非黑即白：场景决策矩阵

数据看完了，回到最核心的问题，那面对不同的业务场景到底该用哪个？下面这张表是我从自己做过的几个项目里总结出来的，每个都是真实实施或咨询过的场景，供各位参考：

场景	推荐方案	为什么这么选
非标设备报价（7000+ 历史报价文件）	Skill 为主	知识密集、流程固定，核心是从历史报价里匹配 SKU 和填充 Excel 模板，不需要实时外部连接
工控软件售后知识库（1600+ Word 文档）	Skill + CLI	RAG 检索用 CLI 脚本跑（向量化、召回、Rerank），分析和回答流程用 Skill 定义，纯离线场景
设备预测性运维 ⭐	MCP + Skill + CLI 混合	需要实时 IoT 数据流（MCP）+ 领域诊断知识（Skill）+ 具体执行脚本（CLI），本文重点展开
安全隐患识别（多模态）	Skill + CLI	VLM 看图识别用 CLI 调 Ollama，知识库检索法规也是 CLI，Skill 定义从识别到出报告的工作流，不需要持久连接

几个规律很明显：

大部分企业大模型应用落地场景其实用不到 MCP。 售前报价、售后客服知识库、工业隐患识别这三个项目，数据不需要实时推送，系统之间也不需要持久连接，用 Skill + CLI 就够了。只有设备运维这种需要持续监听 IoT 数据、跨多个系统（IoT + CMMS + MES + ERP）联动的场景，MCP 才有不可替代的价值。在实际选型时，我通常会通过以下三个问题来确定：

1、 需要"一直在线"监听/接收数据流： MCP 不可替代 

2、 需要跨多个系统联动（同时连 ERP + MES + 数据库）：MCP 优先 

3、 任务是"知识密集"还是"执行密集"：知识密集 → Skill 为主；执行密集 → CLI 为主

---

4、实战验证：同一个场景，三种纯代码实现

光说不练假把式，下面和大家一起上手用代码跑一遍就能看到所谓的区别和联系到底在哪。

这一章用一个泵设备预测性运维的场景，分别用 CLI、MCP、Skill+CLI 三种方式实现。三种方式调同一套 Mock API、用同一份模拟数据，唯一的变量就是怎么组织代码和调用。

4.1、场景说明

CNC 加工中心的冷却液泵，实际运维中需要监测振动、轴承温度、出口压力、流量这几个关键参数。数据来自四个系统：IoT 实时工况、CMMS 维护记录、MES 运行日志、ERP 备件库存。

我用 FastAPI 写了一套 Mock API 把这四个数据源都模拟出来，模拟两台泵（PUMP-CNC-001 正常、PUMP-CNC-002 异常恶化）4 天的监控数据。这样三种方式都是在同一个数据基础上做诊断，对比才有意义。

4.2、纯 Python 脚本——固定编排

技术栈很简单：requests + openai SDK，零框架依赖。一个 check_pump.py 搞定全流程：

1、调 Mock API 获取 IoT 最新数据 
2、本地规则判断：振动 > 5mm/s 或轴承温度 > 70°C → 标记异常 
3、发现异常后：自动调 CMMS + MES API 获取维护历史和运行上下文
4、拼 prompt → 调 LLM 生成诊断报告 
5、LLM 推荐换件 → 调 ERP API 查库存 6、终端直接输出 Markdown 格式的诊断报告。

实际两条命令就能测：

# 不调 LLM，验证数据管道和规则检测
python cli/check_pump.py --pump PUMP-CNC-002 --no-llm

# 调 LLM，走完整诊断链路
python cli/check_pump.py --pump PUMP-CNC-002

实测下来，--no-llm 模式下正确识别了 PUMP-CNC-002 的 6 项异常（振动 13.2mm/s、轴承温度 92.5°C、出口压力 -20%、流量 -26%、功率因数 0.65、噪音 89.2dB），数据管道没问题。

加上 LLM 后，通过 OpenRouter 调用Claude Sonnet 4.5 生成了一份完整的诊断报告，包含故障定位、根因分析、维修方案和备件清单。

这种方式的好处很明显：流程完全可控，Token 消耗最低，5 分钟跑通。坏处也很明显：流程是写死的，想换个诊断逻辑就得改代码。每种新场景都要写新脚本，灵活性约等于零。

4.3、MCP Server + Claude Desktop之动态决策

换一种思路，不写死流程，而是把 4 个数据源封装成 5 个 MCP 工具（IoT 状态、IoT 历史、CMMS 维护记录、MES 运行日志、ERP 备件），每个工具带完整的 JSON Schema 描述。

然后用 Claude Desktop 连接这个 MCP Server。

用户直接用自然语言提问，LLM 自己决定调哪些工具、什么顺序。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("pump-maintenance",
    instructions="泵类设备预测性运维工具集")

@mcp.tool()
def get_iot_status(pump_id: str) -> dict:
    """获取指定泵的最新 IoT 传感器数据"""
    ...

这种方式的灵活性很高。问"PUMP-CNC-002 状态怎么样"，它可能只调一个 IoT 工具；问"全面诊断一下"，它会自动走完 IoT → CMMS → MES → ERP 的完整链路。路径完全由 LLM 自主决定。

但代价也很直观，5 个工具的 JSON Schema 加起来就占上千 token，还没开始干活就先花了这么多。这也印证了 Garry Tan 说的 Context Window 占用问题。而且 LLM 的调用路径不可预测，同一个问题问两次，可能走不同的路径，对于需要确定性输出的工业场景来说，这是个隐患。

Claude原生客户端的可视化加成

Claude Desktop近期更新了一个可视化的功能，在这个case演示中，在分析完 IoT 数据后，Claude自动生成了 SVG 可视化图，包括了关键参数的趋势折线图、异常偏差数据卡片，格式也相当专业。

当然，这不是 MCP 协议本身的功能，而是大模型厂商在原生客户端里加入的代码执行能力，遇到数据分析类的内容会自动做可视化。CLI 版只能输出纯文本，下面要介绍的飞书机器人也只能展示文字消息。在交互体验这个维度上，原生 AI 客户端确实有不可替代的优势，这个我之前没预想到，但确实是选型时容易忽视的一个因素。

4.4、OpenClaw Skill + CLI——编排调度

第三种思路是不写死流程（那是 CLI 的做法），也不让 LLM 完全自由发挥（那是 MCP 的做法），而是用 SKILL.md 把领域知识和诊断工作流都定义好，再配一组独立的 CLI 脚本各自完成单一任务。OpenClaw 作为编排平台，部署在 Mac mini 上 7x24 运行，飞书机器人作为交互入口。

SKILL.md 里封装了什么：

阈值表（振动 > 5mm/s 告警、轴承温度 > 70°C 危险等）
故障模式库（轴承磨损、密封泄漏、叶轮堵塞等常见故障特征）
备件映射（哪个故障对应哪个零件号）
诊断工作流（先查状态 → 发现异常 → 查历史 → 综合分析 → 查备件）

在飞书上问同样的问题“PUMP-CNC-002 好像有点问题，帮我全面诊断一下”

OpenClaw 正确加载了 Skill 并调用了多个 CLI 脚本。输出是一份结构化的文字报告，正确识别了全部 6 项异常（和 CLI/MCP 版结果一致），自动查了 ERP 备件库存（BRG01 库存 3 件 ¥250、SEAL01 库存 8 件 ¥85.5），还给出了分步维修方案和预计工时。

虽然没有 Claude Desktop 那种 SVG 趋势图，但飞书消息天然适合移动端查看。设备巡检人员在车间里掏出手机就能看结果，不需要开电脑。在实际工厂场景中，这反而可能是最实用的交互方式。

注：Skill 必须放在 workspace 级别目录（~/.openclaw/workspace/skills/），而不是 Agent 子目录下。

4.5、三种方式正面对比

对比维度	CLI 脚本（固定编排）	MCP Server（动态决策）	OpenClaw Skill+CLI（编排调度）
技术栈	纯 Python，零框架	MCP SDK + Claude Desktop	SKILL.md + Python + OpenClaw
流程控制	人工写死，确定性强	LLM 自主决策，灵活	Skill 定义策略，CLI 执行
Token 成本	🟢 最低	🔴 高（schema+多轮推理）	🟢 低（Skill 按需加载）
灵活性	🔴 新场景写新脚本	🟢 自然语言即可	🟡 需写新 Skill
可预测性	🟢 强	🔴 弱	🟢 强
自动化	🔴 需 cron/手动	🔴 需手动对话	🟢 内建定时 + 飞书触发
输出体验	🔴 纯文本终端	🟢 自动可视化（SVG 图表）	🟡 飞书消息卡片
交互方式	终端命令行	Claude Desktop 对话	飞书机器人
适合场景	快速验证、定时脚本	灵活诊断问答	7x24 自动监控+告警

三种方式跑同一份数据，诊断结果一致（6 项异常、同一批备件推荐）。差异只在于代码组织方式、Token 成本和交互体验。这也正是这篇文章想说明的，不是哪种方式更好，而是不同场景该用不同方式。

4.6、从 Demo 到真实场景

上面这个对比不只是 Demo，我实际帮一些制造业客户做 AI 能力集成时发现，部分客户其实已经有了 IoT/CMMS/MES/ERP 的数据闭环，只是运维还停留在"参数越限后告警 + 维修人员凭经验"的阶段。AI Agent 能补的是中间这一段：

能力	传统模式	+ AI 后
异常发现	越限后告警（规则驱动）	趋势识别，超标前预警
故障诊断	维修人员凭经验	自动关联工况+历史+知识库
维修决策	因人而异	标准化方案+备件库存查询
知识沉淀	散落在工单文本中	可检索知识库，支持案例匹配

而且不同环节该用不同方式，规则告警继续用 CLI 固定流程、智能诊断做增量用 MCP/Agent 动态决策、定时巡检做自动化用 Skill+CLI 编排调度。混合架构不是过渡方案，而就是这个场景的正解。

5、写在最后

每一轮技术浪潮似乎都会经历类似的周期，一个新协议或新框架出来，社区先是一窝蜂地追捧，什么场景都往上堆；然后碰壁了，又一窝蜂地唱衰，觉得这东西根本不行。MCP 正在经历的就是这个过程。但如果你真的在企业里落地过大模型应用就会知道，技术选型从来不是追热点，而是解决真实问题。需要实时数据流和跨系统联动的场景，MCP 依然是目前最合适的选择；不需要的场景硬往上堆，那确实是在给自己找麻烦。

从个人阶段性实践经验来看，给企业做 AI 能力落地有一个比较稳的节奏：先用 CLI 验证数据管道是否跑得通，再用 MCP 验证智能诊断的增量价值，最后用 Skill+编排平台实现自动化。不要一步到位，分阶段走，每一步都有明确的验证目标。很多项目失败不是因为选错了技术，而是一上来就搞一个大而全的方案，结果数据没跑通、模型没调好，架构先搭起来了。

往远了看，我比较认同的一个趋势是：未来的 AI 应用架构会越来越“Skills-first”。Agent 平台负责编排调度，Skills 负责封装业务知识和工作流，CLI 负责执行，MCP 收缩到它真正擅长的实时连接场景。不存在银弹，只有适合自己场景的组合。

---

---

---

这套代码不只是一个演示 Demo，里面的数据格式参考了真实设备预测性维护的场景结构，只是做了必要的脱敏处理。如果你正在做类似的工业 AI 场景，可以直接拿来做技术选型测试和方案验证。

文章里演示的 CLI 版 Python 脚本可以关注公众号后回复关键词“CLI”获取，拿来跑一遍就能快速验证数据管道和规则检测逻辑。

如果要获取完整的 OpenClaw Skill 包和 MCP Server 代码，可以通过加入知识星球或视频获取（知识星球成员可免费兑换视频和一本书）。