CLI + MCP + Skill：2026年AI Agent开发的三大范式
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 的几个典型用法：
# 查日程
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：
# 它会尝试自己摸索
lark-cli doc read --id xxx --help
# 然后尝试各种参数组合
# 出错
# 重试... 很慢
有Skill的AI：
# 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能飞多高。
