过去一年，AI Agent 的工具调用方式迅速分化成两条路线：一条是标准化协议路线，以 MCP（Model Context Protocol）为代表；另一条是经典工具路线，以 CLI（Command Line Interface，命令行接口）为代表。前者试图为 AI 应用连接外部系统提供统一接口，后者则继承了几十年软件工程积累下来的命令行生态。

如果只看“连接外部能力”这个目标，MCP 很有吸引力；但如果把效率、成本、可组合性、生态成熟度和未来 Agent 的执行方式放在一起看，我的判断是：MCP 会成为重要的集成标准，但 CLI 更可能成为未来 Agent 执行任务的主战场。

什么是 CLI

CLI 是 Command Line Interface 的缩写，中文通常称为命令行接口。它允许用户通过文本命令与操作系统、程序或服务交互，而不是通过图形界面点选按钮。

Windows 和 Windows Server 内置了一组控制台命令，可用于通过脚本或脚本工具自动化任务；Linux系统的命令行 Shell 为用户和操作系统或应用程序之间提供直接通信，并提供自动化 操作的环境。换句话说，CLI 的核心价值不是“黑窗口”，而是自动化、可脚本化、可组合。

这也是为什么开发者长期依赖命令行。很多任务用图形界面需要反复点击，用 CLI 只需要一行命令。

例如：

ffmpeg -i input.mov output.mp4

这是一条典型的 CLI 命令，使用命令行工具FFmpeg将视频从mov转换为mp4。ffmpeg 是命令行领域处理音视频的“瑞士军刀”。它可以读取输入文件、网络流、采集设备等，并输出为不同格式。视频转码、换封装、压缩、抽取音频、加滤镜，很多操作都可以通过一行命令完成。

再比如搜索文件：

find . -name "*.txt"

一行命令就可以将当前目录下以“txt”结尾的文件列举出来。

再比如批量调整图片大小使用的magick命令：

magick input.jpg -resize 800x output.jpg

magick 命令可以进行格式转换、裁剪、旋转、压缩、调整尺寸、添加文字、移除元数据等图像处理任务。

这些工具看似朴素，但它们有一个共同特点：输入明确，输出明确，执行路径短，几乎没有额外抽象层。

什么是 MCP

MCP 是 Model Context Protocol 的缩写。官方文档将它定义为一个开源标准，用于把 AI 应用连接到外部系统。MCP 可以让 Claude、ChatGPT 等 AI 应用连接数据源、工具和工作流，例如本地文件、数据库、搜索引擎、计算器、Notion、Google Calendar、Figma、Sentry 等。

MCP 官方用了一个很形象的比喻：MCP 就像 AI 应用的 USB-C 接口。USB-C 为电子设备提供统一连接方式，MCP 则为 AI 应用连接外部系统提供统一协议。

从架构上看，MCP 采用 client-server 模型：

• MCP Host：AI 应用，例如 Claude Desktop、Claude Code、VS Code。
• MCP Client：Host 内部负责连接某个 MCP Server 的组件。
• MCP Server：向 AI 应用暴露上下文、工具或能力的程序。

MCP Server 可以暴露三类核心能力：

• Tools：可执行函数，例如查询数据库、调用 API、操作文件。
• Resources：上下文数据，例如文件内容、数据库记录、接口响应。
• Prompts：可复用提示模板，例如特定工作流提示词或 few-shot 示例。

MCP 的意义很清楚：它试图把“每个 AI 应用都单独对接每个外部系统”的混乱局面，变成“外部系统只要实现 MCP Server，就能被多个 AI 应用复用”的标准化生态。

这很重要，也确实有价值。

MCP 的优势：标准化、可控、安全边界更清晰

公平地说，MCP 不是噱头。它解决的是一个真实问题：AI 应用需要访问外部世界，而外部世界的接口五花八门。

如果没有 MCP，每个应用都要单独写 Notion 集成、GitHub 集成、Slack 集成、数据库集成、搜索集成。开发成本高，权限模型也容易混乱。MCP 提供了统一的发现、调用和返回结构，让工具可以被 AI 应用动态发现和使用。

MCP 的几个优势很明显。

第一，工具描述更结构化。MCP 工具有名称、描述、输入 schema。模型知道工具能做什么、应该传什么参数，客户端也可以验证输入格式。

第二，权限和安全边界更清晰。相比让模型直接写任意 shell 命令，MCP 工具可以把危险操作封装在更小的接口里。例如，与其让模型执行一串 curl 和脚本，不如暴露一个 create_ticket 或 query_orders 工具，并限制它的参数和权限。

