MCP 太重时，Skill + CLI 可以顶上一部分场景

围绕 MCP 有一个很常见的观点：MCP Server 需要部署、协议适配、工具描述、鉴权、权限控制和治理，很多任务用 CLI 就能完成，再用 Skill 把流程组织起来，成本更低。

这个观点有很强的工程现实感。

很多本地任务本来就有成熟 CLI。比如测试、构建、格式化、静态检查、Markdown 转换、图片压缩、日志解析。Agent 直接调用命令行，拿退出码和标准输出判断结果，确实比写一个 MCP Server 轻很多。

但 Skill + CLI 覆盖的是一类场景，MCP 覆盖的是另一类场景。它们之间的差异不在“谁更先进”，而在工具半径不同。

方案	更适合解决	核心价值
CLI	一个动作怎么稳定执行	确定性、本地友好、容易调试
Skill	一类任务怎么按流程完成	复用经验、组织步骤、统一输出
MCP	外部能力怎么被多个 Agent 接入	标准化连接、工具发现、生态复用

轻量场景里，Skill + CLI 很好用。工具数量多、接入方多、跨系统复用需求强时，MCP 的价值会重新出现。

各自的特色

MCP 的目标是让 AI 应用通过统一协议接外部工具。这个方向很适合工具生态化，但它也会带来额外工程成本。

接一个 MCP Server，至少要考虑这些事：

• Server 怎么启动。
• Host 怎么连接。
• 工具描述怎么写。
• 参数 Schema 怎么维护。
• 鉴权怎么做。
• 权限怎么收口。
• 调用日志怎么记录。
• 错误怎么标准化返回。

对企业工具平台来说，这些都值得做。对一个本地 Markdown 检查、代码格式化、测试执行任务来说，这套东西很容易显得偏重。

CLI 的优势正好在这里。很多开发工具天然就是命令行接口：

npm test
pytest
ruff check .
eslint .
tsc --noEmit
markdownlint README.md
git diff --stat

这些命令已经有稳定输入、稳定输出、退出码、日志和 CI 集成方式。Agent 通过 shell 调用它们，再根据结果继续判断，就能完成很多确定性任务。

Skill 在这里补上另一层能力：它告诉 Agent 什么时候调用这些 CLI、按什么顺序调用、结果怎么判断、最后怎么输出。

所以这场争论可以拆成一句话：

Skill + CLI 的优势在轻量和确定性，MCP 的优势在标准化连接和生态复用。

CLI 的优势：确定性动作

CLI 是最成熟的自动化接口之一。

它适合 Agent 调用，主要有几个原因。

能力	CLI 的优势
输入明确	参数、文件路径、环境变量都比较清楚
输出明确	标准输出、错误输出、退出码可判断
容易调试	人可以直接在终端复现
容易组合	Shell、脚本、CI 都能串起来
成本低	不需要单独部署协议服务
本地友好	文件处理、构建、测试天然适配

比如一次 Python 项目检查，可以直接走：

ruff check .
pytest
mypy .

Agent 不需要理解 ruff 内部怎么工作，只需要知道：

• 命令怎么运行。
• 退出码是否为 0。
• 错误输出里有哪些文件和行号。
• 修复后是否需要重跑。

这就是 CLI 的确定性。它把一个动作压成了稳定接口。

很多任务如果只需要“执行一个动作并读取结果”，CLI 会比 MCP 更直接。

CLI 的短板：它只管动作

CLI 擅长做动作，但它不理解任务目标。

pytest 只负责跑测试。它不知道当前任务是修 bug、补功能、发版前检查，还是做一次代码审查。

markdownlint 只负责检查 Markdown。它不知道这篇文章准备发到知乎、CSDN，还是内部知识库。

git diff 只负责展示变更。它不知道哪些变更需要重点审查。

所以 CLI 需要一个上层流程来组织。

这正是 Skill 的位置。

Skill 在这里补的，是流程

Skill 可以把多个 CLI 动作组织成一个任务流程。

比如一个“发布前检查”Skill，可以这样设计：

1. 接收文章路径
2. 调 markdownlint 检查 Markdown 格式
3. 调自定义脚本检查标题、图片、本地路径
4. 调转换脚本生成发布正文
5. 汇总错误和警告
6. 严重错误直接停止
7. 通过后输出发布前检查报告

这里 CLI 负责确定性动作：

markdownlint article.md
node check-local-images.js article.md
node export-publish-body.js article.md

Skill 负责流程规则：

• 哪些命令先跑。
• 哪些错误算阻断。
• 哪些警告只提示。
• 输出报告长什么样。
• 哪一步需要人工确认。

可以把三层关系看成这样：

层	作用
Agent	理解用户目标，选择合适能力
Skill	规定任务流程、判断规则和输出格式
CLI	执行确定性动作并返回结果

这个组合很适合内部工作流。尤其是流程固定、动作确定、输入输出明确的任务。

Skill + CLI 适合哪些场景

Skill + CLI 适合本地、确定性、内部流程型任务。

典型场景包括：

• 代码格式化。
• 静态检查。
• 单元测试。
• 构建前检查。
• Markdown 转换。
• 图片压缩。
• 日志解析。
• 数据清洗。
• 发布前检查。
• 本地文件批处理。

