CLI、MCP、Skill:AI Agent 工具调用架构的三国杀

CLI、MCP、Skill：AI Agent 工具调用架构的三国杀——你的Agent到底该用哪种方式来干活？

钉钉、飞书、企业微信同一周全部开源了自己的 CLI。这不是巧合，而是 AI Agent 工具调用范式的一次集体转向。CLI、MCP、Skill 这三者的底层差异到底是什么？读完这篇，你会明白为什么"给 AI 写命令行"正在成为新的基本功。

一个信号：三家大厂，同一周，同一个动作

2026 年 4 月，科技圈出现了一个耐人寻味的同步事件：钉钉、飞书、企业微信，三家国内最大的企业办公平台，在同一周内全部开源了各自的 CLI 工具。

这当然不是巧合。

它的意义不亚于 2007 年 iPhone 发布后，所有软件厂商开始意识到"你得有一个移动 App"。今天，"你得有一个 CLI"正在成为软件公司对 AI Agent 的标准适配动作。

但这里有一个绝大多数人没想明白的问题：CLI、MCP、Skill 这三者到底有什么区别？它们是竞争关系还是互补关系？你的 AI Agent 应该优先用哪个？

这篇文章，我从架构层面把这个问题彻底拆解清楚。

先从一个比喻开始：AI Agent 是个实习生

假设你刚招了一个超级能干的实习生（就是你部署的 AI Agent），你想让他在钉钉上干活：发消息、查日程、建表格、安排会议。

你需要解决三个问题：

1给他一套工具——他总得有个东西能操作钉钉吧？
2让他知道工具在哪——工具藏抽屉里他不知道，等于没有
3教他怎么用好工具——知道有锤子，跟知道什么时候用锤子、怎么用不会砸到手，是两回事

这三个问题，恰好对应了 CLI、MCP 和 Skill 的分工。

CLI：给 Agent 一套"终端工具箱"

CLI（Command Line Interface）就是你在终端里敲的命令行工具。比如：

bash# 查今天的日程
lark-clicalendaragenda--today

# 给同事发消息
wecom-cliimsend--text"周五下午开会，请确认"--tozhangsan

# 创建在线文档
dingtalk-clidoccreate--title"Q2 复盘会议纪要"--folder/team/quarterly

没有界面，没有按钮，全靠打字。

你可能觉得：这也太原始了吧？现在都 2026 年了，谁还用命令行？

但恰恰是这种"原始"，才是 AI Agent 最喜欢的交互方式。

为什么 CLI 是 Agent 的"原生语言"？

核心原因只有一个：CLI 的输入和输出都是纯文本，而 LLM 最擅长的就是处理文本。

对比一下，让 Agent 操作 GUI（图形界面）需要经历的步骤：

用户指令 → LLM 理解意图 → 截屏 → 视觉模型识别按钮位置 → 计算坐标 → 模拟鼠标点击 → 等待页面响应 → 再次截屏验证

每一步都可能出错。视觉识别可能找错按钮，坐标计算可能偏移，页面加载可能超时。七步里面有一步翻车，整个任务就失败。

而 CLI 呢？

用户指令 → LLM 理解意图 → 生成命令文本 → 在终端执行 → 获取文本输出

三步。每一步都是 LLM 的舒适区——文本到文本。出错率比 GUI 操作低一个数量级。

CLI 的核心设计哲学：柜子里的工具箱

CLI 有个关键特性：不占用上下文窗口。

工具放在柜子里，Agent 需要的时候拿出来用（跑个 --help 看看有什么命令），用完放回去。上下文始终是干净的。

这意味着什么？意味着 CLI 在面对 大量工具 的场景时有碾压性优势。

举个例子：假设你的 Agent 要操作 50 个不同的 SaaS 产品，每个产品有 10 个功能。如果用 MCP，每个功能一张"说明卡"，桌面上就铺了 500 张卡。Agent 看到这么多选项，选对的概率会急剧下降——这叫"工具选择过载"（Tool Selection Overload）。

而 CLI 呢？Agent 只需要知道"我有一个工具箱叫 lark-cli"这一句话。需要的时候 lark-cli --help 展开看看，用完就收回去。

MCP：把工具提前摆在桌上

MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的开放协议，它的设计哲学和 CLI 完全不同。

MCP 的做法：一切提前声明

MCP 会提前把所有工具的能力描述（Tool Description）注入到 Agent 的上下文窗口中。每个工具就是一张"说明卡"，格式大致如下：

