今天，几乎所有的 AI Agent 都需要"动手"——写代码、查数据库、操作文件系统、调用 API。Agent 不能只思考，必须行动。而行动，就需要工具。

目前，Agent 获取工具有两条路径：CLI（命令行） 和 MCP（Model Context Protocol）。这不是两种"人机交互方式"的对比——在 Agent 场景下，人是退到幕后的。这是同一个 Agent 的两种工具接入模式，它们决定了 Agent 能做什么、怎么做、以及做的时候有多安全。

这篇文章要回答一个核心问题：当 Agent 需要操作外部世界，CLI 和 MCP 分别给了它什么？两者如何共存？

一、Agent 需要什么样的工具接口

在讨论 CLI 和 MCP 之前，先理解 Agent 对工具接口的核心需求：

可发现性：Agent 需要知道"我能做什么"

Agent 的第一个问题永远是：我现在有哪些工具可用？

如果 Agent 不知道自己有 git 命令，它就不会尝试提交代码。如果 Agent 不知道有一个"查询订单数据库"的 MCP Tool，它就不会去查。工具的可发现性决定了 Agent 能力的天花板。

可组合性：Agent 需要把多个工具串起来

Agent 很少只用一个工具完成任务。“查一下最近的 bug 报告，然后写个修复，再跑一遍测试”——这涉及数据库查询、文件编辑、命令执行三个工具的组合。

工具之间能否无缝组合，决定了 Agent 是"能干活"还是"只能做单步操作"。

可靠性：Agent 需要可预测的执行结果

Agent 做决策的前提是：如果我调用这个工具，我会得到什么。工具返回结果的格式越确定，Agent 的推理越可靠。

一个返回结构化 JSON 的工具，和一个输出格式随心情变化的命令行工具，对 Agent 来说是天壤之别。

安全性：Agent 需要被约束

Agent 拿到工具就像人拿到车钥匙——你希望它开车去超市，不希望它飙车撞墙。工具接口的设计决定了你能给 Agent 多大的自由度，以及出事时能不能兜住。

二、CLI：Agent 的瑞士军刀

当下主流 Agent 的实际选择

看看今天最强大的 Agent 系统怎么做工具接入的：

  • Claude Code：直接在终端中运行，通过 shell 执行命令、读写文件
  • OpenAI Codex CLI：沙箱中执行 shell 命令
  • Aider：通过 git 和文件系统操作代码
  • Devin：在浏览器和终端中执行操作
  • SWE-Agent：通过 bash 命令与代码仓库交互

这些顶级 Agent 几乎都选择了 CLI 作为主要工具接口。不是巧合，而是因为 CLI 有几个 Agent 特别需要的特性。

CLI 对 Agent 的核心优势

覆盖面极广。操作系统上几乎所有能力都有一条命令行入口。git、docker、kubectl、psql、curl、python——CLI 是现有软件生态最大的"工具超市"。Agent 通过 shell 可以触及几乎一切。

无需额外开发。MCP Server 需要有人写，但 CLI 工具已经存在了。Agent 想用 Docker，不需要等谁写一个 Docker MCP Server，直接 docker run 就行。这是 CLI 对 MCP 最大的现实优势：存量工具的覆盖度，CLI 是 MCP 的数百倍。

天然可组合。Unix 管道 | 和重定向 > 让命令组合成流水线。Agent 可以 curl | jq | grep 一条龙完成数据获取、解析、过滤——这种组合在 MCP 中需要三个独立的 Tool 调用和手动传递中间结果。

执行结果可观察。stdout 和 stderr 是确定的输出通道，Agent 知道去哪里读结果、怎么解析。退出码 0/1 提供了最简单的成功/失败判断。

CLI 对 Agent 的致命问题

自由度过高 = 风险过高。给 Agent 一个 shell，等于给了它操作系统的完整权限。rm -rf /、curl malicious.com | bash、sudo——shell 不区分"Agent 应该做的事"和"Agent 不应该做的事"。

这就是为什么 Claude Code 需要用户逐条确认危险命令，为什么 Codex CLI 需要沙箱。CLI 的自由度是它的力量，也是它的诅咒——你给了 Agent 一切能力，但你无法只给"安全的那部分"。

