CLI vs MCP：为什么AI Agent工具化应该从终端命令行开始？

你只想让 AI Agent 帮你把活干完：定位 bug、跑测试、改配置、发版回滚，最后把改动收敛到一份可审查的 git diff。

但很多团队在“让模型用工具”这一步，先把自己拖进了另一件事：工具怎么接、怎么描述、怎么分发、怎么治理。协议、schema、catalog、discovery、权限、审计，一层层叠上去，最后工具是连上了，交付速度却没上来。

这让我想起最近某大厂研发团队的一组数据：AI 代码生成率从 1% 干到 30%+，部分业务线超 40%，个人体感效率提升 20%–40%。听起来很漂亮，但拉全局一看——组织整体的需求交付效率，基本没变。他们把这个现象总结成一个不等式：用 AI 工具 ≠ 个人提效 ≠ 组织提效。

工具层的选择也一样。MCP（Model Context Protocol）的 schema 写得再规范、catalog 梳理得再齐整，如果它没有缩短“需求到上线”这条链路，那它只是在中间加了一站，而不是修了一条高速公路。

今天我翻到一条在 2 月 11 日发布的长推，作者是 Marco Franzon（来自 eXact-lab，专注计算机视觉与边缘 AI，同时也是 Docker Captain 社区成员）。他把这股情绪拉满了：CLI Is All You Need。

六万次浏览，评论区几乎一边倒。

他的核心观点很直接：MCP 这波热潮，对大多数日常开发来说“偏重”。简单讲，MCP 想把“工具调用/资源访问”标准化，让 Agent 通过统一协议去发现与调用能力。问题在于，当你的目标只是把代码改对、把测试跑通，这套标准化常常来得太早、太重。

他给出的更短路径是：把 Agent 放进项目目录，给它受控的 shell 执行权限，让它使用几十年来最成熟的工具链：bash、git、rg、grep、curl、jq、docker、tail。他甚至用一句很短的话概括这种取舍：No custom servers. No massive schema descriptions.

这不是一个人在喊。

早在 2 月 4 日，Tony Bai 就撰文分析了 OpenClaw 作者 Peter Steinberger 的同一判断——“忘掉 MCP？CLI 才是 AI 连接世界的终极接口”。而在 OpenClaw 创下 2 天 10 万 Star 的纪录后，整个社区都在重新审视这个问题。更有意思的是，2 月 14 日 Google 与 Microsoft 刚刚联合发布了 WebMCP 早期预览——协议本身还在进化，但一线开发者已经在用脚投票了。

所以这不是“CLI 对不对”的问题，而是：什么时候用 CLI，什么时候才该上 MCP？

这篇我想把四件事说清楚：

• 这条长推到底在反对什么（以及它没说出来的前提）
• CLI 为什么对 LLM/Agent 这么“顺手”
• MCP 的价值边界在哪里（别把它写死）
• 一套可落地的“先 CLI，后 MCP”的工具化路线

原帖在这里（建议先看一眼原话语气）：
https://x.com/mfranz_on/status/2021364017147818434

---

TL;DR

• CLI 对 Agent 友好，靠的是“自描述 + 可组合 + 低摩擦”：--help 能把用法讲清楚，stdout/stderr + exit code 天生适配流水线与重试。
• MCP 的问题不在于“没用”，而在于“默认过重”：当你只需要执行动作，MCP 往往把成本提前了。
• 真正分界线是治理需求：多租户、权限分级、审计、发现机制、长效资源抽象，这些是 MCP 的主场。
• 走 CLI 也要工程化：否则你只是把“协议复杂”换成“脚本地狱”。
• AI-Native CLI 的关键是：少交互、可机读、可回滚、可验证：--json、稳定 exit code、--dry-run、--yes、幂等、超时与重试。
• 推荐路线：个人/小团队先用“CLI + 护栏”跑起来；当工具开始被多人复用、开始需要治理时，再把成熟子集封装成 MCP server。

---

1）这条长推反对的，其实是“把工具化写成平台化”

长推里的攻击点很集中：

• schema/catalog 太长，占上下文
• 为了对齐协议，重复造轮子
• 少了 Unix 管道的组合感，反而不好拼

我更愿意把它翻译成一句话：

如果一个问题的核心是“执行动作”，你却先去解决“能力描述与分发”，大概率会慢。

这就像堵车时你换了一台加速更快的车。绿灯亮了你确实起步比别人快，但前面还是堵着，到目的地的时间并没有变。瓶颈不在你的车，在路上。 同理，瓶颈往往不在“模型能不能调到工具”，而在“调到工具之后能不能把闭环跑完”。