第三，适合 SaaS 和企业系统集成。对于 Notion、Sentry、Linear、GitHub、数据库等服务，MCP 可以把认证、能力发现、工具调用统一起来。远程 MCP Server 还可以通过 HTTP、OAuth、Bearer token 等方式进行认证。

第四，适合跨客户端生态。MCP 已被 Claude、ChatGPT、VS Code、Cursor 等多个客户端或开发工具支持。这意味着一个 MCP Server 理论上可以被多个 AI 客户端复用。

所以，MCP 的价值不在于比所有工具都快，而在于它更像“集成层标准”。

MCP 的问题：协议层越标准，执行链路越长

但 MCP 的优势，也正是它的成本来源。

MCP 为了标准化，必须引入协议层、生命周期管理、能力协商、工具发现、schema 描述、远程通信、认证和结果包装。这些机制带来了更强的可控性，却也带来了额外开销。

首先是 token 成本。Claude 工具使用文档明确说明，工具调用请求的计费基于输入 token、输出 token，以及服务器端工具可能产生的额外使用费用。工具相关的额外 token 来自三个方面：

• tools 参数中的工具名称、描述和 schema；
• 请求和响应中的 tool_use 内容块；
• 请求中的 tool_result 内容块。

也就是说，工具不是免费的上下文。你暴露给模型的工具越多、schema 越长、工具结果越大，输入 token 就越多。

其次是缓存和上下文稳定性问题。请求渲染顺序是 tools → system → messages。工具定义位于最前面，因此工具定义的任何变化都会改变整个 prompt 前缀，导致 tools、system、messages 缓存全部失效。对复杂 MCP 工具生态来说，工具列表动态变化、schema 版本变化、权限变化，都可能让缓存命中率下降。

第三是执行链路更长。一次 MCP 调用通常包括工具发现、模型判断、工具调用、MCP Server 执行、结果返回、模型继续推理等步骤。对需要强审计和权限控制的企业系统，这是值得的；但对“把视频转成 mp4”“查找文件”“压缩图片”这类本地确定性任务，协议层未必划算。

第四是生态质量参差不齐。MCP 标准本身有价值，但每个 MCP Server 的实现质量、权限设计、错误处理、结果格式、性能优化都不同。标准化接口并不自动等于高质量工具。

这些问题导致不少团队需重新评估 MCP 的使用边界。对于需要权限治理、跨应用集成、远程 SaaS 访问的场景，MCP 仍然合理；对于高频、本地、确定性、可脚本化任务，CLI 往往更高效。

CLI 的优势：它不是一种接口，而是一整个成熟执行生态

CLI 的真正优势，不只是“命令短”，而是它背后有一个极其成熟的软件生态。

第一，CLI 工具已经存在，而且经过长期验证。ffmpeg、find、grep、tar、curl、git、magick、jq、rsync、sed、awk 等工具不是为 AI 时代临时发明的。它们被人类开发者、运维工程师、数据工程师用了几十年，稳定、可组合、文档丰富、行为可预测。

第二，CLI 天然适合 Agent。Agent 最擅长的不是点按钮，而是规划步骤、生成命令、读取输出、继续决策。CLI 正好把世界压缩成“命令输入”和“文本输出”。这对语言模型非常友好。

第三，CLI 可组合性极强。Unix 哲学强调一个工具做好一件事，再通过管道组合起来。例如：

find . -name "*.log" -type f | xargs grep "ERROR"

这个命令把“找文件”和“搜索内容”组合起来。对 Agent 来说，这种组合比调用多个远程工具更直接，也更容易调试。

第四，CLI 成本更低。让模型调用一个通用 bash 工具，生成一条短命令，通常比在上下文里塞入大量 MCP 工具 schema 更轻量。尤其当任务可以通过本地命令完成时，CLI 的 token 开销和协议开销都更小。

第五，CLI 的结果可以先过滤再进入上下文。Agent 可以用 find、grep、jq、head、tail、wc 等工具在本地把海量数据筛成很小的摘要，再把结果交给模型。MCP 也可以做类似优化，但 CLI 的生态已经天然支持这种工作方式。

CLI 与 MCP 的核心差异

可以从几个维度比较二者。

1. 定位不同

CLI 是执行界面。它面向操作系统、程序和脚本，重点是“做事”。

MCP 是连接协议。它面向 AI 应用和外部系统，重点是“标准化连接”。