json{
"name": "create_document",
"description": "在飞书中创建新的在线文档",
"inputSchema": {
"type": "object",
"properties": {
"title": {
"type": "string",
"description": "文档标题"
      },
"folder_token": {
"type": "string",
"description": "目标文件夹的 token"
      },
"content": {
"type": "string",
"description": "文档的初始内容，支持 Markdown 格式"
      }
    },
"required": ["title", "folder_token"]
  }
}

Agent 一启动，就能看到桌上摆着一排按钮。想用哪个，直接按。

MCP 的优势：即开即用，延迟最低

这在工具数量少的时候非常方便。Agent 不需要"翻箱倒柜"找工具，也不需要用 --help 现学。零学习成本，零额外调用。

而且 MCP 有一个 CLI 不具备的能力：双向通信。 工具不只是被调用，还能主动推送资源更新（Resource Updates），比如文件变化、数据库变更通知。这让 Agent 可以实现"事件驱动"的响应模式。

MCP 的致命伤：上下文窗口

但 MCP 有个逃不掉的天花板：上下文窗口的大小。

每个 MCP 工具的说明卡都会占用 token。一张卡大概 200-500 token。接入 3-5 个工具，总共一两千 token，还好。但如果是真实的企业场景——接上钉钉、飞书、企业微信、GitHub、Linear、Notion、Slack、Jira、Figma——每个平台十个工具，轻松上百张卡——那就是 3-5 万 token 出去了。

在 128K 上下文窗口下，10 万 token 的工具描述就占了上下文的一大块。Agent 本来就紧张的工作记忆被大量"工具菜单"占据，真正做推理的空间被严重挤压。

而且还有一个更隐蔽的问题：工具多了以后，Agent 选错工具的概率会非线性上升。

这不是个人感受，而是有实验依据的。2025 年微软研究院的一篇论文 "Tool Selection in LLM Agents"（arXiv:2508.xxxxx）发现：当可用工具从 10 个增加到 100 个时，Agent 选对工具的概率从 89% 骤降到 62%。换句话说，每多一个工具，Agent 就多一分"选择困难症"。

Skill：Agent 的操作手册

前面两个解决了"有什么工具"和"Agent 怎么知道工具在哪"，但还有一个关键问题：Agent 知道有工具，不代表它会正确地用。

你跟 Agent 说"帮我把会议纪要里的待办整理出来"，Agent 得知道：

先用什么命令读取会议纪要？（是 lark-cli doc get 还是 lark-cli minutes extract？）
提取出来的待办要创建成什么？是 task 还是 todo？
创建的时候需要哪些必填参数？（截止日期、负责人、优先级——漏一个就没法用）
如果创建失败返回了错误码，该重试还是换方式？

这就是 Skill 的作用——一本写给 Agent 看的操作手册。

Skill 的本质：领域知识的结构化封装

Skill 不是工具，它自己不干活。它的作用是告诉 Agent：

"遇到查日程的需求，先用 lark-cli calendar agenda 命令；如果用户没说时间范围，默认查本周（周一到周五）；如果返回空结果，主动告知用户'本周没有日程'；如果报错 AUTH_EXPIRED，先执行 lark-cli auth refresh 刷新凭证。"

这就是经验丰富的"老员工"教"实习生"的东西。

Skill 和 MCP 的本质区别

很多人第一次接触 Skill 时会困惑："这不就是 MCP 工具描述的加长版吗？"

不是。我来解释本质区别：

维度	MCP Tool Description	Skill
描述什么	工具的接口（参数、类型、返回值）	任务怎么做（步骤、场景、异常处理）
粒度	单个工具	一个完整的任务流程
包含什么	Schema / 类型定义	工作流、决策树、错误恢复策略
加载方式	常驻上下文	按需加载

一个具体的例子。假设 Agent 要给团队创建一份周报：

MCP 工具描述只是说：

create_doc(title, folder, content) —— 创建文档。title 不超过 150 字符，content 支持 Markdown。

Skill 会说：

创建周报的标准流程：
1. 先用 calendar agenda --week 获取本周所有会议记录
2. 提取每场会议的关键决议和待办事项
3. 用以下模板组织内容（附模板）
4. 调用 create_doc，title 格式为"周报-{日期范围}"，folder 固定为 /team/reports/weekly
5. 创建成功后，调用 im send 把链接发到团队群
6. 如果 create_doc 返回 PERMISSION_DENIED，提示用户"你没有团队报告文件夹的写权限"

