作者：小枫
关注公众号：weelinking | 访问官网：weelinking.com

前言

在 AI Agent 工具化的实践中，一个有趣的现象正在发生：当行业还在热议 MCP（Model Context Protocol）标准化时，一线开发者已经开始用脚投票——回归 CLI（Command Line Interface）。

这不是技术的倒退，而是对"效率本质"的重新思考。

快手万人研发团队的数据揭示了一个关键矛盾：AI 代码生成率从 1% 提升到 30%+，个人体感效率提升 20%–40%，但组织整体的需求交付效率基本没变。他们总结出一个不等式：

用 AI 工具 ≠ 个人提效 ≠ 组织提效

这个不等式同样适用于工具层选择。MCP 的 schema 写得再规范、catalog 梳理得再齐整，如果它没有缩短"需求到上线"这条链路，那它只是在中间加了一站，而不是修了一条高速公路。

本文将系统性地回答四个问题：

1. 这场争论的本质是什么（不只是技术选型）
2. CLI 为什么对 LLM/Agent 如此友好
3. MCP 的价值边界在哪里（别把它写死）
4. 如何落地"先 CLI，后 MCP"的工具化路线

💡 国内怎样才能流畅的上手使用 Claude： weelinking，weelinking

---

一、争论的起源：一条六万浏览的长推

2026 年 2 月 11 日，Marco Franzon（Docker Captain 社区成员、eXact-lab 计算机视觉专家）发布了一条长推，核心观点直击痛点：

“CLI Is All You Need”

六万次浏览，评论区几乎一边倒。他的观点很直接：

• MCP 想把"工具调用/资源访问"标准化，让 Agent 通过统一协议去发现与调用能力
• 但对于大多数日常开发任务（改代码、跑测试、修 bug），这套标准化常常来得太早、太重
• 更短的路径是：把 Agent 放进项目目录，给它受控的 shell 执行权限，让它使用几十年来最成熟的工具链

他用一句话概括这种取舍：

“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 对 Agent 友好的三大核心优势

2.1 自描述：--help 就是零配置的 Prompt

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

Peter Steinberger 在 OpenClaw 开发中观察到一个现象：

智能体拿到新工具后，会自发运行 my-tool --help，然后仅仅通过阅读帮助文档，在那一秒钟内就学会了如何操作这个工具。

把 --help 当成 Prompt，你会发现它天然具备：

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

示例对比：

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

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

2.2 可组合：Unix 管道与 LLM 思维链的天然契合

CLI 的默认 I/O 模型是 stdout/stderr + exit code，对 Agent 来说非常"工程化"：

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

管道式的链式组合，与智能体的**思维链（Chain of Thought）**逻辑高度契合：

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

这种原子化工具的组合能力，恰恰是 MCP 体系里最容易被稀释的部分。

2.3 低摩擦：前沿模型针对 Shell 深度训练

Marco Franzon 特别提到：

前沿模型（Claude、GPT 变体、Gemini）都针对 Shell 使用进行了大量训练。它们对参数（Flags）、管道、错误信息和 Man 手册风格的文档理解得异常透彻。

对 Agent 来说，Shell 不是冰冷的命令，而是它最擅长的"母语"。

---

三、典型场景对比：CLI 何时更高效

Marco 在原帖中列举了四个高频研发任务，展示了 CLI 的"最短路径"优势：

场景 1：Monorepo 全局重构

