飞书 CLI 被开发者热捧的背后，我们看到了这几点
「古老」的 CLI 成为了 AI 时代的锚点。
「古老」的 CLI 成为了 AI 时代的锚点。
👦🏻 作者: GaKi
🥷 编辑: Koji
🧑🎨 排版: NCon
如果把 2026 年 AI 圈最低调、也最有意思的故事线画出来，大概是这样一条路径：
几乎所有厂商，都在做自己的 CLI。 从 Anthropic 的 Claude Code，到 OpenAI 的 Codex CLI，再到 Google 的 Gemini CLI，连 Vercel 这种以「好看」著称的产品公司，CEO Guillermo Rauch 都在 X 上直接发文：
CLI 就是 Agent 事实上的 MCP。
当这股潮流风吹到国内办公协同工具领域的时候，一开始大家其实难以理解这种「非图形化」的形式，好奇怎么反过来做这种「难以理解」的命令行？
但随着用的人越来越多，大家发现：办公协同工具一旦被 CLI 化，隐藏在图形界面里的能力，将会被完整、可调用、可编排地暴露出来。
其中一个非常典型的案例，就是飞书 CLI。其 3 月 28 日开源，到现在不到两个月，GitHub 上已经达到 1 万颗星。 这一增长速度和关注度在 SaaS 工具中已经算比较高的了。
对比来看，Google Workspace CLI 虽然已经达到了 2.6 万颗星，但光看 5.8 那一周的 npm 的下载量，查查 npm downloads API 的话，飞书 CLI 甚至要更高。从这些数据可以看出飞书 CLI 的受欢迎程度相当可观。
🚥
一个国内办公 SaaS 的命令行工具，短时间有这样的增长，值得我们停下来好好想一下。
接下来，分享我们的完整观察。
飞书 CLI 开源之后，创业者正在用它做什么？
先来说说飞书 CLI 开源之后，前沿的创业者正在用它构建什么，这样更好理解飞书、飞书 CLI 在整个工作流里的角色。
我们从开源社区、Demo Day 里，看到了 2 个比较有代表性的案例，整体来看可以总结为：「AI Native 的工作流」。
这几个案例的共同点是，他们都把飞书 CLI 当成自己工作系统里最底下的一块 AI Infra。
第一个人，张昊，他做了一个叫 NoteLoom 的产品。
NoteLoom 有意思的地方，在于它不是「对话框式 AI」，整个界面，是一张可以自由画的画板，用户能在上面组织多线程、多起点的知识工作流。
飞书在里面扮演的角色是数据底座。用户把飞书内容导进 NoteLoom 处理，做各种重组、推演、再加工，处理完，成果再沉淀回飞书。
如果从用户的工作流来看，NoteLoom 更像是飞书数据的一个「处理中间层」，真正的资产最后还是留在用户自己的飞书里。
我们联系到了张昊，在聊到这件事的时候，他给的判断是：Agent 真正需要的，是一个已经承载了组织真实工作的「事实源」，而文档、表格、会议、任务、日历、权限关系，本来就已经在飞书里了。
变化发生在接入飞书 CLI 之后。
张昊说，过去 Agent 是在处理用户给它的材料，用户得先把会议纪要、调研文档、表格数据复制进来。现在 Agent 可以在用户授权的工作空间里，直接读文档、查多维表、看日历，再把不同方向的结论生成到 NoteLoom 的画布上。
过去 Agent 拿不到企业里的真实数据，用户得自己去飞书翻资料、复制粘贴回 AI 产品，再让 AI 处理。
接入飞书 CLI 之后，Agent 能直接在数据所在的地方干活，不用再等用户复制粘贴。这其实就是 AI Native 工作方式真正发生的样子。
第二个人，Daniel，他做了一个叫 Pokoclaw 的开源项目。
Pokoclaw 是一套面向真实工作的个人 AI 助理系统，把飞书作为唯一的当前交互入口。
Daniel 给它定义了五个关键词：可执行、可观测、可操控、可长期协作、可自我改进。
每个词都对应一条具体标准。
而这套系统能成立的前提，是飞书给它提供了「工作空间」，Agent 在这里「上班」。
Daniel 自己在我们的访谈中说，飞书 CLI 对 Agent 来说，相当于提供了一套清晰、稳定、自动化的方式去使用飞书里的能力，这件事很 AI Native。
而且即使不看 CLI，飞书本身就很适合承载 AI Agent。它不只是聊天窗口，还有卡片、按钮、回调、群聊、thread、置顶、文档这些能力，所以 AI 和人协作可以做得很自然。
总结这 2 个人对飞书 CLI、以及飞书 AI Native 工作流，会很容易发现虽然「AI Native」这个词，在过去一年里几乎被讲烂了，但大部分时候它指的只是 UI 上多了一个对话框。
真正的 AI Native，是工具链本身就按 Agent 能用的方式被设计出来：结构化输出、最小权限、可调试、可组合。
而目前看来，飞书 CLI 再叠加上飞书原本就有的卡片、回调、群聊、thread 这些非聊天交互能力，能提供一个 AI Native 工作流的初级答案。
为什么飞书 CLI 这么被开发者热捧？
我们再回到飞书 CLI，在实际使用一段时间之后，我大致发现背后有 3 个比较具体的原因。
【1】底座够大。
飞书不是一个单独的 IM，也不是一个文档工具。它是把通讯、文档、多维表格、日历、视频会议、任务、OKR、审批、知识库、通讯录全部集合在一起的大平台。
每一个模块，对 Agent 来说都是一个非常真实的、可调用的能力。
在我的实际使用中，总的来说一共有 3 个需求，是非常想要被满足的，也是飞书 CLI 做的还可以的。
第一个是自然的交互方式，命令行里可以以自然语言调用，同时飞书应用本身就不用多说了，已经用的很熟了。
第二个是完整的业务运行环境。一个 Agent 想真正帮我做事，得能把查数据、生成分析、撰写方案、通知相关人员这一整条链路跑完。
飞书里这些模块是打通的，Agent 通过 CLI 拿到你的日程，能接着看到日程里那场会的纪要，纪要里提到的某个客户，能直接拉进通讯录查部门、发消息、建任务、起审批。
第三个是语境。飞书上有我在工作语境里沉淀很多年的消息、文档、日程、表格、妙记，这对 Agent 来说就是最好的信息来源。
比如，我可以直接在 Codex 里，通过自己做的飞书 CLI Skill，轮询「最近一个月我编辑过的云空间文档」：
这也是飞书在 AI 时代真正的护城河，工具可以复制，但多年积累的业务上下文，会非常增加粘性。
这 3 个能力，是飞书给 CLI 带来的，而不是 CLI 给飞书带来的。
【2】更新够快。
CLI 这种产品形态有一个很独特的属性，开发者每天用的频率是非常高的，所以使用者往往在调用一个命令时，立刻就有体感的反馈。
所以一个 CLI 好不好用，很大程度上看它能不能跟着开发者的实际反馈进行调整、每周都能调一调，对应的就是 GitHub Issue 和 PR 的处理速度。
飞书 CLI 开源 40 多天，迭代新增了 100 多项能力，32 个 release，平均一天半一版。而且，官方自建了一个「能力许愿池」，开发者在里面提出需求，很快就会看到对应的命令出现。
而且不只是飞书团队在写代码，这肯定是跟不上用户体验需求变化的速度的。
社区 50 多位贡献者里，有 10 位外部开发者的代码被合进了主干，在我们仔细翻了一遍后，发现里面有河南科大的后端实习生、土耳其 Hepsiburada 电商公司的工程师、越南的独立开发者，还有杭州再惠的工程师陈家名一周内连着两个 fix 合入。
一个国内办公平台的 CLI，开源第一个月就已经有了一个全球开发者共建的雏形。
【3】「Agent 友好」到底该怎么做？
具体使用的话，像我就会让 Claude Code、Codex 记录飞书 CLI 的所有能力，学习相关技术文档的内容，把飞书 CLI 做成 Skill，方便之后调用。
这种情况下，飞书 CLI 整体大致做了 3 层，会让这个 Skill 更好用：
最上面一层是 Shortcut，给人和 AI 共用的快捷命令，让常见任务以非常快速的方式完成。
中间一层是 API Commands，和飞书 OpenAPI 映射。
最底下一层就是 Raw API Calls，大致的效果就是即便 CLI 版本很旧，只要开放平台上新了 API，Agent 都可以直接通过 Raw API 去调用。
在三层之上，就是 Skills 了，Skills 把典型场景的最佳路径固化下来，Agent 可以直接用飞书已经总结出来的经验。
我大致调研了下，整体一共有 200 多个命令 + 2500 多个 Raw API + 一层 Skills 。这为之后的实际使用，做好了基础。
整体来看，开源迭代的好处是收敛到正确的速度。
AI 时代的产品迭代，最怕的是做错方向，开源加 CLI 这套组合，恰好让产品每天都在被真实场景修正。
对一个想把自己做成 Agent 工作空间的办公平台来说，这种速度就是一种非常大的优势。
所以，这股 CLI 潮流，为什么偏偏在 2026 年刮起来？
看完了前沿创业者正在拿飞书 CLI 做的事情以及飞书本身所提供的资源与能力，我们很容易有个疑惑：为什么 CLI，成了潮流？为什么 CLI 在 2026 年「复古」了起来。
从 2025 年底到 2026 年初，整个 AI 行业对「Agent 应该怎么用工具」这件事，集体换了个答案。
之前的答案是 MCP，这是 Anthropic 在 2024 年底推出的一套标准协议，给 Agent 定义了一种通用工具接口。
当时看起来几乎是完美的设计，所有工具按统一规范接进来，Agent 理解一套协议就能通吃。
但到了** 2026 年大家用 Agent 做长任务**的时候，问题慢慢出现了。
ScaleKit 在 2026 年 3 月发布了社区基准测试《MCP vs CLI: Benchmarking AI Agent Cost & Reliability》：
他们发现同一批任务分别用 CLI 和 MCP 跑，结果是 MCP 的 token 成本比 CLI 高 10 到 32 倍，任务一次成功率 72%，CLI 是 100%。
一个标准的 GitHub MCP Server 会话，只是加载工具 schema 就要消耗掉 55,000 tokens，Claude 200K 的上下文直接被削掉四分之一，这还没开始干活。
所以到 2026 年春天，那条「MCP 已死，CLI 当立」的帖子登上了 Hacker News 热榜。
Perplexity 的 CTO Denis Yarats 在 Ask 2026 大会上直接宣布，Perplexity 要从 MCP 切回 API 加 CLI。Y Combinator 的创始人 Garry Tan、Vercel CEO Rauch，都在差不多的时间点公开支持 CLI 这一边。
对 Agent 来说，CLI 可能是它出厂时，就已经内化的语言。
这也就解释了为什么 Claude Code 在不到一年时间里，能占到 GitHub commits 的 4%，为什么 Anthropic Q1 API 调用量同比涨了近 70 倍，主力就是跑在终端里的 Claude Code。
顺着这个逻辑再往下看，就能理解为什么办公协同工具这批厂商会在 2026 年初集体下场做 CLI。
对办公平台来说，CLI 是目前已知最便宜、最兼容、也最好接入 Agent 的 Harness 之一。
不用给每个 AI 工具单独写插件，不用维护 MCP Server，只要把自己的能力按命令的形式暴露出来，然后等 Agent 自己来调用就可以了。
一旦办公平台的能力以 CLI 的形式开放出来，Agent 就终于从聊天框里走出来，进入了真实工作区。
它可以直接帮你看会议纪要、发消息、建文档、查日程、改表格、走审批。办公软件的图形界面里的原本只属于人的动作、任务、执行、操作，变成了 Agent 也能按同一套规则做的事。
「古老」的 CLI 成为了 AI 时代的锚点
再深入一点， CLI 这种「最老」的界面，在 2026 年变成了 AI 时代很潮流的「中间层」。
过去二十年，整个软件行业都在把界面做得更像「给人用的」，按钮、菜单、拖拽、低代码、零代码，图形界面越来越复杂，门槛也越来越低。
但当 Agent 出现之后，事情开始反过来了。一个模型要跟软件对话，最难的是搞清楚「按钮」在哪、「菜单」要点几下才能进、「流程」走到了哪一步。
图形界面对人越友好，对模型大概率就越不友好，现在的 Agent CLI，反而要通过低效率的视觉 Use，去一点点拆解图形界面。
CLI 恰好是另一端。它是人、模型、系统三方都能看懂的最小公约数。当用户在命令行里输入
lark-cli calendar +agenda:
人能理解自己这是在查日程，模型能看懂这是一次函数调用，系统能看懂这是一次结构化 API 请求。
三方在同一个语言里，没有翻译成本。
现在看来，飞书 CLI 的 1 万颗星，很像是一个小小的坐标，指出了 2026 年 AI 和传统图形软件关系变化的节点 —— AI Native 在协同办公产品里的可能性，正在生长。
办公协同工具 CLI 化一开始看起来没什么「优秀之处」，但用着用着，「美妙和顺畅」感就出来了，也就成为了现在的「Fashion」。
因为 Agent 第一次真的有了一块地方，可以长期地、具体地、被人看得见地，干活。
十字路口正在寻找独立撰稿人，撰写 AI 产品和模型评测。
如果你写过类似文章：实测 PixVerse C1、实测 LibTV，请联系 zeo0811@gmail.com ，邮件内容请包括：① 个人介绍、② 你写过的 AI 评测文章。
我们会提供有竞争力的稿酬。期待与你一起观察与记录 AI 时代 🎪