输出格式不可控。每个 CLI 工具的输出格式都不一样，而且同一个工具的不同版本可能输出不同。Agent 需要为每个命令写专门的解析逻辑。ls 的输出和 ps aux 的输出没有统一的格式规范——对 Agent 来说，每解析一个新命令就像对接一个没有文档的 API。

没有自描述能力。CLI 工具不会告诉 Agent “我能做什么、参数是什么、返回什么格式”。Agent 要么靠训练数据中的知识（“我知道 git commit -m 可以提交”），要么靠 --help 输出猜测。这就像一个人在黑暗中摸索工具箱——工具都在，但你不一定找得到。

状态管理困难。CLI 命令是无状态的——每次执行都是独立的进程。Agent 需要自己管理工作目录、环境变量、进程间状态。在 CLI 中做"cd 到项目目录，激活虚拟环境，然后跑测试"需要 Agent 自己维护上下文，而这些上下文在每次命令执行后就消失了。

三、MCP：Agent 的标准工具箱

MCP 给 Agent 提供了什么

MCP 为 Agent 定义了一个结构化的工具接入协议：

  • Tools：Agent 可以调用的函数，有明确的参数 schema 和返回格式
  • Resources：Agent 可以读取的数据源，类似"只读文件系统"
  • Prompts：预定义的提示模板，帮助 Agent 在特定场景中更有效

对 Agent 来说，MCP 的核心价值是：每个工具都是自描述的。Agent 不需要猜，MCP Server 会告诉它"我有这些工具，每个工具接受这些参数，返回这种格式的数据"。

MCP 对 Agent 的核心优势

自描述 = 可发现。这是 MCP 对 CLI 最大的架构优势。Agent 连接到一个 MCP Server，可以通过协议自动发现所有可用工具和它们的参数 schema。这意味着 Agent 可以在运行时动态适配新工具，而不需要提前训练。

想象一下：一个 Agent 被部署到新公司，连接到公司的 MCP Server，自动发现"查内部知识库"、“提交审批单”、“查询项目进度"三个工具——然后就能开始工作。不需要微调，不需要插件市场，连接即用。

结构化输入输出。MCP Tools 的参数和返回值都是 JSON Schema 定义的结构化数据。Agent 不需要解析自然语言格式的 stdout，它拿到的是确定的数据结构。这让 Agent 的工具调用可靠性大幅提升。

权限边界清晰。MCP Server 只暴露它想暴露的工具。一个数据库 MCP Server 可以只提供"查询"工具而不提供"删除"工具。这比给 Agent 一个 shell 然后祈祷它不执行 DROP TABLE 安全得多。

跨客户端复用。同一个 MCP Server 可以被 Claude、ChatGPT、VS Code Copilot、任何支持 MCP 的 Agent 使用。写一次，到处运行。

MCP 对 Agent 的现实困境

工具覆盖度严重不足。截至 2026 年初，MCP 生态的工具数量和 CLI 生态不在一个量级。Agent 想用 terraform？没有官方 MCP Server。想用 ffmpeg？没有。想用 awk？没有。MCP 的"标准工具箱"目前还太小，远远覆盖不了 Agent 的日常需求。

组合能力受限。MCP Tools 是独立调用的——Agent 调用 Tool A，拿到结果，再调用 Tool B。没有管道，没有流式处理。比起 CLI 的 cmd1 | cmd2 | cmd3，MCP 的工具组合更笨重、更慢、更耗 token。

每次工具调用都是一次 LLM 推理。在 Agent 循环中，每个 MCP Tool 调用通常需要一轮 LLM 思考。三个工具的组合 = 三次 LLM 调用。而 CLI 可以一条命令 cmd1 | cmd2 | cmd3 一次执行完成。在 token 成本和延迟上，MCP 的组合远比 CLI 管道昂贵。

引入新的复杂度。MCP 不是银弹——它引入了自己的问题：服务发现、版本兼容、连接管理、错误重试。对于简单的"帮我跑个命令"场景，搭一套 MCP Server 反而比直接 shell 执行重得多。

