MCP与CLI：AI执行层正在CLI化，MCP只做插头

「MCP 已死，CLI 称王」——话太满，但方向不算错。

我 Cursor 里仍挂着 GitHub MCP，终端里也天天 gh。感受是：MCP 和 CLI 都会长期存在；而在「Agent 真正动手」这一层，CLI 正在变成更占优的默认选项——所以你看到一堆产品主动 CLI 化：不是抛弃智能，而是把执行层改回命令行擅长的形状。

下面用 MCP × CLI（GitHub 上即 GitHub MCP × gh）把趋势、分工和边界说清楚。

为什么 AI 产品开始 CLI 化

大模型本质是 文本进、文本出；命令行也是 文本进、文本出。GUI 要截图、点按钮、猜布局；CLI 用 help、man、管道，和 Agent 同构。这不是怀旧，是 工程上更贴 Agent 的默认接口。

近一年里「把产品做成 CLI」的例子很集中：

• GitHub：gh 本来就有；又推 Copilot CLI，和 IDE 里的 Agent 同一套肌肉
• Anthropic：Claude Code——对话外壳，执行落在终端
• OpenAI / 社区：ChatGPT CLI、各类 coding agent 终端入口
• Google：gws CLI 管 Workspace
• 飞书：开源 CLI，200+ 指令，和 Agent Skills 一起卖
• Perplexity：CTO 公开讨论在生产里 减少 MCP、加大 API + CLI——争议点正是「执行层别再用胖 MCP 扛一切」

所以在Cursor中你用的 /pr-review-canvas、/issue_to_fix_workflow 体验上可以挂在 MCP 生态里，但 Skill 里写明的往往是 gh pr diff、gh issue view——产品表面 MCP 化，执行层却在 CLI 化。这不是矛盾，是分层：MCP 管入口和目录，CLI 管高频动手。

当下 Agent 里，CLI 为什么更占优

相对「会话开始就加载几十个 MCP tool Schema」，CLI 在 AI 应用里有几条硬优势：

省上下文（钱和智商一起省）
GitHub MCP 我本地 42 个 tool，描述约 47KB（粗算 ~1.2 万 token）。一次 merge 可能只用 3 个，其余 push_files、run_secret_scanning 等仍占着窗口。社区里多 Server 叠加时出现 70%+ 上下文被 tool 文档吃掉、工具选择准确率 掉到 14% 以下，并不意外。
gh pr checks 128 则不必预付 gh release 的说明书——按需 help。

可组合、可复跑
gh pr diff | …、git 管道，人和 Agent 复制同一条命令就能重跑。MCP 路径多一层 JSON 是否拼对，调试成本更高。

训练与生态
模型在 man、Stack Overflow、shell 脚本上练得多；gh 是 GitHub 官方 CLI，和「让 Agent 用熟工具」一致。

认证与合规
gh auth login 一次，人机共用；企业审计对「终端里跑了什么」也熟。MCP 常是每个 Server 一套 PAT，Server 越多越碎。

因此：不是 MCP 不能做这些事，而是同样的事用 MCP 做往往更贵、更脆、更难查——在「执行层」这一棒，CLI 当前明显更占优。

MCP 没退场：它更适合另一层

MCP 的价值要放在 「协议 / 插头 / 能力目录」，而不是和 CLI 抢每一次 merge。

• 跨客户端统一：同一 GitHub Server 给 Cursor、Claude Desktop 用——工具发现、能力声明
• 人主要在对话窗、少切终端：issue_write、create_pull_request、get_file_contents
• 跨 repo / 组织检索：search_code、search_pull_requests——不必先拼一长串 shell
• 复杂 API 一次 Structured 调用：pull_request_read 带 get_review_comments、分页等
• MCP Prompt 编排：如 issue_to_fix_workflow——流程入口在协议层，步骤里仍可调用 gh

MCP 被说「喂胖」，通常是因为 用 MCP 承担了 CLI 更擅长的执行层：每天本地的 list PR、看 CI、merge 都走 merge_pull_request，等于高频动作也为 42 个 tool 买单。

仍值得用 MCP 的场景：

怎么选：CLI 优先，MCP 补位

• 动作是否每天都在本机仓库发生？ 是 → CLI（gh）优先；只读远端、跨 repo → MCP 补上。
• 要不要给人一条可复制命令？ 要 → CLI；只在 IDE 里点一次、参数极多 → MCP 可更稳。
• 会话已挂多少 MCP Server？ 越多 → 越应把高频执行迁到 CLI，给上下文减负；检索类仍可留给 MCP。

认证也各有利弊：gh auth 适合「我就是这台机器上的开发者」；MCP PAT/OAuth 适合「IDE 内统一接入、多 Server 各管各的」——企业里两种都会并存。

如下是Cursor结合了GitHub MCP和GitHub gh两种模式下直接修复GitHub Issue以及对已知PR的评审，可以说是很好的诠释了两者都有各自的应用场景。

我现在的做法

• 执行默认 gh：PR、CI、merge、本地 diff；规则里限制 Agent 为这类动作乱点 merge_pull_request。
• MCP 收窄：跨 repo 搜索、远端读文件、对话里开 issue；GitHub MCP 留着，不承包执行层。
• Slash / Canvas 照用：接受「入口在 IDE、干活在终端」的产品形态——这和行业 CLI 化一致。
• 减 Server 数量：比换更大模型便宜；把 MCP 当 插头，不当 唯一的手。

MCP 与 CLI 都会长期并存；趋势是 AI 应用在执行层更偏向 CLI——省 token、好调试、好组合、产品也在跟着 CLI 化。

MCP 没死，但在分工上更像 标准化插头 + IDE 内能力目录；和 CLI 抢的是层，不是命。真正要避免的，是用 MCP 做 gh 每天都做、且做得更好 的事——那不是否定 MCP，而是 把 MCP 从「胖执行层」放回「合适的层」。

你若是做 Agent 产品，可以自问：对外是卖 40 个 MCP tool，还是卖一条 gh pr 级别的 CLI + 少量 MCP 插头？ 行业里越来越多人选后者。