所以二者不是完全替代关系。但当一个任务既可以通过 CLI 做，也可以通过 MCP 做时，CLI 往往更直接。

2. 抽象层不同

CLI 的抽象层很薄。模型生成命令，系统执行命令，返回 stdout、stderr 和退出码。

MCP 的抽象层更厚。它要定义 server、client、transport、tools、resources、prompts、schema、生命周期、能力协商等。

抽象层越厚，可控性越强；但性能和调试成本也更高。

3. 成本结构不同

CLI 的成本主要是模型理解任务、生成命令、读取必要输出。命令本身通常很短。

MCP 的成本除了模型推理，还包括工具描述、schema、工具调用内容块、工具结果内容块等上下文成本。Claude 官方工具使用文档明确说明，这些都会计入 token。

这意味着：工具数量越多、schema 越复杂、结果越冗长，MCP 的上下文成本越明显。

4. 安全模型不同

MCP 更适合细粒度权限控制。每个工具都有明确 schema，可以做参数校验、权限控制和审计。

CLI 更强大，也更危险。一个 bash 工具能做很多事，权限边界不如专用工具清晰。让 Agent 执行 CLI，最好放在沙箱里，并对删除、写入、网络访问、密钥读取等动作做限制。

所以安全上不能简单说 CLI 更好。更准确的说法是：MCP 的默认治理结构更清晰，CLI 的能力密度更高，需要更强的运行时沙箱和审批机制。

5. 适用场景不同

MCP 更适合：

• 连接 SaaS 服务；
• 需要 OAuth 或企业权限控制；
• 需要跨多个 AI 客户端复用工具；
• 工具参数需要强校验；
• 业务系统需要审计调用记录；
• 不希望 Agent 直接接触底层命令。

CLI 更适合：

• 本地文件处理；
• 代码库检索；
• 媒体转码；
• 图像处理；
• 数据清洗；
• 批处理自动化；
• DevOps 和构建任务；
• 任何已有成熟命令行工具的场景。

为什么未来 CLI 的优势会更明显

我更看好 CLI，不是因为 MCP 没用，而是因为 AI Agent 的发展方向越来越接近“会使用计算机的自动化工程师”。

一个强 Agent 最需要的不是成百上千个包装好的 API，而是一个可靠的执行环境：文件系统、shell、包管理器、语言运行时、测试框架、编译器、调试器、网络工具、媒体工具、图像工具、数据库客户端。

这些东西本来就以 CLI 形式存在。

未来 Agent 的工作方式大概率是这样的：

1. 先理解用户目标；
2. 在沙箱中检查文件和环境；
3. 选择已有 CLI 工具；
4. 执行命令；
5. 读取输出；
6. 根据结果继续行动；
7. 最后交付文件、报告、代码或变更。

这套流程中，CLI 是天然底座。

MCP 当然可以把工具包装得更标准，但它很难复制 CLI 生态的广度。今天几乎每个严肃工具都有 CLI：Git 有 CLI，Docker 有 CLI，Kubernetes 有 CLI，FFmpeg 有 CLI，ImageMagick 有 CLI，数据库有 CLI，云服务有 CLI，测试框架有 CLI，包管理器有 CLI。让 Agent 学会 CLI，相当于让它接入了整个工程世界。

更关键的是，CLI 的组合能力会随着模型能力提升而放大。过去人类需要记住命令参数；现在模型可以查文档、生成命令、解释错误、修正参数。CLI 的学习门槛被 AI 降低了，但 CLI 的执行效率和生态优势仍然保留。

这会改变工具生态的重心：过去 CLI 是专家工具，未来 CLI 会变成 Agent 的通用执行语言。

MCP 是连接标准，CLI 是执行底座

MCP 和 CLI 不是非黑即白的竞争关系。更合理的分工是：

• MCP 负责标准化连接外部系统；
• CLI 负责在执行环境中高效完成任务。

如果你要让 AI 访问 Notion、Linear、Sentry、企业数据库，MCP 很有价值。它让权限、工具发现和结构化调用更清晰。

但如果你要让 AI 真正“干活”，尤其是处理文件、代码、视频、图片、日志、构建、测试和部署，CLI 的优势会越来越明显。它更轻、更快、更成熟，也更接近软件世界原本的工作方式。

短期看，MCP 会继续增长，因为 AI 应用需要统一连接外部系统。长期看，CLI 会更胜一筹，因为真正的 Agent 不只是“会调用接口”，而是“会操作环境”。而操作环境这件事，CLI 已经领先了几十年。