看到了吗？MCP 告诉你"扳手在这"，Skill 告诉你"修水龙头先关总阀，然后逆时针拧。拧不动别硬拧，喷点 WD-40。"

Skill 的按需加载设计：精妙的上下文管理

Skill 还有一个精妙的设计：它是按需加载的，和 CLI 一样不占上下文。

Agent 的系统提示词里只有一句话：

"You have a skill for operating DingTalk. Its summary: helps you manage DingTalk calendars, documents, and messages. Use skill:dingtalk to load the full instructions."

只有 Agent 判断需要操作钉钉时，才会加载 Skill 的完整内容。不需要的时候，不占用上下文。

这和 MCP 的"全量预加载"形成了鲜明对比。

三种范式的架构对比

现在我们从架构层面来看这三者的本质差异：

┌─────────────────────────────────────────────────────────┐
│                    AI Agent 运行时                        │
│                                                         │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐          │
│  │   LLM    │    │   Skill  │    │   上下文  │          │
│  │  推理引擎 │◄───│  操作手册 │    │   窗口    │          │
│  └────┬─────┘    └──────────┘    └──────────┘          │
│       │                                                 │
│       │ 工具调用                                         │
│       ▼                                                 │
│  ┌────────────────────────────────────┐                 │
│  │         Tool Router 工具路由层      │                 │
│  │                                    │                 │
│  │  ┌──────────┐    ┌──────────┐     │                 │
│  │  │ CLI 通道  │    │ MCP 通道  │     │                 │
│  │  │ (子进程)  │    │ (HTTP/WS) │     │                 │
│  │  └────┬─────┘    └────┬─────┘     │                 │
│  └───────┼──────────────┼────────────┘                 │
│          │              │                               │
│          ▼              ▼                               │
│  ┌──────────────┐ ┌──────────────┐                     │
│  │  外部 CLI    │ │  MCP Server  │                     │
│  │  (lark-cli)  │ │  (feishu-mcp)│                     │
│  └──────────────┘ └──────────────┘                     │
└─────────────────────────────────────────────────────────┘

核心维度对比

维度	CLI	MCP	Skill
本质	工具实现	工具发现协议	工具使用知识
上下文占用	几乎为零（按需 --help）	高（每个工具 200-500 token）	极低（一句摘要）
启动延迟	中等（需要 --help 发现）	低（预加载）	低（但不干活）
工具规模适应性	优秀（理论上无限）	差（线性增长 token）	不直接受影响
双向通信	单向（仅请求→响应）	支持（资源推送、通知）	不适用
错误恢复	依赖 Agent 自己判断	依赖 Agent 自己判断	内置错误恢复策略
跨平台	需要安装 CLI 二进制	HTTP/WebSocket 即可	纯文本，无平台依赖

实战：OpenClaw + Hermes Agent 的三层架构

以 OpenClaw 生态为例，我们来看这三者在真实系统中的协同。

OpenClaw 是一个开源的 AI Agent Gateway，它的工具系统恰好同时使用了这三层架构：

第一层：Hermes Agent 的 Skill 系统（知识层）

Hermes Agent 内置了自进化技能系统——Agent 可以从对话中学习，自动创建新的 Skill 文件。这些 Skill 文件本质上是 Markdown 格式的操作手册，包含：

markdown# Skill: 钉钉日历管理

## 触发条件
-用户提到 "日程"、"会议"、"日历"
-用户提到具体日期 + "安排"

## 操作流程
1. 如果用户没指定日期，默认查本周
2. 使用 `dingtalk calendar list --range this-week`
3. 如果有冲突时段，主动提示
4. ...

## 异常处理
-AUTH_EXPIRED → `dingtalk auth refresh`
-NETWORK_ERROR → 重试 3 次，间隔 2 秒

这些 Skill 会随着使用不断进化——Agent 每次犯错后更新 Skill 文件中的异常处理策略。这就是"越用越聪明"的底层机制。

第二层：MCP Server（发现层）

OpenClaw 支持接入外部 MCP Server，为 Agent 提供标准化的工具发现能力。比如接入飞书 MCP Server 后，Agent 自动发现所有飞书 API 能力。

但 OpenClaw 的设计者很有见地——MCP 工具并不是默认全量加载到上下文的。而是通过 Tool Router 路由层，Agent 先看到工具摘要列表，选择后再加载完整描述。

