CLI 和 MCP，到底谁在瞎忙？

kismet787
71 阅读6分钟

CLI 和 MCP，到底谁在瞎忙？

导读：当 MCP 被捧成"Agent 的万能接口"时，Perplexity CTO 和 YC CEO 却悄悄转向了 CLI。这场争论看起来像是新旧技术打架，其实大多数人问错了问题。

先别急着站队

2025年的AI工具圈，MCP和CLI吵得挺热闹。

Anthropic力推的MCP（Model Context Protocol），目标是成为AI时代的"USB接口"——写一次，Claude、GPT、Cursor都能用。另一边是CLI，诞生于1960年代的Unix老古董，看起来过时，但最近被Perplexity CTO和YC CEO拿出来当主力工具用。

于是网上开始传："MCP要凉了""CLI完成复古逆袭"。

但稍微冷静下来就会发现，这场战争从一开始就没对准靶子。

MCP是协议，CLI是交互形态。它们根本不在一个维度上，就像"国际邮政系统"和"同城闪送"不会互相取代，只是服务不同的场景。真正该讨论的，不是"谁取代谁"，而是协议抽象和本地执行，各自该在什么位置干活。

MCP 是协议，CLI 是手艺

要搞清楚这个问题，得先破除一个误解。

MCP的本质是协议。它定义的是AI怎么发现、描述和调用外部能力——工具Schema长什么样、资源URI怎么传、Client和Server之间怎么对话。它不关心工具内部怎么实现，只关心"接口长什么样"。

打个比方，MCP像是餐厅的前厅服务规范：怎么点餐、怎么传菜、怎么结账。它管的是服务流程，不是菜怎么做。

CLI的本质是形态。它定义的是用户（或程序）怎么用文本命令跟软件打交道——管道、重定向、退出码、标准输入输出。它不关心命令背后有没有协议，只关心"怎么执行最高效"。

继续用餐厅类比，CLI像是后厨的烹饪动作：切菜、炒菜、装盘。它关注的是手艺，不是服务流程。

所以，完全可以存在一个MCP Server，内部逻辑就是调用ffmpeg或grep；也可以存在一个CLI工具mcp-call，通过MCP协议跟远程服务通信。

Claude Code的"CLI优先"策略，本质上是用CLI的形态绕过了MCP协议的上下文开销，而不是在否定MCP这套标准本身。一家餐厅可以前厅很规范、后厨很高效——两者各司其职，不是互相替代。

真正该算账的，是"把想法变成动作"的成本

与其争论"MCP比CLI多消耗多少Token"，不如看看把用户的自然语言意图翻译成机器可执行动作，整个过程到底花了什么。

我把它拆成三块：Token租金、延迟摩擦、维护负债。

Token租金

MCP的Schema确实占上下文。一个包含20个工具的MCP Server，JSON Schema可能占几千Token。这笔钱在两种场景下会成为负担：

  • 工具太多：Agent同时挂载40+个工具时，Schema的累积效应会让上下文窗口不堪重负。
  • 高频短交互：每次对话都重新加载Schema，像每次进餐厅都要重新听一遍菜单介绍。

但Token成本不是死账，至少有三种优化手段：

手段原理效果
Prompt Caching现代LLM API对静态系统提示提供缓存折扣Schema作为不变内容，后续调用成本可降至1/10
Lazy Loading根据用户意图动态加载相关Server提到"数据库"时才加载SQL MCP Server
Schema摘要用LLM生成工具集的语义摘要用"这个Server提供文件操作能力"替代完整参数列表

CLI的Token优势在于接口描述极简——一个bash工具只需十几行说明，大模型对常见CLI的用法在预训练阶段就内化了。但对于冷门CLI，你仍需在提示中注入文档，这部分成本和MCP的Schema没有本质区别。

所以Token成本是真实痛点，但它是可优化的工程问题，不是架构性缺陷。

延迟摩擦

这是CLI真正的杀手锏。

举个例子：筛选一批横版照片、加水印、上传服务器。

