CLI 和 MCP，到底谁在“瞎忙”？
在2025年的AI工具领域，MCP与CLI成为最受关注的一对组合——但客观来看，它们的争论焦点其实有些偏离核心。
一边是Anthropic力推的MCP协议，号称要成为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；同样可以存在一个名为mcp-call的CLI工具，通过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成为串行调度的瓶颈。每一步都需重新进入推理循环，即使单次推理仅需500毫秒，累积起来也会导致数秒的延迟。
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路径是“老板绘制了一张流程图，交由自动化流水线执行”。后者在批量任务中，效率显然高出一个数量级。
维护负债
这是最容易被短期性能对比所掩盖的维度。
| 维度 | MCP | CLI |
|---|---|---|
| 跨平台复用 | 一次开发，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认证、结构化数据查询、条件分支、跨服务状态传递。
例如这样一个任务：查询数据库、进行条件判断、调用邮件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包装器，同时享受协议的标准化和执行的零开销。
但这会发生、何时发生，目前尚未可知。至少现在，同时使用双方，并不觉得谁会杀死谁。
