从飞书和企微看Agent生态：CLI、MCP、Skill的边界与分工
企业微信和飞书最近都把办公能力搬到了云端接口上。同一批能力，现在有好几种不同的使用方式。
更有意思的是，两家几乎同时发布了各自的开源仓库：一个叫lark-cli（飞书），一个叫wecom-cli（企微）。翻开两个仓库的目录结构，你会发现几乎一模一样的三件套：
| 层级 | lark-cli（飞书） | wecom-cli（企微） |
|---|---|---|
| CLI命令 | 200+命令，14个业务域 | 覆盖通讯录、待办、会议、消息、日程、文档 |
| Agent友好的命令层 | shortcuts/ + cmd/service/ | 每条命令都为Agent设计 |
| Skill包 | skills/下22个SKILL.md | skills/下6个SKILL.md |
| Skill格式 | YAML frontmatter + Markdown | 完全一致 |
| 安装入口 | npm i @larksuite/cli | npm i -g @wecom/cli |
两家巨头没有商量过，却不约而同地收敛到了同一套目录结构、同一套SKILL.md规范。这个现象本身就是这轮生态演化里最强的信号：CLI + Agent命令层 + Skill包正在成为SaaS接入Agent生态的事实标准。
四个角色在解决不同问题
很多讨论把Agent、MCP、Skill、CLI混在一起讲。其实问一句"你在解决什么问题"，边界就很清楚了：
| 角色 | 定位 | 解决的问题 |
|---|---|---|
| Agent | 大模型+工具调用循环 | 什么时候该调用什么工具 |
| MCP Server | 工具能力的标准暴露层 | 把业务API翻译成Agent能理解的协议 |
| Skill | 业务编排与语义知识的载体 | 让Agent正确、稳定地用这些工具 |
| CLI | 终端/脚本直调通道 | 脱离Agent也能用，或为Agent提供本地脚手架 |
一句话总结：MCP告诉Agent能做什么，Skill告诉Agent什么时候做、怎么做、出错了怎么办，CLI让你就算没Agent也能做，Agent把这三者编织起来。
套回两个例子，分工是一样的：
wecom-cli：CLI层是wecom-cli contact get_userlist这类命令；Skill层是wecomcli-doc、wecomcli-msg等包，在SKILL.md里写明操作流程和注意事项。
lark-cli：CLI层是lark-cli docs create、lark-cli base records add；Skill层是22个包，沉淀了"wiki链接要先查真实token"、"多维表格写入前要先判断字段类型"这类业务知识。
两边的Skill都在做同一件事：把那些模型自己大概率会犯的错提前写下来，放进一份可版本化、可按需加载的文档里。
四条典型调用路径
路径A：Agent ←→ MCP（无Skill）
适合工具职责单一、参数自解释的场景。代价是Agent容易裸调翻车，工具一多就抓瞎。很多只做了MCP没做Skill的接入走的就是这条，全靠Agent自己摸索。
路径B：Agent ←→ Skill ←→ MCP（编排型）
适合跨多工具的业务流程、有状态依赖、需要异常处理的场景。典型例子就是飞书Skill：写入多维表格前先解析token、判断字段类型、失败时分不同情况处理。这些知识放system prompt太贵、放MCP tool description不合适、放Agent代码里每个平台都得重写一遍。Skill是这份知识最合适的地方。
路径C：Agent ←→ Skill ←→ CLI（混合模式）
适合不该走网络的本地动作：文件写入、密钥保存、git/npm调用。比如wecom-cli init交互式写本地凭证、lark-cli auth login把token存进钥匙串。这些让MCP去做不合适，让Agent直接走shell又不安全，CLI刚好填上这个缝。
路径D：纯CLI（无Agent）
定时任务、CI流水线、大批量操作。这里没有模型、没有自然语言、没有不确定性，Skill是多余的，CLI必不可少。
关键观察：这四条路径不互斥，同一份能力应该同时支持B、C、D。只做MCP不做CLI，CI场景就成了累赘；只做CLI不做Skill，Agent里用起来就很笨，每次都要用户亲口教它走流程。
Skill的本质
往本质看，Skill就是提示词工程，只是被包装成了可分发、可版本化、可按需加载的单元。
一个SKILL.md做的事情很朴素：
用frontmatter的description字段告诉Agent"什么时候该想到我"（触发条件、触发词、适用场景）
用正文告诉Agent"想起我之后该怎么做"（前置检查、步骤编排、调哪条命令、错误分支、话术）
Agent一启动并不会把所有Skill内容都塞进上下文，而是先扫一遍frontmatter当索引，命中才去读正文。这和传统system prompt把一切都前置塞进去的做法完全不同。Skill是一种"延迟加载的prompt"。
Skill的几种典型形态
同一套协议下，Skill会随着业务复杂度长成不同样子：
| 形态 | 定位 | 典型例子 |
|---|---|---|
| 说明书 | 把一类领域知识结构化喂给模型 | lark-doc里讲wiki_token必须先转换 |
| 单工具编排 | 包住一个工具，把调用规范、异常分支写死 | lark-base：多维表格的字段类型、权限、批量写入策略 |
| 工作流 | 跨多个工具组合出一个业务流程 | 查会议、读纪要、生成周报 |
| 元Skill | 用来生产其他Skill | 引导用户按模板写新的SKILL.md |
| 共享型 | 被其他Skill显式引入的公共片段 | 认证、权限、错误处理 |
| CLI绑定动作型 | 专门把本地副作用收口到CLI | 画板导出要走本地CLI才能写文件 |
Skill的形态是从"纯知识文档"一路演化到"多工具编排工作流"，光谱两端差别很大，但都用同一份SKILL.md规范表达。
为什么Skill不会被MCP或CLI吃掉
MCP吃不掉它：MCP只描述"我这个工具是什么"，不关心"你在什么场景该调我、挂了该重试还是告诉用户"。这些是跨工具的业务编排知识，不属于任何一个工具。
CLI吃不掉它：CLI是确定性执行流，没有意图识别层，也不能向Agent贡献语义知识。
system prompt吃不掉它：prompt是会话级的、不可版本化、不可被第三方复用分发。Skill可以像npm包一样被安装、升级、回滚。
你可以把Skill理解成给LLM用的SDK。只不过SDK的"API调用"在这里变成了"自然语言意图匹配+流程编排"。
未来三个值得关注的方向
方向1：Skill Runtime标准化
今天每家Agent平台的Skill约定都不一样，Cursor、Claude Code、OpenClaw各搞一套。长期一定会出现类似MCP的Skill Protocol，定义manifest、依赖、权限、激活、监测标准。谁先把这个协议做出来，谁就拿到比MCP更上游的分发层。MCP解决"工具能力标准化"，Skill Protocol要解决"智能行为标准化"。
方向2：Skill作为可组合单元
今天一个Skill解决一个场景。下一步是skill组合：飞书读文档加企微发消息，合成一个每日摘要。需要Skill之间能声明依赖、共享鉴权上下文、Agent端有多Skill调度层。有了组合能力，Skill生态才能从一堆孤岛变成可拼装的场景库。
方向3：Skill的自我进化
最有想象空间的是：用户演示几次怎么完成任务，大模型反向抽取流程，生成SKILL.md草稿，人工审核发布。同一个Skill发两个版本，后端收集完成率决出胜者。Skill激活时加载用户历史偏好，让同一份Skill对不同用户呈现不同行为。
三条建议
给正在把SaaS能力接入Agent生态的团队：
不要只做MCP，同时规划Skill和CLI。三者对应Agent交互、本地副作用、CI/脚本三种场景，缺一个就会有明显盲区。lark-cli和wecom-cli的目录结构可以直接抄。
把Skill当产品做，不是当文档。它有版本、分发、埋点、A/B测试、反馈闭环。评估标准是"Agent激活准确率"和"完成率"，不是"写得详不详细"。
鉴权、配置、埋点这些早点抽成SDK。做多个Skill的团队会发现重复代码一大堆，一套skill-sdk能把每个Skill的边际成本降一个数量级。
MCP是这一轮AI工具生态的传输层协议，它解决了工具能怎么被调。但要让AI可靠地完成业务流程，光有MCP不够，还需要Skill的编排语义，也需要CLI的确定性兜底。
飞书和企微两家的开源CLI放在一起看很有意思：两家都同时交付了CLI、Agent友好的命令层和Skill包，连目录结构都几乎一致。这种头部玩家不约而同的收敛，在技术生态史上通常意味着事实标准的雏形。
如果要给2026年的Agent生态挑一个关键词，我会选"Skill正在独立出来"。它不是MCP的附庸，不是CLI的翻译，不是system prompt的延伸。它会长成一个独立的、可分发、可组合、可度量的软件形态。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！