四、Agent 场景下 CLI 与 MCP 的真实关系

不是二选一，是分层协作

在真实的 Agent 系统中，CLI 和 MCP 的关系不是"谁替代谁”，而是分层协作：

┌─────────────────────────────┐
│       Agent（LLM 推理）      │
├──────────┬──────────────────┤
│  MCP 层  │   Shell/CLI 层   │
│ (结构化)  │   (自由形式)      │
├──────────┴──────────────────┤
│       操作系统 / 外部服务     │
└─────────────────────────────┘

MCP 层：用于需要安全性、可发现性、结构化的工具——数据库查询、API 调用、文件读写、消息发送。这些操作有明确的输入输出，需要权限控制，值得投入开发 MCP Server。

Shell/CLI 层：用于需要灵活性和覆盖面的工具——系统管理、DevOps 操作、一次性任务、还没有 MCP Server 封装的存量工具。这是 Agent 的"万能钥匙"。

CLI 是 MCP 的底层实现

一个关键的事实：很多 MCP Server 的底层就是 CLI 工具的封装。

GitHub MCP Server 底层调用 git 命令。Docker MCP Server 底层调用 docker 命令。Postgres MCP Server 底层调用 psql 或 SQL 驱动。MCP 不创造新能力，它结构化地暴露已有能力。

这意味着 CLI 和 MCP 不是竞争关系，而是封装关系：CLI 是能力的原子层，MCP 是能力的结构化接口。就像 REST API 底层可能调用系统命令一样，MCP 是 CLI 之上的一层协议抽象。

信任梯度

在 Agent 系统中，CLI 和 MCP 形成了一个信任梯度：

信任级别工具接口Agent 行为人类介入
高信任MCP（只读）自动执行无需确认
中信任MCP（写入）自动执行+日志事后审查
低信任CLI（安全命令白名单）需确认事前审批
危险CLI（任意命令）禁止/需人工必须人在环

好的 Agent 架构应该利用这个梯度：尽量通过 MCP 完成操作，CLI 作为后备和逃逸通道，但施加更严格的约束。

Agent 的工具选择策略

对 Agent 来说，选择 CLI 还是 MCP 不是哲学问题，是实用策略：

优先 MCP 的场景：

  • 有现成 MCP Server 的工具（数据库、日历、消息）
  • 需要结构化输入输出的操作（查询、搜索）
  • 需要权限控制的操作（写入、删除）
  • 需要跨客户端复用的工具

回退 CLI 的场景：

  • 没有 MCP Server 的工具（大量 DevOps 工具）
  • 需要管道组合的操作（数据处理流水线）
  • 一次性快速操作（ls、cat、grep）
  • MCP Server 出错时的降级方案

这种"优先 MCP，回退 CLI"的策略，可能是当前最务实的 Agent 工具架构。

五、深度思考：Agent 工具接口的演进方向

CLI 会不会被 MCP 完全取代？

不会，至少短期不会。原因很简单：MCP 的工具覆盖度增长速度远低于 CLI 生态的存量。 而且很多 CLI 工具的输出格式混乱、行为不可预测，天然不适合结构化封装——硬要包一层 MCP，反而增加了复杂度。

更可能的演进是：高频、高风险、需要权限控制的工具逐步被 MCP 封装；低频、灵活、一次性的操作继续通过 CLI 完成。

“Shell MCP”——两者的融合点

一个有趣的融合方向是"Shell MCP Server"——一个把 shell 能力封装为 MCP Tools 的服务。Agent 通过 MCP 协议调用 run_command，MCP Server 在沙箱中执行命令并返回结构化结果。

这看起来像是多此一举——为什么不直接跑 shell？但在 Agent 架构中，这个中间层有价值：

  • 统一的工具发现协议：Agent 只需对接 MCP，不用同时维护 MCP 和 Shell 两种工具接口
  • 沙箱化执行：MCP Server 可以在容器中执行命令，隔离风险
  • 审计日志：所有命令调用都经过 MCP 协议，天然可追踪
  • 权限过滤：MCP Server 可以禁止危险命令

