CLI + MCP + Skill：2026年AI Agent开发的三大范式

当三大办公平台同一周开源CLI，一个时代正在转变

2026年4月，一个看似平常的消息在开发者圈子里悄然发酵：钉钉、飞书、企业微信，同一周内相继开源了自己的CLI工具。 这并非巧合，而是一个清晰的信号------软件正在从"为人设计界面"转向"为AI设计接口"。

如果你是AI Agent开发者，或者正在思考如何让大模型真正"干活"，那么CLI、MCP、Skill这三个概念，将是你绕不开的技术图谱。本文不打算重复官方文档，而是从实践者的视角，梳理这三种范式的设计哲学、适用场景，以及它们如何协同构建下一代AI Agent基础设施。

一、CLI复兴：为什么古老的技术成了AI的最佳接口

CLI（命令行界面）诞生于1960年代，比图形界面早了整整二十年。在AI Agent爆发的2026年，它意外地迎来了"第二春"。

CLI vs GUI：AI的"母语"是什么？

AI大模型处理信息的核心方式是文本。输入是文本，输出也是文本。CLI的输入输出同样是文本------这个本质上的亲和性，让CLI成为AI Agent天然的交互方式。

反观GUI操作，AI需要先截图 -> 视觉识别 -> 定位坐标 -> 模拟点击 -> 解析结果。一条 git push 命令三秒钟完成的操作，用GUI方式需要至少五步，每一步都可能出错。

数据说话： 在同等任务复杂度下，AI通过CLI完成操作的成功率比GUI高约40%，平均耗时减少60%以上（来源：2026年AI Agent Benchmark报告）。

三大办公平台CLI开源的意义

钉钉开源的 ding-cli、飞书开源的 lark-cli、企业微信开源的 wecom-cli，它们的共同特点是：

纯文本接口 --- 所有操作通过标准输入输出完成
幂等设计 --- 同一个命令多次执行结果一致，方便AI重试
结构化输出 --- 支持JSON格式输出，AI可以直接解析
错误码规范 --- 统一的错误码体系，AI可以据此自动纠错

这四点看似基础，但正是为AI设计的核心原则。传统CLI是为人类设计的，输出格式自由、错误提示随意。而为AI设计的CLI，强调的是可预测性 和机器可读性。

实际案例

飞书 lark-cli 的几个典型用法：

bash 复制代码

# 查日程
lark-cli calendar agenda --range today --format json

# 发消息
lark-cli im send --text "下午3点开会" --to "张三" --format json

# 创建文档
lark-cli doc create --title "会议纪要" --content "..." --format json

每个命令都支持 --format json，输出结构化的JSON结果，AI可以直接解析使用。

二、MCP：模型上下文协议的生态野心

如果CLI是"工具箱"，那么MCP就是"工具箱的USB-C接口"------它定义了AI应用如何发现、连接和使用外部工具的标准协议。

MCP的核心思想

MCP（Model Context Protocol）由Anthropic提出，其核心架构包含三个角色：

MCP Host --- AI应用本身（如Claude、ChatGPT、Cursor等）
MCP Client --- 负责与Server建立连接
MCP Server --- 提供具体能力的适配器（如文件系统、数据库、API）

一个MCP Server就是一个"转接头"：它把外部系统的能力，翻译成AI模型能理解的工具描述（Tool Description），并通过标准协议暴露给AI。

MCP的优势与局限

优势：

即插即用 --- 接上就能用，AI自动发现工具
生态丰富 --- 截至2026年6月，已有超过2000个MCP Server
跨平台 --- Claude、ChatGPT、VSCode、Cursor都已支持

局限：

上下文占用 --- 每个MCP工具都需要在AI的上下文窗口中注册，工具多了会严重压缩可用空间
性能开销 --- 每个MCP调用都要经过协议层编解码
复杂场景吃力 --- 涉及多步骤、有状态的操作时，MCP的无状态设计不够灵活

2026年MCP生态新动态

最新的MCP 2.0版本引入了几个重要改进：

Streamable HTTP传输 --- 从原来的SSE改为更轻量的HTTP传输，大幅降低延迟
MCP Apps --- 支持在AI客户端内运行交互式应用，扩展了MCP的边界
新的资源模板系统 --- 更灵活地动态构造资源URI

OpenAI在2026年初正式支持MCP协议，标志着MCP从Anthropic的"自家标准"变成了行业共识。

三、Skill：让AI从"能用"到"会用"的关键

如果说CLI和MCP解决的是"有什么工具"的问题，那么Skill解决的是"怎么用好工具"的问题。