# 定位 → 批量改动 → 审查 → 测试
rg "OldClassName" -l . \
  && sed -i 's/OldClassName/NewClassName/g' **/*.ts \
  && git diff \
  && npm test

无需 GitHub MCP 服务器，无需臃肿的上下文，只有 rg、git 和测试运行器。

场景 2：生产 bug 排查

# 实时日志 → 探测端点 → 拉依赖 → 针对性修改
tail -f /var/log/app.log \
  && curl -v https://api.example.com/health \
  && docker-compose up -d \
  && vim src/controller.ts

无需 Docker MCP，无需日志 MCP，只需精通 Shell。

场景 3：脚手架式新服务

# 初始化 → 安装依赖 → 边跑边修
cargo new my-service \
  && cd my-service \
  && cargo add tokio \
  && cargo run

无需 Rust MCP，无需数据库 MCP，现有工具链已经足够。

场景 4：CI/CD 抖动修复

# 本地复现 → 定位失败点 → 改配置 → 验证
docker run --rm -v $(pwd):/workspace ci-image \
  && vim .github/workflows/ci.yml \
  && act push

全是标准 CLI 工具，无需定制 CI 集成层。

---

四、MCP 的价值边界：什么时候才该上协议

4.1 三个维度决定是否需要 MCP

我用一个更直白的分界线：当你开始需要"治理"，MCP 才开始划算。

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

4.2 MCP 无法替代的三大能力

1. 发现机制：从"盲摸"到"自报家门"

• CLI 模式：Agent 必须预先知道命令名。环境里有几百上千个内部工具时，会导致严重的 Context 溢出和注意力稀释
• MCP 模式：拥有标准的 **Discovery（发现）**机制。Server 会主动上报"能力清单"，机器与机器之间的元数据对齐比"瞎撞"高效得多

2. 资源抽象：从"一次性动作"到"长效资源"

• CLI 的本质是"工具"：瞬时的、原子化的动作
• MCP 引入"资源"：将持续更新的数据库表、实时日志流、远程设备状态抽象为 URI。还可以为资源提供"动态提示词模板"——不仅给数据，还告诉 AI “针对这组数据，应该关注哪些风险点”

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

• CLI 的风险：赋予 Agent Shell 权限，可能因为幻觉运行 rm -rf /
• MCP 的护城河：
  • 代理（Proxy）架构
  • 精细权限——只读/只写分离
  • 跨宿主复用——一次编写，无缝挂载到 Claude 网页版、Cursor、自建机器人

4.3 协议还在进化：WebMCP 的启示

2026 年 2 月 14 日，Google 和 Microsoft 联合发布 WebMCP 早期预览，目标是把每个网站变成 AI Agent 可调用的 API。

Chrome for Developers 官方说明：

“WebMCP 旨在提供一种标准方式来暴露结构化工具，确保 AI Agent 能以更快、更可靠、更精准的方式在你的站点上执行操作。”

这说明 MCP 的理念不仅没有消亡，反而在向更广的生态渗透。

---

五、AI-Native CLI 的设计原则

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

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

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

• 语义明确的参数描述（尤其是副作用参数，如 --force、--dry-run）
• 2–6 个高质量示例（覆盖常见路径 + 边界）
• 输出格式说明（默认 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

5.2 默认非交互：交互是 Agent 的"卡死点"

尽量别让命令停在：

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

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

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

5.3 可机读输出：--json 是稳定性的底座

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

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

并且约定：

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

5.4 稳定的 exit code：别让模型猜"是不是失败"

建议约定：

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

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

5.5 幂等 + --dry-run：让"试一次"变得安全

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

最低配建议：

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

---

六、"给 Shell 权限"的护栏设计

很多人听到"直接给 Agent shell"，第一反应是"这不就是把核按钮交出去？"

这个担心完全合理。但现实里我们并不是在两种极端之间选：

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

更务实的做法是：CLI + 护栏。

Marco Franzon 在原帖里给了一句关键的限定词：with safeguards（带安全防护）。

有效的护栏组合

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

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

---

七、一张决策树：先 CLI，什么时候再上 MCP

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

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

核心三问：

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

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

---

八、给不同读者的落地建议

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

• ✅ 先把你的"重复劳动"做成 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，个人再快也会被流程卡住。

最务实的路线

对大多数团队来说：

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

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

---

最后一句话

当你下一次准备"给 Agent 接一个工具"时，不妨先问一句：

这事写成一个靠谱的 CLI，能不能 30 分钟内跑起来？

如果能，那就先别急着建 server。

📌 系列导航： 产品经理用 Claude 实现产品 · 系列目录

💡 先把claude的用起来吧： weelinking - 完美支持 Skills 功能

---

🌟 觉得有帮助？点赞 + 收藏 + 关注，不错过更多 AI 实用技巧！