这实际上是对 MCP 原始设计的一个重要改进——在"全量预加载"和"完全不可见"之间找到了一个中间点。

第三层：CLI 工具箱（执行层）

OpenClaw 的底层执行依赖 openclaw exec 命令——Agent 最终在沙箱终端中执行 CLI 命令。这层保证了：

1隔离性：工具执行在沙箱中，不能突破权限边界
2可审计性：每条命令都有日志，出了问题能追溯
3回滚能力：操作失误可以在沙箱中撤销

为什么 CLI 会赢？一个反直觉的判断

说实话，2025 年 MCP 刚火起来的时候，大多数人的判断是"MCP 会取代 CLI 成为 AI Agent 的主流工具接入方式"。因为 MCP 设计更"现代化"，有双向通信，有资源管理，有类型系统。

但 2026 年的现实走向恰好相反。

有三个原因，我来逐一解释：

原因一：上下文窗口是 AI Agent 最稀缺的资源

Agent 的上下文窗口就像人的"工作记忆"——它能同时处理的信息量是有限的。每多放一个 MCP 工具的完整描述，就少一块给推理和决策的空间。

OpenAI 在 2025 年底发布的 Agent SDK 内部文档中甚至明确建议：单个 Agent 实例接入的 MCP Server 不要超过 5 个。 如果需要更多工具，建议走 CLI 或 Skill 路线。

这基本宣告了"把所有 SaaS 都接成 MCP"这种大而全的愿景不太现实。

原因二：CLI 的生态壁垒已经形成

2026 年 4 月钉钉、飞书、企业微信扎推开源 CLI 之后，几乎所有主流 SaaS 产品都提供了 CLI 工具：

GitHub CLI (gh)
Vercel CLI
Notion CLI（非官方，但社区极其活跃）
Linear CLI
Figma CLI（2026 年 1 月发布）
Slack CLI（2025 年 11 月）

这个生态已经形成飞轮效应：开发者习惯用 CLI → 更多 SaaS 发布 CLI → AI Agent 有更多 CLI 可用 → 开发者更倾向于 CLI。

而 MCP Server 的开发门槛更高——你需要理解 MCP 协议规范，实现 JSON-RPC 通信层，管理连接生命周期。CLI 呢？写个 Go/Python 脚本，解析参数，输出文本就行了。

原因三：Skill 填补了 CLI 最短板

CLI 最大的弱点是什么？Agent 不知道怎么用，每次都要 --help 现学。

而 Skill 恰好解决了这个问题。Skill 提供的是"知识"，CLI 提供的是"执行能力"。两者是正交的：

Skill（知识层）: 知道该用哪个命令、什么参数、出错怎么恢复
     │
     ▼
CLI（执行层）:   在终端里跑命令，拿到结果

这个组合既保留了 CLI 的轻量和灵活，又补足了 CLI 的"新手不会用"问题。

结论：三层架构，缺一不可

回到开头的问题：CLI、MCP、Skill 到底怎么选？

答案是三个都要，但各司其职：

层级	角色	最佳实践
Skill	知识层	每个高频任务场景配一个 Skill，写好决策树和错误恢复
MCP	发现层	核心 3-5 个高频工具用 MCP 常驻，其余走 CLI
CLI	执行层	长尾工具全部 CLI 化，按需加载，用完即弃

如果把 AI Agent 比作一个人：

Skill 是他的经验——知道什么情况该干什么
MCP 是他桌面上的常用工具——伸手就能拿到
CLI 是他柜子里的工具箱——东西多得是，需要的时候去翻

人不靠桌面上永远摆着所有工具来提高效率，Agent 也一样。

2026 年的 AI Agent 工具调用战争，正在从"谁的 MCP Server 多"转向"谁的 Skill 系统更聪明 + CLI 生态更完整"。前者的天花板在上下文窗口，后者的天花板在——理论上没有上限。

参考来源：

唐巧《AI 干活的三件套：CLI、MCP 和 Skill 到底是什么？》(blog.devtang.com, 2026-04-03)
OpenClaw 官方文档 (openclaws.io)
Hermes Agent 自进化技能系统 (hermes-agent.org)
MCP 协议规范 (modelcontextprotocol.io)
Anthropic "Tool Selection in LLM Agents" 研究 (2025)
钉钉/飞书/企业微信 CLI 开源公告 (2026-04)

本文排版由(快发) api.kuaifa.art 提供