推文里举的例子非常“终端本能”，也很能代表日常研发的高频任务：

• Monorepo 全局重构：先 rg 定位，再批量改动，git diff 审查，最后跑测试——无需 GitHub MCP 服务器，没有臃肿的上下文，只有 rg、git 和测试运行器
• 生产 bug 排查：tail -f 盯日志、curl -v 探端点、docker-compose up 拉依赖，再针对性改一处——无需 Docker MCP，无需日志 MCP，只需精通 Shell
• 脚手架式新服务：cargo new / npm create 这种一条条命令把工程拉起来，边跑边修——无需 Rust MCP，无需数据库 MCP，现有工具链已经足够
• CI/CD 抖动修复：本地复现工作流，定位失败点，改配置或 Dockerfile，再验证——全是标准 CLI 工具，无需定制 CI 集成层

这些动作放在 MCP 体系里当然也能做，但推文的意思是：在“改代码 + 验证 + 收敛 diff”这个闭环上，CLI 天然就是最短路径。

他还顺带点名了一批“CLI 原生”的编码 Agent：Claude Code（深度推理领先，原生终端工作流）、Codex CLI（轻量快速，开源可调）、Gemini CLI（免费层级 + 强多模态，终端优先的 ReAct 循环）、OpenClaw（75+ 供应商多模型灵活性，LSP 集成，社区增长最快）。它们共同点很一致：把 shell、文件编辑、测试运行、git diff 这些动作放在第一优先级，而不是先让你搭一套能力服务器。

评论区也很典型。@yogssh_sh 的回复很直白：“CLI 是无头的、直接 API 调用、快、轻量、直连终端工具、资源占用少、易用。” Marco 本人回了一句更干脆的：“我经常看到 Notion MCP、Slack MCP……但如果你有靠谱的 CLI，MCP 的意义何在？” 另一位社区开发者 @cjimti 也点了个更深的问题：“Kubernetes 根本不适合用来托管个人博客。MCP 拿来描述一套通用工具，也不应该是评判标准。”——本质上在说：别拿企业级需求去衡量个人/小团队的工具选择。

原帖里那几句流传很快的话，我觉得可以当成提醒贴在工位上：

“Stop building integrations. Build CLIs.”
“Bash is the ultimate MCP.”
“Agents were trained on Unix pipes—they’re ridiculously good at it.”
“CLI is all you need. Everything else is ceremony.”

很多团队在做 Agent 工具化时，默认的路线是：

1. 先建一套 server（或者买一套）
2. 先把能力都描述成 schema
3. 先搞 discovery、权限、审计、发布
4. 再回到具体任务：改代码、跑测试、排 bug

这条路当然“正规”，但它对绝大多数研发团队来说，往往过早。

你要的结果通常是：
能在仓库里跑起来，能把改动收敛到 diff，能把失败复现并定位。

而这些，终端工具链本来就擅长。

---

2）CLI 对 Agent 友好，核心是三个字：自描述

人类觉得 CLI 难，是因为我们得“记住怎么用”。
Agent 不需要记，它会先问：--help。

这就是 CLI 在 AI 时代“突然变简单”的关键：工具把自己教给模型。

这不是推测——OpenClaw 的作者 Peter Steinberger 在实际开发中观察到了一个非常具体的现象：智能体拿到新工具后，会自发运行 my-tool --help，然后仅仅通过阅读这份帮助文档，在那一秒钟内就学会了如何操作这个工具。零配置，零预训练，零人工对齐。正如 Tony Bai 在分析文章中提炼的：

--help 吐出的文档，本质上就是一份零噪音、高密度、且包含示例（Few-shot）的 Prompt。

把 --help 当成 prompt，你会发现它天然具备几件事：

• 参数表是结构化的（而且短）
• 常见用法可以写成 few-shot 示例
• 输入输出边界清晰（尤其是非交互式命令）

更重要的是：CLI 的默认 I/O 模型是 stdout/stderr + exit code。
这对 Agent 来说非常“工程化”：

• stdout：业务结果（可继续被管道消费）
• stderr：错误与诊断（可被总结/重试/上报）
• exit code：确定性的成败信号（比“看起来像失败”靠谱）

还有一层经常被忽视的对齐优势：Marco Franzon 在原帖中特别提到，前沿模型（Claude、GPT 变体、Gemini）都针对 Shell 使用进行了大量训练。它们对参数（Flags）、管道、错误信息和 Man 手册风格的文档理解得异常透彻。对 Agent 来说，shell 不是冰冷的命令，而是它最擅长的“母语”。

