飞书接入Agent：官方 CLI `lark-cli` 到底值不值得看？

2026年5月15日 · 3423 字 · 7 分钟 · 飞书 Lark-Cli AI Agent CLI 办公自动化

1779636736663

很多 Agent 还停留在会聊天、会写代码，但一碰到真实办公系统就容易卡住。

飞书官方开源的 lark-cli，真正有意思的地方，不是它又多了一个命令行工具，而是它正在把飞书里的文档、消息、表格、日历、任务这些能力，重新整理成一层更适合人和 Agent 一起调用的接口。

这不只是又一个命令行工具

最近我越来越关注一类项目：

它们不是在卷模型参数，也不是在卷聊天体验。

它们在解决一个更实际的问题：

如果 Agent 真要去做事，它到底该怎么碰真实软件。

写代码这件事，今天已经有不少成熟入口了。Codex、Claude Code、Cursor，这些工具至少证明了一件事：只要目标世界足够结构化，Agent 就能稳定推进任务。

但一离开代码编辑器，情况马上就变了。

你让 Agent 去碰企业办公系统，尤其是消息、日历、任务、文档、表格、审批、知识库这些高频协作能力，它很容易卡在两个地方：

一是 GUI 太脆，靠点按钮不稳；

二是 OpenAPI 太碎，虽然能调，但对人和 Agent 都不够顺手。

所以我这次看到飞书官方开源的 lark-cli，第一反应不是"又一个 CLI 工具"，而是：

飞书终于开始认真给 Agent 准备办公入口了。

从 GitHub 页面来看，这个仓库目前大约有 10.2k Star，最新版本是 v1.0.31，发布时间是 2025 年 5 月 14 日。这至少说明，它不是一个停留在概念层的 demo，而是在快速迭代的正式项目。

重新定义办公软件的调用层

如果只看 README，你很容易把它理解成"飞书版命令行 SDK"。

这么看不算错，但还是低估了它。

我更愿意把 lark-cli 理解成：

飞书在 Agent 时代的一层官方命令接口。

为什么这么说？

因为它从一开始就不是只为“开发者手敲几条命令”设计的。

README 开头写得很直接：这是飞书官方维护的 CLI，目标用户同时包括人类和 AI Agent。它覆盖 17 大业务域、200+ 命令、24 个 AI Agent Skills，而且很多设计明显是在给 Agent 降低调用门槛。

这就和传统 CLI 很不一样了。

传统 CLI 往往只是“把 API 包一下”。

但 lark-cli 更像是在做另一件事：

把飞书原本分散在各个产品模块和开放平台接口里的能力，重新整理成一层可发现、可组合、可审计的执行层。

这层执行层，人能直接用，脚本能接，Agent 也更容易接。

这才是它最值得看的地方。

它不只是命令多，更是思路变

前几天我写钉钉 DingTalk Workspace CLI（dws） 的时候，一个很强烈的感觉就是：

大厂办公软件正在补同一种基础设施。

表面看，一个是钉钉，一个是飞书；一个叫 dws，一个叫 lark-cli。

但它们想解决的问题其实很像：

怎么让一句自然语言，最后能稳定落到真实办公动作。

区别在于，lark-cli 这一版做得更“完整平台化”一些。

从 README 能看到，它覆盖的已经不只是消息和日历，而是从 IM、Docs、Drive、Markdown、多维表格、Sheets、Slides、Task、Mail、Wiki，一路扩展到了 VC、Minutes、Approval、OKR、Attendance，甚至还带了 workflow 类 skill。

换句话说，它不是只想帮你“发条消息”。

它想做的是：

让 Agent 能在飞书里穿过多个业务域，连成一条真实工作流。

它已经能做什么

如果只列能力清单，信息会很多。我挑几个最能说明问题的部分说。

1. 办公高频域基本都齐了

项目说明里列出的核心能力包括：

  • 日历：查看日程、创建日程、查询忙闲、找会议室、建议时间
  • 即时通讯：发消息、回消息、建群、搜消息、下载媒体
  • 文档与云空间：创建、读取、更新、搜索文档，上传下载文件，管理评论
  • Markdown：直接读写 Drive 原生 .md
  • 多维表格和电子表格：读写记录、字段、视图、导出和分析
  • 任务、邮箱、知识库、审批、OKR、会议纪要、妙记等

只看这一层，你已经能感觉到它不是“工具箱”，而更像是“办公操作系统的命令入口”。

2. 它不是只有命令，还有 24 个 Agent Skills

这一点特别关键。

很多项目嘴上说自己“支持 Agent”，结果实际上只是留几个 JSON 接口，剩下全靠提示词工程师自己补。

但 lark-cli 把这件事往前推了一步。

项目说明里直接列出了 24 个 AI Agent Skills，比如：

  • lark-calendar
  • lark-im
  • lark-doc
  • lark-drive
  • lark-markdown
  • lark-sheets
  • lark-base
  • lark-task
  • lark-mail
  • lark-approval
  • lark-workflow-meeting-summary
  • lark-workflow-standup-report

这意味着它不是只提供 API。

它还在提供一套让 Agent 更容易学会怎么用这些 API 的操作层。

这件事很值钱。