当然，这层封装也有代价——灵活性受限、延迟增加、维护成本上升。它是否值得，取决于你的 Agent 需要多大的安全性和可审计性。

工具的"涌现能力"

CLI 的管道组合天然支持"涌现能力"——sort | uniq -c | sort -rn 不是任何单一工具的功能，而是组合后涌现出来的。MCP 目前的架构（独立的 Tool 调用）不太支持这种涌现。

未来的 MCP 可能需要引入"工具链"（Tool Chain）或"工作流"（Workflow）的概念——允许 Agent 预定义一组工具的组合方式，一次调用执行整条链路。这将减少 LLM 调用次数、降低 token 成本、提高可靠性。

从"工具"到"协作者"

CLI 和 MCP 目前都是"工具接口"——Agent 用它们操作无生命的东西（文件、数据库、API）。但 Agent 的未来可能需要"协作者接口"——Agent A 通过某种协议委托 Agent B 执行子任务。

MCP 的架构天然支持这个方向：如果把 Agent B 暴露为 MCP Server，Agent A 就可以通过 MCP 协议"调用"Agent B 的能力。这不是工具调用，而是任务委派——Agent 之间的协作。

CLI 在这个方向上则无能为力——命令行是"人对机器"的接口，不是"机器对机器"的协作协议。

六、实践启示

对 Agent 开发者

  1. 不要只用 CLI，也不要只用 MCP。两者互补，不是互斥。“优先 MCP，回退 CLI"是当前最务实的策略。
  2. 把你最常用的 CLI 工具封装为 MCP Server。这是投入产出比最高的工作——一次封装，所有 MCP 客户端受益。
  3. 设计好信任边界。MCP 处理高信任操作，CLI 用于低信任但必要的操作，危险操作需要人在环。
  4. 记录所有工具调用。无论走 MCP 还是 CLI，日志是事后审计和调试的基础。

对企业 Agent 平台

  1. 建设 MCP 工具生态是战略投资。企业内部系统（CRM、ERP、工单系统）的 MCP 封装，是 Agent 落地的前提。
  2. 不要忽视 CLI 的价值。在 MCP 生态不成熟的今天，CLI 是 Agent 能力的"安全网”。过早限制 Agent 只用 MCP，等于人为限制能力。
  3. 安全模型要覆盖两层。CLI 的权限控制和 MCP 的权限控制是两套体系，但 Agent 会同时使用两者——你需要统一的审计和授权框架。

对 AI 应用产品经理

  1. 用户看到的不是 CLI 或 MCP，是"Agent 能不能帮我搞定"。底层用哪种接口是工程决策，不是产品决策。
  2. 可解释性的需求在 MCP 层更容易满足。MCP 的结构化调用天然可解释，CLI 的自由形式命令需要额外解析。如果你的产品需要向用户展示"Agent 做了什么"，优先走 MCP。

七、结语

在 Agent 场景下，CLI 和 MCP 不是两种"交互方式"的竞争，而是同一个 Agent 的两种工具接入模式：

  • CLI 是存量能力的万能钥匙——覆盖广、组合灵活、但自由度过高、输出不可控
  • MCP 是结构化能力的标准接口——自描述、安全可控、但覆盖不足、组合笨重

它们的关系是分层协作 + 封装依赖：CLI 是能力的原子层，MCP 是能力的结构化接口。大多数 MCP Server 底层就是 CLI 的封装。

对 Agent 来说，最好的架构不是"选一个"，而是让两者各司其职：MCP 处理需要安全性、可发现性的结构化操作，CLI 处理需要灵活性和覆盖面的自由操作。

而更长远的趋势是：MCP 会逐步吞噬 CLI 的领地——不是消灭 CLI，而是把 CLI 的能力逐步结构化地封装进 MCP 生态。就像 REST API 没有消灭系统命令，但把最常用的能力抽象成了更容易消费的接口。

最终，Agent 的工具接口会收敛到一种状态：底层是 CLI 的灵活性，上层是 MCP 的结构化，中间是信任梯度和权限边界。 在这个架构中，人不再直接操作 CLI 或 MCP——但人的意图、约束和审批，渗透在每一层。