当你把这些拼在一起，Agent 的能力会从“会调用某个 API”，变成“能把一条流水线跑通”：

rg "AuthError" -n . \
  | head -n 20 \
  && git blame -L 120,180 src/auth.ts

这种管道式的链式组合，与智能体的思维链（Chain of Thought） 逻辑高度契合——正如 Unix 哲学的核心：“只做一件事，并把它做好”，通过管道进行组合。智能体不需要你编写复杂的集成逻辑，它只需要像玩积木一样编排原子化的 CLI 工具。这恰恰是 MCP 体系里最容易被稀释掉的部分。

---

3）MCP 仍然很值钱：当你的问题从“动作”变成“资源”

我不认同“CLI 会全面替代 MCP”。

因为 MCP 的价值点，很多时候不在“能不能执行动作”，而在“能不能把复杂世界做成可治理的资源层”。Tony Bai 在分析 OpenClaw 时用了一个精准的比喻：CLI 是肌肉，MCP 是神经系统。肌肉负责执行敏捷的本地动作，神经负责连接并治理复杂的分布式资源。

MCP 的核心价值集中在几个 CLI 难以替代的维度：

从“盲摸”到“自报家门”：发现机制的代差

• CLI 模式：Agent 必须预先知道 ls、grep 这些命令名。你在自己机器上跑十几个命令，CLI 很顺。但一旦环境里有几百上千个内部工具，你不可能把所有命令名、参数、注意事项都塞进上下文让模型“碰运气”。这会导致严重的 Context 溢出和注意力稀释。
• MCP 模式：拥有标准的 Discovery（发现）机制。当 Agent 连接到一个 MCP Server 时，Server 会主动上报一份精简的“能力清单”。这是机器与机器之间的元数据对齐，比 Agent 在 Shell 里“瞎撞”要高效且精准得多。

从“一次性动作”到“长效资源”：抽象能力的升维

• CLI 的本质是“工具（Tools）”：它是瞬时的、原子化的动作。
• MCP 引入了“资源（Resources）”：它能将一个持续更新的数据库表、一个实时日志流、甚至一个远程设备状态抽象为一个 URI。MCP Server 还可以为这些资源提供“动态提示词模板”——它不仅给 AI 数据，还告诉 AI “针对这组数据，你当前应该关注哪些风险点”。这种“数据 + 方法论”的打包分发，是 CLI 无法实现的。

安全治理：执行层护栏 vs. 协议层契约

• CLI 的风险：赋予 Agent Shell 权限，意味着你把“核武器”交给了它。它可能在修复 Bug 时，因为一个幻觉顺手运行了 rm -rf /。
• MCP 的护城河：代理（Proxy）架构。精细权限——你可以定义此 Server 只能 Read 资源，严禁任何写操作。跨宿主复用——MCP Server 一旦写好，可以无缝挂载到 Claude 网页版、Cursor、甚至自建机器人中，无需在对应宿主机上安装任何二进制程序。这种“即插即用”的可移植性和安全性，是传统 CLI 无法比拟的。

协议本身也在进化

值得注意的是，2 月 14 日 Google 和 Microsoft 刚刚联合发布了 WebMCP 早期预览——目标是把每个网站变成 AI Agent 可调用的 API。Chrome for Developers 官方说明：“WebMCP 旨在提供一种标准方式来暴露结构化工具，确保 AI Agent 能以更快、更可靠、更精准的方式在你的站点上执行操作。” 这说明 MCP 的理念不仅没有消亡，反而在向更广的生态渗透。

我常用一个更直白的分界线：

当你开始需要“治理”，MCP 才开始划算。

简单对比一下：

维度	CLI（工具）	MCP（能力/资源）
本质	一次性动作	可发现的能力集合 + 资源抽象
组合方式	管道/脚本/Makefile	server 端编排 + 统一协议
上手成本	低	中-高
复用与分发	靠约定/文档/脚手架	协议化分发、可治理
安全策略	依赖外部护栏	内建权限、审计、边界
可移植性	需要在宿主机安装二进制	即插即用，跨宿主复用
适用场景	个人/小团队、快速迭代、排障与重构	企业集成、多租户、合规、强审计

重点不在于“选边站”，而在于：先把任务跑通，再决定要不要把它产品化。

用 L1/L2/L3 来校准你的选择

某大厂在实践中提出了一套“需求 AI 研发成熟度”分级，对这个判断很有帮助：