因为真正阻碍 Agent 落地的，很多时候不是“能力不存在”，而是“能力太散，调用太难，参数太烦，成功率太低”。

三层调用架构，各有用途

项目说明里有一句我很认可：

快捷命令 → API 命令 → 通用调用。

这其实是在解决一个长期被忽略的问题：

不同角色，需要的控制粒度根本不一样。

第一层：快捷命令

比如：

lark-cli calendar +agenda
lark-cli im +messages-send --chat-id "oc_xxx" --text "Hello"

这一层明显是给“人类用户”和“轻量 Agent 调用”准备的。

优点是上手快、参数少、默认值友好，还支持 dry-run。

第二层：API 命令

这一层和飞书平台端点做一一映射，适合更明确、更稳定的自动化场景。

第三层：通用 API 调用

如果前两层不够，就直接调用任意开放平台端点，覆盖 2500+ API。

这个设计最厉害的地方，不是“层数多”，而是它很现实。

它没有假装所有用户都该被迫走同一层抽象，而是承认：

有人只想快速搞定任务；

有人需要和平台严格对齐；

还有人就是想把底层能力完整暴露给 Agent。

这种分层，比一味追求“统一优雅”更适合真实落地。

Agent 友好不只是支持 JSON

不少工具一提 Agent 友好，最后就只剩一句"支持结构化输出"。

lark-cli 更实在一些。

1. 它把 AI Agent 的安装流程单独写出来了

项目说明里专门给了"快速开始（AI Agent）"，不是顺手提一句，而是明确告诉你：

  1. 先安装
  2. 再配置应用凭证
  3. 再做授权登录
  4. 最后验证状态

而且 config init --new、auth login --recommend 这类命令，还专门考虑了授权链接回传给用户的协作路径。

这说明维护者不是把 Agent 当营销词，而是真的拿 Agent 场景走过一遍。

2. schema 自省能力非常重要

项目说明里支持：

lark-cli schema
lark-cli schema calendar.events.instance_view
lark-cli schema im.messages.delete

很多人会把这个理解成“查文档方便”。

但站在 Agent 视角，这其实是在解决更根本的问题：

不要把所有工具知识硬塞进提示词。

更稳的方式是先发现能力，再看参数，再决定怎么调用。

谁能把这一步做好，谁的 Agent 调用成功率就更高。

3. --dry-run、分页、格式输出都很实用

企业办公和个人脚本不一样。

你发错消息、写错表、改错文档，后果都可能是真实的。

所以 --dry-run 这种预演机制很重要；--format table/json/ndjson/csv 这种输出分层也很重要；--page-all、--page-limit 这些分页控制同样重要。

这些东西单看都不是 headline 功能，但它们决定了一个工具到底是"能演示"，还是"能拿来持续干活"。

安全态度决定成败

很多 AI 工具最喜欢把"自动化"讲得很轻巧，像是什么都能一键完成。

但 lark-cli 在项目说明里专门拉出一大段安全提示，明确提到：

  • AI Agent 调用飞书开放平台存在模型幻觉、执行不可控、提示词注入等风险
  • 授权之后，Agent 会在你的权限范围内以用户身份执行操作
  • 不建议主动放开默认安全配置
  • 更建议把机器人当私人对话助手，而不是直接拉进群聊

我反而觉得，这种写法比一味炫技靠谱得多。

因为真正做企业自动化的人都知道，权限和边界从来不是“附录”，而是主线问题。

能把风险直接写在项目说明里，说明这个项目至少不是只想做一层漂亮壳子。

普通用户更要关注它的意义

如果你不是开发者，可能会觉得：这不就是个终端工具吗，和我有什么关系？

关系其实不小。

因为它背后代表的不是“命令行回潮”，而是：

办公软件正在重新为 Agent 设计可调用接口。

今天你看到的是 lark-cli。

明天你更可能看到的是：

  • 飞书里的任务、消息、日历、文档不再只是人手点点点
  • 它们会逐步变成可以被 Agent 编排的流程节点
  • 很多跨工具协作，最后都会沉淀成命令、skill、workflow 这类更稳定的中间层

从这个角度看，lark-cli 值得关注的，不只是“它好不好用”。

更重要的是，它很可能代表了飞书接下来对 Agent 办公入口的官方思路。

一个信号：办公入口正在重新定义

如果你只把 lark-cli 当成"飞书官方出的命令行工具"，那你看到的只是表层。

我更愿意把它看成：

飞书正在把自己的办公能力，从 GUI 和零散 API 之间，再抽出一层真正适合 Agent 调用的执行接口。

这件事一旦跑通，影响不会只停留在开发者圈。

因为 Agent 真正进入办公现场，靠的从来不只是模型会不会说话，而是有没有稳定入口去做事。

而 lark-cli，至少已经把这条路铺出来了。

项目地址：

https://github.com/larksuite/cli


如果你也在关注 AI Agent、办公自动化、企业协作工具怎么真正接进工作流，可以关注我。后面我会继续把这类工具拆成“官方能力做到哪了、普通人值不值得上、团队怎么少踩坑”三件事。觉得这篇有用，欢迎收藏，也可以转发给正在折腾办公 AI 的同事朋友。