MCP不香了？为什么AI开发者又爱上CLI

最近技术圈出现一个有意思的现象：不少做AI智能体的开发者，在追捧了一年多MCP协议之后，开始重新重视命令行（CLI）这种"老古董"方案。这并非技术倒退，而是在真实开发落地过程中，大家重新算了一笔关于成本与效率的账。

MCP和CLI到底是什么

要理解这场变化，先得弄清两个概念。

MCP全称模型上下文协议（Model Context Protocol），可以把它理解为给AI准备的一套标准化工具接口。过去AI想调用数据库、文件系统或各种外部服务，都需要单独开发适配层，工作量大且难以复用。MCP希望通过统一协议，让AI能够更方便地发现和调用不同工具，本质上是一次"接口标准化"的尝试。

CLI则是命令行界面，程序员用了几十年的黑框工具。通过输入文本命令，让计算机直接执行任务。它没有华丽的协议包装，却因为简单直接而长盛不衰。当这两种方案摆在AI智能体开发者面前时，选择的天平开始出现微妙的倾斜。

MCP由Anthropic于2024年底提出并开源，随后迅速获得OpenAI、Google等主流AI厂商的跟进支持。其核心设计思想借鉴了软件工程中的"适配器模式"——通过定义统一的请求/响应格式，让AI模型与外部工具之间无需定制化对接。一个符合MCP规范的工具服务器，理论上可以被任意支持MCP的AI客户端直接调用，这正是其最大的吸引力所在。从架构上看，MCP分为Host（AI应用）、Client（协议客户端）和Server（工具服务端）三层，Server负责向AI暴露"工具列表"，其中每个工具都附带名称、输入参数schema和功能描述，这些元信息在每次会话中都需要传递给大模型，也因此成为Token消耗的主要来源之一。

Token成本：MCP绕不开的账单

开发者重新关注CLI的第一个核心原因是成本。

大模型调用服务时，Token数量直接决定使用成本。而MCP的工作方式需要向AI提供工具的名称、参数、功能描述等一整套元信息。当一个智能体需要连接大量工具时，这些说明文本本身就会持续占用宝贵的上下文空间。

有个恰当的比喻：这就像去餐厅吃饭，每次点菜前服务员都要把整本菜单从头到尾完整介绍一遍。工具越多，这份"菜单"越长，每一次对话都要为它付费。

CLI的逻辑完全不同。它只需要告诉AI"你可以执行命令"，具体怎么执行，AI依靠自己训练时积累的经验直接生成对应操作，省去了大量重复的工具描述信息。在工具数量庞大的场景下，这种差异会直接反映在账单上。

Token是大模型处理和生成文本的基本计量单位，通常一个汉字或英文单词对应1至3个Token不等。主流商业模型如GPT-4o、Claude 3.5的API按输入和输出Token分别计费，价格从每百万Token数美元到数十美元不等。在实际工程中，上下文窗口的Token用量由两部分构成：真正的业务内容（用户指令、历史对话、任务数据）和系统级开销（工具描述、格式规范、安全提示等）。当一个智能体集成了数十个MCP工具时，仅工具描述这一项就可能占据数千甚至上万Token，且每轮对话都要重复计入，累计成本相当可观。这也是为什么"减少工具描述冗余"成为AI应用优化中越来越受重视的工程课题。

CLI更贴合大模型的"肌肉记忆"

第二个原因，是CLI更契合当前大模型的能力结构。

现在的大模型在训练过程中吞下了海量代码、技术文档和终端操作记录，对git、Linux、Docker等经典命令天然熟悉。对AI来说，生成一条shell命令，几乎和写一句话一样自然。这意味着调用CLI时，模型不需要额外学习，直接调用已有知识即可。

更关键的是CLI天然支持命令组合。一个命令的输出可以直接作为另一个命令的输入，通过管道串联，AI能像一名真正的程序员那样，分多个步骤完成复杂任务。相比之下，MCP虽然更标准化，但在简单任务中反而可能引入额外的调用开销，显得"杀鸡用牛刀"。

管道（pipe）是Unix/Linux系统中一种进程间通信机制，用符号|表示，可将前一条命令的标准输出直接作为后一条命令的标准输入，无需借助中间文件。例如cat log.txt | grep ERROR | wc -l可在一行内完成"读取文件→过滤关键词→统计行数"三步操作。这种组合方式让CLI天然具备流水线处理能力，与AI智能体分解子任务、逐步执行的工作模式高度契合。大模型在大量开源代码和技术博客的训练数据中反复接触了这类命令组合，因此能够较为可靠地生成符合语义意图的shell脚本，而不仅仅是单条命令。这种"训练数据优势"在短期内仍是CLI方案的重要竞争力。

MCP并没有被淘汰

必须强调，CLI的轻量高效，并不意味着MCP会退出舞台。两者的适用场景其实相当清晰。

CLI更适合个人开发、本地自动化以及开发者工具类场景，追求的是灵活和低成本。而MCP在企业应用、多人共享环境，以及需要严格权限控制的场景中依然不可替代。

安全是核心分水岭。直接开放终端能力给AI，意味着它理论上可以执行任何系统命令，这在生产环境中是巨大的风险。而MCP通过结构化接口，可以精细地限制AI能够执行哪些操作、访问哪些资源，把权限牢牢握在可控范围内。对企业而言，可控性往往比效率更重要。

本质是工程化的重新平衡

这场从MCP到CLI的回摆，本质上不是谁取代谁，而是AI工程化过程中一次工具选择的重新平衡。

过去一年，行业普遍追求统一协议的美好愿景。但当技术真正落地后，成本、效率、安全这三个现实因素，才是决定技术选型的关键。理想很丰满，账单很骨感。

可以预见，未来成熟的AI智能体很可能不会二选一，而是在不同场景下组合使用两种方案：用CLI换取灵活性与低成本，用MCP保障可靠性与安全边界。让AI既拥有程序员般的动手能力，又具备可控的权限护栏，这才是工程实践的最优解。

对开发者来说，与其纠结"MCP还是CLI"，不如根据具体任务的成本、复杂度和安全要求，做出最务实的判断。工具没有高低之分，只有合不合适。