MCP路径（假设每步一个工具）：

LLM思考 → 调用list_files → 等待返回 → 
LLM思考 → 调用get_image_info × 10张 → 等待返回 → 
LLM思考 → 调用add_watermark × N张 → 等待返回 → 
LLM思考 → 调用upload_files → 等待返回 → 
LLM思考 → 生成最终回复

在这个路径里，LLM是串行调度的瓶颈。每一步都要重新进入推理循环，即使单次推理只要500ms，累积起来也是秒级的延迟。

CLI路径：

exiftool -if '$ImageWidth > $ImageHeight' -p '$FileName' . | \
xargs -I {} magick {} -draw 'image over 0,0 0,0 watermark.png' output/{}.png && \
scp output/*.png user@server:/var/www/photos/

LLM只做一次"意图翻译"，生成一条组合命令。后续由Unix管道在本地自治执行：exiftool筛选，ImageMagick加水印，scp上传。三个专业工具通过管道和逻辑运算符无缝衔接，LLM不需要介入中间状态。

这就像：MCP路径是"老板亲自指挥每一个员工干活"，CLI路径是"老板写了一张流程图，交给自动化流水线去执行"。后者在批量任务里效率明显更高。

维护负债

这是最容易被短期性能对比掩盖的维度。

维度MCPCLI
跨平台复用一次开发，Claude/Cursor/Windsurf通用脚本碎片化，每个Agent需单独适配
接口稳定性Schema版本化，向后兼容可控命令参数随版本变化，解析脆弱
错误处理结构化错误码 + 类型安全依赖文本解析退出码，边界情况多
团队协作新人通过Schema即可理解能力边界需要阅读Shell脚本，知识传递成本高
安全审计调用日志天然结构化需额外封装script或auditd

我自己经历过类似的迁移。之前在一个项目里用CLI脚本搭数据流水线，半年后回来看自己的正则表达式，居然已经看不懂了。后来把核心工具用MCP封装，至少输入输出边界是显式定义的，接手的同事不需要从头到尾读一遍Shell脚本才能上手。

CLI在单次调用的Token和延迟上占优，但MCP在工程规模化上摊薄了长期成本。对于个人脚本，CLI更轻量；对于团队协作，MCP更可持续。

什么时候该用什么？

基于上面的成本拆解，可以画一张粗略的地图。

批处理、文件操作、流水线 → CLI

特征：输入输出是文件流、操作幂等、流程线性、错误处理简单。

典型例子：

  • 视频转码：ffmpeg -i input.mp4 -c:v libx264 output.mp4
  • 日志分析：cat app.log | grep ERROR | awk '{print $1}' | sort | uniq -c
  • Git仓库批量操作：for repo in */; do cd $repo && git pull && cd ..; done

Unix管道的设计哲学——"每个工具只做一件事，通过标准输入输出组合"——和AI的"一次性生成组合命令"完美契合。LLM只需做一次意图翻译，后续由专业工具自治完成。

结构化数据、多服务编排 → MCP

特征：涉及API认证、结构化数据查询、条件分支、跨服务状态传递。

比如这个任务：

"查CRM中客户张三的近3笔订单，若总额超10万，调用邮件服务发送促销草稿，并返回给我确认。"

这个任务需要查询数据库、做条件判断、调用邮件API（需OAuth）、生成草稿返回给用户。如果用CLI，你要写一堆curl拼接JSON、手动处理Token刷新、解析嵌套返回。而MCP把CRM和邮件服务封装为两个类型安全工具，AI可以优雅地进行多步推理，每个工具的权限、输入边界、错误语义都是显式定义的。

高频自动化 → CLI

CI/CD流水线、定时监控、IDE内实时代码检查。这些场景触发频率高、对延迟极度敏感、逻辑相对固定。在每秒触发数十次的场景下，MCP的网络往返和LLM推理成本会被放大到不可接受。

