MCPModel 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 三种原生方式实现后的真实对比。以下enjoy1先搞清楚CLI、MCP、Skills 到底是什么在正式展开之前老规矩我先把几个核心概念快速和各位做个对齐。这三个词在不同文章里的定义经常混着用为了防止理解偏差先快速统一一下口径。另外为了简化对比这三个概念之间的区别和联系下面会以厨房场景作为对比。1.1CLI——直接伸手拿食材CLI 就是命令行工具这个开发背景的盆友应该都比较熟悉。在 AI Agent 的语境下含义稍微扩展了一点Agent 通过 bash/shell 直接调用命令来完成任务。比如 git push、curl、python analyze.py也包括 claude-code、gemini-cli 这类 AI 编码工具。核心特点就四个字简单直接。一条命令一个响应没有协议开销Token 消耗极低通常不到 50 tokens。为了好理解用厨房的比喻来说CLI 就是你直接伸手去抓食材和工具不需要规范化的摆放拿起来就用。1.2MCP——标准化的厨房而 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.3Skills——食谱最后是当前最火的 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 中的 143K72%上下文污染的最直观案例GitHub MCP初始化消耗约 50,000 token还没开始干活就花了这么多CircleCI 基准测试 ( https://circleci.com/blog/mcp-vs-cli/ )CLI 方案 token 效率高 33%任务得分 77 vs 60CLI 和 MCP 的正面对决Cloudflare Code Mode ( https://blog.cloudflare.com/mcp-code-mode )实现了 99.9% 的 token 减少说明 MCP 的优化空间是巨大的数据的指向很明确MCP 在 Token 消耗上确实是硬伤。但话说回来从企业大模型应用落地视角来看Token 成本其实只是选型的一个维度。如果只看这个表可能会觉得 CLI 和 Skills 完胜MCP 没用但把对比维度拉开来看三种方式实则各有适用情形维度CLIMCPSkillsToken 成本 极低 高 极低实时数据 需自建 原生支持 不适合标准化程度 无标准 统一协议 SKILL.md企业安全 需自建 内建认证 依赖底层多 Agent 协作 困难 共享上下文 间接支持离线能力 完全离线 需网络 完全离线学习成本 低 高 中等适合环节内循环外循环通用抽象层虽然 MCP 在 Token 成本上吃了大亏但在实时数据、标准化、企业安全、多 Agent 协作这几个维度上它是目前相对成熟的选择。所以问题不是 MCP 行不行而是你的场景到底需不需要这些能力。3不是非黑即白场景决策矩阵数据看完了回到最核心的问题那面对不同的业务场景到底该用哪个下面这张表是我从自己做过的几个项目里总结出来的每个都是真实实施或咨询过的场景供各位参考场景推荐方案为什么这么选非标设备报价7000 历史报价文件Skill 为主知识密集、流程固定核心是从历史报价里匹配 SKU 和填充 Excel 模板不需要实时外部连接工控软件售后知识库1600 Word 文档Skill CLIRAG 检索用 CLI 脚本跑向量化、召回、Rerank分析和回答流程用 Skill 定义纯离线场景设备预测性运维 ⭐MCP Skill CLI 混合需要实时 IoT 数据流MCP 领域诊断知识Skill 具体执行脚本CLI本文重点展开安全隐患识别多模态Skill CLIVLM 看图识别用 CLI 调 Ollama知识库检索法规也是 CLISkill 定义从识别到出报告的工作流不需要持久连接几个规律很明显大部分企业大模型应用落地场景其实用不到 MCP。 售前报价、售后客服知识库、工业隐患识别这三个项目数据不需要实时推送系统之间也不需要持久连接用 Skill CLI 就够了。只有设备运维这种需要持续监听 IoT 数据、跨多个系统IoT CMMS MES ERP联动的场景MCP 才有不可替代的价值。在实际选型时我通常会通过以下三个问题来确定1、 需要一直在线监听/接收数据流 MCP 不可替代2、 需要跨多个系统联动同时连 ERP MES 数据库MCP 优先3、 任务是知识密集还是执行密集知识密集 → Skill 为主执行密集 → CLI 为主4实战验证同一个场景三种纯代码实现光说不练假把式下面和大家一起上手用代码跑一遍就能看到所谓的区别和联系到底在哪。这一章用一个泵设备预测性运维的场景分别用 CLI、MCP、SkillCLI 三种方式实现。三种方式调同一套 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.3MCP 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.4OpenClaw 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 SkillCLI编排调度技术栈纯 Python零框架MCP SDK Claude DesktopSKILL.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 动态决策、定时巡检做自动化用 SkillCLI 编排调度。混合架构不是过渡方案而就是这个场景的正解。5写在最后每一轮技术浪潮似乎都会经历类似的周期一个新协议或新框架出来社区先是一窝蜂地追捧什么场景都往上堆然后碰壁了又一窝蜂地唱衰觉得这东西根本不行。MCP 正在经历的就是这个过程。但如果你真的在企业里落地过大模型应用就会知道技术选型从来不是追热点而是解决真实问题。需要实时数据流和跨系统联动的场景MCP 依然是目前最合适的选择不需要的场景硬往上堆那确实是在给自己找麻烦。从个人阶段性实践经验来看给企业做 AI 能力落地有一个比较稳的节奏先用 CLI 验证数据管道是否跑得通再用 MCP 验证智能诊断的增量价值最后用 Skill编排平台实现自动化。不要一步到位分阶段走每一步都有明确的验证目标。很多项目失败不是因为选错了技术而是一上来就搞一个大而全的方案结果数据没跑通、模型没调好架构先搭起来了。往远了看我比较认同的一个趋势是未来的 AI 应用架构会越来越“Skills-first”。Agent 平台负责编排调度Skills 负责封装业务知识和工作流CLI 负责执行MCP 收缩到它真正擅长的实时连接场景。不存在银弹只有适合自己场景的组合。2026年AI行业最大的机会毫无疑问就在应用层字节跳动已有7个团队全速布局Agent大模型岗位暴增69%年薪破百万腾讯、京东、百度开放招聘技术岗80%与AI相关……如今超过60%的企业都在推进AI产品落地而真正能交付项目的大模型应用开发工程师****却极度稀缺落地AI应用绝对不是写几个prompt调几个API就能搞定的企业真正需要的是能搞定这三项核心能力的人✅RAG融入外部信息修正模型输出给模型装靠谱大脑✅Agent智能体让AI自主干活通过工具调用Tools环境交互多步推理完成复杂任务。比如做智能客服等等……✅微调针对特定任务优化让模型适配业务目前脉脉上有超过1000家企业发布大模型相关岗位人工智能岗平均月薪7.8w实习生日薪高达4000远超其他行业收入水平技术的稀缺性才是你「值钱」的关键具备AI能力的程序员比传统开发高出不止一截有的人早就转行AI方向拿到百万年薪AI浪潮正在重构程序员的核心竞争力现在入场仍是最佳时机我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】⭐️从大模型微调到AI Agent智能体搭建剖析AI技术的应用场景用实战经验落地AI技术。从GPT到最火的开源模型让你从容面对AI技术革新大模型微调掌握主流大模型如DeepSeek、Qwen等的微调技术针对特定场景优化模型性能。学习如何利用领域数据如制造、医药、金融等进行模型定制提升任务准确性和效率。RAG应用开发深入理解检索增强生成Retrieval-Augmented Generation, RAG技术构建高效的知识检索与生成系统。应用于垂类场景如法律文档分析、医疗诊断辅助、金融报告生成等实现精准信息提取与内容生成。AI Agent智能体搭建学习如何设计和开发AI Agent实现多任务协同、自主决策和复杂问题解决。构建垂类场景下的智能助手如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等。如果你也有以下诉求快速链接产品/业务团队参与前沿项目构建技术壁垒从竞争者中脱颖而出避开35岁裁员危险期顺利拿下高薪岗迭代技术水平延长未来20年的新职业发展……那这节课你一定要来听因为留给普通程序员的时间真的不多了立即扫码即可免费预约「AI技术原理 实战应用 职业发展」「大模型应用开发实战公开课」还有靠谱的内推机会直聘权益完课后赠送大模型应用案例集、AI商业落地白皮书
大模型落地选型指南：CLI、MCP、Skills如何抉择？
MCPModel 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 三种原生方式实现后的真实对比。以下enjoy1先搞清楚CLI、MCP、Skills 到底是什么在正式展开之前老规矩我先把几个核心概念快速和各位做个对齐。这三个词在不同文章里的定义经常混着用为了防止理解偏差先快速统一一下口径。另外为了简化对比这三个概念之间的区别和联系下面会以厨房场景作为对比。1.1CLI——直接伸手拿食材CLI 就是命令行工具这个开发背景的盆友应该都比较熟悉。在 AI Agent 的语境下含义稍微扩展了一点Agent 通过 bash/shell 直接调用命令来完成任务。比如 git push、curl、python analyze.py也包括 claude-code、gemini-cli 这类 AI 编码工具。核心特点就四个字简单直接。一条命令一个响应没有协议开销Token 消耗极低通常不到 50 tokens。为了好理解用厨房的比喻来说CLI 就是你直接伸手去抓食材和工具不需要规范化的摆放拿起来就用。1.2MCP——标准化的厨房而 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.3Skills——食谱最后是当前最火的 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 中的 143K72%上下文污染的最直观案例GitHub MCP初始化消耗约 50,000 token还没开始干活就花了这么多CircleCI 基准测试 ( https://circleci.com/blog/mcp-vs-cli/ )CLI 方案 token 效率高 33%任务得分 77 vs 60CLI 和 MCP 的正面对决Cloudflare Code Mode ( https://blog.cloudflare.com/mcp-code-mode )实现了 99.9% 的 token 减少说明 MCP 的优化空间是巨大的数据的指向很明确MCP 在 Token 消耗上确实是硬伤。但话说回来从企业大模型应用落地视角来看Token 成本其实只是选型的一个维度。如果只看这个表可能会觉得 CLI 和 Skills 完胜MCP 没用但把对比维度拉开来看三种方式实则各有适用情形维度CLIMCPSkillsToken 成本 极低 高 极低实时数据 需自建 原生支持 不适合标准化程度 无标准 统一协议 SKILL.md企业安全 需自建 内建认证 依赖底层多 Agent 协作 困难 共享上下文 间接支持离线能力 完全离线 需网络 完全离线学习成本 低 高 中等适合环节内循环外循环通用抽象层虽然 MCP 在 Token 成本上吃了大亏但在实时数据、标准化、企业安全、多 Agent 协作这几个维度上它是目前相对成熟的选择。所以问题不是 MCP 行不行而是你的场景到底需不需要这些能力。3不是非黑即白场景决策矩阵数据看完了回到最核心的问题那面对不同的业务场景到底该用哪个下面这张表是我从自己做过的几个项目里总结出来的每个都是真实实施或咨询过的场景供各位参考场景推荐方案为什么这么选非标设备报价7000 历史报价文件Skill 为主知识密集、流程固定核心是从历史报价里匹配 SKU 和填充 Excel 模板不需要实时外部连接工控软件售后知识库1600 Word 文档Skill CLIRAG 检索用 CLI 脚本跑向量化、召回、Rerank分析和回答流程用 Skill 定义纯离线场景设备预测性运维 ⭐MCP Skill CLI 混合需要实时 IoT 数据流MCP 领域诊断知识Skill 具体执行脚本CLI本文重点展开安全隐患识别多模态Skill CLIVLM 看图识别用 CLI 调 Ollama知识库检索法规也是 CLISkill 定义从识别到出报告的工作流不需要持久连接几个规律很明显大部分企业大模型应用落地场景其实用不到 MCP。 售前报价、售后客服知识库、工业隐患识别这三个项目数据不需要实时推送系统之间也不需要持久连接用 Skill CLI 就够了。只有设备运维这种需要持续监听 IoT 数据、跨多个系统IoT CMMS MES ERP联动的场景MCP 才有不可替代的价值。在实际选型时我通常会通过以下三个问题来确定1、 需要一直在线监听/接收数据流 MCP 不可替代2、 需要跨多个系统联动同时连 ERP MES 数据库MCP 优先3、 任务是知识密集还是执行密集知识密集 → Skill 为主执行密集 → CLI 为主4实战验证同一个场景三种纯代码实现光说不练假把式下面和大家一起上手用代码跑一遍就能看到所谓的区别和联系到底在哪。这一章用一个泵设备预测性运维的场景分别用 CLI、MCP、SkillCLI 三种方式实现。三种方式调同一套 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.3MCP 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.4OpenClaw 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 SkillCLI编排调度技术栈纯 Python零框架MCP SDK Claude DesktopSKILL.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 动态决策、定时巡检做自动化用 SkillCLI 编排调度。混合架构不是过渡方案而就是这个场景的正解。5写在最后每一轮技术浪潮似乎都会经历类似的周期一个新协议或新框架出来社区先是一窝蜂地追捧什么场景都往上堆然后碰壁了又一窝蜂地唱衰觉得这东西根本不行。MCP 正在经历的就是这个过程。但如果你真的在企业里落地过大模型应用就会知道技术选型从来不是追热点而是解决真实问题。需要实时数据流和跨系统联动的场景MCP 依然是目前最合适的选择不需要的场景硬往上堆那确实是在给自己找麻烦。从个人阶段性实践经验来看给企业做 AI 能力落地有一个比较稳的节奏先用 CLI 验证数据管道是否跑得通再用 MCP 验证智能诊断的增量价值最后用 Skill编排平台实现自动化。不要一步到位分阶段走每一步都有明确的验证目标。很多项目失败不是因为选错了技术而是一上来就搞一个大而全的方案结果数据没跑通、模型没调好架构先搭起来了。往远了看我比较认同的一个趋势是未来的 AI 应用架构会越来越“Skills-first”。Agent 平台负责编排调度Skills 负责封装业务知识和工作流CLI 负责执行MCP 收缩到它真正擅长的实时连接场景。不存在银弹只有适合自己场景的组合。2026年AI行业最大的机会毫无疑问就在应用层字节跳动已有7个团队全速布局Agent大模型岗位暴增69%年薪破百万腾讯、京东、百度开放招聘技术岗80%与AI相关……如今超过60%的企业都在推进AI产品落地而真正能交付项目的大模型应用开发工程师****却极度稀缺落地AI应用绝对不是写几个prompt调几个API就能搞定的企业真正需要的是能搞定这三项核心能力的人✅RAG融入外部信息修正模型输出给模型装靠谱大脑✅Agent智能体让AI自主干活通过工具调用Tools环境交互多步推理完成复杂任务。比如做智能客服等等……✅微调针对特定任务优化让模型适配业务目前脉脉上有超过1000家企业发布大模型相关岗位人工智能岗平均月薪7.8w实习生日薪高达4000远超其他行业收入水平技术的稀缺性才是你「值钱」的关键具备AI能力的程序员比传统开发高出不止一截有的人早就转行AI方向拿到百万年薪AI浪潮正在重构程序员的核心竞争力现在入场仍是最佳时机我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】⭐️从大模型微调到AI Agent智能体搭建剖析AI技术的应用场景用实战经验落地AI技术。从GPT到最火的开源模型让你从容面对AI技术革新大模型微调掌握主流大模型如DeepSeek、Qwen等的微调技术针对特定场景优化模型性能。学习如何利用领域数据如制造、医药、金融等进行模型定制提升任务准确性和效率。RAG应用开发深入理解检索增强生成Retrieval-Augmented Generation, RAG技术构建高效的知识检索与生成系统。应用于垂类场景如法律文档分析、医疗诊断辅助、金融报告生成等实现精准信息提取与内容生成。AI Agent智能体搭建学习如何设计和开发AI Agent实现多任务协同、自主决策和复杂问题解决。构建垂类场景下的智能助手如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等。如果你也有以下诉求快速链接产品/业务团队参与前沿项目构建技术壁垒从竞争者中脱颖而出避开35岁裁员危险期顺利拿下高薪岗迭代技术水平延长未来20年的新职业发展……那这节课你一定要来听因为留给普通程序员的时间真的不多了立即扫码即可免费预约「AI技术原理 实战应用 职业发展」「大模型应用开发实战公开课」还有靠谱的内推机会直聘权益完课后赠送大模型应用案例集、AI商业落地白皮书
