MCP工具实战（一）-认识MCP与CLI选型

发表于 2026-05-05 更新于 2026-05-05 分类于技术文章阅读次数：本文字数： 1.7k 阅读时长 ≈ 6 分钟

最近在整理 Agent 工具链时，我发现很多同学会把 MCP 和 CLI 混在一起讨论：
有的人觉得 MCP 是 CLI 的“替代品”，也有人觉得 MCP 是“换个名词的函数调用”。

其实这两者并不是二选一关系，而是面向不同调用方的两种接口形态。
这篇先把“认知层”讲透，重点回答三个问题：

MCP 到底是什么，解决了什么问题？
MCP 和 CLI 的区别与联系是什么？
在真实项目里，该怎么做选型？

1. 为什么会有 MCP

在没有 MCP 之前，AI 调工具通常是“各家各写一套接法”：

有的走插件协议
有的直接拼 prompt 让模型输出命令
有的手写函数调用 JSON 格式
有的干脆把 shell 命令直接暴露给模型

短期看都能跑，但随着工具数量变多，会出现几个明显问题：

接入碎片化：每个客户端都要单独适配，每接一个平台就重做一遍。
参数不稳定：缺少统一 schema，模型容易传错字段或类型。
治理困难：权限、审计、错误处理分散在各处，难以统一管理。
迁移成本高：换一个 Agent 平台，工具层几乎要重来。

MCP（Model Context Protocol）出现的价值，就是把“模型如何发现和调用外部能力”这件事协议化、标准化。

2. MCP 是什么：一句话与核心结构

一句话理解：

MCP 是连接大模型与外部工具/资源的标准协议层。

可以把它理解成 AI 工具生态里的“通用接口标准”。

MCP 里最重要的几个概念：

2.1 Host / Client / Server

Host：承载 AI 能力的应用（例如 IDE、Agent 平台）
Client：Host 内部负责和 MCP Server 通信的组件
Server：暴露能力的一端（由你或第三方提供）

2.2 Tool / Resource / Prompt

Tool：可执行动作（查数据库、发请求、执行任务）
Resource：只读上下文（文档、配置、知识数据）
Prompt：可复用提示模板（用于规范任务输入）

可以先记住一个核心点：
MCP 不只是“执行函数”，还强调能力发现、参数约束和结构化返回。

3. MCP 的工作方式：从发现到调用

一个典型 MCP 工具调用流程大致如下：

Client 与 Server 建立连接
Client 拉取可用工具列表（工具发现）
模型根据工具描述与参数 schema 组织调用参数
Client 发起结构化调用请求
Server 执行工具逻辑并返回结构化结果
模型基于结果继续推理或生成最终回答

这套机制有两个工程收益非常明显：

对模型更友好：有明确参数定义，减少“猜参数”错误
对系统更友好：调用链可审计，可治理，可演进

4. MCP vs CLI：区别、联系与常见误区

这一节是最容易争议的地方。先看结论：

CLI 不是过时方案，MCP 也不是万能替代。二者面向对象不同，可以互补。

4.1 关键区别

对比维度	MCP	CLI
主要调用方	模型/Agent	人或脚本
参数表达	结构化 schema（字段、类型、必填）	命令参数字符串
能力发现	可发现（list tools）	依赖文档/`--help`
错误语义	可返回结构化错误	多为 stdout/stderr 文本
治理能力	易做统一权限、审计、限流	更依赖系统层约束
组合能力	通过编排层实现	天然支持管道与 shell 组合

4.2 二者的联系

常见的工程做法有两种：

CLI 外包一层 MCP：保留原有 CLI 能力，对 AI 暴露 MCP 接口。
MCP 内部调用 CLI：MCP 作为统一入口，底层仍复用成熟命令工具。

所以它们不是互斥关系，而是“接口层”和“执行层”的不同切面。

4.3 常见误区

误区 1：MCP 出现后，CLI 就没用了
- 实际上，CLI 在开发运维和本地自动化中仍然非常高效。
误区 2：把任意脚本直接塞给 MCP 就算完成改造
- 如果没有清晰 schema、稳定返回和错误分级，模型调用体验会很差。
误区 3：MCP 一定比 CLI 更省成本
- MCP 在治理上收益大，但也有协议接入与维护成本。

5. 如何选型：一套可执行决策法

下面给一个“能直接用”的判断顺序。

Step 1：先看主要调用方是谁

如果主要是人/脚本在终端执行，优先 CLI。
如果主要是AI Agent稳定调用，优先 MCP。

Step 2：看你是否需要结构化治理

如果你需要这些能力，MCP 优势明显：

统一参数约束（schema）
统一权限边界
统一审计日志
统一工具发现与描述

Step 3：看你是否已有成熟 CLI 资产

如果已有大量 CLI，建议走渐进路线：

先不推翻 CLI，先给高频能力加一层 MCP 适配。

这样风险小、见效快，也方便团队迁移。

Step 4：看团队角色构成

开发者主导团队：CLI 起步更快
多角色协作（产品、运营、分析）且希望 AI 可直接用：MCP 更合适

6. 落地建议：团队从 0 到 1 的实践路线

如果你准备开始做，推荐按这 4 步推进：

先选 1~2 个高频场景
例如“知识检索”“工单创建”“查询指标”。
定义稳定的输入输出 schema
不追求大而全，先把高频参数设计清晰。
补齐错误分层与日志审计
至少区分用户错误、权限错误、系统错误。
建立 MCP + CLI 共存策略
新能力优先 MCP，老能力逐步适配，不做一次性重构。

你会发现，真正难的不是“把工具跑起来”，而是“让工具长期可维护”。

7. 总结

这篇先统一认知：

MCP 的核心价值是“标准化模型调用外部能力”
CLI 依旧重要，尤其在开发和脚本自动化场景
工程上最稳妥的路线通常是：CLI 能力沉淀 + MCP 统一对接 AI

下一篇我会进入实战：
从一个普通函数出发，完整演示如何封装成 MCP Tool（含参数 schema 与错误处理）。