本文主要从 AI Coding Agent（Codex、Cursor、Claude Code 等）的角度，聊聊两者的区别，以及为什么我越来越喜欢 CLI + Skill 这种方案。

很多人第一次接触 Skill，会误以为它和 MCP 一样，是一种扩展能力。

实际上完全不是。

可以简单理解成：

Skill = 告诉 AI 应该怎么做

CLI/MCP = 真正帮 AI 去做

Skill 本质就是一个 Markdown。

例如：

当用户询问 React、Vue、TypeScript 等第三方库时：

1. 使用 ctx7 CLI 查询官方文档
2. 阅读返回结果
3. 总结回答

它不会联网。

不会执行代码。

不会调用 API。

它只是告诉模型：

遇到这种情况，请按照这个流程处理。

真正执行工作的，是后面的 CLI 或 MCP。

MCP（Model Context Protocol）更像给 AI 暴露了一组 Tool。

例如 Context7 MCP：

resolve-library-id
get-library-docs

模型调用：

get-library-docs("react")

MCP Server：

整个过程和调用 REST API 很像，只不过协议变成了 MCP。

所以：

MCP 提供的是能力，而不是工作流。

研究了一圈之后，我发现越来越多 AI 工具开始提供 CLI。

例如：

这些工具都有 CLI。

AI Agent 本身又已经拥有 Shell 能力。

于是整个流程变成：

User
    ↓
LLM
    ↓
Shell
    ↓
CLI
    ↓
stdout
    ↓
LLM

这条链路非常简单。

不需要额外实现协议。

这是我觉得最有意思的一点。

假设 Skill 写着：

如果用户询问任何第三方库：

执行：

ctx7 docs ...

以后我只需要问：

模型自己就会：

ctx7 docs react useEffect

然后读取结果回答。

整个过程，我甚至不知道它执行了命令。

这就是 Skill 的价值。

它改变的是模型的行为。

而不是增加一种能力。

很多人第一次看到 CLI + Skill，都会有一个疑问：

大模型怎么控制 CLI？

其实很简单。

假设模型决定执行：

ctx7 docs react useEffect

Agent Runtime 会真正启动一个 Shell：

ctx7 docs react useEffect

CLI 输出：

useEffect(...)
Runs after render...

Runtime 捕获：

• stdout
• stderr
• exit code

然后把 stdout 再交给模型。

于是模型继续推理：

整个过程其实就是：

LLM
    ↓
Shell
    ↓
CLI
    ↓
stdout
    ↓
LLM

没有任何魔法。

因为操作系统几十年前就已经帮我们定义好了。

所有 CLI 都遵循：

stdin
stdout
stderr
exit code

例如：

git
docker
npm
pnpm
ffmpeg
kubectl

AI Agent 只需要：

剩下的事情都是操作系统负责。

所以 CLI 天然就是一种标准接口。

如果做过 MCP Server，就会发现需要处理很多事情。

例如：

• Tool Schema
• 参数定义
• Tool 注册
• MCP 生命周期
• Tool 返回格式

还需要遵循 MCP 协议。

例如一个 Tool：

{
  "name": "get_positions",
  "inputSchema": {
    ...
  }
}

然后实现：

initialize

list_tools

call_tool

最后返回 MCP 格式的数据。

相比之下，CLI 几乎没有约束。

例如：

甚至输出 Markdown 都没问题：

# Weekly Report

## NVDA

收益：+3%

建议继续持有。

Skill 只需要告诉模型：

整个集成就完成了。

这是我最喜欢 CLI 的一点。

命令怎么设计完全由自己决定。

例如：

stock positions

stock analyze NVDA

stock weekly-report

stock export markdown

参数格式。

输出格式。

日志格式。

全部自己决定。

甚至输出：

• Markdown
• JSON
• HTML

都没有问题。

如果 AI 更适合读取 JSON：

stock weekly-report --json

如果方便人阅读：

直接输出 Markdown。

没有任何协议限制。

当然有。

MCP 更适合：

• 在线 API
• 登录认证
• 数据库
• 长连接
• 多 Tool 协同
• 状态管理

例如：

• GitHub
• Notion
• Longbridge
• Figma
• Slack

这些服务天然就是远程能力。

MCP 可以很好地统一它们。

而 CLI 更适合：

• 本地工具
• 开发工具
• 自动化脚本
• 一次性任务

对于 AI Coding Agent，我越来越喜欢下面这种结构：

                Skill
                  │
      决定什么时候执行
                  │
        ┌─────────┴─────────┐
        │                   │
      CLI                 MCP
        │                   │
   本地能力            远程能力

Skill 负责工作流。

CLI/MCP 负责真正执行。

两者其实不是竞争关系。

而是互补关系。

如果是个人项目或者开发工具：

优先做 CLI。

原因很简单：

• 开发成本低
• 调试方便
• 不需要学习 MCP 协议
• 能直接接入任何支持 Shell 的 AI Agent

以后如果需要支持 MCP，再基于 CLI 封装一层 MCP Server 即可。

这样既保留了 CLI 的灵活性，也兼容了 MCP 生态。

对于大多数开发者来说，这是投入产出比最高的一种方案。