• L1（AI 辅助）：Copilot 模式，人主导所有环节，AI 只在编码时帮忙——编码快了，但省下的是碎片时间，不够再接一个需求
• L2（AI 协同）：Agent 模式，从技术设计到编码到测试，研发全流程 AI 参与——开发周期缩短约 30%
• L3（AI 自主）：Agentic 模式，人更像产品经理，把需求说清楚交给 AI 验收——开发周期缩短约 40%

关键洞察是：CLI 原生 Agent 天然在 L2/L3 更有优势。因为 Agent 在终端里“改代码 + 跑测试 + 审查 diff + 提交”是一个连续的闭环，不需要你先搭平台再回来干活。而 MCP 更适合在 L2/L3 的组织层解决问题——当多个 Agent、多个团队、多个入口需要共享同一组能力时，协议的治理价值才真正显现。

他们的数据也佐证了这一点：50%–70% 的需求在不改流程的情况下就可以用 L2 方法，但实际只有不到 10% 的人在这么做。问题不在工具不够多，而在工作方式没跟上。选 CLI 还是 MCP，本质也是同一个问题的投影。

---

4）AI-Native CLI 怎么写：把“好用”写进默认值里

如果你决定走 CLI 路线，我建议把 CLI 当成“给 Agent 的 SDK”。
重点不在于“人能用就行”，而在于“机器用起来稳定”。

Peter Steinberger 在开发 OpenClaw 时发现：在 AI 时代，写好 --help 文档，比写好 UI 界面更重要。 下面这份清单，我自己会当作最低配。

---

4.1 --help 不要敷衍：它就是你的系统提示

一个对 Agent 友好的 --help，至少要有：

• 语义明确的参数描述（尤其是副作用参数，如 --force、--dry-run）
• 2–6 个高质量示例（覆盖常见路径 + 边界，AI 最擅长模仿，多给 Example 出错率直线下降）
• 输出格式说明（默认 human readable，另提供机读）

示例（示意写法）：

USAGE:
  deploy --env <staging|prod> --service <name> [--json] [--dry-run] [--yes]

EXAMPLES:
  # 预览将执行哪些变更（不落地）
  deploy --env staging --service api --dry-run

  # 真正执行，并输出 JSON 便于 agent 解析
  deploy --env staging --service api --yes --json

---

4.2 默认非交互：交互是 Agent 的“卡死点”

尽量别让命令停在：

• “Are you sure? (y/n)”
• “Choose an option”
• “Press any key to continue”

要确认，就提供 --yes 或 --force，并且：

• 默认更保守（例如默认 dry-run）
• 把危险操作显式化（例如必须加 --dangerous 才允许）

---

4.3 可机读输出：--json 不是锦上添花，是稳定性的底座

给 Agent 用的 CLI，最好同时支持：

• --json：结构化输出（给 agent/脚本）
• 默认输出：给人看的摘要（给人类）

典型反例与正例：

# ❌ 让 AI 费劲解析 ASCII 表格
$ aws ec2 describe-instances
INSTANCE        STATE    TYPE
i-12345         running  t2.micro

# ✅ 直接吐出 JSON，方便 AI 解析
$ aws ec2 describe-instances --output json

并且约定：

• stdout 只放结果（JSON 或简短摘要）
• stderr 放诊断信息（可被收集）

---

4.4 稳定的 exit code：别让模型猜“是不是失败”

最常见的坑是：失败了也 exit 0，或者成功了却在 stderr 打了一堆“看起来很像报错”的字。

建议约定：

• 0：成功
• 1：业务失败（输入不合法/权限不足/资源不存在）
• 2：可重试失败（网络/超时/依赖不可用）

你不一定要照这个分，但要稳定，并写进 --help。

---

4.5 幂等 + --dry-run：让“试一次”变得安全

Agent 出错时常见策略是重试。
如果你的命令不是幂等的，重试就是灾难。

最低配建议：

• 支持 --dry-run：输出将执行的动作（尤其是写操作）
• 支持 --idempotency-key（或在内部自动生成并记录）
• 支持 --timeout 与 --retry（避免无限挂起）

---

5）“给 shell 权限”不是一句话：护栏要前置

很多人听到“直接给 Agent shell”，第一反应是“这不就是把核按钮交出去？”
这个担心完全合理。Tony Bai 在分析文章中也直言：“赋予智能体 Shell 权限意味着你把‘核武器’交给了它。”

但现实里我们并不是在两种极端之间选：

• 要么全开放 shell
• 要么全封闭协议

更常见、也更务实的做法是：CLI + 护栏。

Marco Franzon 在原帖里给了一句关键的限定词，很容易被忽略：with safeguards（带安全防护）。这不是无条件把终端交出去。

我见过有效的护栏组合大概是这样：

