CLI vs MCP：AI Agent 如何选择正确的工具

0｜基本信息

• 标题：CLI vs MCP: How AI Agents Choose the Right Tool for the Job
• 创作者：IBM Technology（官方技术频道）
• 发布时间：2026 年 5 月 4 日
• 视频背景：围绕 AI Agent 工具选择的争论——MCP（Model Context Protocol）是否是不必要的复杂度？用 CLI 是不是更轻量？

TL;DR｜核心结论

• CLI 赢在已知任务：文件操作、Git、文本处理——模型训练数据中已有海量 CLI 示例，零上下文开销
• MCP 赢在「工具-结果」之间有鸿沟的场景：JS 渲染页面（Next.js）、认证管理、权限控制、审计日志
• GitHub MCP Server 一次性加载 80 个工具 ≈ 55,000 tokens——如果只用其中 1-2 个，这笔 token 开销确实浪费
• 结论：两者互补，Agent 应按任务动态选择——CLI 走直达路径，MCP 走抽象路径

1｜核心观点

观点 1：CLI 在「模型已知的命令」上天然更优

• 支撑理由：模型在训练数据中看过海量的 CLI 示例（Stack Overflow、man pages、教程），已经”知道”cat、grep、git、curl 等命令及参数组合。不需要额外 schema 说明。
• 效率对比：读文件 + 搜索词，CLI 只需 cat notes.md && grep -n "agent" *.md。MCP 需加载 13 个工具的定义（~数千 tokens），实际只用了 2 个。
• 可信度：高，有具体实验数据支撑。

观点 2：MCP 在「CLI 力所不及」的场景下不可替代

• 支撑理由：获取 Next.js 页面内容时，curl 只返回 JS bundle 代码（纯 HTML skeleton），Agent 被逼到”逆向工程 Next.js 内部数据格式”的地步。而 MCP Fetcher server（headless browser）一键完成。
• 其他 MCP 优势场景：认证（OAuth token 管理）、组织级访问控制、审计日志——这些是 CLI “事后难以补充”的 governance 能力。
• 可信度：高。Demo 3 的 curl vs MCP fetcher 对比极其有说服力。

观点 3：MCP 的 token 开销是真实痛，但不是致命问题

• 支撑理由：GitHub MCP Server = 80 个工具 × 每个含 JSON schema 定义 ≈ 55,000 tokens。即使 Agent 只用其中 2 个，剩余 78 个仍然占用上下文窗口。
• 注意：这不是 MCP 协议本身的缺陷，而是粗粒度 server 设计的副产品。理论上可以将 server 拆分得更细（如 GitHub-Auth、GitHub-Repo、GitHub-PR 各一个 server）。
• 可信度：高。55K tokens = 实打实的 API 成本和上下文空间。

观点 4：Agent 的工具选择应该动态化——”如果 Agent 开始逆向工程 JS 框架，说明它选错了工具”

• 支撑理由：视频中同一个 Agent 同时使用了 CLI 和 MCP 来处理不同类型的任务。CLI 适用于 file ops / Git / text processing，MCP 适用于需要抽象、认证、JS 渲染的场景。
• 可信度：高。这是最务实的最佳实践。

2｜话题分析

话题 1：三个演示实验的技术细节

实验 1 — 文件操作 | 维度 | CLI | MCP | |——|—–|—–| | 命令/工具 | cat notes.md + grep -n "agent" *.md | read_file() + search_files() | | 上下文开销 | 0（模型已知） | ~2,000 tokens（13 个工具定义） | | 结果 | ✅ 成功，紧凑 | ✅ 成功 | | 胜出 | CLI（更高效） | |

实验 2 — Git 操作 | 维度 | CLI | MCP | |——|—–|—–| | 命令/工具 | git log --oneline -10 + git status | GitHub MCP Server × 80 tools | | 上下文开销 | 0 | ~55,000 tokens | | 结果 | ✅ 成功 | ✅ 成功 | | 胜出 | CLI（token 开销小太多） | |

实验 3 — 获取网页内容（modelcontextprotocol.io） | 维度 | CLI | MCP | |——|—–|—–| | 命令/工具 | curl -s URL \| head -200 | Fetcher MCP Server → fetch_url() | | 尝试次数 | 5+ 次（试了 curl→strip HTML→JSON→Python） | 1 次 | | 耗时 | 几分钟 + 2,000+ tokens | 几秒 + ~250 tokens | | 结果 | 勉强成功，过程痛苦 | ✅ 干净利落 | | 胜出 | MCP（压倒性） | |

话题 2：MCP 的治理优势——组织级部署的关键考量

作者指出 MCP 在以下方面有结构性优势：

• 认证管理：MCP Server 处理 OAuth/token，Agent 只需说”做什么”；CLI 需要 Agent 自己管理 token 刷新
• 权限控制：per-user access control，无需共享凭证
• 审计追踪：协议层面内置可追溯性——谁、什么时间、调用了哪个工具、参数是什么
• 这些是 CLI 体系”事后很难补”的能力

话题 3：社区争议的真相——MCP 是否过度工程化？

作者承认 MCP 批评者的核心论据成立（token 开销、已有 CLI）、但也指出批评者忽略的场景（JS 渲染、认证治理）。结论是「两派都对了一部分」。

3｜关键数据

4｜可操作信息

1. 如果你在构建 AI Agent 并纠结 MCP vs CLI → 两个都给。让 Agent 按任务类型自行选择：已知的、可直接操作的命令走 CLI；需要抽象/渲染/认证/治理的场景走 MCP。
2. MCP Server 设计应追求「粒度适中」。GitHub 80 个工具塞一个 server 太粗了。理想粒度：每个 server 暴露 5-15 个工具，按领域拆分（GitHub Issues、GitHub Repo、GitHub Auth）。
3. JS 渲染场景是 CLI 的致命弱点。如果你的 Agent 需要大量处理 web 内容（SPA、SSR 页面），MCP Fetcher + headless browser 是必须的。curl + 正则解析遇到现代 JS 框架几乎是死路。
4. 监控 Agent 的「工具退避策略」——如果 Agent 开始写 Python 脚本去逆向工程 API 内部数据格式，说明当前工具集不适合该任务。这是 MCP 切换的天然触发信号。

5｜一句话总结

CLI 是 AI Agent 的「肌肉记忆」——快、省、不必思考；MCP 是「外接大脑」——慢一点但能处理 CLI 搞不定的事；好 Agent 两者都用，按需切换。