这些场景有共同特征。

特征	说明
输入输出明确	文件、参数、退出码都能判断
环境可控	多数在本机、仓库或 CI 里执行
权限简单	主要操作本地文件或已授权资源
复现方便	人可以在终端手动运行
流程稳定	适合写成 Skill 步骤

这里用 MCP 也能做，但经常会显得绕。

比如只是检查一个 Markdown 文件，直接执行：

markdownlint article.md

再让 Skill 解释结果就够了。为它单独包一层 MCP Server，收益并不明显。

MCP 适合哪些场景

MCP 的优势在工具连接和生态复用。

当工具变成远程系统、共享系统或多应用复用能力时，MCP 会更合适。

典型场景包括：

• GitHub。
• Jira。
• 数据库。
• 企业知识库。
• 浏览器自动化。
• 云服务控制台。
• 监控系统。
• 内部业务系统。

这些场景有几个特点：

特征	MCP 的价值
多个 AI 应用要接同一工具	统一封装一次，多处复用
工具需要被发现和描述	Server 可以暴露工具列表和 Schema
需要统一鉴权	Server 侧集中处理认证和授权
工具状态复杂	Server 可以维护会话和连接
团队需要治理	工具描述、版本、权限、审计可以集中管理

比如 GitHub 场景。

如果只是本地看 diff，CLI 很方便：

git diff
git log --oneline

但如果要获取 PR 评论、CI 状态、Issue 关联、Review 记录，再把结果写回 GitHub，MCP Server 会更合适。它可以把 GitHub API、鉴权、分页、错误处理、返回格式统一封装起来。

这时 MCP 的价值不在“执行一个命令”，而在“把一个外部系统稳定接进 Agent 环境”。

关键区别：工具半径不同

CLI、Skill、MCP 的差异，可以用工具半径来理解。

方案	半径	关心的问题
CLI	单机 / 脚本半径	这个动作怎么稳定执行
Skill	任务流程半径	这类任务怎么按步骤完成
MCP	工具生态半径	外部能力怎么被多个 Agent 统一接入

CLI 解决动作确定性。

Skill 解决经验复用。

MCP 解决工具接入标准化。

真实项目里，它们经常组合使用：

用户目标
-> Agent 选择 Skill
-> Skill 调 CLI 做本地检查
-> Skill 通过 MCP 调远程工具
-> Agent 汇总结果并给出下一步

把三者放在同一层比较，容易得出偏激结论。放到不同层后，边界会清楚很多。

一个例子：代码审查

假设要做一个代码审查 Agent。

只做本地审查时，Skill + CLI 很够用。

Skill 规定流程：

1. 读取当前 diff
2. 识别改动文件
3. 运行静态检查
4. 运行相关测试
5. 汇总风险
6. 输出 review 报告

CLI 执行动作：

git diff
npm test
eslint .
tsc --noEmit

这种情况下，CLI 的输出已经足够稳定。Skill 负责把这些动作组织起来，Agent 负责解释结果和提出建议。

如果审查要接 GitHub PR，情况就变了。

它可能需要：

• 获取 PR 标题和描述。
• 获取评论线程。
• 获取 CI 状态。
• 查询关联 Issue。
• 写回 Review 评论。
• 读取仓库权限。

这些动作跨越远程系统、鉴权、分页、写操作和审计。用 MCP Server 封装 GitHub 能力，会比散落的一堆 CLI 命令更稳。

所以同一个“代码审查”任务，轻量版本可以 Skill + CLI，平台化版本更适合 Skill + MCP + CLI。

一个判断矩阵

做方案时，可以先问几个问题。

问题	更倾向
只是处理本地文件	CLI
只是跑测试、构建、格式化	CLI
需要把多个命令组织成流程	Skill + CLI
需要复用团队经验和输出格式	Skill
需要接远程系统	MCP
多个 AI 应用要复用同一工具	MCP
需要统一鉴权和审计	MCP
一类任务同时需要本地检查和远程查询	Skill + CLI + MCP

这个矩阵比“谁替代谁”更实用。

我的判断

Skill + CLI 确实能顶上一部分 MCP 需求。

尤其是本地、确定性、团队内部的自动化流程，Skill + CLI 往往更轻、更稳、更容易调试。文件处理、代码检查、测试、构建、发布前检查，都可以优先从这条路线开始。

但这种替代有前提：

• 工具主要在本地。
• 调用方比较少。
• 权限边界简单。
• 输入输出稳定。
• 跨应用复用需求不强。

一旦工具变成远程服务，多个 Agent 应用都要接，或者需要统一鉴权、工具发现、权限治理和审计，MCP 的价值会重新出现。

所以我更倾向于把三者放在不同层：

层级	方案	作用
动作层	CLI	稳定执行一个具体动作
流程层	Skill	组织一类任务的执行顺序和判断规则
连接层	MCP	把外部系统标准化接进 Agent

轻量场景先用 Skill + CLI。工具生态扩大、共享需求增强、权限治理复杂后，再引入 MCP。

这条路线也更符合工程演进：先用最简单的方式跑通确定性动作，再把重复流程沉淀成 Skill，最后把跨系统、跨应用的能力上升为 MCP Server。