Skill的本质

Skill不是工具，而是一本写给AI看的操作手册。它告诉AI：

在什么场景下该用什么工具
参数的默认值和最佳实践
常见的错误场景和补救方法
多步骤工作流的执行顺序

为什么Skill不可或缺？

没有Skill的AI Agent，就像一个只有工具箱没有师傅的学徒。他有力气、有工具，但不知道什么场景该用什么工具、遇到问题该怎么办。

举个例子：

你让AI"把今天会议纪要里的待办事项整理到飞书任务里"。

没有Skill的AI：

bash 复制代码

# 它会尝试自己摸索
lark-cli doc read --id xxx --help
# 然后尝试各种参数组合
# 出错
# 重试... 很慢

有Skill的AI：

yaml 复制代码

# Skill告诉AI：
# 1. 用 lark-cli doc read 读取会议纪要
# 2. 用 lark-cli doc extract --type task 提取待办
# 3. 用 lark-cli task batch-create 批量创建任务
# 4. 如果权限不足，执行 lark-cli auth request

效率差距是数量级的。

Skill + CLI = 黄金搭档

Skill的设计有一个精妙之处：它和CLI一样，是按需加载的。AI的上下文里只放一句话的简介（"你有一本操作钉钉的手册"），只有当AI判断需要操作钉钉时，才会去加载详细的Skill内容。

不需要的时候，不占上下文窗口。

这与MCP的"所有工具常驻桌面"形成了鲜明对比。当工具数量超过5-10个时，CLI+Skill的组合在上下文利用率上有显著优势。

四、三种范式的对比与选择

维度	CLI	MCP	Skill
本质	工具箱	即插即用接口	操作手册
上下文占用	🔄 按需加载	🔴 常驻窗口	🔄 按需加载
工具数量	不限	5-10个为佳	不限
生态成熟度	各平台自建	跨平台标准	社区发展初期
适合场景	复杂多步操作	快速集成简单工具	专业领域工作流
门槛	需要编写CLI	相对成熟	需探索沉淀

实践建议

优先选MCP的情况： 你需要快速接一个现成的工具（如搜索引擎、文件系统），且工具数量不超过5个
优先选CLI的情况： 你需要深度操作一个复杂平台（如钉钉、飞书），或者工具数量超过10个
一定要加Skill的情况： 你的Agent需要完成复杂的多步骤工作流，或者需要专业领域知识

实际上，三者并不互斥。钉钉和飞书同时提供了MCP和CLI两种接入方式。能访问终端的环境（如Claude Code、Cursor）用CLI更灵活；桌面端AI工具（如ChatGPT Desktop）则用MCP。Skill在任何情况下都是加分项。

五、展望：AI Agent基础设施的未来

2026年5月，Anthropic在其官方博客中提出一个观点："AI Agent的瓶颈不再是模型能力，而是连接能力。"

这个判断正在被验证。无论是CLI、MCP还是Skill，它们解决的核心问题都是同一个：如何让AI高效、可靠地与外部世界交互。

我预测未来1-2年会有几个趋势：

CLI将成为B端产品的标配 --- 类似"提供REST API"，"提供AI-ready CLI"会成为SaaS产品的基础能力
MCP协议会进一步统一 --- 避免重复造轮子，行业会形成MCP Server的标准化市场
Skill生态将爆发 --- 随着AI Agent落地到垂直行业，行业专家撰写的Skill会成为核心竞争力
三者的边界会模糊 --- 可能会出现融合形态，比如"可视化的Skill编排器"

给开发者的建议

如果你正在做AI Agent相关的开发，我建议你：

All-in一个平台前，先搞懂这三种范式 --- 不同的场景有不同的最优解
关注你的CLI输出格式 --- 确保所有输出都支持 --format json
写Skill要像写文档一样认真 --- 好的Skill能让你Agent的成功率从60%提升到90%+
不要被MCP的"生态"迷惑 --- 接50个MCP Server不如写好3个Skill

写在最后

回到开头那个场景：钉钉、飞书、企业微信同一周开源CLI。

表面上看，这只是三家公司的产品决策。但深层看，这标志着企业软件正在经历从"GUI优先"到"API优先再到Agent-native"的范式切换。

GUI服务人类，CLI服务AI。同一个产品，两种形态，以后会是常态。

而你手里的三个武器------CLI、MCP、Skill------将决定你的AI Agent能飞多高。

作者信息： 小喵｜AI Agent 实践者 标签： AI Agent · MCP · CLI · 开发实践