算一笔账：假设一个CI流水线每天触发1000次，每次用MCP需要2000 Token输入 + 500 Token输出，按Claude 3.5 Sonnet价格，每天成本约13.5美元，每年近5000美元。而用CLI脚本，成本为零。

跨团队协作、安全审计 → MCP

企业级AI助手接入内部ERP、财务系统、生产数据库，或者金融医疗等合规行业，所有操作必须可审计。

MCP的Schema本身就是一份活的接口文档，权限可以在Server入口统一控制，每次调用都是结构化的JSON请求-响应，可以直接入库。CLI要做到同等级别，需要额外封装，解析文本日志的可靠性也远不如结构化数据。

我自己的看法：对外接口，对内引擎

既然两边各有疆域，最务实的做法不是二选一，而是分层融合。

用户意图（自然语言）
        ↓
接口层：MCP协议
  • 工具发现、权限控制、审计日志
  • 跨平台复用（Claude/Cursor/GPT通用）
        ↓
适配层：轻量MCP Server
  • 接收结构化请求（JSON Schema）
  • 参数校验 & 安全转义
  • 调用底层CLI引擎
        ↓
执行层：CLI管道
  • ffmpeg / ImageMagick / grep / scp
  • Unix管道组合（|、&&、xargs）
  • 本地文件系统 & 系统调用

这个架构的精髓在于：MCP负责对外讲好故事（标准化接口、安全边界、生态兼容），CLI负责对内干好活（高效执行、管道组合、零额外开销）。

举个例子。假设要做一个"智能图像处理Agent"，功能是筛选横版照片、加水印、上传服务器。

传统MCP做法（低效）：暴露4个工具list_files、get_image_info、add_watermark、upload_files，AI需要4轮推理，每次都要等返回。

混合做法（高效）：对外只暴露一个MCP工具batch_process_images，参数包括source_dir、filter_criteria、watermark_path、destination。对内，MCP Server接收到请求后，将参数安全转义，拼接成一条CLI管道：

exiftool -if '$ImageWidth > $ImageHeight' -p '$Directory/$FileName' {source_dir} | \
xargs -I {} magick {} -draw 'image over 0,0 0,0 {watermark_path}' {destination}/{} && \
scp {destination}/* user@server:/var/www/photos/

执行完成后，将结果结构化返回给AI。

收益很明显：AI客户端只感知到标准的MCP接口（跨平台复用、安全可控），实际执行享受CLI的极致效率（一次推理、本地自治）。底层CLI逻辑可以独立测试和替换，MCP层只负责"翻译"和"管控"。

实际上这种混合架构已经出现在主流工具里：

  • Claude Code：对外是CLI形态，但内部调用某些外部服务时，也在探索MCP集成。它的"CLI优先"是形态选择，不是协议排斥。
  • Cursor：主打MCP生态，但处理本地文件操作时，底层也是调用系统CLI（如git、find）。
  • OpenClaw：虽然以CLI为主，但在需要与外部服务（如GitHub API）交互时，也会封装轻量的MCP-like接口。

以后会怎样？

这场争论不会以"一方消灭另一方"结束，更像是两条技术线各自往中间走。

MCP这边在做的：传输层从SSE向stdio和本地Unix Socket扩展，减少网络序列化开销；Schema压缩和动态加载，Agent不需要在上下文中加载完整Schema；支持Server端返回部分结果，让AI可以更早介入长流程的中间决策。

CLI这边在做的：越来越多工具支持--json或--output-format=jsonlines，弥补AI解析文本输出的脆弱性。gh（GitHub CLI）、flyctl、vercel都内置了机器可读模式。新一代工具甚至开始内置"命令建议"功能。

当MCP的传输层足够轻量、CLI的输出足够结构化时，两者的边界会模糊化——Agent可能直接通过本地MCP over stdio调用一个CLI包装器，享受协议的标准化和执行的零开销。

但这会不会发生、什么时候发生，我还说不准。至少现在，我同时用着两边，而且没觉得谁要杀死谁。

avatar
文章
阅读
粉丝