• 命令白名单：只允许一组固定工具（git/rg/npm/docker…）
• 只读优先：默认只读；写操作必须显式开启
• 目录隔离：限制工作目录与可访问路径（避免“误删家目录”）
• 网络边界：按环境限制外网访问、限制凭证注入
• 审计与回放：记录每次命令、输出摘要、变更 diff

如果你的团队已经在做 MCP 的权限治理，这些东西你其实已经在做了。
只是换成 CLI 路线后，需要把护栏放在“执行层”而不是“协议层”。

---

6）一张决策树：先 CLI，什么时候再上 MCP？

我更推荐的路线不是“选一个押注”，而是“分阶段收敛复杂度”：

你想给 AI 增加新能力
    │
    ├─ 只给自己/小团队用？
    │   └─ YES → 写 CLI（--help + examples + --json + exit code + --dry-run + --yes）
    │
    ├─ 需要权限/审计/合规？
    │   └─ YES → 封装成 MCP server（能力发现 + 权限治理 + 审计与回放）
    │
    └─ 能力是否稳定且会被多处复用？
        ├─ NO → 写 CLI
        └─ YES → 封装成 MCP server

你会发现这里的核心不是“技术优劣”，而是三个问题：

• 这东西是不是要被多人复用？
• 我是不是必须治理与审计？
• 能力是否已经稳定到值得协议化？

把这三问答清楚，争论会少很多。

OpenClaw 的成功也印证了这条路线：它避开了复杂的协议之争，用 CLI 解决了 AI “手脚”的问题，让 Agent 能够真正触碰到现实世界。700+ 技能插件、5 分钟部署、2 天 10 万 Star——这不是偶然，而是“简单优先”原则在社区里的正向选择。

---

7）给不同读者的落地建议

如果你是工程师（个人/小团队）

• 先把你的“重复劳动”做成 CLI：日志筛选、发布、回滚、对比、迁移、批处理
• 写 CLI 时默认带上：--help 示例、--json、--dry-run、稳定 exit code
• 让 Agent 围绕 git diff 工作：所有改动都要可审查、可回滚
• 原则：写个脚本就能搞定的事，别去写 Server

如果你是技术负责人（团队）

• 别急着平台化：先在 2–3 条最痛的工作流上跑通闭环（排障/修复/发布）
• 把护栏标准化：白名单、目录隔离、审计、权限分级
• 当 CLI 工具开始扩散到多个团队、多个入口，再考虑收敛成 MCP（否则你会维护一堆半成熟 schema）

如果你是平台/基础设施团队

• 把“工具发现、权限、审计、凭证管理”做成通用能力，这些无论 CLI 还是 MCP 都需要
• 允许“轻量接入”：给业务团队一条最短路径（先 CLI），同时提供升级路径（再 MCP）
• 关注 WebMCP 等新规范的演进——协议在成熟，但节奏要跟场景走

---

结尾：别把它写成宗教之争

“CLI Is All You Need”这句口号，价值不在于它对不对，而在于它提醒我们回到一个很朴素的目标：

让 Agent 真的把活干完，而不是让我们把连接方式做得很漂亮。

高可用架构在解读 Marco 原帖时用了一句话，我觉得很精准：与其为 AI 建造精致的“笼子”（MCP），不如给它一套通用的“杠杆”（CLI）。 MCP 本质上是在 AI 和操作系统之间加了一层翻译，试图把万物转换成结构化的 JSON。但 AI 本身就是通过阅读大量代码和 Unix 文档长大的——Shell 脚本不是冰冷的命令，而是它最擅长的“母语”。

回到那个不等式：用 AI 工具 ≠ 个人提效 ≠ 组织提效。CLI vs MCP 的争论背后，真正的问题从来不是“哪个协议更好”，而是“你的工作方式有没有跟上工具的进化”。如果组织的节奏还是一周一评审、两周一合并、三层审批才能上线，那无论你用 CLI 还是 MCP，个人再快也会被流程卡住。

对大多数团队来说，最可控的路线往往是：

先用 CLI 把闭环跑通（带护栏），再用 MCP 把成熟能力产品化（可治理）。

工具是肌肉，协议是神经。先让肌肉动起来，再搭神经系统也不迟。

当你下一次准备“给 Agent 接一个工具”时，不妨先问一句：
这事写成一个靠谱的 CLI，能不能 30 分钟内跑起来？
如果能，那就先别急着建 server。

---

参考来源：

• X 原帖：https://x.com/mfranz_on/status/2021364017147818434

---

延伸阅读

想了解更多技术趋势和一线开发者的实践讨论？欢迎来 云栈社区 的开发者广场看看。